ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
GLumen has quit [Ping timeout: 240 seconds]
kevinrowland has quit [Quit: Client closed]
tomzy_0 has quit [Quit: Client closed]
amahnui1 has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
Circuitsoft has joined #yocto
sakoman has joined #yocto
<khem> zeddii 5.15.36 has all the needed patches for kernel to build with gcc 12 at least known ones when do you plan to bring it in ?
goliath has quit [Quit: SIGSEGV]
<khem> rburton perhaps we need to set IMAGE_LINGUAS = "" for poky-tiny distro conf
<khem> it wad done in musl.conf which I have removed
<khem> regardless its perhaps logical to set it in distro config
olani has quit [Ping timeout: 276 seconds]
olani has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
<zeddii> khem: shortly. I do a weekly -stable update. I have a kernel queue ready to go, but there's some patches breaking qemuarm boot. Everything is stacked on that. I was waiting to see if jonmason had a tweak for me, but I'll send the queue, and then consider a temporary revert if it fails the AB.
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
mrnuke has quit [Quit: ZNC 1.8.2 - https://znc.in]
OutBackDingo has quit [Ping timeout: 276 seconds]
OutBackDingo has joined #yocto
bluelightning is now known as bluelightning_
bluelightning has joined #yocto
<zeddii> khem: I just sent .36 for my own build testing, I'll send the queue out on Thursday morning (assuming it all passes).
OutBackDingo has quit [Ping timeout: 272 seconds]
OutBackDingo has joined #yocto
bluelightning_ has quit [Quit: Konversation terminated!!!111]
dtometzki has quit [Ping timeout: 276 seconds]
kleist[m] has joined #yocto
mrnuke has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
olani has quit [Ping timeout: 250 seconds]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
kranzo has joined #yocto
thomasd13 has joined #yocto
kroon has joined #yocto
<LetoThe2nd> yo dudX
<thomasd13> RP, I applied your commit from yesterday: https://git.yoctoproject.org/poky/commit/?id=5bca57859b280f73b23247aac7dec6b05f48fde8 regarding the git ownership issue. However, I still have the same problem, but this time at do_rootfs task at my image.
<thomasd13> Should this patch fix ALL git ownership issues, or just for do_install tasks?
<thomasd13> morning LetoThe2nd
<LetoThe2nd> thomasd13: yo
mvlad has joined #yocto
<LetoThe2nd> RP: okay now where the heck is langdale??
rob_w has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
amahnui1 has joined #yocto
amahnui1 has quit [Client Quit]
amahnui1 has joined #yocto
<LetoThe2nd> early morning sigh. board vendor telling me "its a good thing to dynamically fetch the dts from some random github url during the build so we can change it on the fly!"
<RP> thomasd13: it should have fixed the issue
<RP> LetoThe2nd: obviously! :/
xmn has quit [Ping timeout: 246 seconds]
<thomasd13> RP, I inserted again my debug code at metadata_scm.bblass and it happens when ROOT is trying to execute the git process.
<thomasd13> If you are interested in that particular issue I can try different things, otherwise I would just give up and downgrade my local git client
<LetoThe2nd> RP: i wish for a clue bat right now.
<paulg> LetoThe2nd, agree with them and suggest to fetch kernel and userspace on the fly too.
<LetoThe2nd> paulg: don't get me started or it will be either running amok or be shitfaced by 10AM
<RP> thomasd13: this is when building an eSDK right?
<LetoThe2nd> but for some good news, we have a lot of cool new stuff lined up for the YPS, exciting new speakers and topics! schedule will be announced soon! \o/
<thomasd13> Yes. -c do_populate_sdk_ext
<LetoThe2nd> and OEDvM is also coming around
GNUmoon has quit [Ping timeout: 240 seconds]
<RP> thomasd13: we don't see this on the autobuilders which makes me wonder what is different about your setup
<thomasd13> RP, but im not up to date in respect of OE. My current state is about 9 month old. And I am on the TI distribution "arago"
<thomasd13> So I'm not sure, if this is not just a waste of your time
<thomasd13> RP okay, nevermind then. I'll do just the downgrade and go on ;)
<RP> thomasd13: it is as if the commands are being executed in a context where the export isn't set. Did you post a log showing where/when this happens?
<RP> thomasd13: I'm just struggling to understand the environment needed to reproduce it
Circuitsoft has quit [Quit: Connection closed for inactivity]
Guest21 has joined #yocto
tomzy_0 has joined #yocto
<thomasd13> RP, I can give you any logs, just let me get started with pastebinit
Guest21 has quit [Client Quit]
Guest21 has joined #yocto
<Guest21> can we use inherit extrausers in an image recipe ? After migration to kirkstone branch root password looks not correctly set with EXTRA_USERS_PARAMS
GNUmoon has joined #yocto
<thomasd13> RP just a question in between: Does your patch require, that the user downgraded their local git client to <2.30, to function properly?
kroon has quit [Remote host closed the connection]
kroon has joined #yocto
<LetoThe2nd> RP: thanks, will look at it. sorry was afk for a moment taking my norsk lesson :-)
<RP> thomasd13: no
<thomasd13> Which service you use to upload your paste? I have in mind pastebin.org is not welcomed
<LetoThe2nd> RP: hehe the symptoms look similar but I'm pretty sure its a completey unrelated thing (re SO)
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
<thomasd13> omg - how do I paste the output of bitbake correctly? using "bitbake <recipe> | pastebinit" does not contain the same output compared to run normal in console
<thomasd13> bitbake <recipe> | cat | pastebinit doesnt work either, also missing some lines at the end
frieder has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
hcg has joined #yocto
<qschulz> Guest21: extrausers is supposed to be inherited in image recipes... so it should work. if you can reproduce with vanilla poky only and have a non-working EXTRA_USERS_PARAMS, that'be super helpful
<qschulz> right now, you could still give us more clue by giving us the content of EXTRA_USERS_PARAMS to check if something obviously wrong
<qschulz> (e.g. since honister 3.4, the plaintext password option for usermod/useradd is not available anymore
<qschulz> "Hardcoded passwords are still supported but they need to be hashed, see examples in EXTRA_USERS_PARAMS."
florian_kc has quit [Ping timeout: 272 seconds]
<qschulz> mornin' folks :)
<RP> LetoThe2nd: fair enough, I couldn't remember the details but it did sound similar!
<thomasd13> I tried my best to copy & paste my workflow RP :D. This is "MACHINE=j7-processor bitbake viop-image -c do_populate_sdk_ext" https://dpaste.com//968H7EZ33
<thomasd13> The problem is, that something changes in metadata: https://dpaste.com/74BZ8Q3DC
<thomasd13> When I track down the METADATA_REVISION, I get this: https://dpaste.com/9ZKCU7NLP So I modified the metadata_scm.bbclass to print out the Exception
<RP> thomasd13: that latter log is much more helpful as I can start to see where the error is coming from. So the issue is buildtools-tarball changing rev
<Guest21> qschulz I'm using basic encrypted password : inherit extrausers core-image
<Guest21> IMAGE_ROOT_PASSWD = "\$5\$Jb.nfdgtrhQc\$8jITJIMxyzuA"
<Guest21> EXTRA_USERS_PARAMS = "usermod -p ${IMAGE_ROOT_PASSWD} root;"
<RP> thomasd13: is this dunfell?
<thomasd13> This is the exception which leads me to the git owner issue: https://dpaste.com/GWMJL72Y5
<qschulz> Guest21: in the example, there are single quotes around the IMAGE_ROOT_PASSWD variable
<Guest21> qschulz already tried ...
<thomasd13> RP, let me check if this is dunfell - I didnt update oe since 9 months i think
<thomasd13> Well, meta-openembedded is checked out at 7bd47ef6c
<thomasd13> oe-core at 7bd47ef6c
<thomasd13> sorry, i meant oe core at 9b83aefa9c
Schiller has joined #yocto
<thomasd13> Yes, it's dunfell
<thomasd13> RP, that commit (076d50da2e5652088d453d12eba0b5b445f29f85) is not in my local oe-core repository. Its that the probably the issue?
<RP> thomasd13: worth a try to see if it fixes things?
florian has joined #yocto
<thomasd13> RP thank you so much. Now the task goes further. No more git ownership issues. However it still fails, but that is another issue. Something with the EXTERNAL_TOOLCHAIN. I try to fix that myself
ilunev has joined #yocto
kanavin has quit [Remote host closed the connection]
<RP> thomasd13: progresss I guess. Sharing fuller logs helps as at way I could see the issue was the METADATA_REVISION variable and I know there were fixes to that recently
<thomasd13> RP I totally understand that. I would love to show you the full logs and console output. But bitbake -e produces a log which is 2,5 MB large, which fails to paste, and the redirect the bitbake output like "bitbake foo > log.txt" misses half of the console print
kanavin has joined #yocto
<RP> thomasd13: it wasn't bitbake -e I was thinking of. My point is that information helps
<thomasd13> Ok, I see. I try my best :)
florian_kc has joined #yocto
PaowZ has joined #yocto
<rburton> khem: the problem is musl-locales inherits gettext but that doesn't depend on gettext-native if NLS is disabled.
vladest has joined #yocto
argonautx has joined #yocto
adrian__ has joined #yocto
<LetoThe2nd> zeddii: so tell me, are you a "contributor in the OE dev team?"
hcg has quit [Quit: Ping timeout (120 seconds)]
olani has joined #yocto
pgowda_ has joined #yocto
goliath has joined #yocto
Schlumpf has joined #yocto
Schiller has quit [Ping timeout: 252 seconds]
frieder has quit [Remote host closed the connection]
Schiller has joined #yocto
<zeddii> LetoThe2nd: just read my email, and now that makes sense.
* zeddii considers how to maybe just not reply
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
kovalevsky has joined #yocto
prabhakarlad has joined #yocto
<qschulz> RP: ndec: michaelo: https://wiki.yoctoproject.org/wiki/Documentation_Review I tried to document the issues I had in mind wrt the docs
<qschulz> I assume the second issue might be better suited for Bugzilla
<qschulz> the first one, is a lightly redacted version of the mail I sent yesterday
<qschulz> it's meant to be a start of a discussion on how to improve the migration/release manuals
<qschulz> and have notes somewhere
xmn has joined #yocto
<RP> qschulz: added the one comment I had
amitk has joined #yocto
<vvn> hi there -- what is pulling in kernel-devicetree? I used RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = "" to get rid of the /boot artifacts in the rootfs (they are in an external boot partition) but the .dtb files are still there
<ndec> qschulz: cool, thanks for writing it down.. i will have a look!
vladest has quit [Quit: vladest]
vladest has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
leon-anavi has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
amahnui1 has quit [Quit: Connection closed for inactivity]
florian_kc has quit [Ping timeout: 240 seconds]
kroon has quit [Quit: Leaving]
sakoman has joined #yocto
amahnui1 has joined #yocto
rob_w has quit [Remote host closed the connection]
Starfoxxes has quit [Remote host closed the connection]
GLumen has joined #yocto
GLumen_ has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
kranzo has quit [Quit: Client closed]
Schiller has quit [Ping timeout: 252 seconds]
GLumen has quit [Ping timeout: 256 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
thomasd13 has quit [Ping timeout: 246 seconds]
Minvera has joined #yocto
<LetoThe2nd> zeddii: when has anything that i said or typed ever made no sense?... erm... wait. nevermind.
* zeddii is just learning about kernel configuration. so what do I know ?
amitk_ has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
amitk has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<kergoth> Hmm, seeing an issue where globally exported variables being added to the hashbase ignore vars isn't preventing them from being added to task dependencies and changing their basehash.
<kergoth> Specifically, meta-mingw32 changes quilt-native from a non-mingw32 build, even though it should only actually affect sdk recipes
olani has quit [Ping timeout: 272 seconds]
Schlumpf has quit [Quit: Client closed]
Piraty has quit [Quit: -]
Schlumpf has joined #yocto
Piraty has joined #yocto
<kergoth> Hmm, multiconfig multimachine builds in a single tmpdir can see gcc-source conflicts, probably due to work-shared, it's not isolated by package arch..
Guest21 has quit [Quit: Client closed]
pgowda_ has quit [Quit: Connection closed for inactivity]
<kergoth> Hmm, use of BBTARGETS breaks bitbake -e, since it's using the default targets for that too, so it becomes impossible to get the base 'bitbake -e' environment
<kergoth> (guessing most don't use bbtargets, i usually dont either, just figured i'd try it )
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
kovalevsky has quit [Remote host closed the connection]
Schlumpf has quit [Quit: Client closed]
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
saumya__[m] has quit [Quit: You have been kicked for being idle]
cperon has quit [Quit: You have been kicked for being idle]
<RP> kergoth: most people don't know BBTARGETS exists!
<RP> kergoth: master or an older release?
* RP changed something in flags recently but I can't remember what :/
florian_kc has joined #yocto
mckoan is now known as mckoan|away
<JPEW> kergoth: Ya, a lot of stuff depends on BBTARGETS. We were going to use it for our multiconfig "build selection", but too much broke when we changed it, so we switched to this class: https://gerrit.marine.garmin.com/code-review/c/platforms/linux/alchemy/+/275756
<JPEW> Oops wrong link
<JPEW> whisk uses this so that you can run `bitbake all-targets` and you get the default build targets (defined in the whisk.yaml file) for the currently configured product(s)
dlan has quit [Ping timeout: 248 seconds]
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
davidinux has quit [Quit: WeeChat 2.8]
skoech[m] has left #yocto [#yocto]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 246 seconds]
ilunev has joined #yocto
cmd has joined #yocto
prabhakarlad has quit [Quit: Client closed]
tomzy_0 has quit [Quit: Client closed]
<kanavin> halstead, https://git.yoctoproject.org/poky/stats/ no longer seems to react to 'stat options' :)
<kanavin> maybe not a major issue but it's fun to check now and then :)
<halstead> kanavin: Good catch. Probably caused when we changed cgit versions a few months ago.
<kanavin> halstead, right, it might be causing problems elsewhere then too
<halstead> kanavin: The year stats are disabled but if you know the args you can still get stats. https://git.yoctoproject.org/poky/stats/?period=m&ofs=50 Fixing this will have to wait until later.
<amahnui[m]> rburton: noticed that but I thought it was intentional
<halstead> kanavin: Would you email helpdesk@yoctoproject.org to log a request to fix this?
kroon has joined #yocto
Circuitsoft has joined #yocto
<kroon> RP, i think its a little unfortunate that there is now both a tag and a branch named "2.0" in bitbake :-/
<kroon> RP, maybe "2.0.0" would be more consistent as a tag name
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ilunev has joined #yocto
ilunev has quit [Ping timeout: 246 seconds]
<kergoth> JPEW: ah! i was going to use it for multiconfig targets too! :) that's a cool task, I like it, might use it myself
<vvn> Do you guys have this issue with the DM_UDEV_PRIMARY_SOURCE_FLAG flag not being set by cryptsetup or device-mapper, causing SYSTEMD_READY=0 and thus subsequent mount points to time out?
<vvn> It affect btrfs subvolumes or LVM even (https://bugs.gentoo.org/330651)
<vvn> I have no idea what to look for, especially since I have a pure-systemd initramfs+rootfs (so the same udev rules are present in both images, and initrd context is passed along to the final rootfs supposedly)
prabhakarlad has joined #yocto
<kergoth> class, rather
<vvn> rather than have yet another tool-specific config file and language, I would prefer a tool which assumes you have a site-specific metadata layer containing your multiconfigs and site.conf which depends on a build metadata layer such as meta-whisk
<vvn> but at least whisk kinda goes in that direction, providing a layer, not like kas
* vvn hates intrusive tools
davidinux has joined #yocto
ilunev has joined #yocto
<JPEW> vvn: That's actually how we use whisk... all our products conf fragements in whisk.yaml are a single line of "require conf/product/product-$NAME.conf"
<JPEW> But not to be too opinionated, it will let you put the whole config in the YAML file if you want :)
manuel1985 has joined #yocto
<manuel1985> Can I tell Yocto to do incremental package builds?
<manuel1985> That is, if I point the SRC_URI to another git tag which has only a few C files changed, can I tell it to reuse the cmake build dir from last time?
<kergoth> vvn: I'd agree with that, and I'm wondering if an official upstream yocto layer configuration and setup tool would better leverage existing capabilities in that way. I just wonder if avoiding yaml entirely would lose too much flexibility, or if inclusion of additional config files for configurations would be sufficient
<rburton> manuel1985: we typically wipe the build tree for safety
<manuel1985> Do I just have to tell yocto to not delete the working dir or is there mor to do?
<rburton> that would do it, yeah
<rburton> if you're using cmake it will clean the build tree, so disable that
<rburton> (see cmake.bbclass)
<manuel1985> rburton: Cool, thanks
ilunev has quit [Ping timeout: 276 seconds]
<vvn> kergoth: multiconfig and site.conf do it all already. I think it would be great that instead of making people write or copy a build/conf/local.conf, Yocto encourages people to define a project layer with all the build-specific crap: multiconfig + site.conf + various keys or certs files, etc. <git root>/meta would be an ideal path for a versioned project.
Starfoxxes has joined #yocto
mvlad has quit [Remote host closed the connection]
<kergoth> Hmm, gcc-cross-canadian is being rebuilt between different arm multiconfig configurations with different DEFAULTTUNEs, but the same arch. That shouldn't be necessary...
<kergoth> Ah, gcc-cross-canadian depends on glibc as you'd expect, and glibc's TUNE_CCARGS is different. I don't think gcc-cross-canadian is supposed to be rebuilt for different tunings, though, only architectures.
manuel1985 has quit [Ping timeout: 240 seconds]
kroon has quit [Quit: Leaving]
<kergoth> Ah, gcc-cross was made libc indpeendent and had the libc dep dropped, but not gcc-cross-canadian. dont see any reason we couldnt drop that one also and avoid this issue
florian_kc has joined #yocto
fitzsim has quit [Read error: Connection reset by peer]
<hushmoney> does anyone know how, from a client python module, how do i access recipe vars from the server?
<hushmoney> bitbake server
cmd has quit [Remote host closed the connection]
florian_kc is now known as florian
<kergoth> tinfoil python module in bitbake
cmd has joined #yocto
<hushmoney> i've been reading the tinfoil module all day and it's not clear to me how i can get a particular recipe's SRCREV variable
<hushmoney> is there an example you can point me to somewhere?
<hushmoney> i think i'm supposed to use TinfoilDataStoreConnector but it needs a dsindex parameter. where do i find this for the recipe i'm interested in?
<JPEW> I thought there were some public tinfoil examples somewhere....
cmd has quit [Remote host closed the connection]
<hushmoney> i would really appreciate that because i've been looking and i can't find diddly squat
cmd has joined #yocto
gsalazar has quit [Ping timeout: 272 seconds]
<JPEW> hushmoney: bitbake/bin/bitbake-getvar ?
<hushmoney> JPEW: ah-ha, that's not in my version. and i see it does exactly what i'm doing - calling tinfoil.parse_recipe. i was thinking that since tinfoil.prepare() already parsed recipes there must be some way to access cached data so that it doesn't have to be parsed twice
amitk_ has quit [Ping timeout: 246 seconds]
<JPEW> hushmoney: Ya, I've never needed to use tinfoil in a context where time mattered (usually in scripted batch jobs on CI), so I don't know how to get it to use the parse cache (maybe it does already, I'm not sure)
<hushmoney> i see. ok, thanks anyway
florian has quit [Ping timeout: 276 seconds]
<kergoth> remember that the up front recipe parsing is only used for runqueue creation, we don't keep all the parsed recipes in memory, only specifi cpieces of data needed to set up the run queue
<kergoth> hushmoney: ^
<kergoth> prepare with recipe parsing will get you things like taskdata and dependency info and stuff, but not full recipe metadata
jmiehe has joined #yocto
<hushmoney> kergoth: ok, i misunderstood. thanks for explaining
<kergoth> no problem
Minvera has quit [Remote host closed the connection]
florian has joined #yocto
<RP> kergoth: starting to wonder if we could compress and save it somehow...
frieder has joined #yocto
<JPEW> Has anyone had trouble with (traditional) SDK .sh files not seeming to transfer correctly between hosts? I'm wondering if the mix of text + binary data is causing us some headache
* JPEW wonders if the SDK should be base64 encoded
frieder has quit [Remote host closed the connection]
florian has quit [Ping timeout: 276 seconds]
argonautx has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
turkeykittin has joined #yocto
<turkeykittin> I've been trying to compile and install a python library with my own cpp bindings using pybind11 with bitbake + cmake. Ive been able to get the compiling working but I'm not sure how to specify to cmake to install the resulting bindings. Usually on my development pc, setup.py would handle this. Any thoughts on how to approach this?
<kergoth> Aha, archiver is what causes gcc-source to be different across my multiconfig builds. If archiver is enabled, have to use separate tmpdirs.
<turkeykittin> I had wanted to include all dependencies including my source in my meta-layer but it looks like I'll just have to handle it externally, build it into a wheel, and pull it in as a dependency in a .bb :\ But I suppose that means easier testing as I can push the wheel over to the device for dev testing as opposed to rebuilding image and flashing each
<turkeykittin> time :X
<turkeykittin> Something inside me just screams there has got to be a more 'proper' way
<RP> JPEW: I've never seen that fwiw
kevinrowland has joined #yocto
<JPEW> It was a problem on our end. Turns out if you have two things uploading a (separately built) sdk to the same path, it's hard get a correct SHA1
dlan has joined #yocto
<RP> JPEW: if only you could atomically create files! :)
mckoan|away has quit [Ping timeout: 272 seconds]
mckoan|away has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto