<abelloni>
../libsoup-2.74.3/libsoup/soup-xmlrpc.c:1206:15: error: implicit declaration of function 'xmlParseMemory' [-Werror=implicit-function-declaration]
mulk has quit [Ping timeout: 252 seconds]
mulk has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
Net147 has quit [Ping timeout: 252 seconds]
jclsn has quit [Ping timeout: 268 seconds]
jclsn has joined #yocto
simonew has quit [Remote host closed the connection]
<newbie>
Hi I am trying to add meson0.63 to dunfell but facing Could not inherit file classes/python_setuptools_build_meta.bbclass. If I add this file classes directory gettting another issue as ERROR: ExpansionError during parsing /openembedded-core/meta/recipes-devtools/meson/meson_0.63.3.bb##############################################
<newbie>
| ETA: 0:00:00
<newbie>
Traceback (most recent call last):
<newbie>
File "Var <install_templates>", line 1, in <module>
<newbie>
File "/home/khan/bin/sources/openembedded-core/meta/classes/meson.bbclass", line 38, in meson_array(var='BUILD_READELF', d=<bb.
<newbie>
How can I fix this?
mulk has quit [Ping timeout: 256 seconds]
goliath has joined #yocto
mulk has joined #yocto
rob_w has joined #yocto
xmn has quit [Quit: ZZZzzz…]
mulk has quit [Ping timeout: 246 seconds]
mulk has joined #yocto
mckoan_ is now known as mckoan
xmn has joined #yocto
mvlad has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
zpfvo has joined #yocto
xmn has quit [Quit: ZZZzzz…]
zpfvo has quit [Ping timeout: 256 seconds]
rfuentess has joined #yocto
luc4 has joined #yocto
mbulut has joined #yocto
mbulut has quit [Client Quit]
Kubu_work has joined #yocto
zpfvo has joined #yocto
leon-anavi has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
xmn has joined #yocto
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
<RP>
At least the builds feel faster now we're not rebuilding glibc/qemu every build run
frieder has joined #yocto
xmn has quit [Quit: ZZZzzz…]
newbie has quit [Quit: Client closed]
amitk_ has quit [Remote host closed the connection]
amitk has joined #yocto
prabhakar has quit [Quit: Connection closed]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
<dvergatal>
is it possible to set initramfs image bundle name?
simonew has joined #yocto
florian has joined #yocto
schtobia has quit [Quit: Bye!]
schtobia has joined #yocto
<Ad0>
hm, I modified systemd-networkd-wait-online.service, and I can see it in my resulting image, but in real linux it's unmodified
<Ad0>
something must be generating it
<Ad0>
maybe I have to modify /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service instead
* RP
notes we didn't say exactly when the freeze was today. I could make my life easier and say it was now passed and we're done for 5.0 while the builds work :)
<Tyaku_>
Hello, I am looking how to remove the "login prompt" in the serial console of my linux board. Currently I successfully remove: U-Boot logs and kernel loading logs, But I still have the login prompt
<Tyaku_>
On internet I found many solutions, like looking in /etc/inittab
<Tyaku_>
but I don't have this file
<rburton>
Tyaku_: are you using systemd?
<Tyaku_>
Yes I am using systemd
<Tyaku_>
It seems that the software doing this is "/sbin/agetty -8 -L ttymxc1 115200 linux"
<rburton>
don't install the systemd-getty service
<Tyaku_>
I think I already disabled it, by modifing 90-preset file (I found it on google)
<rburton>
there's a package called something like systemd-getty which installs .service files that start gettys
<Tyaku_>
do_install:append:hub-mz() { sed -i -e "s/enable getty@.service/disable getty@.service/g" ${D}${systemd_unitdir}/system-preset/90-systemd.preset
<luc4>
Hello! I used useradd to add a user in a recipe. During rootfs creation I'm getting this error: "configuration error - unknown item 'SYSLOG_SU_ENAB' (notify administrator)". Any idea what it means?
<JaMa>
luc4: is that fatal for you? SYSLOG_SU_ENAB is available only without pam
<kanavin>
RP: FileNotFoundError: [Errno 2] No such file or directory: '/srv/autobuilder/autobuilder.yocto.io/pub/sstate/universal/90/11/sstate:update-rc.d-native:x86_64-linux:0.8:r0:x86_64:11:9011ce22ce830d73f6a51ba8733624f9c4a2640671acfd1e06268e2304f998ae_configure.tar.zst.siginfo'
<RP>
kanavin: yes, although he has other challenges atm :/
<RP>
maintenance later will probably make it go away
<RP>
kanavin: I've merged the conf changes. I have some reservations about bits of this but nothing I have time left to send out and discuss :/
<RP>
Hopefully things we can tweak later
<kanavin>
RP: thanks! btw I'm planning to send a proposal for 'config fragments' to oe-architecture. There's no code for it, and any changes will of course happen after LTS.
<Ad0>
my CMDLINE variable does not exist when doing bitbake -e but a cmdline is still produced from my variables ...
<RP>
Ad0: bitbake -e or bitbake -e <recipe> ?
<Ad0>
I guess it's not produced on my image recipe which is weird
<Ad0>
I do bitbake -e my-image
<kanavin>
hopefully the idea of self-documented config snippets in conf/fragments/ and simple, optional tooling to add/remove/list/search them isn't too controversial
<Ad0>
bitbake -e rpi-cmdline | grep ^CMDLINE= produces the cmdline
<RP>
kanavin: we're definitely moving along something like those directions
<Ad0>
CMDLINE_ROOTFS it was in kirkstone
Thorn_ has joined #yocto
xmn has joined #yocto
Thorn has quit [Ping timeout: 255 seconds]
<Tyaku_>
Thanks rburton, removing systemd-serialgetty removed the login prompt on startup.
destmaster has joined #yocto
Chaser has joined #yocto
destmaster has quit [Remote host closed the connection]
destmaster has joined #yocto
salahaldeen has quit [Ping timeout: 256 seconds]
mithro has quit [Ping timeout: 268 seconds]
salahaldeen has joined #yocto
rmmr has quit [Ping timeout: 256 seconds]
Tartarus has quit [Ping timeout: 268 seconds]
patersonc has quit [Ping timeout: 246 seconds]
Tartarus has joined #yocto
tortoise has quit [Ping timeout: 260 seconds]
CosmicPenguin has quit [Ping timeout: 246 seconds]
rmmr has joined #yocto
praneeth_ has quit [Ping timeout: 246 seconds]
denix has quit [Ping timeout: 268 seconds]
jonmason has quit [Ping timeout: 268 seconds]
ndec has quit [Ping timeout: 260 seconds]
salahaldeen has quit [Ping timeout: 260 seconds]
nohit has quit [Ping timeout: 246 seconds]
elfenix|cloud has quit [Ping timeout: 268 seconds]
CosmicPenguin has joined #yocto
mithro has joined #yocto
ndec has joined #yocto
madisox_ has quit [Ping timeout: 246 seconds]
patersonc has joined #yocto
tortoise has joined #yocto
rmmr has quit [Ping timeout: 260 seconds]
praneeth_ has joined #yocto
astlep55040180 has quit [Ping timeout: 264 seconds]
Tartarus has quit [Ping timeout: 264 seconds]
jonmason has joined #yocto
ndec has quit [Ping timeout: 256 seconds]
nohit has joined #yocto
joekale_ has quit [Ping timeout: 264 seconds]
simonew has quit [Ping timeout: 272 seconds]
dl9pf has quit [Ping timeout: 256 seconds]
salahaldeen has joined #yocto
elfenix|cloud has joined #yocto
rmmr has joined #yocto
CosmicPenguin has quit [Ping timeout: 256 seconds]
denix has joined #yocto
CosmicPenguin has joined #yocto
Ch^W has quit [Ping timeout: 246 seconds]
Tartarus has joined #yocto
dl9pf has joined #yocto
ndec has joined #yocto
Ch^W has joined #yocto
madisox_ has joined #yocto
astlep55040180 has joined #yocto
joekale has joined #yocto
tgamblin has quit [Remote host closed the connection]
joekale has quit [Ping timeout: 256 seconds]
tin_ has quit [Ping timeout: 246 seconds]
CosmicPenguin has quit [Ping timeout: 246 seconds]
jonmason has quit [Ping timeout: 256 seconds]
armpit has quit [Ping timeout: 256 seconds]
denix has quit [Ping timeout: 246 seconds]
praneeth_ has quit [Ping timeout: 256 seconds]
paulg has joined #yocto
praneeth_ has joined #yocto
jsbronder has quit [Ping timeout: 246 seconds]
darknighte has quit [Ping timeout: 246 seconds]
dl9pf has quit [Ping timeout: 256 seconds]
dl9pf has joined #yocto
praneeth_ has quit [Ping timeout: 260 seconds]
smooge has quit [Quit: I have resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed, or numbered! My life is my own.]
alejandrohs has quit [Ping timeout: 268 seconds]
Tartarus has quit [Ping timeout: 256 seconds]
jonmason has joined #yocto
rmmr has quit [Ping timeout: 256 seconds]
praneeth_ has joined #yocto
jsbronder has joined #yocto
darknighte has joined #yocto
Tartarus has joined #yocto
denix has joined #yocto
CosmicPenguin has joined #yocto
rmmr has joined #yocto
tin_ has joined #yocto
alejandrohs has joined #yocto
joekale has joined #yocto
armpit has joined #yocto
smooge has joined #yocto
rsalveti has joined #yocto
gchamp has quit [Ping timeout: 268 seconds]
simonew has joined #yocto
speeder has joined #yocto
<speeder>
When applying a .patch file, does the "index" matter?
linfax has quit [Ping timeout: 255 seconds]
rob_w has quit [Remote host closed the connection]
<RP>
speeder: depends which tool you apply it with
<RP>
patch, no, git, yes
<speeder>
how yocto applies patch files anyway?
<RP>
speeder: quilt (which is patch underneath)
florian_kc has quit [Ping timeout: 268 seconds]
destmaster has quit [Remote host closed the connection]
destmaster has joined #yocto
destmaster has quit [Remote host closed the connection]
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
tin_ has quit [Ping timeout: 246 seconds]
tin_ has joined #yocto
rmmr has quit [Ping timeout: 256 seconds]
lexano has joined #yocto
<speeder>
Yocto ptest allows you to printf debug info?
rmmr has joined #yocto
joekale has quit [Ping timeout: 268 seconds]
CosmicPenguin has quit [Ping timeout: 256 seconds]
<rburton>
anything output to stdout is in the log
CosmicPenguin has joined #yocto
lexano has quit [Remote host closed the connection]
florian_kc has joined #yocto
mvlad has quit [Remote host closed the connection]
mvlad has joined #yocto
goliath has quit [Quit: SIGSEGV]
aardo has quit [Ping timeout: 252 seconds]
joekale has joined #yocto
<Tyaku_>
Just to be sure, is it a normal usecase to switch between DISTRO when building (for exemple Dev/Prod image) ? Because I got some stranges issues: First the changes of one distro was not taken in rootfs when built, and after I arrived at a point where there are missing common stuffs (like kernel modules) in the two distro images. So currently I am rebuilding everything to see If I restart from 0 how it is,
<Tyaku_>
but..
tgamblin has joined #yocto
<mckoan>
Tyaku_: First: i this case would be better to use bitbake -C imagename ('-C' uppercase)
<LetoThe2nd>
Tyaku_: it is a standard use case, IMHO
prabhakarlad has quit [Quit: Client closed]
luc4 has quit [Ping timeout: 256 seconds]
prabhakalad has joined #yocto
yudjinn has joined #yocto
<ederibaucourt>
Hello! I'm testing my patches after a rebase on top of poky-contrib/abelloni/master-next. Is there a public shared state cache to speed up my core-image-minimal/x86_64/poky build?
<rburton>
ederibaucourt: see your local.conf, there's two lines you can uncomment to use the sstate on the CDN
<rburton>
ederibaucourt: i'd rebase to origin/master as of right now though
<ederibaucourt>
rburton: thanks! that's all I needed to know <3
<RP>
rburton: master and master-next are one patch different and you owe review on that one ;-)
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<JaMa>
heh master is on fire today, cannot keep up rebasing and rebuilding today :)
<rburton>
but you can turn off bluetooth in network manager, and it should be doing that already
<rburton>
you're not doing the machine/distro removes in your image file are you?
<Ad0>
neard I don't klnow what even is
<rburton>
NFC daemon
<Ad0>
ok
<Ad0>
I def don't need that
<rburton>
(this is why i tell people to build your own distro)
<Ad0>
yeah
<Ad0>
you mean instead of poky?
<rburton>
absolutely
<rburton>
poky is a reference distro for QA
<rburton>
which is why it turns on NFC, bluetooth, wifi, debuginfod, opengl, vulkan, pulseaudio...
<Ad0>
yeah
<Ad0>
I soon end up doing more :remove than anything haha
florian_kc has joined #yocto
<rburton>
that's a sign that you should stop using poky :)
<Ad0>
I guess I can just use meta-openembedded
<rburton>
?
<Ad0>
yes true
<rburton>
poky-the-git-repo is oe-core+bitbake+meta-yocto. you can still use poky the git repo if you wish for the convenience of bitbake+oecore in one, but that's unrelated to poky-the-distro
<rburton>
and meta-oe is just a collection of layers
otavio has quit [Quit: Lost terminal]
<rburton>
anyway, my question remains unanswered: where did you do DISTRO_FEATURES:remove?
<rburton>
RP: can you merge my poky patch to make it more verbose about being a reference distro?
<Ad0>
yeah, I mean there's systemd etc in poky. where else would I find that? or is it just some patching on top or something
vladest has quit [Ping timeout: 268 seconds]
vladest1 is now known as vladest
<rburton>
poky is just oe-core + bitbake
<Ad0>
I have been leaning on poky forever
<rburton>
compare the contents of the poky repo with what happens if you clone bitbake and oe-core in the same directory. the extra pieces are yocto-docs (the documentation) and meta-yocto (the poky distro and the reference hardware BSPs)
<JaMa>
I am 100% sure the meta-my-layer/conf/distro/common.conf is just wrong :)
florian_kc has quit [Ping timeout: 255 seconds]
<Ad0>
that could be true
<Ad0>
it managed to remove pulseaudio so
<JaMa>
yes, because pulseaudio was :removed without incorrect use of an override
leon-anavi has quit [Quit: Leaving]
<rburton>
can you share the common.conf?
<Ad0>
you are right
<Ad0>
I missed the prefix of the machine name
<JaMa>
Ad0: you should experiment with :override:remove and :remove:override to understand what you did wrong
<Ad0>
thanks a lot, that bitbake-getvar was really useful
<Ad0>
it's when it looks right and you look at it 10 times, the 11th time you see the mistake
<rburton>
i wonder if we can make doing FOO:bar:append an error now that overrides have their own syntax
<Ad0>
I would love if you could have a strict bitbake that will throw a warning or error if what you are overriding does not exist
<JaMa>
it might not exist in the current build, but it might be valid expression in different build (e.g. when different DISTRO/MACHINE is used)
vladest has quit [Ping timeout: 255 seconds]
<rburton>
yeah that would break the point of overrides, really
<JaMa>
so it's hard to guess what's just wrong and what's PEBKAC
<JaMa>
with great power comes great responsibility, so learn the syntax and use getVar whenever you're not sure
<Ad0>
you can remove based on machine like that in the distro conf right?
<Ad0>
DISTRO_FEATURES:machine:remove
<Ad0>
when I don't specify the machone and just do :remove it works, when I specify the machine, it doesn't
vladest has joined #yocto
<khem>
RP: rv64 results look ok for toolchain pieces no big red flags, some failures in gcc testsuite are clustered around floating point/snan which could be looked into and also riscv/predef seems to be another area
<Saur_Home>
rburton: There are many cases where FOO:bar:remove is used, e.g., RDEPENDS:${PN}:remove
<khem>
it could be how be configure toolchain for single ABI
<Ad0>
DISTRO_FEATURES:remove works from machine but DISTRO_FEATURES:machine:remove does not work from distro
<JaMa>
DISTRO_FEATURES:machine:remove is almost always wrong
<Ad0>
yeah but one machine has bluetooth, another one has not
<Ad0>
to me it feels equally wrong
<JaMa>
I was talking about syntax, not feelings :)
<Ad0>
lol
<Ad0>
yeah so 1) why does it not work 2) where should I remove it ?
<Ad0>
it works from machine, but is that the right place to remove the distro feature?
<JaMa>
it isn't, DISTRO_FEATURES are DISTRO policy
<Ad0>
but bluetooth are both distro and machine features
<JaMa>
and it works, because you didn't use override there (incorrectly)
<Ad0>
so you have to specify it based on machine somewhere
<JaMa>
nm uses just DISTRO_FEATURES, it would be better for your use-case to use COMBINED_FEATURES (as discussed yesterday)
<Ad0>
I thought that wasn't supposed to be written to , also I run into the same problem
<JaMa>
COMBINED_FEATURES is better in many cases, but unfortunately it causes all recipes which use COMBINED_FEATURES to be effectively MACHINE_ARCH
<JaMa>
you shouldn't be building nm with and without bluetooth support in the same TUNE_PKGARCH, so it's still DISTRO policy to either disable bluetooth for all MACHINEs or enable it for all
Vonter has quit [Ping timeout: 256 seconds]
<JaMa>
or if they really care about bluetooth, then they can use COMBINED_FEATURES in nm, mark it (and everything which depends on it) as MACHINE_ARCH
<Ad0>
I gfuess I have to read about MACHONE_ARCH
Vonter has joined #yocto
<Ad0>
I don't use X but I use the dbus , I guess I need X
<Ad0>
MACHINE_ARCH is set to my machine with underscores instead of -
<JaMa>
now read about PACKAGE_ARCH
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<Tyaku_>
< mckoan> Tyaku_: First: i this case would be better to use bitbake -C imagename ('-C' uppercase)
<Tyaku_>
What does it changes exactly ? 'Invalidate the stamp for the specified task such as 'compile' and then run the default task for the specified target(s).'
<Tyaku_>
Is it like a clear ?
<Tyaku_>
'This new command line option forces the specified task and all dependent
<Tyaku_>
tasks up to the default task to re-run.'
<Tyaku_>
Oh nice
<rburton>
Ad0: you don't need X to use dbus
<RP>
rburton: added to -next
<rburton>
thanks
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Tyaku_>
I'm not sure how to use -C :
<Tyaku_>
'bitbake -C myimage' produce this: 'Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.'
<JaMa>
bitbake -C compile foo
<JaMa>
will rerun do_compile and the tasks after that until default task (do_build usually)
amitk has quit [Ping timeout: 256 seconds]
<JaMa>
similarly as "bitbake -c compile -f foo && bitbake foo" would do
<Tyaku_>
I tryed this: "bitbake --clear-stamp=INVALIDATE_STAMP myimage", it seems working but the build is VERY fast. (less 1 minute) so not sure if it works. I'm going to try like you said when finished.
<Tyaku_>
Now I'm going to try 'bitbake -C compile myimage'
<JaMa>
I haven't read the whole backlog but -C compile doesn't make much sense for image recipe, maybe you should start by explaining what you want to achieve
<Tyaku_>
That's maybe the same, tomorrow I will try to build with DISTRO=a and DISTRO=b multiple times, to check if with the option '-C compile' I get better results as before.
<Tyaku_>
JaMa, This is because I remark something strange when building with multiple DISTRO, sometimes, the image is not containings the "things" of the "last distro" beging built
<JaMa>
it shouldn't be needed to re-run tasks which are supposed to be re-run
<JaMa>
for that I would use bitbake -S to verify that the sigdata changed when it should (and how it should)
<JaMa>
but for different DISTROs I usually use separate builddirs
<Tyaku_>
Oh yeah, I don't get this idea.. But are my remarks "normal" if we use the same builddir ?
<Tyaku_>
I mean, is it a normal behavour that sometimes , when we build with DISTRO=A then DISTRO=B and DISTRO=A, we are not sure about what will be in the image ?
<JaMa>
no, that's not normal and would be a bug somewhere
<Tyaku_>
Maybe using separate build-dir will fix it, but it will hide the problem so.
<JaMa>
reusing builddir should trigger inefficient rebuilds/unpacks from sstate, but not undeterministic image content
<Tyaku_>
I need to make some more tests, maybe tomorrow, because today I rebuild Everything (I mean: 'rm -rf tmp' && 'rm -rf ~/yocto-cache')
<Tyaku_>
@JaMa, ok, so then I need to do more tests. But this kind of tests takes me a lot of compilation times. I will see tomorrow.
<JaMa>
-S doesn't need any compilation
<Tyaku_>
I mean "trying to build/flash/test with DISTRO=A then DISTRO=B and then DISTRO=A after a fresh build)" I didn't try -S option yet, (bitbake is building)
florian_kc has joined #yocto
<Ad0>
rburton, ok
vladest has quit [Remote host closed the connection]
ptsneves has joined #yocto
jmd has quit [Remote host closed the connection]
vladest has joined #yocto
jmd has joined #yocto
florian has quit [Ping timeout: 260 seconds]
Dr_Who has quit [Quit: So long and thanks for all the bits.]
Dr_Who has joined #yocto
goliath has quit [Quit: SIGSEGV]
alessioigor has quit [Quit: alessioigor]
ptsneves has quit [Ping timeout: 264 seconds]
fermion has quit [Ping timeout: 264 seconds]
fermion has joined #yocto
mvlad has quit [Remote host closed the connection]
yudjinn has quit [Ping timeout: 260 seconds]
jmd has quit [Remote host closed the connection]
smokey has joined #yocto
<smokey>
newbie yocto user looking for some help...
<smokey>
anyone there?
<Saur_Home>
Depends on what you need help with?
nerdboy has quit [Remote host closed the connection]
<Saur_Home>
smokey: ^
<smokey>
thanks,. I am getting an error during packaging:
<smokey>
DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/tdowty/cfc510p/christian_devel/poky/meta-secure-core/meta-efi-secure-boot/recipes-bsp/efitools/efitools-native_git.bb:do_populate_sysroot', '/home/tdowty/cfc510p/christian_devel/poky/meta/recipes-bsp/grub/grub-efi_2.06.bb:do_populate_sysroot', '/home/tdowty/cfc510p/christian_devel/poky/meta/recipes-core/gli
<smokey>
hmmm... pasting long data didn't work
<landgraf>
smokey: use pastebin
<Saur_Home>
Use pastebin to paste logs etc...
<smokey>
Anyway... how to debug this?
<Saur_Home>
Can't say from the above. Need the actual error...
<smokey>
I started with a working build and added secure boot layers and configuration, which has broken the build
<smokey>
here;s the actual error from the log:
<smokey>
install: cannot stat '/home/tdowty/cfc510p/christian_devel/poky/build/tmp/deploy/images/innoflight-cfc510-live-usb/grub-efi-bootx64.efi': No such file or directory
<smokey>
There is no indication in terminal output of an earlier build failure.
<nerdboy>
should probably be a dependency on grub-efi somewhere for that ^^
<smokey>
great. i will try that.
<smokey>
OK, I do see that one of my receipes has a dependency on grub-efi.
<smokey>
Can I use pastebin from an irc web client?
<landgraf>
smokey: you can paste pastebin link here
Net147 has quit [Read error: Connection reset by peer]
<Saur_Home>
IMAGE_INSTALL:remove = "grub" in anything but an image recipe and/or .conf file will have no effect. One recipe cannot affect another recipe.
<smokey>
Ahhh... that sounds like it could be the problem.