ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
AkkermT_ has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
foxxesStar has quit [Ping timeout: 276 seconds]
sakoman has quit [Quit: Leaving.]
goliath has quit [Quit: SIGSEGV]
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #yocto
fenrig has quit [Quit: Client closed]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
paulg has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
foxxesStar has joined #yocto
paulg has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
amitk has joined #yocto
alimon has left #yocto [#yocto]
camus has quit [Quit: camus]
camus has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
mckoan|away is now known as mckoan
<mckoan> good morning
<LetoThe2nd> yo dudX
<LetoThe2nd> dmoseley: shoragan might be helpful here!
leon-anavi has joined #yocto
wkawka has joined #yocto
ptsneves has joined #yocto
<shoragan[m]> dmoseley: this channel is already bridged to #yoctoproject:matrix.org
<shoragan[m]> dmoseley: same with #oe:matrix.org and #oe on libera.chat
<shoragan> dmoseley, a main benefit is that matrix has proper multi-client support with configurable push notifications for mobile
Patrick2 has joined #yocto
Schlumpf has joined #yocto
perdmann has joined #yocto
<perdmann> Hi, maybe this is a strange question. I know there are multiple ways to modify the "standard" devicetrees and kernel configs... I use an old Raspberrypi for this and I found this: https://wiki.koansoftware.com/index.php/Modify_the_linux_kernel_with_configuration_fragments_in_Yocto It looks good to me. (No copying, just add additional information) Is there something similiar for Devicetrees?
<mckoan> perdmann: glad to see you liked my wiki ;-)
<mckoan> perdmann: for devicetree you have to create a parch, no fragments
<mckoan> s/parch/patch
<perdmann> So, rpi is heavily using DT overlays, but how do I add an additional overlay? I tried with creating a seperate machine and "require" the raspberrypi machine. But it turns out that i would need to additionally add things (devicetree, kernelconfig, uboot config) which are already set in the rpi machine
<perdmann> mckoan: Yes, its good. Do you also have a site for that? :)
<LetoThe2nd> perdmann: the layer is really ugly (thanks Seeed!), but maybe you can find inspiration at https://github.com/TheYoctoJester/meta-seeed-cm4/blob/kirkstone/recipes-kernel/seeed-linux-dtoverlays/seeed-linux-dtoverlays.bb
<perdmann> Thank you both.
<LetoThe2nd> have fun!
<mckoan> \o/
<perdmann> Ill let you know when its booting :)
Patrick2 has quit [Quit: Connection closed]
goliath has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
<qschulz> o/
florian has joined #yocto
<qschulz> janvermaete[m]: wondering how you came to this conclusion while not using the recipe :)?
<qschulz> janvermaete[m]: at the very least, compiling the native and target version of the recipe would be good
<qschulz> sending a patch to the appropriate ML (oe-core it seems)
<qschulz> would be cool once that's done
GNUmoon has quit [Remote host closed the connection]
mvlad has joined #yocto
GNUmoon has joined #yocto
adams[1] has quit [Quit: Client closed]
Guest99 has joined #yocto
<ptsneves> a bit out of topic. Has anybody ever used on of these https://en.wikipedia.org/wiki/NodeMCU for their labs?
<Guest99> Why can't I put "IMAGE_INSTALL:append" inside a  bitbake recipe file but I have to put it inside a configuration file?
<mckoan> Guest99: because is a IMAGE append
<ptsneves> Guest99: You can and should definitely add it to a recipe. What is the issue you have?
<mckoan> Guest99: actually you can add it into an image recipe
<Guest99> If I make a new custom recipe and I put it inside the .bb of that recipe the image that will be built won't contain that package. As soon as I put it inside the configuration file it will be in the image.
<ptsneves> Guest99: as @mckoan mentions you need to add it to an image recipe, not just any recipe
<jclsn[m]> Is there a way to see a real-time compile log for a recipes?
<ptsneves> jclsn[m]: dont think so, but if you are feeling adventurous fireup the devshell and run the temp/run.do_compile manually
<Guest99> A recipe file is a .bb file, then you are saying it shouldn't matter if it is inside a .bb file or a configuration file, as long as it is related to configuring the final image file?
<Guest99> trying to learn the ropes here so sorry about asking these kind of questions
<jclsn[m]> ptneves: I have never used the devshell. Will have a look. Thanks
<ptsneves> Guest99: No problem. Metadata defined in a recipe is specific to that recipe and nothing else. When you add some kind of metadata info to a conf file it is possibly taken globally and is available on all recipes as well. Your situation with the conf looks like your image recipe is catching the global conf you set up and it works as you wish. Find the image recipe and add the IMAGE_INSTALL:append there and you shall not need to make
<ptsneves> the changes in the at a configuration level
<Guest99> Thank you ptsneves and mckoan, I understand now.
<jclsn[m]> ptneves: I have tried settings up the devshell with ``bitbake -c devshell image_name``, but bitbake then tries to build the package again
<jclsn[m]> The U-Boot compilation is taking more than 10 mintues. Something is fishy
<jclsn[m]> Ah I had to use the package name, not the image name
<qschulz> jclsn[m]: yeah 10min ain't right for U-Boot
<ptsneves> jclsn[m]: Previosuly you mentioned compilation but now you mention an image_name. Confused :)
<ptsneves> you should run devshell with the recipe you want to inspect, one with a compile task in your case
<jclsn[m]> ptsneves: I just assumed the image name was meant by "target"
<ptsneves> nope. Were you successful?
<jclsn[m]> I have the devshell now and I guess I have to update my defconfig. U-Boot expects and ENV_OFFSET now, which was prompted for after running make
<jclsn[m]> Not yet, but I am getting there
<jclsn[m]> Hopefully
<ptsneves> jclsn[m]: my suggestion is to do bitbake <recipe> -c compile, ctrl-c after a bit, bitbake <recipe> -c devshell, ./temp/run.do_compile
<ptsneves> you should not need to do any manual changes
<ptsneves> it is hacky but it is a quick and dirty way to get the scripts generated
florian_kc has joined #yocto
<jclsn[m]> ptsneves: Thanks, will try that after the break
<jclsn[m]> But I would have assumed that everything is set up by launching the devshell as well
<jclsn[m]> I just ran make defconfig and then make as usual
<ptsneves> no
<ptsneves> you should not do that unless you know what you are doing or have an extremely simple recipe
<ptsneves> the devshell sets up an environment similar to the one the run.do_* will run but that is it
<ptsneves> at the top of my head i do not recall what tasks it depends on but i would be surprised it depends on do_configure
<ptsneves> actually you may have modified your workspace in a way it will not help you. I suggest running bitbake <recipe> -c clean and then do exactly the steps i wrote above
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<wkawka> Hi, can I somehow have different fstab files in base-files? I have second image and it will need another fstab
<wkawka> But i can't change fstab because it will corrupt my first image
<qschulz> wkawka: you need a different distro configuration
<qschulz> (I mean, two distro configruation files)
Guest99 has quit [Ping timeout: 252 seconds]
<wkawka> Or maybe I can modify fstab file to satisfy them both
<qschulz> that's also one way indeed
<qschulz> maybe there's a better way than modifying base-files's fstab
<qschulz> but am not aware of any (I haven't played with fstab)
<wkawka> The problem is /boot partition, on the first image it is called boot, on the second iboot and i think i cant change this name (maybe it will be overwritten by wic I have to check it)
starblue1 has quit [Ping timeout: 240 seconds]
perdmann has quit [Ping timeout: 240 seconds]
starblue1 has joined #yocto
perdmann has joined #yocto
grma has quit [Ping timeout: 272 seconds]
<ptsneves> @wkaka if you use systemd you can use .mount files which allow for more powerful configurability at runtime
<ptsneves> @wkawka
perdmann has quit [Ping timeout: 244 seconds]
perdmann has joined #yocto
<rburton> hm, oe-core master appears to have broken meta-zephyr
Guest99 has joined #yocto
grma has joined #yocto
<jclsn[m]> Is there a way to add a recipe to your workspace again after removing it with ``devtool reset``
<jclsn[m]> ?
<jclsn[m]> I still have the folder in my workspace and want to use it again instead of checking it out again
<qschulz> jclsn[m]: devtool modify -n IIRC?
<qschulz> (or -x?)
<jclsn[m]> qschulz: Ah yes, thanks
<jclsn[m]> Should have done entered a -h after the modify command
perdmann has quit [Ping timeout: 272 seconds]
<jclsn[m]> ptneves: Ah after cleaning it also fails properly, so no need I guess
<jclsn[m]> CONFIG_SPL_FIT_GENERATOR seems deprecated plus I need to add CONFIG_DMI_SPI_FLASH also it already is
perdmann has joined #yocto
<ptsneves> qschulz: cheers. Did not know of the -n option. Again the discoverability issues in Yocto. We should have a tip of the day enabled by default every time one runs bitbake
phako[m] has joined #yocto
phako has joined #yocto
manuel1985 has joined #yocto
<phako> hi
<phako> Im trying to get boost-numpy into a recepie, but er - I am failing to understand how to do that, of if that's even possible
<phako> *as a dependency
<rburton> phako: not sure what you're actually trying to do
<phako> hey ross :)
GNUmoon has quit [Remote host closed the connection]
<rburton> hi phako :)
<rburton> the boost recipe builds the python support by default
GNUmoon has joined #yocto
<phako> yes. I do have boost-python in the sysroot - but the cmake fails to find boost::numpy
<phako> boost-python is found
<jclsn[m]> <ptsneves> "qschulz: cheers. Did not know of..." <- Yeah also maybe show this when ``devtool modify <target>`` fails because the workspace already exists
<phako> I meant
<rburton> phako: boost doesn't depend on numpy so maybe thats disabled at configure time?
<phako> blergh
<phako> how would I convince boost to come with numpy?
<rburton> boost's build system is 100% blergh
<phako> agree
LocutusOfBorg has quit [Quit: ZNC 1.8.2+deb1 - https://znc.in]
LocutusOfBorg has joined #yocto
denisoft81 has joined #yocto
<rburton> find_package(Python REQUIRED COMPONENTS Development OPTIONAL_COMPONENTS NumPy)
<phako> I found a mail thread where this seems to happen by accident
<rburton> I'd add a PACKAGECONFIG to the boost recipe for numpy which depends on python3-numpy, and enable it in your configuration
<rburton> don't make that a default as boost is horrible enough to build at the best of times
<phako> somewhere around the PACKAGECONFIG[] stuff in the bb?
<rburton> yeah
<rburton> PACKAGECONFIG = "..." defines what options are enabled by default
<rburton> so you want a new PACKAGECONFIG[numpy]
<phako> how do I make local overrides again? I"m off BB for 4 years now :/
<rburton> well, start by just changing the PACKAGECONFIG = ... to get it working
<phako> ah :D
Guest99 has quit [Quit: Client closed]
<phako> Sorry I am proying currently
<phako> *proxy
<phako> blergh. how do you enable that then in your recipe? I have forgotten everything apparently :(
<rburton> :)
<rburton> blindly guessing: PACKAGECONFIG[numpy] = ",,python3-numpy" (as there's no on/off toggle, just add the build dependency)
<rburton> then for now, PACKAGECONFIG ??= "locale python numpy"
<phako> yep that was the clear part
<phako> weirdly
<rburton> in an ideal world, your distro would set PACKAGECONFIG:append:pn-boost = " numpy" to enable numpy on top of whatever the defaults are
<phako> thanks. we will kick that off and see what happens
<qschulz> jclsn[m]: patches welcome :)
<wkawka> what is pre-expansion-value and where can it be set?
perdmann has quit [Ping timeout: 268 seconds]
perdmann has joined #yocto
<jclsn[m]> <qschulz> "jclsn: patches welcome :)" <- Repo?
<qschulz> jclsn[m]: https://cgit.openembedded.org/openembedded-core/tree/scripts/devtool seems to be part of oe-core
<wkawka> is there an option to force wic to overwrite (not append) fstab file?
fenrig has joined #yocto
manuel1985 has quit [Ping timeout: 276 seconds]
<RP> ptsneves: I merged the fetcher changes FWIW, DL_DIR is removed :)
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
GNUmoon has joined #yocto
<jclsn[m]> qschulz: I can't even find the relevant error message in the Python scripts
<jclsn[m]> output path /home/userWorkspace/Yocto/my-machine/build/workspace/sources/u-boot-imx already exists and is non-empty
<jclsn[m]> Tried ag on all meta layers already...
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<jclsn[m]> Ah well
<jclsn[m]> The motivation is fading
<jclsn[m]> Haven't had a beer in a few days hmm
<jclsn[m]> Things LetoThe2nd would never say :D
<jclsn[m]> Yocto Yoga what? :D
mrpelotazo has quit [Quit: Hasta la vista!]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
mrpelotazo has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<ptsneves> RP: Yay great news :) Thanks for the effort and follow up
<RP> ptsneves: it would make it much less readable
<qschulz> RP: Path(core_layer).parent / "scripts" should work IIRC (I like pathlib :) )
<RP> qschulz: that looks horrible though
<ptsneves> @RP congrats on having a project that is working so well that we can finally argue about nitpick stuff
<qschulz> RP: /me gasps
Schlumpf has quit [Quit: Client closed]
florian has quit [Ping timeout: 276 seconds]
florian has joined #yocto
<janvermaete[m]> Hi, I try to update the python3-jsonrpcserver recipe. It's now depends on the python oslash package.
<janvermaete[m]> what's not that active :-) But used in the latest version of jsonrpcserver.
<janvermaete[m]> Should this that be a new recipe in meta-python?
camus has quit [Quit: camus]
florian has quit [Ping timeout: 272 seconds]
fenrig has quit [Ping timeout: 252 seconds]
florian_kc has quit [Ping timeout: 260 seconds]
phako has quit [Quit: leaving]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
<qschulz> and there's no mention of oslash anywhere
<qschulz> but at the same time oslash is listed in setup.py of the project, so I am surrpised it compiles (does it?)
<janvermaete[m]> well, it does compile here. But when loading the application with jsonrpcserver it's compaining.
<janvermaete[m]> but oslash seems to be not yet part of yocto/oe
<janvermaete[m]> but I'm not sure it's (except for one recipe) needed.
<janvermaete[m]> last commits at oslash is from 2020.
<JPEW> rsalveti, RP: Sent the V2 of that signature patch
sakoman has joined #yocto
<qschulz> janvermaete[m]: understood. if jsonrpcserver does not work without it, then you need to add it to meta-python
<qschulz> and add it to RDEPENDS of jsonrpcserver package
<qschulz> or, we remove jsonrpcserver from meta-python because it does not work and nobody has complained in the few months it's been updated (it's part of kirkstone already)
<janvermaete[m]> @qschulz I'll do my best to add it and test it.
<RP> JPEW: cool, thanks
<janvermaete[m]> Jsonrpcserver will remove in the 6.x release the oslash dependency.
<janvermaete[m]> So, no big issue. Once it's at 6.x, we can remove the python3-oslash again.
<qschulz> janvermaete[m]: well.. yes but 1) no guarantee there'll be a 6.x any time soon 2) kirkstone is an LTS, so for its life-time we'll carry this recipe
florian has joined #yocto
<qschulz> (don't forget to send the patch against master first but once merged to notify sakoman he shoudl take them in oe-core because IMO this should be backported
<janvermaete[m]> Anyhow, it's not my call. But if it's removed from meta-python. Could it be moved somewhere else? After all, it's a nice and useful python package.
<qschulz> janvermaete[m]: if we remove it from meta-python because it does not work, it's not to have it maintained by us somewhere else I'm afraid
<qschulz> janvermaete[m]: I've looked into the patch and it's not a simple one, so *I* would not backport it if I were the maintainer of meta-python
<qschulz> but I don't have any authority on what goes in or not
<rburton> qschulz: RP is just wrong, pathlib is great
<janvermaete[m]> qschulz: ok, got it. I'll expect to have a patch in master of the python3-jsonrpcserver + a new python3-oslash recipe.
<qschulz> janvermaete[m]: that's what makes the most sense to me yes
<qschulz> but it can go ugly very fast, I also don't know the dependencies of python3-oslash
<janvermaete[m]> qschulz: will see. Soon weekend here...
<qschulz> janvermaete[m]: have fun :)
<rsalveti> JPEW: great, thanks!
seninha has joined #yocto
<rburton> kanavin_: what's the use-case for a site.conf which gets copied from a layer to the build directory? As its meant to be site-wide why can't the file stay in the layer? Things the user can customise should go into local.conf.sample, surely
AkkermT_ has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
xmn has joined #yocto
perdmann has quit [Ping timeout: 276 seconds]
perdmann has joined #yocto
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
ptsneves has quit [Ping timeout: 255 seconds]
kscherer has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
wkawka has quit [Quit: Client closed]
<kanavin_> rburton, I thought I made the case in the commit message?
perdmann has quit [Ping timeout: 272 seconds]
perdmann has joined #yocto
<kanavin_> rburton, ah, you mean meta-layer/conf/site.conf will work just as well?
AkkermT_ has quit [Ping timeout: 240 seconds]
jpuhlman has quit [Remote host closed the connection]
jpuhlman has joined #yocto
<rburton> kanavin_: yeah
<rburton> that's what I have, meta-ross/conf/site.conf
<kanavin_> rburton, right, then the only situation is when these things vary between builds, e.g. where the cache is on the network
<kanavin_> rburton, the other use case is when setting up a build with default templates, you get local.conf.sample, bblayers.conf.sample from meta-poky/conf, but not site.conf.sample
florian has quit [Quit: Ex-Chat]
AkkermT has joined #yocto
florian_kc has quit [Ping timeout: 272 seconds]
mootikins[m] has quit [Quit: You have been kicked for being idle]
dti has quit [Ping timeout: 260 seconds]
Telgareith has quit [Quit: Ping timeout (120 seconds)]
dtometzki has joined #yocto
Telgareith has joined #yocto
perdmann has quit [Ping timeout: 244 seconds]
khem has quit [Ping timeout: 240 seconds]
cperon has quit [Ping timeout: 240 seconds]
dtometzki has quit [Ping timeout: 276 seconds]
JudgeMaygarden[m has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
dtometzki has joined #yocto
dtometzki has quit [Ping timeout: 268 seconds]
khem has joined #yocto
cperon has joined #yocto
JudgeMaygarden[m has joined #yocto
jpuhlman_ has joined #yocto
jpuhlman is now known as Guest456
jpuhlman_ is now known as jpuhlman
violet has quit [Ping timeout: 255 seconds]
violet has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
mckoan is now known as mckoan|away
dtometzki has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
kanavin_ has quit [Quit: Leaving]
vladest has quit [Quit: vladest]
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
AkkermT has quit [Read error: Connection reset by peer]
vladest has joined #yocto
kanavin has joined #yocto
leon-anavi has quit [Quit: Leaving]
<rburton> hm clang makes buildpaths explode too
adams[1] has joined #yocto
kanavin has quit [Remote host closed the connection]
kanavin has joined #yocto
<rburton> khem: FYI meta-oe master will break without the python fixes i sent today/yesterday for meta-oe
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
dtometzki has quit [Ping timeout: 244 seconds]
Guest49 has joined #yocto
<Guest49> Thanks
Guest49 has quit [Quit: Client closed]
dtometzki has joined #yocto
vladest has quit [Ping timeout: 240 seconds]
vladest has joined #yocto
<khem> rburton: yeah I saw that in meta-oe AB and other CI jobs
<khem> rburton: clang should be as bad as gcc when it comes to buildpaths I assume. Or are you seeing something more
<rburton> khem: more warnings that gcc doesn't give
perdmann has quit [Ping timeout: 240 seconds]
gsalazar has quit [Remote host closed the connection]
perdmann has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<khem> oh that for sure
cambrian_invader has quit [Ping timeout: 244 seconds]
GNUmoon has quit [Remote host closed the connection]
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
GNUmoon has joined #yocto
dti has joined #yocto
dtometzki has quit [Ping timeout: 240 seconds]
GNUmoon has quit [Remote host closed the connection]
dti has quit [Ping timeout: 260 seconds]
GNUmoon has joined #yocto
dtometzki has joined #yocto
cambrian_invader has joined #yocto
adams[1]80 has joined #yocto
dtometzki has quit [Ping timeout: 240 seconds]
florian_kc has joined #yocto
dtometzki has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<RP> zeddii: thanks for everything this week, it has been a bit crazy but I've merged all the pending kernel bits and the buildpaths changes
<zeddii> no problem. Glad it is looking better. Now Ive got 5 or 6 for meta-virt :)
perdmann has quit [Ping timeout: 260 seconds]
perdmann has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<RP> zeddii: there will be a ripple effect from that change but I think it a worthwhile one (not least for better hashequiv)
<RP> zeddii: btw, if you do have any info on which kernels enable DEBUG_INFO and which don't I would like to understand that at some point for spdx manifests
hushmoney has joined #yocto
<RP> zeddii: buildpaths might mean fewer reproducibility issues making it through local user testing
<zeddii> right now, it's a per BSP thing. for the kernels. We have a "developer" kernel type, that isn't widely used, that globally enables things like that.
<zeddii> the default -standard doesn't, as it is leaner and suitable for deployment.
amitk has quit [Quit: leaving]
<zeddii> it seems like few of the go packages in meta-virt have buildpaths warnings. need to see if it is in the go binaries or secondary generated files.
<RP> zeddii: ok. We might want to look at enabling that kernel feature by default in OE-Core or in poky or something just so spdx works as expected now we have a good user of it...
<RP> zeddii: no idea on go I'm afraid
<RP> zeddii: I found all multilibs were broken for reproducibility earlier today which is kind of scary
<zeddii> RP: yah, it is something we can add in with the other kernel features. I can have a look at it early next week.
kscherer has quit [Quit: Konversation terminated!]
<RP> zeddii: ok, I'm asking mainly whilst I remember! I think I might know how to do it but you'd probably stand a better chance of getting it right!
denisoft81 has quit [Quit: Leaving]
* RP realises he forgot to try and sort CVEs :/
<zeddii> RP: right, it is just a matter of including features/debug/debug-kernel.scc in KERNEL_FEATURES
<zeddii> we can do at along side our other qemu bbappends.
xmn has quit [Ping timeout: 276 seconds]
<zeddii> or whatever machines we want. we'd need it for the reference h/w BSPs as well, I suppose.
<zeddii> would you want it on conditionally on a distro feature ? do we have a debug one like that ? one for SPDX ? i haven't checked, but will.
<RP> zeddii: we don't currently have a suitable distro feature
<zeddii> ok. I'll add that to the "to ponder" part
* RP ponders too
mvlad has quit [Remote host closed the connection]
<zeddii> it looks like it is the go binaries themselves that have the reference, probably a build ID.
* zeddii calls it quits and will look at that on Monday or over the weekend.
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
perdmann has quit [Ping timeout: 240 seconds]
perdmann has joined #yocto
olani has joined #yocto
adams[1]80 has quit [Ping timeout: 252 seconds]
adams[1] has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
seninha has quit [Quit: Leaving]