<mckoan>
Universal Greeting Time, an Internet Relay Chat convention whereby a person who joins a conversation is greeted "Good morning" and a person who leaves is bidden "Good night", regardless of the time zones of participants.
<LetoThe2nd>
its always beer o clock somewhere
<mcfrisk>
rust-native and cargo-native recompiling a lot..
<qschulz>
mckoan: funny how this came up naturally without even knowing about it :)
Danct12 has quit [Read error: Connection reset by peer]
WinstonSmith2600 has quit [Remote host closed the connection]
xmn has quit [Quit: ZZZzzz…]
Schlumpf has quit [Ping timeout: 245 seconds]
mckoan is now known as mckoan|away
<rburton>
mcfrisk: i've a patch to remove one of the python-native dependencies which will help slightly
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
rburton: we could put the dependency in the "ignore the sig changing" list
<rburton>
rust depending on pynative still makes me very sad
<RP>
rburton: it fixed a horrible problem. Better solutions very welcome
<RP>
rburton: how sure are we that the arm getty mess caused that failure? :/
<rburton>
ish
<RP>
rburton: I'm a bit worried we're missing something. The two arm selftest failures are bugging me
<RP>
combined with the x86 one which I just can't explain
<rburton>
can we set a range of when stuff broke?
<RP>
rburton: its 6.
<RP>
6.5
<rburton>
_sure_?
<RP>
rburton: well, some of these have seemed to hang around for a while but much much rarer
<RP>
6.5 makes them happen much more frequently, if it is the same issue
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
manuel1985 has joined #yocto
prabhakarlad has quit [Quit: Client closed]
florian_kc has joined #yocto
prabhakarlad has joined #yocto
amitk_ has quit [Ping timeout: 260 seconds]
amitk has joined #yocto
GillesMM has quit [Quit: Leaving]
luc4 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
brazuca has joined #yocto
Minvera2 has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
<qschulz>
I think I'm going to regret asking this questio but is there an override for a specific version of a recipe?
<qschulz>
pn-my-recipe-1.0 by any chance :D ?
<qschulz>
I don't think so?
<qschulz>
bitbake-getvar OVERRIDES -r u-boot doesn't return anything else than pn-u-boot so I'll answer myself and say no
brazuca has quit [Quit: Client closed]
xmn has joined #yocto
<rburton>
this is when you used a versioned bbappend
<qschulz>
sadly yes, but this isn't fun :)
<qschulz>
for some context, trying to find a solution to being able to build linux kernel pre-6.5 AND 6.5+ on ARM for meta-rockchip
<mcfrisk>
and bbappends to versions which don't exist anymore break builds, unless bbappends are in dynamic layer paths
<qschulz>
in 6.5 the path for ARM (Aarch32) DTB got moved to vendor directories like they are on Aarch64
<qschulz>
but then KERNEL_DEVICETREE doesn't work anymore for both
<mcfrisk>
as user, I had to BBMASK some bbappends away due to this, e.g. meta-xilinx and wayland_10.2.bbappend which doesn't exists on poky master anymore
<mcfrisk>
qschulz: convert from patch to a script with same output and some conditional paths? (if initial version was a patch)
<qschulz>
mcfrisk: didn't get it sorry
<mcfrisk>
if change is a patch to specific version, try to apply the same change via a script e.g. sed line which can check for additional things like versions or if paths exist
<qschulz>
so, force Aarch32 boards to update their path to have their vendor path in (so match newer kernels)
<qschulz>
and if building for an older kernel, it'll try with the basename only if it cannot find the file
<qschulz>
but this isn't nice for current users
<mcfrisk>
would be a good idea to support broader kernel version ranges, also for RP in case downgrade is needed
<qschulz>
the other option is to use a glob pattern with current path (old layout, all Aarch32 DTB in the same dir so only basename) and check if there's only one match for this glob pattern and take it, but I kinda don't like it
<qschulz>
Actually... this is probably something rburton had to deal with in meta-arm... let's check it
<qschulz>
or zeddii as part of kernel updates maybe... mmm
<qschulz>
rburton: ack
Xagen has joined #yocto
Estrella__ has joined #yocto
Vonter has quit [Ping timeout: 248 seconds]
Vonter has joined #yocto
<RP>
mcfrisk: if you have any ideas on the remaining issues I'm open to them. I can't quite explain some of the missing getty issues :(
<mcfrisk>
RP: checking the details you provided...
rob_w has quit [Remote host closed the connection]
<luc4>
Hello! Is SYSTEMD_AUTO_ENABLE ??= "enable" sufficient to enable at boot systemd services even for readonly rootfs?
<mcfrisk>
RP: FWIW, I've update poky to latest master in our setup including update of kernel from 6.4 to 6.5 and on our arm64 environtment(s) with qemu and a number of boards all tests just work. something on x86_64 and/or oe selftests is different to our setup, or test runner load is higher with qemu
Guest6 has quit [Quit: Client closed]
Maxxed has quit [Ping timeout: 255 seconds]
<LetoThe2nd>
luc4: i think it is SYSTEMD_AUTO_ENABLE ??= "1"
Maxxed has joined #yocto
<landgraf>
LetoThe2nd: It's enable/disable
<LetoThe2nd>
landgraf: ok
goliath has quit [Quit: SIGSEGV]
<luc4>
LetoThe2nd: hope this is not something unavailable when the image is ro
<LetoThe2nd>
luc4: last time i looked it worked fine on RO
<luc4>
LetoThe2nd: thanks, then it must be me doing something wrong
<landgraf>
luc4: first of all double check if systemd is in DISTRO_FEATURES
<qschulz>
zeddii: thanks for chiming in :)
<luc4>
landgraf: yes, it. The services are there, I can enable them, start/stop etc... the enable is missing though
<landgraf>
luc4: do you have some sort of custom pkg_postinst scripts?
<luc4>
landgraf: I have the do_install script, but nothing else
<luc4>
landgraf: is the order relevant maybe?
<luc4>
landgraf: should I inherit systemd and set the other vars after do_install()? Cause I see some examples where the order is different than mine.
<landgraf>
luc4: SYSTEMD_AUTO_ENABLE is processed in systemd.bbclass, so yes, you must inherit systemd in your recipe
<luc4>
landgraf: I already did that, but is the order important?
<luc4>
do_install() before inherit?
<landgraf>
I don't think so
prabhakarlad has quit [Quit: Client closed]
<luc4>
landgraf: what about this? NATIVE_SYSTEMD_SUPPORT. Is this important? I just noticed it is there in some examples.
<landgraf>
luc4: can you share you recipe maybe? on pastebin service
<luc4>
landgraf: ah ah... it worked now... I think one of these last things made it work.
<luc4>
landgraf: I changed the order and added NATIVE_SYSTEMD_SUPPORT.
<luc4>
landgraf: I wonder what change made it work.
<landgraf>
luc4: are you using some older branch/release?
<luc4>
landgraf: I'm using kirkstone
<landgraf>
luc4: NATIVE_SYSTEMD_SUPPORT is not defined in kirkstone
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<landgraf>
it must be something really old
<luc4>
landgraf: in fact I couldn't find it in the manual
<luc4>
I have other services to add. I'll experiment a bit. Probably the order matters then...
Xagen has joined #yocto
<luc4>
landgraf: thanks for your help!
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
luc4 has quit [Ping timeout: 255 seconds]
Danct12 has joined #yocto
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
manuel1985 has quit [Ping timeout: 260 seconds]
<rburton>
random idea: write coverage reports for bitbake runs, identifying what recipes were build. then ci could validate that all recipes in a specific layer were actually built.
<fray>
it's approaching the north america fall holiday season.. why wouldn't we want to release everything at the same time?
Kubu_work has quit [Quit: Leaving.]
<tlwoerner>
denix: thanks :-) i think Ryan's meta-ti-bsp/recipes-kernel/linux/ti-kernel-devicetree-prefix.inc will be quite useful
zpfvo has quit [Quit: Leaving.]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
tgamblin has quit [Ping timeout: 258 seconds]
florian_kc has quit [Ping timeout: 255 seconds]
florian has quit [Ping timeout: 255 seconds]
tgamblin has joined #yocto
florian has joined #yocto
florian_kc has joined #yocto
alberto_pianon has joined #yocto
radanter has quit [Remote host closed the connection]
<alberto_pianon>
Hi, I created a layer with no recipes, only classes and a python lib, to start playing with an implementation of the proposed unpack tracer API. It apparently works, but when I run bitbake I get a warning:
<alberto_pianon>
WARNING: No bb files in default matched BBFILE_PATTERN_meta-bbtracer '^/build/poky/4.3_M3-311-gc6ed95a7e4/meta-bbtracer/'. I'd like to get rid of that warning but I cannot avoid setting BBFILE_PATTERN. Any hints? Thanks!
<reatmon>
Afternoon folks. I'm seeing some odd sstate cache behavior on our build farm for master builds. I'm basically getting very little sstate reuse if I rerun the same build right after the first one finishes. I'm not seeing this under kirkstone, so I'm thinking it's something in our setup for master, or some change in master that I don't have configured correctly. Is there a good way to debug this?
<RP>
reatmon: hash equivalence?
<RP>
reatmon: can you compare the stamps directories between the two builds ?
<reatmon>
I have that setup. At least I see the hash db on our server has data in it. So I think it is setup correctly.
<reatmon>
where is the stamps dir?
<RP>
reatmon: are you sharing the data between all the builds that use that sstate cache?
<RP>
reatmon: tmp/stamps/
<reatmon>
We share it from a NAS over http.
<reatmon>
the sstate that is.
<RP>
reatmon: do all the builds point at a common hash equivalence server?
<reatmon>
Yes.
<RP>
ok, then I'd suggest comparing the stamp dirs
<RP>
see where the differences start, bitbake-diffsigs might help once you have files to compare
<reatmon>
ok. I'll copy the stamps dir and run the build again. Thanks.
<reatmon>
Just for sanity sake. I should be able to make a build for a machine on one server. And then run a clean build on a second server for the same target and it should be able to find all of the sstate from the first server's build. Right? I don't need any of the files from the first build server? Just the sstate on the NAS and the hash equiv server.