<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.
<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
<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]
<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
<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
<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
<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>
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.
<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
* 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]
<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