<c-thaler>
Hi all. Anyone knows why "require conf/machine/${MACHINE}-extra.conf" works in "local.conf" but not in the "layer.conf" of my custom layer? In the "layer.conf", ${MACHINE} is not expanded.
rfried has quit [Quit: Ping timeout (120 seconds)]
rfried has joined #yocto
<LetoThe2nd>
c-thaler: layer.conf gets parsed earlier and per layer, AFAIK so its not in the build context.
<LetoThe2nd>
c-thaler: hiding things in there is a really bad practise anyways.
pvogelaar has joined #yocto
pvogelaar has left #yocto [#yocto]
ptsneves has joined #yocto
mckoan is now known as mckoan|away
pvogelaar has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
<c-thaler>
Yes, you're right. Just saw it in the include history, sorry.
<c-thaler>
So it's a better practice to keep this "require" statement in the "local.conf"?
<c-thaler>
My idea was to move as many details as possible into my custom layer to keep the "local.conf" as lean as possible.
<kanavin>
c-thaler, for that you need to define a distro and/or a machine
<kanavin>
local.conf ideally should contain only DISTRO and MACHINE assignments
sakoman has quit [Ping timeout: 268 seconds]
<c-thaler>
kanavin ok, thanks. I will look into that.
<rburton>
as kanavin said, the solution to "there's too much in my local.conf" is "create your own distro". simply adding a layer (so layer.conf gets passed) should be a no-op, so adding things to layer.conf is bad practise
rber|res has joined #yocto
sakoman has joined #yocto
ptsneves has quit [Ping timeout: 255 seconds]
<c-thaler>
rburton I've already added a layer. I'm just looking for a clean way to override a few things of the BSP layer I'm using (mostly UBOOT stuff).
sakoman has quit [Ping timeout: 256 seconds]
florian_kc has quit [Remote host closed the connection]
mbulut__ has quit [Quit: Leaving]
<qschulz>
I have to support stupid vendor kernels (5.10; and maybe 44.4) on Scarthgap... I see that I should be able to lower OLDEST_KERNEL to something... well lower. Question: how stupid is it to have it in the machine conf file?
<qschulz>
considering that this touches glibc, I assume a distro would be preferred?
sakoman has joined #yocto
<qschulz>
don't want to have some weird leftover between machines with OLDEST_KERNEL set to 5.15 and some with 4.4 there
mbulut has joined #yocto
mvlad has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
MrCryo has quit [Ping timeout: 272 seconds]
sakoman has joined #yocto
MrCryo has joined #yocto
<kanavin>
qschulz, OLDEST_KERNEL belongs in machine.conf for sure
<kanavin>
it's an indication to glibc about what kernel APIs are safe to enable
<kanavin>
at some point in scarthgap cycle that was raised so that we'd use latest and greatest by default, and particularly 64 bit time apis on 32 bit targets
<kanavin>
which only appeared in 5.something
sakoman has quit [Ping timeout: 256 seconds]
lexano has joined #yocto
<kanavin>
(no idea why glibc can't simply decide at runtime)
<kanavin>
to me glibc is the poster child of 'over-engineered gnu monstrosity'
<qschulz>
kanavin: but isn't the glibc machine agnostic (but not architecture agnostic)? so if i have two machines with the same arch, one with OLDEST_KERNEL at 5.15 (as default in Scarthgap) and one with 4.4... will it not mess my TMPDIR (I don't think it would mess with the sstate though)
<qschulz>
well, I don't know... it just feels wrong but it's just a gut feeling :/
<kanavin>
qschulz, I can't investigate now. it's on you.
<kanavin>
you might put it in distro then, and make it arch-specific
MrCryo has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
ptsneves has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
jmiehe has joined #yocto
<qschulz>
kanavin: yup, thanks!
MrCryo has joined #yocto
rob_w has quit [Remote host closed the connection]
<qschulz>
Considering this change has been in the oe-core tree for one year, the only thing I can complain about is me not looking at it earlier anyway :)
<qschulz>
(i'm not disputing the fact that it's motivated (yet?) BTW)
<qschulz>
i know too little to dispute that fact
<olani>
But it would fall back if OLDDEST_KERNEL was < 5.1 and __ASSUME_TIME64_SYSCALLS was not set.
sakoman has joined #yocto
<qschulz>
yes but this very example contradicts the mail on the buildroot ML
<olani>
The one I linked to, yes.
<qschulz>
ah no, i just cannot read
Saur_Home31 has quit [Quit: Client closed]
<olani>
It's not trivial code :)
Saur_Home31 has joined #yocto
<olani>
I'm not worried about the settings in OE, but about our settings. We have OLDEST_KERNEL = 4.14 because we need it for some platforms.
<qschulz>
olani: I'm worried because I have to support < 5.15 kernels for now :)
<qschulz>
and I kinda want to know what the ramifications are to know where to put this thing and still benefit from as much sstate-cache as we can get :)
<olani>
Yeah, same.
<olani>
Our problem is that we have new platforms that should use OLDEST_KERNEL > 5.15 to get all of the time64 goodness, but they have the same TUNE as some old platforms that do not have that modern kernel versions.
<legraps>
Hi, using devtool, I can develop under .../build/workspace/sources/linux-stable. However, trying to work on a devicetree fails because the modifications are apparently expected in another tree .../build/tmp/work/<machine>-<distro>-linux/linux-stable. How can I convince bitbake/devtool to sync these folders?
<qschulz>
yeah, for me at the moment it's only for two products with the same TUNE so that shouldn't be too bad. The 4.4 kernel though... that's for a platform I can build an upstream kernel for... so maybe I should stop trying to provide this old broken vendor kernel then :)
MrCryo_ has joined #yocto
sakoman has quit [Ping timeout: 268 seconds]
MrCryo_ has quit [Ping timeout: 256 seconds]
MrCryo has joined #yocto
Saur_Home31 has quit [Quit: Client closed]
Saur_Home31 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
sotaoverride has quit [Ping timeout: 272 seconds]
GNUmoon2 has joined #yocto
sotaoverride has joined #yocto
sakoman has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
sakoman has joined #yocto
florian has quit [Quit: Ex-Chat]
sakoman has quit [Ping timeout: 268 seconds]
Xagen has joined #yocto
sakoman has joined #yocto
Abp has quit [Read error: Connection reset by peer]
Abp has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
sakoman has joined #yocto
yudjinn has quit [Ping timeout: 264 seconds]
sakoman has quit [Ping timeout: 255 seconds]
yudjinn has joined #yocto
Abp has quit [Ping timeout: 240 seconds]
Abp has joined #yocto
rfuentess has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
florian has joined #yocto
zpfvo has quit [Quit: Leaving.]
LocutusOfBorg has quit [Read error: Connection reset by peer]
sakoman has joined #yocto
LocutusOfBorg has joined #yocto
<vmeson>
kanavin: khem: ~-6% bloated executable size (nodejs) when using -fvisibility-inlines-hidden
mattsm has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
<RP>
khem: thanks, squashed in!
Abp has quit [Read error: Connection reset by peer]
jmd has joined #yocto
Abp has joined #yocto
jmd has quit [Remote host closed the connection]
snowurm has quit [Ping timeout: 256 seconds]
ptsneves has quit [Ping timeout: 256 seconds]
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
jmd has joined #yocto
jmd has quit [Remote host closed the connection]
florian has quit [Ping timeout: 256 seconds]
jmd has joined #yocto
florian has joined #yocto
amitk_ has quit [Quit: Lost terminal]
amitk has joined #yocto
amitk has quit [Client Quit]
amitk has joined #yocto
jmd has quit [Remote host closed the connection]
amitk has quit [Client Quit]
amitk has joined #yocto
amitk has quit [Client Quit]
amitk has joined #yocto
MrCryo has quit [Remote host closed the connection]
<khem>
qschulz: oldest kernel can be very old and it will still work fine with latest glibc and latest kernel, we have taken the liberty to enforce some policies to ensure OE defaults we have chosen usually. So if you dont care about those e.g. 64bit time_t on 32bit machines etc. then you might want to set it to lowest of kernels you want to support 4.4 in your case
<khem>
for some newer architectures it is different e.g. for RISCV it is 4.15 when kernel ABI became stable and Aarch64 might have older and ofcouse x86 will be oldest so, if you are building for RISCV and chose it to be lower than 4.15 it surely will be a problem
<khem>
I wonder if cmake.bbclass needs some tweaking for WORKDIR
ptsneves has joined #yocto
<khem>
nm, I have accidentally changed workdir to unpackdir in mariadb
Kubu_work has quit [Quit: Leaving.]
amitk has quit [Ping timeout: 260 seconds]
Saur_Home31 has quit [Quit: Client closed]
Saur_Home31 has joined #yocto
<khem>
we use https://github.com/rdfa/librdfa as test for crops and devtool but the code in this repo hasn't been updated in 10 years and it now is failing to compile with GCC14, I am inclined to use some other sample project for this test which is more active perhaps so if you know a good c/c++ project using autotools and does not have many dependencies