On 20/03/2023 08:53:56-0400, Bruce Ashfield wrote:

On Sun, Mar 19, 2023 at 3:39 PM Alexandre Belloni
<alexandre.belloni@...> wrote:

Hi Bruce,

check-layer-nightly is failing for meta-virt:

ERROR: Nothing RPROVIDES '${VIRTUAL-RUNTIME_container_networking}' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/podman/podman_git.bb RDEPENDS on or otherwise requires it)

Aha. These recipes need the defaults that are supplied when the
virtualization distro feature is specified.

What is the exact command the nightly check is running ? I can't locate it here.

The command is:
yocto-check-layer-wrapper ../meta-virtualization --dependency ../meta-openembedded/meta-oe ../meta-openembedded/meta-networking ../meta-openembedded/meta-python ../meta-openembedded/meta-filesystems --no-auto-dependency

This is this line:
https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n953

I'll add a skip recipe on the users of those namespaces if
virtualization isn't enabled and/or set a basic default.

Bruce

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On Sun, Mar 19, 2023 at 3:39 PM Alexandre Belloni
<alexandre.belloni@...> wrote:

Hi Bruce,

check-layer-nightly is failing for meta-virt:

ERROR: Nothing RPROVIDES '${VIRTUAL-RUNTIME_container_networking}' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/podman/podman_git.bb RDEPENDS on or otherwise requires it)

Aha. These recipes need the defaults that are supplied when the
virtualization distro feature is specified.

What is the exact command the nightly check is running ? I can't locate it here.

I'll add a skip recipe on the users of those namespaces if
virtualization isn't enabled and/or set a basic default.

Bruce

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

On 19/03/2023 20:39:36+0100, Alexandre Belloni wrote:

Hi Bruce,

check-layer-nightly is failing for meta-virt:

ERROR: Nothing RPROVIDES '${VIRTUAL-RUNTIME_container_networking}' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/podman/podman_git.bb RDEPENDS on or otherwise requires it)

I missed this one:

ERROR: Nothing RPROVIDES '${VIRTUAL-RUNTIME_container_runtime}' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/cri-o/cri-o_git.bb, /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/podman/podman_git.bb, /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/containerd/containerd-opencontainers_git.bb, /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/docker/docker-ce_git.bb RDEPENDS on or otherwise requires it)


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi Bruce,

check-layer-nightly is failing for meta-virt:

ERROR: Nothing RPROVIDES '${VIRTUAL-RUNTIME_container_networking}' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-virtualization/recipes-containers/podman/podman_git.bb RDEPENDS on or otherwise requires it)


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hello,

We still see this failure on kirkstone:

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1205/steps/11/logs/stdio

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

I noticed Alexandre's build on fedora36-ty-3 was hanging in oe-selftest:

https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/4815

Looking at the bitbake-cookerdaemon.log, we see:

to-worker/oe-selftest-fedora/build/build-st-1756321', 'OLDPWD': '/home/pokybuild/yocto-worker/oe-selftest-fedora/build'}, ['/home/pokybuild/yocto-worker/oe-selfte
st-fedora/build/bitbake/bin/bitbake', '-e']]
1758267 15:58:48.269660 Command Completed (socket: True)
1758267 15:58:48.269853 Running command ['getVariable', 'BBINCLUDELOGS']
Exception in thread Thread-1 (idle_thread):
Traceback (most recent call last):
File "/usr/lib64/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/usr/lib64/python3.10/threading.py", line 953, in run
self._target(*self._args, **self._kwargs)
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 408, in idle_thread
self.cooker.process_inotify_updates()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/cooker.py", line 256, in process_inotify_updates
n.read_events()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/pyinotify.py", line 1207, in read_events
if fcntl.ioctl(self._fd, termios.FIONREAD, buf_, 1) == -1:
OSError: [Errno 9] Bad file descriptor
1758267 15:58:48.694198 Command Completed (socket: True)
1758267 15:58:48.694547 Running command ['getVariable', 'BBINCLUDELOGS_LINES']
1758267 15:58:48.694993 Command Completed (socket: True)
1758267 15:58:48.695184 Running command ['getSetVariable', 'BB_CONSOLELOG']

and then pings are keeping things alive but it looks like the idle thread has crashed. I saved the log into ~/saved.

(gdb) py-bt
Traceback (most recent call first):
<built-in method select of module object at remote 0x7fa4fe92dad0>
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 481, in idle_commands
return select.select(fds,[],[],nextsleep)[0]
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 318, in main
ready = self.idle_commands(.1, fds)
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 153, in run
ret = self.main()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 655, in execServer
server.run()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/bin/bitbake-server", line 54, in <module>
bb.server.process.execServer(lockfd, readypipeinfd, lockname, sockname, timeout, xmlrpcinterface, profile)
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7fa4ff411740 (LWP 1758267) "Cooker" 0x00007fa4fed0841c in select () from /lib64/libc.so.6

