ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.11) Nov 29-Dec 1, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
otavio has quit [Remote host closed the connection]
uniqdom has quit [Quit: Leaving]
BCMM has quit [Quit: Konversation terminated!]
goliath has quit [Quit: SIGSEGV]
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
xmn has joined #yocto
yashraj466 has quit [Quit: Client closed]
florian has quit [Ping timeout: 272 seconds]
sakoman has quit [Quit: Leaving.]
otavio has joined #yocto
seninha has quit [Quit: Leaving]
camus has joined #yocto
camus1 has joined #yocto
seninha has joined #yocto
camus has quit [Ping timeout: 272 seconds]
camus1 is now known as camus
davidinux has quit [Ping timeout: 260 seconds]
invalidopcode has quit [Read error: Connection reset by peer]
invalidopcode has joined #yocto
davidinux has joined #yocto
seninha has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
xmn has quit [Quit: ZZZzzz…]
amitk has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
olani- has quit [Ping timeout: 260 seconds]
Herrie|Laptop has joined #yocto
alessioigor has joined #yocto
goliath has joined #yocto
rob_w has joined #yocto
Xagen has quit [Quit: Textual IRC Client: www.textualapp.com]
goliath has quit [Quit: SIGSEGV]
lexano has quit [Ping timeout: 260 seconds]
lexano has joined #yocto
lamm1 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
bps2 has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 265 seconds]
mckoan|away is now known as mckoan
<mckoan> good morning
<kanavin> JaMa, your patch is fine with me. The reason it wasn't defined is that I don't want to define things that aren't proven necessary :-) in my testing and on the AB it was not necessary.
frieder has joined #yocto
<JaMa> ok
<lamm1> ls
manuel1985 has joined #yocto
<lamm1> wrong terminal hehehe
money_ has joined #yocto
money_ has quit [Client Quit]
goliath has joined #yocto
<LetoThe2nd> yo dudX
zpfvo has joined #yocto
money_ has joined #yocto
money_ has quit [Client Quit]
gho has joined #yocto
mvlad has joined #yocto
frieder has quit [Ping timeout: 260 seconds]
money_ has joined #yocto
vladest has quit [Ping timeout: 252 seconds]
<LetoThe2nd> anybody happen to know why python3 and nodejs by now depend on bash? IIRC that wasn't the case some time ago.
<JaMa> let me grep it for you:
<JaMa> meta/recipes-devtools/python/python3_3.11.1.bb:RDEPENDS:${PN}-tests:append:class-target = " ${MLPREFIX}bash"
<JaMa> meta/recipes-devtools/python/python3_3.11.1.bb:RDEPENDS:${PN}-tests:append:class-nativesdk = " ${MLPREFIX}bash"
money_ has quit [Ping timeout: 256 seconds]
<LetoThe2nd> JaMa: yeah I found that too, but I'm not talking about the -tests package
<JaMa> how the hell I'm supposed to guess what you're talking about? "depend on bash" sounds like build time dependency
<LetoThe2nd> JaMa: ok, apologies. my mindset is "unless explicitly stated otherwise, refers to runtime".
frieder has joined #yocto
money_ has joined #yocto
money_ has joined #yocto
money_ has quit [Changing host]
money_ is now known as money
<LetoThe2nd> so, try to improve: why does installing python3 or nodejs cause bash to also be installed? this did not use to be the case some time ago, and I cannot easily spot the reason.
<JaMa> LetoThe2nd: then it's just not true in my builds, python3 is empty package and nodejs doesn't depend on bash (only nodejs-npm does)
<LetoThe2nd> JaMa: hmm interesting. which release?
<JaMa> master from Sunday
<LetoThe2nd> JaMa: distro?
<JaMa> the same in langdale and kirkstone
<JaMa> nodistro, LuneOS, webOS..
<LetoThe2nd> JaMa: okay thanks. then needs more digging obviously :(
<JaMa> depends.dot is your friend
<LetoThe2nd> i know, but oe-depends-dot also just confirmed the chain without naming the reason.
d-s-e has joined #yocto
money has quit [Quit: late]
<mcfrisk> RDEPENDS only? one of them including a #!/bin/bash script somewhere
<mcfrisk> no yocto in https://lwn.net/Articles/912774/ !?
d-s-e has quit [Quit: Konversation terminated!]
d-s-e has joined #yocto
vladest has joined #yocto
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
leon-anavi has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest1 has joined #yocto
vladest has quit [Read error: Connection reset by peer]
vladest1 is now known as vladest
vladest has quit [Client Quit]
vladest has joined #yocto
seninha has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
Herrie|Laptop has quit [Ping timeout: 260 seconds]
Guest8400 has joined #yocto
dmoimas_cynexo has joined #yocto
vladest has quit [Remote host closed the connection]
dmoimas_cynexo has left #yocto [#yocto]
vladest has joined #yocto
Herrie|Laptop has joined #yocto
invalidopcode has quit [Remote host closed the connection]
florian has joined #yocto
invalidopcode has joined #yocto
Guest8400 has quit [Quit: late]
manuel1985 has quit [Ping timeout: 260 seconds]
azcraft has joined #yocto
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
<RP> mcfrisk: I don't know of anyone invited
<RP> mcfrisk: sounds very systemd centric
<kanavin> RP: if you're seeing gdk-pixbuf fails, I'm looking into that
<kanavin> RP: one of the build hosts is using ivy bridge, and after moving to v3 that revealed an erroneous use of target .so with native executable in that recipe --> illegal instruction crash
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
elaye has joined #yocto
<RP> kanavin: I hadn't got there yet but handy to know, thanks! :)
<RP> abelloni: ^^^
<RP> kanavin: I'm a bit worried we have another bitbake lockup :(
<kanavin> RP: if that leads to something I did, I can try to help
<RP> kanavin: it is almost certainly my threading changes
d-s-e has quit [Ping timeout: 272 seconds]
<kanavin> RP, abelloni: I'll also check what happens in qemu on that host. It'll probably crash as well, and so needs to be excluded from kvm workers.
d-s-e has joined #yocto
demirok has joined #yocto
<qschulz> i'm trying to get a recipe-depends.dot or whatever I can get for finding out which package brings in a package I don't want
<qschulz> bitbake -g does not seem to be doing the trick
alessioigor has quit [Read error: Connection reset by peer]
alessioigor has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
<qschulz> mmmm the file does not exist since 3.0, so we should remove this from the help section of some tools :)
starblue has joined #yocto
d-s-e has quit [Ping timeout: 260 seconds]
<kanavin> RP: where does the AB get the list of its workers from? I'm looking at config.py, and it doesn't seem to match reality, e.g. fedora36 is not there.
AntA has joined #yocto
d-s-e has joined #yocto
<RP> kanavin: the config on the controller is slightly out of sync
<RP> kanavin: mostly for passwords and so on
xmn has joined #yocto
<rfried> Hello.
<rfried> Is there a good way to prevent update-rc.d from running in bbappend ?
<rfried> I have some packages I want to install, but I don't want them starting automatically.
<rfried> But I can't find a proper way of disabling it via bbappend.
<rfried> Looks like the updaterc.d is launched as part of the inherit of update-rc.d
d-s-e has quit [Ping timeout: 268 seconds]
xmn_ has joined #yocto
<RP> rfried: do you want to disable update-rc.d for all packages or just one package in particular ?
xmn has quit [Remote host closed the connection]
<rfried> RP: just one package in particular
<RP> rfried: you could set INITSCRIPT_PACKAGES explicitly?
<rfried> it fails because then it runs update-rc.d -r /work/ramon/bsp/bsp/build/tmp/work/aspen-poky-linux/core-image-minimal/1.0-r0/rootfs
<rfried> Basically it removed the two arguments and updare-rc.d fails.
<rfried> basename and default is missing, that's why it fails.
<rfried> RP: ^
<RP> rfried: I don't really understand what you've done or how it would result in that :/
<rfried> RP: the package I'm working on is ntp
<rfried> I created ntp_%.bbappend with the following content:
<rfried> # Override initscripts to disable autoloading
<rfried> INITSCRIPT_NAME = ""
<rfried> INITSCRIPT_PARAMS = ""
<rfried> INITSCRIPT_PACKAGES = ""
<rfried> That's it./
<rburton> just set INITSCRIPT_PARAMS=disable
<rburton> default is "defaults" which is enabling
beneth has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rfried> rburton: works.
<rfried> thanks RB rburton
d-s-e has joined #yocto
manuel_ has joined #yocto
manuel has quit [Ping timeout: 265 seconds]
manuel_ has quit [Ping timeout: 265 seconds]
manuel has joined #yocto
manuel has quit [Read error: Connection reset by peer]
manuel_ has joined #yocto
kscherer has joined #yocto
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter010067 has joined #yocto
xmn_ has quit [Quit: xmn_]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
xmn has joined #yocto
<elaye> Hi, I'm having trouble building a recipe for a Rust private crate. I generated the recipe with `cargo-bitbake`. Bitbake successfully fetches the private repo and it's private dependencies via SSH however when bitbake invokes `cargo build`, cargo is unable to fetch the private repos anymore. I adapted my recipe based on this similar issue for Go
<elaye> https://lists.yoctoproject.org/g/yocto/topic/ssh_auth_sock_unavailable/82558905?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,82558905 but to no avail. Here is the error log: https://pastebin.com/YShHfqBC and here is my recipe: https://pastebin.com/m1gWWZNQ
<qschulz> elaye: it seems your host was not able to resolve gitlab.com?
<elaye> qschulz: yes that's what the cargo error seems to imply however I can build the crate on the same host outside of the bitbake environment, and bitbake is also able to fetch the crate from the private gitlab repo
<rburton> network is disabled in do_compile, so it must be going to fetch. why can't you fetch everything via SRC_URI?
<elaye> rburton: ah I see that would make sense. Everything is actually fetched via SRC_URI, and this works since I can see the repos cloned in the build/tmp directory. So I guess the issue comes from cargo not being able to use the crates fetched by SRC_URI
<RP> rburton: any idea what this means from debuginfod: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/4643/steps/14/logs/stdio ? :/
<RP> rburton: it is also spewing all those warnings which makes the logs really really annoying
sakoman has joined #yocto
vladest has quit [Ping timeout: 260 seconds]
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
vladest has joined #yocto
whuang0389 has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
Xagen has joined #yocto
|Xagen has joined #yocto
goliath has quit [Quit: SIGSEGV]
Xagen has quit [Ping timeout: 246 seconds]
rob_w has quit [Quit: Leaving]
rsalveti has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
d-s-e has joined #yocto
<qschulz> moto-timo: how bad is it to have [PATCH meta-python 0/2] instead of [meta-python][PATCH 0/2]?
<qschulz> moto-timo: I think b4 only supports generating patches with the first pattern
<qschulz> just to know if I should just edit the headers by hand/work with b4 to have something match your worflow
<qschulz> workflow*
<rburton> RP: hm, give me a minute and i'll page that knowledge back in
whuang0389 has quit [Ping timeout: 260 seconds]
<rburton> RP: reliably failing or intermittent
<RP> rburton: intermittent, naturally. I think the long logs are consistent though, just hidden if nothing fails in that thread
<rburton> i wonder if its getting mixed up with multiple testimages happening at once
<RP> rburton: they'd be in separate build directories
<rburton> its a network operation to the host
<rburton> so it might be hitting the wrong debuginfod socket
<rburton> fairly easily tested, give me a bit
Tokamak has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
goliath has joined #yocto
<moto-timo> qschulz: that is a question for khem, as he is the one staging patches
<rburton> RP: the locked database thing is weird as its using an in-memory db for the selftest
<RP> rburton: yes, I don't understand it but I've not looked :/
<rburton> [Mon 09 Jan 2023 11:18:44 AM GMT] (3773146/3773146): upstream debuginfod servers: https://debuginfod.fedoraproject.org/
<rburton> well i doubt that's the problem but that's stupid :)
lamm1 has quit [Ping timeout: 265 seconds]
<rburton> ah i wonder if its grabbing that from the environment somehow
<rburton> yes, interesting
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
manuel1985 has joined #yocto
agrue has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
florian_kc has joined #yocto
agrue has joined #yocto
Estrella has joined #yocto
Estrella__ has quit [Ping timeout: 265 seconds]
Estrella_ has quit [Ping timeout: 268 seconds]
Estrella__ has joined #yocto
frieder has quit [Quit: Leaving]
d-s-e has quit [Ping timeout: 252 seconds]
Payam has joined #yocto
Payam has quit [Quit: Leaving]
gho has quit [Quit: Leaving.]
zpfvo has quit [Remote host closed the connection]
<qschulz> moto-timo: your mail address is outdated here: https://git.openembedded.org/meta-openembedded/tree/meta-python/README#n40
mckoan is now known as mckoan|away
demirok has quit [Quit: Leaving.]
elaye has quit [Quit: Client closed]
<rburton> RP: ffs try to replicate and it just fails [Mon Jan 9 17:07:21 2023] (2119034/2119034): libmicrohttpd error: Failed to create worker inter-thread communication channel: Too many open files
demirok has joined #yocto
<RP> rburton: sounds very strange
<rburton> $ sysctl fs.file-nr
<rburton> fs.file-nr = 13856065536
<moto-timo> qschulz: no, that is a valid email address for non-work FOSS
<victoridaho[m]> Anyone have any ideas on how to resolve "Error: Could not find class file for 'java.net.InetAddressImplFactory" when trying to add "perf" to the build? Not even sure why "perf" needs java.
<rburton> i'll push that up maybe it needs more
<rburton> victoridaho[m]: perf doesn't
<rburton> (i built perf and don't even have java installed or meta-java added)
<victoridaho[m]> rburton: I think it has to do with creating debug symbols etc.
<qschulz> moto-timo: got rejected by your mail provider then
<rburton> ah hm perf does have some java poking
<rburton> so it probably found java on your host and tried to use it
<victoridaho[m]> It's running "/workdir/build-shasta-dev/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/bootstrap/jdk1.6.0/bin/java"
<qschulz> moto-timo: and I stupidly deleted the mails so can't say, will try with a simple mail instead
<rburton> victoridaho[m]: so our perf recipe turns off java support
<rburton> victoridaho[m]: but you're enabling it as its building icedtea, so you shoud talk to the meta-java maintainers
<victoridaho[m]> How do I find who are the maintainers?
<rburton> meta-java's readme file
<victoridaho[m]> thx
<qschulz> moto-timo: k my bad, got a reject from spam assassin or simialr
whuang0389 has joined #yocto
<qschulz> moto-timo: PEBKAC, sorry
florian_kc has quit [Remote host closed the connection]
whuang0389 has quit [Ping timeout: 260 seconds]
<rburton> RP: would be easier to strace if debuginfod didn't spawn literally 1000 threads
<rburton> strace -ff resulted in 1018 log files
<RP> rburton: that sounds a bit crazy :/
florian_kc has joined #yocto
<rburton> RP: its opening a silly number of epoll sockets and hitting the limit on this machine (the 256 core one...)
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 265 seconds]
manuel1985 has quit [Ping timeout: 252 seconds]
alessioigor has quit [Quit: alessioigor]
<kanavin> rburton, -c, --concurrency=NUM Limit scanning thread concurrency to NUM,
<kanavin> default=#CPUs.
<kanavin> default=unlim.
<kanavin> -C, --connection-pool[=NUM] Use webapi connection pool with NUM threads,
<kanavin> relevant maybe?
<rburton> yeah just wondering why its trying to open 1000+ epoll sockets
<kanavin> halstead, how many pre-haswell build machines are there on the AB? I found at least one (fedora36-ty-1) with 'E5-2697 v2' - v2 is ivy bridge, and just one version short. There's a change in oe-core that requires at least haswell hardware when running qemu with kvm.
<kanavin> RP: ^^^. I fixed gdk-pixbuf, but runqemu kvm does crash on that machine, it's just one generation too old.
<kanavin> RP: I'd hope there is not a lot of those, we'd be seeing a lot more crashes if it was so.
<halstead> kanavin: I think there are quite a few ivybridge machines as well as a few ARM64 machines. I can get a count. Which AMD chips are supported?
<kanavin> halstead, intel: haswell and newer, amd: excavator and newer
<kanavin> arm64 is not affected
beneth has joined #yocto
<moto-timo> qschulz: your patches aren't being picked up by lore nor patchwork... perhaps you need to use 'b4 prep --set-prefixes' differently? https://b4.docs.kernel.org/en/latest/contributor/prep.html
<moto-timo> qschulz: I haven't tried using b4 to send patches yet
<halstead> kanavin: I emailed you the list of CPUs. It does appear everything else is haswell or newer.
<halstead> kanavin: Oh and perf-alma8.yocto.io is also an E5-2697 v2. Do we use qemu on the perf workers?
vladest has quit [Remote host closed the connection]
invalidopcode has quit [Remote host closed the connection]
Wouter010067 has quit [Quit: The Lounge - https://thelounge.chat]
invalidopcode has joined #yocto
Wouter010067 has joined #yocto
vladest has joined #yocto
<kanavin> halstead, thanks. perf workers are not affected either.
<halstead> kanavin: So do we need to limit builds on fedora36-ty-1 or retire the hardware?
<kanavin> halstead, I'm not sure what's best, but maybe you have a spare CPU you could swap in, or simply disable the worker.
<kanavin> halstead, I don't think we can easily filter builds at the moment by whether they need kvm or not, so it can't run anything from a-full or a-quck
<halstead> kanavin: I think we are out of spare CPUs. I can double check. We might have to retire that worker and make it a perf machine or something.
florian_kc has joined #yocto
<kanavin> halstead, thanks, I don't have any particular suggestions.
<kanavin> halstead, not sure if you're aware, it's due to enabling level 3 instructions: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
leon-anavi has quit [Quit: Leaving]
<kanavin> level 4 will not be happening anytime soon (or probably not so soon either)
Haxxa has quit [Quit: Haxxa flies away.]
<kanavin> (the table is slightly out of date, qemu does support level 3 since one month ago)
Haxxa has joined #yocto
Estrella__ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
amitk_ has quit [Ping timeout: 264 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
ferry has joined #yocto
ferry has quit [Client Quit]
florian_kc has quit [Ping timeout: 252 seconds]
Estrella_ has joined #yocto
Herrie|Laptop|2 has joined #yocto
Herrie|Laptop has quit [Ping timeout: 260 seconds]
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
florian_kc has joined #yocto
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
sakoman has quit [Quit: Leaving.]
PhoenixMage has quit [Ping timeout: 268 seconds]
PhoenixMage has joined #yocto
Minvera has joined #yocto
GNUmoon has quit [Ping timeout: 255 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
PhoenixMage has quit [Ping timeout: 260 seconds]
GNUmoon has joined #yocto
alessioigor has joined #yocto
PhoenixMage has joined #yocto
alessioigor has quit [Client Quit]
Payam has joined #yocto
ferlzc has joined #yocto
ferlzc has quit [Quit: Leaving]
<RP> kanavin: we might just have to drop back a tune level, we really need the hardware we have
ferry_ has joined #yocto
jooli has joined #yocto
ferry_ has quit [Client Quit]
<RP> halstead: We can probably go back to an older tune for a while as I suspect if we're hitting this, too many others will as well
<halstead> RP, the uninative is ready.
<halstead> RP, can we select the tune adaptively?
<RP> halstead: I saw, thanks for the that. I'll be happy if we can fix some issues with that!
<RP> halstead: no, this is the CPU optimisation the target binaries are built for so it needs to be the same for qemux86-64 everywhere
vmeson has quit [Quit: Konversation terminated!]
<halstead> I suppose this is an example of our diverse build lab helping certain users.
<RP> halstead: right, I think that is the best way to look at it
sakoman has joined #yocto
<JaMa> FWIW: I've changed DEFAULTTUNE to corei7-64 (instead of the original core2-64), because of VirtualBox and all seems to work https://github.com/webOS-ports/meta-webos-ports/commit/d15535fe4eba8b88f10fd50d92400b5e426bfdc2
jooli59 has joined #yocto
jooli59 has quit [Client Quit]
vvmeson has joined #yocto
<paulg> I don't know where to look to answer this - can anyone say if qemu ppc64 boot tests are still run as part of autobuild coverage?
<RP> paulg: I was talking to vvmeson about this last week. We don't build or boot ppc64 at all at the moment
<RP> well, not active
<vvmeson> paulg: Yeah, we need to convince RP and the YP TSC to drop something (mips64!) and add ppc64. I had assumed that ppc64 was being tested.
<paulg> ok - thanks - good to know.
<paulg> and no. I won't support adding ppc64.
jooli512 has joined #yocto
jooli has quit [Quit: Client closed]
jooli512 has quit [Client Quit]
<paulg> we (RP and I) talked about this over a year ago when ppc32 was becoming problematic emulating a 1998 turd.
jooli has joined #yocto
<vvmeson> paulg: but I bet you wouldn't mind if we drop mips64!
<paulg> Yes, I want all old crap dropped. It is no secret.
<paulg> It is how software survives.
<paulg> I'm sure RP would be thrilled to see a release blocked for a yocto-on-Amiga bug.
<RP> paulg: I'd be surprised it worked there in the first place :D
<abelloni> challenge accepted!
<paulg> yocti, tell vmeson ppc64 and mips64 should die together like Thelma and Louise.
<yocti> paulg: Error: I haven't seen vmeson, I'll let you do the telling.
* RP does have YP building images for his AVR microcontrollers
<paulg> yocti, tell vvmeson ppc64 and mips64 should die together like Thelma and Louise.
<yocti> paulg: The operation succeeded.
<RP> The scary bit of my AVR support is it builds a gcc on target cross compiler :D
<paulg> I should know better by now to simply trust tab completion on IRC nicks.
<RP> An x86-64 host building a cross compiler to run on an arm board generating AVR binaries
<paulg> I might actually be able to get behind AVR since there are a zillion wifi LED bulbs out there that could run it.
<paulg> I'm sure I own a bunch....
* vvmeson waits for his ghost /nick to drift into the ether...
<abelloni> RP: which version of gcc are you using for that? :)
<RP> abelloni: it was a while ago
<paulg> abelloni, don't go there. ;-) You'll never come back.
<paulg> things I call "time thief" or "slave to your possessions"
<abelloni> I ripped out avr from the kernel so I know ;)
jooli65 has joined #yocto
<RP> abelloni: it was for firmware for microcontrollers, not linux
jooli65 is now known as jooli512
jooli has quit [Quit: Leaving]
jooli512 is now known as jooli
jooli has quit [Client Quit]
<abelloni> aren't we ready for avr128? :)
Herrie|Laptop|2 has quit [Ping timeout: 265 seconds]
BCMM has joined #yocto
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
mvlad has quit [Remote host closed the connection]
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
<RP> abelloni: skip to 256 ;-)
Minvera has quit [Remote host closed the connection]
vvmeson is now known as vmeson
PhoenixMage has quit [Ping timeout: 272 seconds]
PhoenixMage has joined #yocto
<RP> JPEW: are you around atm? I've found another threading issue. I think I know the answer but...
<JPEW> Sure, I've got a little time
<RP> JPEW: I think we have a problem with the idle condition we added in that there are actually two things needed for the condition - no idle functions *and* the async command is None
<RP> We don't put any locking around the current async command
<RP> JPEW: this currentAsyncCommand in command.py
<RP> JPEW: I think the code races at the moment since the idle functions can be empty but the command hasn't been cleared
<JPEW> Ah `# FIXME Add a lock for this`
<RP> JPEW: heh, yes
<RP> JPEW: note the second last "Registering idle function" with no "Removing idle function"
<RP> JPEW: I think we may be able to roll this all under the same lock/condition
<JPEW> Ya, you would want to use the same lock
<JPEW> Fortunately, the condition can be as complex as you need, so you don't necessarily have to _leave_ it locked all the time
<RP> the condition is easy, we just check for it being None
<JPEW> currentAsyncCommand == None ?
<JPEW> err, `is None`
<JPEW> I write python, I swear
<RP> heh, yes, that :)
<RP> JPEW: https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=6939b8ace763813eebf33bd54f2404bf47cf892c should make the code a bit easier to follow too
* RP remembers why we did this and is happy it isn't needed now
<JPEW> Oh, ya, this can be simplifed a lot
seninha has quit [Quit: Leaving]
seninha has joined #yocto
BCMM has quit [Quit: Konversation terminated!]
<JPEW> RP: Yes, it needs to all be under the same condition variable; it's a little annoying that the state is split between they two classes; that makes it really hard to follow
<RP> JPEW: yes, I was just cursing that a bit :/
<JPEW> I was moving currentAsyncCommand to be under ProcessServer() with atomic get/set/clear functions, but I don't know how to get that object in all the calls in `class Command`
<JPEW> Passed as an argument in runCommand... but not the others
<RP> JPEW: I think with my patch above we can make it appear to runAsyncCommand as well
<RP> JPEW: finishAsyncCommand is harder
<JPEW> RP: I see that
<RP> JPEW: is "buildTargets.needcache = True" the best way to put information against these functions?
<RP> I was wondering about marking the functions which had return codes or shouldn't have finishAsyncCommand called
<JPEW> Oh, ya, you could put a boolean flag in there like that
<JPEW> mmm...you'll probably need them to return their return code in that case
<JPEW> RP: Also... buildTargets and buildFile are the only two that *don't* need it?
<RP> JPEW: right, it isn't straightforward :/. I think we just add the process server to command.Command()
<JPEW> in __init__ ?
<RP> JPEW: right, those two are the only ones that don't need it but there is a return code on another
<JPEW> (as a member)
<RP> JPEW: yes
<JPEW> Ya, I wasn't sure if that was OK in this case, but that would be the most straight forward way
<RP> JPEW: there were reasons it once wasn't possible. Not sure now
<JPEW> ... why don't those two call finishAsyncCommand?
<RP> JPEW: they trigger their own idle loop handlers to be added
<RP> JPEW: grep for idle in cooker.py
<JPEW> Ah, I see
<JPEW> Ah, and the idle function call finishAsyncCommand when they are done
<RP> right
<JPEW> .... intersting
<RP> JPEW: this is what you get to retrofitting server/client split onto really old code
manuel1985 has joined #yocto
<JPEW> Ya
<JPEW> RP: I have to go, but if you get a change, I can review it, otherwise I can try to cook up something tomorrow
<RP> JPEW: thanks. I'll see what I can come up with. You at least agree it is likely currently quite broken? :/
bps2 has quit [Ping timeout: 252 seconds]
GNUmoon has quit [Ping timeout: 255 seconds]
engeugenius has joined #yocto
GNUmoon has joined #yocto
seninha has quit [Read error: Connection reset by peer]
seninha has joined #yocto
engeugenius has quit [Quit: Leaving]
<JPEW> RP: Seems so
<RP> JPEW: https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/t222&id=18c769b173b9f993425c2fcb29200ec689ca0e55 is my attempt at a patch so far
<RP> JPEW: there is a ton of cleanup I think we can do elsewhere but I'm not cluttering this change with it
<RP> JPEW: I've put them on bitbake master-next
manuel1985 has quit [Ping timeout: 264 seconds]
<zeddii> RP: strange question. I updated master to work on my next series. After I did a bitbake core-image-minimal to get a baseline, like I normally do. Whenever I do it again, it is always finding something to build and package. I assume it is related to your latest bitbake changes and maybe something I don't have in my local.conf now ?
<RP> zeddii: it sounds like a bug :(
azcraft has quit [Read error: Connection reset by peer]
<RP> zeddii: always something different or the same thing each time?
<zeddii> I can answer that in a bit. I'll let it complete this time and do it again.
<RP> zeddii: it isn't anything I'm aware of. There was one cache reparsing issue but that was just the cache and reparsing when it shouldn't, not rebuilding
<zeddii> maybe the image didn't really complete the first time ? it dropped me back to the prompt. I'll have to watch for that s well.
<zeddii> since this is what it found on the 2nd bitbake core-image-minimal
<zeddii> which seems like a lot.
<RP> zeddii: you should have a history of build logs in tmp/log/cooker/<MACHINE> FWIW
<RP> zeddii: those will say what happened in each previous build
<RP> zeddii: knowing which task is the first to rebuild is the data point we need
seninha has quit [Read error: Connection reset by peer]
seninha has joined #yocto
dmoseley has quit [Ping timeout: 272 seconds]