Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tokamak has joined #yocto
sakoman has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jclsn4 has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn4 is now known as jclsn
Vonter has joined #yocto
<khem>
kanavin sounds good, I think we might want llvm 14 for Spring LTS, I am in process of upgrading meta-clang to 14.x
Tokamak has joined #yocto
Tokamak has quit [Client Quit]
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
Tokamak has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<alejandrohs>
3~
<alejandrohs>
oops :)
olani has joined #yocto
dev1990 has joined #yocto
<LetoThe2nd>
yo dudX
<jclsn>
LetoThe2nd: How did you like the film btw?
pgowda_ has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
<LetoThe2nd>
jclsn: new one? not seen yet. hopefully soon.
rob_w has joined #yocto
Vonter has joined #yocto
<jclsn>
LetoThe2nd: Yeah, I really liked it
mckoan|away is now known as mckoan
kroon has joined #yocto
<mckoan>
good morning
lucaceresoli has joined #yocto
ex-bugsbunny has joined #yocto
xmn has quit [Ping timeout: 256 seconds]
dacav has quit [Quit: leaving]
dacav has joined #yocto
mvlad has joined #yocto
rfuentess has joined #yocto
dacav has quit [Quit: leaving]
dacav has joined #yocto
rob_w has quit [Remote host closed the connection]
GillesM has joined #yocto
florian has joined #yocto
Schlumpf has joined #yocto
likewise has joined #yocto
goliath has joined #yocto
smsm has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
florian_kc has joined #yocto
leon-anavi has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
Wouter0100 has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Wouter0100 has joined #yocto
Schlumpf has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #yocto
Vonter has joined #yocto
zyga-mbp has joined #yocto
<kanavin>
khem, llvm 14 isn't due until after feature freeze I think, and llvm deadlines can slip
<kanavin>
but if they can get it at least to rc stage by march, maybe it's possible
goliath has quit [Quit: SIGSEGV]
pgowda_ has quit [Quit: Connection closed for inactivity]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
goliath has joined #yocto
florian has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 250 seconds]
prabhakarlad has joined #yocto
davidinux has quit [Ping timeout: 256 seconds]
davidinux has joined #yocto
dlan has quit [Remote host closed the connection]
rfuentess has quit [Remote host closed the connection]
dlan has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
dagmcr has quit [Ping timeout: 250 seconds]
dagmcr has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Vonter has joined #yocto
<ad__>
question: i am in zeus, anm openssl bbappend is disabling a lot of openssl featurs, as md4 and others, but then, wpa-supplicant fails to build, claiming for md4 functions. How to manage this ?
<jclsn>
Why do packages sometimes not get installed althoug I have added them via IMAGE_INSTALL:append ?
<jclsn>
I really don't get this
<qschulz>
jclsn: triple-check that they really are added to IMAGE_INSTALL
<qschulz>
bitbake-getvar should be helpful
<jclsn>
I checked that
<qschulz>
also, some packages are empty
<qschulz>
and finally.. how do you know theyr are not installed?
<jclsn>
Might also have to do with the honister override syntax in this case
<jclsn>
My colleague did install some sytemd units with IMAGE_INSTALL_append_mx8, which would be IMAGE_INSTALL:append:mx8 now right?
<jclsn>
If yes, the syntax conversion script did miss this
<jclsn>
I know that they are not installed, because the files are not in /etc/systemd/system
florian has joined #yocto
<agherzan>
jclsn: that would be correct
<agherzan>
The conversion script is not perfect.
<qschulz>
jclsn: the conversion script requires some configuration IIRC, e.g. all the possible OVERRIDES
<qschulz>
and since mx8 is not one that exists in poky/oe-core then it was probably just not added
<qschulz>
so in fact, your packages were NOT in IMAGE_INSTALL and bitbake-getvar would have returned such info
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
sakoman has joined #yocto
<jclsn>
They are in IMAGE_INSTALL. I checked that with bitbkake -e
<qschulz>
jclsn: if the syntax was incorrect AND you didn't have the package installed, I'm pretty sure it was not :)
<qschulz>
anyways, if it's fixed it's the most important :)
<jclsn>
No it is still not there
<jclsn>
It is seems like it isn't included in the image when rebuilding
<qschulz>
jclsn: where is your IMAGE_INSTALL?
<qschulz>
the append one, in which file
<jclsn>
I realized this a few times. I always had to clean everything and rebuild, which is weird
<jclsn>
In the image recipe
<qschulz>
this is a huge red flag
<qschulz>
you shouldn't need to rebuild
<qschulz>
if it does fix it, you seriously need to investigate because it means you cannot trust that whatever you're building is actually what gets installed on your system
<qschulz>
well except if you clean everything all the time, which is rather inefficient :)
<jclsn>
Well I need to package the image at least
<jclsn>
I also installed busybox and the printenv command is not available
<jclsn>
Ah not busybox is there
<jclsn>
Maybe recipe to install the sytsemd units is incorrect
<jclsn>
*ah no
<qschulz>
jclsn: check in the recipe if there isn't something that was missed during the migration to the new syntax
<qschulz>
e.g. RDEPENDS_${PN}
<qschulz>
or FILES_, etc...
<jclsn>
There is just the do_install:append:mx8 () {..}
<qschulz>
fabatera[m]: you shouldn't have to do anything
<qschulz>
fabatera[m]: no need to call oe_runmake even, the default do_compile should have this tackled
<moto-timo>
kas users, is there any tooling to grab the commit hash for the layers and inject into the yaml? To pin the refs for a release or tag for instance.
<qschulz>
fabatera[m]: however, there might be some changes required in the Makefile of the project is they hardcode some stuff (which is common for Makefile based projects)
<qschulz>
moto-timo: some python script with yaml parsing and subprocess git and you should be good to go :p
<moto-timo>
qschulz: sure, I was just thinking this should be a common enough workflow that someone might have already done it (could be a feature for kas)
<moto-timo>
asking for a customer, not my own use ;)
<kanavin>
RP: right, the syslog one is new to me
<kanavin>
RP: [pokybuild@centos8-ty-1 ~]$ cd /home/pokybuild/yocto-worker/oe-selftest-centos
<kanavin>
-bash: cd: /home/pokybuild/yocto-worker/oe-selftest-centos: No such file or directory
<kanavin>
this doesn't help :-/ I have to replicate the failure separately then
<RP>
kanavin: lots of people running builds so the broken ones age faster :(
<RP>
kanavin: I have the no-x11 one saved if you want a look
<kanavin>
RP: I'll take a look at virgl first
<RP>
kanavin: ok. I'm going to probably tweak the testcase for the syslog one, get more info next time it fails
<qschulz>
moto-timo: I could see a kas freeze-layer command for example. But the issue I see is when you have layers spread over multiple yaml files
<qschulz>
I don't remember but is it even possible to override a commit hash of a layer from one yaml in another? that would make it more or less impossible to figure out exactly what to do without human intervention?
<moto-timo>
qschulz: good point. 'kas is not psychic' to paraphrase rburton
<moto-timo>
and I already have layers in multiple yaml files (keep feature and repos together)
<moto-timo>
it might get even worse if you use yaml from other layers and they included other layers...
<fabatera[m]>
@qsYes, that's the case
* moto-timo
tosses that idea in the bin
<fabatera[m]>
s/@qsYes/qschulz: Yes/
<moto-timo>
project specific python script as you suggested it is qschulz
<fabatera[m]>
qschulz: in my case I have to use oe_runmake. I'm not sure if CC LD etc should be passed
<qschulz>
fabatera[m]: why do you "have to" ?
<qschulz>
I mean, it's technically done for you already, so just wondering why you need to explicit it
<fabatera[m]>
qschulz: But as I found here looks like it should:
<qschulz>
fabatera[m]: if I were you I'd have two recipes, one for the module and one for the app
<qschulz>
one would `inherit module` to build an out-of-tree module and have most of the usual stuff setup
<qschulz>
you might still need to have ti patch the makefile (I used to maintain an out-of-tree recipe for a wifi kernel driver ,a few patches for the build system were needed
<qschulz>
and then a more common recipe for the app which is in the same git repo
<qschulz>
at least it'll be easier to debug and get help
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
<fabatera[m]>
qschulz: Sure it is, but the package comes "as is".
<fabatera[m]>
I would patch it every time a new one is available or use oe_runmake
<qschulz>
fabatera[m]: we maintain plenty of patches in OE/YP which are used across multiple versions when we cannot upstream them :)
<fabatera[m]>
qschulz: Alright! If I just let do_compile would not build the too modules inside the package: they are located in separete folders with separate make files
<fabatera[m]>
s/too/two/
codavi has joined #yocto
<fabatera[m]>
and there are other apps to build in the same package, so I'm doing everything in one do_compile
<fabatera[m]>
There is no error, I'm just asking if, in this case, I need to pass CC LD.
akiCA has quit [Ping timeout: 256 seconds]
<qschulz>
fabatera[m]: what I;'d do is just cd into the directory with the makefile and call module_do_compile function directly
<qschulz>
everything is done for you already
<qschulz>
and since the module classes are actually pretty not straightforward, I'd saw it's better to reuse whatever was already done
<qschulz>
at least we know it's properly tested
<qschulz>
ah but you do that already
<qschulz>
well, module_*do*_compile actually and not module_compile
xmn has joined #yocto
<qschulz>
IIRC if the makefile is correctly written, the env variables CC, CFLAGS, LDFALGS, etc... should be used without doing anything
<qschulz>
i.e. make will read from the environment first
<rfs613>
shivamurthy: not sure why you are seeing all those errors. I've updated my ubuntu-20.04 with all the latest patches, and I am able to rebuild both autoconf-native and libtool-native from dunfell
goliath has quit [Quit: SIGSEGV]
<shivamurthy>
rfs613: is it because I am using ubuntu 20.04 container?
<rfs613>
shivamurthy: well, mine is native rather than container, but this shouldn't really make a difference. More likely something in the setup is different, like bash-vs-dash for example.
<shivamurthy>
I am using dash as default
<rburton>
that *shouldn't* be a problem
<rfs613>
I switched mine to bash a long time ago, but the Yocto manual doesn't mention it, I think it was done for other reasons (xilinx or altera tools)
<khem>
JPEW: Any pointers for starting to create SBOMs with latest master ( some steps ) I find some docs/ppts describing the process etc at highlevel but I was looking for enabling it in builds
<rburton>
shivamurthy: its quite possible its the container causing problems, if the filesystem on /home is unusual
<JPEW>
khem: Mostly, just INHERIT += "create-spdx"
<JPEW>
khem: There are a set of 4 variables at the top of create-spdx.bbclass (all default to "0") that you can use to add additional things
Schlumpf has quit [Quit: Client closed]
<qschulz>
shivamurthy: I guess another question would be what the exact command you use to start the container (also, rootless container?)
<shivamurthy>
lxc exec <cont_name> -- su --login ubuntu
<rburton>
i guess this could be lxc messing things up, never tried it. can you try a build outside the container?
<fabatera[m]>
s/module_compile/module_do_compile/
<rfs613>
the 'mount' output is a bit curious, it lists /dev/nvme0n1p2 both as root (/), as /home/ubuntu/workspace, and as /snap
<shivamurthy>
rburton: i will give a try now
<rburton>
rfs613: put that under 'lxc messing things up'?
<rburton>
clearly that's not the truth
<rburton>
so some 'magic' hiding the file system reality?
* rfs613
wasn't clear if this 'mount' output was from the host, or from within lxc container
<rburton>
good point, we need the mount from inside, ie what bitbake will see
<shivamurthy>
rfs613: from lxc container
<rburton>
yeah lxc is doing something 'interesting' then
<rfs613>
yep seems like it
<rburton>
my money is the workspace mount is some magic filesystem like docker has, where it pretends to be a proper FS but then you try and do some things and it silently does something else
<fabatera[m]>
<qschulz> "fabatera: we maintain plenty..." <- qschulz: Thanks a lot for the patience! :)
<fabatera[m]>
Yes, I totally understand and agree it's the best way. But in my case it's not convenient (or practical) to maintain the patches and one recipe for each app/module (6 in this package and there are 20 packages more).
<fabatera[m]>
It's not standard way but works very well in the long term.
<shivamurthy>
I am mounting workspace directory from host to container, i have some other things there which i use for different yocto build
jsbronder has quit [Quit: WeeChat 3.2]
jsbronder has joined #yocto
<rburton>
shivamurthy: so what's the mount on the host, as the container thinks that the same device is mounted in three places, which isn't right
<rburton>
we will figure this out and get a sanity check added :). (we already check for the thing that breaks everyone using a linux docker on macos)
<kergoth>
iirc bind mounts show up like that in /proc/mounts, looks like just multiple mounts of the same device rather than what it actually is
<qschulz>
fabatera[m]: yeah sometime sthe best practices don't apply well to some obscure development workflow of some companies :)
<rburton>
shivamurthy: and /home/ubuntu/workspace is just a normal directory on your host which you magic into the container somehow?
<shivamurthy>
rburton: yes
behanw has joined #yocto
<rburton>
super weird
smsm has quit [Quit: Client closed]
florian has joined #yocto
<khem>
JPEW: thanks
<khem>
JPEW: will it work in dunfell too ? or is it too much to ask 🙂
<RP>
smurray: thanks. I need to sort this syslog issue before I can merge more but sounds like we don't have any blockers which is great
rfuentess has quit [Quit: HERMOSAS CHELAS!!!!!!!!!!!!!]
<JPEW>
khem: there is interest in back porting it. I think the license changes sakoman is bringing in will help with that
<khem>
JPEW: thanks
mckoan is now known as mckoan|away
<kanavin>
RP: I reproduced the centos thing - qemu from sstate does not link with librt, while qemu on centos does
<kanavin>
RP: looking into why
<shivamurthy>
rburton: rfs613: you are right, the problem is with container, build works on normal system
<shivamurthy>
thanks for the help and sorry to trouble you
florian has quit [Ping timeout: 256 seconds]
<RP>
kanavin: this is probably the "merge everything into one libc" issue?
goliath has joined #yocto
<RP>
kanavin: oh, I remember what I was thinking of now. This was why I added those binary shims to pseudo :/
<khem>
kanavin: librt has been merged into libc in recent glibc so perhaps its being built on one of the newer distros where it wont have librt in DT_NEEDED but when built on centos it does
<RP>
so pseudo native would work cross platforms
<khem>
maybe we should use tools tarball
<RP>
kanavin: although with uninative it should be using that and not need the separate librt :/
Tokamak has joined #yocto
SpiderDroneX has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SpiderDroneX>
Yo, any tips on the quickest way to add a temporary single file to the image? Can something hacky get into local.conf without having to create a recipe and then adding it to the image...
<kanavin>
RP: I was just looking at libSDL from the two builds, and indeed:
<qschulz>
SpiderDroneX: ROOTFS_POSTPROCESS_COMMAND I guess
<kanavin>
Dynamic Section:
<kanavin>
NEEDED libdl.so.2
<kanavin>
NEEDED librt.so.1
<kanavin>
NEEDED libpthread.so.0
<kanavin>
NEEDED libm.so.6
<kanavin>
NEEDED libc.so.6
<kanavin>
SONAME libSDL2-2.0.so.0
<kanavin>
and another:
<RP>
sgw: I've sent a patch to try and aid debugging of the syslog issue FWIW and kanavin is looking at the qemu librt one
<kanavin>
Dynamic Section:
<kanavin>
NEEDED libc.so.6
<kanavin>
NEEDED libm.so.6
<kanavin>
SONAME libSDL2-2.0.so.0
<SpiderDroneX>
qschulz: Thanks
<sgw>
RP: ok, is the Qemu one related to the libEGL failure on centos8 machine or a different one?
<RP>
kanavin: there is a dummy librt in uninative which I think is supposed to cover this :/
<RP>
sgw: not sure. It is the one with the librt issue being reported
<kanavin>
RP: the first is from direct build on centos 8, the second one from sstate
<kanavin>
RP: so I would have to identify the distro the second one is from and see why it won't link with librt?
<RP>
kanavin: I think more the question is why that second one won't find or use the librt from uninative correctly
<kanavin>
RP: because librt is requested by a mesa driver opened with dlopen() :(
<kanavin>
RP: so it ends up using one from the centos host
<kanavin>
(the mesa driver is also from the host)
<RP>
kanavin: so the issue is a mesa built on centos8 with a libsdl that wasn't?
<RP>
ah, right, so it is a host mesa
<kanavin>
RP: yes
<rfs613>
shivamurthy: glad you were able to get your build working - I've not used lxc myself so I have no idea what might be happening there.
<RP>
kanavin: it should still be looking at the uninative librt first :/
<RP>
kanavin: we probably need an strace to see if it does look at it and rejects it or just doesnt look
<sgw>
Ok, I will just add the other 2 syslog failures to the bugzilla for tracking then
<kanavin>
RP: I have the straces
<SpiderDroneX>
qschulz: But I can't define function outside a `bb` file to feed the `ROOTFS_POSTPROCESS_COMMAND`, right? ;)
<RP>
kanavin: ok, so does it reject the librt or not look at it at all?
<kanavin>
RP: let me check again
<rburton>
shivamurthy: no problem. Really want to figure out what is causing problems so we can detect it…
<RP>
kanavin: would be in sysroots-uninative
<kanavin>
RP: first and only mention of librt:
<kanavin>
openat(AT_FDCWD, "/lib64/../lib64/tls/librt.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<ex-bugsbunny>
question: is there a possibility to add files in a bbappend to be automatically taken into account by referred recipe's do_install() (in an accumulating way) or do I have to use a do_install_append() in the bbappend file for that purpose?
<kanavin>
so not tries to look in uninative at all, seems like
<RP>
kanavin: I wonder if LD_LIBRARY_PATH would help
<RP>
sorry need to step away for food :/
<kanavin>
I'll keep poking
<qschulz>
ex-bugsbunny: bbappends, bbclasses, included/required files, original recipe are all flattened and then "exectued"
<RP>
kanavin: it is almost certainly because we're mixing libc bits, it needs all the uninative ones
<RP>
libc is backwards compat but not forwards
<qschulz>
ex-bugsbunny: so if your original do_install installs a whole directory or has a glob matching the file in the bbappend, that's probably ok yes
<ex-bugsbunny>
just to get it right, qschulz: that means that I just need to replicate the file hierachy of the underlying recipe's output in my bbappend's files directory and this will get merged before do_install() kicks in, right?
<qschulz>
ex-bugsbunny: didn't understand the question
SpiderDroneX has quit [Quit: Client closed]
<kanavin>
RP: librt is loaded by host's /lib64/libLLVM, via RPATH which seems to bypass uninative (not sure why) and is also immune to LD_LIBRARY_PATH. LD_PRELOAD works though.
<sgw>
kanavin: are you looking at the recent qemuppc failure? Just to confirm from my swatting
<kanavin>
sgw, no
<sgw>
RP: it appears that the build dir for the qemuppc failure is already gone then, just have the buildbot logs
<kanavin>
RP: ah, RPATH takes priority over everything else in loader's search order
<kanavin>
with uninative it shouldn't though
<kanavin>
(e.g. we should tweak uninative's loader to ensure it's not tricked into loading things from the host that are available in uninative)
Minvera has joined #yocto
<kanavin>
or just declare Centos 8 broken for having RPATH in its binaries
<ex-bugsbunny>
qschulz: sorry for the complicated question, maybe I better describe an example: assume the recipe uses a git repo which contains dir1/file1 (source path in do_install() will have tp prepend "git/" for it to be installed in some place in rootfs); the bbappend wants to add dir1/file2 to be also installed; is it possible to simply use FILESEXTRAPATHS_prepend := "files:" and put file2 into files/dir1/files2 relative to bbappend file to have i
<ex-bugsbunny>
hopefully this is clearer ...
<ex-bugsbunny>
qschulz: do_install() uses a for loop over ${WORKDIR}/git/dir1/* when placing these files into appropriate location within target rootfs
<ad__>
trying to exclude a package from the image build, but maybe since part of a packagegroup, PACKAGE_EXCLUDE does not work, same for IMAGE_INSTALL_remove
behanw has quit [Quit: Connection closed for inactivity]
<landgraf>
Documentation of PERSISTENT_DIR is confusing (or simply wrong). It says "Specifies the directory BitBake uses to store data that should be preserved between builds". In fact the data is is NOT preserved between build by default and controlled by BB_SRCREV_POLICY. Default value is "clear". This causes https://bugzilla.yoctoproject.org/show_bug.cgi?id=14707
<ex-bugsbunny>
qschulz: nevermind, it is as easy as you said, I only needed also to add an appropriate SRC_URI in bbappend and it worked :-) thanks for your help
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
florian has quit [Ping timeout: 250 seconds]
creich_ has joined #yocto
creich has quit [Ping timeout: 240 seconds]
likewise has quit [Read error: Connection reset by peer]
<kergoth>
Should probably change that from 'uses' to 'may use'
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Minvera has quit [Quit: Leaving]
ex-bugsbunny has quit [Remote host closed the connection]
florian has joined #yocto
mvlad has quit [Remote host closed the connection]