<tgamblin>
Smokey: have you done "bitbake -e secure-core-image | grep PACKAGE_CLASSES" to see what it's set to?
<smokey>
I am explicitly setting PACKAGE_CLASSES = "package_rpm" in conf/auto.conf
<tgamblin>
It's possible it could be getting reset elsewhere, so it helps to run bitbake -e and see what the variable is actually set to when bitbake goes to build the image
<smokey>
unfortunately, bitbake errors out when I run bitbake -e. Any suggestions?
<tgamblin>
Smokey: Hmm, I'm not sure. Maybe someone else will know
<smokey>
thanks tgamblin
<tgamblin>
It doesn't seem right that you can't run 'bitbake -e' though. I just tried manually setting the same problem in my local.conf (i.e. IMAGE_INSTALL:append = " dnf" and PACKAGE_CLASSES = "package_deb") and saw the same error, but I can still run 'bitbake -e' without issue
florian_kc has quit [Ping timeout: 264 seconds]
<moto-timo>
dnf is for package_rpm and apt is for package_deb
<smokey>
I built a different target with -e (core-image-base) retaining my original .conf files, and it does look like my setting of PACKAGE_CLASSES = "package_rpm". Here's the relevant info from the environment: https://pastebin.com/9sMhCdmz How should this be fixed?
<smokey>
...t does look like my setting of PACKAGE_CLASSES = "package_rpm" IS GETTING OVERRIDDEN...
<moto-timo>
so I guess we need to see "bitbake-getvar IMAGE_PKGTYPE -r core-image-minimal" (or whatever target you are trying to build). One of your layers is behaving badly and the order of the layers in bblayers.conf probably needs to change.
smokey has quit [Quit: Client closed]
<moto-timo>
and they left
smokey has joined #yocto
<moto-timo>
Smokey: welcome back. I thought you left.
<moto-timo>
don't know if you saw "so I guess we need to see "bitbake-getvar IMAGE_PKGTYPE -r core-image-minimal" (or whatever target you are trying to build). One of your layers is behaving badly and the order of the layers in bblayers.conf probably needs to change."
<moto-timo>
the error messages are giving you the hints as to what is wrong... you just need to get used to where to look, how to troubleshoot it and what the patterns are.
lexano has quit [Ping timeout: 264 seconds]
<moto-timo>
ERROR: ParseError at /home/tdowty/amd/poky-amd-kirkstone/meta/classes/image.bbclass:19: Could not inherit file classes/rootfs_${IMAGE_PKGTYPE}.bbclass | ETA: --:--:--
<smokey>
I went and set IMAGE_PKGTYPE in auto.conf; running the command line you suggetsted: tdowty@ubuntu:~/amd/poky-amd-kirkstone/build-v3000-kirkstone$ bitbake-getvar IMAGE_PKGTYPE -r secure-core-image
<smokey>
#
<smokey>
# $IMAGE_PKGTYPE [2 operations]
<smokey>
# set /home/tdowty/amd/poky-amd-kirkstone/build-v3000-kirkstone/conf/auto.conf:15
<smokey>
# "rpm"
<smokey>
# set /home/tdowty/amd/poky-amd-kirkstone/meta/conf/documentation.conf:221
<smokey>
# [doc] "Defines the package type (DEB, RPM, IPK, or TAR) used by the OpenEmbedded build system."
<smokey>
# pre-expansion value:
<smokey>
# "rpm"
<smokey>
IMAGE_PKGTYPE="rpm"
<smokey>
BTW, didn't know about bitbake-getvar. Nice.
<moto-timo>
that's somewhat newish... maybe honister or kirkstone
<smokey>
Now with IMAGE_PKGTYPE = "rpm" in auto.conf, build still fails. PACKAGE_CLASSES is empty: https://pastebin.com/ZSPMmeCf. I don't see where it's getting unnet...
<smokey>
*unset*
<smokey>
...so i need to add <build_dir>/meta to my bblayers?
Saur95 has quit [Quit: Client closed]
Saur95 has joined #yocto
<smokey>
wait... i already have it there: /home/tdowty/amd/poky-amd-kirkstone/meta \
<smokey>
thanks for the help moto-timo, much appreciated! I've got to unhook now.
<moto-timo>
Smokey: ok, I'm trying your set up script now... but good luck
<smokey>
moto-timo: thanks... I can hang on for a bit if you're willing to repro
<smokey>
I didn't encounter the ParseError you see; we should have identical runs... hmm...
Saur95 has quit [Quit: Client closed]
Saur95 has joined #yocto
<moto-timo>
Smokey: parse error was because auto.conf existed before all the bitbake-layers add-layer commands had run.
<smokey>
moto-timo: are you able to proceed?
<moto-timo>
Smokey: I have replicated your error, but do not know which bad actor (one of the layers) is at fault yet
<smokey>
moto-timo: (y)
<moto-timo>
Smokey: ok.. so in local.conf I commented out PACKAGES_CLASSES ?= "package_rpm" and DISTRO ?= "poky" (probably not required)
<moto-timo>
Smokey: and in auto.conf ... sigh... PACKAGES_CLASSES:append = " package_rpm" (the space is important) and after that PACKAGE_CLASSES:remove = "package_deb"
<moto-timo>
the package_deb doesn't hurt anything, it just creates both .rpm and .deb packages in tmp/deploy/rpm and tmp/deploy/deb
<moto-timo>
had to say "package_rpm" at the end of it all
<moto-timo>
so now... building it? la la la
<moto-timo>
tick tick -- boom? or just tick tick tock
<moto-timo>
so the reasoning here is that meta-amd-distro/conf/layer.conf PACKAGE_CLASSES is winning because of layer priority (and order in bblayers.conf)... so when we used PACKAGE_CLASSES:remove it made the variable unset (which resolved AFTER the PACKAGE_CLASSES = "package_rpm" that I asked you to put in)... so then PACKAGE_CLASSES:append = " package_rpm" made DARNED SURE package_rpm was in the "string delimited" variable and then the :remove worked like
<moto-timo>
I expected.
<moto-timo>
:remove and :append resolve very very late compared to ??= and ?= and =
<moto-timo>
sadly:
<smokey>
I'm building now too.. (i have most of it already cached from previous)
<smokey>
a bad patch? I've not seen that error before
<moto-timo>
so... now we have to figure out what order the patching is happening in and which layer supplied that patch...
<moto-timo>
you've got a lot of layers involved here (I understand why... I see where you are going), but in this case something (for me at least) is getting in the way
* moto-timo
waits for linux-yocto to fetch since I didn't have any sstate
<moto-timo>
probably a grub bump somewhere along the way or grub patch in poky maybe (or another layer)... I can't remember if I saw this with a recent Intel x86-64 customer on secure boot or not...
<moto-timo>
that patch is added by meta-secure-core/meta-efi-secure-boot/recipes-bsp/grub/grub-efi-efi-secure-boot.inc
joekale has joined #yocto
<moto-timo>
anyway, time to call it a day
<moto-timo>
dog wants dinner and so do I ;)
<smokey>
moto-timo: you have been *so* helpful. I've got to unplug too. thanks again.
<moto-timo>
Smokey: you're welcome. This ramp up is normal. Just stay with it.
Saur95 has quit [Quit: Client closed]
Saur95 has joined #yocto
Saur95 has quit [Client Quit]
Saur95 has joined #yocto
Saur95 has quit [Quit: Client closed]
Saur95 has joined #yocto
Saur95 has quit [Client Quit]
Saur95 has joined #yocto
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #yocto
smokey has quit [Quit: Client closed]
Saur95 has quit [Quit: Client closed]
Saur95 has joined #yocto
ablu has quit [Read error: Connection reset by peer]
<paulg>
What a steaming pile. RP conversion to shallow is good but won't fix compile times...
florian_kc has joined #yocto
* paulg
blames vmeson
<paulg>
if llvm was out on a campaign to demonstrate they were an academic project aimed at annoying the general population by 100x, well they did it.
<paulg>
tone deaf morons...
<JaMa>
I think they lost to rust team
<paulg>
Please submit your code to FreeBSD and leave us alone...
<mcfrisk_>
bootstraping native tools from yocto side sstate mirrors would be nice, sadly many things trigger their recompilation, mostly useless...
<paulg>
geez. I can't under-describe how rust/llvm has made me so close to a "so long and thanks for all the fish" moment.
gchamp has quit [Ping timeout: 256 seconds]
<paulg>
which is sad, 'cause I generally like all the people here.
<JaMa>
paulg: while it builds you can learn about locked sstate to prevent it rebuilding in future
Piraty has quit [Quit: -]
Piraty has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
<paulg>
JaMa, :-) I am about three shovel full deep into ensuring sstate can be recycled across MACHINE and distro
<paulg>
And I look back and ask myself WTF.
<JaMa>
funny coincidence is that if you enable icecc to build llvm faster, it will make all sstate signatures DISTRO specific, so you might build it faster, but will need to build it multiple times
<paulg>
Going on vacation in less than 24h
<Crofton>
Good :)
<paulg>
I'm going to keep lobbying RP to discontinue llvm support...
<JaMa>
lets discontinue rootfs and build only kernels
<paulg>
Sold! "make allnoconfig"
<paulg>
Ah well, it wouldn't be fun if we were not around to pick on each other...
* paulg
looks at Crofton and wonders what he did
<Crofton>
I'm glad someone is going on vacatoin around here
<paulg>
Cool. Context is everything....
<zeddii>
khem: perf on riscv32 is an unknown for me. libseccomp blew up before I could get to it :)
Guest4665 has quit [Remote host closed the connection]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
roussinm has joined #yocto
jmiehe has quit [Quit: jmiehe]
gchamp has quit [Ping timeout: 264 seconds]
<Crofton>
Clearly we need people from that community working on theis tuff!
gchamp has joined #yocto
Guest72 has quit [Quit: Client closed]
sev99 has joined #yocto
ptsneves has joined #yocto
gchamp has quit [Ping timeout: 255 seconds]
rm5248 has joined #yocto
<rm5248>
is it possible to do "inherit foo" on a per-machine basis? I'm making an image that needs to inherit a custom class depending on the machine that it is building for
<Saur>
Except, unless you change `inherit` to `inherit_defer`, you must define `FOO` and its variants before the `inherit`.
simonew has joined #yocto
<moto-timo>
zeddii: ugly but true, but `do_compile[network] = "1"` is the easiest solution to criu
<moto-timo>
zeddii: well, nevermind... seems like it barfed later
<moto-timo>
grrr
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
yudjinn has quit [Remote host closed the connection]
<moto-timo>
zeddii: also `do_install[netwokr] = "1"` and then drop the EGG-IINFO sed and use find to rm -rf all the __pycache__. almost there
goliath has quit [Quit: SIGSEGV]
<moto-timo>
zeddii: last offender is `File /usr/lib/python3.12/site-packages/pycriu-3.19.dist-info/direct_url.json in package criu contains reference to TMPDIR [buildpaths]`
Guest20 has joined #yocto
Guest89 has joined #yocto
Guest89 has quit [Client Quit]
<Guest20>
I joined this group with great inspiration after reading about it on Alper Akcan’s Medium post.
<simonew>
Welcome :)
<tgamblin>
Guest20: Welcome!
<Guest20>
I reviewed the Newcomer Bugs listed on the Yocto Project Bug Triage page. Many of them appear to be quite old. Could someone please provide guidance on selecting my first issue?
mckoan is now known as mckoan|away
<moto-timo>
Guest20: you might want to change your user name to something we will recognize in the future instead of generic Guest20
<moto-timo>
Guest20: just pick something that is interesting to you
Guest20 is now known as sanjay
Guest6 has joined #yocto
Guest6 has quit [Client Quit]
<moto-timo>
sanjay: if one of those Newcomer Bugs jumps out at you as something you have seen before or have touched before, then pick that. If one of them is something you have seen happen in your build, pick that. If one of them is something you hope to learn about, pick that.
<rburton>
we really need to spend some time triaging that newcomer list and getting rid of the not-easy ones, and adding more easier ones
<moto-timo>
rburton: although some of the "easy" things we see are fixed too quickly.... oh well
<rburton>
yeah genuinely easy things are often just fixed
<rburton>
there's a sweet spot...
<sanjay>
ok moto-timo will check
<simonew>
Guest20: Are you interested in a particular area?
<moto-timo>
Guest20 is now sanjay
<simonew>
Just saw it
sev99 has quit [Quit: Client closed]
<moto-timo>
sanjay: the most important thing is something that you are motivated enough about to get past the hurdles... you will ALWAYS come upon things that do not work and are frustrating... you need to find something where your own inspiration and drive will get past that annoyance
leon-anavi has quit [Remote host closed the connection]
<rburton>
fwiw, alper started with simple upgrades in meta-oe: there's a lot of recipes and reports to say what upgrades need doing.
<sanjay>
simonew: nothing as such ..I haven’t delved deeply into the inner workings of Yocto, but I’ve used it in my project.
<sanjay>
I have a reasonable understanding of creating recipe files and using them
<khem>
RP: shadow: Improve connection to systemd DISTRO_FEATURES is causing loops in parsing
<khem>
it helps bunch of ptests in meta-openembedded
<simonew>
There is a patch for the qemu CVE-2023-6683 (not in any release yet). To fix it I backported it, I now wonder though about testing, I build all stuff that inlcudes qemu.inc, though only for x86. It affects the clipboard in the UI. I would guess host to be quite often x86, so is this reasonable, waht else to test?
Dr_Who has joined #yocto
amitk_ has quit [Ping timeout: 256 seconds]
sanjay has quit [Ping timeout: 250 seconds]
<roussinm>
So We have been trying to run qemu with poky nanbield, but we hit `kvm internal error: emulation failure`. But it works on previous poky version, wondering if anyone else has got the same issue and fixed it with some qemu flags that we might be missing or something? Trying to emulate zen2 image on amd hardware.
<roussinm>
actual the image is based on the qemux86-64 machine.
<RP>
zeddii: do we want the kernel config dependent on ptest? :/
<khem>
you are CCed
<khem>
RP: we already have it
<RP>
zeddii: I'd also welcome your thoughts on whether we should upgrade go as per master-next. That is working for core now. The next version bump is trickier
<zeddii>
RP: I'm definitely torn on the go bump, even if it is holding up some meta-virt updates. It's just so late in the cycle, and in theory, a mixin could make the newer go available. but with this being a LTS, we may get blocked out of some CVE updates, and having the LTS branch with packages that need the mixin layer, seems wrong.
<khem>
I think its addressible in meta-clang
<khem>
all meta-openembedded go apps were broken build time with this upgrade
<RP>
zeddii: we have several late things :(
<RP>
khem: are they still broken with the changes in master-next now?
<khem>
since then you have dropped 1.22 so maybe things have changed but the builds are still running for world so I dont know yet
<RP>
khem: 1.22 needs more work which is why I dropped it, I was thinking 1.21 may be an option if it works for enough people
<khem>
yeah I will know by tomorrow morning
<zeddii>
I'll try more against 1.21 as well, but agreed, 1.22 is a no-go .. badum,
<RP>
Let me know your feelings either way
<RP>
I'm leaning to taking 1.21 but could easily be convinced not to
<vvn>
can you have parallel access to DL_DIR and SSTATE_DIR? (e.g. two bitbake instances running)
<RP>
vvn: yes, and multiple hosts over NFS
<vvn>
perfect. I finish setting up docker-compose for my builds and I might have parallel services for my various TEMPLATECONF