Herrie|Laptop has quit [Ping timeout: 248 seconds]
Herrie|Laptop has joined #yocto
landgraf has quit [Remote host closed the connection]
<LetoThe2nd>
yo dudX
landgraf has joined #yocto
goliath has quit [Quit: SIGSEGV]
d-fens has quit [Read error: Connection reset by peer]
d-fens has joined #yocto
frieder has joined #yocto
frieder has quit [Client Quit]
frieder has joined #yocto
jooli has joined #yocto
zpfvo has joined #yocto
jooli has quit [Client Quit]
mckoan|away is now known as mckoan
<mckoan>
good morning
gho has joined #yocto
mvlad has joined #yocto
goliath has joined #yocto
bps2 has joined #yocto
alicef has quit [Quit: install gentoo]
alicef has joined #yocto
bps2 has quit [Ping timeout: 252 seconds]
<qschulz>
o/
lamm1 has joined #yocto
* alessioigor
waves all
leon-anavi has joined #yocto
azcraft has joined #yocto
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
justReddy is now known as justache
marek has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
Chris[m]1234567 has joined #yocto
dev1990 has joined #yocto
seninha has joined #yocto
florian has joined #yocto
zpfvo has joined #yocto
d-s-e has joined #yocto
manuel1985 has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
camus has quit [Quit: camus]
Net147 has quit [Quit: Quit]
camus has joined #yocto
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
<qschulz>
ah shoot. I thought the RDEPENDS dependencies were built only when the package was requested by another dependency or an image, but that's not true is it?
<RP>
qschulz: thanks to debian renaming, we have to build them
alessioigor has quit [Quit: alessioigor]
<qschulz>
so the only way to avoid a big RDEPENDS dependency is to have a recipe per package :/
alessioigor has joined #yocto
<qschulz>
the example here is a recipe with two packages, one I need, another I don't
<qschulz>
the one I don't bring in python3-cryptography (so rust, llvm and co)
<qschulz>
RP: is this a new thing or did I completely missed this fact?
<RP>
qschulz: it has always been like this
<RP>
qschulz: I don't like the situation but changing it would be very hard
<qschulz>
RP: or packageconfig but that makes little sense since it would only impact rdepends and require bbappends or conf file changes for something that should be image-specific :/
<qschulz>
RP: ok, TIL :)
<qschulz>
RP: I suggest we remove .deb support, nobody uses that... right? /s
DvorkinDmitry has joined #yocto
jmiehe has joined #yocto
<RP>
qschulz: it isn't deb support, it debian renaming. Even if you remove that, you still can't know which rdepends the package manager will follow at image build time
manuel1985 has quit [Ping timeout: 256 seconds]
<RP>
Looks like something broke badly in the new uninative. I can guess what the rest of my day will be doing :(
jmiehe has quit [Quit: jmiehe]
starblue has quit [Ping timeout: 265 seconds]
<RP>
abelloni: I confirmed the segfault bisects to the uninative upgrade
starblue has joined #yocto
<qschulz>
RP: we need the debian renaming because of .deb packages no?
<RP>
qschulz: no, something totally different
<RP>
debian allows parallel install of libraries by non overlapping package names
<RP>
we have debian package renaming through debian.bbclass
<qschulz>
moto-timo: mmmm sad. Is there some configuration of patchwork or documentation on mail subject pattern matching so I can forward this to b4 maintainer, I'm pretty sure the project is interested in proper patchwork support
<RP>
zeddii: are you running with a bitbake server timeout set?
* RP
just noticed some very very weird and broken bitbake behaviour when debugging uninative
* RP
wonders if he'll have to debug that first
<qschulz>
RP: mmmm I thought it was the ".deb packages containing only one lib is renamed with the name of the lib" mechanism... i'm missing something but thanks for the pointers
<RP>
qschulz: it applies to all package names, not just debian
<RP>
qschulz: the concept is generically useful in theory
bps2 has joined #yocto
odra has joined #yocto
Granjow has joined #yocto
Herrie|Laptop has quit [Ping timeout: 246 seconds]
Herrie|Laptop has joined #yocto
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
<Granjow>
One of my recipes requires /sbin/sh, but QA complains about missing RDEPENDS on it. How do I find out which recipe provides it, or what I can RDEPEND on for /sbin/sh?
<rburton>
that should be /bin/sh
<rburton>
there isn't a sh in sbin
zpfvo has joined #yocto
<RP>
Found the bug. My parsing changes broke uninative
<RP>
well, I think uninative is broken, my changes exposed the issue :/
<RP>
what a pain to debug
* RP
tries to remember where he was with the other issue
<rburton>
RP: up there with "why is this thread causing an exception" which obviously goes away when gdb is involved
<rburton>
*shakes fist at debuginfod*
<Granjow>
rburton: Hm. nut uses it in several scripts. I'll check if I'm not configuring it correctly.
<RP>
kanavin: it looks like the something between patchelf 0.14.5 and 0.17.0 breaks
<RP>
kanavin: you, me and wang have touched it with upgrades
<rburton>
Granjow: grep says only in the solaris and hpux scripts
<rburton>
so don't install those
<rburton>
RP: so working hunch is that debuginfods woes are because we're hitting it whilst it is still scanning the rpms. the warnings are threads colliding and the occasional fails are when it just hasn't finished sweeping yet. obviously super annoying to fix without a "sleep(60) #hope for the best"
<rburton>
at least i can replicate the warnings on demand and sleeping makes them disappear
warthog9 has quit [Quit: Leaving]
warthog9 has joined #yocto
<DvorkinDmitry>
I have a lot of warnings like WARNING: mc:tppg2:glib-2.0-1_2.62.6-r0 do_package_qa: QA Issue: glib-2.0-ptest rdepends on locale-base-el-gr, but it isn't a build dependency? [build-deps]
<DvorkinDmitry>
how can I get rid of it?
amsobr has joined #yocto
<Granjow>
rburton: Thanks! I'm trying really hard, but I cannot find out how to get rid of these :D I know this is not a Yocto issue anymore, but in case you know how off the cuff, could you give me a hint? The is --without-solaris-smf which does something else, and Makefile.am:307 looks like it thinks I'm on SunOS and it would not support “Linux” at all.
Herrie|Laptop has quit [Ping timeout: 260 seconds]
d-s-e has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
<landgraf>
Is there a tool to convert spec to bb? Google gave me few results from 2013-2015 which are not in the project anymore and probably not up to date
davidinux has joined #yocto
marek has quit [Quit: Client closed]
<zeddii>
RP: I used -k to try and get everything to build, even when my golang applications were blowing up. and it appears that at least everything that completed is not restarting to build now.
<zeddii>
at least autotools are not trying to rebuild anymore :)
<rburton>
landgraf: easier to just do it by hand
bps2 has joined #yocto
<RP>
zeddii: I don't really know what happened there, seems very odd :/
<zeddii>
I'll keep an eye on it, and have a better report next time. for now, I'm diving into go.
<landgraf>
rburton: well. I'm planning to do this for ~200 spec files :)
sakoman has joined #yocto
<rburton>
landgraf: you'll be rewriting them anyway
<RP>
For anyone who cares, it is the patchelf patchelf: upgrade 0.15.0 -> 0.16.1 upgrade that breaks uninative
<landgraf>
for sure I will. but better start from something semi-crafted
<rburton>
landgraf: the tools you found likely still work, once you update them for new override syntax
<rburton>
but, as someone who wrote the "generate spec file from bb" layer, it's a terrible idea
<JaMa>
depends on how different those 200 spec files are, e.g. superflore for ROS packages wasn't too terrible, because they had relatively strict way how to build stuff, so it was quite consistent across couple thousand packages
<landgraf>
JaMa: I don't think it will be my case :-/ From the positive side most of this packages are in YP layers already and I may end up bbappending stuff which is missing
<JaMa>
that's surely better quality than any translation from .spec
lamm1 has quit [Remote host closed the connection]
lamm1 has joined #yocto
Herrie|Laptop has quit [Ping timeout: 268 seconds]
amsobr has joined #yocto
<DvorkinDmitry>
I have SRC_URI:append:class-target = ... how to make it arch-specific, i.e. add my machine name?
<rburton>
DvorkinDmitry: another override
<rburton>
:append:class-target:aarch64
<DvorkinDmitry>
rburton, thanks!
Herrie|Laptop has joined #yocto
kscherer has joined #yocto
Granjow has quit [Quit: leaving]
<moto-timo>
qschulz: I don’t know of any docs about what breaks patchwork or lore picking up a patch… just years of seeing it happen give a few tribal knowledge hints …
<moto-timo>
qschulz: i for one would be interested in seeing a wiki/blog post about how you used b4…
<rburton>
if lore misses a patch it's normally because it's huge and got moderated
<moto-timo>
(I use it to grab patches)
<rburton>
my b4 workflow is a mailer shortcut to copy the message id to the clipboard, and an alias bz='b4 shazam'. copy id, bz <paste> applies the thread i was looking at
<rburton>
very lofi, works
<rburton>
jonmason has something better involving scripts and pushes to CI
amsobr has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
<kanavin>
RP: I see there's a patch to patchelf, do you still need help?
alessioigor has joined #yocto
<moto-timo>
rburton: I know we have seen patchwork fail when certain characters were in the subject line… I don’t remember specifics.
<moto-timo>
qschulz: I believe the YP was recently upgraded… to vanilla patchwork and not the fork of the fork
<moto-timo>
qschulz: right, but at the time you first sent it I saw no sign of the patches… maybe that was just a cli issue on you side
<qschulz>
moto-timo: It ended up in spam most likely, I had sent a mail with a From from my professional mail address while sending it from my personal mail server....
<qschulz>
(I have a somewhat particular setup :) )
Herrie|Laptop has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Quit: Client closed]
Herrie|Laptop has joined #yocto
manuel1985 has joined #yocto
rob_w has quit [Quit: Leaving]
dev1990 has quit [Quit: Konversation terminated!]
demirok has quit [Quit: Leaving.]
prabhakarlad has joined #yocto
<RP>
kanavin: thanks!
yashraj466 is now known as yssh
yssh has quit [Quit: Client closed]
yashraj466 has joined #yocto
yashraj466 has quit [Quit: Client closed]
yashraj466 has joined #yocto
Estrella_ has joined #yocto
Estrella has quit [Ping timeout: 260 seconds]
thomasd13 has quit [Ping timeout: 252 seconds]
Estrella__ has quit [Ping timeout: 272 seconds]
invalidopcode has quit [Remote host closed the connection]
<sirhcel[m]>
Specifying this through `local.conf` gives the desired result but feels quirky to me. Is there a way of specifying such dependency from rauc's recipes?
<sirhcel[m]>
Specifying this through `local.conf` gives the desired result but feels quirky to me. Is there a way of specifying such dependency from rauc's recipes?
<shoragan[m]>
Ah, then we should handle that gracefully in RAUC.
<sirhcel[m]>
qschulz: Thank you very much! I will try out using bbappend files.
<sirhcel[m]>
Alright, then let's switch over to #rauc:matrix.org.
<rburton>
kanavin: ERROR: core-image-sato-sdk-1.0-r0 do_rootfs: The postinstall intercept hook 'update_font_cache' failed, details in /home/pokybuild/yocto-worker/meta-clang/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato-sdk/1.0-r0/temp/log.do_rootfs <-- is that your doing with the qemu tune changes?
<sirhcel[m]>
shoragan: Thank you very much!
manuel1985 has quit [Ping timeout: 255 seconds]
cambrian_invader has joined #yocto
yashraj466 has quit [Quit: Client closed]
prabhakarlad has joined #yocto
d-s-e has joined #yocto
<RP>
rburton: is that not the tune issue on f36-ty-1 as it has the v2 processors?
<Guest8>
| FIT Map data, unit id 65536, serial 3879446968, Sat May 31 11:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
<Guest8>
| expected (len 131)
<Guest8>
| FIT Map data, unit id 65536, serial 3879446968, Sat May 31 10:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
<Guest8>
| ../../git/tests/fit-map-data.testfile: FIT Map data, unit id 65536, serial 3879446968, Sat May 31 11:00:34 2014, manufacturer 1 (garmin), product 1632, type 4 (Activity)
<Guest8>
Looking like some clock configuration in my system is causing this
PhoenixMage has quit [Ping timeout: 272 seconds]
PhoenixMage has joined #yocto
<moto-timo>
RP: 🎉
olani- has joined #yocto
alessioigor has quit [Quit: alessioigor]
vquicksilver has joined #yocto
florian_kc has joined #yocto
leon-anavi has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 255 seconds]
tangofoxtrot has quit [Remote host closed the connection]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
yssh has quit [Quit: Client closed]
azcraft has quit [Remote host closed the connection]
dmoseley has quit [Ping timeout: 260 seconds]
dmoseley has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
dmoseley has quit [Ping timeout: 252 seconds]
dmoseley has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]
chap has joined #yocto
dmoseley has joined #yocto
amsobr has quit [Ping timeout: 260 seconds]
chap has quit [Quit: I laugh with many, but don't trust any.]
bps2 has quit [Ping timeout: 265 seconds]
<RP>
JPEW: your code looks right to be btw now I've had a better chance to look at the issues
florian_kc has joined #yocto
xmn has joined #yocto
<JPEW>
RP: :D
<RP>
JPEW: I've sent an updated version of the patch. I'm pretty sure it wasn't one we would have run into with the current code but who knows what might happen in the future. I did have to add some timeout bits to it
<JPEW>
Ya. Cool. Better to have it right now and not have to figure out why later
<JPEW>
If your want a timeout on the 'with self.idle_cond' you can lock the semaphore instead (as long as it's the same one the condition variable is bound to)
<JPEW>
with self.idle_cond is just short have so you don't have to know which mutex you need to lock
<RP>
JPEW: so I could just replace that with with bb.utils.lock_timeout(self._idlefuncsLock) ?
<JPEW>
Ya I think so
<RP>
If we can, we should do that as it avoids deadlocks in theory
<JPEW>
Yep
<RP>
JPEW: I've updated the patch, thanks
<RP>
quick local testing looks ok so I'll run it on the AB overnight