Re: [OE-core] [PATCH] ltp: Fix format security warnings with gcc10

[Petr Vorel]

Hi Khem,

I see patch has already merged in upstream.
How about adding Upstream status: 58424835952641f4fd60c0ae3ab6c64decca3f8a

Kind regards,
Petr
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138503): 
https://lists.openembedded.org/g/openembedded-core/message/138503
Mute This Topic: https://lists.openembedded.org/mt/74343691/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] ltp: Fix format security warnings with gcc10

[Petr Vorel]

Hi Khem,

> Signed-off-by: Khem Raj 
> Cc: Petr Vorel 
> Cc: Daniel Díaz 

Reviewed-by: Petr Vorel 

Nice, just easy fix. Please just send patch to LTP ML.
Some time ago I tried to add -Wformat-security in upstream LTP travis CI, don't
remember why I haven't finished the effort. If this is the only needed fix,
we'll enable it.

BTW how to add -Wformat-security in for openembedded-core (for next time)?

Kind regards,
Petr
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138502): 
https://lists.openembedded.org/g/openembedded-core/message/138502
Mute This Topic: https://lists.openembedded.org/mt/74343691/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

[Khem Raj]

On Tue, May 19, 2020 at 10:07 PM Konrad Weihmann  wrote:
>
> Hi all,
>
> I don't like the idea of wrapping subprocess.check_* calls once more.
> IMHO too many possible workflows are possible so chances are low
> catching them all appropriately.
>
> check_output is a wrapper around subprocess.run, which is a wrapper
> around subprocess.popen which is wrapper of popen, so an additional
> wrapper doesn't sound like the best idea so far.
>

right, that's what I was contemplating as well.

> I'm okay with generalizing the output of a failed call so maybe just
> http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n330
> could be used more widely.
>
> It all comes down to handling subprocess failures and in this particular
> case it was simply missing.
>
> Long story short, I'd rather fix them one by one (with respect to actual
> code flow) than abstracting things even more.
>
> Regards
> Konrad
>
> On 20.05.20 00:14, Khem Raj wrote:
> > On Tue, May 19, 2020 at 3:02 PM Richard Purdie
> >  wrote:
> >>
> >> On Tue, 2020-05-19 at 20:36 +0200, Konrad Weihmann wrote:
> >>> in case the opkg command fails in before no output of the tool
> >>> itself was printed to assist the user with debugging the issue.
> >>> Print all output of the tool by using CalledProcessError wrapper around
> >>> the call
> >>>
> >>> Signed-off-by: Konrad Weihmann 
> >>> ---
> >>>   meta/classes/package_ipk.bbclass | 11 +++
> >>>   1 file changed, 7 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/meta/classes/package_ipk.bbclass 
> >>> b/meta/classes/package_ipk.bbclass
> >>> index c008559e4a..5e7d552cc5 100644
> >>> --- a/meta/classes/package_ipk.bbclass
> >>> +++ b/meta/classes/package_ipk.bbclass
> >>> @@ -223,10 +223,13 @@ def ipk_write_pkg(pkg, d):
> >>>   conffiles.close()
> >>>
> >>>   os.chdir(basedir)
> >>> -subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> >>> (localdata.getVar("PATH"),
> >>> -  
> >>> d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> >>> -stderr=subprocess.STDOUT,
> >>> -shell=True)
> >>> +try:
> >>> +subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> >>> (localdata.getVar("PATH"),
> >>> +
> >>> d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> >>> +stderr=subprocess.STDOUT,
> >>> +shell=True)
> >>> +except subprocess.CalledProcessError as exp:
> >>> +bb.fatal("{} failed with {}: {}".format(exp.cmd, 
> >>> exp.returncode, exp.output.decode("utf-8")))
> >>>
> >>>   if d.getVar('IPK_SIGN_PACKAGES') == '1':
> >>>   ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))
> >>
> >> I get the feeling we have a problem with our subprocess calls and
> >> debugging but its hard to know what to do about it. We can patch each
> >> call site like this but it starts to make we wonder whether we need a
> >> general wrapper, or we're missing something in bitbake or elsewhere to
> >> help with things.
> >>
> >> There is this code:
> >>
> >> http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n378
> >>
> >> which is meant to help but it clearly isn't helping/catching all cases.
> >>
> >> I think we are going to need to look at a wider/more general solution
> >> or at least have a plan for one.
> >>
> >
> >
> > are you think of wrapping subprocess.check_output calls with some post
> > processing ?
> >
> >> Cheers,
> >>
> >> Richard
> >>
> >> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138501): 
https://lists.openembedded.org/g/openembedded-core/message/138501
Mute This Topic: https://lists.openembedded.org/mt/74331803/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] ✗ patchtest: failure for ltp: Fix format security warnings with gcc10

[Patchwork]

== Series Details ==

Series: ltp: Fix format security warnings with gcc10
Revision: 1
URL   : https://patchwork.openembedded.org/series/24228/
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 586061c469)

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-extended/ltp/ltp/0001-ptrace01-Fix-missing-format-string.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138500): 
https://lists.openembedded.org/g/openembedded-core/message/138500
Mute This Topic: https://lists.openembedded.org/mt/74343732/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] ltp: Fix format security warnings with gcc10

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Petr Vorel 
Cc: Daniel Díaz 
---
 ...1-ptrace01-Fix-missing-format-string.patch | 32 +++
 meta/recipes-extended/ltp/ltp_20200515.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-ptrace01-Fix-missing-format-string.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-ptrace01-Fix-missing-format-string.patch 
b/meta/recipes-extended/ltp/ltp/0001-ptrace01-Fix-missing-format-string.patch
new file mode 100644
index 00..d3785546c9
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-ptrace01-Fix-missing-format-string.patch
@@ -0,0 +1,32 @@
+From adb9587466a493fdd9d4410f1b8b130ebca06daa Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Tue, 19 May 2020 22:21:23 -0700
+Subject: [PATCH] ptrace01: Fix missing format string
+
+Fixes
+| ptrace01.c:89:2: error: format string is not a string literal
+(potentially insecure) [-Werror,-Wformat-security]
+| tst_res(TINFO, tc->message);
+| ^  ~~~
+
+Signed-off-by: Khem Raj 
+---
+ testcases/kernel/syscalls/ptrace/ptrace01.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/testcases/kernel/syscalls/ptrace/ptrace01.c 
b/testcases/kernel/syscalls/ptrace/ptrace01.c
+index 87a99e4150..9071bbabaf 100644
+--- a/testcases/kernel/syscalls/ptrace/ptrace01.c
 b/testcases/kernel/syscalls/ptrace/ptrace01.c
+@@ -86,7 +86,7 @@ static void run(unsigned int i)
+ 
+   got_signal = 0;
+ 
+-  tst_res(TINFO, tc->message);
++  tst_res(TINFO, "%s", tc->message);
+ 
+   if (tc->handler == 1) {
+   parent_act.sa_handler = parent_handler;
+-- 
+2.26.2
+
diff --git a/meta/recipes-extended/ltp/ltp_20200515.bb 
b/meta/recipes-extended/ltp/ltp_20200515.bb
index 37bad53766..e82f6b33a1 100644
--- a/meta/recipes-extended/ltp/ltp_20200515.bb
+++ b/meta/recipes-extended/ltp/ltp_20200515.bb
@@ -34,6 +34,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0004-guard-mallocopt-with-__GLIBC__.patch \
file://0007-Fix-test_proc_kill-hanging.patch \
file://0001-Add-more-musl-exclusions.patch \
+   file://0001-ptrace01-Fix-missing-format-string.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138499): 
https://lists.openembedded.org/g/openembedded-core/message/138499
Mute This Topic: https://lists.openembedded.org/mt/74343691/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

[Konrad Weihmann]

Hi all,

I don't like the idea of wrapping subprocess.check_* calls once more.
IMHO too many possible workflows are possible so chances are low 
catching them all appropriately.


check_output is a wrapper around subprocess.run, which is a wrapper 
around subprocess.popen which is wrapper of popen, so an additional 
wrapper doesn't sound like the best idea so far.


I'm okay with generalizing the output of a failed call so maybe just
http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n330 
could be used more widely.


It all comes down to handling subprocess failures and in this particular 
case it was simply missing.


Long story short, I'd rather fix them one by one (with respect to actual 
code flow) than abstracting things even more.


Regards
Konrad

On 20.05.20 00:14, Khem Raj wrote:

On Tue, May 19, 2020 at 3:02 PM Richard Purdie
 wrote:


On Tue, 2020-05-19 at 20:36 +0200, Konrad Weihmann wrote:

in case the opkg command fails in before no output of the tool
itself was printed to assist the user with debugging the issue.
Print all output of the tool by using CalledProcessError wrapper around
the call

Signed-off-by: Konrad Weihmann 
---
  meta/classes/package_ipk.bbclass | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index c008559e4a..5e7d552cc5 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -223,10 +223,13 @@ def ipk_write_pkg(pkg, d):
  conffiles.close()

  os.chdir(basedir)
-subprocess.check_output("PATH=\"%s\" %s %s %s" % 
(localdata.getVar("PATH"),
-  
d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
-stderr=subprocess.STDOUT,
-shell=True)
+try:
+subprocess.check_output("PATH=\"%s\" %s %s %s" % 
(localdata.getVar("PATH"),
+
d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
+stderr=subprocess.STDOUT,
+shell=True)
+except subprocess.CalledProcessError as exp:
+bb.fatal("{} failed with {}: {}".format(exp.cmd, exp.returncode, 
exp.output.decode("utf-8")))

  if d.getVar('IPK_SIGN_PACKAGES') == '1':
  ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))


I get the feeling we have a problem with our subprocess calls and
debugging but its hard to know what to do about it. We can patch each
call site like this but it starts to make we wonder whether we need a
general wrapper, or we're missing something in bitbake or elsewhere to
help with things.

There is this code:

http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n378

which is meant to help but it clearly isn't helping/catching all cases.

I think we are going to need to look at a wider/more general solution
or at least have a plan for one.




are you think of wrapping subprocess.check_output calls with some post
processing ?


Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138498): 
https://lists.openembedded.org/g/openembedded-core/message/138498
Mute This Topic: https://lists.openembedded.org/mt/74331803/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/1] ltp: Update to 20200515

[Daniel D?az]

Hello!

On Tue, 19 May 2020 at 19:28, Khem Raj  wrote:
> Fails on musl
> https://errors.yoctoproject.org/Errors/Details/412683/

It fails for me (non-musl) too, similarly:

make[4]: Entering directory
'/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0/git/testcases/kernel/syscalls/ptrace'
| aarch64-poky-linux-gcc  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-fstack-protector-strong -Wl,-z,relro,-z,now -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0/recipe-sysroot
-O2 -pipe -g -feliminate-unused-debug-types
-fmacro-prefix-map=/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0=/usr/src/debug/ltp/20200515-r0

-fdebug-prefix-map=/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0=/usr/src/debug/ltp/20200515-r0

-fdebug-prefix-map=/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0/recipe-sysroot=

-fdebug-prefix-map=/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0/recipe-sysroot-native=
 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition
-I../../../../include -I../../../../include -I../../../../include/old/
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
-Wl,-z,relro,-z,now  -L../../../../lib  ptrace01.c   -lltp -o ptrace01
| ptrace01.c: In function 'run':
| ptrace01.c:89:2: error: format not a string literal and no format
arguments [-Werror=format-security]
|89 |  tst_res(TINFO, tc->message);
|   |  ^~~
| cc1: some warnings being treated as errors
| : recipe for target 'ptrace01' failed
| make[4]: *** [ptrace01] Error 1
| make[4]: Leaving directory
'/poky/build/tmp/work/aarch64-poky-linux/ltp/20200515-r0/git/testcases/kernel/syscalls/ptrace'
| ../../../include/mk/generic_trunk_target.inc:93: recipe for target
'all' failed
| make[3]: *** [all] Error 2


Greetings!

Daniel Díaz
daniel.d...@linaro.org



> On Mon, May 18, 2020 at 1:36 PM Petr Vorel  wrote:
> >
> > Inherit also pkgconfig (required for TI-RPC and Netlink based route
> > tests), to fix:
> > configure:6045: error: possibly undefined macro: AC_DEFINE
> >
> > Refreshed patches (some tests have been fixed for musl)
> > * 0001-build-Add-option-to-select-libc-implementation.patch
> > (add a note here)
> > * 0001-Add-more-musl-exclusions.patch
> >
> > Removed patches (different fix in upstream)
> > * 0003-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
> >
> > Removed patches (accepted upstream)
> > * 0008-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch
> > * 0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
> >
> > Update upstream status
> > * 0004-guard-mallocopt-with-__GLIBC__.patch
> >
> > Signed-off-by: Petr Vorel 
> > ---
> > Hi,
> >
> > tested:
> >
> > $ bitbake ltp
> > Build Configuration:
> > BB_VERSION   = "1.44.0"
> > BUILD_SYS= "x86_64-linux"
> > NATIVELSBSTRING  = "opensusetumbleweed-20200516"
> > TARGET_SYS   = "x86_64-oe-linux"
> > MACHINE  = "qemux86-64"
> > DISTRO   = "nodistro"
> > DISTRO_VERSION   = "nodistro.0"
> > TUNE_FEATURES= "m64 core2"
> > TARGET_FPU   = ""
> > meta = 
> > "ltp/20200515.v1:31cb32ae7321027b25080c9f7be56ca140f1eb35"
> >
> > $ MACHINE=qemuarm TCLIBC=musl bitbake ltp
> > Build Configuration:
> > BB_VERSION   = "1.44.0"
> > BUILD_SYS= "x86_64-linux"
> > NATIVELSBSTRING  = "opensusetumbleweed-20200516"
> > TARGET_SYS   = "arm-oe-linux-musleabi"
> > MACHINE  = "qemuarm"
> > DISTRO   = "nodistro"
> > DISTRO_VERSION   = "nodistro.0"
> > TUNE_FEATURES= "arm armv7ve vfp thumb neon callconvention-hard"
> > TARGET_FPU   = "hard"
> > meta = 
> > "ltp/20200515.v1:b66ebb768a2b53f38d62d98249b377c73d5e0b9c"
> >
> > Kind regards,
> > Petr
> >
> >  .../ltp/0001-Add-more-musl-exclusions.patch   |  28 ++--
> >  ...option-to-select-libc-implementation.patch |  47 ++-
> >  ...or-time64-unsafe-syscalls-before-usi.patch | 122 --
> >  ...BC_PREREQ-is-defined-before-using-it.patch |  55 
> >  .../0004-guard-mallocopt-with-__GLIBC__.patch |   4 +-
> >  ...k-nfsv4-acl-acl1.c-Security-fix-on-s.patch |  42 --
> >  .../ltp/{ltp_20200120.bb => ltp_20200515.bb}  |   7 +-
> >  7 files changed, 25 insertions(+), 280 deletions(-)
> >  delete mode 100644 
> > meta/recipes-extended/ltp/ltp/0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
> >  delete mode 100644 
> > meta/recipes-extended/ltp/ltp/0003-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
> >  delete mode 100644 
> > meta/recipes-extended/ltp/ltp/0008-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch
> >  rename meta/recipes-extended/ltp/{ltp_20200120.bb => ltp_20200515.bb} (93%)
> >
> > diff --git 
> > a/meta/recipes-extended/ltp/ltp/0001-Add-more-musl-exclusions.patch 
> > b/meta/recipes-extended/ltp/ltp/0001-Add-more-musl-excl

Re: [OE-core] [PATCH 1/1] ltp: Update to 20200515

[Khem Raj]

Fails on musl

https://errors.yoctoproject.org/Errors/Details/412683/

