<vvn>
what's your opinion on installing packagegroups explicitly or mapping them to image features? (i.e. IMAGE_INSTALL += "packagegroup-foo-bar" vs. IMAGE_FEATURES += "foo-bar")
jclsn0 has quit [Ping timeout: 248 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 248 seconds]
<moto-timo>
I like the organization of packagegroups, but I have experienced some poorly defined odd behavior... where a change in a packagegroup did not cause a rebuild. I'm somewhat inclined to vote for IMAGE_FEATURES...
<moto-timo>
NOTE: if I had some better reproducers for the "odd behavior" I would have shared them... basically a Heisenbug. You can either know what it is or when it happens.
jclsn0 has joined #yocto
<moto-timo>
vvn: and I appreciate your support :)
jclsn0 has quit [Ping timeout: 248 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 246 seconds]
jclsn0 has joined #yocto
starblue has joined #yocto
sakoman has quit [Quit: Leaving.]
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
goliath has quit [Quit: SIGSEGV]
jclsn0 has quit [Ping timeout: 272 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 248 seconds]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 256 seconds]
jclsn0 has joined #yocto
sakoman has joined #yocto
jclsn0 has quit [Ping timeout: 248 seconds]
<moto-timo>
In the dead of night, the cobbler elves come out and make amazing shoes.
jclsn0 has joined #yocto
jclsn0 has quit [Quit: Ping timeout (120 seconds)]
jclsn0 has joined #yocto
jclsn0 has quit [Ping timeout: 248 seconds]
jclsn0 has joined #yocto
Wouter0100 has quit [Ping timeout: 248 seconds]
kevinrowland has quit [Ping timeout: 250 seconds]
Wouter0100 has joined #yocto
<JaMa>
moto-timo: teach the elves to make the ponny you wanted :)
<eFfeM>
Hi, I am trying to build with BB_NO_NETWORK but I get this error:
<eFfeM>
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY)
<eFfeM>
SRCREV_pn is set
<eFfeM>
nevermind, I think I already got it; poroblem is as usual between chair and keyboard :P
<eFfeM>
Hmm, I still seem not to get it. I do a fetch all from a local mirror using BB_FETCH_PREMIRROR_ONLY, I pinned all pn's using the buildhistory-collect-srcrevs script and put them in my conf; however even after fetching all; if I refetch with BB_NO_NETWORK it still fails for a recipe with autorev
<eFfeM>
with BB_NO_NETWORK even when pinning PN it still wants to do a git ls-remote
<eFfeM>
an I doing something wrong? or is there something I am missing?
<jclsn>
landgraf: It still doesn't work with PREMIRROSl although the errors are different https://pastebin.com/UPhqmF4Z
<dwagenk>
Hey there. Can someone here help me understand this problem? I'm building with kas container (v 3.0.2) and am using the uninative.bbclass (`UNINATIVE_VERSION="3.5"`, through basing my own distro on poky). Several nativesdk packages fail to build due to `#include <crypt.h>`. I can work around this by setting `ASSUME_PROVIDED:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/a964baabbe6260f94cac370f559dc9e8d8de8546)
<dwagenk>
> <@dwagenk:tchncs.de> Hey there. Can someone here help me understand this problem? I'm building with kas container (v 3.0.2) and am using the uninative.bbclass (`UNINATIVE_VERSION="3.5"`, through basing my own distro on poky). Several nativesdk packages fail to build due to `#include <crypt.h>`. I can work around this by... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/446108ab7dbd449716e0e8c3afd9b3838cf9a6a7)
zen_coder has joined #yocto
<LetoThe2nd>
zen_coder: sorry, didn't see your TOOLCHAIN_HOST_TASK question yesterday.
<jclsn>
landgraf: Meaning the files on my server are defected?
<jclsn>
I will compare
<landgraf>
jclsn: or something wrong with checksum itself. I'm not familiar with this part of the code
<dwagenk>
Ah, my problem dissolved. The affected recipes didn't properly set their `DEPENDS += "virtual/crypt"`. The `ASSUME_PROVIDED` thing was not really the cause/fix. Sometimes posting the question to IRC is enought o fix a problem :-)
<wyre>
I'm trying to install a single built deb with apt-get ... but apt-get it's not able to do it https://bpa.st/SC4A I'm guessing this is because some mismatch between the .deb name and the debian/control file inside of it, probably some problem in my recipe with PV and PKGV? https://bpa.st/JSIQ
<wyre>
the problem was the .deb file aren't readable by _apt user because of it was placed at /root (and /root has 700 perms)
SpicyChimera has joined #yocto
SpicyChimera has quit [Client Quit]
Guest60 has joined #yocto
<Guest60>
Hello everyone. Is it possible to use pip on Yocto (on runtime)?
<LetoThe2nd>
Guest60: possible,? yes, its only software. sensible? depends.
<LetoThe2nd>
(hint: probably not)
<Guest60>
Would devtool be a better option to install Python packages on runtime?
<qschulz>
Guest60: what is your usecase so we could point you in the right direction :)
<Guest60>
We are using Yocto on a Variscite DART-MX8M-PLUS which we will be using for Computer Vision stuff and sometimes we need to add Python packages without rebuilding the image
<qschulz>
Guest60: for debugging purposes right? because in the end it should be part of the image
<Guest60>
Yes
<qschulz>
Guest60: in that case, devtool probably makes more sense since you anyway are going to need a recipe for it
<Guest60>
Okay, thanks!
<qschulz>
Guest60: also, you'd need to write a recipe for pip which might not be straightforward
<LetoThe2nd>
image_license.manifest gives me the really shipped license information, license.manifest gives me all licenses involved in the build, rgiht?
<Saur[m]>
LetoThe2nd: No. image_license.manifest contains licenses for deployed tasks, e.g., the bootloader. See `license_deployed_manifest()` in license_image.bbclass.
<Saur[m]>
So typically, if you want the licenses for everything in an image, you want everything from both those manifests.
<LetoThe2nd>
Saur[m]: ah okay got it. thanks!
gsalazar has joined #yocto
goliath has joined #yocto
simonew has quit [Quit: Client closed]
leon-anavi has quit [Ping timeout: 246 seconds]
leon-anavi has joined #yocto
leon-anavi has quit [Client Quit]
rob_w has quit [Remote host closed the connection]
<dirtyflag>
hi and good friday all. Is there a way to avoid a bbappend to be processed ? Don't want to comment lines by #
<rburton>
no
<kroon>
BBMASK ?
<rburton>
hm yeah maybe that would work
leon-anavi has joined #yocto
gsalazar has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
BBMASK works.
<LetoThe2nd>
i mean, BBMASK should be the same mechanism as BBLAYERS_DYNAMIC, right? I've succesfully used that to filter out appends too.
prabhakarlad has quit [Quit: Client closed]
selff has joined #yocto
gsalazar has joined #yocto
<selff>
hi everyone. i cannot initialize coral in cm4, but there is no problem in rpi4. any ideas on what could be causing it?
kranzo has joined #yocto
<kranzo>
Hi, Is there a way do bundle all patches sources of an image into a folder/archive?
<rburton>
yes it took my machine over an hour to run the damn thing
<LetoThe2nd>
qschulz: its a hard life.
Minvera has joined #yocto
kranzo has quit [Quit: Client closed]
<RP>
rburton: didn't we enable that on the AB?
<rburton>
yes but this doesn't have an xskip in anymore
<rburton>
xfail, even
<rburton>
sorry should have said
GillesMM has quit [Remote host closed the connection]
<vvn>
If you want to describe your complete software stack in a packagegroup recipe, would you generally advice to have your packagegroup-product-base group depends on packagegroup-core-boot and packagegroup-base-extended or would you leave that to the recipe?
gsalazar has joined #yocto
<vvn>
Explicit is better I guess, and it makes it obvious that you are using the core packagegroups (and thus the MACHINE/DISTRO*_EXTRA_RDEPENDS/RRECOMMENDS variables)
<jclsn>
landgraf: I just tried uploading everything again and it still doesn't work. Another weird thing about the checksum error ist that the uninative bitbake is complaining about doesn't even exist. I deleted the whole folde and is hasn't been fetched again
<jclsn>
And when I fetch the same file manually with wget from Artifactory, the checksum is correct
<vvn>
smurray: khem: did you find a proper fix for wxwidgets? Actually I lied, I'm compiled qtwebengine with DISTRO_FEATURES +opengl -wayland -x11 -vulkan, so even more minimalist
argonautx has joined #yocto
<sotaoverride>
is there a way of figuring out what size a .xz decompresses to, without actually decompressing it?
sakoman has joined #yocto
<LetoThe2nd>
sotaoverride: xz --list and some magic? the actual size on disk would depend on the FS, though.
<RP>
rburton: that seems to add a lot of time to it then? or am I missing something?
<rburton>
RP: my qemu is fairly slow
kroon has quit [Quit: Leaving]
pbergin has joined #yocto
BhsTalel has joined #yocto
GLumen has joined #yocto
GLumen_ has joined #yocto
GLumen has quit [Ping timeout: 268 seconds]
amitk has quit [Ping timeout: 256 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
troth has quit [Ping timeout: 272 seconds]
Net147 has quit [Client Quit]
xmn has joined #yocto
<sotaoverride>
lzma python module doesnt seem to have an api for reading the uncompressed size for a .xz from the header.. trying to stick to some pythonic method of figuring out what size the .xz decompresses to for some unit tests.
troth has joined #yocto
<smurray>
vvn: I've started looking at wxwidgets, it does look like it supports Wayland now (so that could maybe be wired up in the recipe), but AFAICT they've hard-coded libglu use with OpenGL, and that requires x11
BhsTalel has quit [Ping timeout: 250 seconds]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
Net147 has quit [Client Quit]
Cezarus27 has joined #yocto
Cezarus27 has quit [Client Quit]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has quit [Remote host closed the connection]
GLumen_ is now known as GLumen
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
Net147 has quit [Remote host closed the connection]
dtometzki has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
dtometzki has joined #yocto
Net147 has quit [Client Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
<rburton>
i wonder why a build from YP sstate is building things like which and bash but reusing most of the public sstate
<RP>
rburton: do we build them on the autobuilder?
<rburton>
the ab does core-image-sato and i'm building core-image-base, so i'd have *thought* there was coverage
<smurray>
vvn khem: I've sent a patch for wxwidgets to oe-devel
rfuentess has quit [Remote host closed the connection]
<rburton>
hm
<rburton>
2022-04-08 15:44:02 - INFO - Bitbake still alive (no events for 600s). Active tasks:
<rburton>
2022-04-08 15:44:02 - INFO - /builds/engineering/yocto/meta-arm/work/poky/meta/recipes-connectivity/openssl/openssl_3.0.2.bb:do_package_write_rpm_setscene
<rburton>
2022-04-08 15:44:02 - INFO - /builds/engineering/yocto/meta-arm/work/poky/meta/recipes-devtools/gcc/gcc_11.2.bb:do_package_write_rpm_setscene
otavio has joined #yocto
<rburton>
RP: does the sstate fetch happen in the _setscene tasks?
<RP>
rburton: yes
<RP>
smurray: is it ok if I merge that connman-conf patch? I really want rid of that category of intermittent failure!
<RP>
rburton: anything in the logs?
<rburton>
RP: nope
<rburton>
i suspect its just downloading slowly for that run
<rburton>
i shall grab the task logs when the build is done and see if anything failed
<RP>
rburton: ps might show the commands it is running
<rburton>
too many layers, I can't do that
<RP>
rburton: fair enough, just an idea
<smurray>
RP: my concern there is that it seems like qemu target images are then specific to the runqemu imposed config, so maybe it needs to be documented somewhere?
<RP>
smurray: that has always really been the case though
<smurray>
RP: okay. We play a bit loose with that in AGL, as the config has been tweaked to allow booting them on real h/w, but if no one else cares, we'll just hack around this change
<smurray>
RP: I do wonder what benefit connman gives in the qemu images, though, there's no wifi, etc. for it to do anything with
<RP>
smurray: well, there is that. It was mainly to try and be more common with our other targets
<RP>
smurray: where that commonality is breaking our tests intermittently though...
<smurray>
RP: we could try to do something upstream to make it ip auto-config aware the way I believe systemd-networkd is, but that's not a today thing
<RP>
smurray: I'm definitely open to improving things and removing the need to do this. Right now I do think we need to sort the race issue though. I'm happy to do that in a way which minimises the impact on agl if we can though
<RP>
rburton: trying hard not to reply to the "try thing" patch
<smurray>
RP: push the change, and I'll tweak the AGL bbappend, if I remove our own do_install:append, our main.conf will still get picked up via FILESEXTRAPATHS
gsalazar has quit [Ping timeout: 240 seconds]
<RP>
smurray: ok, thanks
<rburton>
RP: i almost cut that all out
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 248 seconds]
leon-anavi has quit [Quit: Leaving]
manuel_ has quit [Quit: Leaving]
mckoan is now known as mckoan|away
<rfs613>
are the variable renames for inclusive language being done for older branches? dunfell does not seem to handle CVE_CHECK_IGNORE currently.
<RP>
rfs613: no, they're not
<rfs613>
RP: ok thanks
jmiehe has joined #yocto
* RP
wonders whether to diverge kirkstone and master
<kergoth>
Which page has the mapping from bitbake version to yocto release?
<kergoth>
oh nevermind, yocto releases
argonautx has quit [Quit: Leaving]
florian has joined #yocto
zen_coder has joined #yocto
<zen_coder>
In which file do I have to place "TOOLCHAIN_TARGET_TASK_append" ?
<rburton>
zen_coder: your local conf, or the image, depending on use-case
<zeddii>
zen_coder, and depending on the release/branch you are building, that may be a :append ...
<amahnui[m]>
Is there another directory that contains local.conf apart from that in the build/conf/local.conf
<amahnui[m]>
Tends there isn't because it was confusing to me, thinking there was one which I could add some special configurations which will be inherited each time I deleted the build directory and started bitbake again.
GNUmoon has quit [Ping timeout: 240 seconds]
florian has quit [Ping timeout: 260 seconds]
<kergoth>
amahnui[m]: no, that's it. but there are other files parsed, not just local.conf. see meta/conf/bitbake.conf and scroll down to the include lines
<zen_coder>
rburton: adding it to "build/conf/local.conf" had no effect
<amahnui[m]>
kergoth: thanks I see them now.
GNUmoon has joined #yocto
<rburton>
zen_coder: maybe you're using a new release which needs :append instead of _append
<kergoth>
RP: thought about allowing the use of f-strings but limiting their syntax to that of format()? would allow for the convenience of the format while still making it easy enough to switch to postponed evaluation with format() later if needed. i.e. https://pypi.org/project/flake8-complex-f-strings/. there's also https://pypi.org/project/f-yeah/
<kergoth>
s/of the format/of the syntax/
<kergoth>
(in bitbake, that is)
<kergoth>
I think either of those options would alleviate the concerns about it
Cezarus27 has joined #yocto
<kergoth>
Not a priority, obviously :)
<rburton>
kergoth: i think the biggest concern was ease of backporting changes to releases which don't support them
<rburton>
personally hell yes demand py3.7 for good f-strings and the improved asyncio support
<kergoth>
Hmm since f-yeah uses an f() function for it, we could probably backport equivalent functionality with format() + inspect
kevinrowland has joined #yocto
mvlad has quit [Remote host closed the connection]
florian has joined #yocto
Cezarus27 has quit [Quit: Client closed]
florian has quit [Ping timeout: 246 seconds]
zen_coder has quit [Ping timeout: 248 seconds]
<rfs613>
sakoman: around?
florian has joined #yocto
<sakoman>
rfs613: yes
<rfs613>
sakoman: oops, just when I wandered off...
<rfs613>
am working on CVE-2022-1271 which affects both gzip and xz.
<rfs613>
patches for xz are done, straightforward backport for both master and dunfell.
<rfs613>
for gzip, it seems like master should just update to newly-released 1.12 version.
<rfs613>
and gzip dunfell, is on 1.10, so i'll backport the fix. First attempt patched clean but fails to build, so I'll have to figure that out
<rfs613>
my question is, for gzip backport, there are multiple commits upstream, but only one of them is the actual fix. Are we okay to take just that one, or do we want all the 'bookkeeping' too?
hushmoney has quit [Read error: Connection reset by peer]
Minvera has quit [Remote host closed the connection]
florian has quit [Ping timeout: 268 seconds]
amitk has quit [Ping timeout: 248 seconds]
<sakoman>
rfs613: I usually just take the actual fix
<sakoman>
under the theory that the less changes the better
<rfs613>
sakoman: ok, sounds good. The build error is resolved, it was 'devtool build' playing some tricks (-Werror failure), which didn't happen when I just used bitbake with the patch applied.
<rfs613>
so I'll post them later, probably after kids asleep