<DvorkinDmitry>
is VIRTUAL_RUNTIME_xx compatible with Dunfell?
<mbulut_>
is there an elegant way to select files in SRC_URI for dev/rel builds?
<DvorkinDmitry>
mbulut_, probably better to do it at do_install()
tangofoxtrot has joined #yocto
<Saur_Home86>
DvorkinDmitry: I assume you mean VIRTUAL-RUNTIME_xx? It is just a variable. What you do with it is up to you, though typically it is used in RDEPENDS:${PN} (or RDEPENDS_${PN} in Dunfell)...
<mbulut_>
yeah, that's an option of course but thought maybe there's some handy feature similar to machine based selection...
vthor has quit [Remote host closed the connection]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
simonew has quit [Ping timeout: 268 seconds]
enok has joined #yocto
enok has quit [Ping timeout: 240 seconds]
enok has joined #yocto
manuel_ has joined #yocto
manuel1985 has quit [Read error: Connection reset by peer]
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
wooosaiiii has quit [Client Quit]
wooosaiiii has joined #yocto
goliath has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
alessioigor has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
rob_w has joined #yocto
MrCryo has joined #yocto
wooosaiiii has joined #yocto
ablu has quit [Read error: Connection reset by peer]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
ablu has joined #yocto
Jones42 has joined #yocto
linfax has joined #yocto
frieder has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
alperak has joined #yocto
Kubu_work1 has joined #yocto
zpfvo has joined #yocto
Jah has joined #yocto
altru has joined #yocto
florian has joined #yocto
<rob_w>
is it straightforward to just update the wic tool from a older toolchain ?
altru has quit [Quit: Client closed]
<Jah>
has someone any clue regarding to error I am having
<Jah>
do_rootfs: Postinstall scriptlets of ['rfkill', 'sysvinit', 'shadow'] have failed. If the intention is to defer them to first boot,
<Jah>
then please place them into pkg_postinst_ontarget_${PN} ().
florian_kc has joined #yocto
Vonter has joined #yocto
altru has joined #yocto
<mcfrisk>
Jah: check do_rootfs logs. and the script in question. it is slightly annoying that on some packaging systems (opkg/ipkg) those scripts don't run with "set -x" to see the actual error right away.
mvlad has joined #yocto
<Jah>
yes as you identify, it is hard to grab from error what needs to be done. The for rfkill looks like
<Jah>
update-alternatives: Error: not linking /home/Build/tmp/work/core-linux-gnueabi/core-image-main/1.0-r0/rootfs/usr/sbin/rfkill to /usr/sbin/rfkill.rfkill since /home/Build/tmp/work/core-linux-gnueabi/core-image-main/1.0-r0/rootfs/usr/sbin/rfkill exists and is not a link
<Jah>
mcfrisk do you have any idea how to resolve this error
enok has quit [Ping timeout: 240 seconds]
tnovotny has joined #yocto
<mcfrisk>
Jah: check what is providing the other rfkill binary. update-alternatives needs to be enabled for both so that a link is used to select between the providers of the file. To resolve the issue, either fix both to use update-alternatives, or remove the second provider of rfkill from image.
enok has joined #yocto
vthor has quit [Ping timeout: 240 seconds]
<Jah>
mcfrisk would you do the same as I do to find who else if providing rfkill "bitbake -e rfkill | grep ^PROVIDES". Or is there other approach you would use to find all providers of rfkill. My search giving me nothing
<RP>
abelloni: thanks, I pulled in a decent chunk of -success. Can you confirm the rust patches pass testing?
<mcfrisk>
when creating products, i would manage target binary and rootfs contents very carefully, e.g. with buildhistory and manual review after all changes to content, installed packages, on rootfs. sizes also matter when trying to fit to HW budget. and licenses. and cves...
<Jah>
mcfrisk that's a great tipp however I can't lead it back through git because it doesn't create installed packages information
enok has quit [Remote host closed the connection]
enok has joined #yocto
<mcfrisk>
package manager is used to generate the rootfs, e.g. install packages and their dependencies. So answer is inside the binary package repo, and bitbake extracts this metadata to buildhistory when building from scratch. So you can try to query the package database for the owner of rfkill binary. It's often visible in bitbake recipes scripts too. util-linux, busybox and rfkill recipes provide rfkill binary,
<mcfrisk>
for example. Some of these get pulled into the image somehow.
<qschulz>
zeddii: cmp returns 0 if the files are identical. So the defconfig in WORKDIR needs to be different from the one in-tree (i.e. patched) for this message to appear, but we say it's unpatched
<Jah>
mcfrisk would there be only solution to filter out rfkill from utillinux and busybox through menuconfig ? Do you have any guesses which binaries can provide sysvinit and shadow?
<mcfrisk>
Jah: sure, adjust the recipes and features in your build. Some of the rfkill variants is not using update-alternatives, hence the error. add that back. Or disable rfkill feafure e.g. from busybox if util-linux version is used. Or stop install rfkill package from rfkill recipe if some dependency is pulling that in. everything depends on your setup.
<Jah>
mcfrisk thank you very much for your help! Do I have to do the same with sysvinit and shadow
lquirion has joined #yocto
<mcfrisk>
Jah: possibly, these all depend on your config. Be careful when adding layers and SW components to the build and rootfs. Some of the dependencies may not work correctly in the config that you use.
<Jah>
mcfrisk I guess I'll have to research to tame it well. Thank you for your assistance
<mcfrisk>
Jah: you're welcome. buildhistory helps once you have builds from scratch which provide the data for all source and binary packages, and images.
manuel_ has quit [Quit: Leaving]
lexano has joined #yocto
alessioigor has quit [Quit: Client closed]
mbulut_ has quit [Remote host closed the connection]
alessioigor has joined #yocto
rob_w has quit [Remote host closed the connection]
leon-anavi has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
Jah has quit [Quit: Client closed]
sakoman has joined #yocto
<qschulz>
does anyone have a hint on how to debug the packaging code?
<qschulz>
I have two kernel recipes, one populates kernel-src package, the other not
<qschulz>
and obviously, the one that does has a build-path QA issue in it :)
<qschulz>
both recipes include the same inc files, inherit the same bbclasses, etc...
<qschulz>
no notable difference in machine conf file and recipes for variables
<qschulz>
the files in question are built in both cases, they only make it to the kernel-src for one recipe though
xmn has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
mvlad has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
mjm has joined #yocto
hiagofranco has joined #yocto
Guest13 has joined #yocto
<Guest13>
hello. i want to create a tool/program that gets all the software versions i have on the yocto image. is there a "general" approach for this?
hiagofranco has quit [Client Quit]
<jonmason>
JPEW: I think you'd be horrified at what my build setup for CI looks like :)
<JPEW>
jonmason: We've all been there; held together by bubblegum and good intentions :)
<jonmason>
I actually have a Orange Pi gitlab CI runner
<jonmason>
I'm actually going through and measureing the power and performance of the random systems. I think it'd make an interesting presentation
<JPEW>
Ya, that would
<qschulz>
Guest13: i'm wondering if this isn't something our spdx mechanism could handle (or already handle)?
<JPEW>
Guest13: Ya, SPDX can tell you all that if you want. you'll currently need a custom tool to parse that (because SPDX 2.2), but it should all be there
lquirion has quit [Ping timeout: 264 seconds]
<jonmason>
I had systems so slow that it could only do 2.8 clean qemuarm minimal builds...a day
<jonmason>
oh, and mac mini m1 seems to be the most efficient builder when it comes to power/time to do a clean build
<jonmason>
which might matter if you are in the UK and doing builds during the day (those electric prices are insane)
<RP>
jonmason: as someone with a large build machine in the UK.... :/
florian has quit [Quit: Ex-Chat]
<jonmason>
Using Ross's rates, it'll cost 5p to do a build (of qemuarm, no sstate, core-image-minimal) on AMD 3950 (32 cores) with 32G RAM
<jonmason>
it costs 0.7p on a mac mini m1
<jonmason>
the time is 3700s for m1 and 2200s for 3950
<jonmason>
I have data for roughly a dozen systems
<jonmason>
the worst in every aspect was RasPi5
<RP>
jonmason: It'd be interesting to know how "bad" my Xeon box is for that
<jonmason>
I used a kasa plug, which can monitor the power usage
<jonmason>
I want Ross to use one on our big iron inside the company
florian_kc has quit [Ping timeout: 268 seconds]
<jonmason>
I even have data on using multiple dockers
<jonmason>
had a fun instance where 32 dockers were 10x faster..then I looked and saw OOMs and killing of containers :)
<RP>
jonmason: I should plug a power meter into my system. I can tell what the overall house consumption is...
<jonmason>
it can be commandline controlled via python-kasa
<jonmason>
there are strips too, but it only monitors the usage for the whole strip, even though the plugs are individually addressable for on/off
<jonmason>
I'm going to put a stip on my build systems, but I'm scared to see how much it's using. my electric bill was 1/4 when I was on my sabbatical (with all the computers off and no electric cars being charged)
altru has quit [Quit: Client closed]
<RP>
I can tell when mine is running from the house monitor
<jonmason>
lol, turns into a fan because it's spinning so fast?
<RP>
It has orange and red bits on the usage chart
<RP>
I've wondered about trying the switch functionality on these to do things like power up/down a compressor but I'm not sure they'd handle a large resistive load at 13A that well
tnovotny has quit [Quit: Leaving]
enok has joined #yocto
linfax has quit [Ping timeout: 240 seconds]
zpfvo has quit [Remote host closed the connection]
MrCryo has quit [Remote host closed the connection]
tangofoxtrot has quit [Remote host closed the connection]
tangofoxtrot has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
frieder has quit [Remote host closed the connection]
thomas81 has joined #yocto
enok has quit [Ping timeout: 240 seconds]
thomas81 has left #yocto [#yocto]
florian_kc has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
alperak has quit [Quit: Connection closed for inactivity]
<tgamblin>
kanavin: do you use the testimage feature with AUH?
<kanavin>
tgamblin, no
<kanavin>
too brittle for mass-updates in oe-core
<tgamblin>
kanavin: ah. I'm running into an error when testimage tries to start :)
alessioigor has quit [Quit: Client closed]
<kanavin>
tgamblin, it's also not entirely obvious how to make it useful when the goal is to go over every recipe in core and try to update them one by one
<kanavin>
I kind of inherited auh from someone else, I fixed it up to serve that goal in okay-ish kind of way, but I'd probably write it entirely differently myself.
<tgamblin>
kanavin: it'd be useful for me at least since a lot of the recipes with my name on them are Python modules that have (or could have) ptests added
<kanavin>
tgamblin, patches welcome (and without hidden meanings or irony :)
<tgamblin>
kanavin: indeed, I'm sure I'll be sending more
enok has joined #yocto
mbulut has joined #yocto
<khem>
RP: master-next bitbake is showing long time between parse and starting task execution
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<RP>
khem: I think it has been doing this for a while
OnkelUlla has quit [Remote host closed the connection]
dankm has quit [Remote host closed the connection]
vthor has quit [Ping timeout: 240 seconds]
OnkelUlla has joined #yocto
dankm has joined #yocto
toric has quit [Read error: Connection reset by peer]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
enok has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #yocto
tangofoxtrot has quit [Ping timeout: 255 seconds]
leonanavi has joined #yocto
leon-anavi has quit [Read error: Connection reset by peer]
tangofoxtrot has joined #yocto
vthor has quit [Ping timeout: 240 seconds]
leon-anavi has joined #yocto
leonanavi has quit [Ping timeout: 252 seconds]
leon-anavi has quit [Quit: Leaving]
<khem>
RP: I am just startting to see it since yesterday
florian_kc has quit [Ping timeout: 240 seconds]
<RP>
khem: is this with or without a hashequiv server?
<khem>
BB_HASHSERVE = "auto"
<khem>
BB_SIGNATURE_HANDLER = "OEEquivHash"
<RP>
khem: so just a local hashserve. I'll look into it tomorrow, I've probably broken something else :(
<khem>
right
<RP>
khem: I'd be interested to know if current -next is any better or not
<RP>
I potentially fixed one issue but I'm not sure if I've done well enough or not
<khem>
still similar
<RP>
khem: Can you run bitbake with the -P option unti the tasks start , stop it and share the profile data?
<RP>
khem: I'm not interested in the parsing ones but the others
<RP>
khem: I queued a mingw test btw. Will the gcc fix just fix the gcc failure or the other failures too for mingw?
ray-san has quit [Ping timeout: 268 seconds]
mbulut has quit [Remote host closed the connection]