Tuesday, 2019-12-10

*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC00:01
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC00:08
*** bluca <bluca!~bluca@88.98.246.218> has quit IRC00:17
*** vineela <vineela!vtummala@nat/intel/x-vrgqahzapjmcvuok> has quit IRC00:24
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:26
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto00:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC00:29
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:31
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC00:45
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC01:09
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:09
khemRP:cool.01:23
khemI was hopeful that if it can build world with meta-openembedded for mips it can build anything :)01:24
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC01:57
*** vineela <vineela!vtummala@nat/intel/x-ydqpgytusjiudune> has joined #yocto02:14
*** vineela <vineela!vtummala@nat/intel/x-ydqpgytusjiudune> has quit IRC02:14
*** Saur <Saur!pkj@nat/axis/x-vqkesgnkwnysgoss> has quit IRC02:46
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC02:47
*** Saur <Saur!pkj@nat/axis/x-rxuiztmzjkwlbniq> has joined #yocto02:47
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto02:48
*** dfrey <dfrey!~dfrey@172.103.152.101> has quit IRC04:36
*** armpit <armpit!~armpit@2601:202:4180:a5c0:1527:dedf:f05:266c> has quit IRC04:37
*** gtristan <gtristan!1b7af250@27.122.242.80> has joined #yocto05:25
gtristanI 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 situation05:28
gtristanMy goal: Enable usage of sstate cache sharing between builds05:28
gtristanMy "current" problem (I expect other roadblocks): systemd.bbclass keeps whining about "Function failed: SYSTEMD_SERVICE_adsprpc value adsprpcd.service does not exist"05:29
gtristanI'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/system05:30
gtristanBut the build/work/8x96autogvmquin-agl-linux/adsprpc/git-r0/image directory contains nothing at all at the time05:31
gtristanI'm not sure why it would contain anything at all, or why systemd.bbclass tries to look for files in there at do_package() time05:31
gtristanThe files were staged perfectly fine from the sstate cache into build/sysroots/8x96autogvmquin at "do_setscene()" time05:33
gtristanBut for some reason, do_package() wants them in this other irrelevant directory05:33
gtristanSo 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 that05:34
gtristandirectoryf05:34
gtristanAnybody 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 it05:35
nrossigtristan: 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.05:37
nrossigtristan: 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 similar05:39
nrossigtristan: 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.05:41
gtristannrossi, thanks for answering ! I don't think that porting the whole shebang to a recent poky is an option here though05:45
gtristanI'm probably better off debugging it05:45
gtristanDo you know where I would find out the version of this ?05:45
* gtristan doesnt seem to find a file in the platheora of scripts which says the version, I thought maybe metalayers/poky/README might say05:47
gtristanSeems not that old, the last commit in the history that is not a downstream modification is Mon Jul 25 13:31:25 2016 +000005:49
gtristanwell, 2 and a half years I guess05:49
nrossigtristan: 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.05:49
*** hyper_dave <hyper_dave!~quassel@196.188.72.247> has joined #yocto05:49
gtristanthat's what I just did, that's the date of the last upstream commit05:50
gtristan"bitbake: bitbake: toaster: settings set ALLOWED_HOSTS to * in debug mode" Bitbake rev: 449dc9b955dfbe048e380f5ab9fd61c3d1489dad... anyway, 2 and a half years05:51
nrossigtristan: thats pretty old, ;). Sorry I am a bit slow, message was typed and sent before i saw your response05:51
* gtristan thinks that sstate-cache was working that recently but maybe not ?05:51
gtristanAh no worries, I'm happy someone is answering me, I've been wrestling this for days... it behaves very strangely05:52
nrossigtristan: 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.05:52
gtristanSeems 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-cache05:52
gtristan(D) is necessary or sometimes I don't get the same error05:53
nrossigtristan: yes inconsistent builds from sstate vs clean were a trait of older builds in certain circumstances05:55
nrossis/older builds/older versions/05:55
*** armpit <armpit!~armpit@2601:202:4180:a5c0:50a9:9288:81a1:163b> has joined #yocto05:57
gtristanYeah, 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 directory05:57
nrossigtristan: 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 release06:03
gtristannrossi, is "recipe specific sysroots" the thing which causes this recipe specific image directory to be "a thing" ?06:05
gtristanif so then it seems we already have that06:05
nrossigtristan: no RSS is what causes you to have a target sysroot for each recipe. Instead of the global tmp/sysroot/06:06
gtristanAha, that must be pretty intense, perhaps this uses hardlinks06:07
gtristanBut it sounds correct, I would definitely use recipe specific sysroots to ensure control of exactly what is present in the sysroot at buildtime06:07
nrossigtristan: it does use hardlinks, but it greatly reduces race issues between recipes06:07
gtristanthe build everything in the same sandbox is so 90s06:07
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC06:08
gtristanOk, I'm going to do some more homework, you've really been very helpful, I have some direction for the moment06:08
gtristannrossi, thanks a lot06:08
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto06:09
nrossigtristan: no problem, :)06:09
* gtristan will at least attempt a work around and try to see if there is any fix for this particular issue06:10
gtristanBut I suspect that a big bad refactor will have happened instead, causing my issue to be obsolete06:11
*** dp <dp!~phillid@oh.not.bad.aye.yeah.nah.nz> has quit IRC06:17
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto06:24
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:31
*** agust <agust!~agust@p5483338F.dip0.t-ipconnect.de> has joined #yocto06:36
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC06:38
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto06:41
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC06:45
*** pohly <pohly!~pohly@p54BD5C64.dip0.t-ipconnect.de> has joined #yocto06:55
*** dp <dp!~phillid@oh.not.bad.aye.yeah.nah.nz> has joined #yocto07:00
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:10
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto07:17
*** hyper_dave <hyper_dave!~quassel@196.188.72.247> has quit IRC07:26
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto07:29
*** lfa <lfa!~lfa@217.19.35.51> has joined #yocto07:35
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:42
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:44
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto07:46
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto07:47
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto07:50
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC07:53
*** gtristan <gtristan!1b7af250@27.122.242.80> has quit IRC07:57
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto08:00
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:00
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:03
*** hyper_dave <hyper_dave!~quassel@196.188.72.247> has joined #yocto08:10
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC08:12
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto08:23
Lihisdevelopment08:30
Lihiswhoops, wrong channel08:31
*** abelal <abelal!~quassel@110.93.212.98> has joined #yocto08:46
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC08:49
yoctiNew 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>08:55
*** yann <yann!~yann@85.118.38.73> has joined #yocto08:57
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:05
*** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto09:07
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto09:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:09
*** goliath <goliath!~goliath@nat002-WLTU1.uibk.ac.at> has joined #yocto09:17
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:50
*** hyper_dave <hyper_dave!~quassel@196.188.72.247> has quit IRC09:54
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC09:56
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto09:56
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC09:56
*** bluca <bluca!~bluca@88.98.246.218> has joined #yocto10:09
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto10:13
*** JoeR <JoeR!~JayBee@30.241.189.80.dyn.plus.net> has joined #yocto10:21
*** JoeR <JoeR!~JayBee@30.241.189.80.dyn.plus.net> has quit IRC10:22
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto10:22
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC10:27
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto10:28
*** goliath <goliath!~goliath@nat002-WLTU1.uibk.ac.at> has quit IRC10:42
*** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC10:46
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC10:48
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto11:03
*** dunc_webb <dunc_webb!~dunc_webb@mail.phabrix.co.uk> has joined #yocto11:14
*** dunc_webb <dunc_webb!~dunc_webb@mail.phabrix.co.uk> has quit IRC11:32
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC11:44
*** berton <berton!~berton@189.103.49.163> has joined #yocto11:46
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC11:51
rburtonreally tempted to rip up the python splitting and have it *far* more granular11:56
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC11:58
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC11:59
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto12:01
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:03
RPrburton: depends how sure we could be about dependency correctness12:03
rburtonwell, step 1 would be pruning some of the tiny splits, merging and adding provides12:04
rburtonlike python3-resource is just 18k12:04
RPrburton: you mean more or less granular?12:09
rburtonerm12:09
rburtonless packages12:09
rburtonwith more in12:09
RPrburton: I'd say that was less granular :)12:09
rburtonyeah you're right ;)12:09
RPwhich makes more sense12:09
RPrburton: I'd say fewer packages but you'd throw something at me ;-)12:11
rburtonhaha12:11
*** frsc <frsc!~frsc@2003:a:a75:a900:c08f:c9f8:6435:d5f2> has joined #yocto12:11
*** goliath <goliath!~goliath@82.150.214.1> has joined #yocto12:18
*** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto12:20
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto12:24
kanavin__RP: can you also obtain the source/build directory for perl? I need to look at the generated Makefile12:36
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto12:36
RPkanavin__: the worker is live but hopefully nothing ovverwritten yet12:39
RPkanavin__: did you ever get an autobuilder ssh account?12:39
kanavin__RP, I probably did years ago, but haven't used it, so I don't know if it's still there12:40
RPkanavin__: ok, probably not then. Let me see if I can get this12:40
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-azchnjbwedcsbsup> has joined #yocto12:43
T_UNIXhi12:43
T_UNIXis anybody else experiencing issues with yocto/bitbake sporadically not `chmod`ding files correctly?12:44
tgamblinRP: 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?12:45
RPtgamblin: not easily :(12:46
* RP wonders what the person who wrote this code was thinking. Sadly, I suspect I know who it would have been :/12:47
RPhmm, and the insanity does have a reason12:51
LetoThe2ndRP: notes to your future self?12:53
*** frsc <frsc!~frsc@2003:a:a75:a900:c08f:c9f8:6435:d5f2> has quit IRC13:03
*** frsc <frsc!~frsc@2003:a:a75:a900:c08f:c9f8:6435:d5f2> has joined #yocto13:03
*** frsc <frsc!~frsc@2003:a:a75:a900:c08f:c9f8:6435:d5f2> has quit IRC13:10
RPrburton: any idea why ptest would be spending hours in the log parser? :(13:14
rburtonworking or sitting and waiting for more input?13:15
RPrburton: working 100% cpu. 71MB logfile13:16
RPrburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13696 has a backtrace13:19
yoctiBug 13696: normal, Undecided, ---, apoorv.sangal, NEW , Ptest log parsing taking hours on the autobuilder13:19
rburtonhow did you get that track?13:19
RPrburton: attached gdb and backtraced13:20
RPrburton: attached the log to the bug, maybe we can reproduce with that13:21
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto13:23
RPhmm, that log breaks my editor13:23
RPrburton: its the bluez5 upgrade13:25
RPrburton: look at https://autobuilder.yocto.io/pub/non-release/20191208-14/testresults//qemux86-64-ptest/13:26
*** anujm <anujm!~anujm@134.134.139.76> has joined #yocto13:27
RPkanavin__: think I may need to revert bluez5 until we figure this out13:28
kanavin__RP, right13:29
RPkanavin__: doing that as I can't afford to try and fix the ptest parsing right now :(13:31
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto13:31
RPneed M1 built13:31
* RP kills the rc2 build and tries rc313:33
RPkanavin__: sorry, having a bad time with that series :/13:33
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC13:40
rburtoni think the meson/setuptools thing is still wrong13:44
rburtonhave you fired rc3 already?13:45
fullstopHi!  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.13:48
fullstopCan I have a different source uri by machine type?13:48
rburtonyes13:48
fullstopawesome!  Is there a recipe which I could use as a reference?13:48
rburtonover machine overrides in the SRC_URIs and ensure the package architecture (PACKAGE_ARCH) is MACHINE13:48
rburtonobviously if one machine has a source you need to build and another has a scipt then you need per-machine do_compile etc13:49
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC13:50
fullstopRight, that's perfect.  Thanks, Robert!13:52
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto13:53
jonmasonokay, 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?13:55
fullstopCan you use /dev/null or /dev/urandom ?13:57
RPrburton: I did. Do we need to abort?13:57
fullstopor /proc/version13:57
RPjonmason: I'd second the "something from /proc"14:00
*** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto14:00
*** hpsy <hpsy!~hpsy@88.128.88.52> has joined #yocto14:03
*** hpsy <hpsy!~hpsy@88.128.88.52> has quit IRC14:07
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto14:08
jonmasonfullstop: null is empty and random never really stops output.  But version is a great idea14:13
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto14:15
fullstopjonmason: 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.14:15
jonmasonI'm betting there are more Linux-isms that will break if/when it is moved to other plats14:16
jonmasonthanks for the help14:17
Ad0how do I get rid of "is tainted from a forced run" ?14:19
Ad0"./poky/meta/recipes-kernel/linux/linux-yocto_4.19.bb.do_kernel_configcheck is tainted from a forced run "14:19
LetoThe2ndAd0: cleansstate it, then do not force run :)14:20
tlwoernerfullstop: i think some people are using it for zephyr and other "iot" things (freertos?)14:20
LetoThe2ndtlwoerner: as targets, but not as host platforms.14:20
fullstoptlwoerner: Right, but surely they aren't running bitbake on that platform.14:20
Ad0LetoThe2nd, thanks :) doesn't that reset everything, and which recipe would I clean? I am not sure I even forced it, I did some menuconfig14:21
tlwoernerlol14:21
tlwoerneri should have read farther back for more context :-)14:21
fullstop:-)14:21
LetoThe2ndAd0: you would cleansstate linux-yocto. i think that does the trick14:23
Ad0great thanks, I'll try14:23
Ad0makes sense14:23
qschulzjonmason: why not a file with just a comment saying this file is empty but needed for the purpose of X14:24
jonmasonqschulz: 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 logic14:26
RPAd0: you just need a plain clean14:26
RPAd0: or remove the taint file in tmp/stamps manually14:26
Ad0I did bitbake -c cleanall <image-recipe>14:26
RPLetoThe2nd: please don't recomment cleansstate, you really should never need that14:27
Ad0that didn't have any effect14:27
RPAd0: people said linux-yocto, not image-recipe14:27
Ad0yeah that was before I asked14:27
qschulzjonmason: are you saying that a file with a comment is hack-ier than a file with random value in it :D?14:28
jofrjonmason: Sounds a bit like /dev/zero to me..14:28
jofr/dev/null contains.. nothing and you said non-empty.14:28
LetoThe2ndRP: /me makes mental note14:29
LetoThe2ndRP: will do so :)14:29
jonmasonqschulz: 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 :)14:30
jofrjonmason: "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.14:30
RPLetoThe2nd: thanks :)14:31
LetoThe2ndRP: 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 :)14:32
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC14:44
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC14:44
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto14:45
kanavin__RP: regarding perl, I have passed the compile log upstream https://github.com/arsv/perl-cross/issues/75#issuecomment-56404664214:47
kanavin__RP, I couldn't find anything suspicious in the build directory, the Makefile is fully formed, but one of the outputs is missing :-/14:48
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto14:50
RPkanavin__: thanks. It looks like a race but I've not looked into the code at all. Its good we at least saved the logs14:52
RPLetoThe2nd: clean removes taints14:52
RPclean sstate is simply clean + sstate removal and cleanall is sources+sstate+ normal clean14:53
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.14:53
kanavin__it seems to run do_configure, without running fetch or unpack!14:53
LetoThe2ndRP: got it, i think.14:54
RPkanavin__: hmm. if that is what happened, it could be the hashequive runqueue pieces misbehaving :(14:55
kanavin__yes :( the log makes it clear I think14:55
*** anujm <anujm!~anujm@134.134.139.76> has quit IRC14:56
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 :-/14:56
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto14:58
RPkanavin__: hmm, you're right. It does run prepare_recipe_sysroot first15:00
RPkanavin__: 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 server15:02
RPkanavin__: I suspect we're not handling that case correctly15:03
kanavin__RP: right, I'm not sure I can help here :-/15:06
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC15:07
RPkanavin__: fair enough, its probably one for JPEW and I to try and figure out15:07
RPkanavin__: sorry for not spotting this earlier, it does look very much like hashequiv broke15:08
kanavin__RP, no problem, should I reassign the bug though? :)15:08
RPkanavin__: probably15:08
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC15:09
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto15:13
JPEWkanavin__: Can you post the log again? I can't seem to find it15:22
kanavin__JPEW, https://wiki.swf.daimler.com/display/public/Fix+fetch+error+from+artifactory+for+local+Yocto+builds15:22
kanavin__oops!15:22
kanavin__haha company internal stuff15:23
kanavin__JPEW, https://bugzilla.yoctoproject.org/show_bug.cgi?id=1368815:23
yoctiBug 13688: normal, Undecided, ---, richard.purdie, NEW , gobject-introspection do_configure failure15:23
JPEWThanks15:24
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto15:25
*** edgar444 <edgar444!uid214381@gateway/web/irccloud.com/x-dfvpmcijkrbhqtds> has joined #yocto15:26
*** florian_kc is now known as florian15:28
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC15:33
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC15:38
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC15:43
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto15:53
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC15:53
*** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto15:54
*** goliath <goliath!~goliath@82.150.214.1> has quit IRC15:57
*** vineela <vineela!~vtummala@134.134.139.74> has joined #yocto15:58
armpitYPTM - armin is one15:58
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC15:59
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto16:00
tlwoernerYPTM - tlwoerner is on16:00
tlwoernerdreyna: are you using https://docs.google.com/document/d/1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg/edit ?16:02
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto16:02
tlwoernerdreyna: perfect :-)16:03
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC16:04
rburtonYPTM ross in16:05
dreynatlwoerner: yes, as you see. That page is clumsy for new header pages16:05
RPaehs29:  https://bugzilla.yoctoproject.org/show_bug.cgi?id=1368816:07
yoctiBug 13688: normal, Undecided, ---, richard.purdie, NEW , gobject-introspection do_configure failure16:07
tlwoernerJPEW: where is this presentation?16:14
tlwoernerwas it at a conference?16:14
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC16:19
dreynatlwoerner: Joshua's paper was at recent YP DevDay San Diego16:21
dreynatlwoerner : https://wiki.yoctoproject.org/wiki/DevDay_San_Diego_201916:22
tlwoernerdreyna: thanks!16:23
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:30
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC16:31
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:31
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto16:32
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto16:34
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC16:35
*** LFSVeteran <LFSVeteran!~LFSVetera@2a02:a440:69df:1:dafc:93ff:fec0:20f6> has joined #yocto16:44
*** yann <yann!~yann@85.118.38.73> has quit IRC16:48
LFSVeteranany idea what to check? https://pastebin.com/hdQPrxWX16:49
alessioigorLFSVeteran: Is it executed inside a devshell?16:52
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC16:54
LFSVeteranno, running on the target16:56
LFSVeteransystem is working so basicly glibc would be fine16:57
yoctiNew 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>16:57
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto17:03
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC17:15
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:16
*** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC17:17
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC17:18
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC17:20
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC17:20
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto17:29
*** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto17:30
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC17:31
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto17:32
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC17:42
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto17:56
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:57
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:58
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC17:59
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto18:09
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC18:19
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto18:21
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto18:22
tlwoerneris there an easy way within, say, conf/local.conf or a bbappends to change a meson buildtype from "plain" to "debugoptimized"?18:38
tlwoernerhttp://cgit.openembedded.org/openembedded-core/tree/meta/classes/meson.bbclass#n1618:38
*** iceaway <iceaway!~pelle@37.233.78.69> has quit IRC18:40
tlwoernernevermind, i should have tried something before asking :-)18:42
tlwoernerMESONOPTS_remove_pn-mesa = "--buildtype plain"18:42
tlwoerneretc..18:43
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC18:43
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC18:50
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto18:51
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has joined #yocto18:56
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:06
JPEWtlwoerner: Ask, sorry about the rock2-square. I thought I checked that all the rk3288 based ones had been switched over19:06
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-azchnjbwedcsbsup> has quit IRC19:13
tlwoernerJPEW: no worries!! my nightly build caught it, sometimes it's just easier to see what fails :-D19:14
tlwoerneri'm just happy someone has taken an interest is my pathetic layer, lol!19:14
tlwoernerthe rock2 is quite old, i haven't tested it in a long time, i wouldn't be surprised if it gets dropped from u-boot19:15
JPEWtlwoerner: I've taken to collecting Raspberry Pi clones here at work for testing our software stack :)19:15
tlwoerneri recently bought an eTrex 30x during the canadian version of "black friday" ;-)19:18
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC19:20
tgamblintlwoerner: looks nifty19:28
tlwoernertgamblin: 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 nothing19:31
tlwoernerif only i knew someone at garmin who i could bug about their product matrix and what's missing...19:31
tlwoerneroops! the eTrex *isn't* 100% what we were hoping for...19:32
tgamblinFigured that's what you meant19:32
tgamblinBeen thinking about picking up a Tinkerboard S, might end up having to use your layer!19:33
tlwoernertgamblin: excellent! more contributors :-D19:33
tlwoernerit seems like everyone who picks up a rockchip board goes and makes their own layer (grrr)19:34
tlwoernerall we need now is some sort of rockbox or chdk project for garmin devices ;-)19:35
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC19:37
ndecjonmason: have you requested meta-arm mailing list already?19:37
jonmasonYes, and it is live19:38
ndechmm.. i can't see it.. let me check again19:39
ndecjonmason: https://lists.yoctoproject.org/g/meta-arm -> "Sorry, but that group does not exist.". what am i missing?19:42
jonmasonMichael created it for me, but maybe it was lost in the migration19:44
*** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC19:44
jonmason:/  the links are no longer working....19:45
ndecyeah.. right. i can see it was there before the migration.. not anymore. let's wait for halstead then.19:46
jonmasonI emailed and cc'ed you.  I'm sure he can get it back up in no time19:48
halsteadjonmason: lists with zero posts didn't make the migration. I can add it now though.19:48
jonmasonhahaha19:48
jonmasonno emails for a yet to be pushed git tree :)19:48
jonmasonactually, I'm going to push it today (as soon as I reassemble my PC)19:49
jonmasonit's good enough for everyone to tell me its not good enough19:49
halsteadjonmason: I'll create it and add the members from before19:49
jonmasonsweet, thanks19:49
ndechalstead: please add me then ;) it all started because I wanted to subscribe to this list !19:53
jonmasonndec: does my bug/patch workflow make sense?19:54
ndecjonmason: you mean assuming there is a mailing list? ;)19:55
ndecthen yes, it looks ok.19:56
jonmasonyes, there are some presumptions :D19:56
*** jklare <jklare!~jklare@157.97.76.18> has quit IRC19:57
*** hpsy <hpsy!~hpsy@195.67.91.135> has joined #yocto20:01
*** jklare <jklare!~jklare@157.97.76.18> has joined #yocto20:01
*** hpsy <hpsy!~hpsy@195.67.91.135> has quit IRC20:05
*** hpsy1 <hpsy1!~hpsy@217.66.60.5> has joined #yocto20:06
*** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-nfrqepxxbhoouxkr> has quit IRC20:07
*** hpsy1 <hpsy1!~hpsy@217.66.60.5> has quit IRC20:07
*** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto20:07
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto20:10
ndecjonmason: halstead "Welcome to meta-arm@lists.yoctoproject.org", thanks!20:26
halsteadjonmason, ndec Almost complete. :020:27
jonmasonthanks halstead, I'll buy the first round next time I see you20:29
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC20:29
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto20:30
halsteadjonmason, 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?20:30
jonmasonarm is fine.  Include Steve Capper as well (incase I get hit by a bus)20:32
jonmasonhalstead: everything is still in place for me to push my meta-arm git repo, right?20:32
halsteadjonmason, 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.20:34
*** georgem <georgem!~georgem@216.21.169.52> has quit IRC20:38
jonmasoncool, then it'll happen in the next few hours.  thanks20:40
*** berton <berton!~berton@189.103.49.163> has quit IRC20:43
*** berton_ <berton_!~berton@189.103.49.163> has joined #yocto20:43
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC20:44
*** berton_ <berton_!~berton@189.103.49.163> has quit IRC20:46
*** berton <berton!~berton@189.103.49.163> has joined #yocto20:47
*** berton <berton!~berton@189.103.49.163> has quit IRC21:15
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC21:17
yoctiNew news from stackoverflow: Install gnu tar on linux arm <https://stackoverflow.com/questions/59275243/install-gnu-tar-on-linux-arm>21:27
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:29
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto21:31
*** third_c <third_c!5106220c@81.6.34.12> has joined #yocto21:35
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto21:38
rburtonjonmason: meta-arm eh21:39
*** florian_kc is now known as florian21:39
jonmasonrburton: yup, soon...21:41
*** JaMa <JaMa!~martin@109.238.218.228> has quit IRC21:41
rburtontlwoerner: re meson, isn't the point that we use plain because we explicitly pass our own -O and -g flags?21:42
rburtonjonmason: nifty21:42
jonmasonrburton: only if we do it right.21:43
third_cso 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?21:48
*** pohly <pohly!~pohly@p54BD5C64.dip0.t-ipconnect.de> has quit IRC21:49
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC21:53
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC21:57
*** third_c <third_c!5106220c@81.6.34.12> has quit IRC22:03
tlwoernerrburton: 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?22:07
*** MiskaX <MiskaX!g06thq0ncf@rankki.sonarnerd.net> has quit IRC22:11
yoctiNew news from stackoverflow: Install gnu tar on linux arm [closed] <https://stackoverflow.com/questions/59275243/install-gnu-tar-on-linux-arm>22:28
rburtontlwoerner: why are you trying to change buildtype?22:32
tlwoernerrburton: i want to do a "debug" build of mesa to help debug panfrost thigns22:33
tlwoernerthe thing i suggested above worked22:33
rburtontlwoerner: does mesa respect the buildtype flag and change how it builds then?22:33
tlwoernerrburton: yes. if nothing is specified you get a debug build, with "--buildtype plain" hardcoded into the meson class, you get a "production" build22:34
tlwoernerin one case you get debugging output when panfrost asserts, in the other you don't22:34
tlwoernerdebug build: tunnel: ../mesa-19.2.4/src/gallium/drivers/panfrost/pan_context.c:292: translate_tex_wrap: Assertion `!"Invalid wrap"' failed.22:35
rburtontlwoerner: ah ok, well if mesa does more than just pass -g when the buildtype is fiddled then the class should expose that22:35
tlwoernerproduction build: illegal instruction (sigill)22:35
tlwoernerrburton: ideally, yes :-)22:35
tlwoernerthankfully the build system is very pokable22:35
rburtontlwoerner: patches welcome22:36
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto22:36
rburtontlwoerner: the docs say build systems should use plain and control optimisation etc itself, which is why it hardcodes plain22:36
tlwoernercan a class have a PACKAGECONFIG? lol22:36
rburtonbut if we have an example of a upstream that uses it then please do make it a variable22:36
tlwoernerrburton: okay22:38
rburtonMESON_BUILDTYPE?='plain' seems sensible22:38
tlwoernersounds good, give me a good 30 minutes or so to test?22:40
Ad0if 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_amdx8622:40
tlwoernerAd0: while figuring out what works and what doesn't you can use "bitbake <recipe> -e | grep "^SRC_URI"22:42
Ad0hehe true, thanks. or show-appends maybe?22:43
*** LFSVeteran <LFSVeteran!~LFSVetera@2a02:a440:69df:1:dafc:93ff:fec0:20f6> has quit IRC22:44
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC22:44
tlwoernersounds good22:44
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC22:46
*** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC22:50
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-duziqgdxhwcqomae> has quit IRC22:55
*** agust <agust!~agust@p5483338F.dip0.t-ipconnect.de> has quit IRC23:07
tlwoernerrburton: i need to make sure, though, that only mesa's buildtype is changed, not the buildtype of every meson project in my image23:12
tlwoernerrburton: MESON_BUILDTYPE would then be set by the mesa recipe?23:13
RPJPEW: that sstate change broke the siginfo handling somehow :(23:16
RPoh, I can see the problem :(23:16
rburtontlwoerner: right23:17
RPJPEW: happens when you say something after staring at it for ages23:21
*** lfa <lfa!~lfa@217.19.35.51> has quit IRC23:23
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC23:28
*** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC23:31
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC23:32
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:54
*** vineela <vineela!~vtummala@134.134.139.74> has quit IRC23:56

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!