<CosmicPenguin>
Long shot but has anybody tried QEMU+OVMF with systemd-boot v254? v253 works, but v254 version of systemd-bootx64.efi won't load. OVMF code implies this might be a corrupted file. There are objdump differences but nothing that would scream breakage.
ablu has quit [Ping timeout: 276 seconds]
ablu has joined #yocto
Daanct12 has joined #yocto
jclsn has quit [Ping timeout: 268 seconds]
jclsn has joined #yocto
sgw has quit [Quit: Leaving.]
mvlad has quit [Remote host closed the connection]
<khem>
CosmicPenguin: check the starting address do they match
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
alessioigor has quit [Read error: Connection reset by peer]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
ray-san has quit [Ping timeout: 255 seconds]
alessioigor has joined #yocto
alperak has joined #yocto
<alperak>
morning
leon-anavi has joined #yocto
ray-san has joined #yocto
jmd has quit [Remote host closed the connection]
lthadeus has quit [Ping timeout: 245 seconds]
rob_w has joined #yocto
lthadeus has joined #yocto
amitk has quit [Remote host closed the connection]
amitk has joined #yocto
mckoan|away is now known as mckoan
Chaser has quit [Quit: Chaser]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
frieder has joined #yocto
Kubu_work has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
lthadeus has quit [Ping timeout: 260 seconds]
lthadeus has joined #yocto
lexano has quit [Ping timeout: 245 seconds]
xmn has quit [Quit: ZZZzzz…]
lexano has joined #yocto
gsalazar_ has joined #yocto
manuel1985 has joined #yocto
lthadeus has quit [Remote host closed the connection]
Guest74 has joined #yocto
Chaser has joined #yocto
Chaser_ has joined #yocto
Chaser has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tnovotny has joined #yocto
prabhakarlad has joined #yocto
jmiehe has joined #yocto
prabhakar has joined #yocto
jmiehe has quit [Client Quit]
d-s-e has joined #yocto
mbulut_ has joined #yocto
manuel_ has joined #yocto
egueli-AV has joined #yocto
<d-s-e>
Hi, I'm going crazy while trying to build multiple packages from one recipe. I did this several times before, but this time it's not working. I have a recipe foo, that builds the package foo. Now I added a FILES:bar="..." and also added bar to PACKAGES. When I look into work/.../packages-split/ after the build, a folder bar has been created, but the files for bar are installed in the foo folder. How can I fix this (on kirkstone)?
manuel1985 has quit [Ping timeout: 240 seconds]
<alessioigor>
Hi all If I make a little trivial change to toolchain-shar-extract.sh the SDK installation (not generation) fails: etting it up.../opt/poky/3.1.29/sysroots/x86_64-pokysdk-linux/usr/bin/python3: line 5: /opt/poky/3.1.29/sysroots/x86_64-pokysdk-linux/usr/bin/python3.8.real: No such file or directory
<alessioigor>
post-relocate command "/opt/poky/3.1.29/sysroots/x86_64-pokysdk-linux/post-relocate-setup.d/meson-setup.py /opt/poky/3.1.29" failed with status 127
<alessioigor>
/usr/bin/python: can't open file '/opt/poky/3.1.29/relocate_sdk.py': [Errno 2] No such file or directory
<alessioigor>
SDK could not be set up. Relocate script failed. Abort!
<alessioigor>
Sorry my mistake.
prabhakar has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
kalj has joined #yocto
mvlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Chaser_ has quit [Remote host closed the connection]
Chaser has joined #yocto
alperak has quit [Quit: Client closed]
<rburton>
d-s-e: packaging works through the packages in the order listed in PACKAGES. if foo is before bar and includes the files then they won't be in bar.
kalj has quit [Quit: Client closed]
Saur_Home3 has quit [Quit: Client closed]
alperak has joined #yocto
Saur_Home3 has joined #yocto
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<d-s-e>
rburton: Ok, that fixes it, thanks. But in other recipes I used PACKAGES += " bar" and it worked.
mbulut_ has quit [Remote host closed the connection]
mbulut has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
<rburton>
d-s-e: what i said continues to apply
starblue has joined #yocto
<KanjiMonster>
d-s-e: some types of files are automatically added to/consumed by the default package (e.g. binaries), maybe your other recipe's bar didn't include them?
<rburton>
FILES:${PN} is quite large so it does by default pick a lot of files
amitk has quit [Ping timeout: 245 seconds]
<d-s-e>
rburton: Oh, I see a difference in the recipes: In one I wrote FILES:${PN} = "..." and in the other FILES:${PN} += "...". So FILES is prepopulated before I set it? Those packages contain only some shell scripts and data files, no binaries or a compile step.
<rburton>
yeah see bitbake.conf
<rburton>
and well every recipe that doesn't list every files in FILES
<rburton>
without writing any FILES you get binaries, actual shared libraries, and data files in PN. headers and unversioned library symlinks in PN-dev, debug symbols in PN-dbg, and documentation in PN-doc. Having to write that out for _every_ recipe would be very boring.
amitk has joined #yocto
<d-s-e>
rburton: Yes, that totally makes sense. I tend to forget that when I have to deal with recipes where nothing is compiled. Thanks for pointing this out :-)
gsalazar_ has quit [Ping timeout: 276 seconds]
goliath has joined #yocto
* kanavin
still has 27 recipes in meta-oe to fix so they don't break with python 3.12
<kanavin>
I'll set this aside for now
<kanavin>
3.12 has removed many deprecated modules and api items, as they have warned for years, and it just doesn't help. deprecation warnings are largely useless :(
<rburton>
pidge: the actual test is more your code than mine
<pidge>
Ah, I'm considering you coauthor at least. It's based off your WIP test
<pidge>
egueli-AV are you around?
leonanavi has joined #yocto
tnovotny has quit [Quit: Leaving]
rfuentess has joined #yocto
<leonanavi>
hi sakoman, does it make sense to add debian-12 to the list of supported distributions in variable SANITY_TESTED_DISTROS for Yocto LTS release Kirkstone?
alessioigor has quit [Quit: alessioigor]
arisut has quit [Quit: install gentoo]
alessioigor has joined #yocto
arisut has joined #yocto
<leonanavi>
I am asking because I ran into a situation where the latest version of kas-container comes with docker container based on debian 12 which triggers an annoying warning for host distribution "debian-12".
<sakoman>
leonanavi: it is *probably* ok, but I'll need to enable autobuilder testing on that distro for a while to make sure
<moto-timo>
given how much longer 'kirkstone' will be supported, it probably makes sense?
<moto-timo>
4.0.15 change type of concept?
ray-san has quit [Ping timeout: 264 seconds]
<CosmicPenguin>
khem: in fact, they do not match
<leonanavi>
sakoman, moto-timo should I send a patch to add debian-12 to SANITY_TESTED_DISTROS in Kirkstone? I will be happy to do it but I am not aware of the big picture for Kirkstone therefore I prefer to ask first.
<sakoman>
leonanavi: no need, I need to enable the autobuilder testing first
<leonanavi>
ok
<moto-timo>
kanavin: did/can you send the list of 27 to the oe-devel mailing list?
<kanavin>
moto-timo, yes, a bit later today
<moto-timo>
kanavin: thank you. You don't have to do this alone ;)
<paulg>
so here is a strange bug. buildtools doesn't seem to work when target arch matches host arch. The pseudo build gets all angry. I think it is pseudo's fault. Default buildtools is 4.1 ; I manually installed a 3.4 and a 3.0 and it was the same.
<paulg>
I've got a an ubu-16.04 building beaglebone on master ; and the 18.04 machine was fine with building i386
Guest26 has quit [Quit: Client closed]
<paulg>
but try and use buildtools on x86-64 to build x86-64 target and pseudo build spits the dummy
<paulg>
undefined reference to `_dl_addr@GLIBC_PRIVATE'
<paulg>
undefined reference to `pow@GLIBC_2.29'
<rburton>
the AB tests that combination so it should work...
d-s-e has quit [Quit: Konversation terminated!]
<paulg>
and a bunch more similar ones. I'm going to test on ubu-20.04 with buildtools, since that *doesn't* actually need buildtools
<paulg>
see if that gives me a hint as to what is going on. I don't *need* to be using these old machines but it was/is cold outside.
rfuentess has quit [Remote host closed the connection]
sotaoverride has quit [Killed (osmium.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
sotaover1ide has joined #yocto
<kanavin>
moto-timo, done
<moto-timo>
kanavin: it might also be a nice easy reason to drop some old cruft ;)
<moto-timo>
kanavin: thank you for all the work you've done already
<kanavin>
moto-timo, I dropped a couple dead projects yes :)
zpfvo has quit [Ping timeout: 264 seconds]
zpfvo has joined #yocto
<kanavin>
tgamblin, you might be interested in these too perhaps
jmd has joined #yocto
<tgamblin>
kanavin: thanks for the heads-up. I'm wondering if 3.12.0 will cause any issues like what we're seeing with F39 systems?
<tgamblin>
s/cause any issues/cause any issues with target images/
<moto-timo>
tgamblin: likely to be the same patterns yes
<kanavin>
tgamblin, a-full passed
zpfvo has quit [Ping timeout: 252 seconds]
<kanavin>
but I did have to backport something asyncio related I think
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
<tgamblin>
kanavin: moto-timo: alright
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #yocto
Guest74 has quit [Quit: Client closed]
<vmeson>
pidge: recent build, in my sstate-cache dir: ls */ -la | grep drwxr-xr-x | wc -l -> 257 -- all ".." directories.
<landgraf>
vmeson: same here
<vmeson>
pidge in an older sstate-cache dir, 301 matches, 43 of which are not ".." directories.
<vmeson>
$ umask -> 0022 fyi.
<landgraf>
TIL: find has '-perm' flag :)
yudjinn has joined #yocto
<yudjinn>
hello, where can I find a list of changes that I need to apply to update from kirkstone -> scarthgap?
<pidge>
vmeson: Any of them happen to contain nativesdk bits?
<RP>
paulg: that is weird because as rburton says, we test with this a lot
<vmeson>
pidge: I'll check after this call..
manuel_ has quit [Ping timeout: 276 seconds]
<pidge>
ty, vmeson
<RP>
paulg: how does uninative compare with your buildtools version. It might be something related to that. Have you tried a recent buildtools?
<paulg>
everything is the latest on master - I don't screw with older stuff or company stuff when it is on my personal kit.
<RP>
paulg: try a 4.3 buildtools ?
<RP>
I'm guessing latest uninative with old buildtools may end badly
<paulg>
It *looks* like it "works" when you overlay buildtools on a supported ubu-20.04 that doesn't really need it but 'cause I'm task switching I need to go back and be sure I sourced the buildtools file...
<RP>
4.1 really shouldn't be the default buildltools :(
<paulg>
and 4.1 is what the script gets by default ; I went backwards to 3.4 and 3.0 but not forward..
<RP>
paulg: the script is wrong :(
<paulg>
I'll take your word for it. Rather than learn the cmd syntax I just went and found the .sh files for 3.4 and 3.0 and wget'ed them.
<yudjinn>
yocton: I'm hoping to get a little ahead and see what kind of lift it'll be, any way I can see the preliminary changes that may happen? i.e. syntax
<yocton>
yudjinn: maybe look at migration guides for release between kirkstone and the future scarthgap? by the way, I believe there was no major syntax changes between those two
mckoan is now known as mckoan|away
<yudjinn>
yocton: is `master` or `master-next` going to be scarthgap?
<yocton>
yudjinn: master-next does become master after maintainer tests and merging, master will become scarthgap at release (~April next year)
<frosteyes>
sakoman: just answered your question regarding gstreamer1.0-plugins-base backport to kirkstone - hope it make sense why I suggest to have it backported
<sakoman>
frosteyes: thanks, I just wanted to make sure it was an issue in stock kirkstone
<frosteyes>
sakoman: for me - it is more some qt apps using qmlgl, but root cause is the same - where Alexander had a very nice fix.
<paulg>
yep, the 4.1 buildtools works when layered onto ubu-20.04 ; just doesn't like ubu-18.04 ; I'll try 4.3 just for laughs. probably not worth spending a lot of time on it as I think it was dropped here when Ubuntu made it EOL in April...
<paulg>
RP told me about some "developer" knob that would default to fetch via git -- cater to ppl who update daily -- meant to go check that out ; now I can't even remember what it was called...
<vmeson>
paulg: on poky/master I get a git repo: downloads/git2/github.com.llvm.llvm-project.git -- what branch are you on?
<paulg>
guessing it only worked for recipes that were written for "dual fetch" support.
<paulg>
I've got that too. But it is native that screws you --- llvm-native-17.0.6-r0
<rburton>
paulg: thats premirrors, which have been disabled for ages
<paulg>
rburton, no surprise - probably was 2-3 years or more when RP told me about it
<paulg>
I have *no* idea why the native triggers going for a tarball over git. They look about the same size.
<paulg>
paul@o960:~/poky/downloads$ ls -ld git2/github.com.llvm.llvm-project.git
<paulg>
drwxr-xr-x 7 paul paul 4096 Dec 1 00:14 git2/github.com.llvm.llvm-project.git
<paulg>
paul@o960:~/poky/downloads$ du -csh git2/github.com.llvm.llvm-project.git
<paulg>
6.2Ggit2/github.com.llvm.llvm-project.git
<paulg>
I don't know enough about llvm to know if there is some subtle difference - a fork or whatever? Don't really want to know. But 12GB for llvm is nutz!!
<paulg>
Oh, I bet we expanded the tarball inside the downloads dir? Just a guess.
<rburton>
paulg: does your local.conf set PREMIRRORS or use own-mirrors?
<rburton>
paulg: llvm shouldn't be hitting the premirror afaik
<paulg>
I'll have to look - thing is probably ancient
<paulg>
or wait - it might be the autogenerated one just a week old at most.
<paulg>
I'm shuffling machines around and dont know what is where....
<Saur>
Maybe llvm-native should be configured with BB_GIT_SHALLOW:pn-llvm-native = "1" in meta/classes-global/mirrors.bbclass just like glibc and binutils?
<paulg>
no PREMIRRORS set and I've never set up a local mirror at home.
jpuhlman has quit [Ping timeout: 240 seconds]
<Saur>
At least that way, the tarball won't be as huge (hopefully)...
<Saur>
paulg: Do you have any problems accessing the remote git repository, so that it is hitting the MIRRORS instead?
<paulg>
oh yeah - look at that ; had to scroll up to see it.
<paulg>
WARNING: llvm-native-17.0.6-r0 do_fetch: Failed to fetch URL git://github.com/llvm/llvm-project.git;branch=release/17.x;protocol=https, attempting MIRRORS if available
<Saur>
There's your answer. :)
<paulg>
damn thing should have tried harder!!!
<paulg>
Or at least tried twice.
<paulg>
cable internet, so I don't know why it would glitch. Maybe it was github?
<paulg>
Not that I'm saying cable internet is perfect!
zpfvo has quit [Ping timeout: 264 seconds]
neverpanic has quit [Quit: .]
neverpanic has joined #yocto
zpfvo has joined #yocto
florian__ has joined #yocto
jpuhlman has joined #yocto
Minvera has joined #yocto
zpfvo has quit [Remote host closed the connection]
zpfvo has joined #yocto
gsalazar_ has joined #yocto
zpfvo has quit [Quit: Leaving.]
gsalazar_ has quit [Ping timeout: 256 seconds]
Saur_Home3 has quit [Quit: Client closed]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
<vmeson>
pidge: ugh, meetings, lunch, co-workers bitching about bloatware problems... ;-) ( a shallow clone of llvm rust-llvm rust, etc seems like a good idea).
<vmeson>
pidge: anyway, no nativesdk according to: for i in `ls */ -la | grep drwxr-xr-x | rg -v "\.\." | rev | cut -c -2 | rev `; do fd nativesdk $i; done
<vmeson>
err, that's not quite right... please hold...
<vmeson>
pidge: heh, there are no nativesdk sstate objects in my sstate-cache... that's not something I work on very often.
<vmeson>
from : for i in `find * -type d -perm 755`; do find $i -name "*nativesdk*"; done -- nothing so sanity check: fd nativesdk -> also zilch!
* vmeson
thinks of telling the story about Gammasphere and the charming young Brazilian physicist telling him to always check if the detector is on! Maybe over beer some time.
Saur_Home has joined #yocto
frieder has quit [Remote host closed the connection]
leon-anavi has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<warthog9>
Anyone know how to muck about with a partition after wic/wks has created it and put a bunch of stuff in it? Specifically I need to go and remove a file and put a custom grub.cfg in place, but so far the ways I've tried have been utterly unsuccessful - mostly wondering if anyone else has done it and has a pointer?
<JPEW>
warthog9: We've done some things kinda like that with a custom wic plugin
<JPEW>
(depending on what you need to do)
<warthog9>
yeah I could extend bootimg-efi.py to make use of the do_post_partition() (pretty sure that's right) but was vaguely hoping to avoid that
amitk has quit [Ping timeout: 245 seconds]
mvlad has quit [Remote host closed the connection]
jmd has quit [Remote host closed the connection]
alessioigor has joined #yocto
pabigot has joined #yocto
Saur_Home43 has joined #yocto
sgw has joined #yocto
Xywzel has quit [Ping timeout: 255 seconds]
mcfrisk_ has quit [Ping timeout: 255 seconds]
mcfrisk has joined #yocto
Saur_Home has quit [Ping timeout: 250 seconds]
Xywzel has joined #yocto
mbulut has quit [Ping timeout: 256 seconds]
tlwoerner has quit [Quit: Leaving]
tlwoerner has joined #yocto
alessioigor has quit [Quit: alessioigor]
yudjinn has quit [Quit: Changing server]
yudjinn has joined #yocto
yudjinn has quit [Client Quit]
yudjinn has joined #yocto
<moto-timo>
warthog9: there is a copy command for wic... it just copies files into an existing partition. I haven't used that in a while.
gsalazar_ has joined #yocto
<moto-timo>
warthog9: also, IMHO a lot of the old assumptions about grub and efi are showing some age... but nobody stops to rework it from the original source... just bandaids.
<RP>
paulg: it tried the git repo, it failed, it went for the mirror tarball which it would extract a git repo from. Why the original clone failed, no idea
<RP>
paulg: I had to read the scrollback to see what you were blaming me for now :)
<paulg>
Hey! This time I was giving you credit for sharing a tip! :-P
<rburton>
warthog9: JPEW: i'm wondering if we should just allow ESPs to be normal images. package for the boot loader, package for efi shell, packages for kernels, etc.
gsalazar_ has quit [Ping timeout: 255 seconds]
jmiehe has joined #yocto
sgw has quit [Quit: Leaving.]
DaveNuge has quit [Ping timeout: 250 seconds]
<warthog9>
rburton: yeah I'm fighting with an ESP specifically, basically replicating what Fedora's doing on EFI to get just enough to pass the boot process off to a more easily accessible partition
<warthog9>
I got it working with the caveat there's a leftover Image file stashed in the ESP that I haven't figured out how to properly delete
<khem>
paulg: building master on ubuntu 18.04 and below is adventure I would guess
<warthog9>
rburton: I'm also running into wonkiness trying to separate /boot from / on the system and appropriately populate them so they mesh back up after boot
<rburton>
right
<rburton>
just admiting that /boot is basically an entirely separate system seems sensible
<warthog9>
yeah EFI is it's own mess, /boot is a different separate mess then / and the rest is isolated enough from the mess of booting
<warthog9>
(at least that's how I'm treating it)
<warthog9>
(and mostly because I'm dealing with u-boot -> UEFI -> Grub -> system)
<warthog9>
(for reasons)
<rburton>
that does make it 'fun'
<warthog9>
context: someone who wasn't me defined the entire system should only boot from EMMC, and the EMMC is utterly obnoxious to deal with from a production stand point (could have told them, but I was late to that party)
<warthog9>
so EFI gets stashed on the EMMC to chain load to grub on an sdcard
Piraty has quit [Quit: -]
<warthog9>
and off to the races from there
Piraty has joined #yocto
<khem>
why SD card and emmc both involved in boot, grub could reside on emmc too
Estrella__ has quit [Ping timeout: 256 seconds]
<warthog9>
khem: I've got grub on the emmc, just enough to load the next grub config from the sdcard
<warthog9>
effectively grub on the emmc does all of: configfile $prefix/grub.cfg
<warthog9>
and jumps off
<khem>
OK so it seems you are trying to use as little of emmc and switch to SD card in boot process
<warthog9>
yup
<khem>
I was thinking you have good sized emmc so use emmc all the way
<warthog9>
8G
<warthog9>
the real problem is dealing with the EMMC from a production physical build is problematic
<warthog9>
and it's a lot easier to prep the emmc with enough to boot to sd and then pop an sd card in
<khem>
have a SD card installer which can partition and install the OS into it during manufecturing/factory
Estrella has joined #yocto
<warthog9>
khem: as noted, the hardware guy made it so it only can boot from emmc in the factory
<khem>
oh so you can basically brick it if emmc is hosed ?
<warthog9>
YUP
<khem>
good lord
<warthog9>
thus: emmc to boot and do next to no writes to to prevent bricking the system
<paulg>
khem - it actually does better than I thought it would!
<warthog9>
I've got a laundry list of fixes for the platform ;-)
Saur_Home44 has joined #yocto
Piraty has quit [Quit: -]
Piraty has joined #yocto
Saur_Home43 has quit [Ping timeout: 250 seconds]
<RP>
khem: we test on 1804 still!
joekale has quit [Ping timeout: 245 seconds]
<landgraf>
RP: SRC_URL bug (the one I've stolen from you today) has been fixed already :(
<landgraf>
and it was not caused by SRC_URL typo...
<RP>
landgraf: it has? were we missing a backport somewhere? I hadn't looked into it at all, just sounded worrying