On Mon, May 18, 2020 at 1:36 PM Petr Vorel  wrote:
>
> Inherit also pkgconfig (required for TI-RPC and Netlink based route
> tests), to fix:
> configure:6045: error: possibly undefined macro: AC_DEFINE
>
> Refreshed patches (some tests have been fixed for musl)
> * 0001-build-Add-option-to-select-libc-implementation.patch
> (add a note here)
> * 0001-Add-more-musl-exclusions.patch
>
> Removed patches (different fix in upstream)
> * 0003-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
>
> Removed patches (accepted upstream)
> * 0008-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch
> * 0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
>
> Update upstream status
> * 0004-guard-mallocopt-with-__GLIBC__.patch
>
> Signed-off-by: Petr Vorel 
> ---
> Hi,
>
> tested:
>
> $ bitbake ltp
> Build Configuration:
> BB_VERSION   = "1.44.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "opensusetumbleweed-20200516"
> TARGET_SYS   = "x86_64-oe-linux"
> MACHINE  = "qemux86-64"
> DISTRO   = "nodistro"
> DISTRO_VERSION   = "nodistro.0"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta = 
> "ltp/20200515.v1:31cb32ae7321027b25080c9f7be56ca140f1eb35"
>
> $ MACHINE=qemuarm TCLIBC=musl bitbake ltp
> Build Configuration:
> BB_VERSION   = "1.44.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "opensusetumbleweed-20200516"
> TARGET_SYS   = "arm-oe-linux-musleabi"
> MACHINE  = "qemuarm"
> DISTRO   = "nodistro"
> DISTRO_VERSION   = "nodistro.0"
> TUNE_FEATURES= "arm armv7ve vfp thumb neon callconvention-hard"
> TARGET_FPU   = "hard"
> meta = 
> "ltp/20200515.v1:b66ebb768a2b53f38d62d98249b377c73d5e0b9c"
>
> Kind regards,
> Petr
>
>  .../ltp/0001-Add-more-musl-exclusions.patch   |  28 ++--
>  ...option-to-select-libc-implementation.patch |  47 ++-
>  ...or-time64-unsafe-syscalls-before-usi.patch | 122 --
>  ...BC_PREREQ-is-defined-before-using-it.patch |  55 
>  .../0004-guard-mallocopt-with-__GLIBC__.patch |   4 +-
>  ...k-nfsv4-acl-acl1.c-Security-fix-on-s.patch |  42 --
>  .../ltp/{ltp_20200120.bb => ltp_20200515.bb}  |   7 +-
>  7 files changed, 25 insertions(+), 280 deletions(-)
>  delete mode 100644 
> meta/recipes-extended/ltp/ltp/0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
>  delete mode 100644 
> meta/recipes-extended/ltp/ltp/0003-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
>  delete mode 100644 
> meta/recipes-extended/ltp/ltp/0008-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch
>  rename meta/recipes-extended/ltp/{ltp_20200120.bb => ltp_20200515.bb} (93%)
>
> diff --git 
> a/meta/recipes-extended/ltp/ltp/0001-Add-more-musl-exclusions.patch 
> b/meta/recipes-extended/ltp/ltp/0001-Add-more-musl-exclusions.patch
> index 02c2fef55b..f2fc8ee958 100644
> --- a/meta/recipes-extended/ltp/ltp/0001-Add-more-musl-exclusions.patch
> +++ b/meta/recipes-extended/ltp/ltp/0001-Add-more-musl-exclusions.patch
> @@ -1,35 +1,22 @@
> -From 788c47ceef7f115ab7f7aa17f918e58795f4e6c7 Mon Sep 17 00:00:00 2001
> +From ad8e73306cb8293f7d32841e1599fd9048801f1f Mon Sep 17 00:00:00 2001
>  From: Alexander Kanavin 
>  Date: Fri, 20 Dec 2019 13:06:05 +0100
>  Subject: [PATCH] Add more musl exclusions
>
>  Upstream-Status: Pending
>  Signed-off-by: Alexander Kanavin 
> +[ pvorel: rebase for 20200515: enable accept4_01 ]
>  [ pvorel: rebase for 20200120: enable fanotify13, fanotify15, setxattr03 ]
>  Signed-off-by: Petr Vorel 
>  ---
> - testcases/kernel/syscalls/accept4/Makefile  | 4 
>   testcases/kernel/syscalls/timer_create/Makefile | 4 
> - 2 files changed, 8 insertions(+)
> + 1 file changed, 4 insertions(+)
>
> -diff --git a/testcases/kernel/syscalls/accept4/Makefile 
> b/testcases/kernel/syscalls/accept4/Makefile
> -index 504042e11..94db06266 100644
>  a/testcases/kernel/syscalls/accept4/Makefile
> -+++ b/testcases/kernel/syscalls/accept4/Makefile
> -@@ -20,4 +20,8 @@ top_srcdir   ?= ../../../..
> -
> - include $(top_srcdir)/include/mk/testcases.mk
> -
> -+ifeq ($(LIBC),musl)
> -+FILTER_OUT_MAKE_TARGETS:= accept4_01
> -+endif
> -+
> - include $(top_srcdir)/include/mk/generic_leaf_target.mk
>  diff --git a/testcases/kernel/syscalls/timer_create/Makefile 
> b/testcases/kernel/syscalls/timer_create/Makefile
> -index 8de247075..eb240f432 100644
> +index ada241fe1..d454b01e7 100644
>  --- a/testcases/kernel/syscalls/timer_create/Makefile
>  +++ b/testcases/kernel/syscalls/timer_create/Makefile
> -@@ -20,6 +20,10 @@ top_srcdir  ?= ../../../..
> +@@ -5,6 +5,10 @@ top_srcdir?= ../../../..
>
>   include $(top_srcdir)/include/mk/testcases.mk
>
> @@ -40,5 +27,6 @@ index 8de247075..eb240f432 100644
>   CPPFLAGS  += -D_GNU_SOURCE -I$(ab

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Peter Kjellerstedt]

> -Original Message-
> From: Randy MacLeod 
> Sent: den 19 maj 2020 23:45
> To: Peter Kjellerstedt ; Rahul Kumar
> 
> Cc: Alexander Kanavin ; Richard Purdie
> ; OE-core  c...@lists.openembedded.org>; Trevor Gamblin
> 
> Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> 
> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> > The jzlib license is a three clause BSD license, and so is the
> > go/LICENSE, so you should be able to set LICENSE as:
> >
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
> 
> Peter,
> 
> I respectfully disagree.
> 
> The only source that is _executed_ in normal use by bzip2-test is
> the run-tests.sh script that is licensed as GPLv3+

Well, I am definitely not a lawyer either, but I am pretty sure that 
whether something that is distributed under a certain license is 
executed or not is irrelevant (unless of course the license covers 
execution of the code).

> The other files, although they came from source packages,
> are *only* used as  test data. The source code has been completely
> stripped out, hasn't it?

Given that they were originally distributed in an archive together 
with a LICENSE/COPYING/similar file covering the entire archive, 
those files are still covered by that license even if they are not 
source files per se.

> If, instead of compressed data,
> someone were to give me an image file covered by a creative common's
> license and the image had a watermark that when extracted produced
> file with source code with a FOO license, would you change the
> package license to include FOO? In fact, we don't even look at
> image file licensing let alone at embedded watermarks.

Well, if there is a file distributed in the picture (not using the 
word "image" here to avoid confusing the discussion any more) in the 
form of a watermark, then that is no different from distributing it 
as part of a tar.gz file (albeit a bit unusual). Whatever license 
that file is covered by still applies in both cases.

Actually, here is something to think about. I recently read an 
article published by the Linux Foundation called "Docker Containers 
for Legal Professionals". [1] There they discussed the distribution 
of Docker images. Consider this, you take an existing Docker image, 
e.g., fedora:32, and remove everything that is covered by GPL-3.0 
(not sure how to actually accomplish that, but anyway) and then you 
distribute this new Docker image to someone. Does this mean that 
GPL-3.0 covered code is being distributed? The answer is yes. 
Because of the way Docker images are made up from layers, you need 
to adhere to the licenses covering everything in all layers, not 
just the final result. And somewhere down the stack of layers 
making up your Docker image is still all of that GPL-3.0 code 
that you removed in a higher layer.

> I'm not a lawyer so this is simply my opinion on the matter.
> How do we come to an agreement?
> I'd be happy to add a comment in the recipe explaining our position:
> 
> # This package contains a script and test data this is derived from
> # other software packages as explained in the top level README.
> # Although there are COPYING files explaining the license terms
> # for each sub-directory, the files in each directory are only used
> # as test data so the LICENSING terms do not appear to apply to
> # the recipe as we ship it and have therefore NOT been incorporated
> # into the bzip2-ptests recipe licensing tags.

I would be very worried seeing such a statement, and I believe any 
lawyer would too.

> I can consult with some intellectual property experts that I know
> about this particular case if you like.

If you have the possibility to do so, I think it may be a good idea.

> ../Randy

//Peter

[1] 
https://www.linuxfoundation.org/wp-content/uploads/2020/04/Docker-Containers-for-Legal-Professionals-Whitepaper_v4.ac_-3.pdf

> > You also need to add:
> >
> > LICENSE_${PN} = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dev = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dbg = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-doc = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-src = "bzip2-1.0.6"
> >
> > LICENSE_libbz2 = "bzip2-1.0.6"
> >
> > so the non-ptest packages are not affected by the licenses for the
> ptest
> > package.
> >
> > //Peter
> >
> > *From:*Rahul Kumar 
> > *Sent:* den 19 maj 2020 13:58
> > *To:* Peter Kjellerstedt 
> > *Cc:* Randy MacLeod ; Alexander Kanavin
> > ; Richard Purdie
> > ; OE-core
> > ; Trevor Gamblin
> > 
> > *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >
> > Hi Peter,
> >
> > I am sharing a few information related to bzip2-test source and
> > licensing information.
> > As per your suggestion and as per my understanding I added License to
> > the bzip2 recipe file.
> >
> > bzip2-tests.git source tree structure is given below
> > (here showing licence related fle, removed other file names )
> >
> > bzip2-tests.git/
> > ├──commons-compress
> > │ ├──LICENSE.txt
> > │
> > ├──dotnetzip
>

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

[Khem Raj]

On Tue, May 19, 2020 at 3:02 PM Richard Purdie
 wrote:
>
> On Tue, 2020-05-19 at 20:36 +0200, Konrad Weihmann wrote:
> > in case the opkg command fails in before no output of the tool
> > itself was printed to assist the user with debugging the issue.
> > Print all output of the tool by using CalledProcessError wrapper around
> > the call
> >
> > Signed-off-by: Konrad Weihmann 
> > ---
> >  meta/classes/package_ipk.bbclass | 11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/classes/package_ipk.bbclass 
> > b/meta/classes/package_ipk.bbclass
> > index c008559e4a..5e7d552cc5 100644
> > --- a/meta/classes/package_ipk.bbclass
> > +++ b/meta/classes/package_ipk.bbclass
> > @@ -223,10 +223,13 @@ def ipk_write_pkg(pkg, d):
> >  conffiles.close()
> >
> >  os.chdir(basedir)
> > -subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> > (localdata.getVar("PATH"),
> > -  
> > d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> > -stderr=subprocess.STDOUT,
> > -shell=True)
> > +try:
> > +subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> > (localdata.getVar("PATH"),
> > +
> > d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> > +stderr=subprocess.STDOUT,
> > +shell=True)
> > +except subprocess.CalledProcessError as exp:
> > +bb.fatal("{} failed with {}: {}".format(exp.cmd, 
> > exp.returncode, exp.output.decode("utf-8")))
> >
> >  if d.getVar('IPK_SIGN_PACKAGES') == '1':
> >  ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))
>
> I get the feeling we have a problem with our subprocess calls and
> debugging but its hard to know what to do about it. We can patch each
> call site like this but it starts to make we wonder whether we need a
> general wrapper, or we're missing something in bitbake or elsewhere to
> help with things.
>
> There is this code:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n378
>
> which is meant to help but it clearly isn't helping/catching all cases.
>
> I think we are going to need to look at a wider/more general solution
> or at least have a plan for one.
>


are you think of wrapping subprocess.check_output calls with some post
processing ?

> Cheers,
>
> Richard
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138494): 
https://lists.openembedded.org/g/openembedded-core/message/138494
Mute This Topic: https://lists.openembedded.org/mt/74331803/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

[Denys Dmytriyenko]

On Tue, May 19, 2020 at 11:02:46PM +0100, Richard Purdie wrote:
> On Tue, 2020-05-19 at 20:36 +0200, Konrad Weihmann wrote:
> > in case the opkg command fails in before no output of the tool
> > itself was printed to assist the user with debugging the issue.
> > Print all output of the tool by using CalledProcessError wrapper around
> > the call
> > 
> > Signed-off-by: Konrad Weihmann 
> > ---
> >  meta/classes/package_ipk.bbclass | 11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/meta/classes/package_ipk.bbclass 
> > b/meta/classes/package_ipk.bbclass
> > index c008559e4a..5e7d552cc5 100644
> > --- a/meta/classes/package_ipk.bbclass
> > +++ b/meta/classes/package_ipk.bbclass
> > @@ -223,10 +223,13 @@ def ipk_write_pkg(pkg, d):
> >  conffiles.close()
> >  
> >  os.chdir(basedir)
> > -subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> > (localdata.getVar("PATH"),
> > -  
> > d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> > -stderr=subprocess.STDOUT,
> > -shell=True)
> > +try:
> > +subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> > (localdata.getVar("PATH"),
> > +
> > d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> > +stderr=subprocess.STDOUT,
> > +shell=True)
> > +except subprocess.CalledProcessError as exp:
> > +bb.fatal("{} failed with {}: {}".format(exp.cmd, 
> > exp.returncode, exp.output.decode("utf-8")))
> >  
> >  if d.getVar('IPK_SIGN_PACKAGES') == '1':
> >  ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))
> 
> I get the feeling we have a problem with our subprocess calls and
> debugging but its hard to know what to do about it. We can patch each
> call site like this but it starts to make we wonder whether we need a
> general wrapper, or we're missing something in bitbake or elsewhere to
> help with things.
> 
> There is this code:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n378
> 
> which is meant to help but it clearly isn't helping/catching all cases.
> 
> I think we are going to need to look at a wider/more general solution
> or at least have a plan for one.

I would just like to add my +1 here - debugging opkg errors was quite 
challenging at times due to inadequate logs. While other areas of the 
project have seen tremendous improvements in the meaningful logs 
department, poor old opkg was lacking. So, a more generic approach may 
be required - I'm all for it.

-- 
Denys


> Cheers,
> 
> Richard
> 

> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138493): 
https://lists.openembedded.org/g/openembedded-core/message/138493
Mute This Topic: https://lists.openembedded.org/mt/74331803/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Khem Raj]

On Tue, May 19, 2020 at 2:46 PM Randy MacLeod
 wrote:
>
> On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
> > The jzlib license is a three clause BSD license, and so is the
> > go/LICENSE, so you should be able to set LICENSE as:
> >
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>
> Peter,
>
> I respectfully disagree.
>
> The only source that is _executed_ in normal use by bzip2-test is
> the run-tests.sh script that is licensed as GPLv3+
>
> The other files, although they came from source packages,
> are *only* used as  test data. The source code has been completely
> stripped out, hasn't it?
>
> If, instead of compressed data,
> someone were to give me an image file covered by a creative common's
> license and the image had a watermark that when extracted produced
> file with source code with a FOO license, would you change the
> package license to include FOO? In fact, we don't even look at
> image file licensing let alone at embedded watermarks.
>
>
> I'm not a lawyer so this is simply my opinion on the matter.
> How do we come to an agreement?
> I'd be happy to add a comment in the recipe explaining our position:
>
> # This package contains a script and test data this is derived from
> # other software packages as explained in the top level README.
> # Although there are COPYING files explaining the license terms
> # for each sub-directory, the files in each directory are only used
> # as test data so the LICENSING terms do not appear to apply to
> # the recipe as we ship it and have therefore NOT been incorporated
> # into the bzip2-ptests recipe licensing tags.

a simple question is, are you distributing this shell script or not.
If you are then you will fall under
the all of the license obligations of the governing license for
distributing it.

As far as image license it concerned, then we generate a separate
license manifest for images
which comprise of package licenses that form the image.

