mckoan has quit [Quit: Quitting irssi IRC Client, bye.]
mckoan has joined #yocto
<janvermaete[m]>
Is it possible to have in the CVE reporting only the non native packages?
gsalazar has quit [Ping timeout: 264 seconds]
leon-anavi has joined #yocto
prabhakarlad has joined #yocto
yocton has joined #yocto
<RP>
janvermaete[m]: only inheriting the class for target recipes would probably do that
<janvermaete[m]>
Could be, now I have enable it with a INHERIT += “cve-check”
goliath has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vmeson has quit [Ping timeout: 272 seconds]
zyga-mbp has joined #yocto
vmeson has joined #yocto
fiorentinoing has joined #yocto
halstead has joined #yocto
<janvermaete[m]>
In the local.conf
<RP>
janvermaete[m]: I'll admit I'm not entirely sure how you'd make that work with an override now I think about it :/
yocton has quit [Ping timeout: 250 seconds]
<janvermaete[m]>
<RP "jan vermaete: I'll admit I'm not"> I will check with Konrad.
hpsy has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
yocton has joined #yocto
<RP>
janvermaete[m]: you'd need something like MYINHERIT = "${SOMEVAR}" SOMEVAR = "" SOMEVAR_class-target = "cve-check" inherit ${MYINHERIT}
<RP>
janvermaete[m]: that will work from a class but not from conf files
tnovotny has joined #yocto
fiorentinoing has quit [Quit: Client closed]
pbaptista has joined #yocto
pbaptista has quit [Ping timeout: 250 seconds]
<paulbarker>
RP: Have the prserv patches caused any issues on the autobuilder? I see they're still in master-next. No rush to get them merged to master, I've got some time this week to look at them again though if needed
<RP>
paulbarker: They seem ok. I wanted to get M1 built and out, then look at them. I'm a little worried that we're hitting timeouts and just hiding issues somehow - I'm not seeing the timeouts triggering anywhere and it worries me that based on the previous testing, you'd kind of have expected to
<RP>
paulbarker: if we do hit a timeout, we should see a failure of some kind right?
pidge has joined #yocto
<paulbarker>
RP: Yes, if the client doesn't receive a reply from the server within 30s it'll raise a ConnectionError now
<paulbarker>
I've not been able to reproduce the failures seen previously on the autobuilder. My home 6c/12t build machine is a very different environment to the autobuilder cluster though
<paulbarker>
My only guess was a race condition or resource exhaustion which is hit in the autobuilder environment but not on a less heavily loaded machine. Due to the way the selftest output is buffered though we can't even see which test was hanging on the autobuilder
<derRichard>
i'm upgrading a old layer to yocto hardknott, i'm facing this error: u-boot PROVIDES virtual/bootloader but was skipped: PREFERRED_PROVIDER_virtual/lib32-bootloader set to lib32-u-boot, not u-boot
<derRichard>
who sets PREFERRED_PROVIDER_virtual/lib32-bootloader? i don't really find it in my layer.
<yocton>
derRichard Check the output of "bitbake -e virtual/lib32-bootloader" maybe ? (This will tell you were was each variables defined/modified/...)
<qschulz_>
derRichard: it does not make much sense to have a 32b variant of the bootloader? So I would try to understand first why this is needed?
qschulz_ is now known as qschulz
yocton57 has joined #yocto
mckoan is now known as mckoan|away
yocton has quit [Ping timeout: 250 seconds]
<derRichard>
qschulz: it makes 0 sense to to have a 32bit variant of u-boot. i don't want this. but somehow yocto thinks i do :(
<derRichard>
yocton57: bitbake -e does not work since it aborts before with the said error :(
<qschulz>
derRichard: I think you have the recipe from which this dependency is done in the error message don't you?
<qschulz>
derRichard: mmm, maybe just grep for virtual/lib32-bootloader and/or virtual/bootloader and start investigating from there?
<derRichard>
no. building fails as soon yocto wants to build "virtual/bootloader"
<derRichard>
virtual/lib32-bootloader is nowhere set. virtual/bootloader only on places where it makes sense
<derRichard>
some magic i don't see so far sets virtual/lib32-bootloader for sure
<qschulz>
derRichard: ilb32- is very often added by bitbake implicitly
<qschulz>
so I would look for recipes that have a DEPENDS on virtual/bootloader and can be built as lib32
<derRichard>
will do!
yocton57 has quit [Ping timeout: 250 seconds]
tnovotny has quit [Read error: Connection reset by peer]
yocton57 has joined #yocto
yocton57 has quit [Ping timeout: 250 seconds]
yocton57 has joined #yocto
yocton57 has quit [Ping timeout: 250 seconds]
yocton57 has joined #yocto
yocton57 has quit [Client Quit]
hpsy1 has joined #yocto
hpsy has quit [Ping timeout: 268 seconds]
yocton57 has joined #yocto
hpsy1 is now known as hpsy
Vonter has quit [Ping timeout: 268 seconds]
Vonter has joined #yocto
<RP>
derRichard: I suspect we may need to teach the single u-boot recipe to PROVIDES both virtual/bootloader and virtual/lib32-bootloader
<RP>
I think we already do this with kernel modules
<qschulz>
RP: I'm not sure it makes sense? This would have made sense when we didn't have the libubootenv recipe, but now, not so sure?
<RP>
qschulz: from which perspective? I suspect it makes sense from some angles bit less so from others
<qschulz>
RP: why would one want to build 32b bootloader if your machine has 64b support? (except well... if your vendor only provided you with a bootloader that can be compiled in 32b only)
<RP>
paulbarker: better, I have a traceback for you
<RP>
paulbarker: I'm guessing that traceback and the hung build are related
<RP>
qschulz: the other way to think about this code is how does the virtual multilib class extension code handle virtua/bootloader ?
<RP>
qschulz: the way we do this with the kernel (from memory) is have the main recipe provide both, then dependency chains work. its less about having two kernels and more about how to map the dependencies to something sensible
georgem has joined #yocto
paulg has joined #yocto
<qschulz>
RP: so I was speaking from the perspective of a "user" and I see you're talking from the perspective of bitbake/yocto. And yes, I assume it shouldn't fail to at least try to build the 32b variant
OnkelUlla has joined #yocto
hpsy has joined #yocto
<paulbarker>
RP: I'll take a look shortly thanks
hpsy has quit [Ping timeout: 244 seconds]
<RP>
qschulz: right, I understand the user perspective but there is the detail of how to implement it
<qschulz>
RP: I'd need to check if one of the classes inherited by u-boot recipes can have this set there. Like all kernel recipes inherit kernel (I'd assume so at least), I would assume the same should be possible for u-boot?
<RP>
qschulz: I'd think so...
marc1 has joined #yocto
hpsy has joined #yocto
otavio has joined #yocto
chrfle_ is now known as chrfle
yocton57 has quit [Ping timeout: 250 seconds]
<vmeson>
last night, I ran a test of rpurdie/t222 -- 46/102 tests had the "BUG:" - most common RIP: 22 d_alloc_parallel+0xd5/0x570, 6 dentry_free+0x69/0x70, 8 do_mkdirat+0x6c/0x130, 7 kernfs_sop_show_path+0x1c/0x60
<RP>
vmeson: hmm, 46% isn't quite my guess of 70% reproducibility
sakoman has joined #yocto
asus_986_gpu[m] has quit [Ping timeout: 244 seconds]
Spectrejan[m] has quit [Ping timeout: 244 seconds]
ndec[m] has quit [Ping timeout: 244 seconds]
khem has quit [Ping timeout: 244 seconds]
shoragan[m] has quit [Ping timeout: 244 seconds]
jordemort has quit [Ping timeout: 244 seconds]
AlessandroTaglia has quit [Read error: Connection reset by peer]
janvermaete[m] has quit [Read error: Connection reset by peer]
dwagenk has quit [Read error: Connection reset by peer]
fabatera[m] has quit [Read error: Connection reset by peer]
shoragan|m has quit [Read error: Connection reset by peer]
Saur[m] has quit [Read error: Connection reset by peer]
Pierre-jeanTexie has quit [Read error: Connection reset by peer]
ejoerns[m] has quit [Read error: Connection reset by peer]
Emantor[m] has quit [Read error: Connection reset by peer]
barath has quit [Read error: Connection reset by peer]
kayterina[m] has quit [Read error: Connection reset by peer]
Andrei[m] has quit [Read error: Connection reset by peer]
Jari[m] has quit [Read error: Connection reset by peer]
cody has quit [Read error: Connection reset by peer]
alex88[m] has quit [Read error: Connection reset by peer]
Andrei[m] has joined #yocto
kayterina[m] has joined #yocto
jordemort has joined #yocto
rob_w has quit [Remote host closed the connection]
<RP>
paulbarker: looks like if async io is still active at exit there can be hangs. no traceback in the latter and it is hung in parsing files in the follow on build
ncaidin_lf has joined #yocto
<paulg>
vmeson, if I am right, your search is doomed to find the LTP change that makes us "see" the issue ; the issue itself dates back to v5.1-rc1
<RP>
paulg: seems odd an issue would have lasted this long without someone else finding it but I guess not impossible. You found that by bisection?
<paulg>
yes, it does seem odd, and "kinda sorta" is the answer to your bisection question.
<paulg>
a lot of UTSL too.
<paulg>
need some more time to complete this invesitgation thread and knwo for sure, but it is looking very likely.
<paulbarker>
RP: Those logs should help. I had assumed that if the issue was fairly low-level with asyncio we'd have already hit it with hashserv as that uses the same approach. But maybe there's just enough different between them to see issues in prserv but not hashserv
<RP>
paulbarker: we don't stop/start a hashserv with each bitbake server, we connect to a central one
<RP>
paulg: is there a revert we could test with a modern kernel?
<paulg>
no
<paulg>
see lwn
<paulg>
it is a new infrastructure being used/implemented in a series of commits.
<paulg>
a series that went thru at least a dozen versions and sat for a while before going mainline.... https://lwn.net/Articles/766155/
<RP>
paulg: fair enough, I guess that could explain some part of this...
wesm has joined #yocto
<RP>
paulg: 14 versions :/
<paulg>
?
<paulg>
Ah, the fs context yea.
<paulg>
I don't want to risk getting ahead of myself and leading others on a wild goose chase; so give me a couple more hours with this to confirm and then I'll share more details.
<paulg>
if it turns out the sonofabitch has been lurking out there since v5.1 and screwing LTP for a month now, a few more hrs won't hurt.
<RP>
paulg: I'll leave it with you. Today I have too many meetings to concentrate :/
<paulg>
yeah, somehow I don't see a whack-tonne of people clamouring at my door to volunteer to take on trying to nut this out.
BCMM has joined #yocto
tlwoerner has quit [Ping timeout: 244 seconds]
tlwoerner has joined #yocto
meego has joined #yocto
rber|res has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<paulg>
RP, if you are bored, look at commit log for 23bf1b6be9c291 and "Weirdies" and tell me if you think that is confidence inspiring.
<paulg>
the merged branch of v5.1-rc1~12 ... i.e. "git log --oneline v5.1-rc1~12^2" is where I'm rummaging around, for those following along at home.
<moto-timo>
🍿
dev1990 has joined #yocto
chrfle has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #yocto
pidge has quit [Remote host closed the connection]
pidge has joined #yocto
meego_ has joined #yocto
fullstop_ is now known as fullstop
meego has quit [Ping timeout: 272 seconds]
meego_ has quit [Quit: Leaving...]
Gaffel has joined #yocto
<fabatera[m]>
I'm still trying to find out the missing piece to boot with root NFS with a core-image-minimal / core-image-minimal-initramfs. Any hints about it?
roussinm has joined #yocto
roussinm has quit [Client Quit]
roussinm has joined #yocto
<alex88>
Is anyone using dracut to generate an initramfs? Any tip on how to generate the initramfs during build time?
ncaidin_lf has quit [Quit: Client closed]
<fabatera[m]>
<alex88 "Is anyone using dracut to genera"> core-image-minimal-initramfs
prabhakarlad has quit [Quit: Client closed]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alex88>
fabatera[m], oh and that will automatically generate the initramfs using it? nice. I just need to add my custom modules then.. thanks!
<fabatera[m]>
<alex88 "fabatera, oh and that will autom"> I'm trying to add kernel modules to it (INITRAMFS_IMAGE_BUNDLE = "1"). But somehow it's not working. How would you add your modules?
<fabatera[m]>
<fabatera[m] "core-image-minimal-initramfs"> I'm also interested in how to use darcut.
<alex88>
oh I'm not sure how to do that, I've just started looking at the initramfs thing, theoretically you need to add the custom dracut modules in /usr/lib/dracut/modules.d as per https://man7.org/linux/man-pages/man7/dracut.modules.7.html
<alex88>
dracut seemes more something you install and then run to generate the image but I'm not sure how that can be done in the build phase
<alex88>
my main goal is to gnerate an initramfs that mounts the root as an overlayfs
<fabatera[m]>
Dracut generates one complete initramfs. The core-image-minimal-initramfs will create initramfs without it (AFAIK)
<alex88>
yeah I don't see any dracut reference in the yocto initramfs code
<rburton>
yocto doesn't use dracut
kpo_ has quit [Read error: Connection reset by peer]
kpo_ has joined #yocto
mattofak has joined #yocto
prabhakarlad has joined #yocto
mattofak has quit [Client Quit]
leon-anavi has quit [Quit: Leaving]
mattofak has joined #yocto
<alex88>
so it might not even be possible to use it to build the initramfs
<RP>
paulg: that isn't confidence inspiring at all :/
<RP>
paulg: I wonder if we should ask the ltp people about this...
<paulg>
not sure the LTP people will have anything useful to say.
<paulg>
basically they've created mindless test cases taht mount/unmount in an endless loop ; there isn't a lot of "thought out technology" there IMHO.
<RP>
paulg: more wondering if they've seen this break and have any leads on where it broke
<paulg>
I *seriously* doubt it.
<RP>
paulg: Did you get any further?
<paulg>
IMHO yes.
* RP
is intrigued
Vonter has quit [Ping timeout: 268 seconds]
Vineela has joined #yocto
<paulg>
I have one commit responsible for a dput WARNING which persists from v5.1 until at least v5.4 ; as of v5.7 it is our "familiar" group of 4 null deref on dentry->d_inode
<paulg>
need to fill in the gap between v5.4 and v5.7 now...
<paulg>
and of course figure out why that old commit is borken
<paulg>
I should also test mainline/next at some point ; with all my other juggled bits unchanged ; haven't tested > v5.10.42 ; going on RP result from linux-yocto-dev earlier...
<paulg>
best way to look like a dumb ass is to post about something already fixed....
<RP>
paulg: I did reproduce the bug on 5.13-rc4 or 5
<RP>
paulg: I'm wondering if there is a reason the bug on 5.8 looked quite different
<paulg>
I'd have to go back and look at your data ; for me it "changes" between v5.6 and v5.7
<paulg>
I'm just about to look at what changed in v5.7...
<zeddii>
I just got notice from aufs's lawyers. I'm being sued for defamation for my revert! ;)
<zeddii>
luckily we settled out of court, as I showed the commits putting it back :D
<paulg>
send the bill to RP ; he can pry the $ out of LF.
<RP>
paulg: that would add up. I think it also likely changes duing 5.4 LTS
<RP>
zeddii: heh, at least you know it is being used :)
Vineela has joined #yocto
Vineela has quit [Changing host]
cambrian_invader has joined #yocto
zyga-mbp has joined #yocto
Vineela has left #yocto [#yocto]
zyga-mbp has quit [Client Quit]
Vineela has joined #yocto
<halstead>
Welcome Vineela. :)
<Vineela>
got the message halstead. Thanks.
<RP>
kergoth: any thoughts on whether X := Y should be overridden by an earlier X_override = Z ?
<paulg>
RP, zeddii, vmeson -- there is no shortage of stuff that might have morphed the dentry fail between v5.6 and v5.7 (the "investigate" part)
* paulg
needs coffee.
<RP>
paulg: hmm, is that good or bad? :/
<paulg>
neither, I guess. It just means I aint done yet. :-/
chrfle has quit [Ping timeout: 272 seconds]
ismail has left #yocto [#yocto]
pidge has quit [Remote host closed the connection]
pidge has joined #yocto
kpo_ has quit [Read error: Connection reset by peer]