[OE-core] [PATCH] meta: conf: avoid appending LIBCOVERRIDE to OVERRIDES
From: Ming Liu The order of any other overrides should be before forcevariable, or else it will get the highest priority. Signed-off-by: Ming Liu --- meta/classes/native.bbclass | 2 -- meta/classes/nativesdk.bbclass| 2 +- meta/conf/bitbake.conf| 3 ++- meta/conf/distro/include/tclibc-baremetal.inc | 5 ++--- meta/conf/distro/include/tclibc-glibc.inc | 5 ++--- meta/conf/distro/include/tclibc-musl.inc | 5 ++--- 6 files changed, 9 insertions(+), 13 deletions(-) diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass index a911f2a..775be04 100644 --- a/meta/classes/native.bbclass +++ b/meta/classes/native.bbclass @@ -106,8 +106,6 @@ PKG_CONFIG_SYSROOT_DIR = "" PKG_CONFIG_SYSTEM_LIBRARY_PATH[unexport] = "1" PKG_CONFIG_SYSTEM_INCLUDE_PATH[unexport] = "1" -# we dont want libc-*libc to kick in for native recipes -LIBCOVERRIDE = "" CLASSOVERRIDE = "class-native" MACHINEOVERRIDES = "" MACHINE_FEATURES = "" diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass index 69fb45c..b6858d2 100644 --- a/meta/classes/nativesdk.bbclass +++ b/meta/classes/nativesdk.bbclass @@ -6,7 +6,7 @@ STAGING_BINDIR_TOOLCHAIN = "${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S # libc for the SDK can be different to that of the target NATIVESDKLIBC ?= "libc-glibc" -LIBCOVERRIDE = ":${NATIVESDKLIBC}" +LIBCOVERRIDE = "${NATIVESDKLIBC}" CLASSOVERRIDE = "class-nativesdk" MACHINEOVERRIDES = "" diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 93f57f3..f240999 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -729,10 +729,11 @@ DISTRO_NAME ??= "OpenEmbedded" # # This works for functions as well, they are really just environment variables. # Default OVERRIDES to make compilation fail fast in case of build system misconfiguration. -OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable" +OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:${LIBCOVERRIDE}:forcevariable" CLASSOVERRIDE ?= "class-target" DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}" MACHINEOVERRIDES ?= "${MACHINE}" +LIBCOVERRIDE ?= "" FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" diff --git a/meta/conf/distro/include/tclibc-baremetal.inc b/meta/conf/distro/include/tclibc-baremetal.inc index a8ce6d3..4c7804e 100644 --- a/meta/conf/distro/include/tclibc-baremetal.inc +++ b/meta/conf/distro/include/tclibc-baremetal.inc @@ -4,9 +4,8 @@ LIBCEXTENSION = "" -# Add baremetal libc overrides to the overrides. -LIBCOVERRIDE = ":libc-baremetal" -OVERRIDES .= "${LIBCOVERRIDE}" +# Set baremetal libc overrides. +LIBCOVERRIDE = "libc-baremetal" ASSUME_PROVIDED += "virtual/libc virtual/libiconv" diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc index ad8000f..672dbfb 100644 --- a/meta/conf/distro/include/tclibc-glibc.inc +++ b/meta/conf/distro/include/tclibc-glibc.inc @@ -4,9 +4,8 @@ LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION') or '') != '']}" -# Add glibc overrides to the overrides for glibc. -LIBCOVERRIDE = ":libc-glibc" -OVERRIDES .= "${LIBCOVERRIDE}" +# Set glibc overrides. +LIBCOVERRIDE = "libc-glibc" PREFERRED_PROVIDER_virtual/libiconv ?= "glibc" PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc" diff --git a/meta/conf/distro/include/tclibc-musl.inc b/meta/conf/distro/include/tclibc-musl.inc index 54e1acf..cd06b11 100644 --- a/meta/conf/distro/include/tclibc-musl.inc +++ b/meta/conf/distro/include/tclibc-musl.inc @@ -4,9 +4,8 @@ LIBCEXTENSION = "-musl" -# Add musl libc overrides to the overrides. -LIBCOVERRIDE = ":libc-musl" -OVERRIDES .= "${LIBCOVERRIDE}" +# Set musl libc overrides. +LIBCOVERRIDE = "libc-musl" PREFERRED_PROVIDER_virtual/libc ?= "musl" PREFERRED_PROVIDER_virtual/libiconv ?= "musl" -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] meta: conf: avoid appending LIBCOVERRIDE to OVERRIDES
On Sat, 2018-04-07 at 11:05 +0200, liu.min...@gmail.com wrote: > From: Ming Liu > > The order of any other overrides should be before forcevariable, or > else it will get the highest priority. > > Signed-off-by: Ming Liu > --- > meta/classes/native.bbclass | 2 -- > meta/classes/nativesdk.bbclass| 2 +- > meta/conf/bitbake.conf| 3 ++- > meta/conf/distro/include/tclibc-baremetal.inc | 5 ++--- > meta/conf/distro/include/tclibc-glibc.inc | 5 ++--- > meta/conf/distro/include/tclibc-musl.inc | 5 ++--- > 6 files changed, 9 insertions(+), 13 deletions(-) We do not want to inject an empty entry into OVERRIDES. This patch changes things so we can end up with "::" in there. I suspect we've fixed bugs in bitbake where problems resulted from that however I still don't want to do it. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] Revert "python3: fix create_manifest to handle pycache folders"
Alejandro asked this be reverted as the patch causes more problems than it solves. This reverts commit 5d288d286e0adb221649d896c132a607ecddc490. Signed-off-by: Richard Purdie --- .../python/python3/create_manifest3.py | 5 + .../python/python3/python3-manifest.json | 20 +--- 2 files changed, 10 insertions(+), 15 deletions(-) diff --git a/meta/recipes-devtools/python/python3/create_manifest3.py b/meta/recipes-devtools/python/python3/create_manifest3.py index 44f3454..2f944f9 100644 --- a/meta/recipes-devtools/python/python3/create_manifest3.py +++ b/meta/recipes-devtools/python/python3/create_manifest3.py @@ -189,10 +189,7 @@ for key in old_manifest: # Ignore folders, since we don't import those, difficult to handle multilib if isFolder(value): # Pass folders directly -if isCached(value): -new_manifest[key]['cached'].append(value) -else: -new_manifest[key]['files'].append(value) +new_manifest[key]['files'].append(value) # Ignore binaries, since we don't import those if '${bindir}' in value: # Pass it directly to the new manifest data structure diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json b/meta/recipes-devtools/python/python3/python3-manifest.json index 26fa613..2491f36 100644 --- a/meta/recipes-devtools/python/python3/python3-manifest.json +++ b/meta/recipes-devtools/python/python3/python3-manifest.json @@ -736,21 +736,21 @@ "${libdir}/python3.5/__pycache__/poplib.*.pyc", "${libdir}/python3.5/__pycache__/smtplib.*.pyc", "${libdir}/python3.5/__pycache__/telnetlib.*.pyc", -"${libdir}/python3.5/__pycache__/uuid.*.pyc", -"${libdir}/python3.5/http/__pycache__", -"${libdir}/python3.5/urllib/__pycache__" +"${libdir}/python3.5/__pycache__/uuid.*.pyc" ], "files": [ "${libdir}/python3.5/base64.py", "${libdir}/python3.5/ftplib.py", "${libdir}/python3.5/hmac.py", "${libdir}/python3.5/http", +"${libdir}/python3.5/http/__pycache__", "${libdir}/python3.5/mimetypes.py", "${libdir}/python3.5/nntplib.py", "${libdir}/python3.5/poplib.py", "${libdir}/python3.5/smtplib.py", "${libdir}/python3.5/telnetlib.py", "${libdir}/python3.5/urllib", +"${libdir}/python3.5/urllib/__pycache__", "${libdir}/python3.5/uuid.py" ], "rdepends": [ @@ -1091,12 +1091,11 @@ "summary": "Python typing support" }, "unittest": { -"cached": [ -"${libdir}/python3.5/unittest/__pycache__" -], +"cached": [], "files": [ "${libdir}/python3.5/unittest", -"${libdir}/python3.5/unittest/" +"${libdir}/python3.5/unittest/", +"${libdir}/python3.5/unittest/__pycache__" ], "rdepends": [ "core", @@ -1136,11 +1135,10 @@ "summary": "Python basic XML support" }, "xmlrpc": { -"cached": [ -"${libdir}/python3.5/xmlrpc/__pycache__" -], +"cached": [], "files": [ -"${libdir}/python3.5/xmlrpc" +"${libdir}/python3.5/xmlrpc", +"${libdir}/python3.5/xmlrpc/__pycache__" ], "rdepends": [ "core", -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead
Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt from glibc despite the change not having merged into glibc upstream yet. This breaks the use of uninative in OE on fedora28 since binaries there are now using new symbols only found in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt but not the reverse. Since this will impact OE in the next release cycle, this changes nativesdk only to use this new model and adds libxcrypt to work in that case. This allows us to build a uninative which is compatible with fedora28 and previous other OSes. In order to work, recipes will now need to depend on virtual/crypt where they use libcrypt since its now a separate library and we can't depend on it from glibc to preseve backwards compatibility since glibc needs to build first. For now, only the problematic nativesdk recipes have been fixed up. For target use, the default provider remains glibc for now. Assuming this change is merged into upstream glibc, we will need to roll this change out for the target but we will do this in the next release cycle when we can better deal with the resulting bugs. [1] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Original patch from Charles-Antoine Couret , tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other minor tweaks. Signed-off-by: Charles-Antoine Couret Signed-off-by: Richard Purdie --- meta/conf/bitbake.conf | 1 + meta/recipes-core/glibc/glibc.inc | 5 +- .../glibc/0031-nativesdk-deprecate-libcrypt.patch | 418 + meta/recipes-core/glibc/glibc_2.27.bb | 1 + meta/recipes-core/glibc/site_config/headers| 1 - meta/recipes-core/libxcrypt/libxcrypt_4.0.0.bb | 31 ++ meta/recipes-core/meta/uninative-tarball.bb| 1 + meta/recipes-core/util-linux/util-linux.inc| 2 +- meta/recipes-devtools/perl/perl_5.24.1.bb | 2 +- meta/recipes-extended/shadow/shadow.inc| 3 +- 10 files changed, 459 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-core/glibc/glibc/0031-nativesdk-deprecate-libcrypt.patch create mode 100644 meta/recipes-core/libxcrypt/libxcrypt_4.0.0.bb diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 93f57f3..60590e2 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -187,6 +187,7 @@ ASSUME_PROVIDED = "\ tar-native \ virtual/libintl-native \ virtual/libiconv-native \ +virtual/crypt-native \ texinfo-native \ bash-native \ sed-native \ diff --git a/meta/recipes-core/glibc/glibc.inc b/meta/recipes-core/glibc/glibc.inc index 361a6fd..9e02ffd 100644 --- a/meta/recipes-core/glibc/glibc.inc +++ b/meta/recipes-core/glibc/glibc.inc @@ -35,7 +35,10 @@ siteconfig_do_siteconfig_gencache_prepend = " \ DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial linux-libc-headers virtual/${TARGET_PREFIX}libc-initial" # nptl needs libgcc but dlopens it, so our shlibs code doesn't detect this #RDEPENDS_${PN} += "${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}" -PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc" + +CRYPTPROVIDES = "virtual/crypt" +CRYPTPROVIDES_class-nativesdk = "" +PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc ${CRYPTPROVIDES}" PROVIDES += "virtual/libintl virtual/libiconv" inherit autotools texinfo distro_features_check systemd diff --git a/meta/recipes-core/glibc/glibc/0031-nativesdk-deprecate-libcrypt.patch b/meta/recipes-core/glibc/glibc/0031-nativesdk-deprecate-libcrypt.patch new file mode 100644 index 000..6b34c70 --- /dev/null +++ b/meta/recipes-core/glibc/glibc/0031-nativesdk-deprecate-libcrypt.patch @@ -0,0 +1,418 @@ +Background information: + +https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html +https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt + +Upstream-Status: Submitted [libc-al...@sourceware.org] + +From: Zack Weinberg +Subject: [PATCH] Deprecate libcrypt and don't build it by default + +Back in June, Björn Esser proposed to add OpenBSD-compatible bcrypt +support to our implementation of crypt(3), and Zack Weinberg replied +that it might actually make more sense to _remove_ libcrypt from +glibc, freeing up libcrypt.so.1 and crypt.h to be provided by a +separate project that could move faster. (For instance, libxcrypt: +https://github.com/besser82/libxcrypt) + +This patch disables build and installation of libcrypt by default. It +can be re-enabled with --enable-obsolete-crypt to configure. Unlike +libnsl, we do *not* install a runtime shared library; that's left to +the replacement. (Unlike the SunRPC situation, I think we can +probably drop this code altogether in a release or two.) + +The function prototypes for crypt and encrypt are removed from +unistd.h, and the function prototype for setkey is removed from +stdlib.h; they do *not* come back
[OE-core] [PATCH 2/3] devtool/oeqa: Ensure added layers set LAYERSERIES_COMPAT
Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated code from devtool/oeqa needs to set this to avoid warnings which break various tests. Signed-off-by: Richard Purdie --- meta/lib/oeqa/utils/commands.py | 2 +- scripts/devtool | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py index cad0bea..0d9cf23 100644 --- a/meta/lib/oeqa/utils/commands.py +++ b/meta/lib/oeqa/utils/commands.py @@ -285,7 +285,7 @@ def create_temp_layer(templayerdir, templayername, priority=999, recipepathspec= f.write('BBFILE_PATTERN_%s = "^${LAYERDIR}/"\n' % templayername) f.write('BBFILE_PRIORITY_%s = "%d"\n' % (templayername, priority)) f.write('BBFILE_PATTERN_IGNORE_EMPTY_%s = "1"\n' % templayername) - +f.write('LAYERSERIES_COMPAT_%s = "${LAYERSERIES_COMPAT_core}"\n' % templayername) @contextlib.contextmanager def runqemu(pn, ssh=True, runqemuparams='', image_fstype=None, launch_cmd=None, qemuparams=None, overrides={}, discard_writes=True): diff --git a/scripts/devtool b/scripts/devtool index b4bfbb8..d681a19 100755 --- a/scripts/devtool +++ b/scripts/devtool @@ -165,6 +165,7 @@ def _create_workspace(workspacedir, config, basepath): f.write('BBFILE_PATTERN_workspacelayer = "^$' + '{LAYERDIR}/"\n') f.write('BBFILE_PATTERN_IGNORE_EMPTY_workspacelayer = "1"\n') f.write('BBFILE_PRIORITY_workspacelayer = "99"\n') +f.write('LAYERSERIES_COMPAT_workspacelayer = "${LAYERSERIES_COMPAT_core}"\n') # Add a README file with open(os.path.join(workspacedir, 'README'), 'w') as f: f.write('This layer was created by the OpenEmbedded devtool utility in order to\n') -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "Revert "python3: fix create_ma..." and 2 more
== Series Details == Series: "Revert "python3: fix create_ma..." and 2 more Revision: 1 URL : https://patchwork.openembedded.org/series/11710/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 27568410eb) * Issue A patch file has been added, but does not have a Signed-off-by tag [test_signed_off_by_presence] Suggested fixSign off the added patch file (meta/recipes-core/glibc/glibc/0031-nativesdk-deprecate-libcrypt.patch) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead
On Sat, Apr 7, 2018, 05:44 Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > Fedora28[1] has decided to go ahead and use libxcrypt to replace libcrypt > from glibc > despite the change not having merged into glibc upstream yet. This breaks > the use of > uninative in OE on fedora28 since binaries there are now using new symbols > only found > in libxcrypt. libxcrypt is meant to be backwards compatible with libcrypt > but not the > reverse. > > Since this will impact OE in the next release cycle, this changes > nativesdk only > to use this new model and adds libxcrypt to work in that case. This allows > us to > build a uninative which is compatible with fedora28 and previous other > OSes. > > In order to work, recipes will now need to depend on virtual/crypt where > they use > libcrypt since its now a separate library and we can't depend on it from > glibc to > preseve backwards compatibility since glibc needs to build first. For now, > only the > problematic nativesdk recipes have been fixed up. For target use, the > default > provider remains glibc for now. Assuming this change is merged into > upstream glibc, > we will need to roll this change out for the target but we will do this in > the next > release cycle when we can better deal with the resulting bugs. > Of course, after this I finished, I think up a new idea :) Would it be possible to add libxcrypt to the default dependencies (along side glibc)? The main advantage I can see is that it would maintain the "status quo" of libcrypt being there be default. My main observation from when I went though the exercise of getting this to build last night is that while we fixed the SDK for core-image-sato, others may be including additional recipes in their SDK that depend on libcrypt and these can fail in non-obvious ways (for example, util-linux would have been very puzzling to track down if I hadn't know it was related to the libcrypt changes). We would obviously remove it in the next dev cycle and make the recipes fix their DEPENDS, like we are already planning to do. It might even be possible to switch the target to using libxcrypt this way, but I don't think I would recommend it. The main disadvantage that I can think of is that the libxcrypt recipe will be ugly, since it would have to build with INHIBIT_DEFAULT_DEPS=1. I'm not sure I sold myself on this idea. I don't think I know enough about all the implications and adding additional nativesdk recipes is not very common, so maybe a blurb in the release notes is sufficent? Anyway, I thought I would put it out there. Thanks, Joshua > > [1] > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt > > Original patch from Charles-Antoine Couret < > charles-antoine.cou...@essensium.com>, > tweaked by RP to add virtual provides, SkipRecipe for libxcrypt and other > minor > tweaks. > > Signed-off-by: Charles-Antoine Couret < > charles-antoine.cou...@essensium.com> > Signed-off-by: Richard Purdie > --- > meta/conf/bitbake.conf | 1 + > meta/recipes-core/glibc/glibc.inc | 5 +- > .../glibc/0031-nativesdk-deprecate-libcrypt.patch | 418 > + > meta/recipes-core/glibc/glibc_2.27.bb | 1 + > meta/recipes-core/glibc/site_config/headers| 1 - > meta/recipes-core/libxcrypt/libxcrypt_4.0.0.bb | 31 ++ > meta/recipes-core/meta/uninative-tarball.bb| 1 + > meta/recipes-core/util-linux/util-linux.inc| 2 +- > meta/recipes-devtools/perl/perl_5.24.1.bb | 2 +- > meta/recipes-extended/shadow/shadow.inc| 3 +- > 10 files changed, 459 insertions(+), 6 deletions(-) > create mode 100644 > meta/recipes-core/glibc/glibc/0031-nativesdk-deprecate-libcrypt.patch > create mode 100644 meta/recipes-core/libxcrypt/libxcrypt_4.0.0.bb > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > index 93f57f3..60590e2 100644 > --- a/meta/conf/bitbake.conf > +++ b/meta/conf/bitbake.conf > @@ -187,6 +187,7 @@ ASSUME_PROVIDED = "\ > tar-native \ > virtual/libintl-native \ > virtual/libiconv-native \ > +virtual/crypt-native \ > texinfo-native \ > bash-native \ > sed-native \ > diff --git a/meta/recipes-core/glibc/glibc.inc > b/meta/recipes-core/glibc/glibc.inc > index 361a6fd..9e02ffd 100644 > --- a/meta/recipes-core/glibc/glibc.inc > +++ b/meta/recipes-core/glibc/glibc.inc > @@ -35,7 +35,10 @@ siteconfig_do_siteconfig_gencache_prepend = " \ > DEPENDS = "virtual/${TARGET_PREFIX}gcc-initial libgcc-initial > linux-libc-headers virtual/${TARGET_PREFIX}libc-initial" > # nptl needs libgcc but dlopens it, so our shlibs code doesn't detect this > #RDEPENDS_${PN} += "${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}" > -PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc" > + > +CRYPTPROVIDES = "virtual/crypt" > +CRYPTPROVIDES_class-nativesdk = "" > +PROVIDES = "virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc >
Re: [OE-core] [PATCH 3/3] nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead
On Sat, 2018-04-07 at 13:36 +, Joshua Watt wrote: > Of course, after this I finished, I think up a new idea :) > > Would it be possible to add libxcrypt to the default dependencies > (along side glibc)? The main advantage I can see is that it would > maintain the "status quo" of libcrypt being there be default. My main > observation from when I went though the exercise of getting this to > build last night is that while we fixed the SDK for core-image-sato, > others may be including additional recipes in their SDK that depend > on libcrypt and these can fail in non-obvious ways (for example, > util-linux would have been very puzzling to track down if I hadn't > know it was related to the libcrypt changes). > > We would obviously remove it in the next dev cycle and make the > recipes fix their DEPENDS, like we are already planning to do. > > It might even be possible to switch the target to using libxcrypt > this way, but I don't think I would recommend it. > > The main disadvantage that I can think of is that the libxcrypt > recipe will be ugly, since it would have to build > with INHIBIT_DEFAULT_DEPS=1. > > I'm not sure I sold myself on this idea. I don't think I know enough > about all the implications and adding additional nativesdk recipes is > not very common, so maybe a blurb in the release notes is sufficent? > > Anyway, I thought I would put it out there. Its not a bad idea but the xcrypt dependencies would get ugly as it would have to depend on glibc without using the default deps as you say. I think we're close to making it work with the virtual/crypt, at least for nativesdk and since this matches what we'll likely ultimately have to do, I'm tempted to go that route. Current patchset is missing a musl PROVIDES but that is easily fixed for the next test. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Openembedded-architecture] LAYERSERIES
On Fri, 2018-04-06 at 15:44 -0700, Scott Rifenbark wrote: > Thanks Richard > > https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var- > LAYERSERIES_COMPAT Can you tweak: "Lists the versions of the OpenEmbedded Core project" -> "Lists the versions of OpenEmbedded-Core" we would never say "OE-Core Project". Also: "To specify the OE-Core projects" -> "To specify the OE-Core versions" I'd go as far as to say any reference to "OE-Core project" in the manual probably needs tweaking. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python3: Add recommended modules to nativesdk install
A colleague pointed out that what we installed in the SDK for python 3 was not functional, and that a minimal set of modules was required. I'm not an expert, but I found a similar line in the python 2 recipe and thought it might be what was needed here. Tom -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Thursday, April 5, 2018 8:56 AM To: Tom Hochstein ; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [PATCH] python3: Add recommended modules to nativesdk install On Wed, 2018-04-04 at 14:25 -0500, Tom Hochstein wrote: > The python3 installation in the SDK did not include the minimum set of > modules. > > Signed-off-by: Tom Hochstein > --- > meta/recipes-devtools/python/python3_3.5.5.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-devtools/python/python3_3.5.5.bb > b/meta/recipes-devtools/python/python3_3.5.5.bb > index d458d32..f893b84 100644 > --- a/meta/recipes-devtools/python/python3_3.5.5.bb > +++ b/meta/recipes-devtools/python/python3_3.5.5.bb > @@ -211,6 +211,7 @@ py_package_preprocess () { > > # manual dependency additions > RPROVIDES_${PN}-modules = "${PN}" > +RRECOMMENDS_${PN}-core_append_class-nativesdk = " nativesdk-python3- > modules" > RRECOMMENDS_${PN}-crypt = "openssl" > RRECOMMENDS_${PN}-crypt_class-nativesdk = "nativesdk-openssl" This doesn't look correct, if you want the SDK to contain all python modules, surely you'd just add nativesdk-python3-modules rather than forcing this everywhere? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core