[OE-core] [PATCH] meta: conf: avoid appending LIBCOVERRIDE to OVERRIDES

2018-04-07 Thread liu . ming50 
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

2018-04-07 Thread Richard Purdie 
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"

2018-04-07 Thread Richard Purdie 
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

2018-04-07 Thread Richard Purdie 
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

2018-04-07 Thread Richard Purdie 
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

2018-04-07 Thread Patchwork 
== 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

2018-04-07 Thread Joshua Watt 
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

2018-04-07 Thread Richard Purdie 
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

2018-04-07 Thread Richard Purdie 
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

2018-04-07 Thread Tom Hochstein 
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