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"
xmn has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
peoliye has quit [Quit: Client closed]
peoliye has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
camus has joined #yocto
seninha has quit [Quit: Leaving]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 244 seconds]
camus1 is now known as camus
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
jclsn has joined #yocto
sakoman has joined #yocto
amitk has joined #yocto
sotaoverride has quit [Quit: Lost terminal]
pgowda_ has joined #yocto
xmn has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
Wouter01001 has quit [Remote host closed the connection]
Wouter01001 has joined #yocto
kroon has joined #yocto
roussinm has quit [Quit: WeeChat 3.0]
thomasd13 has joined #yocto
sakoman has quit [Quit: Leaving.]
goliath has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
marc1 has quit [Ping timeout: 264 seconds]
marc1 has joined #yocto
leon-anavi has joined #yocto
kroon_ has joined #yocto
kroon has quit [Ping timeout: 244 seconds]
frieder has joined #yocto
mckoan|away is now known as mckoan
Wouter01001 has quit [Ping timeout: 240 seconds]
kroon_ has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
rfuentess has joined #yocto
Schlumpf has joined #yocto
Wouter01001 has joined #yocto
goliath has joined #yocto
ptsneves has joined #yocto
SDes91 has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
SDes91 has quit [Client Quit]
<qschulz> halstead: ndec: thanks.
Salamandar has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
peoliye has quit [Quit: Client closed]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
mvlad has joined #yocto
rfuentess_ has joined #yocto
rfuentess has quit [Ping timeout: 276 seconds]
kriive has quit [Read error: Connection reset by peer]
kriive has joined #yocto
rfuentess_ is now known as rfuentess
rfuentess has quit [Ping timeout: 272 seconds]
jatedev has quit [Quit: Client closed]
starblue has quit [Ping timeout: 256 seconds]
florian has joined #yocto
starblue has joined #yocto
ptsneves has quit [Quit: Client closed]
rfuentess has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
florian has quit [Ping timeout: 244 seconds]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
Schlumpf has quit [Quit: Client closed]
wkawka has joined #yocto
seninha has joined #yocto
rfuentess has quit [Ping timeout: 244 seconds]
ptsneves has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
manuel1985 has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<wkawka> Hi, how can I add a container with built in package? My build uses meta-virtualization layer, so I thought about including recipe: https://git.yoctoproject.org/meta-virtualization/tree/recipes-extended/images/container-base.bb?h=master#n17
<wkawka> And then append my package to IMAGE_INSTALL, then this recipe to IMAGE_INSTALL also, however my recipe then does not provide anything
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
Schlumpf has joined #yocto
chep has quit [Quit: ZNC 1.8.2 - https://znc.in]
ToolboxBunny has joined #yocto
<ToolboxBunny> Hi
<ToolboxBunny> I'm hoping to do a `bbfatal` in a recipe in case a variable is not set.
<ToolboxBunny> It's a simple `systemd_%.bbappend` which sets an IP address of an NTP server.
chep has joined #yocto
<ToolboxBunny> I have a conditional within the bbappend to check for that variable `if [ -z ${NTP_SERVER_IP+x} ]; then ...<bbfatal>`
<ToolboxBunny> This seems to be ignored if I first build with the variable set in local.conf and later remove the variable from local.conf
<ToolboxBunny> I'm assuming this is due to caching of the systemd recipe
<ToolboxBunny> I could disable caching (`SSTATE_SKIP_CREATION = "1"`) for systemd but that would influence build time even when the variable `NTP_SERVER_IP` is set correctly.
<ToolboxBunny> Is there a smarter way to enforce a check if a variable is set every time?
<qschulz> ToolboxBunny: there's a varflag to explicit a dependency on a variable
<qschulz> gimme a few seconds/minutes to find it
<ToolboxBunny> qschulz: Thanks. Found something here based on your comment: https://docs.yoctoproject.org/bitbake/1.46/bitbake-user-manual/bitbake-user-manual-metadata.html#variable-flags
rfuentess has joined #yocto
<qschulz> ToolboxBunny: I think vardeps for the task that is running the bbfatal check should work?
<qschulz> I have never used it so can't say, but looks like a good thing to test
<ToolboxBunny> Sounds cool, thanks!
paulg has joined #yocto
GNUmoon has quit [Ping timeout: 268 seconds]
<qschulz> halstead: layers.openmebdded.org has an expired certificate
<wkawka> Can I use require to .bb file?
<qschulz> yes
<wkawka> or I have to use .bbappend file
<qschulz> no
GNUmoon has joined #yocto
<qschulz> halstead: FYI, https://github.com/louislam/uptime-kuma/releases/tag/1.17.0 seems to support notification of certificate expiration if you are looking for some monitoring tool
jpuhlman has quit [Remote host closed the connection]
<wkawka> Unfortunately, it cannot find file within other layer, i have specified this like that: require path/to/recipe/in/other/layer/recipe.bb
<qschulz> wkawka: yes
<qschulz> it's relative to the root of *any* layer
jmiehe has joined #yocto
<qschulz> so it should be require some-layer-root/recipes-something/someofthat/myrecipe.bb
<qschulz> to be precise, if you don't give it a relative path, it looks in the same directory as the recipe the require is in
<wkawka> so in my case it should me meta-virtualization/path/to/recipe.bb ?
<wkawka> if so, that doesn't work too
<qschulz> no
<qschulz> it should be path/to/recipe.bb
<wkawka> ok now it works
<qschulz> (i was not very clear though, not easy to explain :) )O
<wkawka> Thank you
<ToolboxBunny> Is it possible to conditionally enable a task only if a distro feature is enabled?
<kergoth> You'd probably need anonymous python for that, there's a function in the bb python library to do the addtask. It's possible you could leverage variable references within an addtask line as an alternative, but not sure if that statement handles that or not, you'd have to test it
<ToolboxBunny> Something like this: https://pastebin.com/AJkCMNwg
<wkawka> What is busybox and is it required to load and run an image in .tar.bz2 format?
<qschulz> wkawka: busybox is a swiss army knife of many small linux utilities
<kergoth> The format isn't relevant. Any image can be written in whatever format you want, its contents don't matter to that
<ToolboxBunny> kergoth: "anonymous python" is an equivalent of creating a nameless task in bitbake?
<kergoth> A nameless python task, yes
<kergoth> python () {}
<qschulz> ToolboxBunny: you could always have a do_mytask[noexec] = "${@bb.utils.contains("DISTRO_FEATURES", "some-feature", 0, 1)}"
<wkawka> so it isn't required to load an image right?
<qschulz> wkawka: don't know what you mean by "load an image"
<qschulz> but very likely no
<wkawka> i mean by docker load -i image
<ToolboxBunny> qschulz: Thanks! That sounds promising. I just need to check the order of priority between `nostamp` and `noexec` as I'd want it to run with `nostamp` once it's enabled.
<qschulz> ToolboxBunny: you could also always run the task but exit early if the DISTRO_FEATURES feature ius not there
<qschulz> many different implementations are possible
<ToolboxBunny> qschulz: Fair, I'm hoping to identify the one which will be the most obvious to someone is reading the recipe the first time :)
goliath has quit [Quit: SIGSEGV]
xmn has joined #yocto
jpuhlman has joined #yocto
GNUmoon has quit [Write error: Connection reset by peer]
GNUmoon has joined #yocto
<ToolboxBunny> I have something this for a custom task in `systemd_%.bbappend` : `addtask simple_sed_of_config_file after do_install before do_populate_sysroot`
<ToolboxBunny> As the task name implies, it's just sedding a config file based on a value in a variable.
<ToolboxBunny> I've set it to run every time `do_simple_sed_of_config_file[nostamp] = "1"` to get a human friendly debug error ( `bbfatal "Variable SED_VAR needs to be set because... bla bla"` ) in case the variable isn't set.
<ToolboxBunny> However it seems that the dependencies get built only after `do_populate_sysroot`
<ToolboxBunny> That's what I'm seeing for the tasks.
<ToolboxBunny> It executed the `simple_sed_of_config_file` which is a cheap single line command, and after that it rebuilds all the dependencies for systemd...
<ToolboxBunny> Is that a common pattern that dependencies get build only after all tasks in the recipe have been done?
<qschulz> not all tasks, specifically do_populate_sysroot
<ToolboxBunny> qschulz: Thanks. I get that `do_populate_sysroot` will get rebuilt again. What I don't get is what that triggers the rebuild of dependencies. i.e. ` glib-2.0-1_2.62.6-r0 do_configure ...` and a few of those other recipes
<ToolboxBunny> *why that triggers
<qschulz> when you have a build time dependency in recipe A on recipe B (in A you have DEPENDS = B)
<qschulz> the do_prepare_recipe_sysroot task of A will wait for do_populate_sysroot of B to finish
<qschulz> because A will import the sysroot from B into the A directories
<qschulz> so it needs to be available
<qschulz> once that's done, it can run do_configure, do_compile etc
<qschulz> otherwise you wouldn't have the header files/shared libraries from B available at build time for A
<ToolboxBunny> Ok, let me translate that:)   I guess A is `systemd` and B is `glib`
<qschulz> maybe yes
<ToolboxBunny> So `systemd` depends on `glib`. So far so good
<qschulz> mmm no actually, A would be glib and B systemd
<qschulz> (provided you're complaining changing do_simple_sed_of_config_file in systemd triggers glib-2.0-1_2.62.6-r0 do_configure)
<ToolboxBunny> Oh... I guess that's my confusion
<ToolboxBunny> I assumed those were all dependencies of systemd being compiled after systemd was done. :)
<ToolboxBunny> So that didn't make sense.
<ToolboxBunny> > provided you're complaining changing do_simple_sed_of_config_file in systemd triggers glib-2.0-1_2.62.6-r0 do_configure
<ToolboxBunny> Exactly
<ToolboxBunny> No way to avoid that I guess... Perhaps I can make the `do_simple_sed_of_config_file` run after `systemd: do_populate_sysroot` and use that "execute a custom function over to the full rootfs variable (forgot the name :/ )"
<qschulz> ToolboxBunny: if you have the hash equivalence server running, this shouldn't be an issue I think
<qschulz> because it'll detect your change didn't impact other things
<qschulz> and it'll just rebuild a few tasks of dependencies and not all
<qschulz> depends on the version of Yocto you're using
<qschulz> and I'm not too familiar with the hash equiv server unfortunately
kroon has joined #yocto
<qschulz> just know the very basics on what it's supposed to do
sotaoverride has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
pabigot has quit [Remote host closed the connection]
amitk has joined #yocto
sakoman has joined #yocto
goliath has joined #yocto
kroon has quit [Quit: Leaving]
thomasd13 has quit [Ping timeout: 244 seconds]
<halstead> Thank you qschulz. The renewal is complete now.
fitzsim has joined #yocto
florian has joined #yocto
camus has quit [Quit: camus]
florian has quit [Ping timeout: 255 seconds]
<qschulz> halstead: :+1:
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Guest20 has joined #yocto
<Guest20> How to generate iso image, I tried  +IMAGE_FSTYPES_append = " iso hddimg" but getting invalid image type error.
<JaMa> RP: do you remember if there was specific reason for using expand=False for network varFlag in https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543 ? I wanted to change https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=25ea276a13a6ac2342c2b0945c8fafe878d56095 to enable network only when ICECC_DISABLED isn't set
<wkawka> Hi, what can be the problem here: https://pastebin.com/VNJDT8rA
<wkawka> When I to run it via docker, nothing happens
<wkawka> I tried*
<wkawka> It should be a container only with bash, but when i run it like this; docker run -it --rm image-name /bin/bash
<wkawka> Nothing happens
rfuentess_ has joined #yocto
<zeddii> wkawka: you need to docker import the image before docker can run it.
<wkawka> I did that before
<zeddii> not sure then :)
<zeddii> the container image type doesn't do much more than ensure the kernel and some extra's aren't installed, so importing the tgz is most of it, with or without the container image type.
rfuentess has quit [Ping timeout: 240 seconds]
<RP> JaMa: it was efficiency
<RP> JaMa: saved any expansion call
<RP> and any processing to determine if the value was true or false
<JaMa> RP: and would it be acceptable to enable to support https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/kirkstone&id=5bbb735c3285a16bf2ec9548a58b887f93f4900e ?
<wkawka> Still i don't know what to do to make it run
<wkawka> i imported ext4 file and there is an output
<wkawka> docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown.
<JaMa> I guess I can delVarFlag when ICECC_DISABLED is set, but then it would delete it even where it was explicitly enabled in the recipe
<wkawka> however, /bin/bash directory exists in tar.bz2 file
<wkawka> so that's strange
frieder has quit [Remote host closed the connection]
<RP> JaMa: well, I'd prefer not to as all these things mount up to increase parsing time but I'm starting to feel like I should just not care. I'm tired of saying no
<RP> JaMa: you could just equally set or delete those in anon python I guess. I really just don't know what to do for the best any more
nemik has quit [Ping timeout: 240 seconds]
<JaMa> RP: yes delVarFlag in anon python was my backup plan if the price for expand is too high, thanks
nemik has joined #yocto
<RP> JaMa: it is sad in that "0" won't work in there are a value today either but I really don't know what price people want to pay on parsing speed vs usability and consistency
Guest5 has joined #yocto
<JaMa> understood, thanks
<RP> JaMa: memories are paging back in, I think I did this to see whether anyone complained which they now have. It isn't unreasonable to properly check it :/
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<RP> it is a bit like the cleandirs change for externalsrc. It will slow things down a lot :/
<Guest5> Hello, I am trying to override the CVE_CHECK_IGNORE variable in one of the inc file where CVEs for multiple components are ignored. E.g. CVE_CHECK_IGNORE:<component name>. But this is not ignoring CVE for that specific component. Am I missing something or this is not allowed?
jpuhlman has quit [Remote host closed the connection]
<qschulz> Guest5: pretty sure it should be pn-<component name>?
<RP> wouldn't you just set it globally anyway, it doesn't need to be set per recipe really
jpuhlman has joined #yocto
<Guest5> ahh thanks qschulz
<ToolboxBunny> Hey,
<ToolboxBunny> anyone know under which task do functions listed under `ROOTFS_POSTPROCESS_COMMAND` get executed?
<ToolboxBunny> I've just added a `bbwarning "I am executed, can you see me"` into a function and added it under `ROOTFS_POSTPROCESS_COMMAND` but didn't see it get printed during the image build.
wkawka has quit [Quit: Client closed]
wkawka has joined #yocto
rfuentess_ has quit [Remote host closed the connection]
pgowda_ has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
mohamed-dhiamtir has quit [Quit: You have been kicked for being idle]
khem has quit [Quit: You have been kicked for being idle]
nemik has quit [Ping timeout: 256 seconds]
mckoan is now known as mckoan|away
nemik has joined #yocto
Guest20 has quit [Quit: Client closed]
Schlumpf has quit [Quit: Client closed]
manuel1985 has quit [Ping timeout: 244 seconds]
stkw0 has left #yocto [https://quassel-irc.org - Chat comfortably. Anywhere.]
<derRichard> let's say i have a sdk installed and want to install libfoo to this sdk, is there a way to achieve that? of course i could just add libfoo to the sdk build, rebuild and reinstall the sdk. but i'd to "enhance" an already installed sdk.
khem has joined #yocto
<RP> derRichard: a standard sdk, no. There are ways with eSDK
<JaMa> do I remember correctly that there was some limit of how many git repos you can use in SRC_URI? IIRC zeddii came across it in some recipe using go with many deps, I wonder if I've reached that limit with tensorflow-lite as well
<RP> JaMa: I think the limit was his machine :)
<RP> it gets a bit slow as there is no parallelism for that
<JaMa> aha :) then maybe I'm just blind to see the typo, will continue drinking coffee until it pops
<derRichard> RP: the approach for esdk would be adding a libfoo.bb and building it?
<RP> derRichard: yes
<derRichard> i see. thx
<derRichard> on the other hand, adding rpm support to the sdk should be doable. such that rpm -i libfoo-devel.rpm works and installs into the sdk sysroot. no?
<RP> derRichard: we once did that. We removed the support as it turns out it doesn't work well at all
nots has quit [Quit: No Ping reply in 180 seconds.]
<RP> derRichard: not least that people expect non-oe built rpms to work
<derRichard> i'd install only oe build rpms, of course
<derRichard> (i'm currently looking for a way to migrate a massive in-house developed build system to yocto)
Notgnoshi has joined #yocto
<RP> derRichard: I trust you'd do that but users did do all kinds of horrible things with it. In the end we said enough was enough and started work on the eSDK with the idea that it could be extended via sstate instead
<RP> derRichard: setting up the infra to share the rpms and ensuring users consistently installed things was hard even with a package manager, it really didn't work well in practise
ToolboxBunny has quit [Ping timeout: 252 seconds]
<derRichard> RP: when did you remove that feature from the sdk? maybe i can revive it locally :>
<JaMa> ok the typo was that one of 17 SRCREVs was 1 characters shorter, unfortunately the fetcher error didn't say which git repo in Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None), will try to improve this error message when time permits
Notgnoshi has quit [Quit: No Ping reply in 180 seconds.]
Notgnoshi has joined #yocto
<zeddii> JaMa. what RP said. i didn't hit a hard limit, just maybe a limit on patience waiting for the fetches :)
* zeddii sees what it was (the typo).
* zeddii just got an email that his elc-e submission was accepted.
rifida has joined #yocto
* moto-timo notes elc-e schedule will be announced July 12
glembo[m] has joined #yocto
Guest16 has joined #yocto
Guest16 has quit [Client Quit]
peoliye has joined #yocto
<zeddii> there is only one important talk on that schedule. the rest is fluff!
<glembo[m]> Is it possible to read from a local file via inline python? Something like this: `FOO = "${@d.read_file_content_into_var("filename")[0]}"`
Guest16 has joined #yocto
Guest16 has quit [Client Quit]
contre has joined #yocto
Soopaman has joined #yocto
florian has joined #yocto
<Soopaman> greetings all!
<Soopaman> are there any updated tutorials for creating wpe images for multiple platforms?
jmiehe has quit [Ping timeout: 276 seconds]
seninha has quit [Ping timeout: 244 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
florian has quit [Ping timeout: 244 seconds]
Piraty has quit [Quit: -]
Piraty has joined #yocto
ripastri has joined #yocto
contre has quit [Read error: Connection reset by peer]
seninha has joined #yocto
manuel1985 has joined #yocto
Soopaman has quit [Quit: Leaving.]
Guest5 has quit [Quit: Client closed]
rifida has quit [Ping timeout: 240 seconds]
peoliye has quit [Quit: Client closed]
<rsalveti> JPEW: I'm getting an interesting issue with create-spdx which seems to be cache related
<rsalveti> I updated meta-tegra layer which included a kernel rev bump, and then do_rootfs started to fail when generating the spdx tarball (when collecting all dependencies and json files)
<rsalveti> e.g.:
<rsalveti> Exception: FileNotFoundError: [Errno 2] No such file or directory: '..spdx/jetson-agx-xavier-devkit/by-namespace/http:__spdx.org_spdxdoc_kernel-module-wireguard-4.9.253-l4t-r32.7+gac2a37e8219a-2a9f15b9-160a-55c2-afc9-852ee5b15821'
<rsalveti> that is because wireguard-tools rrdepends on kernel-module-wireguard, and the actual rev there depends on the rev used by the kernel
<rsalveti> when I force create_runtime_spdx for wireguard-tools I can see it is generating the right DocumentRef-runtime-dependency-kernel-module-wireguard-4.9.253-l4t-r32.7+gad2fc41d9ae8
<JPEW> rsalveti: interesting. Someone else on the ML saw a similar issue
<rsalveti> but when I try building the image, it uses the older one
<rsalveti> and the diff shows that it is a cache issue because it is matching the revs
<rsalveti> so the kernel srcrev bump didn't reflect into the spdx logic, and it just restored the older one
<JPEW> Ok, I'm afk right now, give me 20 minutes and I'll take a look
<RP> derRichard: it was many years ago
<rsalveti> cool, thanks, looking here as well
<derRichard> RP: i see
gpanders has joined #yocto
<gpanders> I'm trying to build libgfortran for a Zynq board, using the arm-xilinx-linux-gnueabi cross toolchain. It's failing in the configure stage because it can't find arm-xilinx-linux-gnueabi-gfortran. When I check libgfortran's recipe-sysroot-native directory I can verify that -gfortran is not there, but e.g. -gcc and -g++ are there. I've been poking around the GCC recipe trying to figure out how to
<gpanders> install gfortran into the sysroot, but not having any luck. Anyone here happen to know how to do that?
amitk has quit [Ping timeout: 240 seconds]
* paulg waves bye to meta-gplv2
<rsalveti> JPEW: the interesting piece here is that there is indeed no need for rebuilding wireguard-tools because that recipe is userspace only, the piece that requires a rebuild is the kernel module, which is provided by another recipe.
<JPEW> Right, but the spdx needs to be regenerated because the data changed
<rsalveti> but since we have RRECOMMENDS:${PN} = "kernel-module-wireguard" in wireguard-tools, that causes the spdx to generate the runtime dependency based on the kernel-module revision
<rsalveti> right, but it is an indirect dependency
ripastri is now known as contre
<rsalveti> for the actual ipk package this is not a problem because the dependency is not versioned (Recommends: kernel-module-wireguard), but the spdx data includes the exact revision (kernel-module-wireguard-4.9.253-l4t-r32.7+gac2a37e8219a)
pabigot has joined #yocto
<JPEW> rsalveti: Right. Even if it didn't, spdx documents are linked with checksums
seninha has quit [Ping timeout: 244 seconds]
<JPEW> So the wireguard-tools spdx has to be rebuilt, and it's not for since reason
<rsalveti> yeah
<rsalveti> the create_runtime_spdx task should depend on every respective depends/rdepends/rrecommends create_spdx task, or similar
<rsalveti> from the cache perspective
chep has quit [Quit: ZNC 1.8.2 - https://znc.in]
chep has joined #yocto
manuel1985 has quit [Ping timeout: 240 seconds]
contre has quit [Remote host closed the connection]
contre has joined #yocto
contre has quit [Remote host closed the connection]
contre has joined #yocto
<JPEW> rsalveti: Can you send me the SPDX document for wireguard-tools ?
<rsalveti> JPEW: runtime-wireguard-tools.spdx.json?
<JPEW> Ya
pabigot has quit [Remote host closed the connection]
<rsalveti> that is the "bad" one, using the older kernel rev as part of the module package
Xagen has quit [Quit: Textual IRC Client: www.textualapp.com]
<JPEW> rsalveti: I'm not sure why it didn't re-run.... hmmm :/
<JPEW> I *think* `do_create_runtime_spdx[rdeptask] = "do_create_spdx"` should make that happen
<rsalveti> looking at the hash dependencies, and it is indeed not there
<JPEW> Which is strange, because the runtime dependencies are pulled from `BB_TASKDEPDATA`
<JPEW> rsalveti: What "hash dependencies" are you referring to?
<rsalveti> using bitbake-dumpsig on wireguard-tools, for both create_spdx and create_runtime_spdx
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<rsalveti> wonder if that is just because it is rrecommends?
<JPEW> Could be I guess? Strange that it would be in BB_TASKDEPDATA, and not in the signature file
<JPEW> rsalveti: Can you try a test where you repeat it but with it as an RDEPENDS?
<rsalveti> yup, trying that now
florian has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
contre has quit [Remote host closed the connection]
contre has joined #yocto
<rsalveti> rdepends didn't help
seninha has joined #yocto
<JPEW> So, the kernel module still isn't in the dependencies in the signature?
<JPEW> the signature for wireguard-tools:do_create_runtime_spdx
wkawka has quit [Quit: Client closed]
<rsalveti> nops, checking both create_spdx and create_runtime_spdx
<rsalveti> with bitbake-dumpsig -t wireguard-tools create_runtime_spdx
<rsalveti> I get for bash and bash-completion, but nothing related to the module
<rsalveti> which is provided by wireguard-module
<JPEW> That is so weird
<JPEW> Well, probably intentional, just un-expected :)
<rsalveti> right, probably special because it is a module
<JPEW> Hmm, maybe
<JPEW> I'm mostly baffeled why it shows up in BB_TASKDEPDATA, but not the signature :)
<rsalveti> yeah, added another normal recipe/package in rdepends and it shows up, as expected
<rsalveti> just not the module :-)
<JPEW> Must be some module specific thing I guess; I can't seem to find the code though
pabigot has joined #yocto
mvlad has quit [Remote host closed the connection]
jpuhlman_ has joined #yocto
jpuhlman is now known as Guest1413
jpuhlman_ is now known as jpuhlman
Guest1413 has quit [Killed (mercury.libera.chat (Nickname regained by services))]
<JPEW> `sstate_rundepfilter` maybe
<JPEW> Yes, that exactly I think
<rsalveti> yeah
<rsalveti> there is logic there to exclude the dependency :-)
<JPEW> Right, to fix the error, the code sifting through BB_TASKDEPDATA should probably filter like the signature generator does
<JPEW> Not 100% ideal, since you'll miss the runtime dependency in your SPDX, but not the worst
<rsalveti> right
<JPEW> I wonder if there is a way to run the siggen dep_check procedure in our task
<JPEW> `rundep_check` that is
<JPEW> Hmm, except we don't have all the dataCaches :/
<JPEW> I'm also fairly certain that function will just explode if you pass None for dataCaches, even though it claims the default parameter of None is fine :)
<rsalveti> probably yeah :-)
<JPEW> Well, I think we know the problem. Have to think on the solution a little; unfortunately, I have to go feed the fam now so I'm out for the day
<rsalveti> np, thanks for helping out
<JPEW> rsalveti: If you want to find the ML post that was done earlier about a similar problem and report our findings, that would be really helpful
<JPEW> unless it was you that posted it :)
<rsalveti> haha, no, will have a look
contre has quit [Remote host closed the connection]
contre has joined #yocto
ripastri has joined #yocto
contre has quit [Read error: Connection reset by peer]
leon-anavi has quit [Quit: Leaving]
florian has quit [Ping timeout: 276 seconds]
jmiehe has joined #yocto
ripastri has quit [Remote host closed the connection]
ripastri has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
peoliye has joined #yocto
goliath has quit [Quit: SIGSEGV]
<rsalveti> seems the issue raised on the ml is related to a problem when creating the spdx files, here they are created successfully, just with the "wrong" content
peoliye has quit [Ping timeout: 252 seconds]
xmn has quit [Ping timeout: 276 seconds]
Habbie has quit [Ping timeout: 272 seconds]
Habbie has joined #yocto
xmn has joined #yocto