<jaskij[m]>
RP: not sure if I should ping you or khem @khem:matrix.org: , but (in a Reddit thread) I've been asked for input and use case why I'm on Rust 1.59. I'll do my best to reply, but perhaps one of you two could also reply? GH issue: https://github.com/rust-lang/libs-team/issues/72
jmiehe has joined #yocto
rhowell has quit [Quit: Client closed]
jmiehe has quit [Client Quit]
<jaskij[m]>
Gnome depends on it's Rust SVG implementation, right?
vmeson has joined #yocto
qschulz has quit [Read error: Connection reset by peer]
qschulz has joined #yocto
seninha has joined #yocto
sakoman has quit [Quit: Leaving.]
Habbie has quit [Ping timeout: 244 seconds]
Habbie has joined #yocto
vmeson has quit [Ping timeout: 264 seconds]
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 265 seconds]
behanw has joined #yocto
seninha has quit [Quit: Leaving]
seninha has joined #yocto
seninha has quit [Client Quit]
seninha has joined #yocto
Tokamak_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sakoman has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep has joined #yocto
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
seninha has quit [Quit: Leaving]
<PhoenixMage>
what is the location of the initramfs on the host disk after bitbaking an image?
seninha has joined #yocto
seninha has quit [Quit: Leaving]
seninha has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
seninha has quit [Client Quit]
barometz has quit [Remote host closed the connection]
barometz has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
seninha has joined #yocto
amitk has joined #yocto
seninha has quit [Remote host closed the connection]
sakoman has quit [Quit: Leaving.]
thomasd13 has joined #yocto
esai[m] has left #yocto [#yocto]
alessioigor has joined #yocto
beneth has quit [Read error: Connection reset by peer]
<thomasd13>
I have a question regrading providing an (e)SDK for the application developer: Assume the app-developer wants to build an app, which requires the linux-kernel-headers and also some custom library A. So the linux-kernel-headers are included in (e)SDK. But can I also package the custom library A also in (s)SDK?
<thomasd13>
Or is the "normal" workflow like this: app-dev will install e(SDK) on his machine to have the correct toolchains/common linux libs/kernel, and will install himself all other required 3th party libs?
behanw has quit [Quit: Connection closed for inactivity]
thomasd13 has quit [Ping timeout: 265 seconds]
rob_w has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
thomasd13 has joined #yocto
ptsneves has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Schlumpf has joined #yocto
smudge-the-cat has joined #yocto
smudge-the-cat has left #yocto [#yocto]
<RP>
jaskij[m]: Worryingly, kirkstone is only 6 months old and we're hitting this :(
astlep5504 has joined #yocto
astlep550 has quit [Ping timeout: 252 seconds]
<RP>
thomasd13: if you have a recipe for it, yes and you can either ship the binaries in sstate and lock it down, or have it build it on demand
mckoan|away is now known as mckoan
<mckoan>
good morning
<thomasd13>
RP, I have no recipe for "custom library A" yet. If I would have, how can I ship that?
tre has joined #yocto
rfuentess has joined #yocto
zpfvo has joined #yocto
<thomasd13>
Do you mean to do it "manually", so search for the built binary in sstate and provide it by hand?
<LetoThe2nd>
yo dudX
zpfvo has quit [Quit: Leaving.]
zpfvo has joined #yocto
<thomasd13>
Another question: package-X requires CMake 3.24 to build. All other packages should use the "normal" CMake version. What is the best way to handle this?
pbergin has joined #yocto
<LetoThe2nd>
thomasd13: no good solution, bitbake is not meant to handle multiple versions of a package in a single build.
<thomasd13>
LetoThe2nd, I was thinking to explicit create a package with the name cmake-3-24, to have the "normal" version via "cmake" and new version via "cmake-3-24" by hand. Is that somehow possible?
<LetoThe2nd>
thomasd13: maybe rather "cmake-my-patched-version", and yes, that is one way to get around it.
<RP>
thomasd13: you could write a recipe which packages up the binaries if you're sure they're compatible, you will need a recipe either source or binary based
<RP>
thomasd13: what you describe with a version in PN can work but it can sometimes be a bit tricky to have work correctly
<LetoThe2nd>
RP: if it wasn't tricky, then it would be a good way (TM)
<thomasd13>
Thank you both guys! Assume i have a cmake-my-patched-version package. How can I tell yocto, that this cmake should be used for package-A ?
<RP>
LetoThe2nd: recipe specific sysroots made it possible, you just have to ensure there isn't another dependency on the other version somewhere back down the dependency chain
<LetoThe2nd>
RP: possible != simple :-)
<RP>
thomasd13: DEPENDS += "somerecipe-myversion" assuming you changed PN to that
<LetoThe2nd>
thomasd13: first stab would be inheriting cmake and then modifying the result.
<thomasd13>
perfect, thanks guys!
<RP>
LetoThe2nd: I just mention it is possible and can work, not that it is a good idea
<LetoThe2nd>
RP: hi5
manuel1985 has joined #yocto
<qschulz>
RP: got NVD to say they limited the CVE to jpeg-turbo 2.0.5 :) \o/
* qschulz
hi5 RP
LetoThe2nd has quit [Quit: WeeChat 3.5]
manuel1985 has quit [Ping timeout: 265 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
mihai has quit [Quit: Leaving]
prabhakarlad has joined #yocto
zpfvo has joined #yocto
manuel1985 has joined #yocto
smudge-the-cat has joined #yocto
smudge-the-cat has left #yocto [#yocto]
manuel1985 has quit [Read error: Connection reset by peer]
manuel1985 has joined #yocto
<RP>
qschulz: they tried to tell me something different but I convinced them otherwise
<qschulz>
RP: ah, well.. good job I guess then :D
<qschulz>
RP: got a very unclear message from Mitre for adding a link with the patch fixing a CVE for U-Boot, but tha'ts another story
manuel__ has joined #yocto
<RP>
qschulz: if it doesn't look right tell them and they generally get there in the end
zpfvo has quit [Ping timeout: 264 seconds]
<RP>
qschulz: I forwarded you the discussion I had with them
zpfvo has joined #yocto
manuel1985 has quit [Ping timeout: 244 seconds]
zpfvo has quit [Ping timeout: 250 seconds]
davidinux has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
<RP>
Looks like we're down to two CVEs for master without a plan
<qschulz>
RP: when did you forward the mail? haven't received anything on personal or pro mail I think
<RP>
qschulz: 10pm yesterday
<qschulz>
too many mails on personal inbox, should configure the mailing lists better to only receive what i want :)
<qschulz>
I see it now, thx
davidinux has joined #yocto
xmn has quit [Ping timeout: 265 seconds]
xmn has joined #yocto
leon-anavi has joined #yocto
lexano has quit [Ping timeout: 265 seconds]
nemik has quit [Ping timeout: 268 seconds]
beneth has joined #yocto
d-s-e has joined #yocto
lexano has joined #yocto
nemik has joined #yocto
zpfvo has quit [Ping timeout: 268 seconds]
florian has joined #yocto
Tyaku has joined #yocto
tnovotny has joined #yocto
abelloni_ is now known as abelloni
<Tyaku>
Hi, yesterday I speak about a problem that has been resolved, but during this we speak about bitbake-getvars. And today I need to access a bitbake variable from commandline. this is the "MACHINE" variable. Problem: I never found bitbake-getvars and google didn't help me.
<Tyaku>
Is there any way to get the content of a bitbake variable from command line ?
<qschulz>
Tyaku: bitbake-getvar is pretty new
<qschulz>
I think it was backported recently to dunfell
<qschulz>
in any case, you can use bitbake -e recipe | awk '/^# \$FOOBAR \[/,/^FOOBAR/' instead
<Tyaku>
qschulz: Is this the unique way ? Which recipe I have to put to make it working ? Any one ? (MACHINE is supposed to be defined in local.conf and possibly somewhere with ??=)
<qschulz>
Tyaku: any will do since MACHINE is set in a conf file and won't change
<RP>
LetoThe2nd: that is parsing cache. sstate is pretty much in oe-core
<RP>
LetoThe2nd: meta/lib/oe/sstatesig.py and sstate.bbclass
<RP>
LetoThe2nd: bitbake side they hook into siggen.py and runqueue has the execution logic
<RP>
LetoThe2nd: how worried should I be? :)
<LetoThe2nd>
RP: not at all, guess just one of my devs going astray. and I'm not going to stop anybody who wants to learn more about the internals :-)
Schlumpf has quit [Ping timeout: 252 seconds]
<RP>
LetoThe2nd: was just curious on the context, I wouldn't stop anyone like that either :)
<LetoThe2nd>
RP: the trigger is the usual "why are we rebuilding so much", but I'm pretty certain that digging in that code is not the solution. yet it should be educational, hence i support it.
<RP>
LetoThe2nd: comparing sstate sigs is usually the answer to that
<RP>
LetoThe2nd: bitbake-diffisgs
<LetoThe2nd>
yep i know, but he seems to be missing something. my reproducer is not ready yet.
<PhoenixMage>
hmmm, had to increase the size of my initramfs and now when I attempt to boot I get "kworker/u8:0 invoked oom-killer" the VM I am using has 32Gb RAM allocated and 29 Gb free... I cant seem to find a switch to increase the qemu vm mem size on run? Any hints?
<LetoThe2nd>
ah we've got a split in -global and -recipe classes? didn't notice, can anybody give me an executive summary? ;-)
<RP>
LetoThe2nd: very recent and not documented yet
<LetoThe2nd>
perfect summary!
Schlumpf has joined #yocto
<qschulz>
LetoThe2nd: split for classes that should be INHERIT vs classes that should be inherit :)
<qschulz>
(INHERIT for all recipes to inherit the class, inherit for per recipe)
<RP>
LetoThe2nd: basically it enforces anything that are in the recipes/global directories
<qschulz>
(and meta/classes for classes that can be inherited both ways IIRC)
<LetoThe2nd>
k
<RP>
ideally we'll make things one or the other
manuel__ has quit [Ping timeout: 244 seconds]
Tyaku has quit [Quit: Lost terminal]
wkawka has joined #yocto
ptsneves has quit [Quit: ptsneves]
manuel1985 has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
odra_ is now known as odra
mckoan is now known as mckoan|away
EilsNFhlannagin[ has joined #yocto
EilsNFhlannagin[ is now known as pidge[m]
zpfvo has joined #yocto
seninha has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
Guest9 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<jaskij[m]>
RP: oh? I haven't hit it yet, and feel like I don't know enough to properly explain it in that issue. Or should I move this discussion to the mailing list?
<RP>
jaskij[m]: well, we're seeing rust move forward and "obsolete" versions but that isn't really a surprise. We can mention what we're doing on that issue but we'll just be told not to do that :/
<jaskij[m]>
For... Reasons, despite a few years of working experience with Yocto I have not yet had any system put in production.
<RP>
jaskij[m]: I don't know what we should do as the stable branches aren't meant to have large version changes
<jaskij[m]>
I skimmed that discussion and people there seem more open minded than usual.
<jaskij[m]>
And yeah, I get you, 1.59 has an ICE error I seem to hit fairly often and the fix wasn't backported
odra is now known as odra_
odra_ is now known as odra
<jaskij[m]>
RP: The maintainer of RHEL and Fedora Rust packages also participated and the replies were relatively open-minded. Worst case Yocto will get similar treatment to whatever they end up on deciding for Debian.
<jaskij[m]>
But if you feel it useless, I'll just chip in with my own experience and leave it at that.
<RP>
jaskij[m]: I've commented with our position, factually
<RP>
jaskij[m]: I can't really do more. I'm not a rust person really :/
<jaskij[m]>
And I'm someone who merely writes some small services in Rust, don't really participate
dtometzki has quit [Ping timeout: 252 seconds]
<jaskij[m]>
Is Khem still working on Rust in OE? Iirc he did quite a lot of the initial support.
<RP>
jaskij[m]: sometimes. vmeson too
<jaskij[m]>
Feel like I'll need to add some more context - I'm willing to bet that none of the Rust folks in the issue even heard of Yocto
<jaskij[m]>
RP: I'll ping Khem via GitHub then
<jaskij[m]>
But thanks for participating, hopefully they will take OE into account
ptsneves has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<rfuentess>
I'm trying to understand BBCLASSEXTEND. If by example, I want to add an extra feature (e.g. the dbg recipe) to an image. Can I use this variable from a custom config file (or an environment var) to do it?
<rfuentess>
I'm reading it documentation and trying to find examples. But as far I see it only for the pre-existent "native" class
<qschulz>
rfuentess: maybe you're looking for IMAGE_FEATURES rather?
seninha has quit [Ping timeout: 252 seconds]
<qschulz>
and depending on which features are in it, you'd add or not a package to your image?
<rfuentess>
yeah, EXTRA_IMAGE_FEATURES could be ?
<rfuentess>
the idea that we have is to try to determine a "baking" time (bitbake <image>) if we want GDB or not in the final image
<qschulz>
rfuentess: be careful, because using this for a "debug" image only goes so far
<qschulz>
what we usually recommend is to have a debug distro based on your normal distro
<qschulz>
this drastically increases build time but it is much cleaner and allows for much more customization than trying to do everything in an image
pgowda_ has joined #yocto
alessioigor has quit [Quit: alessioigor]
<rfuentess>
ok, I'm still trying to learn yocto itself. But, "debug distro based on your normal distro" means, to have an extra layer that is identical to our distro but with the extra debugging features?
<qschulz>
an extra distro configuration file
otavio has joined #yocto
<jaskij[m]>
<rfuentess> "the idea that we have is to..." <- There's an existing `debug-tweaks` feature. It doesn't add -dbg packages, but disables root password, and adds GDB and some other stuff
<rfuentess>
ohhh
<rfuentess>
uh, `poky/meta/recipes-sato/images/core-image-sato-sdk.bb` this example looks interesting with the IMAGE_FEATURES selection
<jaskij[m]>
rfuentess: what I'm doing is maintain two images, with exact same content, but one has those tweaks and some other development utilities. To make it work in a sane way, you need to set up package groups so you don't end up with different base content.
<jaskij[m]>
Used to do it with classes inherited by the images, but package groups are saner
<rfuentess>
jaskij[m]: basically you have distro.conf and distro_debug.conf where the distro.conf set the packages groups and the latest just add new ones ?
<jaskij[m]>
No, I do it all in the images
<jaskij[m]>
Didn't set up a separate distro
<qschulz>
rfuentess: you only need a distro once you start saying "I want this package to have a different file or compile option if it's in the debug image"
<qschulz>
because recipe data is local, and images are recipes, so you cannot modify a package recipe from your image recipe
<rfuentess>
Ok, I'm starting to understand this better
ptsneves has quit [Quit: ptsneves]
<rfuentess>
Time to read my notes and going further to try to understand properly all your recommendations. Thanks!
<Guest9>
qschulz: Do you think this can be used to have a normal kernel config file and a debug one? for now I have two different MACHINE which is not good
<qschulz>
Guest9: two machines or two distros, up to you
<qschulz>
(two distros is cleaner)
<Guest9>
qschulz: oki many thanks I preffered it with distros too.
<vvn>
is there a "yocto" way to compile virtual/kernel with allmodconfig? So that I can have a minimal kernel and host / install necessary modules afterwards?
seninha has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
<qschulz>
vvn: KERNEL_CONFIG_COMMAND
Guest9 has quit [Ping timeout: 252 seconds]
zpfvo has quit [Ping timeout: 252 seconds]
prabhakarlad has quit [Ping timeout: 252 seconds]
vladest has quit [Quit: vladest]
kevinrowland has quit [Quit: Client closed]
<dwagenk>
qschulz: I recently watched the talk recording of your and your colleagues presentation "Secure Boot from A to Z" where you talk about a dependency loop in yocto with kernel-fitimage and dm-verity. You mention an adapted kernel-fitimage class that works around this issue. Is that class open source and published somewhere?
<dwagenk>
I'm currently in a similar situation with signed UnifiedKernelImages (for UEFI boot on x86-64) and looking for inspiration...
xmn has joined #yocto
rob_w has quit [Quit: Leaving]
vladest has joined #yocto
<qschulz>
dwagenk: unfortunately no and I don't have access to this class anymore
prabhakarlad has joined #yocto
<qschulz>
there's a new way of passing the root hash to the kernel via kcli parameters IIRC
<dwagenk>
qschulz: thanks. I've got a vague idea of how I'll approach it and hope no big issues come up with that
<dwagenk>
well, it's on bare metal and the goal is to have the UnifiedKernelImage directly started by the uefi firmware, to eliminate additional components (bootloaders) in the secure boot chain. I guess kcli is not the correct tool in this scenario.
<qschulz>
dwagenk: you need to verify the rootfs signature
<dwagenk>
The hashed rootfs and all combinations of kernel+initrd+cmdline are known in advance, so it should be achievable.
zpfvo has joined #yocto
Schlumpf has quit [Quit: Client closed]
sakoman has joined #yocto
<dwagenk>
well, if it is part of the cmdline that is part of the signed UnifiedKernelImage
Schlumpf has joined #yocto
ptsneves has joined #yocto
prabhakarlad has quit [Quit: Client closed]
vmeson has joined #yocto
wkawka has quit [Quit: Client closed]
pbergin has quit [Quit: Leaving]
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
<rburton>
triggered by 3670f3685e63345df0501f26acad2044e3544d7b?
<rfuentess>
qschulz: IMAGE_INSTALL is used for the packages that must always goes with a package. Whereas IMAGE_FEATURE may be packages installed by some bbclasses or config files ? And finally, EXTRA_IMAGE_FEATURE when I want to add non-expected features from my local.conf file ?
manuel1985 has quit [Ping timeout: 244 seconds]
<qschulz>
rfuentess: IMAGE_INSTALL is a list of packages to install in an image, to be set in an image recipe
<qschulz>
IMAGE_FEATURE is for controlling the behavior of an image (doing something specific after all packages are installed in the image, installing multiple related packages, disabling root password, etc...)
<RP>
rburton: maybe, I don't know. That shouldn't have changed much should it?
<rburton>
maaaaybe
<RP>
rburton: I suspect it is just a genuine race :/
<rburton>
can't see anything else jumping out though
<rburton>
yeah could be
<RP>
rburton: I was wondering about trying to claim it was arm specific
<rburton>
i doubt it is ;)
<RP>
rburton: can you prove it though? :)
<rfuentess>
qschulz: thanks. I'm reading right now the https://docs.yoctoproject.org/ref-manual/images.html and also that one. But was trying to understand why In the former the IMAGE_FEATURE is also offered as a complement to IMAGE_INSTALL
<rfuentess>
qschulz: OH! core-image-minimal-dev and core-image-minimal just made me to understand better what you and qschulz were speaking before
PhoenixMage has quit [Ping timeout: 265 seconds]
PhoenixMage has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
denisoft81 has joined #yocto
kevinrowland has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
<kevinrowland>
Hi all. I'm trying to understand how bitbake knows to re-fetch a local file (those with file:// URIs) when the file has changed. I think I've got a handle on it (siggen.prep_taskhash() calls fetch2.get_file_checksums() and then siggen.get_taskhash() adds those file checksums to the taskhash). While experimenting, I noticed that if I start with a
<kevinrowland>
file [lets say it's in state A] and build, then modify that file [now let's say it's in state B] and re-build, then the file is re-fetched and the configure/compile/deploy/etc tasks are all re-run. Then if I _remove the modification_ [to return to state A] and re-build again, bitbake will re-compute the file checksum, land at the same taskhash as
<kevinrowland>
the first build, and pull from sstate cache rather than re-running all of the tasks. That's super cool, and it means bitbake can clearly hold on to multiple cache entries for one task. My question is: is there any upper limit to the number of cache entries that bitbake will maintain for a given task? Or will the cache grow unbounded if I continue
<kevinrowland>
to modify this local file?
seninha has quit [Ping timeout: 264 seconds]
seninha has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
<kergoth>
kevinrowland: sstate cache management is up to you, bitbake never removes anything from the sstate cache dir.
<kergoth>
some folks will use access time to periodically remove sstate artifacts that haven't been used by any builds in a certain amount of time
florian_kc has quit [Ping timeout: 250 seconds]
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
<kevinrowland>
kergoth: thanks for the response
kscherer has quit [Ping timeout: 264 seconds]
kscherer has joined #yocto
kscherer_ has joined #yocto
kscherer has quit [Ping timeout: 252 seconds]
Tokamak has quit [Read error: Connection reset by peer]
amitk has quit [Ping timeout: 265 seconds]
florian_kc has joined #yocto
manuel1985 has joined #yocto
Tokamak has joined #yocto
goliath has quit [Quit: SIGSEGV]
kscherer_ has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
odra has quit [Ping timeout: 268 seconds]
seninha has quit [Quit: Leaving]
manuel1985 has quit [Ping timeout: 250 seconds]
pgowda_ has quit [Quit: Connection closed for inactivity]