vladest has quit [Remote host closed the connection]
vladest has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
xmn has quit [Quit: ZZZzzz…]
rfuentess has joined #yocto
mckoan|away is now known as mckoan
* RP
wonders what to to with the rc1 build. An intermittent PRserv selftest came up and a reproducibility failure for go-staticdev, but only for rpm :/
xmn has joined #yocto
Habbie has quit [Ping timeout: 244 seconds]
Habbie has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
alessioigor has quit [Quit: alessioigor]
<RP>
rburton: I think the go issue may be something to do with builds on arm hosts changing the content on x86 ones
<RP>
persisting via sstate
tnovotny has joined #yocto
leon-anavi has joined #yocto
<thomasd13>
Good morning guys: I searched in the yocto manual, but could not find a list of possible values for IMAGE_BUILDINFO_VARS. Do you know where I can find this?
mvlad has joined #yocto
davidinux has quit [Ping timeout: 250 seconds]
davidinux has joined #yocto
jquaresma[m] has joined #yocto
Payam has joined #yocto
<frosteyes>
Hi folks. I have a minor issue with alsa in kirkstone (version 1.2.6.3) where it report an error. "alsa-lib ../../../alsa-lib-1.2.6.1/src/ucm/main.c:1412:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2"
<frosteyes>
It seems to be fixed in 1.2.7. Will check, so if it is fixed I will like to bump alsa in kirkstone and send a patch. Anything preventing us from bumping the alsa to 1.2.7.2 like poky master in poky kirkstone.
GNUmoon has quit [Remote host closed the connection]
ptsneves has joined #yocto
GNUmoon has joined #yocto
florian has joined #yocto
<RP>
thomasd13: I'm guessing it takes general variable names?
<RP>
frosteyes: we'd need a case for it being bugfixes without the risks from new features and other issues
<RP>
or that it is worth the risks to gain the fixes
<jclsn>
Thing is, that I haven't really changed anything in the image recipe
<RP>
thomasd13: those variables aren't in core and not specific to buildinfo
<jclsn>
I already tried going some commit back, even more than what I did yesterday, but it didn't help
apprehend3108[m] has quit [Quit: You have been kicked for being idle]
<jclsn>
Also tried deletin tmp of course
<RP>
thomasd13: I think they must be something that is added by some recipe/layer
apprehend3108[m] has joined #yocto
apprehend3108[m] has left #yocto [#yocto]
<mckoan>
thomasd13: actually "APP_URI_PREFIX" and "APP_URI_BRANCH" are useless. I'll remove them
<rburton>
RP: hm, annoying. i can fire some builds across different machines to test that hyothesis.
Juanosorio94 has quit [Quit: Client closed]
<RP>
rburton: I already started and have confirmed it :/
<RP>
rburton: there is a build on ubuntu2204-arm-1 in ~/rptest/ and go-runtime has different files depending on the host you build it on :(
<rburton>
bah
<rburton>
_files_?!
<RP>
rburton: I'm trying to work out if I delete the cmd directory, whether that is good enough
<rburton>
looking at the wrong tuple to decide what pieces to build?
<RP>
rburton: go-runtime for target builds native components too
<RP>
rburton: if the components overlap, they are in the same path
<rburton>
thanks, go
<thomasd13>
thanks RP and mckoan. Are there any variables I could use, to write the URI_SRC from every package which is gonna installed into the buildinfo-file?
<RP>
thomasd13: that code can't iterate over all recipes
<RP>
rburton: confirmed it is just the cmd directory
<RP>
rburton: so we can delete that and be kind of happy
<thomasd13>
ok :)
<mcfrisk>
multiconfig results in recipe parsing time increases for each config. bitbake -e image for single machine is 18s, with mc enabled for 8 machines 1m10s. I hope multiconfig is worth it..
<mckoan>
thomasd13: AFAIK is a feature not available. However the closes solution is enabling COPY_LIC_MANIFEST
<Payam>
yes I was more thinking about where to put tests and all.
<Payam>
How do you do that? Do you have a repo for the build and another for test and repo docs?
<kanavin>
Payam, what kinds of tests specifically?
<rburton>
a repo for the metadata (recipes, etc). all code should be in separate repositories, not embedded with the build metadata
<Payam>
I am very new with yocto but I worked with other projects in python, c++ etc. where I had src/ and test/ docs/ and in the root I had readme and debian/ or whatever
<Payam>
rburton, ah. okej very good.
<kanavin>
yeah, separate repos for the code itself, then write a recipe for it, and place that into a layer
<kanavin>
the recipe refers to where the code is in SRC_URI
<rburton>
Payam: software development and build integration are separate tasks, best not merged into a single repository.
<Payam>
thanks rburton
Juanosorio94 has joined #yocto
goliath has joined #yocto
<Juanosorio94>
I have a kernel module that has includes (.h) from another propietary module (linux), for some reason im getting errors that types like u16 and so on dont exist, even though the propietary module built just fine. I just checked and I am also setting the KERNEL_SRC variable correctly, anyone any ideas?
Juanosorio9479 has joined #yocto
Juanosorio94 has quit [Quit: Client closed]
<thomasd13>
Does make following sense: 1. I define a .bbclass which contains a function that should get executed during package install. 2. I inherit in each recipe, which I want that this function gets executed, that .bbclass
<thomasd13>
?
<thomasd13>
Does this work? To extend in that way a install function of any recipe in a easy way?
<rburton>
that's what classes are for, yes :)
<thomasd13>
yes!!!!! thanks :D
<rburton>
the class can either provide its own do_install(), or do_install[postfunc], or just a function that the recipes call in their own do_install
grma has quit [Ping timeout: 252 seconds]
<mcfrisk>
is multiconfig completely broken in kirkstone? buildhistory is rewritten for each multiconfig entry after exiting devshell
likewise has joined #yocto
mckoan is now known as mckoan|away
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
sef has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
thomasd13 has quit [Ping timeout: 268 seconds]
<sef>
im trying to use libedgetpu in a c++ project. but getting undefined reference outputs. output like this : https://pastebin.com/7Y7sjVMd
<rburton>
oh joy, it's doing in-tree partial builds instead of from scratch
Tyaku has joined #yocto
vladest1 has joined #yocto
<rburton>
ld: warning: libc++.so.1, needed by libedgetpu.so, not found
<rburton>
are you trying to use clang to build/link?
<rburton>
sef: ^
vladest has quit [Ping timeout: 250 seconds]
vladest1 is now known as vladest
fuzzybear396527 has joined #yocto
Tyaku has quit [Client Quit]
<rburton>
JPEW: have you had thoughts on how to track in the spdx stuff that goes to deploy/ and nowhere else?
<JPEW>
It should be possible to at least report them in an SPDX document
<JPEW>
And link them back to the originating recipe
fuzzybear396527 has quit [Quit: Ping timeout (120 seconds)]
<JPEW>
rburton: There probably needs to be some generic method to say "capture the output of this task that write to DEPLOYDIR as an SPDX document", since it's not standardized which tasks write to deploy
alessioigor has quit [Quit: alessioigor]
<JPEW>
e.g. a postfunc or something
alessioigor has joined #yocto
<qschulz>
JPEW: can't you have a do_build postfunc that reads the content of WORKDIR/deploy?
GNUmoon has quit [Read error: Connection reset by peer]
<JPEW>
qschulz: That won't work with sstate I think
<JPEW>
You need the SPDX to be included in the sstate archive with the deployed artifacts basically
<JPEW>
I think anyway
<rburton>
yeah
<qschulz>
but don't you have the same issue with the normal packages then?
<qschulz>
because there's no guarantee the user will only install in do_install
<qschulz>
(well, I haven't followed anything of the SPDX support in Yocto so I am probably way off :/)
<rburton>
JPEW: i want to figure out why tf-a builds dont have all the 'generated from' stuff in: tf-a-dbg should contain a .elf of the firmware with debug symbols in, so it should be able to
<JPEW>
Normal packages have a well-formed manifest, so we can do the SPDX creation in a separate task
<JPEW>
(as separate task that is also sstate that is)
xmn has joined #yocto
<JPEW>
We might be able to do that with deploy if there is a well-formed manifest; maybe I'm just unaware of one?
<JPEW>
Also, harder because it's not always do_deploy
<JPEW>
rburton: Ya, probably the path mapping
<JPEW>
I think it has trouble with anything that doesn't map exactly to the paths in the -src package
<rburton>
there isn't a defined mapping, but if you postfunc do_deploy then you can look at the deploy staging directory, right?
<JPEW>
rburton: Right
<JPEW>
The image SPDX file bascially does this, except it uses ROOTFS_POSTUNINSTALL_COMMAND, but the idea is the same
<qschulz>
should we create <package>-deploy :D ?
<JPEW>
qschulz: Sorry, I don't understand what you mean
<qschulz>
Well, me neither, that was a pretty nice brainfart
<LetoThe2nd>
yo dudX
sef has quit [Quit: Client closed]
sakoman has joined #yocto
mrpelotazo has quit [Ping timeout: 246 seconds]
Starfoxxes has quit [Ping timeout: 260 seconds]
Starfoxxes has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mrpelotazo has joined #yocto
Minvera has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
Starfoxxes has quit [Ping timeout: 265 seconds]
Starfoxxes has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]