<jmd>
ERROR: e2fsprogs-1.47.0-r0 do_populate_lic: QA Issue: e2fsprogs: LIC_FILES_CHKSUM points to an invalid file: ...
<khem>
it uses multiple files to test.
<khem>
can you show which one is it complaining about ?
<jmd>
khem: ok. Which is the prefered pastebin here?
sakman has joined #yocto
<jmd>
The first warning is:
<jmd>
WARNING: e2fsprogs-1.47.0-r0 do_populate_lic: Could not copy license file /home/me/Yocto/poky/build/tmp/work/core2-64-poky-linux/e2fsprogs/1.47.0/git/NOTICE to /home/me/Yocto/poky/build/tmp/work/core2-64-poky-linux/e2fsprogs/1.47.0/license-destdir/core2-64/e2fsprogs/NOTICE: [Errno 2] No such file or directory: '/home/me/Yocto/poky/build/tmp/work/core2-64-poky-linux/e2fsprogs/1.47.0/git/NOTICE'
<khem>
so I wonder why it complains, can you check in build area of e2fsprogs for NOTICE file in '/home/me/Yocto/poky/build/tmp/work/core2-64-poky-linux/e2fsprogs/1.47.0/git
sakman has quit [Ping timeout: 256 seconds]
<jmd>
Yeah. I've just looked and for some reason that directory is empty.
<jmd>
Oh it looks like something in a local layer is messing with it.
yannd has quit [Remote host closed the connection]
<kanavin>
RP: not seen this before, '·-·empty·(lzip·compressed·data,·version:·0)' might mean rpm runs 'file' on files it's putting into a package, and places the output into .rpm, and the output of file is non-determinstic?
<kanavin>
that, or maybe libmagic offers those directly
<rburton>
jmd: you can turn off spdx entirely if you don't care, just either write your own distro that doesn't inherit it in the first place, or INHERIT:remove = "create-sdpx" if you're reusing poky (if you're using this commercially, don't use poky)
florian_kc has joined #yocto
<jmd>
rburton: I have tried the INHERIT:remove = "create-sdpx" - unfortunately it seems to make no difference.
<jmd>
Is poky not allowed to be used commercially? I thought it was free software.
<rburton>
sure it is
<rburton>
i didn't say you can't, i said its a bad idea
<jmd>
Why?
<rburton>
poky is a reference distro for testing yocto. it turns on most things.
<rburton>
and every release we'll change it.
<jmd>
What's the recommended way?
<rburton>
this means you spend time turning stuff _off_ and every upgrade you have to see what else it turned on.
<rburton>
write your own distro
<jmd>
I think most people write their own distros by deriving from poky.
<khem>
RP: so I guess, we are close to merging glibc 2.39 and binutils 2.42 as well perhaps
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<RP>
moto-timo: looks like python3-markupsafe upgrade to 2.1.4 breaks python3-jinja2 :/
<khem>
We have so many combinations to test in AB that something always cracks open, and usually its one of the lesser used architectures like ppc or mips or mingw
<moto-timo>
RP: how much fun can we have in one week ? :/
<khem>
RP: I am planning a create a branch where I want to track master branch for gcc/binutils/glibc
<RP>
moto-timo: trying to debug ltp in parallel and so on. Its great
<RP>
khem: I'd love to setup poky-bleeding to do it FWIW
<khem>
and perhaps throw that at AB once a week or so, I am sure it will be broken all the time but would be good to see if something breaks down
<khem>
RP: maybe devupstream class might be useful to use here
<RP>
khem: in general, yes but for those recipes, perhaps not!
<khem>
yeah, so how do we go about it ? maybe create bleeding versions of recipes ?
<khem>
or a branch with AUTOREV tuned on?
<RP>
khem: We probably create bleeding recipe versions
<moto-timo>
RP: master-next branch?
vladest has quit [Remote host closed the connection]
<moto-timo>
RP: markupsafe is still using setuptools3 class as well... not sure if switching to python_setuptools_build_meta will help or not (and python3-jinja2 should inherit python_flit_core)... I guess I need to revisit https://bugzilla.yoctoproject.org/show_bug.cgi?id=14736
<RP>
moto-timo: I tried python_flit_core but it blew up :/
simonew has quit [Ping timeout: 250 seconds]
<moto-timo>
RP: sigh
<dvergatal>
if I'm getting abort pseudo during do_rootfs for an image then I shoudl add PSEUDO_DEBUG = "nfoPcvdDyerpswikVx" in recipe for an image or in recipe for which this abort occurs?
<RP>
dvergatal: have you looked at pseudo.log before doing that?
<dvergatal>
yes
<moto-timo>
RP: I'll kick the can on both python3-markupsafe and python3-jinja2 in the coming week...
<RP>
and what does it say?
<dvergatal>
RP: nothing speciall
<RP>
dvergatal: you'd add it to the image recipe FWIW. I'm surprised there isn't something in the log thoug
<dvergatal>
maybe I will paste it somewhere
<dvergatal>
there is but nothing what could tell me what is really wrong
<RP>
dvergatal: the abort would be from path mismatch [2 links]: ino 59941822 db '/work/build/tmp-glibc/work/eg600-WelotecGmbH-linux/welotec-base-image/1.0-r0/rootfs/usr/local/share/ca-certificates' req 'system.posix_acl_access'
<RP>
dvergatal: looks like it is mixing up xattr and the path?
<dvergatal>
RP: I neeed to clarify somethign first
<RP>
moto-timo: 2.1.5 does fix it FWIW
<dvergatal>
generally I have discovered in my code for acls an issue about preserving acls for directories during split of package dir into packages-split
<dvergatal>
meaning that for files they are all preserved
<dvergatal>
in splitted directories
<RP>
dvergatal: I can't say I'm surprised to be honest
<dvergatal>
RP: yeah let me go further:P
<dvergatal>
RP: but for directories acls are not being preserved and I've made a fix for it
<dvergatal>
with usage of already implemented code of JPEW in bitbake and some modification
<dvergatal>
which is reading the acls in package dir and setting in correct path in packages-split
<dvergatal>
and the during image installation I'm getting this error and I didn't want to bother you or anyone else with the problem I wanted to solve it on my ownwith usage of this debug export
<dvergatal>
RP: in addition I see that this ipk package has correct acls for that directory so question is does it somehow checks with some database file during do_rootfs and i'm missing some additional fix for that?
<moto-timo>
RP: little wins
<dvergatal>
moto-timo: btw. I wanted to ask you if I may, are you complaining about python?
kpo has joined #yocto
<moto-timo>
dvergatal: I have been "the python guy" for Yocto Project for a decade and it is 10x or worse more work now than it used to be
<moto-timo>
dvergatal: all the new PEP-517 backends and things like python3-hypothesis that do a new version bump with EVERY commit
<dvergatal>
moto-timo: to be honest I wanted to say that I hate rust and I agree that python is also rubbish
<moto-timo>
dvergatal: it's all rubish?
<moto-timo>
lol
<dvergatal>
not all
<moto-timo>
COBOL is still very stable
<dvergatal>
:D
<moto-timo>
it's just been a week of a lot of things breaking that have been working so we're all on edge
<jmd>
dvergatal: +1
<moto-timo>
"working" meaning the wheels weren't falling off the wagon
jmd has quit [Remote host closed the connection]
<dvergatal>
generally for me the most frustrating thing is when I'm checking my code with mypy and....
vladest has joined #yocto
<RP>
dvergatal: it is possible the pseudo change which is queued fixes rpm
<RP>
dvergatal: that one in theory fixes some rpm issues with pseudo
<dvergatal>
RP: OK but I'm using ipk not rpm
<dvergatal>
RP: aahhhh pseudo is part of rpm ?
<RP>
moto-timo: I'm trying to resist "python3-marksupsafe: Switch to python_setuptools_build_meta as Tim said so" :)
<RP>
dvergatal: I sometimes struggle to understand some of the things you tell me. I thought above you were telling me ipks worked and I assumed that meant rpms do not
<RP>
In reality I see you mean the ipk creation worked but the extraction at do_rootfs does not
<dvergatal>
RP: ok let me explain again :D
<RP>
I don't know if that is a problem in opkg, in pseudo or somewhere else
<RP>
dvergatal: I have no idea why, sorry
<dvergatal>
RP: OK
<RP>
moto-timo: I'll leave jinja2 to you as that didn't seem to work easily
<moto-timo>
RP: I'll take it. Thank you for the heads up.
<RP>
moto-timo: thanks. Hopefully I've cleared some small bits out the way...
ptsneves has quit [Quit: ptsneves]
ptsneves has joined #yocto
ptsneves1 has joined #yocto
ptsneves has quit [Read error: Connection reset by peer]
ptsneves1 is now known as ptsneves
<dvergatal>
RP: thx you have given me some starting point where should I look :D
<khem>
was to fix GCC-14 issue to get core-image-minimal going
<khem>
I think once glibc and binutils are in, I will have bunch of gcc-14 related fixes coming in
<RP>
khem: I think most of these are in Alex's queue, I'm just trying to hit several other issues in parallel, the problem ones
<khem>
yeah it can wait, its not in his queue
<khem>
my tree is rebased on your master-next and alex's master-next
<gmorell>
/w 1
<RP>
khem: ok, I've put it into -next
<moto-timo>
bah. 6 tests in python3-cryptography now are trying to allocate 2**32 with mmap. So if I "runqemu nographic kvm qemuparams='-m 5000'" it has enough free memory
<moto-timo>
not 100% sure this is what is happening on AB, since I see test output locally
<moto-timo>
khem: the openssh log.do_configure I think is not different, but log.do_compile is... but I need more time and it's the weekend and I should be doing something fun
<neverpanic>
I think that's because NIST now requires testing hashes with more than 4GiB of input in a single call to make sure that they don't silently truncate, which could be dangerous for signatures
<neverpanic>
But I agree that's a very annoying test.
Kubu_work has quit [Quit: Leaving.]
<moto-timo>
neverpanic: yeah, there are some new poly* tests for large keys
<moto-timo>
I am still not convinced this is it, because my testresults.json has test results and the failures on the AB had zero test results in the log
<moto-timo>
oh well. tomorrow is another day
<RP>
kanavin: It looks like it runs file on the files within the archive but for some reason it isn't sorting that in the header, so probably an unsorted directory listing somewhere
Sonak has joined #yocto
goliath has quit [Quit: SIGSEGV]
<RP>
kanavin: looking at package_rpm and it's os.walk, there is no sorting in there at all. I suspect that leads to non-determinstic ordering of the files sections in the spec files and I suspect that in turn leads rpm to reorder headers
florian has quit [Ping timeout: 240 seconds]
<abelloni>
khem: it was in my queue and will get back in it once I pinpoint the remaining issues I have
sakman has quit [Ping timeout: 268 seconds]
<RP>
abelloni: it is a nightmare atm. drop python3-markdown .4 if you have it since it breaks jinja2, the .5 is better
<RP>
abelloni: the pseudo patches all merged into the repo
<abelloni>
it is a nightmare...
Sonak has quit [Quit: leaving]
florian has joined #yocto
<dvergatal>
RP: OK I see that in case of files, pseudo is obtaining full path but in case of directories it is not and thus it mixes it
<dvergatal>
RP: unfortunatelly this log is pretty big, so I think that I will post it on mailling list or to bugzilla during the day