>
> I can consult with some intellectual property experts that I know
> about this particular case if you like.
>
> ../Randy
>
>
> >
> > You also need to add:
> >
> > LICENSE_${PN} = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dev = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-dbg = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-doc = "bzip2-1.0.6"
> >
> > LICENSE_${PN}-src = "bzip2-1.0.6"
> >
> > LICENSE_libbz2 = "bzip2-1.0.6"
> >
> > so the non-ptest packages are not affected by the licenses for the ptest
> > package.
> >
> > //Peter
> >
> > *From:*Rahul Kumar 
> > *Sent:* den 19 maj 2020 13:58
> > *To:* Peter Kjellerstedt 
> > *Cc:* Randy MacLeod ; Alexander Kanavin
> > ; Richard Purdie
> > ; OE-core
> > ; Trevor Gamblin
> > 
> > *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
> >
> > Hi Peter,
> >
> > I am sharing a few information related to bzip2-test source and
> > licensing information.
> > As per your suggestion and as per my understanding I added License to
> > the bzip2 recipe file.
> >
> > bzip2-tests.git source tree structure is given below
> > (here showing licence related fle, removed other file names )
> >
> > bzip2-tests.git/
> > ├──commons-compress
> > │ ├──LICENSE.txt
> > │
> > ├──dotnetzip
> > │ ├──License.txt
> > │ ├──License.zlib.txt
> > |
> > ├──go
> > │ ├──LICENSE
> > │
> > ├──lbzip2
> > ├──pyflate
> > ├──README
> > └── run-tests.sh
> >
> > source code link:
> > https://sourceware.org/git/bzip2-tests.git
> >
> > bzip2-tests.git source contains
> > 1) comman-commpress: which is Originally distributed under the Apache
> > License Version 2.0.
> >
> > See LICENSE.txt
> >
> >
> > 2) dotnetzip:
> > (i)  The DotNetZip Library is distributed under the MicroSoft Public License
> >  (Ms-PL) see the License.txt file.
> > (ii) The BZ2 related resources are distributed under the licenses in
> > License.zlib.txt.
> >
> > 3) go:
> >
> >   Go is distributed under a BSD-style license.
> >   See the LICENSE file.
> >
> > 4) lbzip2:
> > lbzip2 is free software: you can redistribute it and/or modify it under the
> > terms of the GNU General Public License as published by the Free Software
> > Foundation, either version 3 of the License, or (at your option) any later
> > version
> >
> > 5) pyflate: You may use and distribute this code and documentation under any
> >  DFSG-compatible license (eg. BSD, GNU GPLv2).
> >
> > 6) run-tests.sh: you can redistribute it and/or modify it under the
> > terms of the GNU General Public License (GPL); either
> >   version 3, or (at your option) any later version.
> >
> >
> > SO in recipe I added the License like below
> > LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> > LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> > LIC_FILES_CHKSUM =
> > "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
> > \
> >
> > file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
> > \ # For comman-commpress (Apache-2.0)
> >
> > file://${WORKDIR}

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

[Richard Purdie]

On Tue, 2020-05-19 at 20:36 +0200, Konrad Weihmann wrote:
> in case the opkg command fails in before no output of the tool
> itself was printed to assist the user with debugging the issue.
> Print all output of the tool by using CalledProcessError wrapper around
> the call
> 
> Signed-off-by: Konrad Weihmann 
> ---
>  meta/classes/package_ipk.bbclass | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/classes/package_ipk.bbclass 
> b/meta/classes/package_ipk.bbclass
> index c008559e4a..5e7d552cc5 100644
> --- a/meta/classes/package_ipk.bbclass
> +++ b/meta/classes/package_ipk.bbclass
> @@ -223,10 +223,13 @@ def ipk_write_pkg(pkg, d):
>  conffiles.close()
>  
>  os.chdir(basedir)
> -subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> (localdata.getVar("PATH"),
> -  
> d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> -stderr=subprocess.STDOUT,
> -shell=True)
> +try:
> +subprocess.check_output("PATH=\"%s\" %s %s %s" % 
> (localdata.getVar("PATH"),
> +
> d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
> +stderr=subprocess.STDOUT,
> +shell=True)
> +except subprocess.CalledProcessError as exp:
> +bb.fatal("{} failed with {}: {}".format(exp.cmd, exp.returncode, 
> exp.output.decode("utf-8")))
>  
>  if d.getVar('IPK_SIGN_PACKAGES') == '1':
>  ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))

I get the feeling we have a problem with our subprocess calls and
debugging but its hard to know what to do about it. We can patch each
call site like this but it starts to make we wonder whether we need a
general wrapper, or we're missing something in bitbake or elsewhere to
help with things.

There is this code:

http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/utils.py#n378

which is meant to help but it clearly isn't helping/catching all cases.

I think we are going to need to look at a wider/more general solution
or at least have a plan for one.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138491): 
https://lists.openembedded.org/g/openembedded-core/message/138491
Mute This Topic: https://lists.openembedded.org/mt/74331803/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Randy MacLeod]

On 2020-05-19 12:29 p.m., Peter Kjellerstedt wrote:
The jzlib license is a three clause BSD license, and so is the 
go/LICENSE, so you should be able to set LICENSE as:


LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"


Peter,

I respectfully disagree.

The only source that is _executed_ in normal use by bzip2-test is
the run-tests.sh script that is licensed as GPLv3+

The other files, although they came from source packages,
are *only* used as  test data. The source code has been completely
stripped out, hasn't it?

If, instead of compressed data,
someone were to give me an image file covered by a creative common's
license and the image had a watermark that when extracted produced
file with source code with a FOO license, would you change the
package license to include FOO? In fact, we don't even look at
image file licensing let alone at embedded watermarks.


I'm not a lawyer so this is simply my opinion on the matter.
How do we come to an agreement?
I'd be happy to add a comment in the recipe explaining our position:

# This package contains a script and test data this is derived from
# other software packages as explained in the top level README.
# Although there are COPYING files explaining the license terms
# for each sub-directory, the files in each directory are only used
# as test data so the LICENSING terms do not appear to apply to
# the recipe as we ship it and have therefore NOT been incorporated
# into the bzip2-ptests recipe licensing tags.

I can consult with some intellectual property experts that I know
about this particular case if you like.

../Randy




You also need to add:

LICENSE_${PN} = "bzip2-1.0.6"

LICENSE_${PN}-dev = "bzip2-1.0.6"

LICENSE_${PN}-dbg = "bzip2-1.0.6"

LICENSE_${PN}-doc = "bzip2-1.0.6"

LICENSE_${PN}-src = "bzip2-1.0.6"

LICENSE_libbz2 = "bzip2-1.0.6"

so the non-ptest packages are not affected by the licenses for the ptest 
package.


//Peter

*From:*Rahul Kumar 
*Sent:* den 19 maj 2020 13:58
*To:* Peter Kjellerstedt 
*Cc:* Randy MacLeod ; Alexander Kanavin 
; Richard Purdie 
; OE-core 
; Trevor Gamblin 


*Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

Hi Peter,

I am sharing a few information related to bzip2-test source and 
licensing information.
As per your suggestion and as per my understanding I added License to 
the bzip2 recipe file.


bzip2-tests.git source tree structure is given below
(here showing licence related fle, removed other file names )

bzip2-tests.git/
├──commons-compress
│ ├──LICENSE.txt
│
├──dotnetzip
│ ├──License.txt
│ ├──License.zlib.txt
|
├──go
│ ├──LICENSE
│
├──lbzip2
├──pyflate
├──README
└── run-tests.sh

source code link:
https://sourceware.org/git/bzip2-tests.git

bzip2-tests.git source contains
1) comman-commpress: which is Originally distributed under the Apache 
License Version 2.0.


See LICENSE.txt


2) dotnetzip:
(i)  The DotNetZip Library is distributed under the MicroSoft Public License
     (Ms-PL) see the License.txt file.
(ii) The BZ2 related resources are distributed under the licenses in 
License.zlib.txt.


3) go:

  Go is distributed under a BSD-style license.
  See the LICENSE file.

4) lbzip2:
lbzip2 is free software: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version

5) pyflate: You may use and distribute this code and documentation under any
             DFSG-compatible license (eg. BSD, GNU GPLv2).

6) run-tests.sh: you can redistribute it and/or modify it under the 
terms of the GNU General Public License (GPL); either

                  version 3, or (at your option) any later version.


SO in recipe I added the License like below
LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
LIC_FILES_CHKSUM = 
"file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664 
\
 
file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327 
\ # For comman-commpress (Apache-2.0)
 
file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f 
\      # For dotnetzip (Ms-PL)
 
file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f 
\   # For dotnetzip  (jzlib +zlib)
 
file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \ 
      # For go (BSD-style license)


here I need few suggestion:

1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
    but not added LIC_FILES_CHKSUM for GPLv3 and BSD because 
bzip2-tests.git source code doesn't have GPLv3 and BSD License text file 
like other

    directories.

2) License.zlib.txt: This is a combination of two licence jzlib and 
zlib. In meta/files/common-licenses Zlib license is available but not jzlib.

  

Re: [oe-core][PATCH 1/3] squashfs-tools: gcc-10

[Adrian Bunk]

On Tue, May 19, 2020 at 02:09:27PM -0700, Joe Slater wrote:
> Add -fcommon to CFLAGS to avoid multiple definition errors for uninitialized 
> variables.
>...

The upstream fix is already backported in master.

cu
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138489): 
https://lists.openembedded.org/g/openembedded-core/message/138489
Mute This Topic: https://lists.openembedded.org/mt/74335778/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe-core][PATCH 1/3] squashfs-tools: gcc-10

[Jacob Kroon]

Hi Joe,

On 5/19/20 11:09 PM, Joe Slater wrote:

Add -fcommon to CFLAGS to avoid multiple definition errors for uninitialized 
variables.

Signed-off-by: Joe Slater 
---
  meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb | 2 ++
  1 file changed, 2 insertions(+)



[cut]

I hope this is already fixed in master by:

https://git.openembedded.org/openembedded-core/commit/?id=bae1603a27fadcfa7257801167f28db3ff02dc97

?

/Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138488): 
https://lists.openembedded.org/g/openembedded-core/message/138488
Mute This Topic: https://lists.openembedded.org/mt/74335778/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/3] syslinux: gcc-10

[Martin Jansa]

Wasn't this fixed by:
https://lists.openembedded.org/g/openembedded-core/message/138364
?

On Tue, May 19, 2020 at 11:10 PM Joe Slater 
wrote:

> Add -fcommon to CFLAGS to avoid multiple definition errors for
> uninitialized variables.
>
> Signed-off-by: Joe Slater 
> ---
>  meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
> b/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
> index e9dbefb930..5dfcfeec02 100644
> --- a/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
> +++ b/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
> @@ -40,6 +40,10 @@ EXTRA_OEMAKE = " \
> DATADIR=${datadir} MANDIR=${mandir} INCDIR=${includedir} \
>  "
>
> +# necessary for gcc-10
> +#
> +CFLAGS_append = " -fcommon"
> +
>  do_configure() {
> # drop win32 targets or build fails
> sed -e 's,win32/\S*,,g' -i Makefile
> --
> 2.26.2
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138487): 
https://lists.openembedded.org/g/openembedded-core/message/138487
Mute This Topic: https://lists.openembedded.org/mt/74335789/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/3] syslinux: gcc-10

[Joe Slater]

Add -fcommon to CFLAGS to avoid multiple definition errors for uninitialized 
variables.

Signed-off-by: Joe Slater 
---
 meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb 
b/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
index e9dbefb930..5dfcfeec02 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb
@@ -40,6 +40,10 @@ EXTRA_OEMAKE = " \
DATADIR=${datadir} MANDIR=${mandir} INCDIR=${includedir} \
 "
 
+# necessary for gcc-10
+#
+CFLAGS_append = " -fcommon"
+
 do_configure() {
# drop win32 targets or build fails
sed -e 's,win32/\S*,,g' -i Makefile
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138486): 
https://lists.openembedded.org/g/openembedded-core/message/138486
Mute This Topic: https://lists.openembedded.org/mt/74335789/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe-core][PATCH 1/3] squashfs-tools: gcc-10

[Joe Slater]

Add -fcommon to CFLAGS to avoid multiple definition errors for uninitialized 
variables.

Signed-off-by: Joe Slater 
---
 meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb 
b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
index 9bcf026ce2..d3f42a84fe 100644
--- a/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
+++ b/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb
@@ -12,6 +12,8 @@ SRC_URI = 
"git://github.com/plougher/squashfs-tools.git;protocol=https \
 
 S = "${WORKDIR}/git/squashfs-tools"
 
+CFLAGS_append = " -fcommon"
+
 EXTRA_OEMAKE = "${PACKAGECONFIG_CONFARGS}"
 
 PACKAGECONFIG ??= "gzip xz lzo lz4 lzma xattr reproducible"
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138485): 
https://lists.openembedded.org/g/openembedded-core/message/138485
Mute This Topic: https://lists.openembedded.org/mt/74335778/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe-core][PATCH 1/1] acpica: gcc-10

[Joe Slater]

Advance to version 20200430 to avoid multiple definition errors for 
uninitialized variables.
In this case, it is not enough to add -fcommon to CFLAGS.

Signed-off-by: Joe Slater 
---
 .../acpica/{acpica_20200214.bb => acpica_20200430.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/acpica/{acpica_20200214.bb => acpica_20200430.bb} 
(91%)

diff --git a/meta/recipes-extended/acpica/acpica_20200214.bb 
b/meta/recipes-extended/acpica/acpica_20200430.bb
similarity index 91%
rename from meta/recipes-extended/acpica/acpica_20200214.bb
rename to meta/recipes-extended/acpica/acpica_20200430.bb
index cfa9fec..478be7f 100644
--- a/meta/recipes-extended/acpica/acpica_20200214.bb
+++ b/meta/recipes-extended/acpica/acpica_20200430.bb
@@ -17,8 +17,8 @@ COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
 DEPENDS = "m4-native flex-native bison-native"
 
 SRC_URI = "https://acpica.org/sites/acpica/files/acpica-unix-${PV}.tar.gz";
-SRC_URI[md5sum] = "3505ba6170b77db1399eae0e2a959113"
-SRC_URI[sha256sum] = 
"e77ab9f8557ca104f6e8f49efaa8eead29f78ca11cadfc8989012469ecc0738e"
+SRC_URI[sha256sum] = 
"fb807f1dec31664f972af37d213abf72987afe33abf68c83051e298da35d297c"
+
 UPSTREAM_CHECK_URI = "https://acpica.org/downloads";
 
 S = "${WORKDIR}/acpica-unix-${PV}"
-- 
2.7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138484): 
https://lists.openembedded.org/g/openembedded-core/message/138484
Mute This Topic: https://lists.openembedded.org/mt/74335777/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 0/4] Import recipes from meta-python

[Andre McCurdy]

On Tue, May 19, 2020 at 11:25 AM Martin Jansa  wrote:
>
> We have discussed this in OE TSC meeting yesterday:
> https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532
>
> tsc suggested to use LAYERVERSION bump in oe-core with 
> LAYERDEPENDS_meta-python update in meta-python, so that people will need to 
> update both layers (or neither if they really cannot).

OE living up to it's nickname... Over Engineered :-)

> Joshua volunteered to send patches if everybody agrees on this proposal.
>
> On Tue, May 19, 2020 at 8:21 PM Steve Sakoman  wrote:
>>
>> On Sun, May 17, 2020 at 1:47 PM Khem Raj  wrote:
>>
>> > On 5/17/20 9:14 AM, Adrian Bunk wrote:
>>
>> > > IMHO moving recipes from meta-openembedded (or other layers) to oe-core
>> > > in a released stable series is not a good idea.
>> >
>> > I think in current form in this situation it certainly seems a bit
>> > complex sadly, however, we also need to explore if there is some "good"
>> > way of doing such changes without breaking distro builders.
>>
>> It seems we don't have a clear consensus that backporting these
>> patches to dunfell is a good idea.
>>
>> So for now I'm going to take the conservative approach and refrain
>> from taking these patches in LTS.
>>
>> We can always revisit this later if the situation changes.
>>
>> Steve
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138483): 
https://lists.openembedded.org/g/openembedded-core/message/138483
Mute This Topic: https://lists.openembedded.org/mt/74214757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

[Konrad Weihmann]

in case the opkg command fails in before no output of the tool
itself was printed to assist the user with debugging the issue.
Print all output of the tool by using CalledProcessError wrapper around
the call

