Although we could potentially build patchelf and all its dependencies,
they would all have to be blacklisted to avoid trying to build them with
icecc. We use the host patchelf instead.
(From OE-Core rev: 0860216a81092fba084d29696db6d0c65a226c85)
(From OE-Core rev: 9d3587dda0e068efb72a89fd94002f13882fe335)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The python function icecc_path() was being invoked inline by set_icecc_env(),
meaning that it was being invoked at recipe-parsing time.
As a side-effect, icecc_path() was creating the recipe-sysroot directory and
symlinking icecc into it. Because this was done at parsing time (rather than
configure time), we were generating otherwise-empty WORKDIRs for *all* parsed
recipes, and for all virtual classes (-native, -nativesdk).
In my build, this generated more than 800 of these otherwise-empty WORKDIRs.
I have simplified icecc_path() to return only the intended path to the icecc
symlinks in the recipe-sysroot, with no side-effect.
We then create the directory and the icecc symlinks at configure time.
Because get_cross_kernel_cc() is still invoked at parse-time,
it needs a guard-clause for the non-kernel case.
We are now finding the host icecc at do_configure time,
so icecc needs to be in the HOSTTOOLS. I have made this non-fatal,
so that we can still inherit icecc without icecc installed.
(From OE-Core rev: d2fcaeb153fdc3f8d7143ea823139f1537055ff1)
(From OE-Core rev: 46db052def5c4fa0de7943262092582c8d897117)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If two bitbake processes try to generate the ICECC_VERSION tarball at the same
time, the thread that fails to get the lock will wait 30 sec for the first to
finish. A syntax error meant that this was not happening, and in particular, if
tarball generation failed (eg. for lack of patchelf), it did so silently.
(From OE-Core rev: 4455c46bf7f49c2b44f250aa89b63b342368e2e3)
(From OE-Core rev: d4ec47005d29e30b31bc61fe126b385e9e781228)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As was warned by commit 312ee68752fa [kconfig: announce removal of
oldnoconfig if used], oldnoconfig has been removed from the 4.20 kernel.
So we switch our default mode to olddefconfig.
commit fb16d8912 [kconfig: replace 'oldnoconfig' with 'olddefconfig',
and keep the old name as an alias] introduced olddefconfig in the 3.10
kernel, we shuffle oldnoconfig to the fallback target.
The fallback mode allows kernels between 3.10 and the currently listed
oldest kernel of 3.2 to continue to configure.
(From OE-Core rev: 8593dcb7e8c938530ff00ffedf7f3d02d26c3bad)
(From OE-Core rev: 0bbe3d579e4363a0ee34a9490dbf10f2a7a6736c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distros use site.conf to emit certain variables which are important
for eSDK e.g. DISTRO with out which eSDK will not be able to ger right
metadata when it tries to build
(From OE-Core rev: 95659bed3f6f3216b346f70cfc9ffae9788c0fc1)
(From OE-Core rev: d2f802b656dea7f9c227bd86db35e02c33f69021)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a fatal error if ELF objects don't have GNU_HASH segments but it
doesn't explain what the problem is. At least give a hint to users by
suggesting that LDFLAGS wasn't passed to the compiler.
(From OE-Core rev: 5d4da6713b40e10e853eb746f700096307ffe158)
(From OE-Core rev: a0ac85826aeee633e01d00d7a1f188724a2937f0)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a file matches the glob that is an absolute symlink then sed will try to
alter files on the host, so restrict the search to just actual files.
(From OE-Core rev: 5556b5ca9efac132754bd82af52a0f68bc4ce85a)
(From OE-Core rev: 3d148218387e968dbf2d3d587329b37d22d7d19e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As per the previous commit, upstream cpio has a bug which means it crashes on
append. If the image being built has already had testimage ran then cpio-native
will be in the sysroot. It's also possible that some distributions are shipping
this broken CVE patch too.
Now that our cpio-native is fixed, until we can be sure that the host cpio isn't
broken depend on cpio-native if building a cpio image.
[ YOCTO #13042 ]
(From OE-Core rev: c3b9aedcbe538d7fa74bd814644b4899769dec46)
(From OE-Core rev: a75eba71145efa1c3d206c5e5c00608a50f013bc)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In multilib_script.bbclass it renames script file which listed in
MULTILIB_SCRIPTS. It may mix up packages split. Take package curl as
example, ${bindir}/curl-config is packaged to curl-dev originally. But
it is renamed to curl-config-${MULTILIB_SUFFIX} and packaged to curl
when multilib is enabled.
And expand 'pkg' to fix QA warning:
| WARNING: Variable key FILES_${PN}-dev (
| ${bindir}/curl-config-${MULTILIB_SUFFIX}) replaces original key
| FILES_curl-dev (${includedir} ${FILES_SOLIBSDEV} ... ${bindir}/*-config)
Insert a necessary space to the argument 'value' of d.appendVar() as well.
(From OE-Core rev: 841bcbe429dcab54de3b89a927394750f9ccae60)
(From OE-Core rev: de222b08fbcc46f60da811a5542d20a9346c32df)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting them to empty before inheriting copyleft_filter
made them not getting their documented values there.
(From OE-Core rev: ee1f86ca7affc65265f219f0718f89406c9181a5)
(From OE-Core rev: b5586a83155e07b0c7a7e82568c18f5e29eaaed2)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A flaw was introduced by commit c5fa6034:
[ image.bbclass: use prependVarFlag for postfuncs ]
it changed to use prependVarFlag instead of appendVarFlag, then the
blank also needs change to adapt it.
(From OE-Core rev: 6085023158ffbfbaf0f3d65ef18054c003d3f463)
(From OE-Core rev: 0e62a5a6e2d3c453dc7e970fd497e050a9e17c7a)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This can improve the performance a lot for "bitbake <recipe-native/cross/crosssdk>
-ccleansstate" when there are a lot of sstate files.
For example:
* Before
$ bitbake quilt-native -ccleansstate
- Check log.do_cleansstate:
Removing /sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_package.tgz*
Removing /sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_package_qa.tgz*
Removing /sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_package_write_rpm.tgz*
Removing /sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_packagedata.tgz*
Removing /sstate-cache/*/sstate:quilt-native::0.65:r0::3:*_populate_lic.tgz*
Removing /sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_populate_sysroot.tgz*
There are no package tasks for quilt-native, so the first 4 lines doesn't
make any sense, but the glob pattern "sstate-cache/*/*" is very time
consuming when there are no disk caches. E.g., I have more than 600,000
sstate files:
- Without disk caches
# echo 3 >/proc/sys/vm/drop_caches
$ time python3 -c 'import glob; glob.glob("/sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_package.tgz*")'
real 4m32.583s
user 0m5.768s
sys 0m12.892s
- With disk caches (e.g., run it in the second time)
$ time python3 -c 'import glob; glob.glob("/sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_package.tgz*")'
real 0m5.128s
user 0m2.772s
sys 0m2.308s
So the 4 removing *package* commands cost more than 20s or 272s in theory.
* After
$ bitbake quilt-native -ccleansstate
- Check log.do_cleansstate:
Removing /sstate-cache/*/sstate:quilt-native::0.65:r0::3:*_populate_lic.tgz*
Removing /sstate-cache/*/*/sstate:quilt-native:x86_64-linux:0.65:r0:x86_64:3:*_populate_sysroot.tgz*
We can see that it saved 20s or 272s in theory.
(From OE-Core rev: bb2d6349ea87f090c58001f0d4348b24c2982cde)
(From OE-Core rev: aa35fbeb995b62523d44c8fad17f67d9852c594f)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is a still python2 bbclass, so it has been broken since bitbake changed to
python3 which was 2 years ago. No one reported/fixed it for python3 in recent 2
years. So we can assume that no one uses it anymore.
(From OE-Core rev: 7f6da5fb54cbcf8e358e988382f45839a8b80019)
(From OE-Core rev: 7264c248946c09b139110b512dd12ce6d8d72ddc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages (eg. init-ifupdown) take their source files entirely from
openembedded-core, that is, they download no source tarball.
These recipes either don't use S at all (ie. it is empty at unpack time),
or they set S = WORKDIR (as in init-ifupdown).
Looking at the file timestamps in the WORKDIR causes a non-reproducible
SOURCE_DATE_EPOCH, as files taken from file:// URIs do not have
reproducible timestamps.
If S == WORKDIR, we are better to assume that there is no source tarball,
and to fall back to a fixed timestamp for the SOURCE_DATE_EPOCH.
This makes the init-ifupdown build reproducible.
(From OE-Core rev: d395bad0179037eb5d0fa4d921985c87ae13f3a4)
(From OE-Core rev: cd56795a1588d780ca6a0cb974bf4024ab636be7)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updates the system blacklists to include packages that are known to have
problems compiling under icecream
(From OE-Core rev: fc5418e7bbdecfb27bafe595084e0fd0f991a388)
(From OE-Core rev: be54e1e0e769a9833b9b595e7a820ea9e098b91d)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The system blacklists are moved to variables which are ignore when
hashing. This prevents changes to the blacklists from causing all
taskhashes to change (and thus rebuild).
(From OE-Core rev: f5be9f6e9180ace3362bba52c7ced3b039441d7d)
(From OE-Core rev: 6f001b7b2ec3a6fb77184ca32664f89fee7ff5c3)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use our own lsb function instead as used elsewhere by the codebase.
(From OE-Core rev: acac45a6fd604d28ef7c23d67482af3d7e8bcfe3)
(From OE-Core rev: 570256a64af5a3fa994a20a5cc4c74d59ffc361f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Users are starting to expect OE to work under WSL which it doesn't. Add a warning to
tell them about this up front and manage expectations.
(From OE-Core rev: 4f22710f9a310412f1de0b4e6905c058ec416f25)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having image-buildinfo enabled causes containerimage.ContainerImageTests.test_expected_files
to fail due to the presence of an unexpected file:
['./',
'./etc/',
- './etc/build',
'./etc/default/',
'./etc/default/postinst',
Tweak the class to allow it to be disabled and disable it from the test just in
case it was enabled.
(From OE-Core rev: af67bf422a4df5b7e07894512ff73a5f493682ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to a bug in find [1], -ignore_readdir_race does not work correctly with
-delete. This can lead to spurious build failures when files disappear
while such a command is running; specifically this was seen in the case of
do_configure and do_populate_lic running concurrently for packages
with ${B} == ${WORKDIR}:
find: '.../sstate-build-populate_lic': No such file or directory
While the issue is fixed in the findutils git master, the find command of
the host system is called here, so we can't ensure that the used version
contains the fix. Many common distros have not updated to a recent enough
findutils version yet (Ubuntu 18.10 contains the fix, while 18.04 is still
affected).
Work around the issue by passing the output of find to 'rm -f' instead of
using -delete.
[1] https://savannah.gnu.org/bugs/?52981
(From OE-Core rev: 8079e2d62e23f7c274f46185e6dad64fa95394c1)
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In sources directory we can find patches/ and temp/.
The first one is filled with symbolic link unusable on another
machines.
The second contains yocto logs to create this archives and are
typically copied when 'S = "${WORKDIR}"'
(From OE-Core rev: 3904f98851c6a63dd9377e38f1432be6b1c0a94d)
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Several distros are now shipping "python" as python v3 contra to the original
python guidelines. This causes users confusion/pain in trying to use our tools.
We can just force "python" to "python2" within HOSTTOOLS to avoid this issue
and hide the complexity from the user.
(From OE-Core rev: b06a6cde5c5503f456f260c773cf126085e18c8d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarlly to OE-Core rev 4b936cde58ca0a6f34092ce82640a02859110411 for
cross.sdk, BUILD_* flags can't be used as TARGET_* flags
gcc-crosssdk buils leaks config.log's through "gcc-stashed-builddir" and
TARGET_* flags to libgcc cross-build through "gcc/libgcc.mvars" file
on "gcc-stashed-builddir". This means that if BUILD_CFLAGS contains
host-specific flags like "-isystem/usr/include" libgcc build will
fail "do_qa_configure" and "do_package_qa" checks.
Remove host-related flags from TARGET_* flags for gcc-crosssdk builds.
[YOCTO #11874]
(From OE-Core rev: 6e162e619b6f5173c073cd9bedbcadf205017e30)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Right now go-cross is changing signatures when you change TUNE for a given
architecture. In particular this breaks layer tests like:
yocto-check-layer ../meta-yocto-bsp/ --machines qemuarm beaglebone-yocto
This changes the PN addtion to something containing the tune rather than
the arch which avoids these kinds of errors. If go-cross can be tune
independent that would be nice but currently that isn't the case.
[YOCTO #12586]
(From OE-Core rev: e3c7e1703499e6a5332d9ab8a941671ec8235c4f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Once the value of SOURCE_DATE_EPOCH is determined, it is stored in the recipe's SDE_FILE.
If none of the existing mechanisms are suitable, replace the do_deploy_source_date_epoch task
with recipe-specific functionality to write the appropriate SOURCE_DATE_EPOCH into the SDE_FILE.
(From OE-Core rev: e7b891b76954c784f5a93bd0a1c91315673ce40d)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Meson uses 'ppc64' for 64 bit powerpc. Issue came up while
building systemd for MACHINE that uses ppc64e5500 tune.
(From OE-Core rev: eccd5414c37be26df63a90154c1808f6f5618b7d)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tweak the preceeding commit to:
* Add STARTTIME to the identifier to make it unique
* Add MACHINE to the identifier
* Use LOG_DIR
* Store the layer config in a more natural json format
* Drop '_' function prefixes
(From OE-Core rev: c272079d662237b1b9f87940c88cbadaeda9a9d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As part of the solution to replace Testopia to store testresult,
OEQA sdk and sdkext need to output testresult into json files, where
these json testresult files will be stored into git repository
by the future test-case-management tools.
By default, json testresult file will be written to "oeqa"
directory under the "WORKDIR" directory.
To configure multiple instances of bitbake to write json testresult
to a single testresult file at custom directory, user will define
the variable "OEQA_JSON_RESULT_DIR" with the custom directory for
json testresult.
(From OE-Core rev: cdbedba7da9c3f97a642d79a5e8ec363ba938e35)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tweak the preceeding commit to:
* Add STARTTIME to the identifier to make it unique
* Log DISTRO
* Use LOG_DIR
* Store the layer config in a more natural json format
* Drop '_' function prefixes
(From OE-Core rev: dda94cfa708cf3c6e5408d6dbcece360b4e8cd27)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As part of the solution to replace Testopia to store testresult,
OEQA testimage need to output testresult into json files, where
these json testresult files will be stored into git repository
by the future test-case-management tools.
By default, json testresult file will be written to "oeqa"
directory under the "WORKDIR" directory.
To configure multiple instances of bitbake to write json testresult
to a single testresult file at custom directory, user will define
the variable "OEQA_JSON_RESULT_DIR" with the custom directory for
json testresult.
(From OE-Core rev: 5d135d4769b6bb60d575eb6ed196367f9e077cc4)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are both "curl" and "libcurl" CPEs in NVD.
All "curl" CVEs are currently missing in the reports.
Hence, switch "CVE_PRODUCT" to a space separated list.
It is useful for recipes generating several packages,
that have different product names in NVD.
(From OE-Core rev: 404f75e026393ddc55da87f6f04fb1201cff4e11)
Signed-off-by: Grygorii Tertychnyi <gtertych@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ptest has dependencies on other tests so contain them in a
variable. This allows layers to not worry about maintaining the depends
themselves.
(From OE-Core rev: c5c5ad9030ec7ddaa6387e2ba52e9e37b9ea76a2)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distros want to install the kernel in a custom location other
than /boot and have it properly packaged, so it's useful to use a
weaker assignment.
(From OE-Core rev: cadd91655a336eb6d65ca43dc1231bbe5271e1cf)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit b1f10b18ea added the NPM_INSTALL_DEV
variable. But due to the use of simple assignment, a recipe can't override its
value.
(From OE-Core rev: b53d5094d5e05f9c1955c8565d777ad74f668f7e)
Signed-off-by: Jef Driesen <jef.driesen@niko.eu>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The node binary searches for packages in a number of locations, the last
of which is $PREFIX/lib/node (here: /usr/lib/node) from the list of
GLOBAL_FOLDERS [1]. So change the installation directory for all
packages depending on npm.bbclass to that location. This removes the
need to define the NODE_PATH variable to the non-standard
/usr/lib/node_modules value.
While the Tips for Package Managers [2] discusses installing packages to
/usr/lib/node_modules/<name>/<version>, this has several drawbacks:
* it does not work for the REPL as mentioned in the documentation
* it also does not work for any code _not_ installed as a global
package under /usr/lib/node_modules (e.g. /usr/share/foo.js will not
find any packages below /usr/lib)
* using the non-default location and then having to set NODE_PATH
barely saves any time: there are only two file-system lookups (to the
legacy $HOME/.node_modules and $HOME/.node_libraries) directories
before the library would be found
And the suggestion was made in the context of deduping the node_modules
tree by installing all packages in a flat hierarchy and using symlinks
to the correct version of each dependency. This is not what OpenEmbedded
does, so none of those benefits (deduping, cleaner packages) are being
had by shifting the installation directory to /usr/lib/node_modules.
The choice of a "proper" installation path is not helped by npm
installing to /usr/lib/node_modules if asked to install globally. Still,
using the location expected by nodejs (/usr/lib/node) seems the right
choice.
[1]: https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders
[2]: https://nodejs.org/api/modules.html#modules_addenda_package_manager_tips
(From OE-Core rev: c73bc49038effd64f2c2542c1f4da8b6a4168477)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The node binary searches for packages in a number of locations, the last
of which is $PREFIX/lib/node (here: /usr/lib/node) from the list of
GLOBAL_FOLDERS [1]. Change the installation directory for all packages
depending on npm.bbclass to that location. This removes the need to
define the NODE_PATH variable to the non-standard /usr/lib/node_modules
value.
While the Tips for Package Managers [2] discusses installing packages to
/usr/lib/node_modules/<name>/<version>, this has several drawbacks:
* it does not work for the REPL as mentioned in the documentation
* it also does not work for any code _not_ installed as a global
package under /usr/lib/node_modules (e.g. /usr/share/foo.js will not
find any packages below /usr/lib)
* using the non-default location and then having to set NODE_PATH
barely saves any time: there are only two file-system lookups (to the
legacy $HOME/.node_modules and $HOME/.node_libraries) directories
before the library would be found
And the suggestion was made in the context of deduping the node_modules
tree by installing all packages in a flat hierarchy and using symlinks
to the correct version of each dependency. This is not what OpenEmbedded
does, so none of those benefits (deduping, cleaner packages) are being
had by shifting the installation directory to /usr/lib/node_modules.
[1]: https://nodejs.org/api/modules.html#modules_loading_from_the_global_folders
[2]: https://nodejs.org/api/modules.html#modules_addenda_package_manager_tips
(From OE-Core rev: 2036137151929b541293154ff529475071cd92b0)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For conditonally applied patches based on SRC_URI overrides, the
devtool-source class would try to create a new branch for each override
assignment as a postfunc to do_patch, but if the same override was used
multiple times, it would try to create the same branch multiple times,
causing errors like
> Exception: bb.process.ExecutionError: Execution of
\ 'git checkout f0f0f0f0f0ff0f0f0f0f0f0f0f0f0f0f0ff0f0f0 -b devtool-override-foo'
\ failed with exit code 128:
> fatal: A branch named 'devtool-override-foo' already exists.
This change makes sure that the devtool-source bbclass will only create
one branch per override.
(From OE-Core rev: 95a921959d340f74b5604df57737c1eeaad0023e)
Signed-off-by: Olof Johansson <olofjn@axis.com>
Reviewed-by: Peter Kjellerstedt <pkj@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The __pycache__ is created based on python3 version in the build machine
and isn't a garantee to be useful on the system that runs exported tests.
(From OE-Core rev: 405e822e9da4b53ec9ee8019364fdcb13ccc2587)
Signed-off-by: Aníbal Limón <anibal.limon@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Static libraries are not included in rootfs, it means, that sources are
not going into debug rootfs. This option enables to install additional
packages even if the standard package is not installed.
(From OE-Core rev: 708fe1df3d3e22dd693ae7bbfdd3e5af1a1b0bdc)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
add -f into postinst OPT to fix run postinst scriptlet fail
problem during do rootfs, while INITSCRIPT_PARAMS set to remove.
+ type update-rc.d
+ '[' -n qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs ']'
+ OPT='-r qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs'
+ update-rc.d -r work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs keepalived remove
update-rc.d: work/qemux86_64-poky-linux/core-image-sato/1.0-r0/rootfs/etc/init.d/keepalived exists during rc.d purge (use -f to force)
D: %post(keepalived-1.4.2-r0.core2_64): waitpid(305974) rc 305974 status 100
(From OE-Core rev: 45224526edbe65012a846c066d2b539a360f0c51)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit [9524330 gobject-introspection: fix multilib install
file conflicts] applied in oe-core, while multilib enabled, gir
files will be installed to `${libdir}'.
Refer above commit, modify gobject-introspection.bbclass to
split gir to package correctly.
(From OE-Core rev: e0cc1dc6f1c14babe29a29a7211dc1c69d782b95)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the name of the last user being part of the group had a name that
was a prefix of the user being added, then perform_groupmems() would
treat it as if the user already existed in the list of users and not
add it.
Reported-by: Peter Henricsson <peter.henricsson@axis.com>
(From OE-Core rev: 3bab0416f20366e75444be9b65fb1369643f103a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
