LetoThe2nd changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Community: https://www.yoctoproject.org/community | IRC logs: http://irc.yoctoproject.org/irc/ | Having difficulty on the list, with someone on the list or on IRC, contact Yocto Project Community Manager Letothe2nd | CoC: https://www.yoctoproject.org/community/code-of-conduct
Jones42 has quit [Ping timeout: 252 seconds]
Jones42 has joined #yocto
Saur_Home35 has joined #yocto
Jones42 has quit [Ping timeout: 264 seconds]
Saur_Home82 has quit [Ping timeout: 256 seconds]
sotaoverride has quit [Ping timeout: 244 seconds]
sotaoverride has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
goliath has quit [Quit: SIGSEGV]
Daanct12 has joined #yocto
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01002 has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
davidinux1 has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
davidinux1 has joined #yocto
cabazon has joined #yocto
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
cabazon has quit [Quit: Client closed]
sotaoverride has quit [Ping timeout: 248 seconds]
sotaoverride has joined #yocto
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
Daanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #yocto
Daanct12 has quit [Ping timeout: 245 seconds]
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #yocto
Articulus has joined #yocto
prabhakalad has quit [Ping timeout: 255 seconds]
prabhakalad has joined #yocto
Jones42 has joined #yocto
sotaoverride has quit [Ping timeout: 260 seconds]
rbox has quit [Quit: ZNC 1.9.1 - https://znc.in]
sotaoverride has joined #yocto
Daanct12 has joined #yocto
rbox has joined #yocto
Daanct12 has quit [Ping timeout: 260 seconds]
Daanct12 has joined #yocto
Daaanct12 has joined #yocto
Daanct12 has quit [Read error: Connection reset by peer]
florian_kc has joined #yocto
florian_kc is now known as florian
Jones42 has quit [Ping timeout: 252 seconds]
druppy has joined #yocto
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01002 has joined #yocto
Wouter01002 has quit [Client Quit]
Wouter01002 has joined #yocto
sotaoverride has quit [Ping timeout: 246 seconds]
sotaoverride has joined #yocto
rob_w has joined #yocto
rob_w has quit [Remote host closed the connection]
rob_w has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
dmoseley has quit [Ping timeout: 252 seconds]
dmoseley_ has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
rfuentess has joined #yocto
zpfvo has joined #yocto
ehussain has joined #yocto
aduskett has joined #yocto
Kubu_work has joined #yocto
thomasxweber has joined #yocto
<thomasxweber> good morning. is this channel also for yocto user questions?
Jones42 has joined #yocto
<mcfrisk> thomasxweber: yes
Tyaku has joined #yocto
Daaanct12 has quit [Ping timeout: 260 seconds]
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
<thomasxweber> should sstate cache be disabled, when building a release image?
Daanct12 has joined #yocto
mckoan|away is now known as mckoan
<mckoan> thomasxweber: no. Why you have this doubt?
<mckoan> khem: thx. Actually I ended using sysbench. What do you think about it?
<thomasxweber> mckoan: are the sources necessary, if the result is already in sstate available? will the source be downloaded then?
<mckoan> thomasxweber: sources are in DL_DIR
<mckoan> the downloaded ones I mean
<thomasxweber> mckoan: someone deletes the source from DL_DIR,  SSTATE_DIR contains artifact from former build; so will the source file be downloaded?
leon-anavi has joined #yocto
<mckoan> thomasxweber: in that case the task do_fetch won't be able to find the sources, therefore will download them again
<thomasxweber> mckoan: thanks
florian has quit [Ping timeout: 245 seconds]
thomasxweber is now known as swirl
yannd has joined #yocto
<RP> swirl: to be clear, if the sstate is present but the files in DL_DIR are not, you would have to rerun do_fetch to get them back. do_fetch would not run if everything needed was in sstate
<ak77> while at it... how to remove files in DL_DIR that are not needed anymore ? e.g. no recipe references them anymore
<landgraf> ak77: DL_DIR can be shared between machines/distro/etc
<ak77> yes. ok. but during development, versions get bumped ... there are lefovers
<landgraf> ak77: how do you know this "leftovers" are not used by different version? :)
florian has joined #yocto
guest20 has joined #yocto
<ak77> ok. fair enough. another one, i have in memory that I tried to move DL_DIR, and updated it in local.conf, and it triggered rebuild. is that so ?
<ak77> shouldn't be if, as RP said, sstate has everything it needs. ...
<ak77> what if I move sstate ?
<ak77> (black friday is near... :))
<RP> ak77: were you using hash equivalence?
* ak77 scratches head...
<RP> moving DL_DIR and SSTATE_DIR wouldn't matter. Losing a copy of the hash equivalence mapping in the build directory would
<guest20> Can anyone please tell me how to resolve these issues
<guest20> Problem 1: package packagegroup-core-standalone-sdk-target-1.0-r0.cortexa7t2hf_neon from oe-repo requires libstdc++-dev, but none of the providers can be installed
<guest20> package space-monitor-1.0-r0.cortexa7t2hf_neon from oe-repo requires busybox-cron, but none of the providers can be installed
ehussain has quit [Ping timeout: 252 seconds]
aduskett has quit [Ping timeout: 252 seconds]
<rburton> ak77: use find to delete files that haven't been accessed for six months, or something
<guest20> rburton could you please help me with my question
aduskett has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
sotaoverride has quit [Ping timeout: 260 seconds]
sotaoverride has joined #yocto
<Jones42> Guest20: try to move step by step. find the providers of busybox cron, try to build them alone (bitbake busybox), check the logs in the "temp" directory for errors
<Jones42> Guest20: 'find' and ''
<Jones42> Guest20: 'find' and 'rgrep' (i like 'ack') are your friends here
<ak77> RP, rburton: tnx
<Jones42> Guest20: you find the log- and run-files of each recipe here: https://docs.yoctoproject.org/ref-manual/structure.html#build-tmp-work-tunearch-recipename-version
<Jones42> and while I'm already here: quick sanity check: Our customer messes with "IMAGE_INSTALL" in his layer.confs. There's no sane reason to do that, right?
<RP> Jones42: it depends what you're trying to do but it would be a best practise, it is potentially very confusing
<Jones42> RP: thanks for the "somewhat-confirmation" :-) - I'm tring to clean up a big project and there are a lot of cases where they just add the packages provided by the layer to IMAGE_INSTALL.
<rburton> yeah that's literally one of the DO NOT DO THIS slides in my 'how to write a bsp' presentation this summer
<Jones42> rburton: oh, great! I've seen the talk but must have forgotten that point.
<Jones42> Good to have some "authority" I can refer to while I'm digging their whole structure over :-)
<Jones42> also I've just figured out that their way of working also conflicts with core-image.bbclass...
<ak77> mcfrisk: thank you for answers on "dobule lives". when is the next LTS expected?
<ak77> hmm. looks like every two years.
<rburton> yes
<ak77> yes. looking at this page now.
<rburton> april 26 is the next lts as the latest lts was april 2024
<ak77> "nice" product i am working on should be release in april 25 :)
<RP> Jones42: unconditionally adding is insane. I wasn't sure what "messes with" meant
<Jones42> RP: ah, sorry for not being more precise. I thought that IMAGE_* should not be modified by layer.conf in general. But I guess there's always exceptions to any rule
<rburton> layer.conf shouldn't really touch anything apart from the layer setup and _maybe_ HOSTTOOLS
<RP> Jones42: I'm a supported of letting people innovate and do interesting things but that kind of change which can be done better elsewhere doens't make sense
<RP> rburton: please not HOSTTOOLS :(
<RP> we need recipe specific host tools
<guest20> Jones42 rburton thank you very much for your inputs
guest20 has quit [Quit: Client closed]
Daanct12 has quit [Quit: WeeChat 4.4.3]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
<LetoThe2nd> long shot, but: is there a way, possibly through some variable, to reference a file in a layer in local.conf, without knowing the absolute position of the layer directory? Like pseudocode MAGIC_FILE = "${TOPDIF_meta-demo}/files/magic-file"
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
<kanavin> LetoThe2nd, what's the use case?
jclsn has quit [Quit: WeeChat 4.4.3]
jclsn has joined #yocto
Wouter01002 has joined #yocto
<LetoThe2nd> kanavin: demoing a pipeline where such an asset is required. if the asset can be bundled into a "layer" like this, and then be set up using the usual layer setup tools, then I just think it is more convenient and reproducible than saying "place the absolute path on your machine into this variable"
<kanavin> LetoThe2nd, but where and how is it used? Typically if something is used in a recipe, then you add it to SRC_URI, and place it next to the recipe file
sotaoverride has quit [Ping timeout: 260 seconds]
<LetoThe2nd> kanavin: its used in a recipe, but an upstream one. so yeah, the next best way would be to use bbappends.
sotaoverride has joined #yocto
<kanavin> RP: I'm rather enjoying sane rpm times again, this glibc-locale thing been bothering me for months
<rburton> LetoThe2nd: so yesterday i had a colleague rant at me about how mender only supports LTS releases
<LetoThe2nd> rburton: ya I can also tell you which colleague :-)
<LetoThe2nd> rburton: updating master-next for him is on my to-do list
<rburton> :)
<RP> kanavin: I had noticed rpm was taking longer, nice find in fixing it!
rob_w has quit [Remote host closed the connection]
Saur_Home35 has quit [Quit: Client closed]
Saur_Home35 has joined #yocto
<Scorpi> Hi, I want to add nodejs to the SDK. Am I right that I need to add nodejs-nativesdk the package list of the SDK?
<mcfrisk> that enables running nodejs natively in SDK environment. "nodejs" would enable using target nodejs in SDK.
<RP> Scorpi: nativesdk-nodejs too btw, nativesdk is a prefix
<Scorpi> mcfrisk: I wand to be able to build nodejs related projects using npm in the SDK
<Scorpi> RP: oops, thanks
<mcfrisk> Scorpi: for target or for the SDK environment?
<Scorpi> mcfrisk: for target
* RP doesn't remember how node works for cross builds
<mcfrisk> for building, it could be that the nativesdk-nodejs works. But there can be issues if something is architecture dependent
<Scorpi> RP: this was my error (prefix, not suffix). Now I need to adjust the nodejs dependencies to provide the nativesdk part, too
swirl has quit [Quit: Client closed]
cyxae has joined #yocto
yannd has quit [Remote host closed the connection]
goliath has joined #yocto
ddee has joined #yocto
florian_kc has joined #yocto
jclsn has quit [Quit: WeeChat 4.4.3]
sotaoverride has quit [Ping timeout: 264 seconds]
sotaoverride has joined #yocto
jclsn has joined #yocto
<Scorpi> mcfrisk: actually, the build produces binaries that use /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2 as the loader
florian_kc has quit [Ping timeout: 252 seconds]
rob_w has joined #yocto
Xagen has joined #yocto
ddee has quit [Ping timeout: 256 seconds]
<RP> Scorpi: if that isn't what you want, you're after something "cross-canadian" in our recipe namespace
<rburton> zeddii: fyi 22aaaa7a1a732a5288aa4a5785a77b6895959134
<rburton> i'll send a patch
<LetoThe2nd> not sure if I'm misunderstanding things, but to me it sounds like overlayfs essentially is a dance around four directories, and not something one could lay over a full rootfs filesystem, right?
CrazyGecko has quit [Quit: Konversation terminated!]
<rburton> zeddii RP: patch sent
florian_kc has joined #yocto
Saur_Home99 has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
Saur_Home35 has quit [Ping timeout: 256 seconds]
<RP> rburton: thanks
Saur_Home17 has joined #yocto
Saur_Home28 has joined #yocto
Saur_Home99 has quit [Ping timeout: 256 seconds]
Saur_Home17 has quit [Ping timeout: 256 seconds]
Saur_Home16 has joined #yocto
rob_w has quit [Ping timeout: 272 seconds]
Saur_Home28 has quit [Ping timeout: 256 seconds]
<khem> mckoan:sysbench does decent job too especially on smaller systems, it has less deps
<mckoan> khem: thank you again
rfuentess has quit [Remote host closed the connection]
<RP> JPEW: I meant ask - the SPDX ID issue keeps corrupting builds when we change it. Are there manual dependencies we can add with SPDX functions to avoid this?
<JPEW> SPDX 2 or 3?
<RP> JPEW: 3
<JPEW> RP: I thought we had fixed those, sorry. Is there a bugzilla or logs I can look at
<RP> JPEW: https://valkyrie.yoctoproject.org/#/builders/29/builds/487 was a failing build and it has "contaminated" mathieudb's following builds in painful ways
<JPEW> k
aduskett has quit [Quit: Konversation terminated!]
<JPEW> K, I'll take a look
<RP> JPEW: some of these are with Hongxu's patches but even when we remove them, the issues then persist
<JPEW> I think some dependency is missing
<RP> JPEW: that is my guess too
<JPEW> Hongxu's patches are only fixes for when SPDX_INCLUDE_SOURCE = "1", which we don't do on the AB because it's _huge_
<JPEW> Yes that one is fine. I need to better understand the other patches that were sent though.... haven't been able to sit and look closely yet
<RP> JPEW: somehow those patches do break on the autobuilder though
<JPEW> RP: Ya, IIUC they are attempts to fix SPDX_INCLUDE_SOURCE, but they are a little invasive so I'm not terribly suprised
<RP> JPEW: the dependency issue does seem like something we should fix regardless though - the issues shouldn't persist when the patches are dropped
<RP> JPEW: I don't want to have to bump the sstate ABI number due to testing some patches :(
<JPEW> Ya. I think if we can find the missing dependency, it will (hopefully) fix the problem
<RP> JPEW: I hope so. I think you said it was due to the dependency code not being able to look inside the dynamic class code
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
zpfvo has quit [Remote host closed the connection]
<Scorpi> RP: sorry, I did not get this. What is this "recipe namespace"?
<Scorpi> RP: my problem is that the build process in nodejs builds binaries that are executed later in the build process, but they are not native
<Scorpi> RP: nodejs-native works, nativesdk-nodejs is broken
Articulus has quit [Quit: Leaving]
PhoenixMage has quit [Ping timeout: 260 seconds]
leon-anavi has quit [Quit: Leaving]
<khem> todays master I am seeing - https://0x0.st/XnGJ.txt
florian_kc has joined #yocto
mckoan is now known as mckoan|away
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
<Saur_> zeddii: Was it intentional to tag meta-virualization with Yocto tags (yocto-5.0.5 and scarthgap-5.0.5)?
<zeddii> nope. not sure where they came from. I don't do any tagging. I'll remove them.
<zeddii> hmm. none of my meta-virtualization layers have any tags
<zeddii> oh. they aren't even ones I created.
* zeddii deletes them with malice
<zeddii> I'm a little bit concerned they could even create those.
<khem> reverting it helped the build
druppy has joined #yocto
sotaoverride has quit [Ping timeout: 276 seconds]
sotaoverride has joined #yocto
brrm has quit [Read error: Connection reset by peer]
druppy has quit [Ping timeout: 252 seconds]
GNUmoon has quit [Ping timeout: 260 seconds]
prabhakalad has quit [Quit: Konversation terminated!]
<RP> zeddii: it was probably done with good intent to say that commit was tested as part of the 5.0.5 release
<RP> halstead: why did we start creating meta-virt tags?
<halstead> RP: Chee Yang sent a request to tag it. I almost double checked with you but went ahead.
<halstead> zeddii: Should I remove the tag and avoid that in the future?
<RP> halstead: I don't think release engineering should be touching layers "we" aren't the maintainers for without agreement with the maintainers
<halstead> RP: Absolutely. This is my mistake.
<halstead> zeddii: I pushed the tag for the release engineer using my access. He wouldn't be able to do it himself.
GNUmoon has joined #yocto
<halstead> zeddii: It will not happen again. My apologies.
<RP> halstead: no harm done, it is just a tag
<halstead> Thanks RP.
<RP> except maybe zeddii's hair colour, I know mine is struggling too :)
<rburton> khem: oh if llvm-objcopy is terrible that's really going to annoy me
<khem> its not a complex tool
<khem> so I will be surprised
<rburton> also i wish subprocess should show at least some of stdout/stderr in the exception
Kubu_work has quit [Quit: Leaving.]
<RP> rburton: we try and patch that in :/
cyxae has quit [Quit: cyxae]
<rburton> yeah i wrote that. its in oeqa, we should just shoehorn it into bitbake so its global
<RP> rburton: see def _print_exception(t, value, tb, realfile, text, context): in lib/bb/utils.py ;-)
<RP> the if isinstance(value, subprocess.CalledProcessError) and value.output:
Wouter01002 has quit [Quit: The Lounge - https://thelounge.chat]
<rburton> khem: ah for some reason with clang systemd doesn't write the dlopen notes or something
Wouter01002 has joined #yocto
<khem> its possible, although that could be a different problem
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton> ah no it just behaves differently
<rburton> binutils doesn't error if it can't find the segment
prabhakalad has joined #yocto
<rburton> khem: remove check=True from the subprocess.run in dlopen-deps.inc
<rburton> i have a patch with a nicer comment that i'll post shortly
<khem> ok
<rburton> hm
<rburton> packages/cortexa57-poky-linux/systemd/libsystemd-shared: RRECOMMENDS: removed all items "libzstd (['>= 1.5.6']) libkmod (['>= 33'])"
<rburton> packages/cortexa57-poky-linux/systemd/systemd-dbg: PKGSIZE changed from 84037600 to 61126112 (-27%)
<rburton> packages/cortexa57-poky-linux/systemd/systemd-dev: RRECOMMENDS: added "libgcc-dev"
<rburton> packages/cortexa57-poky-linux/systemd/libsystemd: RRECOMMENDS: removed all items "libzstd (['>= 1.5.6'])"
<rburton> packages/cortexa57-poky-linux/systemd/systemd-src: PKGSIZE changed from 25136362 to 279312 (-99%)
<rburton> that's unexpected
<rburton> is -src packaging with systemd broken?
Ad0 has quit [Ping timeout: 252 seconds]
druppy has joined #yocto
<rburton> and of course llvm's objcopy behaves differently
Ad0 has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
<RP> rburton: of course it does :/
<rburton> its even weirder
<rburton> its writing the file but the f.read() doesn't see the content
<RP> stdout vs err?
<rburton> nope, its writing to a file
<RP> fair enough, I don't have the context :)
* RP should ignore this
sotaoverride has quit [Ping timeout: 260 seconds]
<rburton> i do with tempfile.NamedTemporaryFile() as f: and then subprocess.run() to write to f.name, and then return f.read()
<rburton> for some reason with binutils that works but with llvm's objcopy it doesn't see any content
<rburton> looks like with open(f.name) as f2: return f2.read() works
sotaoverride has joined #yocto
<RP> rburton: I'd guess llvm is replacing the file so the fd is invalid
<RP> replaces the file vs binutils changing the contents
Xagen has joined #yocto
vthor has quit [Read error: Connection reset by peer]
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
rber|res has joined #yocto
druppy has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
Saur_Home16 has quit [Quit: Client closed]
Saur_Home16 has joined #yocto
jmiehe has joined #yocto