<rburton>
it has a selftest running which stopped doing stuff at 1am this morning
<RP>
rburton: wait for maint I guess
<rburton>
yeah
<RP>
and hope my build finishes or merge some patches blind
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
<eirikb[m]>
In my docker yocto runtime + SDK-image endeavour, would it be possible to kind of automatically source the toolchain? So it is always "enabled" in the image?
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
dacav has quit [Ping timeout: 248 seconds]
jclsn has quit [Quit: WeeChat 3.5]
dacav has joined #yocto
AKN has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
goliath has joined #yocto
<frosteyes1>
JaMa: just sent you an email regarding qtwayland in meta-qt5 (might just be easier to answer hear)
<RP>
rburton: it caught up quite quickly when it did get there! :)
<JPEW>
abelloni: Thanks, I can take a look.... which host do I ssh into?
* JPEW
feels he should probably know that somehow....
<RP>
JPEW: fedora36-ty-1
<RP>
JPEW: it is in the bug
<JPEW>
AH, got it
<JPEW>
Thanks
<JPEW>
Ok, I'm in.... do I have to do something special to get access to that directory? Currently my user (jpew) doesn't have access to that directory. Sorry, it's been a while since I was on an AB node.
<RP>
JPEW: sudo -iu pokybuild
jmiehe has joined #yocto
<JaMa>
frosteyes1: I've replied to e-mail, lets move it to github issue ticket
<mcfrisk>
hi, many recipes in kirkstone poky now add patches to SRC_URI with an :append. Why is the old style += append not used anymore? It's getting trickier to do minor patch or SRC_URI modifications now, or is that the purpose?
<RP>
mcfrisk: I'd love to get us back to +=
<mcfrisk>
RP: is it ok that I send patches? I just want to be able to rewrite SRC_URI of u-boot in custom layers while keeping rest compatible with updates in poky
<RP>
mcfrisk: I'd say yes. There may be some conditional cases we need to keep (native patches) but in general I'd prefer to see += used
<mcfrisk>
RP: ok
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<frosteyes1>
JaMa will do
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<qschulz>
mcfrisk: is there any SRC_URI:machine in there?
<qschulz>
that would be reason for using :append
<qschulz>
instead of +=
<qschulz>
since append will apply to both SRC_URI anmd SRC_URI:machine
<mcfrisk>
qschulz: no, see poky/meta/recipes-bsp/u-boot in kirkstone and master
<mcfrisk>
since several recipes are doing that, I was wondering if bbappends should use some other method for overriding, maybe machine/distro appends if that works
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
mcfrisk: the operators are a kind of arms race :(
<JPEW>
RP: ... do the test run in parallel on the QEMU target?
<RP>
JPEW: no
<JPEW>
I think these `DEBUG: time` statements are not what I think they are then.... they are all over the place :)
<kanavin>
RP: can I throw a quick idea your way? build/conf/local.conf.d/ - yes/no/maybe?
Schlumpf has quit [Quit: Client closed]
<RP>
kanavin: maybe but we need to step back and think about the bigger design
<RP>
JPEW: I don't even remember what/where those are
<kanavin>
RP: I thought about how the fragments would be actually brought into an active build, and this seems like the easiest way. But I can write up something to oe-architecture when this release is out.
<kanavin>
RP: just wanted to ensure you don't shoot it down immediately for some well-known reason :)
xmn has joined #yocto
<RP>
kanavin: In some ways I dislike the "copy" approach that such a directory structure implies
<RP>
I'd rather a conf file specified which ones were wanted rather than have copies
<kanavin>
RP: I am also not sure what is the better direction - copy snippets or refer to them. If you refer to them, you cannot change them. If you copy them, you miss out on upstream changes.
<RP>
kanavin: I prefer only having copies of things you actually modify (and then get to own)
<kanavin>
RP: ideally, no one should ever have to look at yocto configs until you actually want to modify their behavior. e.g. if you want docker, use 'oe-setup-build find docker' - not that dissimilar to a binary package manager actually, but working on a 'yocto config' level.
<JPEW>
Ah, `endtime` is actually the timeout, that makes more sense
<kanavin>
RP: but this warrants a proposal on oe-architecture, which should be done later
<RP>
kanavin: if people don't need to look at the fragments, that implies they're better handled by reference as they don't chage
<RP>
JPEW: ah, yes. This sounds like paranoid debugging we added
jwinarske has joined #yocto
<kanavin>
RP: perhaps the default would be handling by reference, but we could think of some 'copy on write' workflow if that is seen as beneficial
leon-anavi has quit [Quit: Leaving]
<RP>
copy on write happens to work with the way conf files are today
<RP>
they're searched in BBPATH order
zpfvo has quit [Ping timeout: 248 seconds]
<kanavin>
RP: I mean, supported by tooling, e.g. 'oe-setup-build add docker' will insert a reference, but 'oe-setup-build modify docker' will make a copy, and make clear the implications to the user
<RP>
kanavin: but that could just copy into the build's conf directory
<kanavin>
RP: yes, hence build/conf/local.conf.d/ idea I mentioned earlier ;)
<RP>
kanavin: you don't need that though
<RP>
that just adds complexity which isn't needed
<kanavin>
RP: how come? I would not want any tool to modify local.conf itself
<RP>
kanavin: say you have a fragment meta-poky/conf/fragments/xxx.inc. You copy that to build/conf/fragments/xxx.inc
<RP>
no need to modify local.conf
<kanavin>
RP: but how would it be picked up by bitbake then?
<kanavin>
ah!
<kanavin>
via path magic
<RP>
right. This magic works today for classes and conf files
<kanavin>
RP: but then how would the original fragment be 'enabled' in the build?
<kanavin>
in the first place
<RP>
kanavin: that would require a list in local.conf
<RP>
but you don't have to change local.conf to fork a fragment
<RP>
we may as well expose the user to way path works as it is there and they'll have to deal with it at some point
<kanavin>
RP: right, then this shifts the problem to enabling a fragment in the first place - programmatically modifying local.conf is not something I would like
sakoman has joined #yocto
<RP>
kanavin: which is a bit of a different discussion
<RP>
I dislike copying fragments around more than I dislike changing a list of fragments in local.conf
<RP>
we do have code which can edit files already :/
<qschulz>
build/conf/bbconf.conf with a list in there, à la bblayers.conf?
seninha has joined #yocto
<kanavin>
I'd rather create symlinks than edit files
<kanavin>
systemd/sysvinit style :)
<RP>
which is why I said this needs to be thought about as part of the bigger picture
<kanavin>
RP: sure, it's just to seed the brain cells really - thanks :)
<RP>
kanavin: the trouble is people tend to push these kinds of interfaces to breaking point
<RP>
i.e. even if you didn't make it fork things, people soon would
<RP>
this is one reason why I've always said no to classappend files
<RP>
technically trivial but a really bad idea for the project
<RP>
Refusing those is probably one of my better decisions! :)
<kanavin>
RP: I would be horrified if I'd have to understand those as part of my 'upgrade yocto BSP' projects :-)
<kanavin>
RP: every now and again I wonder if oe/bitbake could be redesigned in an 'immutable' fashion
<kanavin>
not that it's practical or realistic, just a thought exercise kind of
<RP>
kanavin: one of it's strengths is that you can change anything
<RP>
there are just different levels of pain in changing different things
jmiehe has quit [Remote host closed the connection]
<JPEW>
RP, abelloni: Left a commend on https://bugzilla.yoctoproject.org/show_bug.cgi?id=14787 I don't know the root cause yet, but it looks like test_dnf_install_from_disk test earlier is stopping some services accidentally
sotaoverride has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
JPEW: some neat debugging there, nice! :)
<JaMa>
frosteyes1: TY
kscherer has joined #yocto
<alessioigor>
Which are the recommended combination operator?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
jwinarske has quit [Remote host closed the connection]
ecdhe has quit [Ping timeout: 244 seconds]
davidinux has quit [Ping timeout: 260 seconds]
ecdhe has joined #yocto
davidinux has joined #yocto
jwinarske has joined #yocto
davidinux has quit [Ping timeout: 244 seconds]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<qschulz>
alessioigor: combination operator?
zpfvo has quit [Quit: Leaving.]
florian_kc has joined #yocto
jmiehe has quit [Quit: jmiehe]
Tokamak has joined #yocto
prabhakarlad has joined #yocto
<rburton>
kanavin: i don't suppose you have a rpm 4.18 upgrade patch floating around do you
milosv has quit [Ping timeout: 248 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<RP>
rburton: was it released?
<rburton>
ah no its still RC
<rburton>
sorry, misread a bug comment
<RP>
rburton: we will need to upgrade so I did wonder about the rc
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
jwinarske has quit [Remote host closed the connection]
<ptsneves>
i think that ltp and watchdog have DEPENDS on libtirpc but it's usage is disabled.
<ptsneves>
Does anybody know any history on this?
<ptsneves>
if not i will submit a patch removing it
<RP>
ptsneves: the git logs probably have info?
dgriego has joined #yocto
jwinarske has joined #yocto
jwinarske has quit [Ping timeout: 260 seconds]
<ptsneves>
RP: for ltp the disabling is ancient(2014) 2020ba7c48793c2a628d90b63fd91d5c283de5ca. The knob was added to stop using tirpc but the depends was not dropped
<ptsneves>
> +[PATCH] add knob to control whether tirpc support should be checked
<RP>
ptsneves: "tirpc support is broken upstream. in the meantime, allow to disable tirpc."
<ptsneves>
exactly. it has been disabled for some time but DEPENDS remained
<rburton>
it's *possible* that it still needs tirpc to build, even with the option disabled. but yeah, remove the depends and check the output doesn't change.
<RP>
ptsneves: I wonder if it uses it anywhere else?
<rburton>
the key is checking that the output is identical. if its a pointless dependency, the binaries won't change.
jwinarske has joined #yocto
<RP>
ptsneves: we should confirm that it really doesn't use it
<ptsneves>
nevermind. ltp does not have a depends i mixed things :(
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
Tokamak_ has joined #yocto
Tokamak has quit [Ping timeout: 260 seconds]
jwinarske has quit [Remote host closed the connection]
geoffhp has joined #yocto
<RP>
cves look to be going crazy on master :(
mckoan is now known as mckoan|away
jwinarske has joined #yocto
jwinarske has quit [Ping timeout: 248 seconds]
<rburton>
i mailed the cpe people about two qemu cves which had bad cpes
<rburton>
three CVEs for the same issue in rpm is annoying
<RP>
rburton: thanks!
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<kanavin>
rburton, no, but I can offer you python 3.11rc1
mrnuke has quit [Ping timeout: 244 seconds]
zeddii has joined #yocto
florian_kc has quit [Ping timeout: 244 seconds]
prabhakarlad has quit [Quit: Client closed]
Ram-Z has quit [Ping timeout: 248 seconds]
Ram-Z has joined #yocto
alessioigor has quit [Quit: alessioigor]
Tyaku has joined #yocto
mrnuke has joined #yocto
<Tyaku>
Hi, is it possible with systemd to start a service when a specific interface (eth0) is UP ? I tried to put a condition with "sys-subsystem-net-devices-eth0.device" but it pass even if the interface is DOWN.
<Tyaku>
I also try to put scripts in "/etc/network/if-up.d" folder, but unfortunately they are not executed when interface is up/down. Probably because i am missing a package.
dgriego has joined #yocto
odra_ has joined #yocto
odra has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
odra__ has joined #yocto
odra_ has quit [Ping timeout: 268 seconds]
davidinux has quit [Ping timeout: 260 seconds]
Ram-Z has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
justache is now known as justJingo
nemik has quit [Ping timeout: 260 seconds]
florian_kc has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
Ram-Z has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<mischief>
Tyaku: you can use network-online.target to synchronize services, but you also need to define the condition for 'network-online-ness' (typically via systemd-networkd and networkd-wait-online). this is more of a systemd question than a yocto question though..
<mischief>
and it's really better if your service is simply resilient to network failures (or auto-restarts on network failure)
Tokamak_ has quit [Ping timeout: 255 seconds]
Tokamak has joined #yocto
usva_td has joined #yocto
<Tyaku>
The objective is just to set a secondary IPV4 (used for rsyslog) on the network interface eth0 when it is UP
<Tyaku>
Thanks for your response, I used this "/lib/systemd/systemd-networkd-wait-online -i eth0" like in the service file that you have mentioned.
<Tyaku>
And it works like a charm
ptsneves has quit [Ping timeout: 268 seconds]
amitk has quit [Ping timeout: 268 seconds]
Vonter has quit [Ping timeout: 248 seconds]
odra__ has quit [Ping timeout: 244 seconds]
btztrz has quit [Remote host closed the connection]
jwinarske has joined #yocto
dwagenk has joined #yocto
zeddii has quit [Read error: Connection reset by peer]
usva_td has quit [Remote host closed the connection]
Tyaku has quit [Ping timeout: 248 seconds]
usva_td has joined #yocto
Tyaku has joined #yocto
DvorkinDmitry has joined #yocto
zeddii has joined #yocto
<DvorkinDmitry>
hello, I have lines in my kmeta config files: ## CONFIG_XXX=y, case I just wanted to comment this line for future. Is is correct to do so? How whould you recommend to write comment?
usva_td has quit [Remote host closed the connection]
jwinarske has quit [Remote host closed the connection]
usva_td has joined #yocto
jwinarske has joined #yocto
jwinarske has quit [Remote host closed the connection]
usva_td has quit [Remote host closed the connection]
jwinarske has joined #yocto
usva_td has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
jwinarske has quit [Remote host closed the connection]
florian_kc has joined #yocto
zeddii has quit [Ping timeout: 252 seconds]
kscherer has quit [Quit: Konversation terminated!]