**** BEGIN LOGGING AT Thu Sep 05 03:00:58 2019
Sep 05 03:10:16 <zeddii> RP: 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.
Sep 05 03:54:46 <mtahmed> Hi 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.dot
Sep 05 03:55:44 <mtahmed> I 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.dot
Sep 05 04:14:34 <yocti> New news from stackoverflow: do_rootfs function failed in yocto project <https://stackoverflow.com/questions/50015694/do-rootfs-function-failed-in-yocto-project>
Sep 05 06:14:51 <yocti> New news from stackoverflow: Unable to start bitbake server <https://stackoverflow.com/questions/48132054/unable-to-start-bitbake-server>
Sep 05 06:52:38 <qschulz> fullstop: glad it's fixed :) Thanks for letting us know!
Sep 05 07:24:56 <RP> zeddii: I just updated to a new git version so the patch was ammended
Sep 05 08:15:13 <yocti> New news from stackoverflow: YOCTO : No '/lib/modules' directory in image, modprobe fails <https://stackoverflow.com/questions/57656086/yocto-no-lib-modules-directory-in-image-modprobe-fails>
Sep 05 08:39:28 <cengiz_io> hello 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?
Sep 05 08:40:41 <cengiz_io> running 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 virtu
Sep 05 08:40:41 <cengiz_io> al/kernel` runs menuconfig (devshell) via `screen` command. I can't modify those arguments because they all come from OpenEmbedded distro.
Sep 05 08:40:50 <cengiz_io> my yocto branch is `thud`
Sep 05 09:27:28 <feilz> cengiz_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).
Sep 05 09:27:44 <feilz> i introduced the changes using patch files to my kernel
Sep 05 09:31:52 <qschulz> feilz: you need menuconfig, then savedefconfig and then use a patch to replace the defconfig in question IIRC
Sep 05 09:46:39 <likewise> I have gdb-cross built. How can I easily call it directly without first going through the BSP flow?
Sep 05 09:47:13 <likewise> I recon I would need to create the combined sysroot for gdb-cross-<target-arch>, but I do not know how to do this.
Sep 05 09:48:07 <likewise> (Calling gdb-cross directly worked in older releases, but broke when sysroot got componentized).
Sep 05 10:02:26 <feilz> qschulz: 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 using
Sep 05 10:03:39 <feilz> I 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 working
Sep 05 10:03:40 <qschulz> feilz: you did bitbake virtual/kernel -c menuconfig right?
Sep 05 10:04:31 <feilz> i used that command, yes.
Sep 05 10:04:32 <qschulz> you have to use this command after the do_configure of the kernel I think, otherwise there is no .config
Sep 05 10:05:40 <feilz> problem with the .config was as well since every build I made I basically rewrote the temp kernel (through changes).
Sep 05 10:05:47 <feilz> and it usually got lost.
Sep 05 10:06:30 <feilz> hence 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.
Sep 05 10:06:36 <feilz> that way I got them incorporated
Sep 05 10:07:23 <feilz> later on I just learned to read the Kconfig files to find the correct config values to get what I needed
Sep 05 10:07:27 <qschulz> feilz: not ideal as .config has way more info than necessary compared to a defconfig
Sep 05 10:07:43 <qschulz> feilz: don't do that please, use menuconfig and savedefconfig
Sep 05 10:07:55 <qschulz> you'll get into trouble faster than you think
Sep 05 10:08:05 <qschulz> pulling your hair for no reason
Sep 05 10:08:39 <qschulz> because you forgot that one depends on that this Kconfig option relied one through the 10th selects Kconfig
Sep 05 10:09:12 <feilz> well... 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 me
Sep 05 10:09:47 <feilz> grep is quite a handy command to find all the dependencies
Sep 05 10:10:17 <feilz> not ideal, I agree.
Sep 05 10:19:14 <rburton> ok any MIPS experts around?
Sep 05 11:36:54 <nrossi> RP: i think i've sorted those gcc test issues i linked yesterday, https://github.com/nathanrossi/openembedded-core/commit/5cbb4f9fad777d20a5905ad305ed54fe2a618e81
Sep 05 11:38:06 <nrossi> RP: 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 https://github.com/nathanrossi/openembedded-core/commit/fa9f3d3af965bcb9598661e62003595683045493
Sep 05 11:39:09 <nrossi> RP: 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?
Sep 05 11:39:43 <rsalveti> khem: thanks for sending the patch!
Sep 05 11:44:06 <RP> nrossi: first change looks good, we should probably duplicate entries for the second, I'm curious which other pn overrides there would be?
Sep 05 11:44:32 <RP> nrossi: glibc-initial is definitely gone, those are just leftovers and should be cleaned up
Sep 05 11:44:59 <RP> nrossi: I've been thinking about the autobuilder integration of this and have run into a few challenges.
Sep 05 11:45:25 <RP> nrossi: resulttool doesn't seem to be processing things entirely correctly :/
Sep 05 11:46:03 <nrossi> RP: by duplicate entries you mean add duplicate entries to e.g. security_flags? or something else?
Sep 05 11:46:07 <RP> nrossi: https://autobuilder.yocto.io/pub/non-release/20190904-7/testresults/testresult-report.txt - no gcc results in the ptest tables
Sep 05 11:46:16 <nrossi> RP: other layers override based on glibc, e.g. https://github.com/kraj/meta-clang/blob/master/conf/nonclangable.conf#L12
Sep 05 11:46:17 <RP> nrossi: yes, security_flags
Sep 05 11:46:46 <RP> nrossi: those other layers should really adapt to the change
Sep 05 11:46:50 <nrossi> RP: yes i noticed the missing results, was very confused
Sep 05 11:47:07 <RP> nrossi: the results are there, its just not processing them as we'd want
Sep 05 11:47:36 <nrossi> RP: are you sure? i looked at the testresults.json file from one of those builds and the ptestresults entries were not there
Sep 05 11:48:30 <nrossi> RP: https://autobuilder.yocto.io/pub/non-release/20190904-7/testresults/qemux86-64/testresults.json <- or are they trimmed somewhere?
Sep 05 11:48:42 <RP> nrossi: ah, you're right. They're not in https://autobuilder.yocto.io/pub/non-release/20190904-7/testresults/qemux86-64/testresults.json
Sep 05 11:49:12 <RP> nrossi: ok, need to investigate that
Sep 05 11:49:20 <RP> nrossi: we also have a timeout problem on long running tests
Sep 05 11:49:33 <RP> nrossi: bitbake prints a "keepalive" to the console but oe-selftest does not
Sep 05 11:50:26 <nrossi> RP: by keepalive, you just mean like a newline or similar yes?
Sep 05 11:50:39 <nrossi> RP: not a special string
Sep 05 11:51:03 <RP> nrossi: It just prints "still alive <time>" or similar
Sep 05 11:51:31 <nrossi> RP: I can look at doing that
Sep 05 11:51:34 <RP> nrossi: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fcec90de9c2c4abb64780628193f0631c0b296ad
Sep 05 11:52:40 <RP> nrossi: devil is in the detail now :)
Sep 05 11:52:49 <nrossi> RP: oh btw, you left the pexpect commit in master-next when you rebased
Sep 05 11:56:01 <RP> nrossi: yes, sorry. won't hurt anything
Sep 05 11:56:20 <RP> nrossi: gone now :)
Sep 05 11:57:09 <nrossi> RP: 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 filtered
Sep 05 11:57:42 <RP> nrossi: no objection as such
Sep 05 11:58:41 <nrossi> RP: 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 met
Sep 05 11:59:46 <nrossi> RP: 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 x86
Sep 05 12:02:39 <RP> nrossi: how does that help compared to what is there now?
Sep 05 12:03:47 <RP> nrossi: 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 arch
Sep 05 12:05:05 <nrossi> RP: that works too, but how would you run the glibc system tests for all machines?
Sep 05 12:06:11 <RP> nrossi: not sure I understand the question?
Sep 05 12:07:14 <nrossi> RP: 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 testing
Sep 05 12:08:00 <RP> nrossi: I'd guess that piece of policy would be down to some variable doing configuration
Sep 05 12:08:28 <RP> nrossi: or we just markup with extra tags to match the pattern we need?
Sep 05 12:08:49 <RP> nrossi: I assume a test or class can have more than one tag?
Sep 05 12:09:06 <nrossi> RP: yes
Sep 05 12:10:28 <nrossi> RP: but the slight annoyance is that classes will inherit tags, so might need to sort that out
Sep 05 12:13:03 <RP> nrossi: you mean all tests within a class inherit tags and all subclasses of a class?
Sep 05 12:13:16 <nrossi> RP: yer
Sep 05 13:04:09 <RP> zeddii: figured out the qemuarm systemtap issue
Sep 05 13:08:19 <zeddii> lol. I was just about to say "i reproduced it!"
Sep 05 13:08:29 <zeddii>                  from /tmp/stapy2SORD/stap_1381_src.c:26:
Sep 05 13:08:29 <zeddii>   261 |   get_fs() == get_ds() ? "kernel" : "user");
Sep 05 13:08:30 <zeddii>       |               ^~~~~~
Sep 05 13:08:30 <zeddii>       |               get_fs
Sep 05 13:08:33 <zeddii> cc1: all warnings being treated as errors
Sep 05 13:08:35 <zeddii> make[1]: *** [scripts/Makefile.build:278: /tmp/stapy2SORD/stap_1381_src.o] Error 1
Sep 05 13:08:37 * zeddii feels the need to prove it :D
Sep 05 13:09:19 <zeddii> I 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 :D
Sep 05 13:09:39 <RP> zeddii: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-kernel/systemtap/systemtap/fixarm.patch?h=master-next&id=e1dddc042ad1396af045e701adc9488715b1b22c
Sep 05 13:10:24 <zeddii> yah. last night in my kernel checking I saw that it had been removed. that
Sep 05 13:10:32 <zeddii> that's the right thing to do to get it back up and running.
Sep 05 13:10:50 <RP> zeddii: mentioning to upstream, see if they like the patch
Sep 05 13:11:54 <zeddii> I 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.
Sep 05 13:13:03 <zeddii> so it is just the mips highmem lockup now ? and that beastie is not 100% reproducible ?
Sep 05 13:13:31 <rburton> zeddii: know anyone who knows mips memory layout?
Sep 05 13:13:49 <rburton> my  limited understanding is that mips 32-bit is a bit of a mess but linux appears to be doing the right thing
Sep 05 13:13:55 <rburton> but hey i know nothing about mips
Sep 05 13:14:14 <rburton> [    0.000000] Zone ranges:
Sep 05 13:14:14 <rburton> [    0.000000]   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
Sep 05 13:14:16 <rburton> [    0.000000]   Normal   [mem 0x0000000001000000-0x000000001fffffff]
Sep 05 13:14:16 <rburton> [    0.000000]   HighMem  [mem 0x0000000020000000-0x000000009fffefff]
Sep 05 13:14:18 <rburton> seems right i guess
Sep 05 13:14:57 <zeddii> I'd have to raise RalfB from whereever he's been hiding.
Sep 05 13:15:12 <zeddii> yah. to my non-mips eye, it looks reasonable.
Sep 05 13:15:54 <zeddii> can 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.
Sep 05 13:16:51 <rburton> its the gl stuff kanavin_ added that breaks with not enough ram
Sep 05 13:17:12 <khem> zeddii:whats up with qemumips ? running out of mem ?
Sep 05 13:18:04 <zeddii> khem. its (sometimes) hanging when the mem is bumped to 512M
Sep 05 13:18:27 <zeddii> RP or rburton may have a more technical description than that though.
Sep 05 13:18:33 <rburton> thats the gist of it :)
Sep 05 13:18:50 <rburton> my hunch is that selftest uses more of the ram and qemu doesn't like it and dies
Sep 05 13:18:53 <khem> rburton:does it function fine with 256 ?
Sep 05 13:19:10 <rburton> sort of. the gl pieces need more than 256 to work.
Sep 05 13:19:17 <rburton> paging kanavin for more context there
Sep 05 13:20:01 <rburton> khem: if you understand the traditional mips memory model then looking at what the kernel thinks it found, and what qemu is doing, would be appreciated
Sep 05 13:20:39 <khem> mips memory accesses are a bit different when its more than 256M it needs to use highmem
Sep 05 13:21:16 <rburton> right
Sep 05 13:21:27 <khem> we do have CONFIG_HIGHMEM enabled right
Sep 05 13:21:29 <rburton> we do
Sep 05 13:22:05 <rburton> khem: https://pastebin.com/qMvjJEum <-- boot with 512mb
Sep 05 13:22:31 <rburton> my working theory is that qemu-system-mips is broken in some way for high memory accesses
Sep 05 13:22:47 <rburton> i guess writing an app to grab all the memory is a way to find out
Sep 05 13:24:11 <nrossi> rburton: you could try this, https://github.com/nathanrossi/meta-random/blob/master/recipes-tests/tests/files/test-malloc-balloon.c used it to find some microblaze memory bugs previously
Sep 05 13:25:10 <rburton> that saves ten minutes thanks
Sep 05 13:25:46 <nrossi> rburton: if i remember correctly they were highmem bugs as well :|
Sep 05 13:26:29 <nrossi> RP: this look like a ok implementation for keepalive messages? https://github.com/nathanrossi/openembedded-core/commit/39ccda0852f3e286693afcba2098f15bba6b50e4
Sep 05 13:27:28 <kayterina> in my-machine.conf I add: APPEND += "lpj=192000" .and it does nothing to cmdline.txt., anyone know why?
Sep 05 13:27:34 <RP> nrossi: yes, looks good at a quick glance
Sep 05 13:28:10 <RP> zeddii: its in systemtap master
Sep 05 13:28:58 <zeddii> commit a25199c9580b9b66424c494d3bf39c4d1b7e1f7b (HEAD -> master, origin/master, origin/HEAD)
Sep 05 13:28:59 <zeddii> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Sep 05 13:28:59 <zeddii> Date:   Thu Sep 5 09:13:13 2019 -0400
Sep 05 13:29:09 <zeddii> these folks need a hobby ;)
Sep 05 13:31:34 <rburton> nrossi: in return my random layer is rossburton/meta-ross on github :)
Sep 05 13:32:25 <nrossi> rburton: its got unigine.... :)
Sep 05 13:34:32 <khem> rburton:secondly do we have CONFIG_NO_BOOTMEM set in kernel
Sep 05 13:35:48 <rburton> $ git grep NO_BOOTMEM|wc -l
Sep 05 13:35:48 <rburton> 0
Sep 05 13:35:57 <kanavin_> rburton, core-image-sato got bumped to 512M because on qemux86-64 X would otherwise fail to start
Sep 05 13:36:01 <rburton> (linux-yocto, so i'm grepping yocto-kernel-cache)
Sep 05 13:36:24 <rburton> kanavin_: maybe thats a x86-64 specific thing and we should just bump that machine?
Sep 05 13:37:05 <kanavin_> rburton, I would rather bump mips down to 256M actually
Sep 05 13:37:14 <kanavin_> because it is not using GL
Sep 05 13:37:23 <kanavin_> and thus doesn't actually need that extra RAM
Sep 05 13:37:45 <rburton> just mips specifically
Sep 05 13:37:46 <rburton> ?
Sep 05 13:38:09 <kanavin_> yes - qemumips still defaults to cirrus hardware, and who am I to argue against that :)
Sep 05 13:38:42 <rburton> we can fix that :)
Sep 05 13:38:54 <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 lists
Sep 05 13:39:04 <rburton> yes
Sep 05 13:39:27 <rburton> virtio *should* work but would need turning on and testing in qemu
Sep 05 13:39:28 <kanavin_> so even if you drop -vga cirrus for qemu mips, it will still use it :)
Sep 05 13:39:45 <kanavin_> virtio is not in the list for mips from what I recall
Sep 05 13:40:01 <rburton> right this is roughly where i got to when exploring this a while back
Sep 05 13:40:15 <rburton> at some point you reach 'nobody has tried this, but it should work...'
Sep 05 13:40:25 <kanavin_> I'd suggest just bumping RAM down for mips :-/
Sep 05 13:40:35 <kanavin_> if we can't get to the bottom of 512M issues
Sep 05 13:40:44 <rburton> 1) bump ram back down 2) investigate memory issue
Sep 05 13:40:52 <rburton> so at least we can ship
Sep 05 13:41:10 * zeddii knows where his vote would land
Sep 05 13:41:23 <rburton> oh i meant both in order
Sep 05 13:41:45 <rburton> drop the memory as its not needed, and look to see if fixing the memory thing is easy for later
Sep 05 13:42:35 <RP> rburton: I'm leaning to dropping the ram for mips so we can move forward
Sep 05 13:42:39 <zeddii> you needed to put 3) all of the above, to keep some of us from taking the easy way out :D
Sep 05 13:42:44 <rburton> haha
Sep 05 13:42:48 <kanavin_> the alternative is to bump RAM up only for x86(64) and see if any other target breaks like x86 did
Sep 05 13:43:22 <rburton> i'm happy with marking mips as special here
Sep 05 13:44:25 <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 help
Sep 05 13:44:26 <kanavin_> none                 no graphic card
Sep 05 13:44:26 <kanavin_> std                  standard VGA
Sep 05 13:44:26 <kanavin_> cirrus               Cirrus VGA (default)
Sep 05 13:44:26 <kanavin_> vmware               VMWare SVGA
Sep 05 13:44:27 <kanavin_> xenfb                Xen paravirtualized framebuffer
Sep 05 13:44:44 <kanavin_> (same for mips 32)
Sep 05 13:44:49 <rburton> kanavin_: yeah, there's a load of kconfig pieces in qemu, need to turn the virtio bits on
Sep 05 13:45:30 <kanavin_> rburton, I am not sure if that can be configured at all, I believe it is hardcoded
Sep 05 13:45:37 <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 help
Sep 05 13:45:41 <kanavin_> none                 no graphic card
Sep 05 13:45:41 <kanavin_> std                  standard VGA (default)
Sep 05 13:45:41 <kanavin_> cirrus               Cirrus VGA
Sep 05 13:45:41 <kanavin_> vmware               VMWare SVGA
Sep 05 13:45:43 <nrossi> RP: just sent those patches for -initial cleanup, security flags and oe-selftest keepalive
Sep 05 13:45:43 <kanavin_> xenfb                Xen paravirtualized framebuffer
Sep 05 13:45:45 <kanavin_> virtio               Virtio VGA
Sep 05 13:54:43 <RP> nrossi: thanks. There was one other issue I noticed, the glibc-testsuite recipe breaks the source archiver :/
Sep 05 13:55:05 <RP> nrossi: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/685
Sep 05 13:56:35 <nrossi> RP: will have a look
Sep 05 13:57:33 <RP> nrossi: a quick guess says PACKAGES = "" may "fix" it
Sep 05 13:58:06 <RP> nrossi: sorry, I'm kind of thiniking out loud
Sep 05 13:58:20 <RP> nrossi: I'll throw that into the recipe for the next set of tests
Sep 05 14:02:54 <nrossi> RP: makes you wonder if nopackages should set PACKAGES = ""
Sep 05 14:03:11 <RP> nrossi: actually, I think archiver should test for the existence of the task
Sep 05 14:03:30 <RP> nrossi: we were trying to get away from the zeroing of PACKAGES as that can have unintended side effects
Sep 05 14:03:58 <RP> In this recipe it doesn't matter
Sep 05 14:04:26 <nrossi> RP: ok, I will look at adding the check, you go ahead with ""ing
Sep 05 14:04:48 <RP> nrossi: thanks
Sep 05 14:07:08 <RP> nrossi: error: argument -r/--run-tests: not allowed with argument -t/--run-only-tags
Sep 05 14:07:24 <RP> nrossi: can we change that? I think the autobuilder will need to do that :/
Sep 05 14:08:00 <nrossi> RP: aka mixing tags and specific tests?
Sep 05 14:08:06 <RP> nrossi: yes
Sep 05 14:08:31 <nrossi> RP: would have to make -t as option instead
Sep 05 14:08:54 <nrossi> RP: aka -t <foo> -t <bar>
Sep 05 14:09:21 <RP> nrossi: so be it, we're going to need to be able to list specific tests to exclude
Sep 05 14:09:57 <nrossi> RP: so i should make the -T the same as well?
Sep 05 14:10:09 <RP> e.g. -T machine -R  sourcemirror test
Sep 05 14:10:15 <RP> nrossi: please
Sep 05 14:17:17 <RP> nrossi: just realised that if I tag the tests we include/exclude I could avoid having to use -R and use -T/-t instead
Sep 05 14:17:35 <RP> nrossi: may still be better to allow the combinations though
Sep 05 14:18:19 <nrossi> RP: you can just use "-a -T ..." :)
Sep 05 14:19:53 <RP> nrossi: I'm puzzled where these ptestresults are disappearing
Sep 05 14:19:57 <RP> nrossi: I see them locally
Sep 05 14:33:23 <nrossi> RP: I did initially think it might have something to do with the fact that the tests are now "passing"
Sep 05 14:42:45 <nrossi> RP: archiver fix patch sent
Sep 05 15:02:54 <Crofton|work> RP, https://twitter.com/nixcraft/status/1169570226221961217?s=20
Sep 05 15:13:25 <smurray> I hit fetcher failures with libedit trying to build world on latest master last night, anyone else see that
Sep 05 15:13:48 <smurray> error 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 found
Sep 05 15:15:57 <smurray> almost looks like it happens because it falls back to trying a mirror because upstream is unavailable
Sep 05 15:19:54 <smurray> ah, no, it's FETCHCMD_wget tinkering seems wrong.  Now I'm confused as to how it worked previously
Sep 05 15:21:29 <RP> nrossi: it breaks for oe-selftest -j X
Sep 05 15:21:35 <RP> nrossi: i.e. when we enable paralleliam
Sep 05 15:22:28 <nrossi> RP: what breaks? the keepalive?
Sep 05 15:24:00 <RP> nrossi: the reason the ptestresults don't make the json file
Sep 05 15:25:11 <RP> nrossi: I've proven it locally
Sep 05 15:25:54 <nrossi> RP: 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?
Sep 05 15:26:18 <RP> nrossi: probably related to how tc.extra is processed
Sep 05 15:26:42 <RP> nrossi: selftest doesn't usually add ptest results until now and runtime never uses -j
Sep 05 15:27:25 <RP> nrossi: I've not looked at why yet but at least we now know how to reproduce
Sep 05 15:29:53 <nrossi> RP: I wont be able to look at it today, will look at it tomorrow along with -t/-T changes
Sep 05 15:30:57 <RP> nrossi: no problem, thanks for the heads up. I'll let you know if I've looked at it
Sep 05 15:31:52 * RP isn't sure how much of a chance he'll get
Sep 05 15:33:48 <rburton> smurray: delete the tinkering (patch on the list)
Sep 05 15:34:25 <smurray> rburton: ah, I did a quick look, missed
Sep 05 15:36:05 <smurray> rburton: it's not clear to me how that worked before, given the way FETCHCMD_wget is used
Sep 05 16:07:19 <kergoth> huh, vscode with Remote - SSH is pretty nice, even with bitbake stuff
Sep 05 16:16:21 <rburton> kergoth: yeah tried it yesterday
Sep 05 16:16:42 <rburton> presumably the git stuff all works too
Sep 05 16:16:47 <rburton> haven't yet tried that
Sep 05 16:17:05 <rburton> is there a proper bitbake extension yet that does more than just syntax highlighting?
Sep 05 16:17:08 <kergoth> it does, though can get a little slow and can run into inotify limits on file monitoring
Sep 05 16:17:14 <kergoth> good question
Sep 05 16:17:20 <rburton> right, had to bump the inotify limit already
Sep 05 16:19:37 <kergoth> huh, ctrl+click will open an included/inherited/reuiqred file, and ctrl+space will complete inherit/etc, it seems?
Sep 05 16:19:45 <kergoth> in the most popular bitbake extension
Sep 05 16:19:46 * kergoth tries ti
Sep 05 16:22:05 <rburton> holy crap
Sep 05 16:22:17 <rburton> thats witchcraft
Sep 05 16:48:19 <tgoodwin> I'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?
Sep 05 16:49:14 <Crofton|work> perf?
Sep 05 16:49:36 <smurray> heh, that was my first thought.  Seems there's a serf recipe
Sep 05 16:49:43 <Crofton|work> vscode?
Sep 05 16:50:00 <smurray> "High-Performance Asynchronous HTTP Client Library"
Sep 05 16:50:08 <smurray> it looks to be the only thing that uses the scons.bbclass
Sep 05 16:50:20 <tgoodwin> smurray: yes, it's over in recipes-support/serf
Sep 05 16:50:22 <Crofton|work> and depends on py and py3 versions
Sep 05 16:51:07 <smurray> Crofton|work: ?  not in master afaics
Sep 05 16:51:18 <Crofton|work> http://layers.openembedded.org/layerindex/recipe/28439/
Sep 05 16:52:00 <Crofton|work> weird
Sep 05 16:52:42 <smurray> Crofton|work: I can't see how that can be correct, neither the recipe nor scons.bbclass refer to python-scons-native
Sep 05 16:53:12 <smurray> Crofton|work: and it built for me when I tested last week in a container w/o python2
Sep 05 16:53:27 <smurray> tgoodwin: can you pastebin the parse error?
Sep 05 16:54:16 <tgoodwin> smurray: sure; https://pastebin.com/uweLnrmK
Sep 05 16:54:16 <smurray> Crofton|work: heh, subversion requires serf
Sep 05 16:55:57 <smurray> tgoodwin: which branch was that from?
Sep 05 16:56:38 <smurray> tgoodwin: warrior, I'm guessing?
Sep 05 16:58:06 <tgoodwin> smurray: that one was master.  I've tried thud; it dies in the same spot.
Sep 05 16:58:10 <smurray> tgoodwin: I'd have to guess you've maybe set PARALLEL_MAKE or the like?
Sep 05 16:58:29 <tgoodwin> smurray: yes
Sep 05 16:58:39 <smurray> tgoodwin: can't have been master, it does not have anything to muck with -j that I can see in scons.bbclass
Sep 05 16:59:05 <smurray> the do_compile in the serf recipe in warrior does, though
Sep 05 17:00:51 <tgoodwin> When I run this outside of the gitlab-runner environment, it's fine... Weird.
Sep 05 17:01:08 <smurray> tgoodwin: are you trying to set PARALLEL_MAKE globally, or BB_NUMBER_THREADS?
Sep 05 17:01:19 <tgoodwin> smurray: both, globally
Sep 05 17:01:23 <tgoodwin> in an auto.conf
Sep 05 17:01:37 <smurray> tgoodwin: hrm, you shouldn't need to change PARALLEL_MAKE afaik
Sep 05 17:03:09 <smurray> ah, there is a use of PARALLEL_MAKE in scons.bbclass in master, missed it the first time I looked
Sep 05 17:03:18 <Crofton|work> is the use of subversion my fault?
Sep 05 17:03:24 <tgoodwin> smurray: 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.
Sep 05 17:03:51 <RP> tgoodwin: you're moving from ab-2 to gitlab-ci?
Sep 05 17:03:54 <smurray> Crofton|work: no, just amuses me that library is included just for subversion
Sep 05 17:04:11 <smurray> tgoodwin: it does look like a quoting issue or the like
Sep 05 17:04:12 <tgoodwin> RP: testing it out; we use it for everything else.
Sep 05 17:04:23 <RP> tgoodwin: fair enough, just curious
Sep 05 17:04:36 <RP> rburton: second mention of gitlab today...
Sep 05 17:04:44 <tgoodwin> smurray: I was missing a trailing } in PARALLEL_MAKE = "-j ${BB_NUMBER_THREADS"
Sep 05 17:04:53 <Crofton|work> heh
Sep 05 17:05:03 <tgoodwin> That fixed it.
Sep 05 17:05:08 * tgoodwin doh!
Sep 05 17:05:11 <tgoodwin> Thanks y'all.
Sep 05 17:05:13 <smurray> all good
Sep 05 17:05:25 <Crofton|work> people 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 know
Sep 05 17:05:42 <Crofton|work> fascinating error for that case :)
Sep 05 17:05:45 <smurray> Crofton|work: heh, I always have to do "git submodule --help"
Sep 05 17:06:58 <kergoth> when i use submodules, i also use 'mr' to avoid using submodule commands more often than not
Sep 05 17:12:35 <tgoodwin> RP: 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/conf
Sep 05 17:12:35 <tgoodwin> and layers).
Sep 05 17:13:25 <tgoodwin> The frustrating part of it so far is not being able to use cache at the local workstation to test each stage.
Sep 05 17:13:57 <tgoodwin> At this point though it's running into the same mechanical problems as AB2's helper.
Sep 05 17:18:00 <tgoodwin> (our problems, obviously, because of what we're trying to accomplish)
Sep 05 18:23:22 <rburton> RP: i've got travis doing dumb ci for meta-acrn, it's just a parse and dry-run build but that's better than nothing
Sep 05 18:23:27 <rburton> (on the free travis plan)
Sep 05 18:23:45 <rburton> next step is to run a container here and get it doing actual builds
Sep 05 18:26:04 <rburton> obviously just a very quick smoketest, but again better than nothing
Sep 05 18:26:13 <rburton> for meta-acrn we've a nice small subset that we care about
Sep 05 18:59:07 <khem> rburton: I use drone.io and have put in for meta-clang
Sep 05 18:59:39 <khem> works nicely, its all docker based flow as well, even drone.io runs on docker itself
Sep 05 19:00:05 <khem> so my server can be torn and rebuilt in mins
Sep 05 19:17:01 <yocti> New news from stackoverflow: Same build/source code for multiple machines in Yocto <https://stackoverflow.com/questions/57811452/same-build-source-code-for-multiple-machines-in-yocto>
Sep 05 21:17:20 <yocti> New news from stackoverflow: YOCTO : remove all my led drivers from my yocto linux os image <https://stackoverflow.com/questions/57812953/yocto-remove-all-my-led-drivers-from-my-yocto-linux-os-image>
Sep 05 21:21:58 <RP> tgoodwin: definitely worth posting about, I'm curious
Sep 05 21:22:00 <RP> rburton: makes sense
Sep 05 21:49:03 <rburton> khem: can you share your setup for that?
Sep 05 23:09:17 <rburton> zeddii: can i blame you for https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/341/steps/8/logs/step1c
Sep 05 23:10:26 <zeddii> not easily. :D this is the kernel module test that marka from wind river is trying to replace.
Sep 05 23:10:50 <zeddii> out of tree modules build fine. that one just has some sort of config issues that Mark was describing.
Sep 05 23:11:04 <zeddii> but I can check to see if something it requires is not removed, renamed or just gone.
Sep 06 00:46:07 <khem> halstead: pwclient is failing today to talk to patchwork ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)
Sep 06 00:47:07 <halstead> khem, is the pwclient on your machine?
Sep 06 00:47:36 <halstead> khem, The SSL cert is having issues. I'll hop right on it.
Sep 06 00:51:14 <halstead> khem, The cert was already current but the webserver had the expired cert in memory. I'll make sure this doesn't happen again.
Sep 06 00:52:30 <khem> yes pwclient is on my machine
Sep 06 00:53:00 <halstead> khem, Should be repaired now.
Sep 06 00:53:02 <khem> halstead:ah working again thanks for resolving it
Sep 06 00:53:20 <halstead> Thank you for reporting khem.
Sep 06 00:53:45 <khem> rburton:.drone.yml is there on meta-clang
**** ENDING LOGGING AT Fri Sep 06 03:00:56 2019