Signed-off-by: Konrad Weihmann 
---
 meta/classes/package_ipk.bbclass | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index c008559e4a..5e7d552cc5 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -223,10 +223,13 @@ def ipk_write_pkg(pkg, d):
 conffiles.close()
 
 os.chdir(basedir)
-subprocess.check_output("PATH=\"%s\" %s %s %s" % 
(localdata.getVar("PATH"),
-  
d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
-stderr=subprocess.STDOUT,
-shell=True)
+try:
+subprocess.check_output("PATH=\"%s\" %s %s %s" % 
(localdata.getVar("PATH"),
+
d.getVar("OPKGBUILDCMD"), pkg, pkgoutdir),
+stderr=subprocess.STDOUT,
+shell=True)
+except subprocess.CalledProcessError as exp:
+bb.fatal("{} failed with {}: {}".format(exp.cmd, exp.returncode, 
exp.output.decode("utf-8")))
 
 if d.getVar('IPK_SIGN_PACKAGES') == '1':
 ipkver = "%s-%s" % (d.getVar('PKGV'), d.getVar('PKGR'))
-- 
2.20.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138482): 
https://lists.openembedded.org/g/openembedded-core/message/138482
Mute This Topic: https://lists.openembedded.org/mt/74331803/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 0/4] Import recipes from meta-python

[Martin Jansa]

We have discussed this in OE TSC meeting yesterday:
https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532

tsc suggested to use LAYERVERSION bump in oe-core with
LAYERDEPENDS_meta-python update in meta-python, so that people will need to
update both layers (or neither if they really cannot).

Joshua volunteered to send patches if everybody agrees on this proposal.

On Tue, May 19, 2020 at 8:21 PM Steve Sakoman  wrote:

> On Sun, May 17, 2020 at 1:47 PM Khem Raj  wrote:
>
> > On 5/17/20 9:14 AM, Adrian Bunk wrote:
>
> > > IMHO moving recipes from meta-openembedded (or other layers) to oe-core
> > > in a released stable series is not a good idea.
> >
> > I think in current form in this situation it certainly seems a bit
> > complex sadly, however, we also need to explore if there is some "good"
> > way of doing such changes without breaking distro builders.
>
> It seems we don't have a clear consensus that backporting these
> patches to dunfell is a good idea.
>
> So for now I'm going to take the conservative approach and refrain
> from taking these patches in LTS.
>
> We can always revisit this later if the situation changes.
>
> Steve
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138481): 
https://lists.openembedded.org/g/openembedded-core/message/138481
Mute This Topic: https://lists.openembedded.org/mt/74214757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 0/4] Import recipes from meta-python

[Steve Sakoman]

On Sun, May 17, 2020 at 1:47 PM Khem Raj  wrote:

> On 5/17/20 9:14 AM, Adrian Bunk wrote:

> > IMHO moving recipes from meta-openembedded (or other layers) to oe-core
> > in a released stable series is not a good idea.
>
> I think in current form in this situation it certainly seems a bit
> complex sadly, however, we also need to explore if there is some "good"
> way of doing such changes without breaking distro builders.

It seems we don't have a clear consensus that backporting these
patches to dunfell is a good idea.

So for now I'm going to take the conservative approach and refrain
from taking these patches in LTS.

We can always revisit this later if the situation changes.

Steve
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138480): 
https://lists.openembedded.org/g/openembedded-core/message/138480
Mute This Topic: https://lists.openembedded.org/mt/74214757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

Hi Peter,

Thank you for the quick response.
I will work on your suggestion.but I need your confirmation on
LIC_FILES_CHKSUM also.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com



On Tue, May 19, 2020 at 9:59 PM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> The jzlib license is a three clause BSD license, and so is the go/LICENSE,
> so you should be able to set LICENSE as:
>
>
>
> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"
>
>
>
> You also need to add:
>
>
>
> LICENSE_${PN} = "bzip2-1.0.6"
>
> LICENSE_${PN}-dev = "bzip2-1.0.6"
>
> LICENSE_${PN}-dbg = "bzip2-1.0.6"
>
> LICENSE_${PN}-doc = "bzip2-1.0.6"
>
> LICENSE_${PN}-src = "bzip2-1.0.6"
>
> LICENSE_libbz2 = "bzip2-1.0.6"
>
>
>
> so the non-ptest packages are not affected by the licenses for the ptest
> package.
>
>
>
> //Peter
>
>
>
> *From:* Rahul Kumar 
> *Sent:* den 19 maj 2020 13:58
> *To:* Peter Kjellerstedt 
> *Cc:* Randy MacLeod ; Alexander Kanavin <
> alex.kana...@gmail.com>; Richard Purdie <
> richard.pur...@linuxfoundation.org>; OE-core <
> openembedded-core@lists.openembedded.org>; Trevor Gamblin <
> trevor.gamb...@windriver.com>
> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>
>
>
> Hi Peter,
>
> I am sharing a few information related to bzip2-test source and licensing
> information.
> As per your suggestion and as per my understanding I added License to the
> bzip2 recipe file.
>
> bzip2-tests.git source tree structure is given below
> (here showing licence related fle, removed other file names )
>
> bzip2-tests.git/
> ├── commons-compress
> │   ├── LICENSE.txt
> │
> ├── dotnetzip
> │   ├── License.txt
> │   ├── License.zlib.txt
> |
> ├── go
> │   ├── LICENSE
> │
> ├── lbzip2
> ├── pyflate
> ├── README
> └── run-tests.sh
>
> source code link:
> https://sourceware.org/git/bzip2-tests.git
>
> bzip2-tests.git source contains
> 1) comman-commpress: which is Originally distributed under the Apache
> License Version 2.0.
>
> See LICENSE.txt
>
>
> 2) dotnetzip:
> (i)  The DotNetZip Library is distributed under the MicroSoft Public
> License
> (Ms-PL) see the License.txt file.
> (ii) The BZ2 related resources are distributed under the licenses in
> License.zlib.txt.
>
> 3) go:
>
>  Go is distributed under a BSD-style license.
>  See the LICENSE file.
>
> 4) lbzip2:
> lbzip2 is free software: you can redistribute it and/or modify it under the
> terms of the GNU General Public License as published by the Free Software
> Foundation, either version 3 of the License, or (at your option) any later
> version
>
> 5) pyflate: You may use and distribute this code and documentation under
> any
> DFSG-compatible license (eg. BSD, GNU GPLv2).
>
> 6) run-tests.sh: you can redistribute it and/or modify it under the terms
> of the GNU General Public License (GPL); either
>  version 3, or (at your option) any later version.
>
>
> SO in recipe I added the License like below
> LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
> LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
> LIC_FILES_CHKSUM =
> "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
> \
>
> file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
> \ # For comman-commpress (Apache-2.0)
>
> file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f
> \  # For dotnetzip (Ms-PL)
>
> file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f
> \   # For dotnetzip  (jzlib +zlib)
>
> file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
>  # For go (BSD-style license)
>
> here I need few suggestion:
>
> 1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
>but not added LIC_FILES_CHKSUM for GPLv3 and BSD because
> bzip2-tests.git source code doesn't have GPLv3 and BSD License text file
> like other
>directories.
>
> 2) License.zlib.txt: This is a combination of two licence jzlib and zlib.
> In meta/files/common-licenses Zlib license is available but not jzlib.
>In this case how can I proceed?
>
> Kindly comment on this and feel free to point out if i am wrong at any
> place.
>
>
>
> *Thanks & Regards,*
>
> Rahul Kumar
>
> Software Engineer,Linux Solutions Engineering
>
> Group,Montavista Software LLC
>
> Email Id: rah...@mvista.com
> 
>
>
>
>
>
> On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt <
> peter.kjellerst...@axis.com> wrote:
>
> As I wrote in my previous mail, when it comes to licenses, it is the
> distribution that is important. So if you build a package (bzip2-ptest)
> that includes code that is GPL-3.0, it does not matter if that code is only
> used as a binary blob, it is still distributed in the package, and thus the
> package needs to be cover

[OE-core] [PATCH] devtool: do not write md5sums into upgraded recipes

[Alexander Kanavin]

This will drop them md5sums from recipes that still have them,
and will not re-add them for recipes where they're already
removed.

Signed-off-by: Alexander Kanavin 
---
 scripts/lib/devtool/upgrade.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/devtool/upgrade.py b/scripts/lib/devtool/upgrade.py
index cb6dce378a..f962a71e41 100644
--- a/scripts/lib/devtool/upgrade.py
+++ b/scripts/lib/devtool/upgrade.py
@@ -391,12 +391,12 @@ def _create_new_recipe(newpv, md5, sha256, srcrev, 
srcbranch, srcsubdir_old, src
 newvalues['SRC_URI[%s.md5sum]' % name] = None
 newvalues['SRC_URI[%s.sha256sum]' % name] = None
 
-if md5 and sha256:
+if sha256:
 if addnames:
 nameprefix = '%s.' % addnames[0]
 else:
 nameprefix = ''
-newvalues['SRC_URI[%smd5sum]' % nameprefix] = md5
+newvalues['SRC_URI[%smd5sum]' % nameprefix] = None
 newvalues['SRC_URI[%ssha256sum]' % nameprefix] = sha256
 
 if srcsubdir_new != srcsubdir_old:
-- 
2.26.2

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138478): 
https://lists.openembedded.org/g/openembedded-core/message/138478
Mute This Topic: https://lists.openembedded.org/mt/74329924/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Peter Kjellerstedt]

The jzlib license is a three clause BSD license, and so is the go/LICENSE, so 
you should be able to set LICENSE as:

LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD-3-Clause & Zlib"

You also need to add:

LICENSE_${PN} = "bzip2-1.0.6"
LICENSE_${PN}-dev = "bzip2-1.0.6"
LICENSE_${PN}-dbg = "bzip2-1.0.6"
LICENSE_${PN}-doc = "bzip2-1.0.6"
LICENSE_${PN}-src = "bzip2-1.0.6"
LICENSE_libbz2 = "bzip2-1.0.6"

so the non-ptest packages are not affected by the licenses for the ptest 
package.

//Peter

From: Rahul Kumar 
Sent: den 19 maj 2020 13:58
To: Peter Kjellerstedt 
Cc: Randy MacLeod ; Alexander Kanavin 
; Richard Purdie ; 
OE-core ; Trevor Gamblin 

Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

Hi Peter,

I am sharing a few information related to bzip2-test source and licensing 
information.
As per your suggestion and as per my understanding I added License to the bzip2 
recipe file.
bzip2-tests.git source tree structure is given below
(here showing licence related fle, removed other file names )
bzip2-tests.git/
├── commons-compress
│   ├── LICENSE.txt
│
├── dotnetzip
│   ├── License.txt
│   ├── License.zlib.txt
|
├── go
│   ├── LICENSE
│
├── lbzip2
├── pyflate
├── README
└── run-tests.sh

source code link:
https://sourceware.org/git/bzip2-tests.git

bzip2-tests.git source contains
1) comman-commpress: which is Originally distributed under the Apache License 
Version 2.0.
See LICENSE.txt

2) dotnetzip:
(i)  The DotNetZip Library is distributed under the MicroSoft Public License
(Ms-PL) see the License.txt file.
(ii) The BZ2 related resources are distributed under the licenses in 
License.zlib.txt.

3) go:
 Go is distributed under a BSD-style license.
 See the LICENSE file.

4) lbzip2:
lbzip2 is free software: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version

5) pyflate: You may use and distribute this code and documentation under any
DFSG-compatible license (eg. BSD, GNU GPLv2).

6) run-tests.sh: you can redistribute it and/or modify it under the terms of 
the GNU General Public License (GPL); either
 version 3, or (at your option) any later version.


SO in recipe I added the License like below
LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
LIC_FILES_CHKSUM = 
"file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664 \

file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
 \ # For comman-commpress (Apache-2.0)

file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f
 \  # For dotnetzip (Ms-PL)

file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f
 \   # For dotnetzip  (jzlib +zlib)

file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \  # 
For go (BSD-style license)

here I need few suggestion:

1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
   but not added LIC_FILES_CHKSUM for GPLv3 and BSD because bzip2-tests.git 
source code doesn't have GPLv3 and BSD License text file like other
   directories.

2) License.zlib.txt: This is a combination of two licence jzlib and zlib. In 
meta/files/common-licenses Zlib license is available but not jzlib.
   In this case how can I proceed?

Kindly comment on this and feel free to point out if i am wrong at any place.

Thanks & Regards,
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com



On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt 
mailto:peter.kjellerst...@axis.com>> wrote:
As I wrote in my previous mail, when it comes to licenses, it is the 
distribution that is important. So if you build a package (bzip2-ptest) that 
includes code that is GPL-3.0, it does not matter if that code is only used as 
a binary blob, it is still distributed in the package, and thus the package 
needs to be covered by the GPL-3.0 license.

//Peter

From: 
openembedded-core@lists.openembedded.org
 
mailto:openembedded-core@lists.openembedded.org>>
 On Behalf Of Rahul Kumar
Sent: den 17 maj 2020 21:18
To: Randy MacLeod 
mailto:randy.macl...@windriver.com>>
Cc: Alexander Kanavin mailto:alex.kana...@gmail.com>>; 
Richard Purdie 
mailto:richard.pur...@linuxfoundation.org>>;
 OE-core 
mailto:openembedded-core@lists.openembedded.org>>;
 Trevor Gamblin 
mailto:trevor.gamb...@windriver.com>>
Subject: Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

Hi Randy,

patch has been accepted by bzip2 community with additional changes.
https://sourceware.org/git/?p=bzip2-tests.git;a=co

Re: [OE-core] [PATCH] libubootenv: Depend on zlib

[Khem Raj]

On Tue, May 19, 2020 at 9:07 AM Stefano Babic  wrote:
>
> Hi Khem,
>
> On 19.05.20 17:56, Khem Raj wrote:
> > On Mon, May 18, 2020 at 1:28 AM Marek Vasut  wrote:
> >>
> >> The libubootenv depends on zlib as it calls at least crc32() from
> >> there and links against it. Add the DEPENDS entry.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Stefano Babic 
> >> ---
> >>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> >> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> >> index 3251d0f05b..fa90a12bf8 100644
> >> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> >> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> >> @@ -1,5 +1,5 @@
> >>  SUMMARY = "U-Boot libraries and tools to access environment"
> >> -DEPENDS += "mtd-utils"
> >> +DEPENDS += "mtd-utils zlib"
> >>
>
> It can't, it is not an option. U-Boot requires a CRC-32 on the
> environment and zlib is always linked to the binaries fw_setenv /
> fw_printenv.
>

OK thanks

> Stefano
>
> >
> > should this be a packageconfig
> >
> >>  DESCRIPTION = "This package contains tools and libraries to read \
> >>  and modify U-Boot environment. \
> >> --
> >> 2.25.1
> >>
> >> 
>
>
> --
> =
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138476): 
https://lists.openembedded.org/g/openembedded-core/message/138476
Mute This Topic: https://lists.openembedded.org/mt/74287225/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libubootenv: Depend on zlib

[Stefano Babic]

Hi Khem,

On 19.05.20 17:56, Khem Raj wrote:
> On Mon, May 18, 2020 at 1:28 AM Marek Vasut  wrote:
>>
>> The libubootenv depends on zlib as it calls at least crc32() from
>> there and links against it. Add the DEPENDS entry.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Stefano Babic 
>> ---
>>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
>> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
>> index 3251d0f05b..fa90a12bf8 100644
>> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
>> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
>> @@ -1,5 +1,5 @@
>>  SUMMARY = "U-Boot libraries and tools to access environment"
>> -DEPENDS += "mtd-utils"
>> +DEPENDS += "mtd-utils zlib"
>>

It can't, it is not an option. U-Boot requires a CRC-32 on the
environment and zlib is always linked to the binaries fw_setenv /
fw_printenv.

Stefano

> 
> should this be a packageconfig
> 
>>  DESCRIPTION = "This package contains tools and libraries to read \
>>  and modify U-Boot environment. \
>> --
>> 2.25.1
>>
>> 


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138475): 
https://lists.openembedded.org/g/openembedded-core/message/138475
Mute This Topic: https://lists.openembedded.org/mt/74287225/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libubootenv: Depend on zlib

