rfiizshyl has quit [Remote host closed the connection]
dadgmjcgb has quit [Remote host closed the connection]
olani_ has quit [Remote host closed the connection]
olani- has quit [Ping timeout: 244 seconds]
vthor has quit [Excess Flood]
leon-anavi has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
Guest97 has joined #yocto
zeemate has quit [Ping timeout: 276 seconds]
<Guest97>
hey, having a small problem using devtool extract or devtool modify, it does fail complaining about a detached HEAD state, not sure how to recover as it does not fill the workspace/source/<recipe> directory
<Guest97>
devtool should create its own local branch, all i need to do is change a source file, commit the change locally and git format patch... create a bbappend and introduce the patch to this bbappend, should be straight forward :-(
florian has joined #yocto
grma has quit []
grma has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
bigch1cken has quit [Quit: Client closed]
Guest97 has quit [Quit: Client closed]
frgo_ has quit [Remote host closed the connection]
frgo has joined #yocto
frgo has quit [Remote host closed the connection]
frgo has joined #yocto
bigch1cken has joined #yocto
goliath has joined #yocto
olani- has joined #yocto
frgo has quit [Remote host closed the connection]
frgo has joined #yocto
<qschulz>
ah, got a nice "bug" today. I used WICVARS += in my image recipe and wic wouldn't build anymore
<qschulz>
because the WICVARS defaults from image_types_wic wouldn't be in there
<qschulz>
and they aren't in there because we use inherit_defer for image_types_wic.bbclass
<qschulz>
so my += happens before the ?= from the inherited class
<qschulz>
I wonder if this is intended
<mcfrisk>
these happen frequently to me with various variables. I've learned to be really careful and "bitbake -e" any changes to variables. Still I get bitten by this weekly...
<qschulz>
also wondering if we couldn't mix and match normal inherit and inherit_defer in image.bbclass
<qschulz>
to limit the number of variables this would happen to
<qschulz>
mcfrisk: bitbake-getvar -r <recipe> <VAR> for something a bit more digest BTW :)
* RP
worries about variable assignment stuff a lot
rfuentess has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
rfuentess has joined #yocto
enok71 has joined #yocto
enok has quit [Ping timeout: 252 seconds]
enok71 is now known as enok
florian_kc is now known as florian
rcw has joined #yocto
rcw has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
rcw has joined #yocto
rcw has quit [Quit: Client closed]
rcw has joined #yocto
wicki has quit [Quit: Ping timeout (120 seconds)]
wicki has joined #yocto
darko311 has joined #yocto
darko311 has quit [Client Quit]
goliath has joined #yocto
olani- has quit [Ping timeout: 276 seconds]
rfuentess has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
martin_97 has joined #yocto
zeemate has quit [Ping timeout: 276 seconds]
bigch1cken has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
<khem>
rburton: I get Video unavailable is it posted on some alternative universe
<rburton>
must have broke the link. it was monty python's I'm So Worried song
<khem>
bitbake assignement operators are tricky indeed we have added to it overtime
<khem>
maybe it is monty python3 now so youtube forgot to set !/usr/bin/python3 in scripts :)
<khem>
I use to watch a lot of them may years ago, quite funny
<rburton>
Life of Brian still holds up as an excellent film, fwiw.
rcw has quit [Quit: Client closed]
<khem>
hmm
<khem>
rburton: btw. did you get around the libunwind issue on musl/arm64
tlwoerner has joined #yocto
druppy has joined #yocto
ptsneves has joined #yocto
goliath has joined #yocto
florian has quit [Ping timeout: 244 seconds]
goliath has quit [Ping timeout: 276 seconds]
enok has quit [Ping timeout: 276 seconds]
savolla has joined #yocto
enok has joined #yocto
wicki has quit [Quit: Ping timeout (120 seconds)]
wicki has joined #yocto
<rburton>
Yeah patches on the list
enok has quit [Ping timeout: 276 seconds]
florian has joined #yocto
wicki has quit [Quit: Ping timeout (120 seconds)]
wicki has joined #yocto
enok has joined #yocto
florian has quit [Ping timeout: 245 seconds]
Kubu_work has quit [Quit: Leaving.]
druppy has quit [Ping timeout: 276 seconds]
wicki has quit [Quit: Ping timeout (120 seconds)]
wicki has joined #yocto
cyxae has quit [Quit: cyxae]
LainIwakura has joined #yocto
florian has joined #yocto
LainIwakura has quit [Ping timeout: 240 seconds]
zeemate has joined #yocto
olani- has joined #yocto
LainIwakura has joined #yocto
<khem>
cool see it hmm gc sections interesting
<khem>
lto also reproduces this problem so I think its the same underlying problem
<khem>
because LTO also figures out the unused sections and automatically removed them
savolla has quit [Ping timeout: 260 seconds]
<rburton>
yeah
<rburton>
if you have insight then great, i really don't want to become the libunwind packager but it keeps on breaking on me :)
LainIwakura41 has joined #yocto
LainIwakura has quit [Ping timeout: 240 seconds]
olani- has quit [Ping timeout: 252 seconds]
frgo has quit [Read error: Connection reset by peer]
frgo has joined #yocto
<khem>
There is another awkward problem I encountered lately, where binutils libbfd build uses libtool to generate shared libs, so linker correctly links with libc.so on musl since thats what it is called on musl, but it goes ahead and rewrites it to libc.so.6 ld-linux-x86-64.so.2 in DT_NEEDED sections because on glibc systems /usr/lib/libc.so is a linker stub
<khem>
so libtool expands it before installing the final .so
<fray>
ya, I want to come up with some sort of reproducer, but since ld.so seems to be able to use the filter entries, we should pay attention to them in dependency scanning..
enok has quit [Ping timeout: 265 seconds]
<fray>
hopefully I can get someone with access to the code (since it's closed source) to help me write a simple reproducer that isn't closed.. then I can attach it and we'll have something to build against..
<fray>
I'd never seen the FILTER section before today..
<fray>
(the real issue was the section wanted 'libmali.so', and libmali.so.0 was the SONAME, so the dev-so stuff split it off and the libraries didn't work
<khem>
reproducer is to create a custom ld script which has something like above and then use that gcc -shared -o libbar.so bar.c -Wl,-Tfilter.lds
<khem>
now you have created libbar.so which had FILTER entry for libfoo.so
<fray>
I spent all day trying to figure this out until I found the solaris docs on what it was doing.. :P Then it became obvious it was a SONAME mismatch.. :P
<khem>
I remember fixing libmali.so to edit SONAME to use libmali.so.0, it was my patch :)
<khem>
without correct soname packager treats it like a symlink
<khem>
development one
<fray>
well, I'm going to let our people who work with ARM deal with that (since I don't have the source). But it's definitely broken
<khem>
do you get libmali.so as binary blob ?
<khem>
My memory is faded but I think I did it for meta-96boards layer