Thursday, 2019-09-05

*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC00:25
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto00:59
khemrsalveti:my bad01:02
khemI guess I have to update my patchset01:02
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC01:06
*** mckoan|away <mckoan|away!~marco@unaffiliated/mckoan> has quit IRC01:14
*** anujm <anujm!~anujm@> has quit IRC01:40
*** chinhuat647997 <chinhuat647997!~chinhuat@> has joined #yocto01:47
*** chinhuat64799 <chinhuat64799!~chinhuat@> has quit IRC01:49
*** JPEW <JPEW!> has quit IRC01:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:59
*** camus <camus!~Instantbi@> has joined #yocto02:06
*** armpit <armpit!> has quit IRC02:07
*** kaspter <kaspter!~Instantbi@> has quit IRC02:08
*** camus is now known as kaspter02:08
*** kaspter <kaspter!~Instantbi@> has quit IRC02:12
*** jklare <jklare!~jklare@> has quit IRC02:12
*** goliath <goliath!> has quit IRC02:18
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:19
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto02:20
*** jklare <jklare!~jklare@> has joined #yocto02:20
zeddiiRP: I didn't see a systemtap patch on master-next or master-next2, I wanted to grab it, since when I tested 32bit arm, I ran into the flags issue from earlier.03:10
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC03:17
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto03:23
*** jklare <jklare!~jklare@> has quit IRC03:35
*** jklare <jklare!~jklare@> has joined #yocto03:35
*** mtahmed <mtahmed!ad24d476@> has joined #yocto03:53
mtahmedHi all! I have been trying to figure out why building a simple recipe that has no dependencies ends up building "everything". Anything that ends up in the final image for that machine ends up as a dependency of the target_recipe.do_build in task-depends.dot03:54
mtahmedI saw that there is a `do_build[recrdeptask] = "do_package_write_ipk` but this tiny recipe I am building has no declared dependencies yet ends up depending on a bunch of unrelated stuff in task-depends.dot03:55
*** mtahmed <mtahmed!ad24d476@> has quit IRC03:58
*** mtahmed <mtahmed!ad24d476@> has joined #yocto03:59
yoctiNew news from stackoverflow: do_rootfs function failed in yocto project <>04:14
*** mtahmed <mtahmed!ad24d476@> has quit IRC04:23
*** mtahmed <mtahmed!> has joined #yocto04:27
*** mtahmed <mtahmed!> has quit IRC04:32
*** iceaway <iceaway!~pelle@> has joined #yocto05:13
*** tprrt <tprrt!> has quit IRC05:25
*** AndersD <AndersD!> has joined #yocto05:26
*** armpit <armpit!~armpit@2601:202:4180:c33:811a:fbd5:24bc:2160> has joined #yocto05:31
*** agust <agust!> has joined #yocto05:35
*** kroon <kroon!~kroon@> has joined #yocto06:07
*** iceaway <iceaway!~pelle@> has quit IRC06:13
*** iceaway <iceaway!~pelle@> has joined #yocto06:14
yoctiNew news from stackoverflow: Unable to start bitbake server <>06:14
*** saraf <saraf!~a_saraf@> has joined #yocto06:15
*** feilz <feilz!> has joined #yocto06:16
*** frsc <frsc!> has joined #yocto06:32
*** micka <micka!> has quit IRC06:33
*** micka <micka!> has joined #yocto06:35
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-dzqnckydpijeibqp> has quit IRC06:45
*** griffinp <griffinp!griffinp@gateway/shell/linaro/x-otxlgrsgngkzwvxg> has quit IRC06:45
*** alimon <alimon!alimon@gateway/shell/linaro/x-jgbtkxiflkqtvjob> has quit IRC06:45
*** chinhuat6479978 <chinhuat6479978!~chinhuat@> has joined #yocto06:49
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-qrhypfouzsfpgvfe> has joined #yocto06:50
*** chinhuat647997 <chinhuat647997!~chinhuat@> has quit IRC06:50
qschulzfullstop: glad it's fixed :) Thanks for letting us know!06:52
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto06:54
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:07
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:09
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:17
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:23
RPzeddii: I just updated to a new git version so the patch was ammended07:24
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:25
*** tprrt <tprrt!~tprrt@> has joined #yocto07:26
*** JaMa <JaMa!> has joined #yocto07:29
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:30
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:32
*** yacar_ <yacar_!~yacar@> has joined #yocto07:34
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:36
*** bisbarn <bisbarn!> has joined #yocto07:43
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:56
*** Bunio_FH <Bunio_FH!> has joined #yocto08:04
*** tprrt <tprrt!~tprrt@> has quit IRC08:07
*** Bunio_FH <Bunio_FH!> has quit IRC08:08
*** tprrt <tprrt!~tprrt@> has joined #yocto08:08
yoctiNew news from stackoverflow: YOCTO : No '/lib/modules' directory in image, modprobe fails <>08:15
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC08:19
cengiz_iohello there! I have a very silly question regarding `menuconfig` ncurses view. I'm indirectly running `make menuconfig` thru yocto/bitbake and whenever the ncurses UI pops up, line characters are messed up (particularly replaced with ^@ symbol). Any ideas?08:39
cengiz_iorunning in a docker container based on ubuntu:18.10, I've tried changing $TERM variable, installing libncurses(w)5-dev instead of libncurses-dev, tried exporting some environment variable that supposedly forces ncurses to NOT to use unicode while drawing lines, I've messed with locale settings, LC_ALL=en.US-UTF8 oh and, `bitbake -c menuconfig virtu08:40
cengiz_ioal/kernel` runs menuconfig (devshell) via `screen` command. I can't modify those arguments because they all come from OpenEmbedded distro.08:40
cengiz_iomy yocto branch is `thud`08:40
*** rburton <rburton!> has joined #yocto08:45
*** yacar_ <yacar_!~yacar@> has quit IRC09:04
*** likewise <likewise!~leon@> has joined #yocto09:24
feilzcengiz_io: this isn't directly the answer, but for me at least I never successfully managed to use the 'menuconfig' to modify my kernel values, and were forced to still manually implement the changes I attempted that way (might also be cause I don't know how to get it to work).09:27
feilzi introduced the changes using patch files to my kernel09:27
qschulzfeilz: you need menuconfig, then savedefconfig and then use a patch to replace the defconfig in question IIRC09:31
*** yacar_ <yacar_!~yacar@> has joined #yocto09:33
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:46
likewiseI have gdb-cross built. How can I easily call it directly without first going through the BSP flow?09:46
likewiseI recon I would need to create the combined sysroot for gdb-cross-<target-arch>, but I do not know how to do this.09:47
likewise(Calling gdb-cross directly worked in older releases, but broke when sysroot got componentized).09:48
*** yacar_ <yacar_!~yacar@> has quit IRC09:55
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC09:57
feilzqschulz: tried that multiple times. I tried following the instructions I found online, however to no avail. One issue I found (not sure if every time was cause of this) was that sometimes the menuconfig opened the kernel of the local system I was using10:02
feilzI believe that happened if I was using the menuconfig through bitbake, but if I used 'make menuconfig' in the temp work directory of the kernel, it built using the virtual kernel I was working10:03
qschulzfeilz: you did bitbake virtual/kernel -c menuconfig right?10:03
feilzi used that command, yes.10:04
qschulzyou have to use this command after the do_configure of the kernel I think, otherwise there is no .config10:04
feilzproblem with the .config was as well since every build I made I basically rewrote the temp kernel (through changes).10:05
feilzand it usually got lost.10:05
feilzhence after doing menuconfig (before I gave up on using it), I looked through the actual .config value changes, and noted them manually into our custom defconfig file.10:06
feilzthat way I got them incorporated10:06
feilzlater on I just learned to read the Kconfig files to find the correct config values to get what I needed10:07
qschulzfeilz: not ideal as .config has way more info than necessary compared to a defconfig10:07
qschulzfeilz: don't do that please, use menuconfig and savedefconfig10:07
qschulzyou'll get into trouble faster than you think10:07
qschulzpulling your hair for no reason10:08
qschulzbecause you forgot that one depends on that this Kconfig option relied one through the 10th selects Kconfig10:08
feilzwell... I got a successful delivery eventually on the first project for this client, and using the method I described. On the second project now, and the method hasn't failed me yet, where the menuconfig and savedefconfig commands failed me10:09
feilzgrep is quite a handy command to find all the dependencies10:09
feilznot ideal, I agree.10:10
*** lfa <lfa!~lfa@> has quit IRC10:10
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC10:14
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto10:17
rburtonok any MIPS experts around?10:19
*** goliath <goliath!> has joined #yocto10:20
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:30
*** camus <camus!~Instantbi@> has joined #yocto10:32
*** kaspter <kaspter!~Instantbi@> has quit IRC10:34
*** saraf <saraf!~a_saraf@> has quit IRC10:46
*** mrpelotazo <mrpelotazo!> has joined #yocto11:04
*** yacar_ <yacar_!~yacar@> has joined #yocto11:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:35
nrossiRP: i think i've sorted those gcc test issues i linked yesterday,
nrossiRP: also, khem's comment about needing to set TOOLCHAIN for glibc-testsuite made me think of various other glibc overrides. So i think this change is needed too
nrossiRP: and just a side query, glibc-initial is definitely gone yes? there are still some overrides remaining for it in security_flags and other various comments, are those still applicable or should they be cleaned up?11:39
rsalvetikhem: thanks for sending the patch!11:39
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:42
*** berton <berton!~berton@> has joined #yocto11:44
RPnrossi: first change looks good, we should probably duplicate entries for the second, I'm curious which other pn overrides there would be?11:44
RPnrossi: glibc-initial is definitely gone, those are just leftovers and should be cleaned up11:44
RPnrossi: I've been thinking about the autobuilder integration of this and have run into a few challenges.11:44
RPnrossi: resulttool doesn't seem to be processing things entirely correctly :/11:45
nrossiRP: by duplicate entries you mean add duplicate entries to e.g. security_flags? or something else?11:46
RPnrossi: - no gcc results in the ptest tables11:46
nrossiRP: other layers override based on glibc, e.g.
RPnrossi: yes, security_flags11:46
RPnrossi: those other layers should really adapt to the change11:46
nrossiRP: yes i noticed the missing results, was very confused11:46
RPnrossi: the results are there, its just not processing them as we'd want11:47
nrossiRP: are you sure? i looked at the testresults.json file from one of those builds and the ptestresults entries were not there11:47
nrossiRP: <- or are they trimmed somewhere?11:48
RPnrossi: ah, you're right. They're not in
RPnrossi: ok, need to investigate that11:49
RPnrossi: we also have a timeout problem on long running tests11:49
RPnrossi: bitbake prints a "keepalive" to the console but oe-selftest does not11:49
nrossiRP: by keepalive, you just mean like a newline or similar yes?11:50
nrossiRP: not a special string11:50
RPnrossi: It just prints "still alive <time>" or similar11:51
nrossiRP: I can look at doing that11:51
RPnrossi: devil is in the detail now :)11:52
nrossiRP: oh btw, you left the pexpect commit in master-next when you rebased11:52
RPnrossi: yes, sorry. won't hurt anything11:56
*** yacar_ <yacar_!~yacar@> has quit IRC11:56
RPnrossi: gone now :)11:56
nrossiRP: also i had some ideas about how to do the autobuilder selftest with exclusion of qemu sys tests. Wondering if you had any opposition to the tests being "skipped" instead of filtered11:57
RPnrossi: no objection as such11:57
*** vmeson <vmeson!> has quit IRC11:57
nrossiRP: the idea is that instead of tags being special, they simply follow a tags_filter expression and then cause a skip if the tag filter is not met11:58
*** berton <berton!~berton@> has quit IRC11:59
*** berton <berton!~berton@> has joined #yocto11:59
nrossiRP: the idea then is to have that work with the datavar decorator, so that it can check if the tags match or if the machine==x86-64. Allowing for the glibc-sys for only x8611:59
RPnrossi: how does that help compared to what is there now?12:02
RPnrossi: FWIW I've been wondering about marking the system and user tests with a specific tag, having the autobuilder select both, then let the class setup decide whether to run or skip based on the host arch12:03
nrossiRP: that works too, but how would you run the glibc system tests for all machines?12:05
*** yacar_ <yacar_!~yacar@> has joined #yocto12:05
RPnrossi: not sure I understand the question?12:06
nrossiRP: if the class decides to run or skip based on host, would it be skipping all non-kvmable hosts? and if so then how do you get the class to execute e.g. say locally or for release testing12:07
RPnrossi: I'd guess that piece of policy would be down to some variable doing configuration12:08
RPnrossi: or we just markup with extra tags to match the pattern we need?12:08
*** nabokov <nabokov!~armand@> has joined #yocto12:08
RPnrossi: I assume a test or class can have more than one tag?12:08
nrossiRP: yes12:09
*** lexano <lexano!> has quit IRC12:09
nrossiRP: but the slight annoyance is that classes will inherit tags, so might need to sort that out12:10
*** lexano <lexano!> has joined #yocto12:12
RPnrossi: you mean all tests within a class inherit tags and all subclasses of a class?12:13
nrossiRP: yer12:13
*** diego_r <diego_r!> has joined #yocto12:16
*** tprrt <tprrt!~tprrt@> has quit IRC12:25
*** nabokov <nabokov!~armand@> has quit IRC12:26
*** tprrt <tprrt!~tprrt@> has joined #yocto12:27
*** vmeson <vmeson!~rmacleod@> has joined #yocto12:28
*** nabokov <nabokov!~armand@> has joined #yocto12:39
*** alimon <alimon!alimon@gateway/shell/linaro/x-kdxwurhyvcmjuqof> has joined #yocto13:00
*** bisbarn <bisbarn!> has quit IRC13:03
RPzeddii: figured out the qemuarm systemtap issue13:04
zeddiilol. I was just about to say "i reproduced it!"13:08
zeddii                 from /tmp/stapy2SORD/stap_1381_src.c:26:13:08
zeddii  261 |   get_fs() == get_ds() ? "kernel" : "user");13:08
zeddii      |               ^~~~~~13:08
zeddii      |               get_fs13:08
zeddiicc1: all warnings being treated as errors13:08
zeddiimake[1]: *** [scripts/ /tmp/stapy2SORD/stap_1381_src.o] Error 113:08
* zeddii feels the need to prove it :D13:08
zeddiiI bumped the stap srcrev here as well. but it takes about 10 minutes for the case to error when I run it. + time to make scripts prepare, so it was about an hour round trip from the update to the error :D13:09
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC13:10
zeddiiyah. last night in my kernel checking I saw that it had been removed. that13:10
zeddiithat's the right thing to do to get it back up and running.13:10
RPzeddii: mentioning to upstream, see if they like the patch13:10
zeddiiI don't see why they wouldn't. That's what it was being resolved to anyway. so outside of dropping the use of get_ds (kernel_ds) completely .. that's the only way to go.13:11
zeddiiso it is just the mips highmem lockup now ? and that beastie is not 100% reproducible ?13:13
rburtonzeddii: know anyone who knows mips memory layout?13:13
rburtonmy  limited understanding is that mips 32-bit is a bit of a mess but linux appears to be doing the right thing13:13
rburtonbut hey i know nothing about mips13:13
rburton[    0.000000] Zone ranges:13:14
rburton[    0.000000]   DMA      [mem 0x0000000000000000-0x0000000000ffffff]13:14
rburton[    0.000000]   Normal   [mem 0x0000000001000000-0x000000001fffffff]13:14
rburton[    0.000000]   HighMem  [mem 0x0000000020000000-0x000000009fffefff]13:14
rburtonseems right i guess13:14
zeddiiI'd have to raise RalfB from whereever he's been hiding.13:14
zeddiiyah. to my non-mips eye, it looks reasonable.13:15
zeddiican we leave 32 bit mips slumming with 256M or memory ? I'll have to check the list to see what was breaking with it that low.13:15
rburtonits the gl stuff kanavin_ added that breaks with not enough ram13:16
khemzeddii:whats up with qemumips ? running out of mem ?13:17
zeddiikhem. its (sometimes) hanging when the mem is bumped to 512M13:18
zeddiiRP or rburton may have a more technical description than that though.13:18
rburtonthats the gist of it :)13:18
rburtonmy hunch is that selftest uses more of the ram and qemu doesn't like it and dies13:18
khemrburton:does it function fine with 256 ?13:18
rburtonsort of. the gl pieces need more than 256 to work.13:19
rburtonpaging kanavin for more context there13:19
rburtonkhem: if you understand the traditional mips memory model then looking at what the kernel thinks it found, and what qemu is doing, would be appreciated13:20
khemmips memory accesses are a bit different when its more than 256M it needs to use highmem13:20
khemwe do have CONFIG_HIGHMEM enabled right13:21
rburtonwe do13:21
rburtonkhem: <-- boot with 512mb13:22
rburtonmy working theory is that qemu-system-mips is broken in some way for high memory accesses13:22
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:22
rburtoni guess writing an app to grab all the memory is a way to find out13:22
*** bisbarn <bisbarn!> has joined #yocto13:23
nrossirburton: you could try this, used it to find some microblaze memory bugs previously13:24
rburtonthat saves ten minutes thanks13:25
nrossirburton: if i remember correctly they were highmem bugs as well :|13:25
nrossiRP: this look like a ok implementation for keepalive messages?
*** nabokov <nabokov!~armand@> has quit IRC13:27
kayterinain my-machine.conf I add: APPEND += "lpj=192000" .and it does nothing to cmdline.txt., anyone know why?13:27
RPnrossi: yes, looks good at a quick glance13:27
*** nabokov <nabokov!~armand@> has joined #yocto13:27
*** nabokov <nabokov!~armand@> has quit IRC13:28
RPzeddii: its in systemtap master13:28
zeddiicommit a25199c9580b9b66424c494d3bf39c4d1b7e1f7b (HEAD -> master, origin/master, origin/HEAD)13:28
zeddiiAuthor: Richard Purdie <>13:28
zeddiiDate:   Thu Sep 5 09:13:13 2019 -040013:28
zeddiithese folks need a hobby ;)13:29
*** bisbarn <bisbarn!> has quit IRC13:29
rburtonnrossi: in return my random layer is rossburton/meta-ross on github :)13:31
nrossirburton: its got unigine.... :)13:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:32
khemrburton:secondly do we have CONFIG_NO_BOOTMEM set in kernel13:34
rburton$ git grep NO_BOOTMEM|wc -l13:35
kanavin_rburton, core-image-sato got bumped to 512M because on qemux86-64 X would otherwise fail to start13:35
rburton(linux-yocto, so i'm grepping yocto-kernel-cache)13:36
rburtonkanavin_: maybe thats a x86-64 specific thing and we should just bump that machine?13:36
kanavin_rburton, I would rather bump mips down to 256M actually13:37
kanavin_because it is not using GL13:37
kanavin_and thus doesn't actually need that extra RAM13:37
rburtonjust mips specifically13:37
kanavin_yes - qemumips still defaults to cirrus hardware, and who am I to argue against that :)13:38
rburtonwe can fix that :)13:38
kanavin_rburton, it wasn't obvious to me, but various qemu-system targets have totally different lists of what graphical hardware they can emulate, and what is the default choice in those lists13:38
rburtonvirtio *should* work but would need turning on and testing in qemu13:39
kanavin_so even if you drop -vga cirrus for qemu mips, it will still use it :)13:39
kanavin_virtio is not in the list for mips from what I recall13:39
rburtonright this is roughly where i got to when exploring this a while back13:40
rburtonat some point you reach 'nobody has tried this, but it should work...'13:40
kanavin_I'd suggest just bumping RAM down for mips :-/13:40
kanavin_if we can't get to the bottom of 512M issues13:40
rburton1) bump ram back down 2) investigate memory issue13:40
rburtonso at least we can ship13:40
* zeddii knows where his vote would land13:41
rburtonoh i meant both in order13:41
rburtondrop the memory as its not needed, and look to see if fixing the memory thing is easy for later13:41
RPrburton: I'm leaning to dropping the ram for mips so we can move forward13:42
zeddiiyou needed to put 3) all of the above, to keep some of us from taking the easy way out :D13:42
kanavin_the alternative is to bump RAM up only for x86(64) and see if any other target breaks like x86 did13:42
rburtoni'm happy with marking mips as special here13:43
kanavin_rburton, alexander@alexander-box:~/development/poky/build-virgl-gtk-64/tmp$ ./work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-mips64 -vga help13:44
kanavin_none                 no graphic card13:44
kanavin_std                  standard VGA13:44
kanavin_cirrus               Cirrus VGA (default)13:44
kanavin_vmware               VMWare SVGA13:44
kanavin_xenfb                Xen paravirtualized framebuffer13:44
kanavin_(same for mips 32)13:44
rburtonkanavin_: yeah, there's a load of kconfig pieces in qemu, need to turn the virtio bits on13:44
kanavin_rburton, I am not sure if that can be configured at all, I believe it is hardcoded13:45
kanavin_for comparison alexander@alexander-box:~/development/poky/build-virgl-gtk-64/tmp$ ./work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -vga help13:45
kanavin_none                 no graphic card13:45
kanavin_std                  standard VGA (default)13:45
kanavin_cirrus               Cirrus VGA13:45
kanavin_vmware               VMWare SVGA13:45
nrossiRP: just sent those patches for -initial cleanup, security flags and oe-selftest keepalive13:45
kanavin_xenfb                Xen paravirtualized framebuffer13:45
kanavin_virtio               Virtio VGA13:45
RPnrossi: thanks. There was one other issue I noticed, the glibc-testsuite recipe breaks the source archiver :/13:54
*** AndersD <AndersD!> has quit IRC13:56
nrossiRP: will have a look13:56
*** jofr <jofr!~jofr@> has quit IRC13:57
*** jofr <jofr!~jofr@> has joined #yocto13:57
RPnrossi: a quick guess says PACKAGES = "" may "fix" it13:57
RPnrossi: sorry, I'm kind of thiniking out loud13:58
RPnrossi: I'll throw that into the recipe for the next set of tests13:58
nrossiRP: makes you wonder if nopackages should set PACKAGES = ""14:02
RPnrossi: actually, I think archiver should test for the existence of the task14:03
RPnrossi: we were trying to get away from the zeroing of PACKAGES as that can have unintended side effects14:03
RPIn this recipe it doesn't matter14:03
nrossiRP: ok, I will look at adding the check, you go ahead with ""ing14:04
RPnrossi: thanks14:04
RPnrossi: error: argument -r/--run-tests: not allowed with argument -t/--run-only-tags14:07
RPnrossi: can we change that? I think the autobuilder will need to do that :/14:07
*** likewise <likewise!~leon@> has quit IRC14:07
nrossiRP: aka mixing tags and specific tests?14:08
RPnrossi: yes14:08
nrossiRP: would have to make -t as option instead14:08
nrossiRP: aka -t <foo> -t <bar>14:08
RPnrossi: so be it, we're going to need to be able to list specific tests to exclude14:09
nrossiRP: so i should make the -T the same as well?14:09
RPe.g. -T machine -R  sourcemirror test14:10
RPnrossi: please14:10
*** yacar_ <yacar_!~yacar@> has quit IRC14:16
RPnrossi: just realised that if I tag the tests we include/exclude I could avoid having to use -R and use -T/-t instead14:17
RPnrossi: may still be better to allow the combinations though14:17
nrossiRP: you can just use "-a -T ..." :)14:18
RPnrossi: I'm puzzled where these ptestresults are disappearing14:19
RPnrossi: I see them locally14:19
*** griffinp <griffinp!griffinp@gateway/shell/linaro/x-glcajiuzjrhmniyg> has joined #yocto14:27
*** vmeson <vmeson!~rmacleod@> has quit IRC14:31
nrossiRP: I did initially think it might have something to do with the fact that the tests are now "passing"14:33
nrossiRP: archiver fix patch sent14:42
*** yacar_ <yacar_!~yacar@> has joined #yocto14:52
*** kroon <kroon!~kroon@> has quit IRC14:55
*** frsc <frsc!> has quit IRC15:05
smurrayI hit fetcher failures with libedit trying to build world on latest master last night, anyone else see that15:13
smurrayerror is: ERROR: libedit-20190324-3.1-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; unset _PYTHON_SYSCONFIGDATA_NAME; export PATH="/ws/scottm/dev/oe/test.systemd/test/tmp/sysroots-uni: /bin/sh: 1: -U: not found15:13
smurrayalmost looks like it happens because it falls back to trying a mirror because upstream is unavailable15:15
smurrayah, no, it's FETCHCMD_wget tinkering seems wrong.  Now I'm confused as to how it worked previously15:19
RPnrossi: it breaks for oe-selftest -j X15:21
RPnrossi: i.e. when we enable paralleliam15:21
nrossiRP: what breaks? the keepalive?15:22
RPnrossi: the reason the ptestresults don't make the json file15:24
RPnrossi: I've proven it locally15:25
nrossiRP: ah that explains why i never saw it. Do you know if its a general issue with how tc.extra is accessed or specific to how the toolchain cases populate it?15:25
RPnrossi: probably related to how tc.extra is processed15:26
RPnrossi: selftest doesn't usually add ptest results until now and runtime never uses -j15:26
RPnrossi: I've not looked at why yet but at least we now know how to reproduce15:27
nrossiRP: I wont be able to look at it today, will look at it tomorrow along with -t/-T changes15:29
RPnrossi: no problem, thanks for the heads up. I'll let you know if I've looked at it15:30
* RP isn't sure how much of a chance he'll get15:31
rburtonsmurray: delete the tinkering (patch on the list)15:33
*** berton_ <berton_!~berton@> has joined #yocto15:33
*** xtron <xtron!~xtron@> has quit IRC15:34
smurrayrburton: ah, I did a quick look, missed15:34
smurrayrburton: it's not clear to me how that worked before, given the way FETCHCMD_wget is used15:36
*** berton <berton!~berton@> has quit IRC15:36
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has joined #yocto15:48
*** WillMiles <WillMiles!> has joined #yocto15:52
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has quit IRC15:53
*** yacar_ <yacar_!~yacar@> has quit IRC15:55
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:07
kergothhuh, vscode with Remote - SSH is pretty nice, even with bitbake stuff16:07
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:10
*** kroon <kroon!> has joined #yocto16:10
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has joined #yocto16:13
*** yann <yann!~yann@> has quit IRC16:15
rburtonkergoth: yeah tried it yesterday16:16
rburtonpresumably the git stuff all works too16:16
rburtonhaven't yet tried that16:16
rburtonis there a proper bitbake extension yet that does more than just syntax highlighting?16:17
kergothit does, though can get a little slow and can run into inotify limits on file monitoring16:17
kergothgood question16:17
rburtonright, had to bump the inotify limit already16:17
kergothhuh, ctrl+click will open an included/inherited/reuiqred file, and ctrl+space will complete inherit/etc, it seems?16:19
kergothin the most popular bitbake extension16:19
* kergoth tries ti16:19
rburtonholy crap16:22
rburtonthats witchcraft16:22
*** mckoan is now known as mckoan|away16:27
*** aehs29 <aehs29!~aehs29@> has quit IRC16:35
*** tprrt <tprrt!~tprrt@> has quit IRC16:36
*** aehs29 <aehs29!~aehs29@> has joined #yocto16:39
tgoodwinI'm trying to run bitbake in a container drived from CROPS/poky:ubuntu-18.04 via gitlab-ci and am running a sanity check "bitbake -n world", but bitbake fails parsing serf no matter which branch of poky I use.  Has anyone ever seen that?16:48
*** diego_r <diego_r!> has quit IRC16:49
smurrayheh, that was my first thought.  Seems there's a serf recipe16:49
smurray"High-Performance Asynchronous HTTP Client Library"16:50
smurrayit looks to be the only thing that uses the scons.bbclass16:50
tgoodwinsmurray: yes, it's over in recipes-support/serf16:50
Crofton|workand depends on py and py3 versions16:50
smurrayCrofton|work: ?  not in master afaics16:51
smurrayCrofton|work: I can't see how that can be correct, neither the recipe nor scons.bbclass refer to python-scons-native16:52
smurrayCrofton|work: and it built for me when I tested last week in a container w/o python216:53
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:53
smurraytgoodwin: can you pastebin the parse error?16:53
tgoodwinsmurray: sure;
smurrayCrofton|work: heh, subversion requires serf16:54
smurraytgoodwin: which branch was that from?16:55
smurraytgoodwin: warrior, I'm guessing?16:56
tgoodwinsmurray: that one was master.  I've tried thud; it dies in the same spot.16:58
smurraytgoodwin: I'd have to guess you've maybe set PARALLEL_MAKE or the like?16:58
tgoodwinsmurray: yes16:58
smurraytgoodwin: can't have been master, it does not have anything to muck with -j that I can see in scons.bbclass16:58
smurraythe do_compile in the serf recipe in warrior does, though16:59
tgoodwinWhen I run this outside of the gitlab-runner environment, it's fine... Weird.17:00
smurraytgoodwin: are you trying to set PARALLEL_MAKE globally, or BB_NUMBER_THREADS?17:01
tgoodwinsmurray: both, globally17:01
tgoodwinin an auto.conf17:01
smurraytgoodwin: hrm, you shouldn't need to change PARALLEL_MAKE afaik17:01
smurrayah, there is a use of PARALLEL_MAKE in scons.bbclass in master, missed it the first time I looked17:03
Crofton|workis the use of subversion my fault?17:03
tgoodwinsmurray: I'm porting over a build from the autobuilder2 setup where the default sets both values; I can remove them.  I think I just found a typo actually in PARALLEL_MAKE.17:03
RPtgoodwin: you're moving from ab-2 to gitlab-ci?17:03
smurrayCrofton|work: no, just amuses me that library is included just for subversion17:03
smurraytgoodwin: it does look like a quoting issue or the like17:04
tgoodwinRP: testing it out; we use it for everything else.17:04
RPtgoodwin: fair enough, just curious17:04
RPrburton: second mention of gitlab today...17:04
tgoodwinsmurray: I was missing a trailing } in PARALLEL_MAKE = "-j ${BB_NUMBER_THREADS"17:04
tgoodwinThat fixed it.17:05
* tgoodwin doh!17:05
tgoodwinThanks y'all.17:05
smurrayall good17:05
Crofton|workpeople like to minimize the number of tools used. Why I use git submodules for layer management, not perfect, but I alady know 90% of what I need to know17:05
Crofton|workfascinating error for that case :)17:05
smurrayCrofton|work: heh, I always have to do "git submodule --help"17:05
kergothwhen i use submodules, i also use 'mr' to avoid using submodule commands more often than not17:06
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto17:11
tgoodwinRP: depending on how this works out, I'll probably post how to do it.  I patched the crops/poky container builds (on my end) to allow for scripts to be passed as arguments (making it compatible with Docker's ENTRYPOINT needs with the runner).  Then the gitlab docker runner, it has a volume mount to the output shared directory for sstate, etc. and am using "cache" between jobs to pass what few artifacts we need (build/conf17:12
tgoodwinand layers).17:12
*** WillMiles <WillMiles!> has quit IRC17:13
tgoodwinThe frustrating part of it so far is not being able to use cache at the local workstation to test each stage.17:13
tgoodwinAt this point though it's running into the same mechanical problems as AB2's helper.17:13
tgoodwin(our problems, obviously, because of what we're trying to accomplish)17:18
*** kaspter <kaspter!~Instantbi@2409:8928:64e:1680:545a:12f3:1e8b:5f80> has quit IRC17:27
rburtonRP: i've got travis doing dumb ci for meta-acrn, it's just a parse and dry-run build but that's better than nothing18:23
rburton(on the free travis plan)18:23
rburtonnext step is to run a container here and get it doing actual builds18:23
rburtonobviously just a very quick smoketest, but again better than nothing18:26
rburtonfor meta-acrn we've a nice small subset that we care about18:26
*** berton_ <berton_!~berton@> has quit IRC18:54
*** berton <berton!~berton@> has joined #yocto18:58
khemrburton: I use and have put in for meta-clang18:59
khemworks nicely, its all docker based flow as well, even runs on docker itself18:59
khemso my server can be torn and rebuilt in mins19:00
yoctiNew news from stackoverflow: Same build/source code for multiple machines in Yocto <>19:17
*** berton <berton!~berton@> has quit IRC19:40
*** berton <berton!~berton@> has joined #yocto19:45
*** armpit <armpit!~armpit@2601:202:4180:c33:811a:fbd5:24bc:2160> has quit IRC19:49
*** armpit <armpit!~armpit@2601:202:4180:c33:1428:d184:917c:1fd5> has joined #yocto20:01
*** sa2ajj <sa2ajj!> has quit IRC20:07
*** kroon <kroon!> has quit IRC20:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:17
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:17
*** rewitt <rewitt!rewitt@nat/intel/x-hrzfvohlnvxyqomo> has joined #yocto20:29
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC20:46
*** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto20:47
*** zbooth <zbooth!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto20:52
*** diego_r <diego_r!~diego@> has joined #yocto20:54
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC20:57
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:59
*** berton <berton!~berton@> has quit IRC21:15
yoctiNew news from stackoverflow: YOCTO : remove all my led drivers from my yocto linux os image <>21:17
*** vmeson <vmeson!> has joined #yocto21:20
RPtgoodwin: definitely worth posting about, I'm curious21:21
RPrburton: makes sense21:22
rburtonkhem: can you share your setup for that?21:49
*** agust <agust!> has quit IRC21:55
*** diego_r <diego_r!~diego@> has quit IRC21:56
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC22:26
rburtonzeddii: can i blame you for
zeddiinot easily. :D this is the kernel module test that marka from wind river is trying to replace.23:10
zeddiiout of tree modules build fine. that one just has some sort of config issues that Mark was describing.23:10
zeddiibut I can check to see if something it requires is not removed, renamed or just gone.23:11
*** JaMa <JaMa!> has quit IRC23:24
*** stephano <stephano!~stephano@2620:10d:c090:380::1:132d> has joined #yocto23:27
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC23:38
*** rburton <rburton!> has quit IRC23:40
*** rburton <rburton!> has joined #yocto23:51

Generated by 2.11.0 by Marius Gedminas - find it at!