[Khem Raj]

On Mon, May 18, 2020 at 1:28 AM Marek Vasut  wrote:
>
> The libubootenv depends on zlib as it calls at least crc32() from
> there and links against it. Add the DEPENDS entry.
>
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> ---
>  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
> b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> index 3251d0f05b..fa90a12bf8 100644
> --- a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> +++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
> @@ -1,5 +1,5 @@
>  SUMMARY = "U-Boot libraries and tools to access environment"
> -DEPENDS += "mtd-utils"
> +DEPENDS += "mtd-utils zlib"
>

should this be a packageconfig

>  DESCRIPTION = "This package contains tools and libraries to read \
>  and modify U-Boot environment. \
> --
> 2.25.1
>
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138474): 
https://lists.openembedded.org/g/openembedded-core/message/138474
Mute This Topic: https://lists.openembedded.org/mt/74287225/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 2/8] python: Upgrade 2.7.17 -> 2.17.18

[akuster]

From: Adrian Bunk 

LICENSE checksum changed due to 2019 -> 2020 update.

Signed-off-by: Adrian Bunk 
Signed-off-by: Anuj Mittal 
Signed-off-by: Armin Kuster 
---
 .../{python-native_2.7.17.bb => python-native_2.7.18.bb}| 0
 meta/recipes-devtools/python/python.inc | 6 +++---
 .../python/{python_2.7.17.bb => python_2.7.18.bb}   | 0
 3 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/python/{python-native_2.7.17.bb => 
python-native_2.7.18.bb} (100%)
 rename meta/recipes-devtools/python/{python_2.7.17.bb => python_2.7.18.bb} 
(100%)

diff --git a/meta/recipes-devtools/python/python-native_2.7.17.bb 
b/meta/recipes-devtools/python/python-native_2.7.18.bb
similarity index 100%
rename from meta/recipes-devtools/python/python-native_2.7.17.bb
rename to meta/recipes-devtools/python/python-native_2.7.18.bb
diff --git a/meta/recipes-devtools/python/python.inc 
b/meta/recipes-devtools/python/python.inc
index a2424a67bf..bd214e8f8b 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -5,13 +5,13 @@ SECTION = "devel/python"
 # bump this on every change in contrib/python/generate-manifest-2.7.py
 INC_PR = "r1"
 
-LIC_FILES_CHKSUM = "file://LICENSE;md5=e466242989bd33c1bd2b6a526a742498"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=203a6dbc802ee896020a47161e759642"
 
 SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
"
 
-SRC_URI[md5sum] = "b3b6d2c92f42a60667814358ab9f0cfd"
-SRC_URI[sha256sum] = 
"4d43f033cdbd0aa7b7023c81b0e986fd11e653b5248dac9144d508f11812ba41"
+SRC_URI[md5sum] = "fd6cc8ec0a78c44036f825e739f36e5a"
+SRC_URI[sha256sum] = 
"b62c0e7937551d0cc02b8fd5cb0f544f9405bafc9a54d3808ed4594812edef43"
 
 # python recipe is actually python 2.x
 # also, exclude pre-releases for both python 2.x and 3.x
diff --git a/meta/recipes-devtools/python/python_2.7.17.bb 
b/meta/recipes-devtools/python/python_2.7.18.bb
similarity index 100%
rename from meta/recipes-devtools/python/python_2.7.17.bb
rename to meta/recipes-devtools/python/python_2.7.18.bb
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138467): 
https://lists.openembedded.org/g/openembedded-core/message/138467
Mute This Topic: https://lists.openembedded.org/mt/74326632/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 4/8] openssl: recommend cryptodev-module for corresponding PACKAGECONFIG

[akuster]

From: Denys Dmytriyenko 

Signed-off-by: Denys Dmytriyenko 
Signed-off-by: Richard Purdie 
(cherry picked from commit 57fcf9b517fe95e871122946cb99fe7fa9fd2e26)
Signed-off-by: Armin Kuster 
---
 meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index 67eea6592e..d656cb3cfa 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -33,7 +33,7 @@ PACKAGECONFIG ?= ""
 PACKAGECONFIG_class-native = ""
 PACKAGECONFIG_class-nativesdk = ""
 
-PACKAGECONFIG[cryptodev-linux] = 
"enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux"
+PACKAGECONFIG[cryptodev-linux] = 
"enable-devcryptoeng,disable-devcryptoeng,cryptodev-linux,,cryptodev-module"
 
 B = "${WORKDIR}/build"
 do_configure[cleandirs] = "${B}"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138469): 
https://lists.openembedded.org/g/openembedded-core/message/138469
Mute This Topic: https://lists.openembedded.org/mt/74326634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 6/8] openssl: update to 1.1.1f

[akuster]

From: Alexander Kanavin 

This also un-breaks python3 ptest which got broken
with 1.1.1e update.

Signed-off-by: Alexander Kanavin 
Signed-off-by: Richard Purdie 
(cherry picked from commit b4ddf5b9d8cd769b7026663f93c8bc69b55d8cbf)
[AK: bugfix only update]
Signed-off-by: Armin Kuster 
---
 .../openssl/{openssl_1.1.1e.bb => openssl_1.1.1f.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1e.bb => 
openssl_1.1.1f.bb} (98%)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1e.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1e.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
index d016bb67e7..204dc7c6fe 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1e.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
@@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[sha256sum] = 
"694f61ac11cb51c9bf73f54e771ff6022b0327a43bbdfa1b2f19de1662a6dcbe"
+SRC_URI[sha256sum] = 
"186c6bfe6ecfba7a5b48c47f8a1673d0f3b0e5ba2e25602dd23b629975da3f35"
 
 inherit lib_package multilib_header ptest
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138471): 
https://lists.openembedded.org/g/openembedded-core/message/138471
Mute This Topic: https://lists.openembedded.org/mt/74326636/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 8/8] cve-check: CPE version '-' as all version

[akuster]

From: Lee Chee Yang 

CPE version could be '-' to mean no version info.
Current cve_check treat it as not valid and does not report these
CVE but some of these could be a valid vulnerabilities.

Since non-valid CVE can be whitelisted, so treat '-' as all version
and report all these CVE to capture possible vulnerabilities.

Non-valid CVE to be whitelisted separately.

[YOCTO #13617]

Signed-off-by: Lee Chee Yang 
Signed-off-by: Richard Purdie 
(cherry picked from commit c69ee3594079589d27c10db32bc288566ebde9ef)
Signed-off-by: Armin Kuster 
---
 meta/classes/cve-check.bbclass | 2 +-
 meta/recipes-core/meta/cve-update-db-native.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 01b3637469..0ab022b135 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -214,7 +214,7 @@ def check_cves(d, patched_cves):
 (_, _, _, version_start, operator_start, version_end, 
operator_end) = row
 #bb.debug(2, "Evaluating row " + str(row))
 
-if (operator_start == '=' and pv == version_start):
+if (operator_start == '=' and pv == version_start) or 
version_start == '-':
 vulnerable = True
 else:
 if operator_start:
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb 
b/meta/recipes-core/meta/cve-update-db-native.bb
index 575254af40..1b4f31692b 100644
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ b/meta/recipes-core/meta/cve-update-db-native.bb
@@ -122,7 +122,7 @@ def parse_node_and_insert(c, node, cveId):
 product = cpe23[4]
 version = cpe23[5]
 
-if version != '*':
+if version != '*' and version != '-':
 # Version is defined, this is a '=' match
 yield [cveId, vendor, product, version, '=', '', '']
 else:
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138473): 
https://lists.openembedded.org/g/openembedded-core/message/138473
Mute This Topic: https://lists.openembedded.org/mt/74326639/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 3/8] openssl: Fix reproducibility issue

[akuster]

From: Richard Purdie 

There was a build architecture leaking into the target ptest which
could vary depending upon host. Remove it as its cosmetic.

[YOCTO #13770]

(From OE-Core rev: 37db519eedb7eb5cd4f14d05f30f5d580aa7458d)

(From OE-Core rev: c31c676319812e6fc036741db2ab8e16eccff723)

Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
 .../openssl/openssl/reproducible.patch| 32 +++
 .../openssl/openssl_1.1.1d.bb |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 meta/recipes-connectivity/openssl/openssl/reproducible.patch

diff --git a/meta/recipes-connectivity/openssl/openssl/reproducible.patch 
b/meta/recipes-connectivity/openssl/openssl/reproducible.patch
new file mode 100644
index 00..a24260c95d
--- /dev/null
+++ b/meta/recipes-connectivity/openssl/openssl/reproducible.patch
@@ -0,0 +1,32 @@
+The value for perl_archname can vary depending on the host, e.g. 
+x86_64-linux-gnu-thread-multi or x86_64-linux-thread-multi which
+makes the ptest package non-reproducible. Its unused other than 
+these references so drop it.
+
+RP 2020/2/6
+
+Upstream-Status: Pending
+Signed-off-by: Richard Purdie 
+
+Index: openssl-1.1.1d/Configure
+===
+--- openssl-1.1.1d.orig/Configure
 openssl-1.1.1d/Configure
+@@ -286,7 +286,7 @@ if (defined env($local_config_envname))
+ # Save away perl command information
+ $config{perl_cmd} = $^X;
+ $config{perl_version} = $Config{version};
+-$config{perl_archname} = $Config{archname};
++#$config{perl_archname} = $Config{archname};
+ 
+ $config{prefix}="";
+ $config{openssldir}="";
+@@ -2517,7 +2517,7 @@ _
+   @{$config{perlargv}}), "\n";
+ print "\nPerl information:\n\n";
+ print '',$config{perl_cmd},"\n";
+-print '',$config{perl_version},' for 
',$config{perl_archname},"\n";
++print '',$config{perl_version},"\n";
+ }
+ if ($dump || $options) {
+ my $longest = 0;
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index d256646934..67eea6592e 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -17,6 +17,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz 
\

file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
file://afalg.patch \
file://CVE-2019-1551.patch \
+   file://reproducible.patch \
"
 
 SRC_URI_append_class-nativesdk = " \
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138468): 
https://lists.openembedded.org/g/openembedded-core/message/138468
Mute This Topic: https://lists.openembedded.org/mt/74326633/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 0/8] Patch review

[akuster]

Here are the next set of changes for warrior last dot release.

Please have comments back by Friday.

The following changes since commit ae341aed81be28232cc34daf4684bc0922f17699:

  yocto-uninative.inc: version 2.8 updates glibc to 2.31 (2020-03-26 07:04:11 
-0700)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/warrior-nut
  http://cgit.openembedded.org//log/?h=stable/warrior-nut

Adrian Bunk (3):
  git: Upgrade 2.20.1 -> 2.20.4
  python: Upgrade 2.7.17 -> 2.17.18
  openssl: Upgrade 1.1.1d -> 1.1.1e

Alexander Kanavin (1):
  openssl: update to 1.1.1f

Denys Dmytriyenko (1):
  openssl: recommend cryptodev-module for corresponding PACKAGECONFIG

Jan Luebbe (1):
  openssl: upgrade 1.1.1f -> 1.1.1g

Lee Chee Yang (1):
  cve-check: CPE version '-' as all version

Richard Purdie (1):
  openssl: Fix reproducibility issue

 meta/classes/cve-check.bbclass|   2 +-
 .../openssl/openssl/CVE-2019-1551.patch   | 758 --
 .../openssl/openssl/reproducible.patch|  32 +
 .../{openssl_1.1.1d.bb => openssl_1.1.1g.bb}  |   7 +-
 .../recipes-core/meta/cve-update-db-native.bb |   2 +-
 meta/recipes-devtools/git/git_2.20.1.bb   |  11 -
 meta/recipes-devtools/git/git_2.20.4.bb   |  11 +
 ...tive_2.7.17.bb => python-native_2.7.18.bb} |   0
 meta/recipes-devtools/python/python.inc   |   6 +-
 .../{python_2.7.17.bb => python_2.7.18.bb}|   0
 10 files changed, 51 insertions(+), 778 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2019-1551.patch
 create mode 100644 meta/recipes-connectivity/openssl/openssl/reproducible.patch
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1d.bb => 
openssl_1.1.1g.bb} (97%)
 delete mode 100644 meta/recipes-devtools/git/git_2.20.1.bb
 create mode 100644 meta/recipes-devtools/git/git_2.20.4.bb
 rename meta/recipes-devtools/python/{python-native_2.7.17.bb => 
python-native_2.7.18.bb} (100%)
 rename meta/recipes-devtools/python/{python_2.7.17.bb => python_2.7.18.bb} 
(100%)

-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138465): 
https://lists.openembedded.org/g/openembedded-core/message/138465
Mute This Topic: https://lists.openembedded.org/mt/74326627/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 1/8] git: Upgrade 2.20.1 -> 2.20.4

[akuster]

From: Adrian Bunk 

This includes the fixes for CVE-2020-5260 and CVE-2020-11008.

Signed-off-by: Adrian Bunk 
Signed-off-by: Armin Kuster 
---
 meta/recipes-devtools/git/git_2.20.1.bb | 11 ---
 meta/recipes-devtools/git/git_2.20.4.bb | 11 +++
 2 files changed, 11 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-devtools/git/git_2.20.1.bb
 create mode 100644 meta/recipes-devtools/git/git_2.20.4.bb

diff --git a/meta/recipes-devtools/git/git_2.20.1.bb 
b/meta/recipes-devtools/git/git_2.20.1.bb
deleted file mode 100644
index 877fb05e58..00
--- a/meta/recipes-devtools/git/git_2.20.1.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require git.inc
-
-EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
- 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
- "
-EXTRA_OEMAKE += "NO_GETTEXT=1"
-
-SRC_URI[tarball.md5sum] = "7a7769e5c957364ed0aed89e6e67c254"
-SRC_URI[tarball.sha256sum] = 
"edc3bc1495b69179ba4e272e97eff93334a20decb1d8db6ec3c19c16417738fd"
-SRC_URI[manpages.md5sum] = "78c6e54a61a167dab5e8ae07036293ab"
-SRC_URI[manpages.sha256sum] = 
"e9c123463abd05e142defe44a8060ce6e9853dfd8c83b2542e38b7deac4e6d4c"
diff --git a/meta/recipes-devtools/git/git_2.20.4.bb 
b/meta/recipes-devtools/git/git_2.20.4.bb
new file mode 100644
index 00..e44da452ad
--- /dev/null
+++ b/meta/recipes-devtools/git/git_2.20.4.bb
@@ -0,0 +1,11 @@
+require git.inc
+
+EXTRA_OECONF += "ac_cv_snprintf_returns_bogus=no \
+ 
ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \
+ "
+EXTRA_OEMAKE += "NO_GETTEXT=1"
+
+SRC_URI[tarball.md5sum] = "6f524e37186a79848a716e2a91330868"
+SRC_URI[tarball.sha256sum] = 
"92719084d7648b69038ea617a3bc45ec74f60ed7eef753ae2ad84b6f0b268e9a"
+SRC_URI[manpages.md5sum] = "dceabcda244042a06ed4cabd754627a5"
+SRC_URI[manpages.sha256sum] = 
"72fdd1799756b1240921d10eb5c67de9a651b44d429ba7293929c9d5344ad3e0"
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138466): 
https://lists.openembedded.org/g/openembedded-core/message/138466
Mute This Topic: https://lists.openembedded.org/mt/74326630/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 7/8] openssl: upgrade 1.1.1f -> 1.1.1g

[akuster]

From: Jan Luebbe 

This also fixes CVE-2020-1967.

Signed-off-by: Jan Luebbe 
Signed-off-by: Anuj Mittal 
Signed-off-by: Armin Kuster 
---
 .../openssl/{openssl_1.1.1f.bb => openssl_1.1.1g.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1f.bb => 
openssl_1.1.1g.bb} (98%)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1f.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 204dc7c6fe..a57e09c802 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1f.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -23,7 +23,7 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[sha256sum] = 
"186c6bfe6ecfba7a5b48c47f8a1673d0f3b0e5ba2e25602dd23b629975da3f35"
+SRC_URI[sha256sum] = 
"ddb04774f1e32f0c49751e21b67216ac87852ceb056b75209af2443400636d46"
 
 inherit lib_package multilib_header ptest
 
