Re: [yocto] [Question] How to handle GPLv3 packages?

[Robert Berger]

Hi,

My comments are inline.

On 08/04/2022 13:15, Matthias Schoepfer via lists.yoctoproject.org wrote:

Hi!

To elaborate more on the GPLv3 topic: If you were to use secure boot, 
signed update images, and all that jazz, how can you make your Firmware 
GPLv3 compliant? Has *anyone* done it or knows a company / product, that 
does that?!


I am not a lawyer, but I guess you could mention in your manual that you 
can dish out a non reversible image which was built with a "dummy" key. 
This would allow the end customer to replace the xGPLv3 components.


But instead of a "car" you have an expensive eval board afterwards.

Another interesting issue is the "EU Radio Equipment Directive". It 
seems to be incompatible with GPLv3[1] ;)


[1] https://fsfe.org/activities/radiodirective/radiodirective.en.html



Regards,

     Matthias




--
Robert Berger
Embedded Software Evangelist

Reliable Embedded Systems
Consulting Training Engineering
URL: https://www.reliableembeddedsystems.com

Schedule a web meeting:
https://calendly.com/reliableembeddedsystems/
~~~
--

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56697): https://lists.yoctoproject.org/g/yocto/message/56697
Mute This Topic: https://lists.yoctoproject.org/mt/90285507/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Additional hardening options

[Robert Berger]

Hi,

This[1] is what I usually add as well to the security flags.

With respect to the "default" flags I had some fun with the SDK and 
-D_FORTIFY_SOURCE=2 and -fstack-protector-strong.

I guess they do have some performance impact as well, but I did not do very 
thorough research.

Also, I did not confirm it yet but suspect that some of those flags might be 
the reason for "debuginfod gdb: *** stack smashing detected ***: terminated".[2]

[1] 
https://gitlab.com/meta-layers/meta-resy/-/blob/master/conf/distro/include/more_security_flags.inc

[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14570

Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56040): https://lists.yoctoproject.org/g/yocto/message/56040
Mute This Topic: https://lists.yoctoproject.org/mt/88687579/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #dunfell Path to sources in debugfs

[Robert Berger]

Hi,

My comments are inline.

On 05/10/2021 17:04, bohdan.shubenok@sigma.software wrote:

Hi all,

I`m trying to debug coredump generated on embedded system running 
dunfel. 


Just to clarify your user space applications crashes and you try to see 
why? In other words you would like to load the application and the core 
file into your debugger and inspect it?


The issue I`m facing is with the source files path in 
"-dbg.rootfs" archive and within dedug portion of a package.

