On Wed 2022-03-30 @ 04:08:31 PM, Richard Purdie wrote:

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

Awesome! That is a very simple and quick reproducer!

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).

As per our conversation I quickly tried the following (not that I expected
this to be a final solution, but just a poking-around kind of thing):

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index cc81461473..503da61b3d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -170,6 +170,7 @@ do_unpack[dirs] = "${WORKDIR}"
do_unpack[cleandirs] = "${@d.getVar('S') if os.path.normpath(d.getVar('S')) != os.path.normpath(d.getVar('WORKDIR')) else os.path.join('${S}', 'patches')}"

python base_do_unpack() {
+ bb.utils.remove(d.getVar('B') + "/.pc", recurse=True)
src_uri = (d.getVar('SRC_URI') or "").split()
if not src_uri:
return

And it changed the error message from:

$ bitbake keymaps -c patch
...
ERROR: keymaps-1.0-r31 do_patch: Applying patch 'GPLv2.patch' on target directory '/z/build-master/quilt-fix/qemux86/nodistro/build/tmp-glibc/work/qemux86-oe-linux/keymaps/1.0-r31'
CmdError('quilt --quiltrc /z/build-master/quilt-fix/qemux86/nodistro/build/tmp-glibc/work/qemux86-oe-linux/keymaps/1.0-r31/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout:
stderr: File series fully applied, ends at patch GPLv2.patch
')

to:

$ bitbake keymaps -c patch
...
ERROR: keymaps-1.0-r31 do_patch: Applying patch 'GPLv2.patch' on target directory '/z/build-master/quilt-fix/qemux86/nodistro/build/tmp-glibc/work/qemux86-oe-linux/keymaps/1.0-r31'
CmdError('quilt --quiltrc /z/build-master/quilt-fix/qemux86/nodistro/build/tmp-glibc/work/qemux86-oe-linux/keymaps/1.0-r31/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch GPLv2.patch
The next patch would create the file COPYING,
which already exists! Applying it anyway.
patching file COPYING
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- rejects in file COPYING
Patch GPLv2.patch can be reverse-applied

stderr: ')

progress? https://www.reddit.com/r/ProgrammerHumor/comments/8j5qim/progress/