-- 
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138472): 
https://lists.openembedded.org/g/openembedded-core/message/138472
Mute This Topic: https://lists.openembedded.org/mt/74326637/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [warrior 5/8] openssl: Upgrade 1.1.1d -> 1.1.1e

[akuster]

From: Adrian Bunk 

Backported patch removed.

Signed-off-by: Adrian Bunk 
Signed-off-by: Richard Purdie 
(cherry picked from commit 710bc0f8544f54750c8fb7b8affa243932927a24)
[AK: bug fix only update]
Signed-off-by: Armin Kuster 
---
 .../openssl/openssl/CVE-2019-1551.patch   | 758 --
 .../{openssl_1.1.1d.bb => openssl_1.1.1e.bb}  |   4 +-
 2 files changed, 1 insertion(+), 761 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2019-1551.patch
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1d.bb => 
openssl_1.1.1e.bb} (97%)

diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2019-1551.patch 
b/meta/recipes-connectivity/openssl/openssl/CVE-2019-1551.patch
deleted file mode 100644
index 0cc19cb5f4..00
--- a/meta/recipes-connectivity/openssl/openssl/CVE-2019-1551.patch
+++ /dev/null
@@ -1,758 +0,0 @@
-From 419102400a2811582a7a3d4a4e317d72e5ce0a8f Mon Sep 17 00:00:00 2001
-From: Andy Polyakov 
-Date: Wed, 4 Dec 2019 12:48:21 +0100
-Subject: [PATCH] Fix an overflow bug in rsaz_512_sqr
-
-There is an overflow bug in the x64_64 Montgomery squaring procedure used in
-exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
-suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as 
a
-result of this defect would be very difficult to perform and are not believed
-likely. Attacks against DH512 are considered just feasible. However, for an
-attack the target would have to re-use the DH512 private key, which is not
-recommended anyway. Also applications directly using the low level API
-BN_mod_exp may be affected if they use BN_FLG_CONSTTIME.
-
-CVE-2019-1551
-
-Reviewed-by: Paul Dale 
-Reviewed-by: Bernd Edlinger 
-(Merged from https://github.com/openssl/openssl/pull/10575)
-
-CVE: CVE-2019-1551
-Upstream-Status: Backport
-Signed-off-by: Anuj Mittal 

- crypto/bn/asm/rsaz-x86_64.pl | 381 ++-
- 1 file changed, 197 insertions(+), 184 deletions(-)
-
-diff --git a/crypto/bn/asm/rsaz-x86_64.pl b/crypto/bn/asm/rsaz-x86_64.pl
-index b1797b649f0..7534d5cd03e 100755
 a/crypto/bn/asm/rsaz-x86_64.pl
-+++ b/crypto/bn/asm/rsaz-x86_64.pl
-@@ -116,7 +116,7 @@
-   subq\$128+24, %rsp
- .cfi_adjust_cfa_offset128+24
- .Lsqr_body:
--  movq$mod, %rbp  # common argument
-+  movq$mod, %xmm1 # common off-load
-   movq($inp), %rdx
-   movq8($inp), %rax
-   movq$n0, 128(%rsp)
-@@ -134,7 +134,8 @@
- .Loop_sqr:
-   movl$times,128+8(%rsp)
- #first iteration
--  movq%rdx, %rbx
-+  movq%rdx, %rbx  # 0($inp)
-+  mov %rax, %rbp  # 8($inp)
-   mulq%rdx
-   movq%rax, %r8
-   movq16($inp), %rax
-@@ -173,31 +174,29 @@
-   mulq%rbx
-   addq%rax, %r14
-   movq%rbx, %rax
--  movq%rdx, %r15
--  adcq\$0, %r15
-+  adcq\$0, %rdx
- 
--  addq%r8, %r8#shlq   \$1, %r8
--  movq%r9, %rcx
--  adcq%r9, %r9#shld   \$1, %r8, %r9
-+  xorq%rcx,%rcx   # rcx:r8 = r8 << 1
-+  addq%r8, %r8
-+   movq   %rdx, %r15
-+  adcq\$0, %rcx
- 
-   mulq%rax
--  movq%rax, (%rsp)
--  addq%rdx, %r8
--  adcq\$0, %r9
-+  addq%r8, %rdx
-+  adcq\$0, %rcx
- 
--  movq%r8, 8(%rsp)
--  shrq\$63, %rcx
-+  movq%rax, (%rsp)
-+  movq%rdx, 8(%rsp)
- 
- #second iteration
--  movq8($inp), %r8
-   movq16($inp), %rax
--  mulq%r8
-+  mulq%rbp
-   addq%rax, %r10
-   movq24($inp), %rax
-   movq%rdx, %rbx
-   adcq\$0, %rbx
- 
--  mulq%r8
-+  mulq%rbp
-   addq%rax, %r11
-   movq32($inp), %rax
-   adcq\$0, %rdx
-@@ -205,7 +204,7 @@
-   movq%rdx, %rbx
-   adcq\$0, %rbx
- 
--  mulq%r8
-+  mulq%rbp
-   addq%rax, %r12
-   movq40($inp), %rax
-   adcq\$0, %rdx
-@@ -213,7 +212,7 @@
-   movq%rdx, %rbx
-   adcq\$0, %rbx
- 
--  mulq%r8
-+  mulq%rbp
-   addq%rax, %r13
-   movq48($inp), %rax
-   adcq\$0, %rdx
-@@ -221,7 +220,7 @@
-   movq%rdx, %rbx
-   adcq\$0, %rbx
- 
--  mulq%r8
-+  mulq%rbp
-   addq%rax, %r14
-   movq56($inp), %rax
-   adcq\$0, %rdx
-@@ -229,39 +228,39 @@
-   movq%rdx, %rbx
-   adcq\$0, %rbx
- 
--  mulq%r8
-+  mulq%rbp
-   addq%rax, %r15
--  movq%r8, %rax
-+  movq%rbp, %rax
-   adcq\$0, %rdx
-   addq%rbx, %r15
--  movq%rdx, %r8
--  movq%r10, %rdx
--  adcq\$0, %r8
-+  adcq\$0, %rdx
- 
--  add %rdx, %rdx
--  lea (%rcx,%r10,2), %r10 #shld   \$1, %rcx, %r10
--  movq%r11, %rbx
--  adc

[OE-core] Yocto Project Status WW20'20

[Stephen Jolley]

Current Dev Position: YP 3.2 M1

Next Deadline: YP 3.2 M1 build date 2020/6/16

 

Next Team Meetings:

*   Bug Triage meeting Thursday May 21st at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday June 2nd at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday May 19th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See http://www.twitch.tv/letoatreidesthe2nd

 

Key Status/Updates:

*   YP 3.0.3 is in QA and due out on 21st May
*   Gcc 10 merged to master, with the 'no-common' default change
disabled for now whilst we address the other gcc 10 issues first, then we'll
loop back to that.
*   We are struggling with autobuilder infrastructure problems, in
particular with NFS locking but also with cancelled builds not terminating
correctly. These are having a significant negative impact on master and all
stable builds and are a significant concern as there is no clear path
forward to any resolution.
*   Patches continue to merge into master but at a slower rate than
normal. The patch submission rate has dropped slightly which has helped
ensure there isn't a huge backlog.
*   We're moving the AUH job functionality to the autobuilder and
integrating it there which should mean it's easier to reproduce its
functionality and allows more people to see what it's doing and work on/with
it. This should also reduce hosting costs.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M1 build date 2020/6/16
*   YP 3.2 M1 Release date 2020/6/26
*   YP 3.2 M2 build date 2020/7/27
*   YP 3.2 M2 Release date 2020/8/7
*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.0.3 is In QA
*   YP 3.0.3 release date 2020/5/15
*   YP 2.7.4 build date 2020/5/18
*   YP 2.7.4 release date 2020/5/29
*   YP 3.1.1 build date 2020/6/29
*   YP 3.1.1 release date 2020/7/10
*   YP 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/9/14
*   YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2577 (last week 2577) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1352 (last week 1345)
*   Patches in the Pending State: 537 (40%) [last week 536 (40%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138464): 
https://lists.openembedded.org/g/openembedded-core/message/138464
Mute This Topic: https://lists.openembedded.org/mt/74326609/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2

[Rahul Kumar]

Hi Peter,

I am sharing a few information related to bzip2-test source and licensing
information.
As per your suggestion and as per my understanding I added License to the
bzip2 recipe file.

bzip2-tests.git source tree structure is given below
(here showing licence related fle, removed other file names )

bzip2-tests.git/
├── commons-compress
│   ├── LICENSE.txt
│
├── dotnetzip
│   ├── License.txt
│   ├── License.zlib.txt
|
├── go
│   ├── LICENSE
│
├── lbzip2
├── pyflate
├── README
└── run-tests.sh

source code link:
https://sourceware.org/git/bzip2-tests.git

bzip2-tests.git source contains
1) comman-commpress: which is Originally distributed under the Apache
License Version 2.0.
See LICENSE.txt

2) dotnetzip:
(i)  The DotNetZip Library is distributed under the MicroSoft Public License
(Ms-PL) see the License.txt file.
(ii) The BZ2 related resources are distributed under the licenses in
License.zlib.txt.

3) go:
 Go is distributed under a BSD-style license.
 See the LICENSE file.

4) lbzip2:
lbzip2 is free software: you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version

5) pyflate: You may use and distribute this code and documentation under any
DFSG-compatible license (eg. BSD, GNU GPLv2).

6) run-tests.sh: you can redistribute it and/or modify it under the terms
of the GNU General Public License (GPL); either
 version 3, or (at your option) any later version.


SO in recipe I added the License like below
LICENSE = "bzip2-1.0.6 & GPLv3+ & Apache-2.0 & MS-PL & BSD "
LICENSE_${PN}-ptest = "GPLv3+ & Apache-2.0 & MS-PL & BSD"
LIC_FILES_CHKSUM =
"file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664
\

file://${WORKDIR}/git/commons-compress/LICENSE.txt;md5=86d3f3a95c324c9479bd8986968f4327
\ # For comman-commpress (Apache-2.0)

file://${WORKDIR}/git/dotnetzip/License.txt;md5=9cb56871eed4e748c3bc7e8ff352a54f
\  # For dotnetzip (Ms-PL)

file://${WORKDIR}/git/dotnetzip/License.zlib.txt;md5=cc421ccd22eeb2e5db6b79e6de0a029f
\   # For dotnetzip  (jzlib +zlib)

file://${WORKDIR}/git/go/LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707 \
 # For go (BSD-style license)

here I need few suggestion:

1) I added the BSD and GPLv3+ license in LICENSE and LICENSE_${PN}-ptest.
   but not added LIC_FILES_CHKSUM for GPLv3 and BSD because bzip2-tests.git
source code doesn't have GPLv3 and BSD License text file like other
   directories.

2) License.zlib.txt: This is a combination of two licence jzlib and zlib.
In meta/files/common-licenses Zlib license is available but not jzlib.
   In this case how can I proceed?

Kindly comment on this and feel free to point out if i am wrong at any
place.

*Thanks & Regards,*
Rahul Kumar
Software Engineer,Linux Solutions Engineering
Group,Montavista Software LLC
Email Id: rah...@mvista.com



On Mon, May 18, 2020 at 1:18 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> As I wrote in my previous mail, when it comes to licenses, it is the
> distribution that is important. So if you build a package (bzip2-ptest)
> that includes code that is GPL-3.0, it does not matter if that code is only
> used as a binary blob, it is still distributed in the package, and thus the
> package needs to be covered by the GPL-3.0 license.
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core@lists.openembedded.org <
> openembedded-core@lists.openembedded.org> *On Behalf Of *Rahul Kumar
> *Sent:* den 17 maj 2020 21:18
> *To:* Randy MacLeod 
> *Cc:* Alexander Kanavin ; Richard Purdie <
> richard.pur...@linuxfoundation.org>; OE-core <
> openembedded-core@lists.openembedded.org>; Trevor Gamblin <
> trevor.gamb...@windriver.com>
> *Subject:* Re: [OE-core] [PATCH v2] bzip2: Add test suite for bzip2
>
>
>
> Hi Randy,
>
> patch has been accepted by bzip2 community with additional changes.
>
> https://sourceware.org/git/?p=bzip2-tests.git;a=commit;h=f9061c030a25de5b6829e1abf373057309c734c0
>
>
> So I need your suggestion with respect to Yocto.
>
> Since required changes for ptest infrastructure is integrated to the
> bzip2-tests.git source code.
> So now we can just change the SRCREV with the latest commit instead of
> applying the patch to the bzip2-tests.git source code.
>
> And since we are just integrating the bzip2-tests source to the bzip2
> recipe and not modifying any file so i think no need to add any License for
> it.
>
>
> Now patch will look like
> =
> --- a/meta/recipes-extended/bzip2/bzip2/Makefile.am
> +++ b/meta/recipes-extended/bzip2/bzip2/Makefile.am
> @@ -46,6 +46,7 @@ runtest:
> else echo "FAIL: sample2 decompress"; fi
> @if cmp sample3.tst sample3.ref; then echo "PASS: sample3
> decompress";\
> else echo "FAIL: sample3 decompress"; fi
> +   ./bzip2-tests/r

Re: [OE-core] [PATCH] classes/image_types_wic.bbclass: fix racing risk on rootfs

[hongxu]

On 5/19/20 6:19 PM, Richard Purdie wrote:

On Tue, 2020-05-19 at 00:00 +0800, hongxu wrote:

Since wic image creation will temporarily update rootfs/etc/fstab
to add UUID (*temporarily* means rootfs/etc/fstab will be recovered
after wic image creation), there is a potential racing risk with other
image creation (such as tar, ext)

Such as UUID was unexpected in tar.bz2's fstab:
$ cat unpack_tar_bz2_dir/etc/fstab
...
UUID=219B-2933 /boot vfat defaults 0 0
...

Explicitly make do_image_wic depend on other do_image_XXX (listed in
IMAGE_FSTYPES except do_image_wicXXX) to avoid potential racing

Signed-off-by: Hongxu Jia 
---
  meta/classes/image_types_wic.bbclass | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index 96ed0473ee..79bafeb818 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -25,6 +25,7 @@ def wks_search(files, search_path):
  
  WIC_CREATE_EXTRA_ARGS ?= ""
  
+IMAGE_TYPEDEP_wic += "${@' '.join('%s' % r for r in d.getVar('IMAGE_FSTYPES').split() if not r.startswith('wic'))}"

  IMAGE_CMD_wic () {
out="${IMGDEPLOYDIR}/${IMAGE_NAME}"
build_wic="${WORKDIR}/build-wic"

I thought wic took a copy of the rootfs which it could them modify for
this reason but I can't find the code which would do that.


The is my v1 fix for this issue long ago

--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -26,14 +26,21 @@ def wks_search(files, search_path):
 WIC_CREATE_EXTRA_ARGS ?= ""

 IMAGE_CMD_wic () {
+   [ -d "${IMAGE_ROOTFS}_wic" ] && rm -rf "${IMAGE_ROOTFS}_wic"
+   # Refer oe.path.copytree(src, dst): ${WORKDIR}/rootfs -> 
${WORKDIR}/rootfs_wic

+   mkdir -p "${IMAGE_ROOTFS}_wic"
+   tar --xattrs --xattrs-include="*" -cf - -S -C "${IMAGE_ROOTFS}" 
-p . | tar --xattrs --xattrs-include="*" -xf - -C "${IMAGE_ROOTFS}_wic"

+
    out="${IMGDEPLOYDIR}/${IMAGE_NAME}"
    build_wic="${WORKDIR}/build-wic"
    wks="${WKS_FULL_PATH}"
    if [ -z "$wks" ]; then
    bbfatal "No kickstart files from WKS_FILES were found: 
${WKS_FILES}. Please set WKS_FILE or WKS_FILES appropriately."

    fi
-   BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create "$wks" --vars 
"${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o 
"$build_wic/" ${WIC_CREATE_EXTRA_ARGS}

+
+   BUILDDIR="${TOPDIR}" PSEUDO_UNLOAD=1 wic create "$wks" --vars 
"${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -r 
"${IMAGE_ROOTFS}_wic" -o "$build_wic/" ${WIC_CREATE_EXTRA_ARGS}
    mv "$build_wic/$(basename "${wks%.wks}")"*.direct 
"$out${IMAGE_NAME_SUFFIX}.wic"

+   rm -rf "${IMAGE_ROOTFS}_wic"
 }



I think we should teach wic to take a copy (using hardlinks) as editing
files in the rootfs in do_image_* is not allowed. By using hardlinks
and putting it on the same filesystem as the original (rootfsdir +
".wic" maybe?) then it should be fast.


But it does not quick, just a copy, no hardlink

I guess we could split the copy operation into two parts,

for the editing file, we copy it, for the others, using hardlink

//Hong

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138462): 
https://lists.openembedded.org/g/openembedded-core/message/138462
Mute This Topic: https://lists.openembedded.org/mt/74294520/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes/image_types_wic.bbclass: fix racing risk on rootfs