When loaded in QtCreator some sources can`t be found :


The part is missing is "*build/..*". Such notation is obviosly cancels 
itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found 
in build path for sqlite:


    build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
    build/Makefile:313:abs_srcdir = 
/home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
    build/Makefile:315:abs_top_srcdir = 
/home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100

    build/Makefile:358:srcdir = ../sqlite-autoconf-3310100

So I tried to disable out-of-tree build for sqlite by replacing 
*'inherit autotools*' with '*inherit autotools-brokensep*'. After 
building and loading new debugfs QtCreator was able to found required 
sources:



Is this a known issue or me doing something wrong with build setup?


This is very strange, but also I am not quite sure how exactly you debug.
I assume you run gdbserver on the target and connect from some cross-gdb 
on your host to it.


You could try to install gdb onto your target plus debug info and 
sources to exclude the cross-gdb configuration problem as I describe below.


If you use gdbserver/cross-gdb I assume directories on your target 
rootfs and host roots are different. So you need to tell your cross-gdb 
on the host where to find the debug info and the sources.


Can you please try something like this?

http://docs.yoctoproject.org/singleindex.html#using-the-gdbserver-method

What I would inspect carefully is something like that:

$ cd directory-holding-the-debugfs-directory
$ arch-gdb
(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) target remote IP-of-target:1234

At least in the latest and greatest version this works. I remember a bug 
a long time ago with some ancient yocto release with cross-debugging, 
but this was resolved with some upgrade and was certainly older than 
dunfell.


Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54969): https://lists.yoctoproject.org/g/yocto/message/54969
Mute This Topic: https://lists.yoctoproject.org/mt/86094129/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto -third party licensimg

[Robert Berger]

Hi Steven,

Please see my comments inline

On 24/09/2021 14:10, Monsees, Steven C (US) via lists.yoctoproject.org 
wrote:


The one solution I found says : Add *LICENSE_PATH += 
"${LAYERDIR}/custom-licenses"* under conf/layer.conf, *this does not 
resolve this warning*.


This is a new item being added to our Yocto build.

The Data Direct vendor does not submit their code to Yocto because they 
sell thier code.


We are adding code to Yocto that has a private license and we are 
attempting to have Yocto accept the license, *is this proper way to 
handle this ?*


I am a bit confused, but can try to show you what I typically do.
In my custom meta-my-layer I add to layer.conf:

#-->
LICENSE_PATH += " ${LAYERDIR}/custom-licenses"

CUSTOM_COMMON_LICENSE_DIR := 
'${@os.path.normpath("${LAYERDIR}/custom-licenses")}'

BB_HASHBASE_WHITELIST_append = " CUSTOM_COMMON_LICENSE_DIR"
#<--

underneath the custom-licenses dir in this meta-my-layer I put the 
custom "hello-license".




*Can you tell me the proper way to add a custom license to a recipe in 
yocto ?*


Once you did something like mentioned above you can add the license to 
the recipe you use to build the funny component of your supplier.


example_0.1.bb:

LICENSE = "hello-license"
LIC_FILES_CHKSUM = 
"file://${CUSTOM_COMMON_LICENSE_DIR}/hello-license;beginline=5;endline=12;md5=36e6988a930e054886e6af19372edb07"


If you want to get fancy, since it does not seem to be an open source 
license, you can mark it also as:


LICENSE_FLAGS = "commercial" in the recipe

but then you need to whitelist e.g. in your local.conf to be able to 
bitbake it:


# whitelist example recipe, which is under a commercial license
LICENSE_FLAGS_WHITELIST = "commercial_example"



Thanks,

Steve


Hope this helps,

Regards,

Robert










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54845): https://lists.yoctoproject.org/g/yocto/message/54845
Mute This Topic: https://lists.yoctoproject.org/mt/85836383/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Pyinstaller error in yocto #yocto

[Robert Berger]

Hi,

Please don't use screen shots, but pastebin instead. I already mentioned 
this on fb.


My comments are inline.

On 29/08/2021 13:48, yasminebenghoz...@gmail.com wrote:

Hello,
I successfully installed pyinstaller in my yocto image , but while 
executing the command it doesn't work


It misses ldd.

It's here:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/glibc/glibc-package.inc

You might want to try something like:

IMAGE_INSTALL += "ldd"

Regards,

Robert










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54594): https://lists.yoctoproject.org/g/yocto/message/54594
Mute This Topic: https://lists.yoctoproject.org/mt/85225741/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-security][PATCH 1/2] image-with-hardened-binaries: add class

[Robert Berger]

Hi,

On 21/08/2021 18:35, Armin Kuster wrote:


Regarding the selftest, is there test for failure?

I ran this against core-image-minimal and nothing was printed out. Does
that mean its fine?

You may want to remove the ".py" from
python3-checksec.py-native_0.6.1.bb, its not needed.


If you run checksec manually against some binary e.g. ls.coreutils it 
outputs something like this:


https://pastebin.com/JkeN1h3k

Not sure what this should output.



-armin



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54530): https://lists.yoctoproject.org/g/yocto/message/54530
Mute This Topic: https://lists.yoctoproject.org/mt/84968578/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Cannot build yocto anymore after updating all layers to current dunfell branch tips

[Robert Berger]

On 14/08/2021 00:28, Manuel Wagesreither wrote:

Hello all,

I updated the layers of my project to the current dunfell branch tips. See 
here: 
https://gitlab.com/manuel_wagesreither/bora-proj/-/commit/de631634d7556987d2551d0cedca8f67530bc78d

Since then, the build is failing with the following message:
```
ERROR: ParseError at 
/home/manuel/bora-proj/meta-openembedded/meta-oe/conf/layer.conf:104: unparsed line: 
'DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"'
```



There was an OVERRIDE syntax change and this is what are seeing.
Some layers, like meta-openembedded incorporated this change into their 
master branch. So either you need to update all your layers as well, or 
you need to use meta-openembedded with a branch/commit before the change.


Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54400): https://lists.yoctoproject.org/g/yocto/message/54400
Mute This Topic: https://lists.yoctoproject.org/mt/84873772/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Install SDK with yocto

[Robert Berger]

Hi,

After you download e.g. the tarball, you'll find an installation guide 
inside.


It says:

OpenSUSE 13.1 / 42.3
Ubuntu ® 14.04 / 16.04
Fedora 26 / 27
Debian 8.10 / 9.3

So I am not sure why you assume that this should work out of the box/at 
all with the Yocto Project.


If you really want it I suggest to talk to Baumer about it and I am 
happy to help you and them with the integration.


Regards,

Robert







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54256): https://lists.yoctoproject.org/g/yocto/message/54256
Mute This Topic: https://lists.yoctoproject.org/mt/84515269/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [poky] [PATCH] local.conf.sample: disable prelink

[Robert Berger]

On 22/07/2021 22:05, Alexander Kanavin wrote:
PIE is nowadays more or less the only available option and is expected 
for improved security; Yocto does not even test non-PIE builds or 
provide an off the shelf way to turn it off.


I am worried about those libraries, which are non-PIE libraries by 
default. My theory is, that they are non-PIE since prelink is able to 
operate on them. So prelink can "at least" be used a PIE detector.


They are:

lib/libdl-2.33.so is prelinked
lib/ld-2.33.so is prelinked
lib/libpthread-2.33.so is prelinked
lib/libc-2.33.so is prelinked

Is there are rational explanation why they are not compiled in PIE mode 
and/or if they are compiled in PIE mode how cross-prelink can operate on 
them? If cross-prelink can operate on them why not on the others?




I also have to note that prelink does show higher RAM consumption in 
your tests as well (MemFree column). On the constrained systems which 
would benefit most from improved prelink timings that might be a bigger 
loss than not prelinking.


I guess we agree that MemFree shows free physical memory (user and 
kernel space).


My experiments show, that non-PIE and no prelink leaves the biggest 
amount of free physical memory.


They also show that non-PIE and prelink leave the smallest amount of 
free physical memory ;)


The difference is significant
prelinked-no-pie/no-prelink-no-pie: 4552 (kB)

If we leave things are they are:
prelinked-no-pie/prelinked-with-pie:3972 (kB)

If we disable prelink (as you suggest - and I tend to agree since it 
does not make sense as it is right now)

prelinked-no-pie/no-prelink-with-pie:   4120 (kB)

...

but

if you look at the next line MemAvailable kB things looks a bit differently.

My interpretation of MemAvailable is, that it is an estimate of virtual 
memory available after reclaimable parts of memory (caches, buffer, 
slab,...) have been reclaimed without getting swap involved.


I see this:

MemAvailable kB

prelinked-with-pie  939412
no-prelink-with-pie 939696
prelinked-no-pie940344
no-prelink-no-pie   941216

Which means, that our current default setting is the worst possible 
solution ;)


no-prelink-no-pie would (theoretically) be the best.

I will try to update my second article and try to explain a bit more my 
interpretation of the results and maybe also try to see what bootchart 
says to all this.


Don't get me wrong. I am neither pro nor con prelink. I just would like 
to understand what it does, if it does something ;)


I spent quite some time on this - also discussing with most of you offline.
If you ask me, we should use your patch, since people didn't even notice 
that prelink can not prelink on PIE binaries for a couple of years.


So there does not seem to be much demand for it ;)

We can keep a "placebo" in for the homeopaths who think they use prelink 
in their images since PIE was enabled ;)




But yes, there is a timing benefit visible in the tests: 0.01s vs 0.1s.


Also less CPU usage can be seen. I hope I'll find time to run some test 
with bootchart. Maybe then we can also see boot time, memory, CPU,...


Regards,

Robert



Alex

On Mon, 19 Jul 2021 at 22:58, Robert ber...@yocto.user 
> wrote:


Hi Alex, RP, Mark,

I did some research on the subject in order to try to figure out
what is
going on.

1) I come to a similar conclusion with what found, but tried to look a
bit deeper for the reason.

1.1) The reason that cross-prelink is not prelinking is, that for a
quite some time by default everything is built with PIE mode by default
and cross-prelink does not seem to be able to work on exe/libs compiled
with PIE mode. So seeing the same behavior with and without prelinking
is what I would expect as long as everything is compiled with PIE mode.

A more detailed analysis of my tests can be found on my not yet
officially published site:

https://rlbl.me/prelink-1 

https://rlbl.me/prelink-2 

Alex:

Can you please rebuild your test images without PIE mode and re-run the
tests?

Then we should have the 4 test cases:

prelinked-with-pie
no-prelink-with-pie
prelink-no-pie
no-prelink-no-pie

I guess then we can discuss what are the next steps.

In my opinion the current default settings, which compile close to
everything in PIE mode, but invoke also cross-prelink do not make much
sense.

The question is: "Do we want to drop cross-prelink, or do we want to
drag it along and come up more fine-grained configuration options?"

We could e.g. exclude certain files from pre-linking.

IMHO cross-prelink still works, but not on exe/libs which were compiled
in PIE mode.

Regards,

Robert




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54205): 

Re: [yocto] [poky] [PATCH] local.conf.sample: disable prelink

[Robert Berger]

Hi Alex, RP, Mark,

I did some research on the subject in order to try to figure out what is 
going on.


1) I come to a similar conclusion with what found, but tried to look a 
bit deeper for the reason.


1.1) The reason that cross-prelink is not prelinking is, that for a 
quite some time by default everything is built with PIE mode by default 
and cross-prelink does not seem to be able to work on exe/libs compiled 
with PIE mode. So seeing the same behavior with and without prelinking 
is what I would expect as long as everything is compiled with PIE mode.


A more detailed analysis of my tests can be found on my not yet 
officially published site:


https://rlbl.me/prelink-1

https://rlbl.me/prelink-2

Alex:

Can you please rebuild your test images without PIE mode and re-run the 
tests?


Then we should have the 4 test cases:

prelinked-with-pie
no-prelink-with-pie
prelink-no-pie
no-prelink-no-pie

I guess then we can discuss what are the next steps.

In my opinion the current default settings, which compile close to 
everything in PIE mode, but invoke also cross-prelink do not make much 
sense.


The question is: "Do we want to drop cross-prelink, or do we want to 
drag it along and come up more fine-grained configuration options?"


We could e.g. exclude certain files from pre-linking.

IMHO cross-prelink still works, but not on exe/libs which were compiled 
in PIE mode.


Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54166): https://lists.yoctoproject.org/g/yocto/message/54166
Mute This Topic: https://lists.yoctoproject.org/mt/83558267/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] the downside of parallelism

[Robert Berger]

Hi,

On 20/06/2021 12:55, Robert P. J. Day wrote:


   refactoring existing (legacy) code base into more bite-sized
bitbake recipes to speed up build by taking advantage of 6-core
(12-thread) dell laptop ... end result is that i get so much
parallelism that laptop shuts down from overheating.


Sorry for my stupid question;)

If you have 12 threads, it's 12 threads and not more.

I guess there needs to be some kind of dependency between your new recipes.

make -j can use as many cores as you like even with a single recipe.

How would it speed up builds if you break up a recipe into multiple recipes?

What is your refactoring approach?



   le *sigh* ...

rday


Regards,

Robert










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53922): https://lists.yoctoproject.org/g/yocto/message/53922
Mute This Topic: https://lists.yoctoproject.org/mt/83664460/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Extensible SDK of core-image-minimal fails to install

[Robert Berger]

Hi,

On 12/06/2021 10:47, Richard Purdie wrote:


I think it may be this bug:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14428

We don't have a fix as yet, it looks difficult to solve :(

Cheers,

Richard


Not a fix, but a workaround, if you are willing to use containers is to 
create a build container and a similar sdk container.


I added more information to the bug above.

Regards,

Robert



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53846): https://lists.yoctoproject.org/g/yocto/message/53846
Mute This Topic: https://lists.yoctoproject.org/mt/83423927/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #golang: go fetches dependencies in compile phase

[Robert Berger]

Hi,

My comments are inline.

On 12/04/2021 14:47, Juergen Landwehr wrote:

Hi Robert,

thanks for your thoughts.

I see your point and the last thing I want is "NOT reproducable builds".

But dependency management in go is not that arbitrary as it may seem. 


... if everybody does what they are supposed to - which is not the case.

Dependencies and their version is stored in "go.mod". To ensure 
reproducable builds, hashes for each dependency and version are stored 
in "go.sum". Both files are in git and together with a local golang 
proxy, this should ensure reproducable builds, right?


This does not sound too bad. This would also mean, that if the outside 
repo dies you can still build and that you know what's on your proxy.




To ensure that licences are valid and did not change over time, we 
developed a little tool, that goes through all dependencies and creates 
the following output, which we insert into our recipe:


LICENSE = "Apache-2.0 & MIT & MIT & BSD-2-Clause & BSD-3-Clause & ...


Here you

1) Totally lost which License comes from which module and I hope 2 times 
MIT is just a typo.


Of course if you are really serious about licensing you should use a 
tool like fossology, upload all your sources there and inspect them.

You will be surprised.

There are a couple of tools out there which scan your sources and some 
which claim to do stuff with golang as well.


2) Do you check if the licenses are compatible?

MIT and Apache are compatible:

some googling:

"Both the Apache License and the MIT license are permissive, so 
incorporating MIT licensed code into your Apache licensed project is 
certainly allowed. Just be sure to attribute the original author for the 
parts your incorporated and include a copy of the MIT License terms, as 
required by the license."


Apache and BSD should also be OK:

some googling:

"In both of them you must:

Include copyright

But in Apache, unlike BSD you must:

Include License
State Changes
Include Notice
"



LIC_FILES_CHKSUM = " \
file://${S}/src/${GO_IMPORT}/vendor/github.com/coreos/go-oidc/LICENSE;md5=d2794c0df5b907fdace235a619d80314
 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/locales/LICENSE;md5=3ccbda375ee345400ad1da85ba522301
 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/go-playground/universal-translator/LICENSE;md5=2e2b21ef8f61057977d27c727c84bef1
 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/godbus/dbus/v5/LICENSE;md5=09042bd5c6c96a2b9e45ddf1bc517eed
 \
file://${S}/src/${GO_IMPORT}/vendor/github.com/golang/gddo/LICENSE;md5=4c728948788b1a02f33ae4e906546eef
 \
...

This is a manual step and whenever dependencies change we have to create 
this list again and add it to the recipe, but it contains all the 
required license information and makes them visible in the recipe.


really all?

You search through every single file of a go module and it's 
dependencies? Or just the license text, if there is one?




It might pollute the recipe a bit, but luckily we do not have thousands 
of dependencies like some npm projects. So I think it is still 
manageable. And is it much less work, than defining a recipe for each 
dependency.


So we would
* guarantee reproducable builds
* use the programming language (in our case golang) to handle dependency 
management

* ensure that licenses are visible and correct

I mean it is not perfect and still a compromise, but it should work 
without breaking reproducable builds or causing license issues?

What do you think?

Regards,
Jürgen

PS: Thanks for the link. I was not aware of this discussion (it is quite 
a bit to read:))


Regards,

Robert









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53141): https://lists.yoctoproject.org/g/yocto/message/53141
Mute This Topic: https://lists.yoctoproject.org/mt/81968964/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #golang: go fetches dependencies in compile phase

[Robert Berger]

On 09/04/2021 16:53, Juergen Landwehr wrote:

Hi,
we are developing an application in go and use the "go-mod" bb-class 
from poky. This works fine.
However, the problem is, that the dependencies in go.mod are now fetched 
in the compile phase and not in the fetch phase.


Alexander (whom you cc'ed here as well) wrote a long time ago on the 
mailing list[1] about this stuff.


We have a couple of issues with those "modern" languages like go, which 
behave quite differently from good old Unix stuff. So the paradigm on 
which the whole Bitbake/OpenEmbedded/Yocto system was built does not 
quite apply for those.


Don't get me wrong, you can also do stupidities like git clone via make 
or cmake, but this is most likely not the way those tools should be used.


1) "Guaranteed __NOT__ reproducible builds"(C)

Go pulls in dependencies by itself, which might explain why it's in the 
compile phase and not it the fetch phase.


This leads to many interesting issues, like "guaranteed __NOT__ 
reproducible builds"(C). The problem is, that you don't have any 
influence on dependencies of dependencies. Someone changes somewhere a 
dependency on github and the party starts.


1.1) One sane solution to "please give me always the same input" is what 
Konrad already mentioned in combination with a local golang proxy.


2) Open Source License Compliance

If you pull in all those funny dependencies and also link things 
statically, like with go, Open Source License Compliance is getting very 
interesting.


People typically just use the license of the top level "main" entry 
point. In reality you would need to check all the dependency tree for 
licenses. You should also check if it's legally allowed to combine the 
licenses and in case it's allowed what are implications of GPLvx, 
LGPLv2, LGPLv3 without exceptions for your product.


[1] https://www.yoctoproject.org/pipermail/yocto/2017-March/035028.html

Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53079): https://lists.yoctoproject.org/g/yocto/message/53079
Mute This Topic: https://lists.yoctoproject.org/mt/81968964/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] bitbake controlling memory use

[Robert Berger]

Hi,

My comments are in-line.

On 11/04/2021 18:23, Gmane Admin wrote:
My build machine has 8 cores + HT so bitbake enthusiastically assumes 
16. However I have (only?) 16GB of RAM (+24GB swap space).


16GB of RAM has always been more then enough with 4 core + HT, but now 
building certain recipes (nodejs, but rust will probably do it as well) 
eats up more memory then there actually is RAM causing excessive swapping.


The RAM usage depends heavily on what you are building ;) - It could be 
some crazy C++ stuff ;)


Is Linux your build host?

Then you can use cgroups to limit resources like memory.

Do you use a build container? It uses cgroups underneath.

e.g. docker:

https://docs.docker.com/config/containers/resource_constraints/

Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53076): https://lists.yoctoproject.org/g/yocto/message/53076
Mute This Topic: https://lists.yoctoproject.org/mt/82015730/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Regarding Mender integration

[Robert Berger]

Hi,

Please see my comments in-line.

On 16/02/2021 19:48, U RAVI KUMAR wrote:

I have some issues while integrating the mender on the yocto
project.I have included meta-mener-core,meta-mender-raspberrypi
layers.And iam getting the following error:

ERROR: u-boot-1_2020.07-r0 do_patch: Command Error: 'quilt --quiltrc

/home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0  Output:
Applying patch 0001-configs-rpi-enable-mender-requirements.patch
patching file configs/rpi_0_w_defconfig
Hunk #1 FAILED at 19.


...

This looks like the patch you/mender try/tries to apply does not work 
with your u-boot version.[0]


[0] 
https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-core/recipes-bsp/u-boot


Which Yocto version do you use?

Which Mender version do you use?

You could look into creating your own Mender integration[1] instead of 
the mender class.


[1] 
https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot/manual-u-boot-integration


I think the right place to ask Mender specific questions is here[2].

[2] https://hub.mender.io/

Regards,

Robert



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52359): https://lists.yoctoproject.org/g/yocto/message/52359
Mute This Topic: https://lists.yoctoproject.org/mt/80585537/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #yocto #kernel #linux

[Robert Berger]

Hi,

My comments are in-line.


On 12/02/2021 14:30, Ross Burton wrote:

The first question is why.  It sounds like you want Ubuntu but the
bootloader and kernel built by Yocto.  I'm struggling to see what this
would achieve.


... a legal battle maybe?

Bring in the lawyers!

I would also ask:

"What is your use case?"
"Did you ask Canonical?"
"Does Canonical allow you to do this?"

From [1]:

"Copyright licensing[1] and trademarks[3] are two different areas of 
law, and we consider them separately in Ubuntu. The following policy 
applies only to copyright licences. We evaluate trademarks on a 
case-by-case basis."


From [4]:

"
You can download, install and receive updates to Ubuntu for free.

You can modify Ubuntu for personal or internal commercial use.

You can redistribute Ubuntu, but only where there has been no 
modification to it.


You can use our copyright, patent and design materials in accordance 
with this IPRights Policy.


You can be confident and can trust in the consistency of the Ubuntu 
experience.


You can rely on the standard expected of Ubuntu.

Ubuntu is an aggregate work; this policy does not modify or reduce 
rights granted under licences which apply to specific works in Ubuntu.

"

"
Any redistribution of modified versions of Ubuntu must be approved, 
certified or provided by Canonical if you are going to associate it with 
the Trademarks. Otherwise you must remove and replace the Trademarks and 
will need to recompile the source code to create your own binaries. This 
does not affect your rights under any open source licence applicable to 
any of the components of Ubuntu. If you need us to approve, certify or 
provide modified versions for redistribution you will require a licence 
agreement from Canonical, for which you may be required to pay. For 
further information, please contact us (as set out below).

"

"
We do not recommend using modified versions of Ubuntu which are not 
modified in accordance with this IPRights Policy. Modified versions may 
be corrupted and users of such modified systems or images may find them 
to be inconsistent with the updates published by Canonical to its users. 
If they use the Trademarks, they are in contravention of this IPRights 
Policy. Canonical cannot guarantee the performance of such modified 
versions. Canonical’s updates will be consistent with every version of 
Ubuntu approved, certified or provided by Canonical.

"

"
You can use the Trademarks, in accordance with Canonical’s brand 
guidelines, with Canonical’s permission in writing. If you require a 
Trademark licence, please contact us (as set out below).

"

"
You can use the Trademarks in discussion, commentary, criticism or 
parody, provided that you do not imply endorsement by Canonical.

"

[1] https://ubuntu.com/licensing

[2] 
https://forum.snapcraft.io/t/commercial-usage-of-snaps-and-dealing-with-licensing/6211


[3] https://ubuntu.com/legal/trademarks

[4] https://ubuntu.com/legal/intellectual-property-policy

Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52304): https://lists.yoctoproject.org/g/yocto/message/52304
Mute This Topic: https://lists.yoctoproject.org/mt/80581074/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-virtualization]: dunfell docker run issues

[Robert Berger]

Hi,

On 04/02/2021 17:03, Marek Belisko wrote:

Hi,

I'm trying to run docker containers on orangepi and use
meta-virtualization layer to add docker. I've installed the docker-ce
package and everything seems to be fine.

But docker service seems fails to start with:
Feb 04 15:00:01 orange-pi-zero dockerd[495]: failed to start daemon:
Devices cgroup isn't mounted



Can you please tell us which version of yocto this is?

Also which kernel and especially which kernel config.

I use something pretty recent (master kind of) and I am able to start 
docker and podman with a custom kernel, but networking is very wrong.


e.g.
1) if I run a web service in a container and open port 8080 to the 
outside world it is not accessible.


2) it's also not possible with docker-compose/podman-compose to 
communicate between containers


... unless I put everything on the host network.

Once you reconfigure your kernel and get it up and running could you 
please also test the issues I mention here?


BTW will dunfell it seems to work, I need to retest, but I have some 
boards running with it, I believe.


If you manage to get an upstream kernel to run on your orangepi zero I 
guess I could even give you my layers to give it a try. You will need 
another device tree and boot loader, but the rest should work.


Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52249): https://lists.yoctoproject.org/g/yocto/message/52249
Mute This Topic: https://lists.yoctoproject.org/mt/80381272/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [prelink-cross][PATCH] Add SPDX license headers to all source files

[Robert Berger]

On 04/02/2021 19:17, Richard Purdie wrote:


-   GNU Lesser General Public
-   License as published by the Free Software Foundation; either
-   version 2.1 of the License, or (at your option) any later version.
-
+* SPDX-License-Identifier: GPL-2.0-or-later
+*/


I guess the correct SPDX id is then:

LGPL-2.1-or-later

In order to get this right I would highly recommend to use fossology to 
look at those files.






This file mentions "GNU Lesser General Public License" and version 2.1
which is not GPL-2.0!

It is critical to get this bit right.

Cheers,

Richard


Regards,

Robert










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52233): https://lists.yoctoproject.org/g/yocto/message/52233
Mute This Topic: https://lists.yoctoproject.org/mt/80311841/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Building eSDK fails #sdk

[Robert Berger]

Hi,

My comments are in-line

On 04/02/2021 19:43, alexander.tr...@deveritec.com wrote:

Hello,
I build the SDK with bitbake core-image-base -c populate_sdk and it 
works just fine. But trying to build the eSDK with bitbake 
core-image-base -c populate_sdk_ext results in this error:


ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Unable to install 
packages. Command 
'/opt/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/recipe-sysroot-native/usr/bin/opkg 
--volatile-cache -f 
/opt/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/opkg.conf 
-t 
/opt/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/ipktemp/ 
-o 
/opt/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/sdk/image/opt/my-os/0.1/sysroots/none  
--force_postinstall --prefer-arch-to-version   install cppzmq-dev 
googletest-dev libappcommunicator-dev liblogger-dev libmodbus-dev 
libmyos-common-dev protobuf-c zeromq-staticdev' returned 255:

Collected errors:
  * opkg_prepare_url_for_install: Couldn't find anything to satisfy 
'cppzmq-dev'.


ERROR: Logfile of failure stored in: 
/opt/build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-tarball/1.0-r0/temp/log.do_populate_sdk.155
ERROR: Task 
(/opt/yocto/poky/meta/recipes-core/meta/buildtools-tarball.bb:do_populate_sdk) 
failed with exit code '1'


Which version is this?

Can it be reproduced?

If so you might want to add it to https://bugzilla.yoctoproject.org




The listed Packeges are set in the TOOLCHAIN_TARGET_TASK variable. I 
tryed using IMAGE_INSTALL_append but this didn't help.

Does someone have an idea?

greetings
Alex


Regards,

Robert









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52232): https://lists.yoctoproject.org/g/yocto/message/52232
Mute This Topic: https://lists.yoctoproject.org/mt/80385790/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] 2038 time problem fix in yocto #kernel #linux #yocto #zeus

[Robert Berger]

Hi,

On 03/02/2021 09:13, dhandhukiya.par...@gmail.com wrote:

Hi,

We need to have a fix for 2038 problem for out 32 bit based product 
which is running Yocto (Linux).
2038 time problem was fixed in Linux kernel recently 
https://www.theregister.com/2020/10/19/linux_5_10_y2k38_fixes/


How about switching to a more recent version of the YP then zeus?

A recent version uses the 5.10.x kernel.

... but it does not automatically fix everything.

Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52202): https://lists.yoctoproject.org/g/yocto/message/52202
Mute This Topic: https://lists.yoctoproject.org/mt/80348349/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Points to consider while moving to new yocto versions

[Robert Berger]

Hi,

My comments are in-line

On 25/01/2021 10:07, amaya jindal wrote:

Hi All,

We are planning to move to New yocto from current one that is krogoth 
yocto to some updated one. 


I would consider it "best practice" to somewhat try to stay up to date 
with recent yocto versions and plan for this from the beginning of your 
project.


What I mean is to have a "stable release" and a "next release" which is 
being used in your nightly builds and tests.


This will make it significantly easier to make version upgrades.

We are not thinking to move to gates-garth or 
some other major release but the releases than can have easily support 
for arm.


I am not sure what you mean by that?

Which versions make it easier/more difficult to support arm?

It's more a question of which chip/kernel/boot loader,...



Please support and help.

Points need to take care to port to new yocto version.


Ssince you use a completely outdated and end of life version[1] it might 
require quite some effort to update, but through pain we learn ;)


[1] https://wiki.yoctoproject.org/wiki/Releases

Which chip do you use?

Is it supported by an upstream kernel/boot loader?

Which (additional) layers do you use?

Are these layers supported by the same version as the Yocto version you 
want to move to?


How about your own recipes?

Are they compatible with upstream yocto?



Regards,
Rohit


Regards,

Robert









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52084): https://lists.yoctoproject.org/g/yocto/message/52084
Mute This Topic: https://lists.yoctoproject.org/mt/80099041/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #kernel setting up PREMIRRORS under zeus

[Robert Berger]

Hi,

Please see my comments in-line.

On 24/01/2021 22:09, Robert P. J. Day wrote:

On Sun, 24 Jan 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:


I added the following to my local.conf:

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = “file:///ede/tms/yocto/zeus/downloads/PATH”


I assume your sources are in /ede/tms/yocto/zeus/downloads/

Can you please try without the PATH at the end?

The manual does not mention anything like PATH at the end[1]

I do expose my per site premirror via a web server to all the machines 
like this:


SOURCE_MIRROR_URL = "http://mirror/source_mirror_gatesgarth;

[1] https://docs.yoctoproject.org/singleindex.html#term-SOURCE_MIRROR_URL



But this does not appear to retrieve the tar-balls from from my local 
repository…


   not sure why that wouldn't work, it's what i've used for years.

rday


Regards,

Robert










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52077): https://lists.yoctoproject.org/g/yocto/message/52077
Mute This Topic: https://lists.yoctoproject.org/mt/80086836/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] OpenEmbedded Virtual Stand at FOSDEM 2021

[Robert Berger]

Hi,

On 13/01/2021 23:33, Paul Barker wrote:

Hi folks,

* Any participants in the project who want to help host the Matrix
chat room between 09:00 and 18:00 each day of the event. This will
likely involve introducing the project to folks dropping in the chat
who aren't familiar with OpenEmbedded, answering basic questions and
chatting about example uses of the project. You don't need to be a
long-standing expert in the project to help out here! If you can do a
couple of hours or a half day please let us know.


Let's try to come up with some schedule when I should be there and just 
let me know how the join the chat.




* Any contributions of video content to go along with the static web
pages. I'm planning to record some short introductory video content
but other contributions would also be welcome. Details on how to
upload videos is expected in the near future but for now it would be
good to just collect folks who are interested so we can discuss this
further.

If you're interested in any of the above please reply to me and/or the
list. I look forward to virtually seeing many of you at FOSDEM 2021!


What kind of video would you like? A small video which explains a 
specific topic?


Something like this?[1]

[1] https://www.youtube.com/watch?v=kmpEN953pzs=youtu.be



Thanks,


Regards,

Robert










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52002): https://lists.yoctoproject.org/g/yocto/message/52002
Mute This Topic: https://lists.yoctoproject.org/mt/79662005/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Suggestions on improvements

[Robert Berger]

Hi,

On 08/01/2021 04:59, Meh Mbeh Ida Delphine wrote:
>
> Due to some mismatches, warnings pop up during the build. Below are some
> few sample warnings and I'm aware of false positives;
Why do you think they are false positives?

>
> WARNING: glibc-2.32-r0 do_package: License for package nscd is {'GPL-2.0
> WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
Check this file:

FileName: 
./spdx_temp/git/.pc/0026-inject-file-assembly-directives.patch/sysdeps/aarch64/crti.S

FileChecksum: SHA1: 83c9d68d2f83ca0af8af2a918533f21004aac238
LicenseConcluded: NOASSERTION
LicenseInfoInFile: LGPL-2.1-or-later
LicenseInfoInFile: LicenseRef-scancode-unlimited-linking-exception-lgpl
FileCopyrightText: Copyright (c) 1995-2020 Free Software 
Foundation, Inc.




I play around with meta-spdxscanner and if you run e.g. scancode-toolkit 
it tells you:


FileName: ./spdx_temp/git/nscd/cache.c
FileChecksum: SHA1: ecec99d5427b03fe5c390f5fd78274a2a7c625e7
LicenseConcluded: NOASSERTION
LicenseInfoInFile: GPL-3.0-or-later
FileCopyrightText: Copyright (c) 1998-2020 Free Software 
Foundation, Inc.



;)

Which comes from:

This program 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; version 2 of the License, or
   (at your option) any later version.

So once someone determines what's the real license, I guess packages 
could be licensed accordingly ;)


LICENSE_glibc-xxx = "GPLv3+"

is it? Bring in the lawyers.

> WARNING: glibc-2.32-r0 do_package: License for package sln is {'GPL-2.0
> WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
> WARNING: glibc-2.32-r0 do_package: License for package ldconfig is
> {'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
> WARNING: glibc-2.32-r0 do_package: License for package glibc is
> {'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
> WARNING: glibc-2.32-r0 do_package: License for package glibc-staticdev
> is {'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2 & LGPLv2.1
> WARNING: libcap-ng-0.8-r0 do_package: License for package libcap-ng is
> {'GPL-2.0 WITH Linux-syscall-note'} vs GPLv2+ & LGPLv2.1+> WARNING: 
libtirpc-1.2.6-r0 do_package: License for package libtirpc is

> {'GPL-2.0 WITH Linux-syscall-note'} vs BSD-3-Clause
> WARNING: ptest-runner-2.4.0+gitAUTOINC+834670317b-r0 do_package: License
> for package ptest-runner is {'GPL-2.0-or-later'} vs GPLv2+
I assume GPLv2+ is supposed to mean GPL-2.0-or-later.
One fix would be to put in the LICENSE field of ptest-runnner 
GPL-2.0-or-later instead of GPLv2+. Another fix could be to add the 
mapping between GPLv2+ and GPL-2.0-or-later.


> WARNING: libcap-2.44-r0 do_package: License for package libcap is
> {'GPL-2.0 WITH Linux-syscall-note'} vs BSD | GPLv2> WARNING: 
libcap-2.44-r0 do_package: License for package libcap-staticdev

> is {'GPL-2.0 WITH Linux-syscall-note'} vs BSD | GPLv2
> WARNING: openssl-1.1.1h-r0 do_package: License for package
> openssl-engines is {'GPL-2.0 WITH Linux-syscall-note', 'GPL-2.0+ WITH
> Linux-syscall-note'} vs openssl
> > Any suggestions on improvements I can make to this functionality?
>
> Cheers,
> Ida.
Regards,

Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51954): https://lists.yoctoproject.org/g/yocto/message/51954
Mute This Topic: https://lists.yoctoproject.org/mt/79516164/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Error when building eSDK for a `docker load`able tarball

[Robert Berger]

Hi,

And as far as I understand you tried to build some extensible SDK 
against an x86-64 container.


Please note, that my SDK most likely contains a bit more than the 
"standard" stuff[0], but this should not make much of a difference here.


[0] 
https://gitlab.com/meta-layers/meta-resy/-/blob/dunfell/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend


I take a container-x86-64:

bitbake app-container-image-mosquitto-oci [1]

[1] https://pastebin.com/T9hX1H8f

bitbake app-container-image-mosquitto-oci -c populate_sdk [2]

[2] https://pastebin.com/eujc57DG

bitbake app-container-image-mosquitto-oci -c populate_sdk_ext

breaks in a similar way[3]

[3] https://pastebin.com/rV9ewZa9

So it looks like it's extensible SDK specific.

Can you please try with the "standard" sdk instead of the extensible sdk 
to see if this works for you?


You might want to play with IMAGE_CONTAINER_NO_DUMMY = "1" which is 
defined in poky/meta/classes/image-container.bbclass and try to build a 
container with a kernel as a workaround in case you build an eSDK.


Regards,

Robert


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51352): https://lists.yoctoproject.org/g/yocto/message/51352
Mute This Topic: https://lists.yoctoproject.org/mt/78096462/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Multiconfig question

[Robert Berger]

Hi,

Please see my comments in-line

On 07/09/2020 17:53, Eil?s N? Fhlannag?in wrote:

Assuming this:

bitbake multiconfig:ConfigA:core-image-foo multiconfig:ConfigB:core-image-bar

Is there a way during or before the rootfs of ConfigB:core-image-bar
to tell what else was run during execution?

What I'm trying to do is set an mcdepends in ConfigB:core-image-bar to
magically know everything else it was built with.


Does core-image-foo depend on core-image-bar or the other way around?

I have something like that:

mc:imx6q-phytec-mira-rdk-nand-resy-virt:core-image-minimal-virt-docker-ce-telegraf-prebuilt-mc

which depends on

mc:container-arm-v7-resy-container:app-container-image-telegraf-prebuilt-oci

So the container image is being built and put into the rootfs of the 
imx6q image. (without saying this explicitly on the command line).


I use buildinfo for the container rootfs and the native rootfs so I know 
which layers and which settings were used to build them and I can even 
check this in runtime.




-b


Regards,

Robert








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

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

Re: [yocto] how does "bitbake meta-toolchain" map to a particular "image" when generating SDK?

[Robert Berger]

Hi

My comments are in-line

On 05/07/2020 22:24, Robert P. J. Day wrote:


   i'd assumed as much, but is there a reason that the meta-toolchain 
target

is not mentioned at all in the SDK manual? Would that not be the right
place to mention it, even briefly?


I guess it depends on the definition of the SDK vs. just the toolchain.

With a toolchain alone not much can be done. You need a sysroot as well 
to build against.


The SDK is built against some software stack and actually contains more 
headers and libs than what shows up in the image.


SDK is toolchain + sysroot

meta-toolchain buils only the toolchain. You'll need to install the 
sysroot manually somehow.




rday


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

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

Re: [yocto] License reporting for golang (and rust)

[Robert Berger]

Hi,

My comments are in-line

On 30/06/2020 14:37, Irving ST wrote:

Hi,

For anyone else having the same problem, here's what I eventually did
for my go stuff:

I created a bbclass containing a task that gets inherited by all
packages, but the task only does some work when it detects that it is
inherited by a golang recipe.
The task basically sets up GOPATH and calls
https://github.com/rancher/trash - this tool populates all the source
dependencies and generate a trash.lock file in the repository.
Then I used https://github.com/pivotal/LicenseFinder to generate a
json report that can be postprocessed with python.


Is your work available somewhere in the public? I would like to give it 
a try with dunfell 3.1.1 and influxdb.[1] Also it would be interesting 
what happens if you include a prebuilt go executable[2].


[1] 
https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-from-source/github.com-influxdata-influxdb/github.com-influxdata-influxdb_1.8.0.bb 
(from khem and slightly hacked)


[2] 
https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-prebuilt/influxdb/influxdb_1.8.0.bb




To me it seems that Go used the vendor directory approach in the past,
and there are multiple tools that can be used for this; and nowadays
go seems to have switched to a different approach called go modules.


It looks like master and dunfell 3.1.1 support go modules now.[3][4]

[3] 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell=7892a056f7e03e9c086148f8f027bd1cebf2aa68
[4] 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell=ce277ec45f1f241b1eb17ea6999dbe5a718b898a


Now we have both go dep and go modules support ;)


With this multiple tools and methods of managing dependencies, I am
not sure whether it is feasible to integrate this in Yocto at all -
though I think I have seen mailing list posts on meta-virtualization
adding vendor information to their recipes, so maybe some progress is
happening there.


Currently arm 32 Golang support is broken in meta-virt (docker), but I 
am confident it's going to be fixed soon.[5]


[5] 
https://lists.yoctoproject.org/g/meta-virtualization/message/5488?p=,,,20,0,0,0::Created,,docker,20,2,0,75127700




Best regards,
Irving Tjiptowarsono


Regards,

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

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

Re: [yocto] License reporting for golang (and rust)

[Robert Berger]

Hi,

My comments are in-line

On 22/06/2020 11:53, Irving ST wrote:

Hello,

I am building a device that uses some Go (and Rust) dependencies. This
is on Yocto 2.7 / Warrior.

I noticed that after building an image, the generated license.manifest
and package.manifest (in tmp/deploy/licenses/) does not contain any
mention of go packages or rust crates. The go packages seem to
generate directories in tmp/deploy/licenses/ but they do not seem to
be reported in the final image.


On dunfell 3.1.1 I see this:

licenses/
└── github.com-influxdata-influxdb
├── generic_MIT
├── LICENSE
└── recipeinfo

which is wrong, since I would need to add all the licenses of all the 
dependencies golang pulls in as well to the recipe. It's shows only the 
top level license.


In my license manifest I do have the influxdb:

tmp/deploy/licenses/image-influxdb-from-source-container-x86-64-20200629205620/license.manifest

PACKAGE NAME: github.com-influxdata-influxdb
PACKAGE VERSION: 1.8.0
RECIPE NAME: github.com-influxdata-influxdb
LICENSE: MIT

Regards,

Robert



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

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

Re: [yocto] Go toolchain in SDK

[Robert Berger]

On 16/06/2020 23:55, Robert Berger via lists.yoctoproject.org wrote:


bitbake core-image-sato-sdk -c populate_sdk

and currently also for:
bitbake core-image-sato-sdk -c populate_sdk_ext



... and no arm-resy-linux-gnueabi-go on the target, only on the host SDK


I don't think that's the way it was intended.

Can you please enlighten me?

Regards,

Robert





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

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

[yocto] Go toolchain in SDK

[Robert Berger]

Hi,

What is the "proper" way to add the Go toolchain to an SDK nowadays 
(dunfell)?


I saw there is in poky:

./meta/recipes-core/meta/meta-go-toolchain.bb

but I am not quite sure how to build an SDK with meta-go-toolchain included.

so I added something like that to local.conf which seems to work for the 
"classic" SDK:


# --> golang stuff
# attempt to add golang to SDK
TOOLCHAIN_HOST_TASK_append = " \
packagegroup-go-cross-canadian-${MACHINE} \
"

TOOLCHAIN_TARGET_TASK_append = " \
${@multilib_pkg_extend(d, 'packagegroup-go-sdk-target')} \
"
# <-- golang stuff

bitbake core-image-sato-sdk -c populate_sdk

and currently also for:
bitbake core-image-sato-sdk -c populate_sdk_ext

I don't think that's the way it was intended.

Can you please enlighten me?

Regards,

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

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

Re: [yocto] #yocto bootchooser: Cannot get state 'state'

[Robert Berger]

Hi,

Did you install the SDK?

Did you run the environment script?


make: /path/to/your/yocto/toolchain/bin/arm--linux-gnueabihf-gcc: Kommando 
nicht gefunden
   LEX scripts/kconfig/lexer.lex.c
/bin/sh: 1: flex: not found



   YACCscripts/kconfig/parser.tab.h
/bin/sh: 1: bison: not found


flex and bison seem to be missing as well.

Regards,

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

View/Reply Online (#48090): https://lists.yoctoproject.org/g/yocto/message/48090
Mute This Topic: https://lists.yoctoproject.org/mt/69715120/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-