yocto@lists.yoctoproject.org

Re: Dealing with go dependencies in recipes - native docker-compose

Konstantin Kletschke

On Tue, Oct 18, 2022 at 01:39:34PM -0400, Bruce Ashfield wrote:

root@qemux86-64-c9:~# /usr/lib/docker/cli-plugins/docker-compose version

Docker Compose version v2.11.2root@insidem2m:~/docker-nginx-demo# docker compose version
Docker Compose version v2.11.2

I did a test run with a small docker-compose.yml for a nginx hello world demo.
It worked flawlessly, downloading, installing and starting went really
fine.

Perfect, nice work!

Kind Regards
Konstantin




-- 
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@...
http://www.inside-m2m.de 

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover

Re: do_kernel_configme - Could not generate configuration queue

Jeremy Puhlman

#58363

On 10/18/2022 3:31 PM, Bruce Ashfield wrote:

On Tue, Oct 18, 2022 at 5:01 PM Jeremy Puhlman <jpuhlman@...> wrote:

On 10/14/2022 6:52 PM, Bruce Ashfield wrote:

On Fri, Oct 14, 2022 at 10:11 PM Jose Quaresma <quaresma.jose@...> wrote:

Hi Rudolf,

I have reported this issue and together with a path [1] to fix it.

Anyway Bruce has fixed the issue in another way in [2] and this works for me as well.

[1] https://lists.yoctoproject.org/g/linux-yocto/message/11746

[2] https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=6a4752ebbe7d242c02b3c74a5772926edd243626

Yes indeed. This has also passed my other regression testing, but I was traveling today and couldn't send my pull request.

I'll send it over the weekend, so hopefully it'll be merged shortly!

Bruce

Did this end up getting sen to the list? I also validated updating to the specific hash resolved my issue too.

Nope. I got tied up with some other issues, I'll send it tonight when I get a moment!

Bruce

Thanks!

Jose

Rudolf J Streif <rudolf.streif@...> escreveu no dia sábado, 15/10/2022 à(s) 01:45:

I am running into a bizarre problem with kernel configuration.

I have an existing build environment that builds for an i.MX6ul machine.
That works fine and the linux-fslc kernel 5.18 builds without any
problems. Now within the that build environment I changed the machine to
imx6ullevk and then the kernel configuration fails with this error message:

| DEBUG: Executing shell function do_kernel_configme
| NOTE: do_kernel_metadata: for summary/debug, set KCONF_AUDIT_LEVEL > 0
| [ERROR]: processing of file /tmp/tmp.owmBptYrba failed
| /develop/projects/altec/tcu/build/tmp/hosttools/dirname: missing operand
| Try '/develop/projects/altec/tcu/build/tmp/hosttools/dirname --help'
for more information.
| ERROR: Could not generate configuration queue for imx6ullevk.
| WARNING:
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 209
|     #2: do_kernel_metadata,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 382
|     #3: do_kernel_configme,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 150
|     #4: main,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 484
ERROR: Task
(/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
failed with exit code '1'

I tried to debug do_kernel_configme. The issue seems in the scc script
more specifically, I think, in the kconf command that is called by scc
when parsing the temporary configuration queue file in /tmp: tmp.owmBptYrba

#
# spp v0.8
# processed: Fri Oct 14 09:49:02 PM UTC 2022
#
# This is a preprocessor output file, do not edit
#
#
prefix
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
kconf non-hardware
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
# run time: 0 seconds
# processed files:
# _cfg
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig

Apparently a call to dirname is missing the argument. However, I do not
understand why.

I wiped out build/tmp directory entirely, ran a cleanall on
virtual/kernel but to no avail. The problem remains the same.

Has anybody seen this issue before?

Rudi

--

Best regards,

José Quaresma

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
Jeremy A. Puhlman
jpuhlman@...
--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-- 
Jeremy A. Puhlman
jpuhlman@...

Re: do_kernel_configme - Could not generate configuration queue

Rudolf J Streif

#58362

On 10/18/22 15:31, Bruce Ashfield wrote:

On Tue, Oct 18, 2022 at 5:01 PM Jeremy Puhlman <jpuhlman@...> wrote:

On 10/14/2022 6:52 PM, Bruce Ashfield wrote:

On Fri, Oct 14, 2022 at 10:11 PM Jose Quaresma <quaresma.jose@...> wrote:

Hi Rudolf,

I have reported this issue and together with a path [1] to fix it.

Anyway Bruce has fixed the issue in another way in [2] and this works for me as well.

[1] https://lists.yoctoproject.org/g/linux-yocto/message/11746

[2] https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=6a4752ebbe7d242c02b3c74a5772926edd243626

Yes indeed. This has also passed my other regression testing, but I was traveling today and couldn't send my pull request.

I'll send it over the weekend, so hopefully it'll be merged shortly!

Bruce

Did this end up getting sen to the list? I also validated updating to the specific hash resolved my issue too.

Nope. I got tied up with some other issues, I'll send it tonight when I get a moment!

I can confirm that updating kern-tools-native to 6a4752eb resolved the issue for me.

Bruce
Jose

Rudolf J Streif <rudolf.streif@...> escreveu no dia sábado, 15/10/2022 à(s) 01:45:

I am running into a bizarre problem with kernel configuration.

I have an existing build environment that builds for an i.MX6ul machine.
That works fine and the linux-fslc kernel 5.18 builds without any
problems. Now within the that build environment I changed the machine to
imx6ullevk and then the kernel configuration fails with this error message:

| DEBUG: Executing shell function do_kernel_configme
| NOTE: do_kernel_metadata: for summary/debug, set KCONF_AUDIT_LEVEL > 0
| [ERROR]: processing of file /tmp/tmp.owmBptYrba failed
| /develop/projects/altec/tcu/build/tmp/hosttools/dirname: missing operand
| Try '/develop/projects/altec/tcu/build/tmp/hosttools/dirname --help'
for more information.
| ERROR: Could not generate configuration queue for imx6ullevk.
| WARNING:
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 209
|     #2: do_kernel_metadata,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 382
|     #3: do_kernel_configme,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 150
|     #4: main,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 484
ERROR: Task
(/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
failed with exit code '1'

I tried to debug do_kernel_configme. The issue seems in the scc script
more specifically, I think, in the kconf command that is called by scc
when parsing the temporary configuration queue file in /tmp: tmp.owmBptYrba

#
# spp v0.8
# processed: Fri Oct 14 09:49:02 PM UTC 2022
#
# This is a preprocessor output file, do not edit
#
#
prefix
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
kconf non-hardware
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
# run time: 0 seconds
# processed files:
# _cfg
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig

Apparently a call to dirname is missing the argument. However, I do not
understand why.

I wiped out build/tmp directory entirely, ran a cleanall on
virtual/kernel but to no avail. The problem remains the same.

Has anybody seen this issue before?

Rudi

--

Best regards,

José Quaresma

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
Jeremy A. Puhlman
jpuhlman@...
--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-- 
Rudolf J Streif
CEO/CTO
1.855.442.3386

Re: EXTRA_IMAGECMD:squashfs-xz support

Bills, Jason M

#58361

Hello,

Just checking if EXTRA_IMAGECMD:squashfs-xz:append failing to apply is expected or if it should be fixed?

Thanks again,
-Jason

Re: do_kernel_configme - Could not generate configuration queue

Bruce Ashfield

#58360

On Tue, Oct 18, 2022 at 5:01 PM Jeremy Puhlman <jpuhlman@...> wrote:

On 10/14/2022 6:52 PM, Bruce Ashfield wrote:

On Fri, Oct 14, 2022 at 10:11 PM Jose Quaresma <quaresma.jose@...> wrote:

Hi Rudolf,

I have reported this issue and together with a path [1] to fix it.

Anyway Bruce has fixed the issue in another way in [2] and this works for me as well.

[1] https://lists.yoctoproject.org/g/linux-yocto/message/11746

[2] https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=6a4752ebbe7d242c02b3c74a5772926edd243626

Yes indeed. This has also passed my other regression testing, but I was traveling today and couldn't send my pull request.

I'll send it over the weekend, so hopefully it'll be merged shortly!

Bruce

Did this end up getting sen to the list? I also validated updating to the specific hash resolved my issue too.

Nope. I got tied up with some other issues, I'll send it tonight when I get a moment!

Bruce

Jose

Rudolf J Streif <rudolf.streif@...> escreveu no dia sábado, 15/10/2022 à(s) 01:45:

I am running into a bizarre problem with kernel configuration.

I have an existing build environment that builds for an i.MX6ul machine.
That works fine and the linux-fslc kernel 5.18 builds without any
problems. Now within the that build environment I changed the machine to
imx6ullevk and then the kernel configuration fails with this error message:

| DEBUG: Executing shell function do_kernel_configme
| NOTE: do_kernel_metadata: for summary/debug, set KCONF_AUDIT_LEVEL > 0
| [ERROR]: processing of file /tmp/tmp.owmBptYrba failed
| /develop/projects/altec/tcu/build/tmp/hosttools/dirname: missing operand
| Try '/develop/projects/altec/tcu/build/tmp/hosttools/dirname --help'
for more information.
| ERROR: Could not generate configuration queue for imx6ullevk.
| WARNING:
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 209
|     #2: do_kernel_metadata,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 382
|     #3: do_kernel_configme,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 150
|     #4: main,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 484
ERROR: Task
(/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
failed with exit code '1'

I tried to debug do_kernel_configme. The issue seems in the scc script
more specifically, I think, in the kconf command that is called by scc
when parsing the temporary configuration queue file in /tmp: tmp.owmBptYrba

#
# spp v0.8
# processed: Fri Oct 14 09:49:02 PM UTC 2022
#
# This is a preprocessor output file, do not edit
#
#
prefix
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
kconf non-hardware
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
# run time: 0 seconds
# processed files:
# _cfg
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig

Apparently a call to dirname is missing the argument. However, I do not
understand why.

I wiped out build/tmp directory entirely, ran a cleanall on
virtual/kernel but to no avail. The problem remains the same.

Has anybody seen this issue before?

Rudi

--

Best regards,

José Quaresma

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
Jeremy A. Puhlman
jpuhlman@...

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: do_kernel_configme - Could not generate configuration queue

Jeremy Puhlman

#58359

On 10/14/2022 6:52 PM, Bruce Ashfield wrote:

On Fri, Oct 14, 2022 at 10:11 PM Jose Quaresma <quaresma.jose@...> wrote:

Hi Rudolf,

I have reported this issue and together with a path [1] to fix it.

Anyway Bruce has fixed the issue in another way in [2] and this works for me as well.

[1] https://lists.yoctoproject.org/g/linux-yocto/message/11746

[2] https://git.yoctoproject.org/yocto-kernel-tools/commit/?id=6a4752ebbe7d242c02b3c74a5772926edd243626

Yes indeed. This has also passed my other regression testing, but I was traveling today and couldn't send my pull request.

I'll send it over the weekend, so hopefully it'll be merged shortly!

Bruce

Did this end up getting sen to the list? I also validated updating to the specific hash resolved my issue too.

Jose

Rudolf J Streif <rudolf.streif@...> escreveu no dia sábado, 15/10/2022 à(s) 01:45:

I am running into a bizarre problem with kernel configuration.

I have an existing build environment that builds for an i.MX6ul machine.
That works fine and the linux-fslc kernel 5.18 builds without any
problems. Now within the that build environment I changed the machine to
imx6ullevk and then the kernel configuration fails with this error message:

| DEBUG: Executing shell function do_kernel_configme
| NOTE: do_kernel_metadata: for summary/debug, set KCONF_AUDIT_LEVEL > 0
| [ERROR]: processing of file /tmp/tmp.owmBptYrba failed
| /develop/projects/altec/tcu/build/tmp/hosttools/dirname: missing operand
| Try '/develop/projects/altec/tcu/build/tmp/hosttools/dirname --help'
for more information.
| ERROR: Could not generate configuration queue for imx6ullevk.
| WARNING:
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 209
|     #2: do_kernel_metadata,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 382
|     #3: do_kernel_configme,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 150
|     #4: main,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 484
ERROR: Task
(/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
failed with exit code '1'

I tried to debug do_kernel_configme. The issue seems in the scc script
more specifically, I think, in the kconf command that is called by scc
when parsing the temporary configuration queue file in /tmp: tmp.owmBptYrba

#
# spp v0.8
# processed: Fri Oct 14 09:49:02 PM UTC 2022
#
# This is a preprocessor output file, do not edit
#
#
prefix
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
kconf non-hardware
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
# run time: 0 seconds
# processed files:
# _cfg
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig

Apparently a call to dirname is missing the argument. However, I do not
understand why.

I wiped out build/tmp directory entirely, ran a cleanall on
virtual/kernel but to no avail. The problem remains the same.

Has anybody seen this issue before?

Rudi

--

Best regards,

José Quaresma

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-- 
Jeremy A. Puhlman
jpuhlman@...

Re: Dealing with go dependencies in recipes - native docker-compose

Bruce Ashfield

#58358

On Tue, Oct 18, 2022 at 9:17 AM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@...> wrote:

On Tue, Oct 18, 2022 at 6:56 AM Konstantin Kletschke <konstantin.kletschke@...> wrote:
On Sun, Oct 16, 2022 at 10:28:18PM -0400, Bruce Ashfield wrote:

> FYI: Here's the very lightly tested RFC version of the recipe:
>
> https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630

Thanks for the kind notification.

My stuff is based upon kirkstone, I stuffed the recipe from master-next
into my kirkstone build. One package of this new docker-compose is depending
upon go-1.19 (kirkstone provides go-1.17) so I pulled in go-1.19 from
langdale also into my kirkstone build.

The compiling and building works just fine! The recipe(s) for
docker-compose look impressive, I would not have expected them being so
complex. But they work.

The amount of fetches is certainly impressive, but it is like that for any non-vendored go application, whether we can see it or not. When the recipes are simple, all of the fetching and source structuring takes place behind the scenes (I know, I'm stating the obvious), just in a manner we don't control.

I just yank the complexity out to the front, and go directly to the upstream sources of all the go libraries/packages. If we let go fetch it, we have to both rely on the versions being in the fetch locations "forever", or the infrastructure always being available (it should, but you never know). We then have to setup our own go proxy/mirror infrastructure to get around those two issues, and have now become curators of our own repositories and infrastructure. That infrastructure isn't really hard to setup, but in a maintenance mode, updating it, and getting new versions of the code for CVEs, etc, could be challenging.

By doing the fetches directly, all of the established infrastructure, archiving, mirrors, licensing, etc, "just work", and we can bump the SRCREV of any dependency if a CVE or issue is found.

Definitely a balancing act, with no 'one true answer' yet, so I've been going with what I know works :)

Two notes:

After installing the package provides /bin/docker-compose. I realized
other parties provide this as /usr/lib/docker/cli-plugins/docker-compose
which make something like "docker compose version" working. For me this
does not harm, only as remark. May be this is intentional.

Completely random. I just put it there. I'll make that adjustment in the recipe.

Upon investigating I realized the version reported by docker-compose is
"dev" instead of the expected "v2.11.2".

I saw the same thing, and was looking into fixing it, I figured it was worth getting the recipe out, before I did more tweaking.

emux86-64-c9 login: root

root@qemux86-64-c9:~# /usr/lib/docker/cli-plugins/docker-compose version

Docker Compose version v2.11.2

Cheers,

Bruce

Great work, thank you!

I appreciate the testing and the report, very helpful!

Bruce

Regards Konstantin

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Minutes: Yocto Project Weekly Triage Meeting 10/18/2022

sakib.sajal@...

#58357

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Steve Sakoman, Stephen Jolley, Randy Macleod, Joshua Watt, Alexandre Belloni, , Ross Burton, Tim Orling, Alexandre Belloni, Michael Opdenacker

ARs:

N/A

Notes:

Medium+ 4.2 Unassigned Enhancements/Bugs: 45 (Last week 27)

Medium+ 4.99 Unassigned Enhancements/Bugs: 44 (Last week 44)

AB Bugs: 66 (Last week 53)

Yocto Project Status 18 October 2022 (WW42

Neal Caidin

#58356

Current Dev Position: YP 4.1 M4 (In TSC Review)

Next Deadline: 28th October 2022 YP 4.1 Release

Next Team Meetings:

Bug Triage meeting Thursday October 20th 7:30 am PDT (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
Weekly Project Engineering Sync Tuesday October 18th at 8 am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09 )
Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

Richard Purdie is on holiday and expects to return on 24th October.
Patches for master are welcome on the mailing list and will be reviewed/tested, but will not be merged until RP has returned. Our patch wranglers Alex and Luca maintain staging branches at oe-core-contrib/abelloni/master-next and oe-core-contrib/lucaceresoli/master-next if you’d like to see what they’ve tested.
YP 3.1.20 has been released. Thanks Steve!
YP 4.1 rc2 has passed QA and has been provisionally approved for release by the TSC. Release is scheduled for the 28th but may happen earlier if the documentation is finalized.
YP 4.2 Proposed Timeline document is at: https://docs.google.com/document/d/1X5KM_3BiEsIrHBO93ULvYHQJ72NqS5U5jjwWo5bxTiY/edit?usp=sharing
Help is very much welcome in trying to resolve our autobuilder intermittent issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT. In particular there is a long-standing qemuppc failure which needs investigating (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14824)

Ways to contribute:

There are bugs identified as possible for newcomers to the project: https://wiki.yoctoproject.org/wiki/Newcomers
There are bugs that are currently unassigned for YP 4.1. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.1_Unassigned_Enhancements.2FBugs
We’d welcome new maintainers for recipes in OE-Core. Please see the list at: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc and discuss with the existing maintainer, or ask on the OE-Core mailing list. We will likely move a chunk of these to “Unassigned” soon to help facilitate this.
Help us resolve CVE issues: CVE metrics

YP 4.1 Milestone Dates:

YP 4.1 M4 is back from QA and in TSC Review
YP 4.1 M4 Release date 2022/10/28

YP 4.2 Milestone Dates:

YP 4.1 M4 build date 2022/12/05
YP 4.1 M4 Release date 2022/12/16
YP 4.1 M4 build date 2023/01/23
YP 4.1 M4 Release date 2023/02/03
YP 4.1 M4 build date 2023/02/20
YP 4.1 M4 Release date 2023/03/03
YP 4.1 M4 build date 2023/04/03
YP 4.1 M4 Release date 2023/04/28

Upcoming dot releases:

YP 3.1.20 build date 2022/10/31
YP 3.1.20 Release date 2022/10/21
YP 4.0.5 build date 2022/10/31
YP 4.0.5 Release date 2022/11/11
YP 4.1.1 build date 2022/11/14
YP 4.1.1 Release date 2022/11/25
YP 3.1.21 build date 2022/11/28
YP 3.1.21 Release date 2022/12/09
YP 4.0.6 build date 2022/12/12
YP 4.0.6 Release date 2022/12/23
YP 4.1.2 build date 2023/01/09
YP 4.1.2 Release date 2023/01/20
YP 3.1.22 build date 2023/01/16
YP 3.1.22 Release date 2023/01/27
YP 4.0.7 build date 2023/01/30
YP 4.0.7 Release date 2023/02/10
YP 3.1.23 build date 2023/02/13
YP 3.1.23 Release date 2023/02/24
YP 4.0.8 build date 2023/02/27
YP 4.0.8 Release date 2023/03/10
YP 4.1.3 build date 2023/03/06
YP 4.1.3 Release date 2023/03/17
YP 3.1.24 build date 2023/03/20
YP 3.1.24 Release date 2023/03/31
YP 4.0.9 build date 2023/04/10
YP 4.0.9 Release date 2023/04/21
YP 4.1.4 build date 2023/05/01
YP 4.1.4 Release date 2023/05/13
YP 3.1.25 build date 2023/05/08
YP 3.1.25 Release date 2023/05/19
YP 4.0.10 build date 2023/05/15
YP 4.0.10 Release date 2023/05/26

Tracking Metrics:

WDD 2459 (last week 2409) (https://wiki.yoctoproject.org/charts/combo.html)
OE-Core/Poky Patch Metrics

Total patches found: 1217 (last week 1217)
Patches in the Pending State: 311 (26%) [last week 311 (26%)]

https://autobuilder.yocto.io/pub/non-release/patchmetrics/

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!]

Neal Caidin

Program Manager, Program Management & Operations

The Linux Foundation

+1 (919) 238-9104 (w/h)
+1 (919) 949-1861 (m)

ncaidin@...

Re: Dealing with go dependencies in recipes - native docker-compose

Bruce Ashfield

#58355

On Tue, Oct 18, 2022 at 6:56 AM Konstantin Kletschke <konstantin.kletschke@...> wrote:

On Sun, Oct 16, 2022 at 10:28:18PM -0400, Bruce Ashfield wrote:

> FYI: Here's the very lightly tested RFC version of the recipe:
>
> https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630

Thanks for the kind notification.

My stuff is based upon kirkstone, I stuffed the recipe from master-next
into my kirkstone build. One package of this new docker-compose is depending
upon go-1.19 (kirkstone provides go-1.17) so I pulled in go-1.19 from
langdale also into my kirkstone build.

The compiling and building works just fine! The recipe(s) for
docker-compose look impressive, I would not have expected them being so
complex. But they work.

The amount of fetches is certainly impressive, but it is like that for any non-vendored go application, whether we can see it or not. When the recipes are simple, all of the fetching and source structuring takes place behind the scenes (I know, I'm stating the obvious), just in a manner we don't control.

I just yank the complexity out to the front, and go directly to the upstream sources of all the go libraries/packages. If we let go fetch it, we have to both rely on the versions being in the fetch locations "forever", or the infrastructure always being available (it should, but you never know). We then have to setup our own go proxy/mirror infrastructure to get around those two issues, and have now become curators of our own repositories and infrastructure. That infrastructure isn't really hard to setup, but in a maintenance mode, updating it, and getting new versions of the code for CVEs, etc, could be challenging.

By doing the fetches directly, all of the established infrastructure, archiving, mirrors, licensing, etc, "just work", and we can bump the SRCREV of any dependency if a CVE or issue is found.

Definitely a balancing act, with no 'one true answer' yet, so I've been going with what I know works :)

Two notes:

After installing the package provides /bin/docker-compose. I realized
other parties provide this as /usr/lib/docker/cli-plugins/docker-compose
which make something like "docker compose version" working. For me this
does not harm, only as remark. May be this is intentional.

Completely random. I just put it there. I'll make that adjustment in the recipe.

Upon investigating I realized the version reported by docker-compose is
"dev" instead of the expected "v2.11.2".

I saw the same thing, and was looking into fixing it, I figured it was worth getting the recipe out, before I did more tweaking.

Great work, thank you!

I appreciate the testing and the report, very helpful!

Bruce

Regards Konstantin

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: Dealing with go dependencies in recipes - native docker-compose

Konstantin Kletschke

#58354

On Sun, Oct 16, 2022 at 10:28:18PM -0400, Bruce Ashfield wrote:

FYI: Here's the very lightly tested RFC version of the recipe:

https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630Thanks for the kind notification.

My stuff is based upon kirkstone, I stuffed the recipe from master-next
into my kirkstone build. One package of this new docker-compose is depending
upon go-1.19 (kirkstone provides go-1.17) so I pulled in go-1.19 from
langdale also into my kirkstone build.

The compiling and building works just fine! The recipe(s) for
docker-compose look impressive, I would not have expected them being so
complex. But they work.

Two notes:

After installing the package provides /bin/docker-compose. I realized
other parties provide this as /usr/lib/docker/cli-plugins/docker-compose
which make something like "docker compose version" working. For me this
does not harm, only as remark. May be this is intentional.

Upon investigating I realized the version reported by docker-compose is
"dev" instead of the expected "v2.11.2".

Great work, thank you!

Regards Konstantin

[ANNOUNCEMENT] Yocto Project 3.1.20 (dunfell-23.0.20) is Released

Lee Chee Yang

#58353

Hi

We are pleased to announce the Yocto Project 3.1.20 (dunfell-23.0.20) Release is now available for download.

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/poky-dunfell-23.0.20.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.20/poky-dunfell-23.0.20.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/testreport.txt

Thank you for everyone's contributions to this release.

Chee Yang Lee chee.yang.lee@...

Yocto Project Build and Release

- --------------------------

yocto-3.1.20 Release Notes

- --------------------------

Repositories/Downloads

- --------------------------

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.20

Git Revision: 7f9b7f912e13451a4cd03b10a8090a5def68dc39

Release Artefact: poky-dunfell-23.0.20

sha: 98ac09e728f27c493fa7022cb0ef01352680c1b2771a9f6320d1b8060f0e0590

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/poky-dunfell-23.0.20.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.20/poky-dunfell-23.0.20.tar.bz2

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: yocto-3.1.20

Git Revision: dbad46a0079843b380cf3dda6008b12ab9526688

Release Artefact: oecore-dunfell-23.0.20

sha: 2bb87a293d3956da648419c313021a883fc9359753d5a662f11327a0d9318ede

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/oecore-dunfell-23.0.20.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.20/oecore-dunfell-23.0.20.tar.bz2

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.20

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.20

sha: 1a90800d7a30c18048ad4699faa9d3e77d973826f363d42902e53356129616bc

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/meta-mingw-dunfell-23.0.20.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.20/meta-mingw-dunfell-23.0.20.tar.bz2

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.20

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.20

sha: 301b761c85af6f263922dfa2e91b7c15dd99d4f46bbfe0854c6dc9cc3e3f8aeb

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/meta-gplv2-dunfell-23.0.20.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.20/meta-gplv2-dunfell-23.0.20.tar.bz2

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: dunfell

Tag: yocto-3.1.20

Git Revision: 048d682b031644fb9f0d41a489bacb873aa27bd7

Release Artefact: bitbake-dunfell-23.0.20

sha: 11deb2f5ab15f83abf6d8851c77a91cf66f1f07b00b3dda5e12fcde100343692

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.20/bitbake-dunfell-23.0.20.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.20/bitbake-dunfell-23.0.20.tar.bz2

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.20

Git Revision: 2359aff814f5faccffbf3cb2cd180979c248fc3c

- ---------------

Known Issues

- ---------------

N/A

- ---------------

Security Fixes

- ---------------

bind: Fix CVE-2022-2795 CVE-2022-38177 CVE-2022-38178

binutils : CVE-2022-38533

bluez: CVE-2022-39176

connman: fix CVE-2022-32292 CVE-2022-32293

curl: fix CVE-2022-35252

expat: Fix CVE-2022-40674

gnutls: fix CVE-2021-4209

golang: ignore CVE-2022-29526 CVE-2022-30634

golang: fix CVE-2021-27918 CVE-2021-36221 CVE-2021-39293 CVE-2021-41771 CVE-2022-30629 CVE-2022-30631 CVE-2022-30632 CVE-2022-30633 CVE-2022-30635 CVE-2022-32148 CVE-2022-32189 CVE-2022-32190 CVE-2022-27664

gst-plugins-good: fix CVE-2022-1920 CVE-2022-1921 CVE-2022-1922 CVE-2022-1923 CVE-2022-1924 CVE-2022-1925 CVE-2022-2122

inetutils: Fix CVE-2022-39028

libarchive: Fix CVE-2021-31566 CVE-2021-23177

libtiff: Fix CVE-2022-34526

libxml2: fix for CVE-2016-3709

python3: Fix CVE-2021-28861

qemu: fix CVE-2020-13754 CVE-2021-3713 CVE-2021-3748 CVE-2021-3930 CVE-2021-4206 CVE-2021-4207 CVE-2022-0216

qemu: ignore CVE-2020-27661

sqlite3: Fix CVE-2020-35525 CVE-2020-35527 CVE-2021-20223 CVE-2022-35737

subversion: fix CVE-2021-28544

tiff: fix CVE-2022-1354 CVE-2022-1355 CVE-2022-2867 CVE-2022-2868 CVE-2022-2869

virglrenderer: fix CVE-2022-0135

- ---------------

Fixes

- ---------------

bitbake: bitbake: runqueue: add cpu/io pressure regulation

bitbake: bitbake: runqueue: add memory pressure regulation

bitbake: runqueue: Change pressure file warning to a note

bitbake: utils: Pass lock argument in fileslocked

build-appliance-image: Update to dunfell head revision

classes: cve-check: Get shared database lock

create-pull-request: don't switch the git remote protocol to git://

cryptodev-module: fix build with 5.11+ kernels

cve-check: Don't use f-strings

cve-check: close cursors as soon as possible

documentation: update for 3.1.20

licenses: Handle newer SPDX license names

linux-firmware: package new Qualcomm firmware

linux-firmware: upgrade 20220708 -> 20220913

linux-yocto/5.4: update genericx86* machines to v5.4.205

linux-yocto/5.4: update to v5.4.213

mobile-broadband-provider-info: upgrade to 20220725

poky.conf: bump version for 3.1.20 release

qemu: Add PACKAGECONFIG for brlapi

qemu: Define libnfs PACKAGECONFIG

ref-manual: add numa to machine features

relocate_sdk.py: ensure interpreter size error causes relocation to fail

systemd: Add 'no-dns-fallback' PACKAGECONFIG option

systemd: Fix unwritable /var/lock when no sysvinit handling

tzdata: Update to 2022c

vim: Upgrade to 9.0.0598

wireless-regdb: upgrade to 2022.08.12

Yocto Project Summit: 2011.11

Armin Kuster

#58352

Hello,

This is a reminder that the Yocto Project Summit is scheduled for November 29th to December. Registration is open.

The CFP still open and will close in 12 days from now on Oct 28th.

For more information see: https://www.yoctoproject.org/yocto-project-summit-2022-11/

regards,
Armin

M+ & H bugs with Milestone Movements WW42

Stephen Jolley

#58351

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
Medium+	5322	Global DNS fallback mechanism not present in poky distro	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	5389	bitbake/lib/bb/fetch2: filename too long	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	5876	Add a test for the kernel -c menuconfig option	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	10061	Ctrl+C during BB_HASHCHECK_FUNCTION execution does not interrupt processing nicely	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	10693	Add a testcase for multilib eSDK on the autobuilder	randy.macleod@...	Qi.Chen@...	4.1 M2	4.2 M1
	11704	Add other resource monitoring options to conf/local.conf STOPTASKS/ABORT	randy.macleod@...	randy.macleod@...	4.1 M3	4.2 M2
	12060	It is possible to specify a PACKAGE and a PKG_ rename that conflict	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	12279	enhance manifest not found warning	randy.macleod@...	randy.macleod@...	4.1 M4	4.2 M1
	12290	cross recipe kernel module dependency generation stopped working	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	12342	lib32-core-image-sato -ctestimage failed due to wrong package names	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	12374	do_rootfs failed when len(TMPDIR) == 410	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	12760	CMake Toolchain File Has Wrong Module Path	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	12963	nativesdk-opkg prefixes all internal paths with $SDKPATH and won't work	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13004	Automate yocto-check-layer -m option	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13123	package.PackageTests.test_gdb_hardlink_debug failed	randy.macleod@...	randy.macleod@...	4.1 M4	4.2 M1
	13236	sstate for host native packages	randy.macleod@...	unassigned@...	4.1 M2	4.2 M1
	13279	Make sure users/groups exist for package_write_* tasks	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13285	YoctoProject Compatibility script improvements needed	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13298	python3 ptest results are inconsistent per image	randy.macleod@...	randy.macleod@...	4.1 M2	4.2 M1
	13311	xargs: fdleak.c:396: complain_about_leaky_fds: Assertion `no_leaks' failed.	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13338	SDK build fails if image contains bash	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13419	recipes that add users to groups cannot rely on other recipes creating those groups (when population from sstate happens)	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13425	Add bblock and bbunlock helper tools	randy.macleod@...	newcomer@...	4.1 M2	4.2 M1
	13520	many valgrind tests fail for arm64	randy.macleod@...	randy.macleod@...	4.1 M3	4.2 M1
	13508	Meson detects googletest installed on system	randy.macleod@...	newcomer@...	4.1 M2	4.2 M1
	13533	Devtool finish on _git package with SRCPV in PV points to wrong WORKDIR	randy.macleod@...	saul.wold@...	4.1 M2	4.2 M2
	13550	username/password specified to gitsm:// does not get propagated to submodules	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13674	master dnf failures on qemumips	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13843	bitbake worker stuck using 100% cpu on aborted build	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13868	Python cache files get lost in packages	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13889	python3 Windows distutils stubs regressed in upgrade to 3.8.2	randy.macleod@...	unassigned@...	4.1 M4	4.2 M1
	13910	Intermittent host UID contamination highlighted by devtool tests	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13919	Multi License GPLv3 -lic cannot be installed into the image because it has incompatible license	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	13920	uninative tarball license compliance in ESDK	randy.macleod@...	unassigned@...	4.1 M3	4.2 M2
	14015	URL Arguments in MIRROR/PREMIRROR get encoded	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14020	environment-setup script in multilib eSDK doesn't work for multilib variant	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14126	resolvconf incompatible with busybox flock	randy.macleod@...	newcomer@...	4.1 M2	4.2 M1
	14139	systemd user/groups different on opkg vs rpm images	randy.macleod@...	hongxu.jia@...	4.1 M2	4.2 M1
	14141	devtool modify fails with submodules	randy.macleod@...	sgw@...	4.1 M2	4.2 M2
	14157	git fetcher: consider using different git commands for repo packing, eliminating "git pack-redundant"	randy.macleod@...	newcomer@...	4.1 M2	4.2 M1
	14218	Recipe rebuilds can contaminate builds	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14236	npmsw does not support github URLs in the npm-shrinkwrap.json file	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14303	Result of build is not stored in testresult.json with resulttool	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14383	archiver.bbclass:do_ar_mirror copies entire contents of ${DL_DIR} to ${WORKDIR} when used with npm.bbclass	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14462	devtool sdk-update does not update sstate-cache	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14466	python: Should we add this optimization: -fno-semantic-interposition for 1.3x speed improvment?	randy.macleod@...	randy.macleod@...	4.1 M3	4.2 M1
	14523	oe-pkgdata-util list-pkg-files doesn't ignore target-sdk-provides-dummy.bb	randy.macleod@...	Zheng.Qiu@...	4.1 M3	4.2 M1
	14528	remove floppy controller from qemu	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14642	Yocto-check-layer add patch Upstream-Status check	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14640	Relocation error when setting up SDK with rust tools	randy.macleod@...	pgowda.cve@...	4.1 M2	4.2 M1
	14693	cmake-native do_configure fails when rebuilding without sstate on NIS hosts	randy.macleod@...	randy.macleod@...	4.1 M3	4.2 M1
	14710	Improve cargo fetcher test cases	randy.macleod@...	randy.macleod@...	4.1 M3	4.2 M2
	14836	Resolvconf missing normalize-resolvconf file since it is moved to a separate file since version 1.90	randy.macleod@...	qorin.qorinna@...	4.1 M2	4.2 M1
	14860	Cannot build x86-64 Go SDK on aarch64	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14866	testsdk logs missing information	randy.macleod@...	unassigned@...	4.1 M3	4.2 M1
	14875	reproducibility failures in rust	randy.macleod@...	sundeep.kokkonda@...	4.1 M3	4.2 M1

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Enhancements/Bugs closed WW42!

Stephen Jolley

#58350

All,

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

Who	Count
ross.burton@...	3
randy.macleod@...	3
Grand Total	6

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley

#58349

All,

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 419 unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “4.1”, “4.2”, “4.3”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Re: core-image-minimal-xfce: Xorg screen remains black

Thomas Perrot

#58348

Hello Manuel,

The regression is linked to the update of the libx11 from 1.8.0 to
1.8.1.
While waiting for a fix you can revert the commit that updates libx11
(7918a25736a7).

Kind regards,
Thomas

Show quoted text

On Thu, 2022-10-06 at 23:31 +0200, Manuel Wagesreither wrote:
I realized `core-image-minimal-xfce.bb` adds `packagegroup-core-x11`
to IMAGE_INSTALL.
Yet, 
* It doesn't add `x11` to IMAGE_FEATURES which would do the same but
perhaps a bit more.
* It doesn't add `x11-base` to IMAGE_FEATURES, which would add
`packagegroup-core-x11-base` to IMAGE_INSTALL and perhaps a bit more.

Hence I added `x11` and `x11-base` to IMAGE_FEATURES and it changed
things in so far as when the flickering occurs, the black screen
changes into a gray screen.

Regards,
Manuel

-- 
Thomas Perrot, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

signature.asc

Re: Dealing with go dependencies in recipes - native docker-compose

Bruce Ashfield

#58347

On Thu, Oct 13, 2022 at 10:05 AM Konstantin Kletschke <konstantin.kletschke@...> wrote:

On Tue, Oct 11, 2022 at 11:23:31PM -0300, Bruce Ashfield wrote:

> Adding the missing setuptools does get things working.

Oh my, I was still looking for python3-distutils (deprecated, not
available) and did not realize I now need setuptools. Thanks for
clarifying, however, I investigated the gao approach then...

> I actually have a prototype recipe for this that I was working on before
> ELCe, but I didn't get it into meta-virtualization yet, as it had a few
> rough edges.

I suppose, those go recipes look extremly difficult to do.

> If you give me a few days, I can post it to the meta-virtualization list,
> but I'm on the road right now and don't have access to all my build
> machines.

Of course I have patience and I am very curious to test this out!
Currently I have no urge but in future it will be extremely handy to
have the native docker compose approach available. It is a bit smaller
then the python approach (if python is only used by this docker-compose,
a third disk space is used by native approach).

> I also did a presentation at the yocto summit about "modern languages".

Opps, interesting. No need to summarize here, I agree. I will dig this
up in the internet. Interesting...

> You can see the approach that I take for this in the k3s and nerdctl recipes
> in meta-virtualization. My new docker-compose recipe is of similar format.

As I vaguely mentioned above, those recipes look far more complex than I
would have imagined when starting to dig into the go world...
astonishing!

FYI: Here's the very lightly tested RFC version of the recipe:

https://git.yoctoproject.org/meta-virtualization/commit/?h=master-next&id=fa24cfc08b129de5c7ba36099985359cc0228630

Cheers,

Bruce

> If we just bypass the fetcher, offline builds, some of licensing and SBOM
> and reproducible builds .. you can have a simple recipe like that as well :)

Yea, and I already learned to lovae this reproducibility approach.

--
INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@...
http://www.inside-m2m.de

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover

--

- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: Fixing [host-user-contaminated] warning

Umut Ediz

#58346

I also tried chown but I am getting permission errors. But I thought this should not be the case since these commands are running under fake root… But I found out this is not the case since these operations running in a custom task rather than do_install so fakeroot usage should be explicit, afaik. I tried to add fakeroot prefix to the related function and updated the task dependency but still I get permission errors.

Show quoted text

On 16 Oct 2022, at 22:51, Martin Jansa <martin.jansa@...> wrote:

You can also chown the files after unpacking them (like in https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442)

On Sun, Oct 16, 2022 at 9:13 PM <umut@...> wrote:
Hi,
I am working on a project that uses some proprietary layers from a 3rd party. These layers provide tar archives that include prebuilt binaries of some packages and these archives cause host-user-contaminated warnings. Since I only have the root user in my target system, and since I changed the UID/GID of my build user I assume it is not a false-positive. So, I dug a bit to find and resolve the issue and find the function that installs binaries. The function only extracts a tar archive to the ${D} directory with the command below, nothing else. No fakeroot, no management of ownership/permissions.

tar -xjvf $prebuiltdir/${TARGET}/${PN}/${PN}-binaries.tar -C ${D}
I tried various options of tar to extract these files with different UID and GID with no success.
How can I solve this issue? I think it would be better if I patch the script to use the install command but I am not sure how can I integrate that kind of workflow with lots of tar archives that includes lots of subdirectories.

P.S. : I use an LXC-based non-privileged ubuntu container in Proxmox VE as the build host. I don't know if it may affect something but wanted to mention it just in case.

Best regards,
Umut Ediz

Re: Error during linux booting

Zoran

#58345

Interesting... Looking into the log massage itself!

[    0.000000] Kernel command line: root=/dev/vda2 rootwait console=ttyS0 earlycon=uart8250,mmio,0x10000000Command line does not specify baud rate... Usually by default it is
115200. Just a kludge.

Then:

[    0.000000] earlycon: uart8250 at MMIO 0x0000000010000000 (options '')
[    0.000000] printk: bootconsole [uart8250] enabledbootconsole enabled, seems correct.

Then:

[    1.628806] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.648238] printk: console [ttyS0] disabled
[    1.652252] 10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 166, base_baud = 230400) is a 16550A
[    1.656816] printk: console [ttyS0] enabled
[    1.656816] printk: console [ttyS0] enabled
[    1.657728] printk: bootconsole [uart8250] disabled
[    1.657728] printk: bootconsole [uart8250] disabledFrom what we see that the base baud rate is 230400 (?), everything
else is, seems, correct.

So, three things, which came adhoc to my mind:
[1] Please, check the baud rate;
[2] Please, check to which group /dev/ttyS0 belongs (root dialout)?
[3] The terminal should be interactive, but no way to check this (from
the logs)???

My two cent worth answer,
Zee
_______

On Sun, Oct 16, 2022 at 8:32 PM Vaibhav Deshpande
<vdeshpande@...> wrote:

Hello

I am trying to build a yocto image from the kirkstone branch (https://github.com/openembedded/openembedded-core/tree/kirkstone) build gets successful but at the time of linux booting I am getting below error....[snap]...