which shows the idle thread is missing due to the exception. I'll kill
the remaining process since it will never get anywhere.

Cheers,

Richard

There's a new DEPENDS on grpc added to agl-shell-activator in meta-agl-core:

https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=commitdiff;h=774ac9f796b684068b08de202e1eb82d3f18d212

grpc comes from meta-oe, but meta-agl-core doesn't depend on meta-oe.

--
Denys

Thanks for the report.

Short term workaround:
PACKAGECONFIG[grpc-proxy] = "-Dgrpc-proxy=true,-Dgrpc-proxy=false"


We'll upload a fix shortly.

Best,
JS




Am Donnerstag, 16. Februar 2023, 10:36:28 CET schrieb Alexandre Belloni:

Hello,

meta-agl failed check-layer-nightly with:

ERROR: Nothing PROVIDES 'grpc' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-agl/meta-agl-core/recipes-graphics/wayland/agl-shell-activator_git.bb, /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-agl/meta-agl-core/recipes-graphics/wayland/agl-compositor_git.bb DEPENDS on or otherwise requires it). Close matches:
ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1185

We also had:

ERROR: Nothing PROVIDES 'grpc-native' (but /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-agl/meta-agl-core/recipes-graphics/wayland/agl-compositor_git.bb, /home/pokybuild/yocto-worker/check-layer-nightly/build/meta-agl/meta-agl-core/recipes-graphics/wayland/agl-shell-activator_git.bb DEPENDS on or otherwise requires it). Close matches:
ERROR: Required build target 'meta-world-pkgdata' has no buildable providers.

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1179/steps/11/logs/errors

--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hello,

meta-agl failed check-layer-nightly with:

ERROR: No recipes in default available for:
/home/pokybuild/yocto-worker/check-layer-nightly/build/meta-agl/meta-agl-core/recipes-graphics/wayland/weston_11.0.%.bbappend

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1062/steps/11/logs/stdio

This is because oe-core langdale doesn't have weston_11, master has.

This was the configuration you gave:
AB master -> meta-agl next
AB langdale -> meta-agl next # our -next branch is of 'master'
AB kirkstone -> meta-agl master # our master tracks the LTS of YP
AB dunfell -> meta-agl lamprey


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi Alexandre,

builds do on the AB. This is how things map out:

AB master -> meta-agl next
AB langdale -> meta-agl next # our -next branch is of 'master'
AB kirkstone -> meta-agl master # our master tracks the LTS of
YP AB dunfell -> meta-agl lamprey

So thats our decoder ring.

Essentially our master will track LTS till the next LTS is out.
We do a -next to enable upstream testing in the AB for anything thats
newer
than the LTS. Now upstream 'master' makes sense as we can help fix things
right away. We could question if langdale makes sense as we would never
switch to it. Might safe the cycles.

Let me know what you think.

Well, I think this goes against the principle of least astonishment and
is quite convoluted. I don't feel this is normal that the only three
commits after introducing langdale on the autobuilders are to fix the
meat-agl branches.

Sorry to hear that that, but we did not intent to be troublemakers ;) for
sure. This is a learning curve I suppose on both sides as we do uprev's on
different timelines while we track the LTS branches.

Best,
Jan-Simon

Hello,

On 08/12/2022 01:28:54+0100, Jan-Simon Moeller wrote:

Hi Alexandre,

hmm, I think there's some confusion. Let me try to clarify:

For https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1049
-> Build Properties
branch (yocto) -> "langdale"
branch_meta-agl -> "master" ## that is wrong, it should be meta-agl-next

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1047
-> Build Properties
branch (yocto) -> "dunfell"
branch_meta-agl -> "next" ## that is (meanwhile) no longer true

I think we just point to the wrong branches meanwhile.

We sorted that out with Steve 3 weeks ago and came up with this::

I'm guessing that means the langdale AB test builds are using meta-agl's
master branch? They should be using the "next" branch like the master
builds do on the AB. This is how things map out:

AB master -> meta-agl next
AB langdale -> meta-agl next # our -next branch is of 'master'
AB kirkstone -> meta-agl master # our master tracks the LTS of YP
AB dunfell -> meta-agl lamprey

So thats our decoder ring.

Essentially our master will track LTS till the next LTS is out.
We do a -next to enable upstream testing in the AB for anything thats newer
than the LTS. Now upstream 'master' makes sense as we can help fix things right
away. We could question if langdale makes sense as we would never switch to
it. Might safe the cycles.

Let me know what you think.

Well, I think this goes against the principle of least astonishment and
is quite convoluted. I don't feel this is normal that the only three
commits after introducing langdale on the autobuilders are to fix the
meat-agl branches.

Anyway, I've sent a patch to fix it.


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi Alexandre,

hmm, I think there's some confusion. Let me try to clarify:

For https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1049
-> Build Properties
branch (yocto) -> "langdale"
branch_meta-agl -> "master" ## that is wrong, it should be meta-agl-next

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1047
-> Build Properties
branch (yocto) -> "dunfell"
branch_meta-agl -> "next" ## that is (meanwhile) no longer true

I think we just point to the wrong branches meanwhile.

We sorted that out with Steve 3 weeks ago and came up with this::

I'm guessing that means the langdale AB test builds are using meta-agl's
master branch? They should be using the "next" branch like the master
builds do on the AB. This is how things map out:

AB master -> meta-agl next
AB langdale -> meta-agl next # our -next branch is of 'master'
AB kirkstone -> meta-agl master # our master tracks the LTS of YP
AB dunfell -> meta-agl lamprey

So thats our decoder ring.

Essentially our master will track LTS till the next LTS is out.
We do a -next to enable upstream testing in the AB for anything thats newer
than the LTS. Now upstream 'master' makes sense as we can help fix things right
away. We could question if langdale makes sense as we would never switch to
it. Might safe the cycles.

Let me know what you think.

Best regards,
Jan-Simon

Am Mittwoch, 7. Dezember 2022, 23:53:59 CET schrieb Scott Murray:

Our next branch seems to have been rebased/pushed to an old version last
night, Jan-Simon and I will try to figure out what happened. I can push
the previous state that I have, but I want to make sure it's not going to
get clobbered again if there's something automated involved.
'
Scott


On Thu, Dec 8, 2022 at 1:47 AM Alexandre Belloni <

alexandre.belloni@...> wrote:

Hello,

meta-agl is still failing check-layer-nightly on langdale builds because
of meta-pipewire:

ERROR: Layer meta-pipewire is not compatible with the core layer which
only supports these series: langdale (layer is compatible with kirkstone)


https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1049/st
eps/12/logs/stdio


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On Thu, Dec 08, 2022 at 08:14:38AM +0900, Scott Murray wrote:

Okay, Jan-Simon is more awake than I am, and points out that our next
branch is where it should be. We do have a commit that adds langdale to
LAYERSERIES_COMPAT for all the layers in meta-agl, so we'll have to
investigate why yocto-check-layer thinks otherwise and get back to you.

As Scott points out, meta-agl uses "next" branch to track upstream master
development, i.e. langdale and later. As meta-agl "master" branch is kept
compatible with the latest LTS, namely kirkstone.

--
Denys

On Thu, Dec 8, 2022 at 7:53 AM Scott Murray <scott.murray@...>
wrote:

Our next branch seems to have been rebased/pushed to an old version last
night, Jan-Simon and I will try to figure out what happened. I can push
the previous state that I have, but I want to make sure it's not going to
get clobbered again if there's something automated involved.

Scott


On Thu, Dec 8, 2022 at 1:47 AM Alexandre Belloni <
alexandre.belloni@...> wrote:

Hello,

meta-agl is still failing check-layer-nightly on langdale builds because
of meta-pipewire:

ERROR: Layer meta-pipewire is not compatible with the core layer which
only supports these series: langdale (layer is compatible with kirkstone)


https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1049/steps/12/logs/stdio

Hello,

meta-agl is still failing check-layer-nightly on langdale builds because
of meta-pipewire:

ERROR: Layer meta-pipewire is not compatible with the core layer which only supports these series: langdale (layer is compatible with kirkstone)

https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/1049/steps/12/logs/stdio


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hello,

python3-colorama has been upgraded once again and we now have a
check-layer-nightly failure.

AssertionError: Adding layer meta-virtualization changed signatures.
23 signatures changed, initial differences (first hash before, second after):
python3-colorama:do_fetch: 1813380fd695551e5112f3d57cb89a33ff8b039e7d40dd611acb5a2e5cbffb33 -> 0ac42383a6557a119738c7fda6a53a08837ffe2686b34f8fa5c2db83213bfe39
bitbake-diffsigs --task python3-colorama do_fetch --signature 1813380fd695551e5112f3d57cb89a33ff8b039e7d40dd611acb5a2e5cbffb33 0ac42383a6557a119738c7fda6a53a08837ffe2686b34f8fa5c2db83213bfe39
NOTE: Starting bitbake server...
basehash changed from 885cd5b7446329609d07bf2180fd6fa5b03edfdd04825d6f19a68474d83c1f33 to e3e476f44ff3905e371e1451a0e6e301baf5bdfb2f39c4140b75925fb331cd57
Variable PV value changed from '0.4.6' to '0.4.5'
Variable SRC_URI[sha256sum] value changed from '08695f5cb7ed6e0531a20572697297273c47b8cae5a63ffc6d6ed5c201be6e44' to 'e6c6b4334fc50988a639d9b98aa429a0b57da6e17b9a44f0451f930b6967b7a4'


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com