[Richard Purdie]

On Tue, 2020-05-19 at 00:00 +0800, hongxu wrote:
> Since wic image creation will temporarily update rootfs/etc/fstab
> to add UUID (*temporarily* means rootfs/etc/fstab will be recovered
> after wic image creation), there is a potential racing risk with other
> image creation (such as tar, ext)
> 
> Such as UUID was unexpected in tar.bz2's fstab:
> $ cat unpack_tar_bz2_dir/etc/fstab
> ...
> UUID=219B-2933 /boot vfat defaults 0 0
> ...
> 
> Explicitly make do_image_wic depend on other do_image_XXX (listed in
> IMAGE_FSTYPES except do_image_wicXXX) to avoid potential racing
> 
> Signed-off-by: Hongxu Jia 
> ---
>  meta/classes/image_types_wic.bbclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/classes/image_types_wic.bbclass 
> b/meta/classes/image_types_wic.bbclass
> index 96ed0473ee..79bafeb818 100644
> --- a/meta/classes/image_types_wic.bbclass
> +++ b/meta/classes/image_types_wic.bbclass
> @@ -25,6 +25,7 @@ def wks_search(files, search_path):
>  
>  WIC_CREATE_EXTRA_ARGS ?= ""
>  
> +IMAGE_TYPEDEP_wic += "${@' '.join('%s' % r for r in 
> d.getVar('IMAGE_FSTYPES').split() if not r.startswith('wic'))}"
>  IMAGE_CMD_wic () {
>   out="${IMGDEPLOYDIR}/${IMAGE_NAME}"
>   build_wic="${WORKDIR}/build-wic"

I thought wic took a copy of the rootfs which it could them modify for
this reason but I can't find the code which would do that.

I think we should teach wic to take a copy (using hardlinks) as editing
files in the rootfs in do_image_* is not allowed. By using hardlinks
and putting it on the same filesystem as the original (rootfsdir +
".wic" maybe?) then it should be fast.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138461): 
https://lists.openembedded.org/g/openembedded-core/message/138461
Mute This Topic: https://lists.openembedded.org/mt/74294520/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] python3: add pydoc and urllib to core

[Richard Purdie]

On Tue, 2020-05-19 at 00:51 -0700, Alejandro Hernandez wrote:
> 
> I still believe python3-core should be left as small as possible, the
> use case
> of an embedded device calling help() is probably seldom, IMO that
> fits more in
> the workflow of installing the netlib and pydoc modules for that
> specific usecase.
> It also looks like simply installing python3-pydoc would do what you
> want, since
> the error to load urllib is coming out of loading pydoc itself and
> the manifest
> does specify the dependency from pydoc to netclient.

I have to agree with Alejandro here, whilst help() not working is not
ideal, we are targetting "embedded" systems where something like this
is not unreasonable for the size gain.

Does anyone have any size information about the implications of this?
I'd guess there could be quite a chain of modules that could end up
installed with this change.

If you don't like the import error, we could just patch it to say
"Sorry, pydoc not installed".

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138460): 
https://lists.openembedded.org/g/openembedded-core/message/138460
Mute This Topic: https://lists.openembedded.org/mt/74286776/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] lttng-tools: upgrade to 2.12.0

[Ovidiu Panait]

Upgrade lttng-tools 2.11.2 -> 2.12.0:
* drop x32 patch, as it was merged upstream
* update ptest file mi-lttng-3.0.xsd -> mi-lttng-4.0.xsd
* add local patch to fix ptest build failure on musl
* License-Update: licenses were moved under LICENSES directory and changed in
  upstream commit [1]

[1] 
https://github.com/lttng/lttng-tools/commit/ab5be9fa2eb5ba9600a82cd18fd3cfcbac69169a

Signed-off-by: Ovidiu Panait 
---
 ...ents-ns-tp.h-Fix-build-with-musl-lib.patch | 43 +++
 .../lttng/lttng-tools/x32.patch   | 36 
 ...-tools_2.11.2.bb => lttng-tools_2.12.0.bb} | 14 +++---
 3 files changed, 50 insertions(+), 43 deletions(-)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-tests-gen-ust-events-ns-tp.h-Fix-build-with-musl-lib.patch
 delete mode 100644 meta/recipes-kernel/lttng/lttng-tools/x32.patch
 rename meta/recipes-kernel/lttng/{lttng-tools_2.11.2.bb => 
lttng-tools_2.12.0.bb} (92%)

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-tests-gen-ust-events-ns-tp.h-Fix-build-with-musl-lib.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-gen-ust-events-ns-tp.h-Fix-build-with-musl-lib.patch
new file mode 100644
index 00..a150d648ab
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-gen-ust-events-ns-tp.h-Fix-build-with-musl-lib.patch
@@ -0,0 +1,43 @@
+From e5d94cf4882cc6516af52b794c6acb8e4d6469a3 Mon Sep 17 00:00:00 2001
+From: Ovidiu Panait 
+Date: Mon, 18 May 2020 16:39:26 +0300
+Subject: [PATCH] tests: gen-ust-events-ns/tp.h: Fix build with musl libc
+
+Fix the following build error with musl libc:
+In file included from 
../../../../../lttng-tools-2.12.0/tests/utils/testapp/gen-ust-events-ns/tp.h:14,
+ from 
../../../../../lttng-tools-2.12.0/tests/utils/testapp/gen-ust-events-ns/tp.c:10:
+../../../../../lttng-tools-2.12.0/tests/utils/testapp/gen-ust-events-ns/tp.h:17:10:
 error: unknown type name 'ino_t'; did you mean 'int8_t'?
+   17 |  TP_ARGS(ino_t, ns_ino),
+  |  ^
+../../../../../lttng-tools-2.12.0/tests/utils/testapp/gen-ust-events-ns/tp.h:17:10:
 error: unknown type name 'ino_t'; did you mean 'int8_t'?
+   17 |  TP_ARGS(ino_t, ns_ino),
+  |  ^
+../../../../../lttng-tools-2.12.0/tests/utils/testapp/gen-ust-events-ns/./tp.h:17:2:
 error: unknown type name 'ino_t'; did you mean 'int8_t'?
+   17 |  TP_ARGS(ino_t, ns_ino),
+  |  ^~~
+../../../../../lttng-tools-2.12.0/tests/utils/testapp/gen-ust-events-ns/./tp.h:17:2:
 error: unknown type name 'ino_t'; did you mean 'int8_t'?
