zelgomer has quit [Remote host closed the connection]
zelgomer has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
thomasd13 has joined #yocto
marka has quit [Ping timeout: 240 seconds]
TundraMan has joined #yocto
goliath has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
rfuentess has joined #yocto
zpfvo has joined #yocto
frieder has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
zelgomer has quit [Ping timeout: 240 seconds]
zelgomer has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
bps2 has joined #yocto
prabhakarlad has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
leon-anavi has joined #yocto
jo-so has joined #yocto
<LetoThe2nd>
yo dudX
<mckoan>
LetoThe2nd: hey
<LetoThe2nd>
mckoan: btw, you got anything for the YPDD CFP maybe? ;-)
florian has joined #yocto
d-s-e has joined #yocto
<jo-so>
Hi, I'm (a beginner with Yocto and) having a project that (uses KAS and) includes the Poky repo. I would like to use *runqemu* in the KAS container which needs *iptables*. But *iptables* in not in the KAS container, which is why I want to build a *iptables-native* and use this to run *runqemu*. But appending `BBCLASSEXTEND = "native"` to the *iptables* recipe installs the binary in
<jo-so>
`build/tmp/work/x86_64-linux/iptables-native/1.8.7-r0/sysroot-destdir/build/tmp/work/x86_64-linux/iptables-native/1.8.7-r0/recipe-sysroot-native/usr/sbin`which looks strange. Am I doing something wrong? Can I use the *iptabes* recipe to build the native binary for the KAS container?
<LetoThe2nd>
jo-so: any particular reason to use kas-container instead of just running natively?
<mckoan>
LetoThe2nd: no, sorry :-(
<LetoThe2nd>
mckoan: awwww
ptsneves has joined #yocto
<jo-so>
LetoThe2nd: When I run `cd layers-3rdparty/poky && . ./oe-init-build-env ../../build` and then `runqemu nographic tmp/deploy/images/qemux86-64/ctn-base-image-qemux86-64.qemuboot.conf` this fails, because *runqemu* calls `bitbake -e` and this uses the *bblayers.conf* that is configured with the paths in the KAS container.
<LetoThe2nd>
jo-so: i rather meant globally. any specific reason to build in kas-container?
<jo-so>
That's a project requirement. I don't know, why this decision was made.
<mcfrisk>
jo-so: roll out your own container? I'm sure kas allows using a different container with needed dependencies for qemurunner
<mcfrisk>
fwiw, I'm using runqemu and testimage.bbclass natively a lot to develop, test, debug
<LetoThe2nd>
mcfrisk: ++
<jo-so>
Yes, it's possible. But creating (and maintaining) a container, just to get iptables, sounds like quite a bit.
<mcfrisk>
jo-so: try upstreaming the the kas container change so that runqemu etc work better, your use case makes sense
<mcfrisk>
I use qemu with userspace slirp networking, which is easier to run without complex network setup. Maybe that works too and iptables isn't needed..
<jo-so>
Hence, my idea to use the iptables in poky to build a native binary.
<mcfrisk>
jo-so: do you need tun networking for something special or basic ssh to the qemu device only? then try slirp, it works too (at least from inside the container ssh to 127.0.0.1 port 2222 will give ssh console access)
kpo has joined #yocto
d-s-e has quit [Ping timeout: 264 seconds]
<mcfrisk>
jo-so: basically "runqemu slirp", or for testimage.bbclass TEST_RUNQEMUPARAMS += "slirp" in image recipe will enable slirp networking without complicated tun interfaces
<mcfrisk>
I think slirp should be the default, it's easier to setup on various distros (just works really). It does not work so well if single machine runs multiple build/test instanes though, or at least I've not tested this.
u4ia has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
<landgraf>
mcfrisk: +1
zpfvo has joined #yocto
d-s-e has joined #yocto
<rburton>
Does Markus Volk hang on irc?
Tamis has joined #yocto
yannd has joined #yocto
<Tamis>
LetoThe2nd: Sorry didn't ping you in Monday. I tested the the per-image INCOMPATIBLE_LICENSE and you are right it is working. But there is a small difference. If you put INCOMPATIBLE_LICENSE into distro.conf then your build does not even start if you try to install GPLv3 packages. If you put INCOMPATIBLE_LICENSE though into an image recipe, it
<Tamis>
starts building and then it goes boom into the rootfs creation stage. Which is fine also.
<Tamis>
LetoThe2nd: So the first it seems to exclude also build time dependencies while the later excluded runtime dependencies which is a lot better.
<LetoThe2nd>
Tamis: yes that is the expected behavior
<Tamis>
LetoThe2nd: Nice to figure it out. Thanks for your tip
<mcfrisk>
Tamis: it is also possible to add exceptions to INCOMPATIBLE_LICENSES to allow build some recipes but to also make sure that none of the binary packages are allowed to be installed to images. Enables building SDK with gdb etc. See INCOMPATIBLE_LICENSE_EXCEPTIONS and PACKAGE_EXCLUDE variables in https://docs.yoctoproject.org/singleindex.html
Tamis has quit [Ping timeout: 245 seconds]
<LetoThe2nd>
Tamis: nice to hear, have fun! Also, what mcfrisk said
scotttravis has joined #yocto
<scotttravis>
Hi, I get poky/meta/recipes-connectivity/openssl/openssl_3.0.8.bb:do_compile) failed with exit code '1' upon a new clone of the poky repository, im on kirkstone
<scotttravis>
there is no temp directory hence no log.do_compile:
<scotttravis>
~/poky/build/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/openssl/3.0.8-r0/build$ ls
<scotttravis>
apps configdata.pm crypto doc engines fuzz include libcrypto.a libcrypto.ld libcrypto.so.3 libssl.a libssl.ld Makefile Makefile.in providers ssl test tools util
<scotttravis>
Furthermore, my machine is qemuarm so I expected it to be inside "~/poky/build/tmp/work/qemuarm-poky-linux-gnueabi$" and not ".../cortexa15t2hf-neon-poky-linux-gnueabi", why is that
<rburton>
Can you pastbin the whole log, makes things easier
<scotttravis>
sorry I thought you meant "the last few lines of the error message on screen would have told you both the actual error" meaning the error lies in the main.c file ( /usr/src/debug/openssl/3.0.8-r0/build/../openssl-3.0.8/test/testutil/main.c:29: undefined reference to `setup_tests' ) as there is an undefined reference. I will paste the whole log
<scotttravis>
I've pasted the whole content of the log.do_compile in pastebin
seninha has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
seninha has joined #yocto
camus has quit [Ping timeout: 240 seconds]
<scotttravis>
? did I say something wrong or did I found out an important bug?
<rburton>
i went to lunch
<rburton>
and that's a pristine tip of kirkstone branch? curious that the autobuilder hasn't seen it as far as i know
<rburton>
file a bug, please
<scotttravis>
I checked out on origin/kirkstone
mkazantsev has quit [Ping timeout: 246 seconds]
mkazantsev has joined #yocto
tnovotny has quit [Ping timeout: 248 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<scotttravis>
and os is ubuntu 22.04 LTS, thanks for your help btw
scotttravis has quit [Quit: Client closed]
tnovotny has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
camus has joined #yocto
vvmeson has joined #yocto
florian__ has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
xmn has joined #yocto
mkazantsev has quit [Quit: Leaving]
sakoman has joined #yocto
tnovotny has quit [Ping timeout: 240 seconds]
Haxxa has quit [Remote host closed the connection]
Haxxa has joined #yocto
tnovotny_ has joined #yocto
visibig has joined #yocto
<visibig>
Hello every one, I have a weird behavior on systemd 250.5 from yocto kirkstone, I would like to get your feeling about it because I didn't go deep on it yet. Actually when I use systemd on normal image with rpm update, systemd is working fine but as soon as I put ostree, systemd stops starting the graphical target correctly and same thing for bluetooth target, But if I put the graphical.target symlink in etc and instead of having default.target pointing to
<visibig>
/lib/.../graphical.target we put /etc/.../default.target --> /etc/.../graphical.target and /etc/.../graphical.target --> /lib/.../graphical.target the graphical target starts normally but this is not the case for bluetooth.target. Has anyone faced this or have hints for me? Thank you very much.
<visibig>
ostree version is 2020.3 and it's working fine
<paulg>
bah. core-image-minimal/1.0-r0/temp/run.do_image_ext4.4175123: 284: bc: not found
<paulg>
would have thought bc would be an ASSUME_PROVIDED sort of thing.
<fray>
Do hows actually not have 'bc' installed by default?
<fray>
'er.. hosts
<paulg>
oh I have /usr/bin/bc of course - the recipe must be excluding default paths.
<paulg>
This is in a meta-security extension I put together to split a UUID into two chunks.
<fray>
Hmm. not sure then
<paulg>
I'll add a line above the bc call to dump the PATH to a temp file and see what is going on.
<paulg>
As expected, all components of $PATH start with /home/paul/poky - no /usr/bin or /bin components.
* paulg
scratches his head, confused.
<fray>
I know there are places where the path is santized so only build components can be used. This may be one of them
<fray>
Whatever you are calculating, can it be done outside of this section of code?
<paulg>
systemd wants partition UUIDs to use parts of the verity root hash.
<paulg>
I think I'll see if I can add a dependency on bc-native and see how ugly that gets.
<fray>
Likely that is what you need to do
<paulg>
Actually I think I'll just hard code the /usr/bin/bc for now, in case the whole thing is a fail and I have to go down a different road...
kscherer has joined #yocto
rfuentess has quit [Remote host closed the connection]
seninha has quit [Remote host closed the connection]
<rburton>
paulg: bc isn't a hostdep, we depend on bc-native where needed
<rburton>
you can argue that it should be, if you want
seninha has joined #yocto
VincentKadar[m10 has joined #yocto
rfuentess has joined #yocto
<paulg>
Yeah, I didn't get a complaint on 'tr' but I bet that comes in coreutils or util-linux vs. being a stand-alone.
tnovotny_ has quit [Ping timeout: 240 seconds]
tnovotny_ has joined #yocto
d-s-e has quit [Quit: Konversation terminated!]
goliath has quit [Quit: SIGSEGV]
<VincentKadar[m10>
!!! Enjoy the most profitable financial market (crypto market ) as you get 100% profit...and you can also make up to $100k or more in 3days send me a private message and ask me HOW
* zeddii
drops a message!
<mckoan>
LOL
* zeddii
quits his job. since I'm now rich!
seninha has quit [Remote host closed the connection]
<mason>
Hi all! I've got a few questions. 1) Is there a way to treat patches applying with fuzz as errors and not warnings, so my build stops? 2) Is there a notion of what's required vs not for .scc files? I'm looking at https://docs.yoctoproject.org/kernel-dev/advanced.html#scc-description-file-reference and I'd like to just have an explicitly ordered set of patches, but I've not yet found anything saying what's
<mason>
strictly required.
<JaMa>
zeddii: will you merge some meta-virtualization changes before you move to Bahamas and stop working completely? :)
<zeddii>
heh. I was actually just doing that, hence why I was distracting myself.
<zeddii>
JaMa. I actually wanted to get your opinion on one of the patches (the autopv one for my busybox-initrd pacckage that includes the main busybox box recipe), since you have had a similar recipe in the past.
<JaMa>
zeddii: cool, some changes were already in mickledore (and master-next) but not yet in master, so I was thinking about pinging you
<JaMa>
I still have ./meta-luneos/recipes-core/busybox/busybox-static_1.36.0.bb
<rburton>
mason: your distro must be setting QA defaults, as the defaults (in mickledore, at least) has patch-fuzz as an error (ERROR_QA in insane.bbclass)
<mason>
rburton: Thank you. That's very likely the case.
<zeddii>
JaMa, I did do a push to mickeldore, but I should have pushed the master-next at the same time. let me check that first.
<JaMa>
haven't touched it for long other than renaming to match version
Tamis has joined #yocto
<zeddii>
right. that's what I do with mine, it is kind of a signal for me to rename, test and validate.
<zeddii>
I''m a bit worried that I won't have that "validation" step if the recipe is searching up the version and automatically including it. also not sure about multiple versions, or parse time races, etc.
tnovotny_ has quit [Quit: Leaving]
VincentKadar[m10 was kicked from #yocto by LetoThe2nd [spam]
<JaMa>
zeddii: "recipe is searching up the version and automatically including it" the version in meta-virt/master seems to do just the require, do you have some pending change elsewhere? I don't think it's dangerous, just annoying as it breaks parsing whenever the version doesn't match anymore
<zeddii>
right. the one in the current master is just the require.
<zeddii>
but [meta-virtualization][PATCH 1/5] busybox-initrd: auto pv from busybox was sent to the list, and it does it automatically via some python. I'm just testing it now as getting the merges up to date.
<JaMa>
ah, I see
<JaMa>
looks reasonable to me
<zeddii>
yah, alternatively to support the branches they are talking about, I could just make it skip recipe or trigger off a distro feature, versus that python .. but that doesn't seem better. I'll roll with testing it and see if anything pops out.
<JaMa>
but I wouldn't use that on meta-luneos as we don't try to support multiple releases from the same branch and busybox PV don't bother me enough
<zeddii>
having the parse error block some layer combinations that would otherwise work, as you said, could be annoying
<zeddii>
yah. I'm not "officially" taking on that support (or promising it), but I don't mind taking a patch to not break it immediately.
rfuentess has quit [Remote host closed the connection]
mckoan is now known as mckoan|away
ptsneves has quit [Ping timeout: 256 seconds]
<kergoth>
Anyone have any tips on diagnosing a NoProvider error from add_provider_internal which has no reasons or dependees provided? There's no info on what dependency is pulling this in, it's not something directly requested as a target on the cmdline.
<kergoth>
Nothing PROVIDES ... Close matches:
ptsneves has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
HenkMedenblik[m] has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
bps2 has quit [Ping timeout: 256 seconds]
<kergoth>
on kirkstone, getting ERROR: Nothing PROVIDES 'virtual/arm-oemllib32-linux-gnueabi-gcc'. Close matches: with a multilib build. presumably something is missing an MLPREFIX since the existing provides have virtual/libc32-, but MLPREFIX isn't needed in DEPENDS or PREFERRED_PROVIDER iirc due to multilib_global, so should only need it explicitly in `depends` flags, and i can't find any of those that are missing it
<kergoth>
mm
<kergoth>
hmm, rather
leon-anavi has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
florian__ has quit [Ping timeout: 268 seconds]
ptsneves has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
seninha has joined #yocto
<paulg>
anyone know where the logger_debug() messages from e.g. scripts/lib/wic/plugins/imager/direct.py land (assuming they are enabled by default)?
vladest has quit [Ping timeout: 256 seconds]
kpo has quit [Remote host closed the connection]
kpo has joined #yocto
Tamis has quit [Ping timeout: 245 seconds]
frieder has quit [Remote host closed the connection]
<mischief>
nevermind, i found the date in an email from the list. > YP 4.0.10 Release date 2023/05/26
thomasd13 has quit [Ping timeout: 240 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<visibig>
Hello every one, I have a weird behavior on systemd 250.5 from yocto kirkstone, I would like to get your feeling about it because I didn't go deep on it yet. Actually when I use systemd on normal image with rpm update, systemd is working fine but as soon as I put ostree, systemd stops starting the graphical target correctly and same thing for bluetooth target, But if I put the graphical.target symlink in etc and instead of having default.target pointing to
<visibig>
/lib/.../graphical.target we put /etc/.../default.target --> /etc/.../graphical.target and /etc/.../graphical.target --> /lib/.../graphical.target the graphical target starts normally but this is not the case for bluetooth.target. Has anyone faced this or have hints for me? Thank you very much.
<visibig>
ostree version is 2020.3 and it's working fine
<JaMa>
rburton: python3-dbusmock should be fixed in oe-core: ERROR: Nothing RPROVIDES 'python3-pygobject' (but /OE/build/oe-core/openembedded-core/meta/recipes-devtools/python/python3-dbusmock_0.28.7.bb, /OE/build/oe-core/meta-openembedded/meta-oe/recipes-gnome/libpeas/libpeas_1.36.0.bb RDEPENDS on or otherwise requires it)
seninha has quit [Remote host closed the connection]
Minvera has joined #yocto
Soopaman has joined #yocto
florian__ has joined #yocto
chep` has joined #yocto
chep has quit [Ping timeout: 248 seconds]
chep` is now known as chep
Soopaman has quit [Quit: Leaving.]
<rburton>
ah, thanks, I thought i did a world parse but obviously not
<rburton>
hm not sure why dbusmock has that dependency
<rburton>
ah, there
<rburton>
that's a recommends at best :)
Soopaman has joined #yocto
mvlad has quit [Remote host closed the connection]
chep` has joined #yocto
chep has quit [Ping timeout: 240 seconds]
chep` is now known as chep
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
vladest has quit [Remote host closed the connection]