create_npm.py duplicated the logic for matching licenses from files and
also finding them. This patch refactors the code to reuse the license
utils. This will make the code more maintainable and also align both
behaviors. For instance, some licenses weren't matched properly because
the duplicate logic did not support the difference in format in the md5
tables for COMMON_LICENSE_DIR and licenses.csv.
This is also faster since the license files were being read twice.
The result is slightly more accurate since the utils have better
implementations, and I was able to reuse the logic for the root PN
package, as well as the base LICENSE variable.
I chose to extract generate_common_licenses_chksums into create.py
since it can be considered a general utility function to allow
other recipetool creators to refer to COMMON_LICENSE_DIR files.
I updated the wording in the code when appropriate.
v3:
- added commit
- this replaces the commit that added all the COMMON_LICENSE_DIR md5
to licenses.csv
(From OE-Core rev: 7bc18bed63b94689890bcde63402d7cc1cedffa9)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The npm recipetool handler redefines the license code the could be
unified. In order to do this refactoring, extract the bits we'll
need into separate functions.
guess_license() is renamed to find_licenses() and is split into
find_license_files() and match_licenses().
(From OE-Core rev: f1ec28feaea8ea6a2df894dd4ddba561c8a04ed2)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some npm packages do not copy the LICENSE or COPY file into their
git repository. They'll instead simply use SPDX identifiers in their
package.json. A fallback for those repositories attempted to match
the README file to a license file instead, which had a very low
probability of success.
This commit replaces this fallback with parsing the package.json and
looking for the license in COMMON_LICENSE_DIR. If the license is not
found, "Unknown" will still be produced.
This also generates "Unknown" for packages which had no README file,
which could silently not appear in the generated recipe. The user was
more likely to miss them.
Co-authored-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
(From OE-Core rev: 445604cfc4a5813ea635f18053cd1f673bf0b830)
Signed-off-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Our current emulation mandates that the package.json contains a version
field. Some packages may not provide it when they are not published to
the registry. The actual `npm pack` would allow such packages, so
should we.
This patch adds a default value to allow building such packages.
This applies for instance to this package which doesn't declare a
version:
- 23701a555a/package.json (L2)
v3:
- Split bitbake npmsw.py modification in another commit
Co-authored-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
(From OE-Core rev: 470c4c027c2b8bbecf23aa63650a22a312de9aa6)
Signed-off-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We fetch npm dependencies from the npm-shrinkwrap.json file. They can
point to a package on the NPM registry with a version field, or to a
git/http/file URL with the resolved field. Such packages are allowed not
to declare a registry version field because they may not have been
published to the NPM registry. The previous implementation refuses to
fetch such packages and throws an error.
The resolved field contains the exact source, including the revision,
wich we can use to pass as SRC_URI to the git/http/file fetcher. The
integrity field is also mandatory for HTTP tarballs which will ensure
reproducibility. So even if the version field is not present, we are
still fetching a precise revision of the package.
Another commit published along this stack is also required in the npm
class to support these packages.
v5:
- improve commit message
v3:
- Split bitbake npmsw.py modification in another commit
Co-authored-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
(Bitbake rev: 209982b5a3efc8081e65b4326bf9b64eef7f0ba0)
Signed-off-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The NPM package.json documentation[1] states that git URLs may contain
a commit-ish suffix to specify a specific revision. When running
`npm install`, this revision will be looked for on any branch of the
repository.
The bitbake implementation however translates the URL stored in
package.json into a git URL to be fetch by the bitbake git fetcher. The
bitbake fetcher git.py, enforces the branch to be master by default. If
the revision specified in the package.json is not on the master branch,
the fetch will fail while the package.json is valid.
To fix this, append the ";nobranch=1" suffix to the revision in the git
URL to be fetched. This will make the bitbake git fetcher ignore the
branch and respect the behavior of `npm install``.
This can be tested with the following command:
$ devtool add --npm-dev https://github.com/seapath/cockpit-cluster-dashboard.git -B version
Which points to a project which has a package.json with a git URL:
```json
"devDependencies": {
"cockpit-repo": "git+https://github.com/cockpit-project/cockpit.git#d34cabacb8e5e1e028c7eea3d6e3b606d862b8ac"
}
```
In this repo, the specified revision is on the "main" branch, which
would fail without this fix.
[1] https://docs.npmjs.com/cli/v10/configuring-npm/package-json#git-urls-as-dependencies
Co-authored-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
(Bitbake rev: 37a35adf7882f231c13643dbf9168497c6a242a1)
Signed-off-by: Tanguy Raufflet <tanguy.raufflet@savoirfairelinux.com>
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When tasks fail, it's very frustrating to have to scroll up to find the
log path(s). Many of us have the muscle memory to navigate to the 'temp'
directories under tmp/work/, but new users do not.
This change enhances the final summary to include log paths (reported
via bb.build.TaskFailed events). Here's an example:
NOTE: Tasks Summary: Attempted 856 tasks of which 853 didn't need to be rerun and 3 failed.
Summary: 3 tasks failed:
virtual:native:/home/chris/repos/poky/meta/recipes-core/ncurses/ncurses_6.5.bb:do_fetch
log: /home/chris/repos/poky/build/tmp/work/x86_64-linux/ncurses-native/6.5/temp/log.do_fetch.1253462
/home/chris/repos/poky/meta/recipes-core/ncurses/ncurses_6.5.bb:do_fetch
log: /home/chris/repos/poky/build/tmp/work/core2-64-poky-linux/ncurses/6.5/temp/log.do_fetch.1253466
virtual:nativesdk:/home/chris/repos/poky/meta/recipes-core/ncurses/ncurses_6.5.bb:do_fetch
log: /home/chris/repos/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-ncurses/6.5/temp/log.do_fetch.1253467
Summary: There were 3 WARNING messages.
Summary: There were 6 ERROR messages, returning a non-zero exit code.
Each log is rendered as a clickable hyperlink in the terminal. See
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
(Bitbake rev: 2852a478ab03a482989c3a7e247860ab4f0e9f3e)
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade util-linux from 2.40.1 to 2.40.2.
0001-Revert-autotools-make-pam-install-path-configurable.patch
is added to solve a problem of lastlog2 pam module not installed
in the expected location.
(From OE-Core rev: 2303f28de507ceb88a012647f70b74e0fad6ec4b)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While do_compile and do_install already have the scons_ prefix,
do_configure did not. This was most likely an oversight from when it
was converted from do_configure[noexec] = "1".
(From OE-Core rev: c2213e0393fc589ac0ee1dd6e67ad624eb0a2706)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows automated updates of the recipe together with mesa-gl
variant, and avoids having to check that update submissions
do include mesa-gl file rename.
(From OE-Core rev: f5cfb3e23603cefb2f3f6bfe776afaedefd10808)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the first post-backdoor release.
These are the release notes:
https://github.com/tukaani-project/xz/releases/
There are also backdoor notes:
https://tukaani.org/xz-backdoor/
"I plan to write an article how the backdoor got into the releases and
what can be learned from this." - that'd be most welcome, as it would
be first hand information that sets the record straight.
And there's a commit by commit review of Jia Tan's contributions:
https://tukaani.org/xz-backdoor/review.html
Add an option for landlock sandbox (off by default as it clashes with running under pseudo).
License-Update: public domain bits were relicensed under 0BSD license
(From OE-Core rev: 6446d82a533da091ec2acc613b4cf06951d78ff3)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: copyright years
(From OE-Core rev: 4e96b886e0e84ecb5f19e73dea444883257da25f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: copyright years
(From OE-Core rev: 807babe5392d3db02b237b17ad5ae773265c26de)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a patch to disable a failing test that is proving difficult
to investigate.
(From OE-Core rev: 0dc2dfcacaa99bdb306215d2a5e135038f72d895)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
history.3 manpage is no longer installed.
(From OE-Core rev: 93a2a1bc48562645ede4ec61f5fd2eb05f54e648)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Disable manpages, as they require scdoc, which is not currently
available in core (and adjust a related selftest).
Drop 0001-Use-portable-implementation-for-basename-API.patch
as upstream fixed the issue differently.
(From OE-Core rev: f868b75ab22cd528d9add744042f13d475715ef4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When xwayland PACKAGECONFIG option is set, xwayland is enabled in
weston.ini. However, if the xwayland module isn't installed, weston will
refuse to start with the following error message:
Failed to load module: /usr/lib/libweston-13/xwayland.so: cannot open shared object file: No such file or directory
Therefore, whenever the xwayland PACKAGECONFIG is set, weston-init
should depend on weston-xwayland to bring this module in.
Fixes: fdbe559c66c9 ("weston.init: enabled xwayland")
(From OE-Core rev: fa2314125318634108452af4e40c9eeee260767c)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
