<qschulz>
so here I think we have an issue with using the old syntax %s_%s should be %s:%s
<qschulz>
But I'm wondering if this is still somehow needed. It used to be because of the old overrides syntax (_ instead of the new :)
<qschulz>
and because variables also had the right to have _ in their name
<qschulz>
but since UBOOT_EXTLINUX_LABELS is now part of OVERRIDES with ':' is it still somehow needed?
<qschulz>
I think it is because we add to the OVERRIDES variable only in the function/task itself so it wouldn't know?
<qschulz>
so still no precise question, sorry. Not sure I understand what I don't understand :/
<RP>
qschulz: right, that code exists since bitbake can't know about the overrides and can't compute the variable dependencies as a result
<RP>
It should be UBOOT_EXTLINUX_%s:%s I think
risca has joined #yocto
<qschulz>
i'll try something out to trigger the rebuild and we'll see what's what, thanks for the confirmation
<qschulz>
funnily enough, I stumbled upon this because I couldn't get it to invalidate the sstate-cache for that and my extlinux.conf would never change
<qschulz>
so it's the bootimg-partition wic plugin that created the extlinux on the fly :D
<RP>
qschulz: there is definitely a bug there
<qschulz>
(wondering if we shouldn't have bootimg-partition to check that UBOOT_EXTLINUX variable and use it if set instead of asking --configfile to be passed, but it's a bigger change than just a bug fix
<qschulz>
RP: thanks, will run a test still, don't like sending untested patches too much :)
risca has quit [Ping timeout: 240 seconds]
<RP>
qschulz: I guess I'm more reckless :)
mbulut has joined #yocto
<qschulz>
RP: you can "afford" it because you're the one dealing with the breakages most of the time. Don't want to put more load on you that you already have ;)
* landgraf
wanted to run tests over night but storm came and cut power. Sorry for sending semitested patches because of that. :-)
mbulut has quit [Client Quit]
<PhoenixMage>
Is there a decent vscode extension for working with bb, bbclass, bbappend, etc?
<RP>
landgraf: you've done well to find those packaging issues, the patches look good thanks. Obviously I've not run them on the autobuilder yet mind :)
<RP>
qschulz: I guess being the maintainer has to have some kind of benefit
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
dacav has joined #yocto
<qschulz>
RP: I hope there are more benefits than "if I break stuff I can fix it!" :)
<RP>
qschulz: I do sometimes wonder
<dacav>
Hi. I've got a weird problem with the SDK. The installer fails because of a broken executable that could not be relocated. I narrowed the problem down to the binary being corrupted. The binary comes from a nativesdk- recipe, whose sysroot contains a good binary.
<dacav>
The corrupted binary ends up in a directory called packages-split
<RP>
dacav: right, image -> packages-split is do_package
<yocton>
PhoenixMage: I've seen patches on the ML recently
<dacav>
RP: the corrupt file is mentioned in the log file as being stripped. I execute manually the stripping (calling x86_64-${oursdk}-linux-strip with the same options as in the log file) and that seems to work. Are you aware of any bug in strip? -- not the first time I encounter something like that --
<RP>
dacav: I'm not aware of anything but as you say, software can have bugs
Daanct12 has quit [Quit: WeeChat 4.0.5]
Ablu has quit [Ping timeout: 255 seconds]
risca has joined #yocto
Daanct12 has joined #yocto
<rburton>
RP: argh
<PhoenixMage>
yocton: Thanks, I use the one linked there, could never get the click to definition to work
<dacav>
RP: is there a way to trigger the do_package task of the do_populate_sdk task? Or is it just bitbake -c do_package my_image ?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
dacav: images don't have package tasks
kanavin has joined #yocto
chat89 has quit [Quit: Client closed]
ThomasRoos has joined #yocto
prabhakarlad has quit [Quit: Client closed]
luc4 has joined #yocto
chat89 has joined #yocto
<dacav>
RP: then how do I trigger the do_package of the do_populate_sdk?
<dacav>
or do I need to re-do the whole do_populate_sdk maybe? :)
<rburton>
what do you actually want to do?
mr_nice has joined #yocto
chat89 has quit [Quit: Client closed]
Ablu has joined #yocto
ThomasRoos has quit [Quit: Client closed]
<dacav>
rburton: I'm trying to understand why a certain binary gets corrupted when copied over the SDK. The nativesdk- variant of the recipe produces a (apprently) good binary, but the packaged one ends up butchered
<ThomasRoos>
Is there a way to have error on warning for CVE_CHECK_SHOW_WARNINGS ? Make the build fail if there is a warning?
Daanct12 has quit [Ping timeout: 258 seconds]
<RP>
ThomasRoos: what check-layer is telling you there is that the two recipes conflict and do different things. It is bad for users to have two things floating around with different behaviours :(
<RP>
ThomasRoos: normally, one would rename to avoid that warning
<RP>
ThomasRoos: do you already depend on that layer? can you use the version in that layer without issue?
<dacav>
RP: thanks :)
psi62 has joined #yocto
<ThomasRoos>
RP we update this package like every day and run ptests on it...
<RP>
ThomasRoos: ok, I hadn't realised that was an AWS api but I see the issue now
<RP>
ThomasRoos: I'd talk to the meta-oe people about using the version in meta-aws?
<RP>
ThomasRoos: I suspect it is just oversight
<ThomasRoos>
RP: thx - will do this
<ThomasRoos>
Next - Is there a way to have error on warning for CVE_CHECK_SHOW_WARNINGS ? Make the build fail if there is a warning?
<RP>
ThomasRoos: currently, looking at the code I'd say not
<ThomasRoos>
Ok, did see nothing, but was thinking my there is a global switch to enable error on warning...
<RP>
ThomasRoos: I did wonder if we'd done that but I can't see one
Schlumpf has quit [Quit: Client closed]
psi62 has quit [Quit: Client closed]
<luc4>
Hello! I would like to have a specific user setup for a set of recipes in my layer. Should I use extrausers or useradd? I was thinking of using useradd in a recipe and then depend on that recipe. Is this a good way to go?
<luc4>
Also I'd need users to be created at image creation time, cause my rootfs is ro.
psi21 has joined #yocto
prabhakarlad has joined #yocto
prabhakar has joined #yocto
alimon has quit [Remote host closed the connection]
slimak has joined #yocto
alimon has joined #yocto
ThomasRoos has quit [Quit: Client closed]
Minvera2 has joined #yocto
silbe has quit [Ping timeout: 240 seconds]
psi21 has quit [Quit: Client closed]
Xagen has joined #yocto
Xagen has quit [Ping timeout: 252 seconds]
silbe has joined #yocto
silbe has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
vladest has quit [Quit: vladest]
mvlad has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
<RP>
luc4: useradd in a recipe should work in theory
<luc4>
RP: thanks. I'm trying but no luck for the moment. I see no user in /etc/passwd.
prabhakarlad has quit [Quit: Client closed]
vladest has joined #yocto
<luc4>
RP: but is useradd supposed to add users to /etc/passwd?
<luc4>
RP: uh, sorry, probably it must be added explicitly to the image
<RP>
luc4: right, you need to add the recipe to the image
<luc4>
RP: as it is a dependency of a recipe, I thought that was sufficient
<luc4>
RP: it apparently needs to be explicit in this case
luc4 has quit [Quit: Konversation terminated!]
luc4 has joined #yocto
luc4 has quit [Client Quit]
vladest has quit [Ping timeout: 272 seconds]
luc4 has joined #yocto
rob_w has quit [Remote host closed the connection]
<JPEW>
It's not "ideal" parallelism, but it still really good
<RP>
JPEW: that is surprisingly simple!
<RP>
JPEW: I'm happy to merge that!
<JPEW>
Err, sorry, that's just the runqueue part. The siggen stuff is a more complicated :)
<RP>
it did seem a bit too good to be true
<JPEW>
My comment was more that the runqueue was already ready for some level of parallelism rather than having to restructured how it does thing
<RP>
JPEW: right, that makes sense. We did try and prepare for this
<RP>
it is nice to have something that isn't painful for a change
dgriego has quit [Ping timeout: 240 seconds]
dgriego has joined #yocto
tnovotny has joined #yocto
<yocton>
RP: Thanks! I'll monitor this :)
vladest has joined #yocto
radanter has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 258 seconds]
jclsn has joined #yocto
vladest has quit [Remote host closed the connection]
silurian_invader has quit [Ping timeout: 255 seconds]
vladest has joined #yocto
silurian_invader has joined #yocto
<smurray>
JPEW: stray though I had, would it make sense to codify packaging up the PR server in a container along the lines of what you're doing with hash equiv? or even the same container...
<JPEW>
Ya, maybe. Probably not the same container though
mvlad has quit [Remote host closed the connection]
mr_nice has quit [Quit: Lost terminal]
l3s8g has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
l3s8g has joined #yocto
mbulut has joined #yocto
mbulut has quit [Client Quit]
dvergatal has quit [Quit: Lost terminal]
ptsneves has joined #yocto
alessioigor has quit [Quit: alessioigor]
olani- has joined #yocto
l3s8g has quit [Ping timeout: 255 seconds]
mario-goulart has quit [Remote host closed the connection]
mario-goulart has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
florian_kc is now known as florian
RP has quit [Remote host closed the connection]
slimak has quit [Remote host closed the connection]
RP has joined #yocto
RP has quit [Remote host closed the connection]
Guest81 has joined #yocto
<Guest81>
hello, I have a recipe that extends gpsd to overwrite the /etc/defaults/gpsd.default file; I also have a postinst that `update-alternatives` the file. Now, in the image, I have a `/etc/default/gpsd` that is a symlink to the gpsd.default file, but that file it just not there? In my WORKDIR/image, the file is correctly in `/etc/default` but in the
tgamblin has quit [Remote host closed the connection]
florian has joined #yocto
mihai- is now known as mihai
olani- has quit [Ping timeout: 272 seconds]
bhstalel has joined #yocto
<bhstalel>
Hello, is anyone here now ?
<bhstalel>
I am trying to debug and analyse the collections expansion and layers config expansion, and I noticed that putting only BBFILES in layer.conf does the trick of finding the recipe and also finding the bbclass, which is not logical because BBPATH is used to find conf and bbclass files which is not defined
<bhstalel>
does bitbake set a default value for it ? though, I checked BBPATH expanded value and it does not have my new layer's path