**** BEGIN LOGGING AT Tue Dec 10 02:59:58 2019
Dec 10 05:28:04 <gtristan> I need help debugging a huge mess of yocto... these guys have some initial import of poky from couple years ago, a ton of vendor nonsense shoved into the tree, all the regular nonsense applies... I'm just not that familiar enough with the metric ton of details to make heads or tails of the situation
Dec 10 05:28:24 <gtristan> My goal: Enable usage of sstate cache sharing between builds
Dec 10 05:29:41 <gtristan> My "current" problem (I expect other roadblocks): systemd.bbclass keeps whining about "Function failed: SYSTEMD_SERVICE_adsprpc value adsprpcd.service does not exist"
Dec 10 05:30:51 <gtristan> I've added some bb.note() statements to trace that function, and it appears to be looking for the file in build/work/8x96autogvmquin-agl-linux/adsprpc/git-r0/image/lib/systemd/system
Dec 10 05:31:09 <gtristan> But the build/work/8x96autogvmquin-agl-linux/adsprpc/git-r0/image directory contains nothing at all at the time
Dec 10 05:31:34 <gtristan> I'm not sure why it would contain anything at all, or why systemd.bbclass tries to look for files in there at do_package() time
Dec 10 05:33:02 <gtristan> The files were staged perfectly fine from the sstate cache into build/sysroots/8x96autogvmquin at "do_setscene()" time
Dec 10 05:33:21 <gtristan> But for some reason, do_package() wants them in this other irrelevant directory
Dec 10 05:34:41 <gtristan> So I'm trying to make heads or tails of this, I've looked at the archives in sstate-cache which appear to have the .service files at the correct location, I don't know why do_package is looking in this other directory, and if it *should* be in this other directory, I don't know why the files wouldnt be also staged from the sstate-cache to that
Dec 10 05:34:41 <gtristan> directoryf
Dec 10 05:35:55 <gtristan> Anybody got any tips of where I can look ? A good start might (?) be to point me to some code around management of this "image" directory, maybe I can figure out what it's for and why these files arent being staged to it
Dec 10 05:37:05 <nrossi> gtristan: the ${workdir}/image/ should be populated for the do_package task to work correctly. The fact that systemd is looking in it for .service files makes sense, thats where the service files should be.
Dec 10 05:39:14 <nrossi> gtristan: if ${workdir}/image (aka "D") is empty for the do_package task. This probably means you have some issue with the do_package setscene or similar
Dec 10 05:41:56 <nrossi> gtristan: btw, sstate-cache sharing between non-concurrent builds works fine with recent versions of oe-core/poky/yocto. Depending how old the "poky from a couple of years ago" is, you might have more success porting the custom changes to a recent version.
Dec 10 05:45:34 <gtristan> nrossi, thanks for answering ! I don't think that porting the whole shebang to a recent poky is an option here though
Dec 10 05:45:40 <gtristan> I'm probably better off debugging it
Dec 10 05:45:59 <gtristan> Do you know where I would find out the version of this ?
Dec 10 05:47:23 * gtristan doesnt seem to find a file in the platheora of scripts which says the version, I thought maybe metalayers/poky/README might say
Dec 10 05:49:09 <gtristan> Seems not that old, the last commit in the history that is not a downstream modification is Mon Jul 25 13:31:25 2016 +0000
Dec 10 05:49:30 <gtristan> well, 2 and a half years I guess
Dec 10 05:49:42 <nrossi> gtristan: if you have a repo that is tracking poky or oe-core with associated history you can use git to find the base of the fork.
Dec 10 05:50:14 <gtristan> that's what I just did, that's the date of the last upstream commit
Dec 10 05:51:23 <gtristan> "bitbake: bitbake: toaster: settings set ALLOWED_HOSTS to * in debug mode" Bitbake rev: 449dc9b955dfbe048e380f5ab9fd61c3d1489dad... anyway, 2 and a half years
Dec 10 05:51:41 <nrossi> gtristan: thats pretty old, ;). Sorry I am a bit slow, message was typed and sent before i saw your response
Dec 10 05:51:42 * gtristan thinks that sstate-cache was working that recently but maybe not ?
Dec 10 05:52:12 <gtristan> Ah no worries, I'm happy someone is answering me, I've been wrestling this for days... it behaves very strangely
Dec 10 05:52:42 <nrossi> gtristan: there has been a lot of more recent work to improve sstate-cache and sharing across builds and build hosts. So it all depends on what you need, and how much effort you are willing to put into it.
Dec 10 05:52:54 <gtristan> Seems that the build fails in different ways, so I (A) Make a clean build (B) Backup the sstate-cache, (C) Reproduce my issue... (D) Remove the build directory and restore sstate-cache
Dec 10 05:53:03 <gtristan> (D) is necessary or sometimes I don't get the same error
Dec 10 05:55:21 <nrossi> gtristan: yes inconsistent builds from sstate vs clean were a trait of older builds in certain circumstances
Dec 10 05:55:43 <nrossi> s/older builds/older versions/
Dec 10 05:57:50 <gtristan> Yeah, maybe I can track down and backport some sstate-cache related bug fixes, I would start by finding out if there are any issues related to setscene failing to populate the image directory
Dec 10 06:03:14 <nrossi> gtristan: hmmm you might hit a wall on how much you can fix, just realized that recipe specific sysroots were added shortly after the morty/nov 2016 release
Dec 10 06:05:40 <gtristan> nrossi, is "recipe specific sysroots" the thing which causes this recipe specific image directory to be "a thing" ?
Dec 10 06:05:49 <gtristan> if so then it seems we already have that
Dec 10 06:06:34 <nrossi> gtristan: no RSS is what causes you to have a target sysroot for each recipe. Instead of the global tmp/sysroot/
Dec 10 06:07:03 <gtristan> Aha, that must be pretty intense, perhaps this uses hardlinks
Dec 10 06:07:45 <gtristan> But it sounds correct, I would definitely use recipe specific sysroots to ensure control of exactly what is present in the sysroot at buildtime
Dec 10 06:07:51 <nrossi> gtristan: it does use hardlinks, but it greatly reduces race issues between recipes
Dec 10 06:07:59 <gtristan> the build everything in the same sandbox is so 90s
Dec 10 06:08:52 <gtristan> Ok, I'm going to do some more homework, you've really been very helpful, I have some direction for the moment
Dec 10 06:08:58 <gtristan> nrossi, thanks a lot
Dec 10 06:09:25 <nrossi> gtristan: no problem, :)
Dec 10 06:10:53 * gtristan will at least attempt a work around and try to see if there is any fix for this particular issue
Dec 10 06:11:09 <gtristan> But I suspect that a big bad refactor will have happened instead, causing my issue to be obsolete
Dec 10 08:30:57 <Lihis> development
Dec 10 08:31:22 <Lihis> whoops, wrong channel
Dec 10 08:55:42 <yocti> New news from stackoverflow: Can't run Yocto image with runqemu like described in documentation <https://stackoverflow.com/questions/55008174/cant-run-yocto-image-with-runqemu-like-described-in-documentation>
Dec 10 11:56:01 <rburton> really tempted to rip up the python splitting and have it *far* more granular
Dec 10 12:03:53 <RP> rburton: depends how sure we could be about dependency correctness
Dec 10 12:04:17 <rburton> well, step 1 would be pruning some of the tiny splits, merging and adding provides
Dec 10 12:04:47 <rburton> like python3-resource is just 18k
Dec 10 12:09:12 <RP> rburton: you mean more or less granular?
Dec 10 12:09:22 <rburton> erm
Dec 10 12:09:24 <rburton> less packages
Dec 10 12:09:27 <rburton> with more in
Dec 10 12:09:40 <RP> rburton: I'd say that was less granular :)
Dec 10 12:09:48 <rburton> yeah you're right ;)
Dec 10 12:09:49 <RP> which makes more sense
Dec 10 12:11:08 <RP> rburton: I'd say fewer packages but you'd throw something at me ;-)
Dec 10 12:11:15 <rburton> haha
Dec 10 12:36:39 <kanavin__> RP: can you also obtain the source/build directory for perl? I need to look at the generated Makefile
Dec 10 12:39:30 <RP> kanavin__: the worker is live but hopefully nothing ovverwritten yet
Dec 10 12:39:43 <RP> kanavin__: did you ever get an autobuilder ssh account?
Dec 10 12:40:11 <kanavin__> RP, I probably did years ago, but haven't used it, so I don't know if it's still there
Dec 10 12:40:28 <RP> kanavin__: ok, probably not then. Let me see if I can get this
Dec 10 12:43:37 <T_UNIX> hi
Dec 10 12:44:29 <T_UNIX> is anybody else experiencing issues with yocto/bitbake sporadically not `chmod`ding files correctly?
Dec 10 12:45:48 <tgamblin> RP: is there any way for me to see the activity on a builder when failures like https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/524 occur?
Dec 10 12:46:47 <RP> tgamblin: not easily :(
Dec 10 12:47:43 * RP wonders what the person who wrote this code was thinking. Sadly, I suspect I know who it would have been :/
Dec 10 12:51:20 <RP> hmm, and the insanity does have a reason
Dec 10 12:53:34 <LetoThe2nd> RP: notes to your future self?
Dec 10 13:14:29 <RP> rburton: any idea why ptest would be spending hours in the log parser? :(
Dec 10 13:15:46 <rburton> working or sitting and waiting for more input?
Dec 10 13:16:15 <RP> rburton: working 100% cpu. 71MB logfile
Dec 10 13:19:02 <RP> rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13696 has a backtrace
Dec 10 13:19:03 <yocti> Bug 13696: normal, Undecided, ---, apoorv.sangal, NEW , Ptest log parsing taking hours on the autobuilder
Dec 10 13:19:24 <rburton> how did you get that track?
Dec 10 13:20:28 <RP> rburton: attached gdb and backtraced
Dec 10 13:21:32 <RP> rburton: attached the log to the bug, maybe we can reproduce with that
Dec 10 13:23:44 <RP> hmm, that log breaks my editor
Dec 10 13:25:54 <RP> rburton: its the bluez5 upgrade
Dec 10 13:26:02 <RP> rburton: look at https://autobuilder.yocto.io/pub/non-release/20191208-14/testresults//qemux86-64-ptest/
Dec 10 13:28:42 <RP> kanavin__: think I may need to revert bluez5 until we figure this out
Dec 10 13:29:53 <kanavin__> RP, right
Dec 10 13:31:37 <RP> kanavin__: doing that as I can't afford to try and fix the ptest parsing right now :(
Dec 10 13:31:42 <RP> need M1 built
Dec 10 13:33:14 * RP kills the rc2 build and tries rc3
Dec 10 13:33:56 <RP> kanavin__: sorry, having a bad time with that series :/
Dec 10 13:44:55 <rburton> i think the meson/setuptools thing is still wrong
Dec 10 13:45:00 <rburton> have you fired rc3 already?
Dec 10 13:48:01 <fullstop> Hi!  Let's say that I have a package which on one machine is a binary but the same functionality is implemented as a script on another machine.
Dec 10 13:48:30 <fullstop> Can I have a different source uri by machine type?
Dec 10 13:48:36 <rburton> yes
Dec 10 13:48:57 <fullstop> awesome!  Is there a recipe which I could use as a reference?
Dec 10 13:48:58 <rburton> over machine overrides in the SRC_URIs and ensure the package architecture (PACKAGE_ARCH) is MACHINE
Dec 10 13:49:40 <rburton> obviously if one machine has a source you need to build and another has a scipt then you need per-machine do_compile etc
Dec 10 13:52:52 <fullstop> Right, that's perfect.  Thanks, Robert!
Dec 10 13:55:31 <jonmason> okay, recipe hacking question.  I have a command that needs a file, could be anything not empty.  It doesn't use the file.  The current version is creating a temp file and deleting it after done.  Is there a better way to do this that creating a temp file?
Dec 10 13:57:02 <fullstop> Can you use /dev/null or /dev/urandom ?
Dec 10 13:57:22 <RP> rburton: I did. Do we need to abort?
Dec 10 13:57:25 <fullstop> or /proc/version
Dec 10 14:00:34 <RP> jonmason: I'd second the "something from /proc"
Dec 10 14:13:40 <jonmason> fullstop: null is empty and random never really stops output.  But version is a great idea
Dec 10 14:15:27 <fullstop> jonmason: great!  I don't think that bitbake supports anything besides Linux at this time, so /proc/version should be safe for the time being.  I don't think that FreeBSD, for example, has /proc/version without some sort of compatibility layer.
Dec 10 14:16:00 <jonmason> I'm betting there are more Linux-isms that will break if/when it is moved to other plats
Dec 10 14:17:23 <jonmason> thanks for the help
Dec 10 14:19:30 <Ad0> how do I get rid of "is tainted from a forced run" ?
Dec 10 14:19:42 <Ad0> "./poky/meta/recipes-kernel/linux/linux-yocto_4.19.bb.do_kernel_configcheck is tainted from a forced run "
Dec 10 14:20:02 <LetoThe2nd> Ad0: cleansstate it, then do not force run :)
Dec 10 14:20:26 <tlwoerner> fullstop: i think some people are using it for zephyr and other "iot" things (freertos?)
Dec 10 14:20:51 <LetoThe2nd> tlwoerner: as targets, but not as host platforms.
Dec 10 14:20:57 <fullstop> tlwoerner: Right, but surely they aren't running bitbake on that platform.
Dec 10 14:21:00 <Ad0> LetoThe2nd, thanks :) doesn't that reset everything, and which recipe would I clean? I am not sure I even forced it, I did some menuconfig
Dec 10 14:21:07 <tlwoerner> lol
Dec 10 14:21:20 <tlwoerner> i should have read farther back for more context :-)
Dec 10 14:21:24 <fullstop> :-)
Dec 10 14:23:16 <LetoThe2nd> Ad0: you would cleansstate linux-yocto. i think that does the trick
Dec 10 14:23:28 <Ad0> great thanks, I'll try
Dec 10 14:23:43 <Ad0> makes sense
Dec 10 14:24:55 <qschulz> jonmason: why not a file with just a comment saying this file is empty but needed for the purpose of X
Dec 10 14:26:22 <jonmason> qschulz: that is what is there now, but seems very hacky.  Also, the recipe author forgot to remove the file after using it.  Since it needs to be fixed anyway, why not use something better was my logic
Dec 10 14:26:30 <RP> Ad0: you just need a plain clean
Dec 10 14:26:40 <RP> Ad0: or remove the taint file in tmp/stamps manually
Dec 10 14:26:50 <Ad0> I did bitbake -c cleanall <image-recipe>
Dec 10 14:27:01 <RP> LetoThe2nd: please don't recomment cleansstate, you really should never need that
Dec 10 14:27:03 <Ad0> that didn't have any effect
Dec 10 14:27:21 <RP> Ad0: people said linux-yocto, not image-recipe
Dec 10 14:27:34 <Ad0> yeah that was before I asked
Dec 10 14:28:01 <qschulz> jonmason: are you saying that a file with a comment is hack-ier than a file with random value in it :D?
Dec 10 14:28:28 <jofr> jonmason: Sounds a bit like /dev/zero to me..
Dec 10 14:28:44 <jofr> /dev/null contains.. nothing and you said non-empty.
Dec 10 14:29:27 <LetoThe2nd> RP: /me makes mental note
Dec 10 14:29:33 <LetoThe2nd> RP: will do so :)
Dec 10 14:30:06 <jonmason> qschulz: yeah, I'm probably splitting hairs.  The real solution is to modify the code so that an unused file is not even needed.  But not my code or recipe :)
Dec 10 14:30:52 <jofr> jonmason: "dd if=/dev/null of=/tmp/blah bs=1k count=1" will result in 0 bytes copied, while "dd if=/dev/zero of=/tmp/blah bs=1k count=1" copies 1kbytes as requested, all of which are zero.
Dec 10 14:31:08 <RP> LetoThe2nd: thanks :)
Dec 10 14:32:14 <LetoThe2nd> RP: i was pretty certain that the taint stamps would persist over clean but not cleansstate, but obviously my memory was wrong. another thing learned today :)
Dec 10 14:47:31 <kanavin__> RP: regarding perl, I have passed the compile log upstream https://github.com/arsv/perl-cross/issues/75#issuecomment-564046642
Dec 10 14:48:50 <kanavin__> RP, I couldn't find anything suspicious in the build directory, the Makefile is fully formed, but one of the outputs is missing :-/
Dec 10 14:52:24 <RP> kanavin__: thanks. It looks like a race but I've not looked into the code at all. Its good we at least saved the logs
Dec 10 14:52:36 <RP> LetoThe2nd: clean removes taints
Dec 10 14:53:01 <RP> clean sstate is simply clean + sstate removal and cleanall is sources+sstate+ normal clean
Dec 10 14:53:40 <kanavin__> RP: I am also somewhat worried about that gobject-introspection failure. I wrote a comment in the bug, but maybe we can discuss here.
Dec 10 14:53:50 <kanavin__> it seems to run do_configure, without running fetch or unpack!
Dec 10 14:54:30 <LetoThe2nd> RP: got it, i think.
Dec 10 14:55:07 <RP> kanavin__: hmm. if that is what happened, it could be the hashequive runqueue pieces misbehaving :(
Dec 10 14:55:38 <kanavin__> yes :( the log makes it clear I think
Dec 10 14:56:13 <kanavin__> RP, various sstate tasks are run for g-i and things that depend on it, then out of the blue it decided to run do_configure for it :-/
Dec 10 15:00:07 <RP> kanavin__: hmm, you're right. It does run prepare_recipe_sysroot first
Dec 10 15:02:37 <RP> kanavin__: NOTE: Task virtual:native:/home/pokybuild/yocto-worker/qemux86-world/build/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.62.0.bb:do_populate_sysroot unihash 630f83a860231d5c9be5cfe442baf833832c306b2b4be022731c661a48a273e5 unchanged by server
Dec 10 15:03:44 <RP> kanavin__: I suspect we're not handling that case correctly
Dec 10 15:06:25 <kanavin__> RP: right, I'm not sure I can help here :-/
Dec 10 15:07:54 <RP> kanavin__: fair enough, its probably one for JPEW and I to try and figure out
Dec 10 15:08:13 <RP> kanavin__: sorry for not spotting this earlier, it does look very much like hashequiv broke
Dec 10 15:08:41 <kanavin__> RP, no problem, should I reassign the bug though? :)
Dec 10 15:08:49 <RP> kanavin__: probably
Dec 10 15:22:02 <JPEW> kanavin__: Can you post the log again? I can't seem to find it
Dec 10 15:22:53 <kanavin__> JPEW, https://wiki.swf.daimler.com/display/public/Fix+fetch+error+from+artifactory+for+local+Yocto+builds
Dec 10 15:22:57 <kanavin__> oops!
Dec 10 15:23:03 <kanavin__> haha company internal stuff
Dec 10 15:23:12 <kanavin__> JPEW, https://bugzilla.yoctoproject.org/show_bug.cgi?id=13688
Dec 10 15:23:14 <yocti> Bug 13688: normal, Undecided, ---, richard.purdie, NEW , gobject-introspection do_configure failure
Dec 10 15:24:02 <JPEW> Thanks
Dec 10 15:58:56 <armpit> YPTM - armin is one
Dec 10 16:00:57 <tlwoerner> YPTM - tlwoerner is on
Dec 10 16:02:06 <tlwoerner> dreyna: are you using https://docs.google.com/document/d/1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg/edit ?
Dec 10 16:03:23 <tlwoerner> dreyna: perfect :-)
Dec 10 16:05:02 <rburton> YPTM ross in
Dec 10 16:05:15 <dreyna> tlwoerner: yes, as you see. That page is clumsy for new header pages
Dec 10 16:07:02 <RP> aehs29:  https://bugzilla.yoctoproject.org/show_bug.cgi?id=13688
Dec 10 16:07:03 <yocti> Bug 13688: normal, Undecided, ---, richard.purdie, NEW , gobject-introspection do_configure failure
Dec 10 16:14:45 <tlwoerner> JPEW: where is this presentation?
Dec 10 16:14:53 <tlwoerner> was it at a conference?
Dec 10 16:21:02 <dreyna> tlwoerner: Joshua's paper was at recent YP DevDay San Diego
Dec 10 16:22:36 <dreyna> tlwoerner : https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_2019
Dec 10 16:23:33 <tlwoerner> dreyna: thanks!
Dec 10 16:49:33 <LFSVeteran> any idea what to check? https://pastebin.com/hdQPrxWX
Dec 10 16:52:20 <alessioigor> LFSVeteran: Is it executed inside a devshell?
Dec 10 16:56:42 <LFSVeteran> no, running on the target
Dec 10 16:57:07 <LFSVeteran> system is working so basicly glibc would be fine
Dec 10 16:57:09 <yocti> New news from stackoverflow: How to source a Bash script in a Yocto recipe <https://stackoverflow.com/questions/59271765/how-to-source-a-bash-script-in-a-yocto-recipe> || Is it possible to run the rootfs containing kernel and DTB files for s specific board using qemu <https://stackoverflow.com/questions/59271650/is-it-possible-to-run-the-rootfs-containing-kernel-and-dtb-files-for-s-specific>
**** BEGIN LOGGING AT Tue Dec 10 17:30:38 2019
Dec 10 18:38:43 <tlwoerner> is there an easy way within, say, conf/local.conf or a bbappends to change a meson buildtype from "plain" to "debugoptimized"?
Dec 10 18:38:45 <tlwoerner> http://cgit.openembedded.org/openembedded-core/tree/meta/classes/meson.bbclass#n16
Dec 10 18:42:52 <tlwoerner> nevermind, i should have tried something before asking :-)
Dec 10 18:42:57 <tlwoerner> MESONOPTS_remove_pn-mesa = "--buildtype plain"
Dec 10 18:43:03 <tlwoerner> etc..
Dec 10 19:06:55 <JPEW> tlwoerner: Ask, sorry about the rock2-square. I thought I checked that all the rk3288 based ones had been switched over
Dec 10 19:14:12 <tlwoerner> JPEW: no worries!! my nightly build caught it, sometimes it's just easier to see what fails :-D
Dec 10 19:14:30 <tlwoerner> i'm just happy someone has taken an interest is my pathetic layer, lol!
Dec 10 19:15:44 <tlwoerner> the rock2 is quite old, i haven't tested it in a long time, i wouldn't be surprised if it gets dropped from u-boot
Dec 10 19:15:53 <JPEW> tlwoerner: I've taken to collecting Raspberry Pi clones here at work for testing our software stack :)
Dec 10 19:18:52 <tlwoerner> i recently bought an eTrex 30x during the canadian version of "black friday" ;-)
Dec 10 19:28:48 <tgamblin> tlwoerner: looks nifty
Dec 10 19:31:16 <tlwoerner> tgamblin: it was a tough decision, so many devices, so many features, in the end, sadly, the eTrex is 100% what we were hoping for, but when you're outside of cell range, it's a lot better than nothing
Dec 10 19:31:33 <tlwoerner> if only i knew someone at garmin who i could bug about their product matrix and what's missing...
Dec 10 19:32:09 <tlwoerner> oops! the eTrex *isn't* 100% what we were hoping for...
Dec 10 19:32:18 <tgamblin> Figured that's what you meant
Dec 10 19:33:12 <tgamblin> Been thinking about picking up a Tinkerboard S, might end up having to use your layer!
Dec 10 19:33:36 <tlwoerner> tgamblin: excellent! more contributors :-D
Dec 10 19:34:16 <tlwoerner> it seems like everyone who picks up a rockchip board goes and makes their own layer (grrr)
Dec 10 19:35:45 <tlwoerner> all we need now is some sort of rockbox or chdk project for garmin devices ;-)
Dec 10 19:37:29 <ndec> jonmason: have you requested meta-arm mailing list already?
Dec 10 19:38:01 <jonmason> Yes, and it is live
Dec 10 19:39:21 <ndec> hmm.. i can't see it.. let me check again
Dec 10 19:42:13 <ndec> jonmason: https://lists.yoctoproject.org/g/meta-arm -> "Sorry, but that group does not exist.". what am i missing?
Dec 10 19:44:00 <jonmason> Michael created it for me, but maybe it was lost in the migration
Dec 10 19:45:36 <jonmason> :/  the links are no longer working....
Dec 10 19:46:46 <ndec> yeah.. right. i can see it was there before the migration.. not anymore. let's wait for halstead then.
Dec 10 19:48:16 <jonmason> I emailed and cc'ed you.  I'm sure he can get it back up in no time
Dec 10 19:48:18 <halstead> jonmason: lists with zero posts didn't make the migration. I can add it now though.
Dec 10 19:48:24 <jonmason> hahaha
Dec 10 19:48:45 <jonmason> no emails for a yet to be pushed git tree :)
Dec 10 19:49:31 <jonmason> actually, I'm going to push it today (as soon as I reassemble my PC)
Dec 10 19:49:42 <jonmason> it's good enough for everyone to tell me its not good enough
Dec 10 19:49:45 <halstead> jonmason: I'll create it and add the members from before
Dec 10 19:49:56 <jonmason> sweet, thanks
Dec 10 19:53:39 <ndec> halstead: please add me then ;) it all started because I wanted to subscribe to this list !
Dec 10 19:54:45 <jonmason> ndec: does my bug/patch workflow make sense?
Dec 10 19:55:26 <ndec> jonmason: you mean assuming there is a mailing list? ;)
Dec 10 19:56:02 <ndec> then yes, it looks ok.
Dec 10 19:56:09 <jonmason> yes, there are some presumptions :D
Dec 10 20:26:48 <ndec> jonmason: halstead "Welcome to meta-arm@lists.yoctoproject.org", thanks!
Dec 10 20:27:16 <halstead> jonmason, ndec Almost complete. :0
Dec 10 20:29:05 <jonmason> thanks halstead, I'll buy the first round next time I see you
Dec 10 20:30:22 <halstead> jonmason, I won't turn you down. :) You're going to get an invite from your arm.com address too. Do you want your owner e-mail to go to your kudzu or arm e-mail?
Dec 10 20:32:26 <jonmason> arm is fine.  Include Steve Capper as well (incase I get hit by a bus)
Dec 10 20:32:57 <jonmason> halstead: everything is still in place for me to push my meta-arm git repo, right?
Dec 10 20:34:21 <halstead> jonmason, Sure. There in an invite at your arm email to accept. Yes that push location is still available. Let me know if you hit any bumps.
Dec 10 20:40:59 <jonmason> cool, then it'll happen in the next few hours.  thanks
Dec 10 21:27:55 <yocti> New news from stackoverflow: Install gnu tar on linux arm <https://stackoverflow.com/questions/59275243/install-gnu-tar-on-linux-arm>
Dec 10 21:39:40 <rburton> jonmason: meta-arm eh
Dec 10 21:41:31 <jonmason> rburton: yup, soon...
Dec 10 21:42:18 <rburton> tlwoerner: re meson, isn't the point that we use plain because we explicitly pass our own -O and -g flags?
Dec 10 21:42:22 <rburton> jonmason: nifty
Dec 10 21:43:45 <jonmason> rburton: only if we do it right.
Dec 10 21:48:01 <third_c> so my first yocto build on a fresh install (thud) fails with: ERROR: dbus-1.12.10-r0 do_prepare_recipe_sysroot: dbus: groupadd command did not succeed. There seems to be no additional info in the logs. Any pointers?
Dec 10 22:07:18 <tlwoerner> rburton: i don't follow (probably because i haven't dug into meson much) are the -O and -g flags related to the --buildtype flag? -O and -g are gcc flags but --buildtype is a meson flag?
Dec 10 22:28:05 <yocti> New news from stackoverflow: Install gnu tar on linux arm [closed] <https://stackoverflow.com/questions/59275243/install-gnu-tar-on-linux-arm>
Dec 10 22:32:29 <rburton> tlwoerner: why are you trying to change buildtype?
Dec 10 22:33:08 <tlwoerner> rburton: i want to do a "debug" build of mesa to help debug panfrost thigns
Dec 10 22:33:39 <tlwoerner> the thing i suggested above worked
Dec 10 22:33:48 <rburton> tlwoerner: does mesa respect the buildtype flag and change how it builds then?
Dec 10 22:34:32 <tlwoerner> rburton: yes. if nothing is specified you get a debug build, with "--buildtype plain" hardcoded into the meson class, you get a "production" build
Dec 10 22:34:47 <tlwoerner> in one case you get debugging output when panfrost asserts, in the other you don't
Dec 10 22:35:00 <tlwoerner> debug build: tunnel: ../mesa-19.2.4/src/gallium/drivers/panfrost/pan_context.c:292: translate_tex_wrap: Assertion `!"Invalid wrap"' failed.
Dec 10 22:35:09 <rburton> tlwoerner: ah ok, well if mesa does more than just pass -g when the buildtype is fiddled then the class should expose that
Dec 10 22:35:23 <tlwoerner> production build: illegal instruction (sigill)
Dec 10 22:35:33 <tlwoerner> rburton: ideally, yes :-)
Dec 10 22:35:56 <tlwoerner> thankfully the build system is very pokable
Dec 10 22:36:03 <rburton> tlwoerner: patches welcome
Dec 10 22:36:24 <rburton> tlwoerner: the docs say build systems should use plain and control optimisation etc itself, which is why it hardcodes plain
Dec 10 22:36:29 <tlwoerner> can a class have a PACKAGECONFIG? lol
Dec 10 22:36:50 <rburton> but if we have an example of a upstream that uses it then please do make it a variable
Dec 10 22:38:15 <tlwoerner> rburton: okay
Dec 10 22:38:43 <rburton> MESON_BUILDTYPE?='plain' seems sensible
Dec 10 22:40:02 <tlwoerner> sounds good, give me a good 30 minutes or so to test?
Dec 10 22:40:33 <Ad0> if another layer has a .patch file I don't want apply, how do I remove it in my layer (with higher pri) ? SRC_URI_remove ? and will it affect things like SRC_URI_append_amdx86 (and not SRC_URI_append), or do I explicitly need to SRC_URI_remove_amdx86
Dec 10 22:42:43 <tlwoerner> Ad0: while figuring out what works and what doesn't you can use "bitbake <recipe> -e | grep "^SRC_URI"
Dec 10 22:43:01 <Ad0> hehe true, thanks. or show-appends maybe?
Dec 10 22:44:31 <tlwoerner> sounds good
Dec 10 23:12:47 <tlwoerner> rburton: i need to make sure, though, that only mesa's buildtype is changed, not the buildtype of every meson project in my image
Dec 10 23:13:09 <tlwoerner> rburton: MESON_BUILDTYPE would then be set by the mesa recipe?
Dec 10 23:16:11 <RP> JPEW: that sstate change broke the siginfo handling somehow :(
Dec 10 23:16:52 <RP> oh, I can see the problem :(
Dec 10 23:17:03 <rburton> tlwoerner: right
Dec 10 23:21:41 <RP> JPEW: happens when you say something after staring at it for ages
Dec 11 01:58:38 <yocti> New news from stackoverflow: Is it possible to run the rootfs containing kernel and DTB files for a specific board using qemu <https://stackoverflow.com/questions/59271650/is-it-possible-to-run-the-rootfs-containing-kernel-and-dtb-files-for-a-specific>
**** ENDING LOGGING AT Wed Dec 11 02:59:58 2019