ello_ has quit [Read error: Connection reset by peer]
ello has joined #yocto
zeemate has joined #yocto
LainIwakura has joined #yocto
florian has joined #yocto
LainIwakura has quit [Ping timeout: 272 seconds]
<Jones42>
Hi, Is there a way for the image-recipe to query the PV of an installed package? I know that recipes are usually built independently from each other, but the image recipe itself should know the versions, since they end up in the image manifest files, no?
<rburton>
Jones42: you can look at the image manifest after the rootfs has been populated, sure
<rburton>
Tartarus: well, is .wic a file format? it's just a name we use for gtp disk images.
frieder has joined #yocto
mbulut has joined #yocto
<mbulut>
playing with meta-rust and cargo bitbake on yocto scarthgap, i found that do_fetch complains about missing SRC_URI checksums for a long list of dependencies...
<rburton>
mbulut: probably best to speak to the meta-rust maintainer directly
<mbulut>
it suggests you to pin those checksums, even provides you with the list so you could easily copy paste it into the recipe
<rburton>
its standard for rust recipes to have a huge .inc with the crate list
<mbulut>
yeah that's one of the options i came across so far. another is said to be vendoring -- i.e. use cargo vendor to bundle deps into a tarball and only checksum that... i was wondering which is more common among rust recipes
mckoan is now known as mckoan|away
<rburton>
big inc file
<rburton>
for rust and scarthgap, you don't need meta-rust at all
<mbulut>
ok thx, that's what i was leaning against too but wasn't too sure tbh
<rburton>
there's even a cargo-update-recipe-crates class in oe-core to just handle this for you
LainIwakura has joined #yocto
<mbulut>
oh, really? i just came here from watching a 4 year old YS session with paulbarker :)
<rburton>
a four year old presentation when scarthgap is barely over one might not be the best idea :)
<mbulut>
hey better than watching Reacher on netflix innit
ablu has quit [Ping timeout: 276 seconds]
<mbulut>
ok seems like the rust toolchain on meta-rust:scarthgap is at least newer which might be a reason to not ditch it right away
<mbulut>
1.75 vs 1.82
ablu has joined #yocto
<paulbarker>
mbulut: the tooling has definitely improved since I did that talk!
<mbulut>
yeah apart the dependency checksums i haven't run into any issues yet
<mbulut>
only minor thing that caught my eye is that cargo bitbake generates SRC_RUI for the git fetcher with both 'nobranch=1' and 'branch=xyz' set... doesn't break anything but also disables -- not sure if that's intended
<mbulut>
rburton, thx for hinting on cargo-update-recipe-crates, very useful! I was on scarthgap-5.0.2 which didn't yet have it
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
LainIwakura has quit [Ping timeout: 272 seconds]
savolla has quit [Quit: WeeChat 4.6.3]
savolla has joined #yocto
savolla has quit [Client Quit]
savolla has joined #yocto
belsirk has joined #yocto
rfuentess has quit [Ping timeout: 276 seconds]
lexano has quit [Remote host closed the connection]
RyanEatmon has quit [Remote host closed the connection]
RyanEatmon has joined #yocto
lexano has joined #yocto
<LetoThe2nd>
random rant: just looking a bit into the pigen script for $work reasons, and this thing takes 20-30minutes to build an image from a binary distro?!? I mean, basically that's hot sstate. on a box that easily does the same in 5 minutes or less with Yocto.
florian__ has joined #yocto
<rburton>
khem: why does clang-cross copy the clang binaries from clang-native?
<Tartarus>
khem: Er? Am I missing something on how you use a .wic to describe the image to make and get out a file ending in .img (or .img.xz, etc) and not .wic ? That's part of the same question fwiw, rburton
<Tartarus>
(The high level problem is, OE is spitting out some-image.wic and then people want to EFI http(s) boot that, but since the filename ends in .wic and not .img, it's not checked as a valid disk image. Someone posted a patch to have U-Boot check .wic too, and part of the feedback was that it looks like EDK II also doesn't do anything smart like check the memory location it just wrote something to, to see what it is and instead goes by
<Tartarus>
filename extension)
<RP>
Tartarus: the issue is probably that our generation code uses the extension to map to the code which generates it
<RP>
Tartarus: whether you can configure the wic image generation code to use a different one, I don't know
<Tartarus>
Yeah, see that's what I kinda assumed
<Tartarus>
You'd have to play some silly games to symlink image.img to image.wic
rob_w has quit [Remote host closed the connection]
vladest has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<rburton>
Tartarus: the .wks file is the image description, the .wic is the disk image itself. bit silly that tools check the filename, but you can trivially make a symlink
<Tartarus>
Yes, or the tool could have used a standard extension a decade ago
<Tartarus>
At the end of the day, shrug. I agree with the suggestion that we (U-Boot) should try and be smarter and look at the contents, not the filename, so hopefully that's easy enough
<Tartarus>
No idea how EDK II will handle the issue.
pidge_ has joined #yocto
<rburton>
khem: can you look at poky-contrib:ross/lld and see if its sensible to you. i can't see why the clang-cross recipe does what it does, but it seems like the right place (for now) to add the lld dependency. glorious future can involve a virtual/cross-linker variable...
Jones42 has quit [Ping timeout: 248 seconds]
pidge has quit [Ping timeout: 240 seconds]
Jones42 has joined #yocto
* mcfrisk
is affected by the .img and .wic issue, currently we rename files in CI due to this
<rburton>
my concern about making wic spit out .img files would be 'what if we wanted to use something else to make disk images'
<rburton>
but it can't be difficult to get wic to spit out symlinks if needed
Jones42 has quit [Ping timeout: 276 seconds]
Jones42 has joined #yocto
LainIwakura has quit [Ping timeout: 272 seconds]
frieder has quit [Remote host closed the connection]
<khem>
rburton:unlike gcc, cross and crossdk recipes are just glues on top of clang-native and nativesdk-clang and somewhere symlinking across recipes sysroot did not work
<khem>
the symlinks are fine as long as they did not get into staging sysroot requirements, which is what happened here, maybe relative symlinks could solve it I dont know