frgo has quit [Read error: Connection reset by peer]
frgo_ has joined #yocto
Daanct12 has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
Kubu_work has quit [Quit: Leaving.]
fhost has quit [Ping timeout: 244 seconds]
fhost has joined #yocto
fhost has quit [Ping timeout: 272 seconds]
Kubu_work has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.5.2]
Daanct12 has joined #yocto
Kubu_work has quit [Quit: Leaving.]
fhost has joined #yocto
fhost has quit [Ping timeout: 252 seconds]
Kubu_work has joined #yocto
fhost has joined #yocto
alessio has joined #yocto
aardo has joined #yocto
ardo has quit [Ping timeout: 248 seconds]
goliath has joined #yocto
savolla has joined #yocto
pbergin has joined #yocto
leon-anavi has joined #yocto
florian has joined #yocto
<wojci>
I have some recipes which don't follow the name_version.bb naming convention (I assume that there is one) for recipe files. How do I write a .bbappend file for a recipe like this?
<wojci>
The recipe that I have trouble with is just named "name.bb" without any version.
<wojci>
This seems like a stupid question .. name.bbappend should work, right?
davidinux has joined #yocto
frieder has joined #yocto
savolla has quit [Ping timeout: 265 seconds]
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
florian has quit [Ping timeout: 244 seconds]
<qschulz>
wojci: I believe it should yes
<dvergatal>
hi all i have a question how can I run function which is in my include file for layer configuration just once? because if i have it as anonymous it is being run multiple times and I just want it to be run once
vthor_ has joined #yocto
rfuentess has joined #yocto
vthor has quit [Ping timeout: 248 seconds]
JMB38 has joined #yocto
<RP>
dvergatal: when does it need to be run? event handlers may be an option...
RP has quit [Quit: Exiting]
<dvergatal>
RP: to download tarball
<dvergatal>
from some secure storage
RP has joined #yocto
florian has joined #yocto
<dvergatal>
RP: i think at the very beginning
<dvergatal>
during the start of building of everything?
frieder has quit [Remote host closed the connection]
frieder has joined #yocto
<RP>
dvergatal: you probably need to use this from a class, not a conf file
<dvergatal>
ok cool
savolla has joined #yocto
<rburton>
landgraf: if you're battling wic and its fighting against you, consider genimage instead
<qschulz>
I have a python script that needs to run natively in a target recipe, this python script has a /usr/bin/env python3 shebang but it seems to be using the host's python instead when executing
<qschulz>
is this supposed to work? or is there some sed magic I need to run somehow?
<qschulz>
instead of the one from the native sysroot
<rburton>
qschulz: do you mean you want it to use the python in python3-native? by default python is the host python, yes.
<qschulz>
rburton: oh ok, I thought it was a case of host poisoning
<rburton>
nope, there's a perfectly good python on the host (as it runs bitbake) so we use that unless told otherwise.
<qschulz>
So follow up question, why would one want to use host's python rather than the one built by Yocto (or vice-versa)
<rburton>
the host python is already there
<dvergatal>
RP: can i inherit a class in layer.conf file?
<qschulz>
rburton: ah yes, BitBake needs python, had forgotten about that /me facepalms.
<rburton>
qschulz: you only need to use the native python if you also depend on some third party modules (and tbh i want to allow recipes to pull in pure-python modules so that doesn't involve building python)
<qschulz>
rburton: mmmmmm, that means I should be able to have a very simple native recipe that just installs this python script in the SYSROOT_DIRS and not have it DEPENDS on python3-native
<rburton>
yeah just drop the script into bindir and it will just work
<qschulz>
thanks, very helpful (feels dirty though :D)
<rburton>
you don't feel dirty about using sh on the host though i presume?
<qschulz>
rburton: I really don't like it
<rburton>
you could just do all the builds inside the build appliance, which is a container for building yocto built by yocto.
<qschulz>
not the running on host's shell but rather it's running on whatever is the default shell no?
<rburton>
hosttools will symlink to the host /bin/sh
<qschulz>
yeah, that I don't like, can allow to have bashism (or any other shell-specific thingy) creep in tasks :/
<rburton>
i wonder what distros have sh->bash still
<qschulz>
rburton: wdym? what did I miss?
<rburton>
our tasks run in sh, which on debian is dash not bash
<RP>
dvergatal: you can set INHERITS
<rburton>
qschulz: the accidental bashism thing happens a lot less these days so i wonder if most distros don't use bash as sh now
savolla has quit [Ping timeout: 260 seconds]
<dvergatal>
RP: in layers.conf of the layer?
<qschulz>
rburton: fedora seems to default to bash? at least fedora:41 container seems to be doing that?
<rburton>
bah
<rburton>
khem: qemuriscv32 has kernel warnings in master ( [NOTE]: 'CONFIG_PAGE_OFFSET' last val (0xC0000000) and .config val (0xc0000000) do not match). presumably an easy fix as its just case :)
savolla has joined #yocto
<qschulz>
rburton: podman run --rm --security-opt label=disable fedora:41 ls -l /bin/sh
<dvergatal>
RP: currently i have "inherit ${@bb.utils.contains('IS_OFFICIAL_BUILD', 'true', 'user-keys', '', d) }"
<dvergatal>
and how to use INHERITS?
<RP>
dvergatal: I said INHERITS, not inherit
<dvergatal>
RP: yes and i asked how to use INHERITS
<RP>
dvergatal: sorry, it is INHERIT
<dvergatal>
INHERIT += "autotools pkgconfig" something like this?
<RP>
dvergatal: if you grep for that you'll see examples in core
<dvergatal>
ok
<RP>
dvergatal: but yes, like that
<dvergatal>
ok testing it
<dvergatal>
RP: thx it is working, btw. how can i do same thing on build finish but as failure?
savolla has quit [Quit: WeeChat 4.4.3]
<dvergatal>
RP: does this bb.event.BuildCompleted is also on failure?
<RP>
dvergatal: I'd have to check the code to be honest, I don't remember
savolla has joined #yocto
<dvergatal>
RP: what code? can you recall?
<RP>
dvergatal: If you grep bitbake for "BuildCompleted" you'll see some lines like bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runtaskentries), buildname, item, failures, interrupted), self.databuilder.mcdata[mc])
<RP>
dvergatal: it is also in the bitbake manual
<RP>
dvergatal: that implies to me that there is failure information in the event
<dvergatal>
RP: i will search for it
<dvergatal>
RP: failure information for event? i don't see it in bitbake manual
<dvergatal>
ahhh to catch it when completed
<dvergatal>
RP: actualy it does not matter if it has failed or not i would like to run some code when completed or failed
<dvergatal>
RP: so if BuildCompleted is on failure as well than it's fine
<RP>
dvergatal: the event happens regardless and contains information about whether there were any failures
<qschulz>
tlwoerner: finally managed to post those Rockchip DDR bin customization patches :)
<dvergatal>
RP: cool which is what i wanted to read :)
<dvergatal>
RP: thx a lot
<dvergatal>
RP: btw. did pidge mentioned you about the issue with USER_ADD and sstate cache? because we had a session together and finally we know what is the cause when building from just sstate_cache without build directory
<RP>
dvergatal: I thought we'd fixed those issues? Are you saying there is still a useradd bug left?
<dvergatal>
yes
<landgraf>
rburton: looks like exactly what I need. Cheers (I have a year old ticket to take a look at genimage even :D )
<RP>
dvergatal: First I've heard of it, I would like to understand/fix it though
<dvergatal>
RP: than you need to ping pidge she knows exactly what happens
<dvergatal>
RP: when building from sstate-cache dependency postinst scripts are not being pulled only the one from the package
<RP>
dvergatal: ideally we'd write a test case for selftest that illustrates the problem
<dvergatal>
RP: yeah pidge knows already about it, because as i said i had a session regarding this issue with her
<dvergatal>
RP: and i demonstrated the issue how it is occuring and so on
<RP>
dvergatal: with master?
<RP>
dvergatal: I'm not going to go and try and extract this info from pidge, it needs a bug report or patches or a test case reproducing it
<dvergatal>
RP: with scarthgap dunno if with master
<dvergatal>
RP: i can create a bug report regarding the issue
<RP>
dvergatal: checking it master has the issue would be very helpful
<dvergatal>
RP: it is harder for me to do it
<RP>
dvergatal: and harder again for me to since I know nothing about it!
Daanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has quit [Quit: WeeChat 4.5.2]
Daanct12 has joined #yocto
pidge has joined #yocto
<rburton>
guest21: with a bbappend that replaces that file. the docs cover doing that
<Guest21>
rburton you mean by copying whole script file and only changing ARGS in my own layer? I though there could be something more elegant
<rburton>
guest21: you could extend the recipe to be more elegant and submit a patch, but the easy way is to copy the script. its not exactly a complicated file
<Guest21>
rburton thank you very much
<dvergatal>
RP: what if i have in this class which i'm using in this INHERIT a call to d.getVar('LAYERDIR') and it reurns me None?
<dvergatal>
returns*
alessio has quit [Quit: alessio]
alessio has joined #yocto
<RP>
dvergatal: LAYERDIR doesn't make sense outside of a layer.conf file
<RP>
"which layer?"
<dvergatal>
RP: mine layer
<dvergatal>
RP: i call it in this class which is added to INHERIT in layer.conf
ptsneves has joined #yocto
<dvergatal>
RP: because i'm downloading some stream which is *something* and want to put in a location of THIS layer
<RP>
dvergatal: My point being that INHERIT is a generic deferral mechanism so it has no idea which layer the inherit came from and bitbake would have no idea how to set LAYERDIR correctly for that
<dvergatal>
d.getVar('LAYERDIR')}/files
<dvergatal>
RP: ok
<RP>
dvergatal: define some variable to point to LAYERDIR in your layer.conf, then use that
<dvergatal>
RP: ahhh ok cool thx
<RP>
but watch out for hardcoding buildpaths into the task hashes
<dvergatal>
sure thx a lot
<Saur>
We have this in all our layers: LAYERDIR_foo := "${LAYERDIR}" (where "foo" is the same name as used in BBFILE_COLLECTIONS). It also needs LAYERDIR_foo[vardepvalue] = "" to avoid affecting the sstate cache when using the variable.
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
<dvergatal>
RP: yeah it works
Xagen has quit [Ping timeout: 252 seconds]
JMB38 has quit [Ping timeout: 240 seconds]
<dvergatal>
Saur: this was to mee?
<dvergatal>
me*
<Saur>
dvergatal: Yes, it was. :)
<dvergatal>
Saur: k thx
<Saur>
dvergatal: Those two lines in each layer.conf file has solved all our problems where we need to refer to some specific file in another layer.
<dvergatal>
Saur: ok will do that thx a lot
<dvergatal>
Saur: can foo have - sign in names?
<Saur>
dvergatal: Yes. It should be the same as with, e.g., LAYERDEPENDS_foo and LAYERSERIES_COMPAT_foo.
<dvergatal>
yeah exactly
<dvergatal>
as it is
<dvergatal>
Saur: thx
ptsneves has quit [Read error: Connection reset by peer]
alessio has quit [Quit: alessio]
ptsneves has joined #yocto
alessio has joined #yocto
JMB38 has joined #yocto
<dvergatal>
btw. can i use if else when assigning to this variable?
<dvergatal>
Saur: RP: ^
<dvergatal>
because i'm trying to use my normal approach like in different places e.g. INHERITS += "${@'user-keys' if bb.utils.to_boolean(d.getVar("VAR")) else ''}"
<dvergatal>
and it doesn't work
<Saur>
dvergatal: Why would you want to do that? Those variables are intended to give the path for each layer.
<RP>
dvergatal: it will depend on where VAR is defined. You're probably doing an immediate expansion and if it wasn't set yet...
<dvergatal>
Saur: because i want to set it when i need to
<dvergatal>
RP: ok
<dvergatal>
RP: it was
leon-anavi has quit [Quit: Leaving]
<dvergatal>
RP: VAR is being passed with BB_ENV_PASSTHROUGH_ADDITIONS and as bitbake variable when bitbake is run
<dvergatal>
RP: if i changed d.getVar("VAR") to 'true' than it works as expected
<dvergatal>
RP: and when using VAR from bitbake variables than it doesn't work
Xagen has joined #yocto
<dvergatal>
and before when i had this as ${@bb.utils.contains('IS_OFFICIAL_BUILD', 'true', 'user-keys.inc', '', d) }
<dvergatal>
than when VAR was containing true the include file was included
<RP>
dvergatal: I tried to give you a hint this morning on a specific issue but I'm not really able to help you debug everything. This all sounds expected behaviour to me...
cyxae has joined #yocto
cyxae has quit [Remote host closed the connection]
<dvergatal>
RP: OK i get it but is it that variables which are passed through BB_ENV_PASSTHROUGH_ADDITIONS and bitbake are not immediate?
cyxae has joined #yocto
Chaser has joined #yocto
JMB38 has quit [Quit: Client closed]
<JPEW>
RP: Sent patch for SPDX dep code. It passed the sstate_allarch_samesigs test locally. The offender was OVERRIDES not being vardepsexclude'd
<RP>
JPEW: that makes sense, thanks
gecko_ has quit [Quit: Konversation terminated!]
vthor_ has quit [Remote host closed the connection]
<dvergatal>
RP: i'm a morron VAR was not being set to true but to false...
<dvergatal>
RP: sorry for pissing you off:P
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Pinta has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.5.2]
florian_kc has quit [Ping timeout: 252 seconds]
savolla has quit [Ping timeout: 260 seconds]
gecko_ has joined #yocto
Guest21 has quit [Ping timeout: 240 seconds]
Chaser has joined #yocto
ashux88 has joined #yocto
GNUmoon has quit [Remote host closed the connection]
Pinta has quit [Quit: Client closed]
ashux88 has quit [Quit: Client closed]
ashux88 has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
gecko_ has quit [Remote host closed the connection]
gecko_ has joined #yocto
gecko_ has quit [Client Quit]
gecko_ has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Chaser has joined #yocto
Chaser has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
wojci has quit [Ping timeout: 245 seconds]
Chaser has joined #yocto
Chaser has quit [Client Quit]
<JPEW>
RP: Weird incongruency for gcc-source: SSTATE_ARCHS has "allarch" but SSTATE_ARCH is "all"; meaning SPDX can't find a document written earlier in the build since it uses those 2 variables
<JPEW>
Should SPDX be doing something different?
<JPEW>
Sorry, SSTATE_PKGARCH is "all"
<khem>
rburton: ah CONFIG_PAGE_OFFSET yes, we should perhaps review the defconfigs with 6.12 I have not booted qemurv32 in a month or so
<RP>
JPEW: I wonder where that comes from? :/
<JPEW>
gcc-source.inc does `PACKAGE_ARCH = "all"`
<RP>
JPEW: we could try changing PACKAGE_ARCH in gcc-source.inc to allarch
<RP>
JPEW: just spotted that :)
<JPEW>
I cna't figure out why it's a problem now though
<ashux88>
hi members
<ashux88>
do we have any link to get openstack on yocto
<ashux88>
and which all modules of openstack are supported by yocto