<angman>
I am the person who asked the question last Sunday about how to get variables. Sorry for asking the same question over and over again, but I want you to help a little bit more!
<angman>
I have put together a quick stackoverflow of what I want to ask. Could someone please help me?
<JPEW>
angman: bitbake -e or bitbake-getvar should give you want your want
<JPEW>
But you need to know what you want :) RDPENDS specifically is a package variable, so you need to use the package name override when you query for it
<JPEW>
For example "RDEPENDS:curl" will get the overrides for the curl package, and correctly apply and other relevant overrides for that value
<JPEW>
Hopefully that makes sense
BoJalling has quit [Ping timeout: 276 seconds]
BoJalling has joined #yocto
<Entei[m]>
Is the build directory transferrable to other machines without having to change absolute paths? I am mainly interested in sstate_cache directory so my builds take lesser time
<Entei[m]>
Apart from bblayers.conf ofcourse. That thing uses absolute paths
Thorn has quit [Ping timeout: 248 seconds]
xmn has quit [Ping timeout: 248 seconds]
Vonter has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
xmn has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
BoJalling has quit [Ping timeout: 255 seconds]
BoJalling has joined #yocto
<JaMa>
FWIW: cmake-native doesn't like gcc-13 on gentoo, but doesn't say it nicely, segfaults when trying to run bootstrap in do_configure
<JaMa>
[ 5019.147337] cmake_bootstrap[2042255]: segfault at ffffffffffffffe8 ip 00007f6334f35097 sp 00007ffdd723af18 error 5 in libstdc++.so.6.0.30[7f6334e99000+105000] likely on CPU 51 (core 19, socket 0)
<JaMa>
and that happens only with libstdc++.so.6.0.30 from uninative which wasn't built with gcc-13
Thorn has joined #yocto
BoJalling has quit [Ping timeout: 248 seconds]
BoJalling has joined #yocto
leon-anavi has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
florian_kc has joined #yocto
xmn has joined #yocto
ptsneves has joined #yocto
<RP>
JaMa: a patch was just merged to gcc 13 which means we'll need to teak our prefix map flags when we get to using it in our builds
<RP>
Entei[m]: you can share the sstate cache, yes
<RP>
Entei[m]: we do this on the autobuilders and so on, it is well tested
<RP>
Entei[m]: you can't transfer bits other than the sstate directory and DL_DIR
xmn has quit [Quit: ZZZzzz…]
BoJalling has quit [Ping timeout: 255 seconds]
BoJalling has joined #yocto
florian_kc has quit [Ping timeout: 276 seconds]
alessioigor has joined #yocto
<JaMa>
RP: ok, thanks
<JaMa>
RP: tzcode-native also fails with gcc-13 on host, I've already reported it upstream and added work around locally
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<JaMa>
khem: there is also new dangling-pointer issue in systemtap (introduced with newer snaphost in your gcc-13 branch), for now I've added just -Wno-error for it in https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=8dc25669c0079a1d9094e6a65d663e9eecffb56a)
leon-anavi has quit [Quit: Leaving]
<JaMa>
just when I was making some progress with selftest issues on the artifacts naming I rebuild gentoo with gcc-13 and now selftest is failing because of very different reasons :)
ptsneves has quit [Ping timeout: 276 seconds]
<Entei[m]>
<RP> "Entei: you can't transfer bits..." <- Oh that should be more than enough. Good to know. Thanks
seninha has quit [Ping timeout: 276 seconds]
seninha has joined #yocto
fancer has quit [Quit: Connection closed for inactivity]
BoJalling has quit [Ping timeout: 255 seconds]
BoJalling has joined #yocto
camus has quit [Quit: camus]
goliath has joined #yocto
<JaMa>
ok, read 2eb0191aa10 file-prefix-map: Fix up -f*-prefix-map= [PR108464] but that's not yet in the snapshot I was building with yesterday
warthog9 has quit [Quit: Leaving]
warthog9 has joined #yocto
azcraft has joined #yocto
BoJalling has quit [Ping timeout: 276 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
BoJalling has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP>
JaMa: right, there is an option we'll need to add to our builds going forward
<JaMa>
gentoo is quite adventurous but still stuck with ffmpeg-4 (ffmpeg-5 available but masked) and procps-3 (procps-4 not even available yet)
<RP>
JaMa: scary when we're ahead of gentoo!
<JaMa>
yes, less places where to steal patches from :)
<JaMa>
and also less likely that other people submit adaptation patches to upstream projects
<JaMa>
being up2date is great, but being the really first early-adopters might hurt the experience for some people (who use more than just oe-core+meta-oe and have huge codebase which doesn't show on autobuilder)
<RP>
JaMa: it is a balancing act, I'd hope we don't do too badly
<JaMa>
yeah, it's not too bad :) openssl was last major PIA I remember
<JaMa>
other upgrades are at least easy to undo when more time is really needed (and one doesn't want to block whole yocto release upgrade, just because of one major component)
<JaMa>
for selftest I'll send patches once I get more confidence in them, it's e.g. selftest setting SSTATE_MIRROR but not disabling auto-enabled BB_HASHSERVE and then tripping on warning shown by sanity.bbclass
<JaMa>
or e.g. RESULTS - incompatible_lic.NoGPL3InImagesTests.test_core_image_full_cmdline_weston: FAILED (3602.41s) where it's not clear what the actual issue was (other than qemu seemingly timeout after an hour)
<JaMa>
or RESULTS - distrodata.Distrodata.test_checkpkg: FAILED (191.60s) which fails to upstream check git-submodule-test and binutils
huseyinkozan has quit [Quit: Leaving]
<JaMa>
and sometimes it's PEBKAC when I forget to touch /tmp/qemu-tap-locks/tap0.skip and runqemu tries to use tap0 already used by openvpn
<JaMa>
or KVM not available when I have another VM running on background in VirtualBox
<JaMa>
but those will be more difficult to avoid (other than possibly showing better error message in advance)
camus has quit [Quit: camus]
camus has joined #yocto
BoJalling has quit [Ping timeout: 255 seconds]
BoJalling has joined #yocto
<RP>
JaMa: putting some better sanity checks and environment isolating around selftest would be good...
<JaMa>
RP: just FYI that docbook issue in xmlto-native recently shown after last langdale update - I wasn't able to reproduce it yet, it might be something broken in sstate or something (as it's triggered for only one of many builds I've triggered with it - but it failed 5 times already so it's persistent for this build) I've asked for access for this SSTATE_MIRROR but didn't get it yet, to reproduce it manually
<JaMa>
sakoman: ^ in case you've seen the same - but it might not be related to last langdale update in the end, just something which happens rarely
<sakoman>
JaMa: I haven't encounter that. Let me know what you discover!
<Entei[m]>
How would I configure gcc for cross toolchain and target? For eg, how would I go about adding the flags for enabling more languages like fortran, obj-c, jit. Or change endianness etc
<landgraf>
Entei[m]: See LANGUAGES variable
<Entei[m]>
landgraf: there's no LANGUAGES variable. Could you link?
<Entei[m]>
<landgraf> "Entei: meta/recipes-devtools/gcc..." <- Oh ok. found it. So I just change the LANGUAGES variable (and other similar variables for other settings) in `local.conf` ?
<landgraf>
Entei[m]: It depends on the language/bootstrap etc I think
<RP>
Entei[m]: some will work, some haven't had the work done to support them. Which ones are you looking at?
<Entei[m]>
Creating a whole new recipe for gcc which includes all the files would take quite a bit of time.... I'll try in local.conf first.
<Entei[m]>
RP: as many as possible. Mainly `fortran`, `obj-c`, `jit`
invalidopcode1 has quit [Remote host closed the connection]
goliath has quit [Ping timeout: 248 seconds]
<landgraf>
RP: I have a dream to enable Ada :-)
<landgraf>
but it's not trivial :/
invalidopcode1 has joined #yocto
alessioigor has quit [Quit: alessioigor]
goliath has joined #yocto
alessioigor has joined #yocto
xmn has joined #yocto
seninha has joined #yocto
BoJalling has quit [Ping timeout: 248 seconds]
BoJalling has joined #yocto
alessioigor has quit [Quit: alessioigor]
goliath has quit [Quit: SIGSEGV]
BoJalling has quit [Ping timeout: 276 seconds]
BoJalling has joined #yocto
<RP>
landgraf: right, I did try that briefly
<RP>
Entei[m]: fortran should work, less sure about others
<JaMa>
core-image-minimal, but that still feels a bit fragile
goliath has joined #yocto
<JaMa>
top 6 commits in https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/pull are relatively safe after I finish more testing, but I don't mind waiting with these for Nanbield (to apply them together with that IMAGE_NAME_SUFFIX change which requires them)
<RP>
JaMa: there is no good way to access another recipe's context
<fray>
...and luckily few bad ways....
<JaMa>
I wasn't expecting a good way, I will be happy with the least terrible