<jonmason>
RP: the nesting into directories is much better than before. I was more thinking about the float, crypto, etc and them being enabled/disabled.
brrm has joined #yocto
qschulz has quit [Quit: qschulz]
qschulz has joined #yocto
LocutusOfBorg has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
marc1 has quit [Ping timeout: 245 seconds]
zwelch has joined #yocto
starblue3 has quit [Ping timeout: 240 seconds]
starblue3 has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
marc1 has joined #yocto
mcfrisk has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
mcfrisk has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #yocto
marc1 has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
marc1 has joined #yocto
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
amitk has quit [Ping timeout: 250 seconds]
amitk has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
florian has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
florian has quit [Ping timeout: 246 seconds]
Minvera has quit [Ping timeout: 264 seconds]
alessioigor has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
_whitelogger has joined #yocto
amitk has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
Guest98 has joined #yocto
amitk has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
amitk has joined #yocto
<mckoan>
good morning
<moto-timo>
strange, `devtool latest-version po4a` is reporting current version 0.69 but it is in fact 0.49. Is there some kind of caching that I need to clear? (AUH related)
<Guest98>
morning
<moto-timo>
ah nevermind, I have to clean the local layer of the previous upgraded recipes...
<Guest98>
lets say i have 3 machine conf machine1.conf, machine2.conf, machine3.conf. confs include:
<Guest87>
Hi, taking over a yo to project here and lots recipes have SRC_URI pointing to savannah, that does fail, looking at the URI with a browser, all directories seem empty, not familiar with savannah project, any advice?
<rburton>
Guest87: yes, that directory is empty. so presumably the recipe never actually worked with an empty DL_DIR and it only worked as whoever wrote that already had the tarballs
<Guest87>
as I said am taking over, only been there 2 days lol
xmn has quit [Ping timeout: 245 seconds]
<rburton>
respectfully, sounds like you need to delete some cruft :)
<Guest87>
rburton totally agreed
<Guest87>
I need to change the content of GNU_MIRROR variable but not sure to what
<moto-timo>
I just posted what it is now
<moto-timo>
or was for kirkstone release anyway
<Guest87>
brilliant thamks
<Guest87>
thanks
<moto-timo>
in your head savannah == GNU
<moto-timo>
salsa == Debian
xmn has joined #yocto
amitk has quit [Ping timeout: 246 seconds]
<moto-timo>
alioth == old Debian
<rburton>
Guest87: is that a special-for-your-layer automake recipe?
<moto-timo>
or maybe just wanted/needed a newer/older automake version...
<moto-timo>
question every single locally carried recipe that is also present in oe-core or other layers.
Kubu_work has quit [Quit: Leaving.]
Kubu_work has joined #yocto
amitk has joined #yocto
Guest98 has quit [Quit: Ping timeout (120 seconds)]
dv_ has quit [Ping timeout: 250 seconds]
dv_ has joined #yocto
pabigot has quit [Ping timeout: 245 seconds]
jpanisbl has joined #yocto
Guest98 has joined #yocto
pabigot has joined #yocto
Guest98 has quit [Client Quit]
Guest98 has joined #yocto
beneth has quit [Read error: Connection reset by peer]
beneth has joined #yocto
vladest has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
amitk has quit [Ping timeout: 245 seconds]
vladest has quit [Quit: vladest]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vvn has quit [Ping timeout: 250 seconds]
Guest87 has quit [Quit: Client closed]
vvn has joined #yocto
amitk has joined #yocto
vvn has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 245 seconds]
nemik has joined #yocto
vvn has joined #yocto
<Ablu>
Are there any example of using systemd in a initramfs?
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest98 has quit [Quit: Client closed]
<rburton>
an initramfs is just another image, so make it as usual
<Ablu>
rburton: true. I was mostly hoping for inspiration on how people call `systemctl switch-root` to switch over. That and maybe some systemd-repart examples.
Guest98 has joined #yocto
vladest has quit [Quit: vladest]
<Ablu>
Ah. initrd-switch-root.service is a thing. Did not realize that from the systemd docs...
GillesM has joined #yocto
vladest has joined #yocto
amitk has quit [Read error: Connection reset by peer]
amitk has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<RP>
rburton: thoughts on merging the test release of autoconf?
<RP>
rburton: I think I'm in favour
<rburton>
RP: i can fire a largish build with just that to see if anything changes obviously
<rburton>
i dont like random git snapshots but i don't like autoconf in general ;)
<RP>
rburton: I don't like it either but this does bring us close to any eventual release
<RP>
there is good time_t and largefile stuff in there
<rburton>
yeah
<rburton>
has upstream stalled or are they still working towards release?
<RP>
rburton: stalled I think but they seemed really close
<linex[m]>
I'm also using siemens's Kas, not sure if that's very relevant, building for dunfell
<linex[m]>
the package that is causing me pain is docker-ce
<linex[m]>
is there a way to get all the dependencies of an image ? show-layers recipe does not give the whole picture
<landgraf>
linex[m]: bitbake -g <image_name> ?
<rburton>
linex[m]: if a recipe is being built then it's being pulled in somehow, quite possibly though potential dependencies so it might be built but not installed.
<linex[m]>
I do not believe that should trigger the build though
<rburton>
you're wrong :)
<rburton>
recipe R may produce packages A and B
<rburton>
your image has A in
<rburton>
but if package B depends on C then C also needs to be built as part of building R
<rburton>
otherwise you go to install B and you get missing dependencies
<rburton>
the dependency chains can be long and unexpected but bitbake won't _invent_ dependencies
pidge has joined #yocto
<linex[m]>
yeah I figured my image is depending on another image, now I have to understand why, there's nothing in the image file pointing to that, it might be some kas behaviour I'm not understanding
<rburton>
kas doesn't do anything special
<rburton>
it just clones, writes a local.conf and calls bitbake
florian has joined #yocto
<linex[m]>
it also does checkout and lose your local commits to the abyss :D
<rburton>
you can tell it not to do that :)
<jclsn>
qschulz: There is an automated way to sign the kernel image and enroll the keys in U-Boot somewhere, if I remember correctly. Where is that again?
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<qschulz>
jclsn: automated within Yocto you mean?
lexano has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest98 has quit [Quit: Client closed]
Xagen has joined #yocto
<linex[m]>
yeah I discovered that after the crime :)
<jclsn>
qschulz: Yes, I remember you saying that FIT image verification is implemented in Yocto somehow, when we were talking about it last year
<qschulz>
jclsn: haven't worked for a while with Yocto and I don't remember discussing this sorry :/
<jclsn>
In our old company we did it with HAB in the end and you encouraged me to use the openssl method from your Secure Boot A-Z
<jclsn>
Alright, thanks anyway
<qschulz>
jclsn: mkimage can sign fitimages for you yes?
<qschulz>
and U-Boot can verify your fitimage at runtime too
<jclsn>
Yes, that is what I mean
<qschulz>
and you can have the kernel verify the rootfs without using an initramfs to switch_root but I have never used this one (and it's "new")
<jclsn>
Thanks, will look into it
xmn has joined #yocto
<jclsn>
Another question: Can you list a .patch file in a recipe that patches the same recipe it is listed in? I would assume no
<jclsn>
That is what a .bbappend is for I guess
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
<qschulz>
jclsn: " in a recipe that patches the same recipe" ?
nemik has joined #yocto
sakoman has joined #yocto
<jclsn>
Yeah, I made it clear^2 I guess
<jclsn>
If that were possible, there would be no reason for a .bbappend
<jclsn>
Or well, maybe there still would be
<kergoth_>
Hmm, anyone recall the history behind the TARGET_VENDOR change for multilib configurations, which makes multilib variants of recipes distinct from an equivalent configuration directly for a target? I'd assume this would reduce sstate usage for equivalent configurations. Something to do with the libexec paths in the toolchain multilib builds, perhaps? I know it goes back to the original multilib implementation, specifically the
<kergoth_>
target vendor fix from mark hatle. What differences are there in a lib32-core-image-minimal targeted for a 64 bit platform with the 32-bit multilib enabled and a core-image-minimal for a 32-bit platform with equivalent tuning?
<kergoth_>
That's all git would turn up, checking my mailing list archives next :)
<RP>
kergoth_: From memory I think we wanted different lib prefix settings to have different vendors. You could match one lib prefix to match the specific target config but we've never picked one
<RP>
kergoth_: I suspect for core we made the differ just to make it obvious which was going where
<RP>
s/the/them/
<kergoth_>
Yeah, was suspecting as much myself. Of course the PN is different anyway, so was curious. That goes way back to 2011 in your original work on it :)
<RP>
kergoth_: My thinking was probably that we could resolve that later ;-)
<RP>
kergoth_: sstate reuse wasn't a thing then either
<kergoth_>
Yeah, with current signature handlers and rebuilds of tasks based on checksums, it's probably less critical to isolate those via namespace. Could be interesting to experiment
<RP>
we ended up making the build trees a lot more resistant to different configs than they ever used to be
<kergoth_>
It's tough with any long-lived project, really. Oh yeah, we did XYZ because of ABC that no longer exists :)
<RP>
kergoth_: I'm still not sure we should rely on the build cleanup code but it does a good enough job now, most people do quite heavily :/
<RP>
i.e. our old rules of only allowing machine changes in a TMPDIR and multi-machine support but not multi-distro
<RP>
if we wanted to make that part of the architecture, some proper injection points into the taskgraph would be much nicer
<rburton>
JPEW: the way mingw32-common.inc sets MACHINEOVERRIDES .= ":sdkmingw32" makes me very suspicious, because it means simply selecting the mingw sdk changes *target* overrides.
<rburton>
JPEW: i need to go eat but if you have a moment to unpick that (I tried just deleting and it broke other things) then that would be great
<rburton>
it's actively causing breakage, ie target freetype builds trying to run windres