<PhoenixMage>
I am trying to use UBOOT_MKIMAGE outside of kernel-fitimage, the variable is populated but the binary cant be found, do I need to set a PATH or something equivelent for it to be found?
sakoman has quit [Quit: Leaving.]
Zappan has quit [Server closed connection]
Zappan has joined #yocto
Thorn has quit [Ping timeout: 246 seconds]
patersonc[m] has quit [Server closed connection]
patersonc[m] has joined #yocto
Thorn has joined #yocto
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #yocto
nerdboy has quit [Ping timeout: 258 seconds]
sakoman has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
nerdboy has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
Ablu has quit [Server closed connection]
Ablu has joined #yocto
wooosaiiii has joined #yocto
lrusak[m] has quit [Server closed connection]
lrusak[m] has joined #yocto
<PhoenixMage>
Forget to add a DEPENDS... On a weird note first time I run the recipe it fails, second time it succeeds, why would that be? Some sort of race condition?
<rburton>
fneddy[m]: they're identical, and the readme says the official location is github, so it probably was on yocto first, moved to github, but they keep the yocto repo mirrored
<rburton>
TRO[m]: :remove the one you want to get rid of, :prepend the new one
Salamandar has quit [Server closed connection]
Salamandar has joined #yocto
<TRO[m]>
rburton: yes, then you have to know what you are looking for. Or does this suppport any regex? I try now getvar -> regex -> modify -> replace string... which is, not good.
<rburton>
no
<rburton>
you probably can use some anon python to mangle the SRC_URI during parse
<rburton>
but if you really need to do this then design the recipe to allow it. I'm guessing the case is "i want to get code from an internal mirror not upstream"?
<TRO[m]>
Yes, and yes, then the devtool autoupgrade will probably fail.
<rburton>
some of the meta-arm firmware recipes have a variable for the git base url, because it's known that many people like to fork tfa for their bsp
<TRO[m]>
good to know, but ideally I do not want to modify the recipe to fit this use case. I just want to replace a string - might I go for - having the original string and replacement string as a parameter. Easier for now.
<rburton>
if its for development purposes then externalsrc _might_ be useful
amsobr has joined #yocto
<TRO[m]>
Yes, might as well - really depends on the use case. My initial idea was just have a small tool that others can include in their CI to see if the recipe build and pass ptests (for meta-aws).
<Martin42>
Hello community, I have a question about the SSTATE cache. I have a network share which hosts the SSTATE cache for my builds. Every night a jenkins server runs a nightly build (which points to that SSTATE cache using SSTATE_MIRRORS ). After the nightly is done, I would like to update the SSTATE cache with the latest changes.
<Martin42>
What is the best practice here? Delete the old SSTATE from the network share and replace with the latest sstate folder from the build, or just copy the new sstate from the build into the existing network share (thus updating the existing sstae). Thanks and best greeting!
<rburton>
Martin42: rsync the new files into the remote cache
adrianf_ has joined #yocto
adrianf has quit [Remote host closed the connection]
<Martin42>
rburton thanks! Do you mean rsync with removal of obsolete files on the network share (like rm -rf network-share/, cp -r sstate-cache/ network-share/), or just rsync like cp?
<rburton>
keep old files
<rburton>
you can delete unread files after a month if you wish
<rburton>
"obsolete" is a strong word for a nightly build
<rburton>
eg if librsvg came from sstate then you won't even need to fetch rust-native but you _really_ want to keep rust-native around
<Martin42>
rburton true, obsolete is a little overkill here! :) thanks alot! Side question: does this apply the same way for a RPM package feed?
<rburton>
no, but you can always regenerate that from sstate.
<rburton>
but feeds are harder
<Martin42>
Thanks! :)
Vonter has quit [Server closed connection]
Vonter has joined #yocto
amitk has joined #yocto
adrianf_ has quit [Ping timeout: 240 seconds]
adrianf has joined #yocto
jpanisbl has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
Alban[m]1 has joined #yocto
kpo has quit [Ping timeout: 246 seconds]
xmn has joined #yocto
Guest98 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 245 seconds]
Guest98 has joined #yocto
nemik has joined #yocto
<Alban[m]1>
Hi! On my project I'm seeing random build failure with do_package_setscene failing because of useradd that depend on the pulse group. The failing package already has DEPENDS on pulseaudio and RDEPENDS on pulseaudio and pulseaudio-server packages. Is there anything else that is needed?
<Alban[m]1>
It is breaking about 10% of our CI build so I expect it is down to some ordering problem depending on which packages get restored from sstate or not
<rburton>
Alban[m]1: you need something like PACKAGE_WRITE_DEPS += "pulseaudio". If the rebuild is _just_ repackaging then pulseaudio might not be in the sysroot but you need it for the pulse user.
<Alban[m]1>
The package create a user that need to be in pulse group. I'll test that but shouldn't the useradd class do it automatically?
<rburton>
well you're not telling us what the error is, so we're guessing here
<rburton>
but no, useradd doesn't know what recipe provides a group that you're trying to be a member of
<Alban[m]1>
do_package_setscene fail and in the log it has: useradd: group 'pulse' does not exist
<Alban[m]1>
PACKAGE_WRITE_DEPS seems exactly like what I need, thanks for the quick help
<smurray>
rburton: I had been thinking that any recipe that needs a user or group needs to configure useradd for it? And I don't see anything in the PACKAGE_WRITE_DEPS description that suggests it'd be used this way?
<rburton>
halstead: ^ see yocton. is there an irc logger active anywhere?
<rburton>
smurray: the system has a few users preconfigured but things like 'pulse' need magic. magic sstate is to blame here :) if there wasn't a way to pull do_package out of sstate and rebuild the packages from that, we wouldn't need this. but you're right, absolutely should be documented.
<halstead>
Thanks rburton. yocton: vacation day for me but I can get the link fixed tomorrow.
<rburton>
halstead: if you know the right url for the logger we can run around fixing the references :)
<smurray>
rburton: tbh, none of the use of PACKAGE_WRITE_DEPS in oe-core really jumps out at me as being to ensure a user/group is present. If it does that, there'd almost seem to be some potential cleanup wrt some of the polkit rules recipe stuff
<rburton>
halstead: i recommend the Patriot burger at Kandelábr for dinner tonight ;)
<halstead>
yocton: qschulz had an alternative I think. That might be available right now but I don't have the url.
torbenh3 has quit [Ping timeout: 260 seconds]
<rburton>
halstead: thanks
<yocton>
halstead: thx! Enjoy your vacation :)
<halstead>
The logs are still being kept. Just inaccessible at the moment.
<sudip>
huh, you all are still in Prague
<rburton>
sudip: only a few left
<halstead>
I am. It's nice to avoid the explosions at home. I miss the BBQ, zipline, and trampoline though.
<Alban[m]1>
rburton: PACKAGE_WRITE_DEPS has not helped, but I found USERADDSETSCENEDEPS and after adding pulseaudio:do_populate_sysroot_setscene my build did got through
amitk has joined #yocto
jpanisbl has quit [Quit: Konversation terminated!]
<rburton>
which has buried in it: "A lot of people have vacation booked for next week so we’re planning to skip a week with status reports and project meetings."
<amsobr>
thanks. I should've remembered to have a look at the minute from the last meeting, right :)
sakoman has joined #yocto
fuzzybear62 has quit [Quit: Client closed]
adrianf has quit [Ping timeout: 264 seconds]
amitk has quit [Ping timeout: 246 seconds]
adrianf has joined #yocto
adrianf has quit [Read error: Connection reset by peer]
amitk has joined #yocto
<rburton>
sakoman: trawling through list mail, did you catch "[OE-core] [PATCH] linux-yocto/5.4: cfg: fix DECNET configuration warning". it wasn't marked but was meant for a stable release