contre has quit [Remote host closed the connection]
dtometzki has quit [Ping timeout: 240 seconds]
sakoman has quit [Quit: Leaving.]
pgowda_ has joined #yocto
peoliye has quit [Quit: Client closed]
peoliye has joined #yocto
thomasd13 has joined #yocto
wkawka has joined #yocto
adrian__ has joined #yocto
goliath has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
leon-anavi has joined #yocto
lowfi has joined #yocto
rfuentess has joined #yocto
mvlad has joined #yocto
ptsneves has joined #yocto
moto-timo has quit [Ping timeout: 276 seconds]
moto-timo has joined #yocto
qschulz has quit [Remote host closed the connection]
Schlumpf has joined #yocto
qschulz has joined #yocto
vladest has quit [Remote host closed the connection]
vladest has joined #yocto
lowfi has quit [Quit: Leaving]
mvlad has quit [Quit: Leaving]
mvlad has joined #yocto
<mihai>
anyone here had any success with finding a decent tool that can analyze or convert the spdx json image output?
Guest5 has joined #yocto
peoliye has quit [Quit: Client closed]
<ptsneves>
@jclsn i have seen this issue before. You will not be able to disable the state cache
<ptsneves>
i believe this is a bug and i will try to make a repro
<ptsneves>
did it happen you had a recipe with BBCLASSEXTENDS = "nativesdk" and then you removed the nativesdk leading to that error?
lexano has quit [Ping timeout: 248 seconds]
zeddii has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
paulg has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
marka has quit [Ping timeout: 255 seconds]
<jclsn[m]>
<ptsneves> "did it happen you had a recipe..." <- I don't know. It is a pretty old layer, which has been abandoned. It might just be deprecated in some way...
<jclsn[m]>
I think someone from openembbedded should fork and maintain this though. Having doom on a imx6 is very important ;)
<jclsn[m]>
It is just weird that it compiles fine, but the rootfs step fails
<wkawka>
Hi, can I use commands for packages which are already built and added as dependencies in do_install task for example?
<wkawka>
I'm trying to have a container already imported into balena (it is like docker but smaller)
<wkawka>
Rather than importing it manually after booting
xmn has quit [Quit: ZZZzzz…]
<qschulz>
wkawka: you cannot run target binaries on your building machine (different CPU architecture)
<qschulz>
you could use a balena-native or something similar I guess
<qschulz>
which would let you run balena natively on your building machine
<qschulz>
i don't know if it'll allow you to import a container from a native balena to run on a cross-compiled balena on your target
<wkawka>
I am thinking of another idea, rather than having container already imported, i can check if it is imported, if not just import it and delete tarball for exampl
<wkawka>
doing this by a script
<wkawka>
But having container already included in balena still would be better
frieder has joined #yocto
frieder has quit [Remote host closed the connection]
Baehrune has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
Baehrune has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
wkawka has quit [Quit: Client closed]
konny has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
Wouter01001 has quit [Remote host closed the connection]
Wouter01001 has joined #yocto
Piraty has quit [Quit: No Ping reply in 180 seconds.]
Piraty has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
<Schlumpf>
Is there a simple way to check if a yocto build is running? I need to know that in another script
nemik has quit [Ping timeout: 264 seconds]
nemik has joined #yocto
seninha has joined #yocto
rfuentess has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
<qschulz>
Schlumpf: pgrep -x bitbake?
<qschulz>
@all: congrats on the 4.0.2 release \o/
thomasd13 has quit [Ping timeout: 256 seconds]
<konny>
Hi, I have a multiconfig setup (based on latest dunfell) with the kernel and root image in separate configs and with mcdepends from the root image to the kernel. When building the root image do_populate_sysroot_setscene for ca-certificates (allarch) sometimes fails due to what looks like a race where the task for one config fetches the sstate from
<konny>
the network at the same time as the other config tries to extract the sstate before it has been completely fetched.
<konny>
Shouldn't bitbake ensure that the same sstate files are not used concurrently?
<Schlumpf>
@qsh
<Schlumpf>
qschulz: pgrep -f bitbake did the trick, thanks
sotaoverride has joined #yocto
eloi1 has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
eloi1 has quit [Client Quit]
eloi1 has joined #yocto
eloi1 has quit [Client Quit]
eloi1 has joined #yocto
Wouter01001 has quit [Remote host closed the connection]
Wouter01001 has joined #yocto
<JPEW>
mihai: I don't know of any tools to process the SPDX. We are an early generator of this amount and complexity of SPDX, so we are ahead of the tooling in some regard
rfuentess has joined #yocto
Wouter01001 has quit [Read error: Connection reset by peer]
Wouter01001 has joined #yocto
eloi1 has quit [Ping timeout: 256 seconds]
<RP>
konny: it is supposed to only run one task at a time where the same sstate hash is used
* RP
isn't sure if bugs in that were fixed since dunfell though
xmn has joined #yocto
<JPEW>
RP: I think some were, our local dunfell fork is carrying a few mc patches because we use it heavily
<ptsneves>
is it correct to set file://dir where dir is actually a directory and not a file?
<RP>
JPEW: I wonder if we should backport some?
<RP>
ptsneves: it can work I think, yes
olani has quit [Ping timeout: 276 seconds]
<JPEW>
RP: Maybe, I think they depend on the more invasive changes, which is why I didn't suggest it; let me see if I can get a list....
<qschulz>
ptsneves: it works but highly do not recommend
eloi1 has joined #yocto
sotaoverride has quit [Ping timeout: 272 seconds]
<ptsneves>
Thanks. I also have a big "disgust" of the file being used for directories as this catches the whole thing, and i believe it is still not well resilient to files with spaces or other funny characters
<konny>
Thanks for the info @RP. It looks like one thread is doing do_populate_sysroot_setscene -> sstate_setscene -> sstate_installpkg -> pstaging_fetch at the same as another thread is doing do_populate_sysroot_setscene -> sstate_setscene -> sstate_installpkg -> sstate_unpack_package for the same hash.
<mihai>
JPEW, thanks for confirming, I got the same feeling after trying out some tools out there
sakoman has joined #yocto
<RP>
JPEW: that looks like it would fix BBMASK issues but the rest look more like cleanups. Hmm :/
<RP>
konny: that info definitely helps. Do you have the exact failure? It should atomic move files into position so whilst that situation isn't ideal, I'm not sure it should break
Schlumpf has quit [Quit: Client closed]
wkawka has joined #yocto
<ptsneves>
Hey Hey. I have a question. In which situation do you find that this code is not fatal
<ptsneves>
> # The local fetcher's behaviour is to return a path under DL_DIR if it couldn't find the file anywhere else
<ptsneves>
bb.warn("Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR" % (d.getVar('PN'), os.path.basename(f)))
<ptsneves>
if os.path.exists(f):
<ptsneves>
this is in __init__.py fetcher and it basically means that if it finds a local file only in the DL_DIR it is ok, even if the file is not found anywhere else. Is this not the definition of unreproducible?
<konny>
RP: Some more info:
<konny>
12:15:27 NOTE: Running setscene task 76 of 2540 (.../sources/poky/meta/recipes-support/ca-certificates/ca-certificates_20211016.bb:do_populate_sysroot_setscene)
<konny>
12:15:27 NOTE: Running setscene task 87 of 2540 (mc:abc:.../sources/poky/meta/recipes-support/ca-certificates/ca-certificates_20211016.bb:do_populate_sysroot_setscene)
<konny>
12:15:27 NOTE: recipe ca-certificates-20211016-r0: task do_populate_sysroot_setscene: Started
<konny>
12:15:27 NOTE: recipe ca-certificates-20211016-r0: task do_populate_sysroot_setscene: Started
<konny>
12:15:27 ERROR: mc:abc:ca-certificates-20211016-r0 do_populate_sysroot_setscene: Error executing a python function in exec_func_python() autogenerated:
<konny>
12:15:27
<konny>
12:15:27 The stack trace of python calls that resulted in this exception/failure was:
<konny>
DEBUG: Executing python function do_populate_sysroot_setscene
<konny>
Saving to: ‘.../sstate-cache/21/86/sstate:ca-certificates:all-poky-linux:20211016:r0:allarch:3:218612773773d78700abfa2a5fe3018bf68dc1ad162c8f65ffcb7240a53aa1df_populate_sysroot.tgz’
<konny>
Unpack log excerpt:
<konny>
DEBUG: Executing shell function sstate_unpack_package
<RP>
ptsneves: I have wondered if we should make that fatal now
<RP>
ptsneves: the world used to be quite different in that regard
leon-anavi has quit [Quit: Leaving]
<ptsneves>
@RP Can i submit a patch raising an exception, or do you prefer a bb.fatal?
<RP>
ptsneves: I suspect a bb.fatal() will display better from a user perspective
<RP>
(it raises a BBHandledException() internally
<RP>
ptsneves: if you can show an exception displays ok, I'd be ok with that too
<ptsneves>
ok. Yes. Raising Exception shows the text in white so not ideal. I will do the bb.fatal then
<konny>
RP: That seems to solve the issue, thanks! Can it be backported to dunfell?
<ptsneves>
@RP "Unable to get checksum for %s SRC_URI entry %s: file could not be found" should also be fatal i guess. Which leads me to the question why does the file fetch return DL_DIR for localpaths at all?
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
pgowda_ has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
olani has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
Xagen has joined #yocto
<Xagen>
is there a way to see which recipe provides a particular executable?
rfuentess has quit [Remote host closed the connection]
<qschulz>
and then you can use oe-pkgdata-util lookup-recipe <pkg-name> I think
<qschulz>
or something like that
<qschulz>
to get the recipe
rfuentess has quit [Remote host closed the connection]
otavio has quit [Quit: Lost terminal]
vmeson has joined #yocto
<Xagen>
qschulz: thanks
<gstinocher[m]>
good morning all. I am pausing workers to begin the maintenance process
mckoan is now known as mckoan|away
adrian__ has quit [Ping timeout: 244 seconds]
vmeson has quit [Ping timeout: 256 seconds]
sotaoverride has joined #yocto
kscherer has joined #yocto
sgw has quit [Quit: Leaving.]
sgw has joined #yocto
sgw has quit [Ping timeout: 255 seconds]
<RP>
konny: you'd need to disucss with sakoman
<RP>
ptsneves: offhand I don't remember
<sakoman>
konny: Yes, I can backport that if testing doesn't reveal any regressions
<konny>
sakoman: Thanks!
jclsn_ has quit [Ping timeout: 244 seconds]
mvlad has quit [Remote host closed the connection]
pabigot has quit [Quit: Leaving.]
Ram-Z has joined #yocto
pabigot has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
pabigot has quit [Remote host closed the connection]
pabigot has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
jclsn_ has joined #yocto
<derRichard>
is SSTATE_MIRRORS supposed to work correcly with recipes that use AUTOREV? it looks like it uses sometimes a cached sstate entry despite a newer version is avaiable in the source repo (svn in my case).
Vonter has quit [Quit: WeeChat 3.5]
<derRichard>
IMHO SSTATE_MIRRORS and AUTOREV cannot be used together in a sane way, but dunno.. :-)
Vonter has joined #yocto
<JaMa>
do you have SRCPV included in PV?
<derRichard>
hm, good question. a missing SRCPV could explain the problems
<landgraf>
looks like dropbear-openssh conflict is not fixed in kirkstone completely :-/
<landgraf>
- package dropbear-2020.81-r0.cortexa53_crypto conflicts with openssh provided by openssh-8.9p1-r0.cortexa53_crypto
<derRichard>
JaMa: SRCPV is set to AUTOREV
<derRichard>
hm, looks PV is wonky
<derRichard>
JaMa: thx! will retest. might take some time as the problem triggers only sometimes
ejhsrp has joined #yocto
<JaMa>
landgraf: is it caused by PN-ptest packages for you?
ejhsrp has left #yocto [#yocto]
<landgraf>
JaMa: - package openssh-ptest-8.9p1-r0.cortexa53_crypto requires openssh, but none of the providers can be installed
<landgraf>
right however fedora 36 has 8.8 so they backported this patch and this might confuse people. dunno
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<JaMa>
yes, it's confusing, but the same issue exists on other images as well (not only built with OE), so people will have to get used to it (use -O whenever you see something like "ash: /usr/libexec/sftp-server: not found")
<JaMa>
e.g. openwrt images also don't include sftp by default, my cameras, security system etc all have some dropbear without sftp
<JaMa>
if someone goes through all the QA tests to use -O for scp as well, then maybe this could be dropped by default, until then I'm using BAD_RECOMMENDATIONS