**** BEGIN LOGGING AT Wed Aug 15 03:00:00 2018 Aug 15 04:17:20 halstead: are any of the openSuSE builders going to be updated to Leap 15.0? Aug 15 04:20:08 tlwoerner, There certainly will be a 15.0 builder in the new cluster. I have additional hardware coming up for that. Do you have any tips? Aug 15 04:22:57 halstead: nothing specific. maybe avoid btrfs (which i think it'll want to do by default) Aug 15 04:24:46 also, don't disable barrier (as suggested on https://wiki.yoctoproject.org/wiki/Build_Performance) it seems to randomly mess up pigz (don't know if this is openSuSE-specific) Aug 15 04:28:01 Will do. Thank you. Aug 15 04:52:41 * armpit pigz don't like barriers Aug 15 05:10:01 we should be testing distro defaults, so if btffs is default for suse then so be it. since we expect the opensuse users to use the defaults Aug 15 05:10:32 We should stick to distro defaults as much as possible for best coverage Aug 15 05:16:01 armpit: apparently they don't Aug 15 05:16:12 We use defaults except the build partition is always ext4. Aug 15 05:17:31 khem: hmm... is anyone else using btrfs for a build disk? i thought "don't use btrfs for OE" was a known rule-of-thumb Aug 15 05:18:09 maybe the manual should be updated to point this out? either specifically for openSuSE or just in general? Aug 15 05:20:13 if it is documented it might be ok, otherwise there is no point of testing various distros if we dont stick to mostly defaults Aug 15 05:20:31 we could just publish a build container Aug 15 05:35:10 I am trying to build a RPI image having read only rootfs. Build fails because busybox post installation fails (update-alternatives: Error: not linking build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-lsb/1.0-r0/rootfs/sbin/klogd to /bin/busybox.nosuid since build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-lsb/1.0-r0/rootfs/sbin/klogd exists and is not a link). Yesterday got an tip that probably klogd is coming from Aug 15 05:35:10 sysklogd. But what my options are to get the build go through? :) Aug 15 05:35:52 learning how the system works, so pretty much no idea to which direction to go with that Aug 15 05:57:46 and definitely /sbin/klogd comes from package sysklogd 1.5.1-r0 Aug 15 08:01:04 #ERROR: Nothing RPROVIDES 'libxml2-native' (but virtual:native:/home/builder/src/base/meta-openembedded/ Aug 15 08:01:07 meta-python/recipes-devtools/python/python-lxml_4.2.1.bb RDEPENDS on or otherwise requires it) Aug 15 08:01:50 Any ideas how to resolve that on sumo? libxml2-native builds, but python-lxml somehow can't find it. Is it because python is arch all and libxml2 not? Aug 15 08:28:45 armpit: nice green rocko :) Aug 15 09:01:37 Hi all. Is anyone here au fait with the meta-qt layer? I have a krogoth build that I'm moving to sumo, however I had been using the EGLFS backend for Qt, now Qt seems to require either x11 or wayland? Is that true? Aug 15 12:26:21 Hi, I want to include "gdbserver" in my image. But despite adding "tools-debug" to EXTRA_IMAGE_FEATURES in my local.conf gdb/gdbserver is not included in my image. Is there anything else that must be enabled? Aug 15 12:27:02 Hmm, I've always just added it as an item within my image, just as "gdbserver". Aug 15 13:35:21 I'm writing a bbappend to add an init-script for a daemon I'm installing. I have added my files like so: FILESEXTRAPATHS_prepend := "${THISDIR}/files:" and SRC_URI_append = "file://init" (plus all the inherit update-rc.d stuff).. But for some reason it seems to override the strings for the original-package source-files. It fails because it can't find the required patch-file, which seems not to be copied in anymore.. Aug 15 13:41:29 Ahh no. It finds the patch-file allright. But it can't find the source-file to patch Aug 15 13:41:39 jofr: you forgot to add a space to the beginning of your SRC_URI_append, so the last entry in the main SRC_URI was joined to file://init without a space Aug 15 13:42:49 RP: No luck reproducing that persist_data failure.... I suspect it is some sort of sqlite DB schema problem. Would it be possible for me to get a copy of the bb_persist_data.sqlite3 file from one of the failed autobuilders? Aug 15 13:43:13 kergoth: Thanks! But I'm still getting the same error Aug 15 13:43:41 Applying patch 0001-Remove-hardcoded-usr-local-includes-from-configure.a.patch Aug 15 13:43:41 can't find file to patch at input line 18 Aug 15 13:44:05 Is there a way to get a devshell before patches are applied? Aug 15 13:44:24 Because it failes on patching so my devshell never gets started.. Aug 15 13:44:40 Comment out your patches maybe? Aug 15 13:45:29 In theory I could .. but those patches are a part of the original recipe which I'm just bbappending. Aug 15 13:46:11 jofr: Oh. So you're saying you have problems even with the original recipe and no append? Aug 15 13:46:47 No. Original recipe works fine. Until I break it with whatever I'm doing wrong in my .bbappend Aug 15 13:47:04 jofr: Ahh. Gotcha. Aug 15 13:48:33 comment out the entire bbappend and try to build it. if it still fails, bitbake -c clean the recipe and build it again and go from there Aug 15 13:58:06 JPEW: surely if that were the case it would be consistent. Failed builds do run again later with no change :/ Aug 15 13:58:20 RP: Oh.... hmm Aug 15 13:59:50 * RP is happier now glibc 2.28 is merged Aug 15 14:07:04 Found my problem. It did NOT like my: S = "${WORKDIR}" Aug 15 14:07:54 So in my do_install_append () I just used WORKDIR instead of trying to make it shorter. This is something I copied from another recipe... Aug 15 14:10:25 JoeR: thanks, simply adding gdbserver works. Aug 15 14:26:03 Is there a way to configure the u-boot recipe to load an FPGA from within the SPL (v2018.0x) Aug 15 14:26:04 ? Aug 15 14:27:12 tgoodwin: AFAIK, no. I think you still need the Xilinx FSBL if you want the bitstream *before* u-boot is loaded. Aug 15 14:28:41 I would have sworn I saw options back in v2017 for this (via menuconfig). I have some PL -controlled devices that need to get loaded before the drivers, otherwise it's hanging. Aug 15 14:30:21 jofr: right now I'm trying to look through how the microblaze config works since it's a soft processor. Aug 15 14:30:30 similar issue... the FPGA would have to be loaded first. Aug 15 14:31:05 Yes. But doesn't that still require the FSBL? I'm more than happy to be corrected, though :) Aug 15 14:31:38 jofr: no idea; never tried it. Aug 15 14:32:23 Me neither. Aug 15 14:34:08 I used to use the FSBL, but since I didn't need my bitstream to get loaded before u-boot (I only need it before Linux, so I just load them from u-boot) I just switched to the u-boot one. Makes the build-environment so much simpler. Aug 15 14:36:32 jofr: I hear you. I'm trying to avoid having to do a canned FSBL recipe or use meta-xilinx-tools given its external toolchain requirement. Aug 15 14:41:11 Exactly. Aug 15 14:43:09 Is there any way to suppress -j X when calling oe_runmake ? Aug 15 14:43:34 normally this produces make -j Aug 15 14:45:06 lukma: set PARALLEL_MAKE = "" ? Aug 15 14:45:51 RP: I would like to have PARALLEL_MAKE properly set (for other build stuff) Aug 15 14:46:05 the current build system do not accept make -j X Aug 15 14:46:16 but instead it wants make JOBS=X Aug 15 14:46:30 and show error when -j is passed to make Aug 15 14:47:44 lukma: PARALLEL_MAKE_pn- = "" ? Aug 15 14:52:06 RP: Ok, this works Aug 15 14:52:25 So if PARALLEL_MAKE is NULL the oe_runmake doesn't pass -j ? Aug 15 14:53:20 lukma: the better way to think of it is the value of PARALLE_MAKE is passed to oe_runmake Aug 15 14:55:12 Ach.... ok Aug 15 14:58:39 RP: The problem is that I do call make (oe_runmake) Aug 15 14:58:56 the during this make ...... another sub project is invoked, which calls ./configure Aug 15 14:59:11 I do need to set FOO=x86 for this configure Aug 15 14:59:24 is there any way to do it from the oe_runmake level? Aug 15 14:59:34 simple export FOO=x86 doesn't help.... Aug 15 15:50:57 armpit: i'm curious to know if you have mali working on the odroid-xu3? i know you don't have an xu4 but that's what i have (i don't have an xu3) and i can't seem to get mali to work Aug 15 15:51:43 armpit: the driver doesn't load (complains about unknown symbols, and when i run glmark2-es2 it says the DDK doesn't match any GPU on the system Aug 15 15:53:49 (the xu3 and the xu4 are basically the same devices, just different boards?) Aug 15 15:53:58 tlwoerner, I thought I did. Yeah, I saw the missing symbols. the driver is calling functions on typically finds in userland not the kernel Aug 15 15:54:36 tlwoerner, so you built mali as a module ? Aug 15 15:55:16 armpit: thanks for the work on rocko, I took the liberty of merging :) Aug 15 15:55:37 armpit: I also moved a couple of patches into sumo-next and rocko-next to clean up my inbox Aug 15 15:56:16 RP, no problem.. I have more patches to push out Aug 15 15:56:58 armpit: the module is /lib/modules/4.17.14-odroid/extra/mali_kbase.ko Aug 15 15:57:41 i'm baking odroid-x11-image and adding 'MACHINE_FEATURES_append = " mali"' in local.conf Aug 15 15:57:42 tlwoerner, I guess I should try that. I built mine static.. I think the fixes are simple enough Aug 15 15:59:25 armpit: I wondered if you might... Aug 15 16:01:12 RP, I have 30+ sitting on my desk. now I get to figure out what is applicable to master/sumo before rocko Aug 15 16:01:57 armpit: sounds like fun :/ Aug 15 16:02:33 * RP is feeling a bit happier to have patches moving again and several annoying things resolved. For some reason I'm mentally feeling shattered :( Aug 15 16:02:49 I should perhaps take a break from the computer Aug 15 16:03:00 sounds like a good plan Aug 15 16:03:10 go riding Aug 15 16:03:21 sounds like you need a proper vacation :) Aug 15 16:03:38 +1 Aug 15 16:04:39 armpit: supposed to be club cycling tonight but not sure I can face it... Aug 15 16:04:44 kergoth: yes! :) Aug 15 16:05:54 RP: got the core-image-sato-sdk -ctestimage passing with security-flags now we need https://patchwork.openembedded.org/patch/153753/ and https://patchwork.openembedded.org/patch/153754/ Aug 15 16:09:01 khem: very cool. Have them queued locally for the next -next run Aug 15 16:10:07 khem: glibc upgrade is finally in :) Aug 15 16:14:11 RP: yes saw it this morning, I was holding all meta OE patches on it Aug 15 16:24:01 * armpit time to see what breaks Aug 15 16:47:42 tlwoerner, I am updating to the latest mail driver and will see how it goes Aug 15 16:48:58 Do we have a process for posting good tasks for new contributors or janitorial type stuff? Aug 15 16:50:18 kergoth: other than bugzilla entries, no Aug 15 16:51:11 is there a flag or something in bugzilla to mark them explicitly yet, or just need to note it int he summary? Aug 15 16:51:34 seems like a helpful thing a lot of projects are doing nowadays, adding entry points for new contributors Aug 15 16:51:47 kergoth: no, this is the bit that needs work as we've not found a mechanism that works Aug 15 16:51:52 * kergoth nods, fair enough Aug 15 16:52:43 kergoth: I'd suggest a new tag in the whiteboard and we mention it to stephen when he sends out the unassigned bugs list... Aug 15 16:52:53 probably a good idea Aug 15 16:53:27 kergoth: I was just looking at https://bugzilla.yoctoproject.org/show_bug.cgi?id=12614 which is probably an interesting task without too much prior knowledge needed Aug 15 16:53:28 Bug 12614: enhancement, Medium+, 2.99, richard.purdie, NEW , Add include_all directive Aug 15 16:53:56 there are a lot of things in my 'should do something about this someday' list, and a lot of them are actually trivial but low priority, so figured it'd be worth pointing them out somewhere for folks looking for something to do Aug 15 16:54:04 ah, indeed Aug 15 16:56:24 kergoth: spending a few minutes creating bugzilla entries would be a good move Aug 15 16:56:49 kergoth: we have a good record of doing things longer term Aug 15 17:09:53 armpit: great! btw should i be using master or master-next of meta-odroid? Aug 15 17:25:08 tlwoerner, master.. I playing around with next too much. you can try it thou Aug 15 17:42:08 * kergoth ponders Aug 15 18:03:30 Is there a way to see all builds of a specific revision on the autobuilder? Aug 15 18:04:14 JPEW, don't think so Aug 15 18:07:37 tlwoerner, still getting error Aug 15 18:14:06 Ah, the builds are logged to the wiki by SHA1: https://wiki.yoctoproject.org/wiki/BuildLog#nightly_1305_-_master-next_cd10a1c45e3c3f471e11e1ea21b6e9a5bd7734fe Aug 15 18:14:59 armpit: okay, thanks for looking into it :-) Aug 15 18:35:38 jofr: Turns out if you use u-boot-xlnx you can do this with an SPL setup for zynq parts (but not zynqmp). Using their 2018.2 version, I enabled CONFIG_SPL_FPGA_SUPPORT and CONFIG_SPL_FPGA_LOAD_ADDR (to 0x100000 in my case). That was enough for it to go find fpga.bin and load it. You just have to make sure your endianness is right for the bin file. It wouldn't take the bit file output from Vivado. Aug 15 19:23:31 while building linux kernel 4.14 I'm getting this error "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, install libelf-dev", now the libelf-dev in not available in oe-core, how to disable this CONFIG_UNWINDER_ORC=y Aug 15 20:07:56 Is there a means to clear/ prevent appends to a variable? Aug 15 20:08:34 Sort-of "seal" it? Aug 15 20:10:02 For example, you have a machine that is derived of another so in most recipes you want to inherit those upstream machine items, but in this case, you want to block them. Aug 15 20:19:25 best would be to undo what they've done in your own bbappend. worst case you could use BBMASK to prevent those appends from being parsed entirely Aug 15 20:47:22 JPEW: you can also query error reporting for failures in a given revision Aug 15 20:49:16 RP: I don't know if I'm familar with "error reporting". Is that some sort of service? Aug 15 20:53:36 JPEW: http://errors.yoctoproject.org/ Aug 15 20:53:48 JPEW: autobuilder uploads all failures to it Aug 15 20:53:48 Ah excellent! Aug 15 20:54:40 RP: I did notice that the only failures with persist_data (that I could find) were on the fedora26 node, which is now offline... concidence? Aug 15 20:54:50 JPEW: builds in the tgrid view on the autobuilder have a link to the right errors query Aug 15 20:55:23 JPEW: there were some on other builds. f26 was running selftest which was perhaps causing the problem to show more Aug 15 20:55:45 JPEW: there was at least one on ubuntu1710 iirc Aug 15 20:56:21 RP: fair enough. Ok. I'll see if I can find that one somewhere. Aug 15 21:00:22 JPEW: we're morphing the f26 worker to f28 now I think Aug 15 21:52:15 RP: sent my share of recipe updates Aug 15 21:53:29 khem: thanks! Aug 15 23:12:43 RP: we need new uninative now too Aug 15 23:12:46 RP: WARNING: Your host glibc verson (2.28) is newer than that in uninative (2.27). Disabling uninative so that sstate is not corrupted. Aug 15 23:13:24 so you not only have to consider older distros but newer ones too :) sandwich Aug 15 23:19:58 at least there was a check Aug 15 23:31:32 * armpit hmm, more unknown symbols Aug 15 23:45:44 * armpit gets hammer out Aug 15 23:51:45 so, rocko got updated today and several of my external modules now break in do_make_scripts... :( Aug 16 00:27:38 kernel modules? Aug 16 00:28:07 armpit: yup, see email Aug 16 00:31:44 so did you try what you suggested? Aug 16 00:32:23 * armpit gets distracted by M-in-law and wife arguing Aug 16 00:32:34 aratiu: yup, I changed oe_runmake back to make and everything worked Aug 16 00:32:56 armpit: grab a beer and go to another room? :) Aug 16 00:34:35 denix, we should bug it or send a patch.. rocko has more working coming Aug 16 00:36:27 armpit: yeah, it's bad timing for me - I'm in the middle of a release, trying to do RC3 now. I either have pin oe-core (but miss CVEs) or overlay module-base.bbclass Aug 16 00:38:17 armpit: starwars !! Aug 16 00:44:23 denix: are you sending the patch or do you want me to? Aug 16 00:45:18 armpit: what's the process for fixing backports in stable? normally patches should go through master, but this is rather specific to rocko only Aug 16 00:45:57 anujm: I can send a patch shortly Aug 16 00:46:20 denix: thank you! I will give it a try too. Aug 16 00:46:30 sorry, it broke your builds. Aug 16 01:02:29 denix, if its specific in Rocko no need to apply to other branches Aug 16 01:04:16 if the patch looks good I can through it a the AB later tonight Aug 16 01:24:01 armpit, anujm: http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154191.html Aug 16 01:54:46 denix, thanks Aug 16 02:04:58 denix: thanks! **** ENDING LOGGING AT Thu Aug 16 03:00:00 2018