+   17 |  TP_ARGS(ino_t, ns_ino),
+  |  ^~~
+
+Upstream-Status: Submitted [https://github.com/lttng/lttng-tools/pull/161]
+
+Signed-off-by: Ovidiu Panait 
+---
+ tests/utils/testapp/gen-ust-events-ns/tp.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/tests/utils/testapp/gen-ust-events-ns/tp.h 
b/tests/utils/testapp/gen-ust-events-ns/tp.h
+index 4dbfed5..e0ddb29 100644
+--- a/tests/utils/testapp/gen-ust-events-ns/tp.h
 b/tests/utils/testapp/gen-ust-events-ns/tp.h
+@@ -11,6 +11,7 @@
+ #if !defined(_TRACEPOINT_TP_H) || defined(TRACEPOINT_HEADER_MULTI_READ)
+ #define _TRACEPOINT_TP_H
+ 
++#include 
+ #include 
+ 
+ TRACEPOINT_EVENT(tp, tptest,
+-- 
+2.17.1
+
diff --git a/meta/recipes-kernel/lttng/lttng-tools/x32.patch 
b/meta/recipes-kernel/lttng/lttng-tools/x32.patch
deleted file mode 100644
index 42cebf94ac..00
--- a/meta/recipes-kernel/lttng/lttng-tools/x32.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-Fix build for x32
-
-Signed-off-by: Christopher Larson 
-
-Fix build error of src/common/utils.c for x32.
-
-Upstream-Status: Submitted [https://github.com/lttng/lttng-tools/pull/150]
-
-Signed-off-by: Kai Kang 
-
-diff --git a/src/bin/lttng/utils.c b/src/bin/lttng/utils.c
-index 0e96ef0c..5c79c8c7 100644
 a/src/bin/lttng/utils.c
-+++ b/src/bin/lttng/utils.c
-@@ -158,7 +158,7 @@ unsigned int fls_u32(uint32_t x)
- #define HAS_FLS_U32
- #endif
- 
--#if defined(__x86_64)
-+#if defined(__x86_64) && !defined(__ILP32__)
- static inline
- unsigned int fls_u64(uint64_t x)
- {
-diff --git a/src/common/utils.c b/src/common/utils.c
-index 08139e5e..3c389981 100644
 a/src/common/utils.c
-+++ b/src/common/utils.c
-@@ -1223,7 +1223,7 @@ static inline unsigned int fls_u32(uint32_t x)
- #define HAS_FLS_U32
- #endif
- 
--#if defined(__x86_64)
-+#if defined(__x86_64) && !defined(__ILP32__)
- static inline
- unsigned int fls_u64(uint64_t x)
- {
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.12.0.bb
similarity index 92%
rename from meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.12.0.bb
index 36a19ec18d..148a7928d2 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.11.2.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.12.0.bb
@@ -5,9 +5,9 @@ to extract program execution details from the Linux operating 
system \
 and interpret them."
 
 LICENSE = "GPLv2 & LGPLv2.1"
-LIC_F

Re: [OE-core] [PATCH] python3: add pydoc and urllib to core

[Yu, Mingli]

Hi Alejandro,

On 5/19/20 3:51 PM, Alejandro Hernandez Samaniego wrote:

Hey Mingly Yu,

On 5/19/20 12:43 AM, Yu, Mingli wrote:

Hi Alejandro,


On 2020/5/19 下午3:22, Alejandro Hernandez Samaniego wrote:

Hello,

The more I look into this, the more I realize its incorrect.


Understood your concern.




On 5/18/20 8:36 AM, Alejandro Hernandez wrote:


Hello Mingli,

Did you happen to run the create_manifest task after modifying the 
manifest to make sure that runtime dependencies are still valid?



Thanks

Alejandro

On 5/18/20 12:32 AM, Yu, Mingli wrote:

From: Mingli Yu

Add pydoc and urllib to core to fix below error:
  # python3
  >>> help()
  Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
  import pydoc
  ModuleNotFoundError: No module named 'pydoc'
  File "/usr/lib64/python3.8/pydoc.py", line 72, in 
  import urllib.parse
  ModuleNotFoundError: No module named 'urllib'


Why would pydoc be required to run python? or urllib in any case?



It's better make the python3-core more lightweight.

But in a system which didn't install other python modules but just 
python3-core, then we type help() as below and the help cannot show 
normally. So add the needed pydoc and urllib file to make the help() 
works.


 # python3
 >>> help()
 Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
 import pydoc
 ModuleNotFoundError: No module named 'pydoc'
 File "/usr/lib64/python3.8/pydoc.py", line 72, in 
 import urllib.parse
 ModuleNotFoundError: No module named 'urllib'


After pydoc and urllib added and also just install python3-core and no 
additional python3 modules installed.


# python3
Python 3.8.2 (default, May 18 2020, 07:15:10)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> help()
Welcome to Python 3.8's help utility!

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at https://docs.python.org/3.8/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, symbols, or topics, type
"modules", "keywords", "symbols", or "topics".  Each module also comes
with a one-line summary of what it does; to list the modules whose name
or summary contain a given string such as "spam", type "modules spam".
help>


Thanks,


I still believe python3-core should be left as small as possible, the use case
of an embedded device calling help() is probably seldom, IMO that fits more in
the workflow of installing the netlib and pydoc modules for that specific 
usecase.

It also looks like simply installing python3-pydoc would do what you want, since


Install python3-pydoc indeed solves the problem, but does it mean 
python3-core depends on python3-pydoc?


Though the use case to type help() is seldom, but help() is much useful 
and I just add as less as possible files to let help() works.(add urllib 
files in as pydoc depends on it).


Thanks,


the error to load urllib is coming out of loading pydoc itself and the manifest
does specify the dependency from pydoc to netclient.

Cheers,

Alejandro




I believe there is a discrepancy between what python3-core does and 
what you believe it should do.
python3-core is the smallest possible package to get a working 
python3 interpreter, if you install python3-core
thats what you get, if you need more modules then you install more 
modules, e.g. python3-pydoc, python3-netlib,

this way it allows us to keep installation size at minimum.

If what you want is to get a fully working python3 interpreter, 
without adding any new packages to the installation,
then you need to install the python3 package (no core), this will in 
fact install python3-modules which contains
all the modules, including python3-pydoc and python3-neclient which 
is the one that provides urllib.


Cheers,

Alejandro


Signed-off-by: Mingli Yu
---
  .../python/python3/python3-manifest.json  | 24 
+--

  meta/recipes-devtools/python/python3_3.8.2.bb |  3 +--
  2 files changed, 7 insertions(+), 20 deletions(-)

diff --git 
a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json

index 3bcc9b8662..808eadb8f6 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -203,6 +203,7 @@
  "${bindir}/python${PYTHON_MAJMIN}",
  "${bindir}/python${PYTHON_MAJMIN}.real",
  "${bindir}/python3",
+    "${bindir}/pydoc*",
"${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
"${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
"${libdir}/python${PYTHON_MAJMIN}/UserList.py",
@@ -289,6 +290,7 @@
   

Re: [OE-core] [PATCH] python3: add pydoc and urllib to core

[Alejandro Hernandez]

Hey Mingly Yu,

On 5/19/20 12:43 AM, Yu, Mingli wrote:

Hi Alejandro,


On 2020/5/19 下午3:22, Alejandro Hernandez Samaniego wrote:

Hello,

The more I look into this, the more I realize its incorrect.


Understood your concern.




On 5/18/20 8:36 AM, Alejandro Hernandez wrote:


Hello Mingli,

Did you happen to run the create_manifest task after modifying the 
manifest to make sure that runtime dependencies are still valid?



Thanks

Alejandro

On 5/18/20 12:32 AM, Yu, Mingli wrote:

From: Mingli Yu

Add pydoc and urllib to core to fix below error:
  # python3
  >>> help()
  Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
  import pydoc
  ModuleNotFoundError: No module named 'pydoc'
  File "/usr/lib64/python3.8/pydoc.py", line 72, in 
  import urllib.parse
  ModuleNotFoundError: No module named 'urllib'


Why would pydoc be required to run python? or urllib in any case?



It's better make the python3-core more lightweight.

But in a system which didn't install other python modules but just 
python3-core, then we type help() as below and the help cannot show 
normally. So add the needed pydoc and urllib file to make the help() 
works.


 # python3
 >>> help()
 Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
 import pydoc
 ModuleNotFoundError: No module named 'pydoc'
 File "/usr/lib64/python3.8/pydoc.py", line 72, in 
 import urllib.parse
 ModuleNotFoundError: No module named 'urllib'


After pydoc and urllib added and also just install python3-core and no 
additional python3 modules installed.


# python3
Python 3.8.2 (default, May 18 2020, 07:15:10)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> help()
Welcome to Python 3.8's help utility!

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at https://docs.python.org/3.8/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, symbols, or topics, type
"modules", "keywords", "symbols", or "topics".  Each module also comes
with a one-line summary of what it does; to list the modules whose name
or summary contain a given string such as "spam", type "modules spam".
help>


Thanks,


I still believe python3-core should be left as small as possible, the use case
of an embedded device calling help() is probably seldom, IMO that fits more in
the workflow of installing the netlib and pydoc modules for that specific 
usecase.

It also looks like simply installing python3-pydoc would do what you want, since
the error to load urllib is coming out of loading pydoc itself and the manifest
does specify the dependency from pydoc to netclient.

Cheers,

Alejandro




I believe there is a discrepancy between what python3-core does and 
what you believe it should do.
python3-core is the smallest possible package to get a working 
python3 interpreter, if you install python3-core
thats what you get, if you need more modules then you install more 
modules, e.g. python3-pydoc, python3-netlib,

this way it allows us to keep installation size at minimum.

If what you want is to get a fully working python3 interpreter, 
without adding any new packages to the installation,
then you need to install the python3 package (no core), this will in 
fact install python3-modules which contains
all the modules, including python3-pydoc and python3-neclient which 
is the one that provides urllib.


Cheers,

Alejandro


Signed-off-by: Mingli Yu
---
  .../python/python3/python3-manifest.json  | 24 
+--

  meta/recipes-devtools/python/python3_3.8.2.bb |  3 +--
  2 files changed, 7 insertions(+), 20 deletions(-)

diff --git 
a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json

index 3bcc9b8662..808eadb8f6 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -203,6 +203,7 @@
  "${bindir}/python${PYTHON_MAJMIN}",
  "${bindir}/python${PYTHON_MAJMIN}.real",
  "${bindir}/python3",
+    "${bindir}/pydoc*",
"${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
"${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
"${libdir}/python${PYTHON_MAJMIN}/UserList.py",
@@ -289,6 +290,7 @@
  "${libdir}/python${PYTHON_MAJMIN}/pkgutil.py",
"${libdir}/python${PYTHON_MAJMIN}/platform.py",
"${libdir}/python${PYTHON_MAJMIN}/posixpath.py",
+    "${libdir}/python${PYTHON_MAJMIN}/pydoc.py",
  "${libdir}/python${PYTHON_MAJMIN}/re.py",
  "${libdir}/python${PYTHON_MAJMIN}/reprlib.py",
"${libdir}/python${PYTHON_MAJMIN}/rlcompleter.py",

Re: [OE-core] [PATCH] python3: add pydoc and urllib to core

[Yu, Mingli]

Hi Alejandro,


On 2020/5/19 下午3:22, Alejandro Hernandez Samaniego wrote:

Hello,

The more I look into this, the more I realize its incorrect.


Understood your concern.




On 5/18/20 8:36 AM, Alejandro Hernandez wrote:


Hello Mingli,

Did you happen to run the create_manifest task after modifying the 
manifest to make sure that runtime dependencies are still valid?



Thanks

Alejandro

On 5/18/20 12:32 AM, Yu, Mingli wrote:

From: Mingli Yu

Add pydoc and urllib to core to fix below error:
  # python3
  >>> help()
  Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
  import pydoc
  ModuleNotFoundError: No module named 'pydoc'
  File "/usr/lib64/python3.8/pydoc.py", line 72, in 
  import urllib.parse
  ModuleNotFoundError: No module named 'urllib'


Why would pydoc be required to run python? or urllib in any case?



It's better make the python3-core more lightweight.

But in a system which didn't install other python modules but just 
python3-core, then we type help() as below and the help cannot show 
normally. So add the needed pydoc and urllib file to make the help() works.


 # python3
 >>> help()
 Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
 import pydoc
 ModuleNotFoundError: No module named 'pydoc'
 File "/usr/lib64/python3.8/pydoc.py", line 72, in 
 import urllib.parse
 ModuleNotFoundError: No module named 'urllib'


After pydoc and urllib added and also just install python3-core and no 
additional python3 modules installed.


# python3
Python 3.8.2 (default, May 18 2020, 07:15:10)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> help()
Welcome to Python 3.8's help utility!

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at https://docs.python.org/3.8/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, symbols, or topics, type
"modules", "keywords", "symbols", or "topics".  Each module also comes
with a one-line summary of what it does; to list the modules whose name
or summary contain a given string such as "spam", type "modules spam".
help>


Thanks,



I believe there is a discrepancy between what python3-core does and what you 
believe it should do.
python3-core is the smallest possible package to get a working python3 
interpreter, if you install python3-core
thats what you get, if you need more modules then you install more modules, 
e.g. python3-pydoc, python3-netlib,
this way it allows us to keep installation size at minimum.

If what you want is to get a fully working python3 interpreter, without adding 
any new packages to the installation,
then you need to install the python3 package (no core), this will in fact 
install python3-modules which contains
all the modules, including python3-pydoc and python3-neclient which is the one 
that provides urllib.

Cheers,

Alejandro


Signed-off-by: Mingli Yu
---
  .../python/python3/python3-manifest.json  | 24 +--
  meta/recipes-devtools/python/python3_3.8.2.bb |  3 +--
  2 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 3bcc9b8662..808eadb8f6 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -203,6 +203,7 @@
  "${bindir}/python${PYTHON_MAJMIN}",
  "${bindir}/python${PYTHON_MAJMIN}.real",
  "${bindir}/python3",
+"${bindir}/pydoc*",
  "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
  "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
  "${libdir}/python${PYTHON_MAJMIN}/UserList.py",
@@ -289,6 +290,7 @@
  "${libdir}/python${PYTHON_MAJMIN}/pkgutil.py",
  "${libdir}/python${PYTHON_MAJMIN}/platform.py",
  "${libdir}/python${PYTHON_MAJMIN}/posixpath.py",
+"${libdir}/python${PYTHON_MAJMIN}/pydoc.py",
  "${libdir}/python${PYTHON_MAJMIN}/re.py",
  "${libdir}/python${PYTHON_MAJMIN}/reprlib.py",
  "${libdir}/python${PYTHON_MAJMIN}/rlcompleter.py",
@@ -313,8 +315,11 @@
  "${libdir}/python${PYTHON_MAJMIN}/tokenize.py",
  "${libdir}/python${PYTHON_MAJMIN}/traceback.py",
  "${libdir}/python${PYTHON_MAJMIN}/types.py",
+"${libdir}/python${PYTHON_MAJMIN}/urllib",
+"${libdir}/python${PYTHON_MAJMIN}/urllib/__pycache__",
  "${libdir}/python${PYTHON_MAJMIN}/warnings.py",
  "${libdir}/python${PYTHON_MAJMIN}/weakref.py",
+ 

Re: [OE-core] [PATCH] python3: add pydoc and urllib to core

[Alejandro Hernandez]

Hello,

The more I look into this, the more I realize its incorrect.


On 5/18/20 8:36 AM, Alejandro Hernandez wrote:


Hello Mingli,

Did you happen to run the create_manifest task after modifying the 
manifest to make sure that runtime dependencies are still valid?



Thanks

Alejandro

On 5/18/20 12:32 AM, Yu, Mingli wrote:

From: Mingli Yu

Add pydoc and urllib to core to fix below error:
  # python3
  >>> help()
  Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.8/sitebuiltins.py", line 102, in __call_
  import pydoc
  ModuleNotFoundError: No module named 'pydoc'
  File "/usr/lib64/python3.8/pydoc.py", line 72, in 
  import urllib.parse
  ModuleNotFoundError: No module named 'urllib'


Why would pydoc be required to run python? or urllib in any case?

I believe there is a discrepancy between what python3-core does and what you 
believe it should do.
python3-core is the smallest possible package to get a working python3 
interpreter, if you install python3-core
thats what you get, if you need more modules then you install more modules, 
e.g. python3-pydoc, python3-netlib,
this way it allows us to keep installation size at minimum.

If what you want is to get a fully working python3 interpreter, without adding 
any new packages to the installation,
then you need to install the python3 package (no core), this will in fact 
install python3-modules which contains
all the modules, including python3-pydoc and python3-neclient which is the one 
that provides urllib.

Cheers,

Alejandro



Signed-off-by: Mingli Yu
---
  .../python/python3/python3-manifest.json  | 24 +--
  meta/recipes-devtools/python/python3_3.8.2.bb |  3 +--
  2 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 3bcc9b8662..808eadb8f6 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -203,6 +203,7 @@
  "${bindir}/python${PYTHON_MAJMIN}",
  "${bindir}/python${PYTHON_MAJMIN}.real",
  "${bindir}/python3",
+"${bindir}/pydoc*",
  "${includedir}/python${PYTHON_MAJMIN}/pyconfig*.h",
  "${libdir}/python${PYTHON_MAJMIN}/UserDict.py",
  "${libdir}/python${PYTHON_MAJMIN}/UserList.py",
@@ -289,6 +290,7 @@
  "${libdir}/python${PYTHON_MAJMIN}/pkgutil.py",
  "${libdir}/python${PYTHON_MAJMIN}/platform.py",
  "${libdir}/python${PYTHON_MAJMIN}/posixpath.py",
+"${libdir}/python${PYTHON_MAJMIN}/pydoc.py",
  "${libdir}/python${PYTHON_MAJMIN}/re.py",
  "${libdir}/python${PYTHON_MAJMIN}/reprlib.py",
  "${libdir}/python${PYTHON_MAJMIN}/rlcompleter.py",
@@ -313,8 +315,11 @@
  "${libdir}/python${PYTHON_MAJMIN}/tokenize.py",
  "${libdir}/python${PYTHON_MAJMIN}/traceback.py",
  "${libdir}/python${PYTHON_MAJMIN}/types.py",
+"${libdir}/python${PYTHON_MAJMIN}/urllib",
+"${libdir}/python${PYTHON_MAJMIN}/urllib/__pycache__",
  "${libdir}/python${PYTHON_MAJMIN}/warnings.py",
  "${libdir}/python${PYTHON_MAJMIN}/weakref.py",
+"${libdir}/python${PYTHON_MAJMIN}/pydoc_data",
  "${prefix}/lib/python${PYTHON_MAJMIN}/config*/*[!.a]"
  ],
  "cached": [
@@ -363,6 +368,7 @@
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/pkgutil.*.pyc",
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/platform.*.pyc",
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/posixpath.*.pyc",
+"${libdir}/python${PYTHON_MAJMIN}/__pycache__/pydoc.*.pyc",
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/re.*.pyc",
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/reprlib.*.pyc",
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/rlcompleter.*.pyc",
@@ -798,7 +804,6 @@
  "plistlib",
  "pprint",
  "profile",
-"pydoc",
  "resource",
  "shell",
  "smtpd",
@@ -857,8 +862,6 @@
  "${libdir}/python${PYTHON_MAJMIN}/poplib.py",
  "${libdir}/python${PYTHON_MAJMIN}/smtplib.py",
  "${libdir}/python${PYTHON_MAJMIN}/telnetlib.py",
-"${libdir}/python${PYTHON_MAJMIN}/urllib",
-"${libdir}/python${PYTHON_MAJMIN}/urllib/__pycache__",
  "${libdir}/python${PYTHON_MAJMIN}/uuid.py"
  ],
  "cached": [
@@ -989,21 +992,6 @@
  "${libdir}/python${PYTHON_MAJMIN}/__pycache__/pstats.*.pyc"
  ]
  },
-"pydoc": {
-"summary": "Python interactive help support",
-"rdepends": [
-"core",
-"netclient"
-],
-"files": [
-"${bindir}/pydoc*",
-"

Re: [OE-core] [PATCH] populate_sdk_base: do not overwrite ld.so.conf in nativesdk

[Ovidiu Panait]

On 19.05.2020 07:36, Denys Dmytriyenko wrote:


From: Denys Dmytriyenko 

Commit 7ec84a463ad4c45aee9cd2cbc75b43e5aab5cd18 has moved creation of ld.so.conf
from buildtools-tarball.bb to create_sdk_files() in populate_sdk_base.bbclass.
But since create_sdk_files() is an SDK_POSTPROCESS_COMMAND, creating ld.so.conf
can potentially overwrite existing file already provided by a nativesdk package.
Use append instead to avoid overwriting existing file.

Signed-off-by: Denys Dmytriyenko 
---
  meta/classes/populate_sdk_base.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 990505e..83c3448 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -189,7 +189,7 @@ fakeroot create_sdk_files() {
 mkdir -p ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/
 echo '${SDKPATHNATIVE}${libdir_nativesdk}
  ${SDKPATHNATIVE}${base_libdir_nativesdk}
-include /etc/ld.so.conf' > 
${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/ld.so.conf
+include /etc/ld.so.conf' >> 
${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/ld.so.conf
  }


Hi Denys,


With this change, in my testing (Ubuntu 18.04 server), nativesdk-gcc 
would still try to link with host libraries first rather than nativesdk 
ones, basically reverting the original intent of commit 
7ec84a463ad4c45aee9cd2cbc75b43e5aab5cd18:


local.conf:

KERNEL_DEV_HOST_PKGS = "\
    nativesdk-openssl-dev \
    nativesdk-libelf \
    nativesdk-elfutils-dev \
    nativesdk-ncurses-terminfo-base \
    nativesdk-chrpath \
    nativesdk-tar \
    nativesdk-git \
    nativesdk-pigz \
    nativesdk-make \
    nativesdk-wget \
    nativesdk-ca-certificates \
    nativesdk-texinfo \
    nativesdk-libnss-nis \
    nativesdk-rpcsvc-proto \
    nativesdk-patch \
    nativesdk-automake \
    nativesdk-autoconf \
    nativesdk-binutils \
    nativesdk-binutils-symlinks \
    nativesdk-cpp \
    nativesdk-cpp-symlinks \
    nativesdk-gcc \
    nativesdk-gcc-symlinks \
    nativesdk-g++ \
    nativesdk-g++-symlinks \
    nativesdk-gettext \
    nativesdk-libatomic \
    nativesdk-libgcc \
    nativesdk-libstdc++ \
    nativesdk-libstdc++-dev \
    nativesdk-libtool \
    nativesdk-pkgconfig \
    nativesdk-glibc-utils \
    nativesdk-libxcrypt-dev \
"
KERNEL_DEV_HOST_PKGS_pn-uninative-tarball = ""
KERNEL_DEV_HOST_PKGS_pn-buildtools-tarball = ""
TOOLCHAIN_HOST_TASK_append = " ${KERNEL_DEV_HOST_PKGS}"

bitbake -c populate_sdk core-image-minimal



$ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
/buildarea/raid0/ovidiu/Builds/Yocto/yocto-latest/poky/build/tmp/deploy/sdk/sdk/sysroots/x86_64-pokysdk-linux/usr/lib
/buildarea/raid0/ovidiu/Builds/Yocto/yocto-latest/poky/build/tmp/deploy/sdk/sdk/sysroots/x86_64-pokysdk-linux/lib
include /etc/ld.so.conf

$ cat test.c
int main()
{
    return 0;
}
$ gcc -o test test.c -lcrypto
/buildarea/raid0/ovidiu/Builds/Yocto/yocto-latest/poky/build/tmp/deploy/sdk/sdk/sysroots/x86_64-pokysdk-linux/usr/lib/gcc/x86_64-pokysdk-linux/10.1.0/../../../../x86_64-pokysdk-linux/bin/ld: 
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to 
`__libc_vfork@GLIBC_PRIVATE'

collect2: error: ld returned 1 exit status


Before this change:

$ gcc -o test test.c -lcrypto
$ echo $?
0

Also, it seems that the scenario in which the SDK provides its own 
/etc/ld.so.conf and other nativesdk packages append to it did not 
operate correctly even before commit 
7ec84a463ad4c45aee9cd2cbc75b43e5aab5cd18, because host paths would be 
appended instead of SDK paths.



Maybe we should try in create_sdk_files to prepend all existing paths 
from /etc/ld.so.conf with ${SDK_OUTPUT}/${SDKPATHNATIVE} to solve this 
overwrite problem?



Ovidiu

  
  python check_sdk_sysroots() {



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#138454): 
https://lists.openembedded.org/g/openembedded-core/message/138454
Mute This Topic: https://lists.openembedded.org/mt/74319242/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-