By default, use an indent of 2, which is the same as what 'jq' uses.
This omits the need for 'jq' in the example usage. Also, add a new
line to the output while at it.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The real file is utils/generate-cyclonedx,
not utils/generate-cyclonedx.py.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Check if the script shall read from stdin if data is piped into.
Otherwise read from the input file or if not specified print usage and
exit.
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There is a growing need to generate software bill of materials (SBOM) from
buildroot configurations. Right now there are different solutions available
for buildroot users `show-info`, `legal-info` and `pkg-stats`.
They all generate similar information but in a format that is specific
to buildroot.
CycloneDX is a SBOM specification that can be consumed by different services.
This patch introduces a Python script, that converts the JSON output of the
show-info Makefile target to a CycloneDX-style SBOM.
The script output contains the following information.
- A list of all packages, or "components" with information about
version, cpe (if available), applied patches.
- By default virtual packages are not listed in the SBOM.
- Additional information is added to the component 'properties' to
specify wheter the component is present on the target or the host
under the `BR_TYPE` property name.
- An overview of the licenses applicable to each package. If possible,
the names of these licenses have been matched to known SPDX license
identifiers.
- Per package, a list of (recursive) dependencies on other packages.
- A list of ignored CVE and their associated component.
More information on CycloneDX at https://cyclonedx.org/.
Usage:
make show-info | utils/generate-cyclonedx.py | jq '.'
Example output:
```
{
"bomFormat": "CycloneDX",
"$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
"specVersion": "1.6",
"components": [
{
"bom-ref": "busybox",
"type": "library",
"name": "busybox",
"version": "1.36.1",
"licenses": [
{
"license": {
"id": "GPL-2.0"
}
},
...
],
"cpe": "cpe:2.3:a:busybox:busybox:1.36.1:*:*:*:*:*:*:*",
"pedigree": {
"patches": [
{
"type": "unofficial",
"diff": {
"text": {
"content": "..."
}
}
}
]
}
"properties": [
{
"name": "BR_TYPE",
"value": "target"
}
]
},
...
],
"dependencies": [
{
"ref": "busybox",
"dependsOn": [
"host-skeleton",
"skeleton",
"skeleton-init-sysv",
"skeleton-init-common",
...
}
...
],
"vulnerabilities": [
{
"id": "CVE-2022-28391",
"analysis": {
"state": "in_triage",
"detail": "The CVE 'CVE-2022-28391' has been marked as ignored by Buildroot"
},
"affects": [
{
"ref": "busybox"
}
]
},
...
],
"metadata": {
"component": {
"bom-ref": "buildroot",
"name": "buildroot",
"type": "firmware",
"version": "2024.02-4744-gafea667f00-dirty"
}
}
}
```
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Co-authored-by: Matthias Swiggers <matthias.swiggers@mind.be>
Reviewed-by: Vincent Jardin <vjardin@free.fr>
[Arnout:
- alphabetically order imports;
- use endswith instead if 'in' to check suffix;
- add usage to help text;
- remove .py suffix.
]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Currently, our docker-run helper will decide on its own whether it
should use docker (preferred) or podman (fallback), as introduced in
9a629f5129 (utils/docker-run: allow running with Podman). In case
both are installed, it is not possible to exercise the podman case.
Often, 'docker' is just an alias for 'podman' when both are available,
but this is not always true - and in the latter case, the user needs to
be able to choose which one they want.
Allow the user to force the one to use, by setting the BR2_DOCKER
environment variable. If that is set and it doesn't exist, exit with
an explicit error message (rather than relying on the failure when
eventually exec-ing the specified command).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Cc: Julien Olivain <ju.o@free.fr>
Cc: Fiona Klute <fiona.klute@gmx.de>
Reviewed-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
We want to redirect both stdout and stderr to the log, so just do both
redirections at once. This simplifies the call to make, which was
inherited from afdb545b28 (tools: new tool to filter the output of
make) when brmake was using unbuffer (and even then it was not entirely
waranted to do the redirection that way).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
All our documented uses of utils/docker-run, besides running it
standalone to get an interactive shell, is to use it as a prefix
to the otherwise standard command to run, e.g.:
- ./utils/docker-run make foo_defconfig
- ./utils/docker-run make menuconfig
- ./utils/docker-run make
- ./utils/docker-run make check-package
Commit 8aad67f157 (utils/brmake: add option to run in docker) departed
from that usual convention, by hiding the call to docker-run inside
brmake, conditioned by an environment variable. The only reason is that
brmake internally used ubuffer. This is no longer the case, so we can
now use brmake together with docker-run in the usual manner.
This basically reverts commit 8aad67f157,
after resolving the conflict due to the removal of unbuffer in te
previous commit.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
When it was introduced in afdb545b28 (tools: new tool to filter the
output of make), brmake made use of unbuffer, so as to try and ensure
that no output would get lost between make printing it, and the logger
loop time-stamping it and storing it in the logfile, in case the user
would interrup the build (SIGINT, ^C)
However, unbuffer is missing in our reference build image (we could have
added it, but we missed the occasion to do so every time we updated the
reference build image).
Furthermore, the rationale for using unbuffer, although reasonable, is
not so practical: indeed, when the user hits Crtl-C, this is inherently
asynchronous, and they can't expect everything to be entirely cleanly
terminated, especially buffering. Using unbuffer is thus slightly
superfluous.
The timestamps will be slightly off because of buffering, but a build
generates so much output that this won't be a problem in practice.
Drop use of unbuffer.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
SC2086 is now reported for missing Double quote around
$FN since shellcheck 0.9.0:
In utils/config line 175:
if grep -q "# ${BR2_PREFIX}$ARG is not set" $FN ; then
^-^ SC2086 (info): Double quote to prevent globbing and word splitting.
In utils/config line 178:
if V="$(grep "^${BR2_PREFIX}$ARG=" $FN)"; then
^-^ SC2086 (info): Double quote to prevent globbing and word splitting.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit [1] introduced the BR2_BROKEN hidden symbol. The intent of
this symbol is to temporarily mark a configuration known to be broken.
This commit was added to fix an undefined usage of the symbol, in a
previous commit [2].
With this somewhat special symbol, it is also perfectly normal to
have no use of it.
Running the command "utils/check-symbols" in a state there is no usage
of the BR2_BROKEN, the script fails with output:
Config.in:15: BR2_BROKEN defined but not referenced
This commit adds an exception for this symbol, allowing it to be
unused in the whole Buildroot tree.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/8925433382
[1] 2ddc5808cd
[2] 11a8cdd2bb
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
For the `b4` tool to support check-package, check-package must support
reading patch files from stdin.
It would be complicated to make check-package actually run checks on
patch files. So instead we search the patch files to figure out what
files are modified in the repo, then run check-package on the modified
files directly.
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
[Arnout: rename variable "files" to "files_to_check"]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
It is very common to use the output of get-developers to add cc: lines
in the commit log.
Add an option so that get-developers reports Cc: lines ready to be
pasted in a commit log. That new option behaves similarly to the
existing -e option: it only affects the output when parsing a patch.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The list of reported developers is not ordered: that may leave the
impression (when receiving a patch) that a Cc is more important than
another, by virtue of being earlier in the list.
Also, the ordering changes on every call.
Report the developers in an alphabetically order, so that there is no
confusion anymore, and so the ordering is reproducible across calls.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
It is very common that get-developers be used with its stdin a pipe from
git-show:
git show |./utils-get-developers -
In this case, the '-' is superfluous: we can very easily deduce that the
user wants to read stdin as the patch.
So, if no other action was requested, and stdin is not a tty, use it as
the source of the patch, and thus '-' is then no longer required.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
parser.error() reports a nice error message, that also displays a short
reminder of the available options.
Adapt the test-suite accordingly: previously, the error string was an
exact string in the stdout list, while it now is a substring in one of
the strings in stderr. The exit code changes, too.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Offloading parser.parse_args() to a helper function does not bring much,
if at all; it even is restrictive: indeed, we can't use parser.error()
to report errors and thus have to resort to a canned print+return
sequence...
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As we have many python packages using the poetry(poetry-core) build
system we should add a setup type for it so that we don't have to
manually specify the host-python-poetry-core dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
When BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y,
BR2_LINUX_KERNEL_IMAGE_TARGET_NAME is supposed to be non-empty. But in
the context of genraconfig, we don't know to what value
BR2_LINUX_KERNEL_IMAGE_TARGET_NAME can be set, so let's avoid cases
where BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM=y. By dropping this option,
kconfig will revert back to the default image format for the selected
architecture.
Fixes:
http://autobuild.buildroot.net/results/1d104a051c83bb31e98565369a2ec7badfa21eca/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The check-package tool requires some PyPi package to be installed before
it can run. This is typically done by manually installing them into the
user's global Python environment or setting up a virtual environment,
then manually installing each dependency.
Python recently defined a format for managing script dependencies as
inline metadata[1]. This can be used with the `uv` tool to run a Python
script and automatically install the minimum required version of Python
and PyPi dependencies.
With this change, it's now possible to run check-package with
uv run -s ./utils/check-package
Note that, because check-package does not have the '.py' file extension
we must specify the `-s` or `--script` argument. That argument was added
very recently in release 0.4.19[2].
I set the minimum python to 3.9 as that is the oldest version still
supported[3]. I verified 3.9 works by running
uv run -p 3.9 -s ./utils/check-package `git ls-tree -r --name-only HEAD` --ignore-list=.checkpackageignore
[1] https://packaging.python.org/en/latest/specifications/inline-script-metadata/#script-type
[2] https://github.com/astral-sh/uv/releases/tag/0.4.19
[3] https://devguide.python.org/versions/
Signed-off-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As we have many python packages using the hatch(hatchling) build
system we should add a setup type for it so that we don't have to
manually specify the host-python-hatchling dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
At the moment, it is difficult to combine brmake with docker-run.
`docker-run brmake ...` doesn't work because our docker image doesn't
have unbuffer. In addition, inside the container the timezone is UTC,
but you probably want the timestamps added by brmake to be in local
time. Therefore, it's better to have the call to docker-run nested
inside brmake.
Currently, brmake doesn't have any way to pass parameters, all of "$@"
is passed unchanged to the `make` invocation. Thus, there is no
established way to pass in the option whether or not to use docker. We
choose to use an environment variable to pass in the option. The
convention is that such a buildroot-specific environment variable should
start with BR2_, so we choose BR2_DOCKER.
Run make inside docker-run if the BR2_DOCKER environment variable is
set. Update utils/readme.txt (the only existing documentation of brmake)
with this information.
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some projects use pyproject.toml without setting a build backend, per
pep517 we should simply fallback to using setuptools when no build
backend is specified.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The imp module is deprecated as of python verison 3.12.
Refactor setuptools handling to remove monkeypatching hack and
instead do pep517 metadata generation and dependency resolution.
This is effectively done by implementing the minimal neccesary
pep517 frontend hooks needed for dependency resolution in scanpypi.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Tested-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reviewed-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
[Arnout: add license info]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Tweaking this variable should allow us to get better coverage of
packages with larger dependency trees.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 2f260084d5 (utils/genrandconfig: remove support for toolchain
CSV) kept the --no-toolchains-csv option, but in the rework forgot to
keep it as a bool, while argparse default is to expect a string.
Rather than re-introduce the action="store_true" which implies the
argument is a bool, explicit make it a bool.
Fixes: 2f260084d5
Reported-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Right now, genrandconfig just spits out the random messages from the
different make invocations, which isn't terribly useful. Instead,
let's redirect the output of make invocations to oblivion, and add
some more high level logging.
As part of this logging, we're interested to see how many iterations
were needed to find a valid configuration, so changed the loop logic
to count from 0 to 100 instead of from 100 to 0 so that we can easily
show the iteration number.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In order to test that upstream sites are still working, we need to NOT
fallback to sources.buildroot.net for some builds.
As there is anyway a local cache in the autobuilder instances, we need
to do quite a lot of builds without any BR2_BACKUP_SITE configured to
have a chance to catch issues, which is why a 50% chance is used to
unset BR2_BACKUP_SITE.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Before calling randpackageconfig/randconfig, we were pre-generating a
snippet of .config with:
(1) minimal.config
(2) BR2_CURL/BR2_WGET settings
(3) some random selection of init system, debug, runtime debug, etc
(4) enabling BR2_REPRODUCIBLE=y when diffoscope was found
Now that we only use randconfig, this whole fine-tuning is completely
irrelevant, as it gets overridden by "make randconfig".
(1) and (3) above are useless, as randconfig does all the
randomization that is needed.
However, we want to preserve (2) and (4) above, so we re-implement
those fixups, but *after* randconfig has done its job.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that the support for generating a fully random configuration has
been well-tested, the whole mechanism based on a toolchain CSV isn't
really useful anymore, so let's drop it to simplify the logic.
Note that the autobuilder code still uses --{,no-}toolchains-csv, so we
can't remove those or the autobuilders would fail. Once all supported
branches no longer use those argumetns, we can drop them from the
autobuilder code, then ask people to update their runners, and we will
finally be able to drop those arguments. Eventually.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: keep --{,no-}toolchains-csv and explain why]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We have accumulated a whole bunch of very old fixups to avoid issues
with super old CT-NG toolchains, which we are not testing anymore, so
remove those fixups.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We do have a few shell scripts that have source directives (either with
'source' or with '.'), and they all are currently either globally
ignored in .checkpackageignore, or have shellcheck directives to ignore
the source statement (SC1090).
So, we can safely instruct shellcheck where to lookup for sourced files;
that does not trigger any new error.
This will alow fixing some shellcheck errors in later commits.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
[Arnout: use long option]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Currently, how to run the check-package test-suite is thoroughly under-
documented. There is one hint in the commit log for commit fc254881e6
(utils/checkpackagelib: add unit tests), and another in commit
242e9d72e7 (utils/docker-run: new script); the former is hard to find,
and the latter is about an unrelated script, so harder yet to find...
Add a new option to check-package, that will make it run its test-suite.
Since pytest is only needed for the test-suite, only import it in that
case.
pytest will be default create a cache of the tests (not sure what it is
about, though), so instruct it not to (esp. since the tree can be
read-only).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
[Arnout: move the code into checkpackagelib.base]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
User may get confused when they see the current hint, and take that as
the proper replacement, while we're only reporting the stem of the
variable name:
.../foo.mk:16: possible typo: BLA -> *FOO*
There is usually no easy way to actually suggest the proper variable
name, though, so let's make it a little bit more obvious that we meant
the variable was improperly prefixed:
.../foo.mk:16: possible typo, variable not properly prefixed: BLA -> *FOO_XXX*
And while at it, throw in the URL to the corresponding manual entry.
Adapt the test accordingly.
Reported-by: "Frager, Neal" <neal.frager@amd.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Reviewed-by: Neal Frager <neal.frager@amd.com>
[Arnout: also update new test, scoped -> prefixed]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Currently, when a package defines an unprefixed variable, but its value
contains a properly prefixed expansion (or even just the name of a
variable), there is not error reported (e.g. with the recently fixed
composer issue):
BASE_SITE = https://getcomposer.org/download/$(COMPOSER_VERSION)/composer.phar
The reason is that he check is done on the whole line, rather than on
the variable that is being set.
We fix that by really looking at the variable we found, instead of
looking in the whole line.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Each linux tool uses a fragment of a .mk file, named, for instance:
package/linux-tools/linux-tool-cpupower.mk.in
So currently check-package does not check these files.
Add the support in check-package script.
At the same time, factor out a function to derive package prefix from
the filename being checked, so the fix (calling os.path.splitext twice)
can be applied in a single place.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
[Arnout: add docstring and explain double splitext to
get_package_prefix_from_filename]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
genrandconfig is used in autobuilders, and some autobuilders are running
on old distributions that are lacking the most recent CAs, causing build
failures because package sources can't be retrieved.
Do for the curl backend what we already did a while back for the wget
backend, with commit 0866a280e4 (utils/genrandconfig: use
--no-check-certificate in wget by default); in curl, the equivalent
would be --insecure, and applies to the ftps transport.
The integrity of the downloads are validated against our bundled hashes
so there is no risk of corruption of the downloaded files. The only
issue would be that an MITM could inspect the transaction, the same way
as for the wget --no-check-certificate in 0866a280e4, but this is not
considered a high-level issue (we're anyway talking FTPS here, that's a
legacy protocol that has other issues).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we no longer use WGET to retrieve FTP-hosted files, we can drop
the --passive-ftp option from genrandconfig, as it would cause
problems on systems that use wget2.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We can use urllib.request without adding any addition lines of code
compared with requests which is not part of the stdlib.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Along with the version bump, a number of the patches have been dropped
or reworked.
Compiled shared module builds are now disabled via py_cv_module_* = n/a
when possible (see PY_STDLIB_MOD_SET_NA). Leveraging this method allows
dropping numerous patches.
Note: this method does not work when access to a compiled module is
wrapped by a python-based module such as sqlite, tkinter, etc. In these
cases, configure knobs are still required to disable these modules and
their wrappers.
Both setup.py and distutils are no longer utilized upstream, so patches
have been dropped or adjusted accordingly.
Patch 0007 has been dropped, the Xtensa architecture can avoid compile
errors by using a toolchain with kernel headers newer than 3.17 [0].
That would require a new, non-trivial dependency to be added, but it
would also need to be propagated to all packages that select python3; as
we consider xtensa with old headers to be a corner case, we decide to
not address the issue, and rather add an exclusion in genrandconfig to
avoid the issue in autobuilders.
Patch 0026 has been dropped, the issue is fixed in uClibc v1.0.37+ [1].
Note: uClibc is not generally supported by upstream CPython.
While we're making assumptions about uClibc, ac_cv_func_wcsftime=no is
no longer set as it was fixed in v1.0.0 [2].
Co-developed-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Co-developed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[See 36e635d2d5]
Co-developed-by: Roy Kollen Svendsen <roy.kollen.svendsen@akersolutions.com>
[See 687b96db4d]
[0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f61bf8e7d19e0a3456a7a9ed97c399e4353698dc
[1]: https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/libcrypt/crypt.c?id=2f6076cdaada2132b670b5ef25ad80c76a916c5a
[2]: https://lists.uclibc.org/pipermail/uclibc/2014-November/048723.html
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
[yann.morin.1998@free.fr;
- extend the commit log for the xtensa headers case
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
