Date   

Re: what is the proper treatment of the "Unlicense" license?

Quentin Schulz
 

Hi Robert,

On Wed, May 13, 2020 at 07:19:59AM -0400, Robert P. J. Day wrote:
On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.
I'm not sure, but there might be a need to add it to SRC_DISTRIBUTE_LICENSES
in openembedded-core/meta/conf/licenses.conf.

Quentin


Re: what is the proper treatment of the "Unlicense" license?

Robert P. J. Day
 

On Wed, 13 May 2020, Richard Leitner wrote:

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses
as long as this requires only adding an Unlicense file to that
directory, i can do that shortly.

rday


Re: what is the proper treatment of the "Unlicense" license?

Robert P. J. Day
 

On Wed, 13 May 2020, Quentin Schulz wrote:

... snip ...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need
any of the suggested ways?
that was one of the first things that came to mind ... if there are
enough packages with this license, why not just make it official? i
just did a quick search, and this is the only layer i see that makes
reference to it:

busybox/networking/tls_aes.c

/*
* Copyright (C) 2017 Denys Vlasenko
*
* Licensed under GPLv2, see file LICENSE in this source tree.
*/

/* This AES implementation is derived from tiny-AES128-C code,
* which was put by its author into public domain:
*
* tiny-AES128-C/unlicense.txt, Dec 8, 2014
* """
* This is free and unencumbered software released into the public domain.

more info on that license:

https://choosealicense.com/licenses/unlicense/

open to suggestions.

rday


Re: what is the proper treatment of the "Unlicense" license?

Richard Leitner
 

On Wed, May 13, 2020 at 12:39:44PM +0200, Quentin Schulz wrote:
On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:
...

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?
+1 for adding Unlicense to openembedded-core's common-licenses

regards;rl


Quentin


Re: what is the proper treatment of the "Unlicense" license?

Quentin Schulz
 

Hi Robert,

On Wed, May 13, 2020 at 06:25:01AM -0400, Robert P. J. Day wrote:

colleague added a new recipe to a build, got a warning "The license
listed Unlicense was not in the licenses collected for recipe
python-filelock" and, sure enough, that source was released under the
"Unlicense" which i had never heard of:

https://github.com/benediktschmitt/py-filelock/blob/master/LICENSE

what is the standard strategy for dealing with that? should i just
whitelist that license? has anyone else run into this "Unlicense"
license?
You can add a license to your layer by doing the following in
conf/layer.conf:
LICENSE_PATH += "${LAYERDIR}/licenses"

and in there you put the Unlicense file named exactly the same with the
correct content. That's one way.

The other is to use NO_GENERIC_LICENSE[Unlicense] = "/path/to/Unlicense"
in the recipe.

If it's really widely used, maybe something to add to
openembedded-core/files/common-licenses/ ? So that you don't need any of
the suggested ways?

Quentin


what is the proper treatment of the "Unlicense" license?

Robert P. J. Day
 

colleague added a new recipe to a build, got a warning "The license
listed Unlicense was not in the licenses collected for recipe
python-filelock" and, sure enough, that source was released under the
"Unlicense" which i had never heard of:

https://github.com/benediktschmitt/py-filelock/blob/master/LICENSE

what is the standard strategy for dealing with that? should i just
whitelist that license? has anyone else run into this "Unlicense"
license?

rday


Re: pkg_postinst_ontarget not executed

Damien LEFEVRE
 

OK I found.

Yes "opkg configure" will call /var/lib/opkg/info/*.postinst for packages marked as "unpacked" in /var/lib/opkg/status ex:

Package: test-deployment-lic
Version: 1.0-r0
Status: install ok unpacked
Architecture: aarch64
Installed-Time: 1589349316
Auto-Installed: yes
 
After update 
Package: test-deployment-lic
Version: 1.0-r0
Status: install ok unpacked
Architecture: aarch64
Installed-Time: 1589349316
Auto-Installed: yes
 
Should be easy to merge.

Thanks!
-Damien

On Wed, May 13, 2020 at 12:04 PM Alexander Kanavin <alex.kanavin@...> wrote:
Reading recipes-devtools/run-postinsts/run-postinsts/run-postinsts and_save_postinsts_common (in rootfs.py) once more, it seems /etc/ipk-postinsts is only used if there is no package manager on the target.

If there is, then 'opkg configure' is run directly, and so postinsts come from some internal database. There is some additional magic in rootfs.py to mark packages with first-boot postinsts as unpacked, so they'll get picked up by opkg.

Alex

On Wed, 13 May 2020 at 09:33, Damien LEFEVRE <lefevre.da@...> wrote:
Thanks Alex,

When I do a factory reset, the system detects as a first boot and the script is executed.

> cat /var/log/postinstall.log
Configuring test-deployment.

One thing which puzzles me: the /etc/ipk-postinsts directory do not exist. Not in the image recipe folder, not in the image file which I mount to check the content before flashing and of course it's deleted at the end of run-postinsts 

rootfs.py:
    def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
        if bb.utils.contains("IMAGE_FEATURES", "package-management",
                         True, False, self.d):
            return
        num = 0
        for p in self._get_delayed_postinsts():
            bb.utils.mkdirhier(dst_postinst_dir)

            if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):
                shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
                            os.path.join(dst_postinst_dir, "%03d-%s" % (num, p)))

            num += 1


package-management is in my image features so I understand nothing get written.

So who temporarily creates that /etc/ipk-postinsts?

Thanks,
-Damien

On Fri, May 8, 2020 at 6:15 PM Alexander Kanavin <alex.kanavin@...> wrote:
On Fri, 8 May 2020 at 11:32, Damien LEFEVRE <lefevre.da@...> wrote:

If can find the postinst script in /var/lib/opkg/info/test-deployment.postinst and execute it.

Since test-deployment is a new package, I would have expected pkg_postinst_ontarget to be executed

How is the first boot detected on a poky image? Is there a way to detect if .postinst scripts haven't been executed?

The scripts to be executed  are written into /etc/rpm|deb|ipk-postinsts/ and executed by
meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts script (which is started on first boot as a service).
Then they get deleted.

Alex


Re: pkg_postinst_ontarget not executed

Alexander Kanavin
 

Reading recipes-devtools/run-postinsts/run-postinsts/run-postinsts and_save_postinsts_common (in rootfs.py) once more, it seems /etc/ipk-postinsts is only used if there is no package manager on the target.

If there is, then 'opkg configure' is run directly, and so postinsts come from some internal database. There is some additional magic in rootfs.py to mark packages with first-boot postinsts as unpacked, so they'll get picked up by opkg.

Alex


On Wed, 13 May 2020 at 09:33, Damien LEFEVRE <lefevre.da@...> wrote:
Thanks Alex,

When I do a factory reset, the system detects as a first boot and the script is executed.

> cat /var/log/postinstall.log
Configuring test-deployment.

One thing which puzzles me: the /etc/ipk-postinsts directory do not exist. Not in the image recipe folder, not in the image file which I mount to check the content before flashing and of course it's deleted at the end of run-postinsts 

rootfs.py:
    def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
        if bb.utils.contains("IMAGE_FEATURES", "package-management",
                         True, False, self.d):
            return
        num = 0
        for p in self._get_delayed_postinsts():
            bb.utils.mkdirhier(dst_postinst_dir)

            if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):
                shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
                            os.path.join(dst_postinst_dir, "%03d-%s" % (num, p)))

            num += 1


package-management is in my image features so I understand nothing get written.

So who temporarily creates that /etc/ipk-postinsts?

Thanks,
-Damien

On Fri, May 8, 2020 at 6:15 PM Alexander Kanavin <alex.kanavin@...> wrote:
On Fri, 8 May 2020 at 11:32, Damien LEFEVRE <lefevre.da@...> wrote:

If can find the postinst script in /var/lib/opkg/info/test-deployment.postinst and execute it.

Since test-deployment is a new package, I would have expected pkg_postinst_ontarget to be executed

How is the first boot detected on a poky image? Is there a way to detect if .postinst scripts haven't been executed?

The scripts to be executed  are written into /etc/rpm|deb|ipk-postinsts/ and executed by
meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts script (which is started on first boot as a service).
Then they get deleted.

Alex


Re: Is there a relationship between the sstate and the machine?

Mikko Rapeli
 

Hi,

On Wed, May 13, 2020 at 10:36:49AM +0200, Mans Zigher wrote:
I am using a build environment based on the yocto project from one of
the big HW suppliers in the mobile industries. They are continuously
breaking the principles behind the yocto project and at one point they
managed to break the sstate cache because they are doing things in
there own way instead of using what already exists. They managed to
fix the sstate cache but it now looks to only work when using there
machines when I am defining my own machine even though it is a copy of
one of theirs the sstate cache it is not working. The sstate cache is
detect and the SSTATE_DIR is correct but it finds only a handful of
matches and builds the rest from scratch. Is there a logical
explanation for this? Or is this yet again some custom crap that this
supplier have done. FYI if you know what supplier I am talking about I
would very much recommend staying the hell away from them this is the
worst linux distro I have ever worked with both on the build and on
the system it is some kind of freak combination of a normal linux
system and android worst combination ever.
This is a common problem. It is likely that I know which SoC supplier you
are talking about and have had the exact same issues. We have managed to
fix or workaround all of them. In most cases by reducing what the SoC layers
do by BBMASK'ing all non-essential BSP recipes, reverse engineering the
machine configuration and bbclasses to only use bare minimal ones.

I can only hope that our feedback in terms of patches and workarounds also
going back the supplier chain(s) and you at some point see the same patches.
For example we updated the yocto open source layers from 2.5 sumo to 3.0 zeus
with very minimal support from the SoC and other suppliers and their layers
are still only compatible with 2.5 sumo, officially. Also switched from
using a custom Android based binary toolchain(s there were multiple
at some point) to using meta-clang.

If you have detailed question or problems, it would be nice to discuss them
here, but I know that some details may be closed. At least some general
aspects how to debug issues may be discussed without exposing too much
details or, well, company names.

Cheers,

-Mikko


Is there a relationship between the sstate and the machine?

Mans Zigher <mans.zigher@...>
 

Hi,

I am using a build environment based on the yocto project from one of
the big HW suppliers in the mobile industries. They are continuously
breaking the principles behind the yocto project and at one point they
managed to break the sstate cache because they are doing things in
there own way instead of using what already exists. They managed to
fix the sstate cache but it now looks to only work when using there
machines when I am defining my own machine even though it is a copy of
one of theirs the sstate cache it is not working. The sstate cache is
detect and the SSTATE_DIR is correct but it finds only a handful of
matches and builds the rest from scratch. Is there a logical
explanation for this? Or is this yet again some custom crap that this
supplier have done. FYI if you know what supplier I am talking about I
would very much recommend staying the hell away from them this is the
worst linux distro I have ever worked with both on the build and on
the system it is some kind of freak combination of a normal linux
system and android worst combination ever.

Thanks


Re: pkg_postinst_ontarget not executed

Damien LEFEVRE
 

Thanks Alex,

When I do a factory reset, the system detects as a first boot and the script is executed.

> cat /var/log/postinstall.log
Configuring test-deployment.

One thing which puzzles me: the /etc/ipk-postinsts directory do not exist. Not in the image recipe folder, not in the image file which I mount to check the content before flashing and of course it's deleted at the end of run-postinsts 

rootfs.py:
    def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
        if bb.utils.contains("IMAGE_FEATURES", "package-management",
                         True, False, self.d):
            return
        num = 0
        for p in self._get_delayed_postinsts():
            bb.utils.mkdirhier(dst_postinst_dir)

            if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):
                shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
                            os.path.join(dst_postinst_dir, "%03d-%s" % (num, p)))

            num += 1


package-management is in my image features so I understand nothing get written.

So who temporarily creates that /etc/ipk-postinsts?

Thanks,
-Damien

On Fri, May 8, 2020 at 6:15 PM Alexander Kanavin <alex.kanavin@...> wrote:
On Fri, 8 May 2020 at 11:32, Damien LEFEVRE <lefevre.da@...> wrote:

If can find the postinst script in /var/lib/opkg/info/test-deployment.postinst and execute it.

Since test-deployment is a new package, I would have expected pkg_postinst_ontarget to be executed

How is the first boot detected on a poky image? Is there a way to detect if .postinst scripts haven't been executed?

The scripts to be executed  are written into /etc/rpm|deb|ipk-postinsts/ and executed by
meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts script (which is started on first boot as a service).
Then they get deleted.

Alex


project that builds target and host

Joel Winarske
 

Hi,

I have a project that generates a native artifact during the target build.  Both the native and target artifacts are needed for other target recipes.

What's the recommended pattern for handling this?


Thanks,
Joel


Re: [PATCH] builders: Add Build Steps to get worker information

Aaron Chan
 

Bug #9917 has been update to "Review In Progress"
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9917


Migrating yocto project from sumo to warrior - getting null registry error from npm

Christopher McClellan
 

I'm migrating a yocto project that is working on sumo to warrior, so I set my layers to be the "warrior" branches. Everything runs fine until it fails in my node project layer on "do_compile" with the error message "Cannot read property 'replace' of null." It seems to return null for npm.config.get('registry'), but it is set on the Docker image that's building this image. If I delete the npm-shrinkwrap.json, it builds, but I'd like to leave that file in for the project. I think I need to either upgrade the npm version to 6.10.3 (where this error was fixed) or set the npm registry for the build process. How would I do that?


Re: python3 path different from python2

Tim Orling
 

Does your recipe inherit pythonnative? If so, you could try switching to ‘python3native’.


On Tue, May 12, 2020 at 12:13 PM Emily <easmith5555@...> wrote:
Hi all - 

I'm working with rocko trying to build a recipe with python3 that used to be build with python2 using cmake. After changing things in the build files, when I run the devshell for the recipe, I see two different include paths for python2 and python3. I have tried switching to zeus but I had a few issues with a xilinx bsp for the machine I wanted to build with. 

For python2 (correct):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python-config --cflags
-I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -fno-strict-aliasing -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/python/2.7.14-r1=/usr/src/debug/python/2.7.14-r1 -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native= -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes

For python3 (incorrect):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python3-config --cflags
-I/usr/include/python3.5m -I/usr/include/python3.5m  -Wno-unused-result -Wsign-compare -g -fstack-protector-strong -Wformat -Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

The python3 one is obviously incorrect, is there a way to tell where this path is coming from? Even if I manually include the proper path in the CMakeLists.txt it doesn't seem to work. Does yocto overwrite this path somewhere? 

Thanks!
Emily Smith



Re: [matchbox-desktop-2][PATCH] Add SPDX-License-Identifier: GPL-2.0-or-later

Richard Purdie
 

On Mon, 2020-03-23 at 11:53 -0400, Matthew wrote:
Fixes [YOCTO #13319]

Signed-off-by: Mingde (Matthew) Zeng <matthew.zeng@...>
---
libtaku/inotify/inotify-diag.c | 2 ++
libtaku/inotify/inotify-diag.h | 2 ++
libtaku/inotify/inotify-kernel.c | 2 ++
libtaku/inotify/inotify-kernel.h | 2 ++
libtaku/inotify/inotify-missing.c | 2 ++
libtaku/inotify/inotify-missing.h | 2 ++
libtaku/inotify/inotify-path.c | 2 ++
libtaku/inotify/inotify-path.h | 2 ++
libtaku/inotify/inotify-sub.c | 2 ++
libtaku/inotify/inotify-sub.h | 2 ++
Thanks for this. I did merge it however to be clear, the above files
are under LGPL, not GPL. As such, I removed this part of the commit and
added a second one of my own which resolves this.

Cheers,

Richard


python3 path different from python2

Emily
 

Hi all - 

I'm working with rocko trying to build a recipe with python3 that used to be build with python2 using cmake. After changing things in the build files, when I run the devshell for the recipe, I see two different include paths for python2 and python3. I have tried switching to zeus but I had a few issues with a xilinx bsp for the machine I wanted to build with. 

For python2 (correct):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python-config --cflags
-I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -I/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python2.7 -fno-strict-aliasing -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/python/2.7.14-r1=/usr/src/debug/python/2.7.14-r1 -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native= -fdebug-prefix-map=/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes

For python3 (incorrect):
root@dc:/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/git# python3-config --cflags
-I/usr/include/python3.5m -I/usr/include/python3.5m  -Wno-unused-result -Wsign-compare -g -fstack-protector-strong -Wformat -Werror=format-security  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

The python3 one is obviously incorrect, is there a way to tell where this path is coming from? Even if I manually include the proper path in the CMakeLists.txt it doesn't seem to work. Does yocto overwrite this path somewhere? 

Thanks!
Emily Smith


M+ & H bugs with Milestone Movements WW19

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW19 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.99

3.2 M1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW18!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

mark.morton@...

3

richard.purdie@...

1

bluelightning@...

1

changqing.li@...

1

limon.anibal@...

1

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW19 of who have open medium or higher bugs and enhancements against YP 3.2.   There are 120 possible work days left until the final release candidates for YP 3.2 needs to be released.

Who

Count

richard.purdie@...

30

david.reyna@...

19

bluelightning@...

16

akuster808@...

14

bruce.ashfield@...

11

kai.kang@...

9

Qi.Chen@...

9

randy.macleod@...

8

trevor.gamblin@...

8

ross@...

7

JPEWhacker@...

7

mark.morton@...

7

timothy.t.orling@...

6

changqing.li@...

6

michael@...

5

pbarker@...

4

raj.khem@...

4

alex.kanavin@...

4

mingli.yu@...

4

rpjday@...

4

hongxu.jia@...

3

yi.zhao@...

3

chee.yang.lee@...

3

akuster@...

3

kexin.hao@...

3

jon.mason@...

3

alejandro@...

2

ycnakajsph@...

2

mark.hatle@...

2

jpuhlman@...

2

mostthingsweb@...

2

seebs@...

2

kergoth@...

2

jaewon@...

2

naveen.kumar.saini@...

1

amber.n.elliot@...

1

maxime.roussinbelanger@...

1

nicolas.dechesne@...

1

ricardo.ribalda@...

1

sakib.sajal@...

1

kai.ruhnau@...

1

zhe.he@...

1

matthew.zeng@...

1

bunk@...

1

dl9pf@...

1

mshah@...

1

denis@...

1

yang.wang@...

1

liu.ming50@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 

8421 - 8440 of 57806