On Wed, 2022-03-30 at 09:40 -0400, Trevor Woerner wrote:

Hi Matthias,

On Wed 2022-03-30 @ 06:32:00 AM, Matthias Klein wrote:

Yes, you are right, it is mostly the same recipes that fail. But they also change from time to time.
Today it happened to me even without Jenkins and Docker, normally in the console with the recipe keymaps_1.0.bb.

And keymaps follows the exact same pattern as modutils-initscripts and
initscripts; namely that their sources are entirely contained in-tree:

keymaps/
├── files
│   ├── GPLv2.patch
│   └── keymap.sh
└── keymaps_1.0.bb

keymaps/keymaps_1.0.bb
23 SRC_URI = "file://keymap.sh \
24 file://GPLv2.patch"

Any recipe that follows this pattern is susceptible, it's probably just a
coincidence that most of my failures happened to be with the two recipes I
mentioned.

This issue has revealed a bug, and fixing that bug would be great. However,
the thing is, keymap.sh is a shell program written 12 years ago which hasn't
changed since. The GPL/COPYING file is only there for "reasons". The license
file doesn't *need* to be moved into the build area for this recipe to get its
job done (namely installing keymap.sh into the image's sysvinit).

The "good" news is I did work out how to reproduce this.

bitbake keymaps -c clean
bitbake keymaps
bitbake keymaps -c unpack -f
bitbake keymaps -c patch
bitbake keymaps -c unpack -f
bitbake keymaps -c patch

I haven't looked at why but hopefully that helps us more forward with looking at
the issue.

The complications with S == WORKDIR were one of the reasons I did start work on
patches to make it work better and maybe move fetching into a dedicated
direction rather than WORKDIR and then symlink things. I never got that patch to
work well enough to submit though (and it is too late for a major change like
that in this release).

Cheers,

Richard