**** BEGIN LOGGING AT Mon Feb 13 03:00:01 2017 Feb 13 09:10:30 good morning Feb 13 09:32:38 I'm having an issue with the default x86-64 tuning and older machines: Feb 13 09:32:44 https://github.com/flatpak/flatpak/issues/143 Feb 13 09:32:58 I guess i can switch to DEFAULTTUNE=x86-64 Feb 13 09:33:16 but isn't there a way to get -mtune=core2, but -march=generic ? Feb 13 10:47:38 halstead: getting reports that git.yocto is incredibly slow Feb 13 12:05:47 rburton, It looks okay now. Is has it improved on your end? Feb 13 13:06:07 * RP worries that halstead is awake Feb 13 13:08:11 RP: since you are here, whats the trick to getting push to poky-contrib and meta-mingw-contrib? (I want to push some refs for this mingw stuff for Juro) Feb 13 13:08:43 nrossi: sending an ssh key to the right people Feb 13 13:09:09 nrossi: have you ssh access to OE or YP git repos atm? Feb 13 13:09:09 RP: my ssh key should already be on git.yoctoproject for meta-xilinx... Feb 13 13:09:20 nrossi: can't you already push to contrib then? Feb 13 13:10:11 RP: I have not tried tbh, if that is the case then I will give it a go. I just assumed it was a request for access first sort of thing Feb 13 13:10:30 nrossi: ssh git@git.yoctoproject.org should show access Feb 13 13:11:09 rburton: the dnf branch is fixed, can you throw it on the AB again? Feb 13 13:11:33 RP: general rule is to use my user name as the prefix for the ref correct? e.g. nrossi/foo Feb 13 13:11:48 kanavin: sure Feb 13 13:12:20 nrossi: yes, it's a way to tell who is owning what branch (there's a lot of them) Feb 13 13:12:36 kanavin: https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/1117 Feb 13 13:12:41 nrossi: yes Feb 13 13:13:58 rburton: thanks, time for lunch then Feb 13 13:14:15 (so I'll be under heavy sedation of food when errors come in) Feb 13 13:14:27 nrossi: I think I'd need to add access to mingw-contrib, just wondering if you have poky-contrib access to not already Feb 13 13:15:59 nrossi: Looking at the config I'm guessing not so I'll add... Feb 13 13:17:30 RP: not sure if you made the change yet, but push worked fine. http://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/log/?h=nrossi/mingw-qemu-v2 Feb 13 13:17:51 nrossi: I just pushed them :) Feb 13 13:18:00 RP: perfect timing then :D Feb 13 13:57:21 rburton: I'm blanking out on piglit: did you not like the compress-generated-tests hack (https://patchwork.openembedded.org/series/4351/)? Feb 13 14:05:43 jku: incorrect blanking sounds like a graphics bug :) Feb 13 14:09:40 jku: i didn't like it one bit but i'm not sure there's a better solution Feb 13 14:20:52 rburton: :) yeah fair. I'll send a mesa update soonish, will push those on top just in case -- take them or leave them Feb 13 14:21:23 yeah thanks Feb 13 14:21:25 rburton: a new kind of fail with dnf :( Feb 13 14:21:37 kanavin: new fail is a step forward i guess Feb 13 14:21:59 rburton: yes, except the new fail is happening earlier in the build than the old one Feb 13 14:25:50 hm automated qa failing on mips only Feb 13 14:25:56 wasn't there a patch to change that recently? Feb 13 14:26:09 kanavin: is it building with non-verbose output? Feb 13 14:27:13 jku: what is building? Feb 13 14:27:51 kanavin: I assumed this is yours https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/1117/steps/BuildImages/logs/stdio Feb 13 14:30:36 jku: yes it is Feb 13 14:31:25 jku: rburton: /usr/include/features.h:225:0: note: this is the location of the previous definition Feb 13 14:31:35 looks like host contamination that I'm not seeing on the local machine Feb 13 15:05:58 rburton: dnf patchset posted for review :) Feb 13 15:15:53 rburton: did the first run of the DNF branch happen on a different machine? Feb 13 15:18:21 entirely likely Feb 13 15:19:07 oh it did it on the internal cluster didn't i Feb 13 15:19:24 well, new Feb 13 15:19:46 first build was ubuntu 1604 on the new cluster, todays was fedora24 on the old cluster Feb 13 15:20:05 rburton: the actual error today is | x86_64-poky-linux-gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory Feb 13 15:20:15 when building g-o stuff of libdnf Feb 13 15:20:27 I vaguely remember seeing this before, but don't remember specifics Feb 13 15:20:39 (before, as in, one year ago when working on g-o) Feb 13 15:22:08 kanavin: i think byacc was also used by packagegroup-core-full-cmdline Feb 13 15:22:31 rburton: only in the sense that the package was included in the group of packages to install Feb 13 15:22:58 together with m4, make and other things Feb 13 15:23:12 rburton: I dropped it from there too Feb 13 15:26:22 let's see if I can find any reference to 'redhat-hardened' here under debian Feb 13 16:06:20 kanavin: one thing that isn't mentioned in your cover letter is the new postinst behaviour Feb 13 16:07:46 rburton: yeah, the old behaviour is still supported but deprecated and produces warnings Feb 13 16:07:59 rburton: forgot about it :) Feb 13 16:08:19 the fact that wic-tools builds a ton of crap my wks files don't use is really rather irritating. i get that it can't really know that, but it's still irritating. guess i'll just have to override its deps on a per-bsp basis, or something Feb 13 16:08:36 rburton: care to rewrite the test_continue? Feb 13 16:09:25 i'll add it to my list :) Feb 13 16:09:52 kanavin: change of behaviour needs proper discussion and is really orthogonal to rpm4 Feb 13 16:10:22 kergoth: hmm, looks like we already encode some machine-specific dependency information in machine.conf can we improve & rely on that? Feb 13 16:10:36 * joshuagl is looking at beaglebone.conf do_image_wic[depends] += Feb 13 16:11:03 rburton: pkg_postinst works exactly as before, the only change is when you want to force something to run on target only Feb 13 16:11:07 that's what we'd been doing in the past, before the introduction of wic-tools.. seems like we should just have a new variable, if unset let it default to the include-verything behavior Feb 13 16:11:20 yes it's orthogonal, but now is the chance to fix it Feb 13 16:12:30 kanavin: i mean, it deserves a proper debate on its own, not being buried in a uberpatch Feb 13 16:14:27 rburton: I can write a separate email to oe-arch, with that, and with other things that may be controversial: removal of rpm5, removal of db6, a bunch of things for which I'm rasing NotImplementedError (mostly because no one bothered to write a test for them, and I can't implement things blindly) Feb 13 16:18:10 Hi, is there any equivalent to bb.fatal for shell task ? Feb 13 16:19:10 geoffrey_l: bbfatal Feb 13 16:19:14 (etc) Feb 13 16:20:17 rburton: the redhat-hardened issue should be fixed now, can you run the AB again? Feb 13 16:20:36 rburton: Thanks Feb 13 16:21:13 kanavin: https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/1118 Feb 13 16:21:46 rburton: this one is on ubuntu though, can you force it to fedora? Feb 13 16:22:36 no Feb 13 16:25:54 well, kinda Feb 13 16:26:11 a specific builder/buildset? or the whole build? Feb 13 16:26:15 hello yocto maniacs :) Feb 13 16:26:49 rburton: if you want to run nightly-x86-64 on fedora pause all non-fedora workers, start the build, unpause Feb 13 16:26:53 (once scheduled) Feb 13 16:27:14 yeah Feb 13 16:27:17 "no" was the short version Feb 13 16:28:34 rburton: maybe I could've added that I discovered actual mistakes in postinst scripts with this change... Feb 13 16:28:57 kanavin: absolutely sure there are plenty with bad behaviour Feb 13 16:29:05 which were previously swept under the carpet by 'non-zero exit is not an error' design Feb 13 16:29:16 so I do think this has to be fixed Feb 13 16:33:26 guys, is there conditional behaviour in bitbake program? I mean if I set some env. variable then particular recipe is used, or something like that Feb 13 16:34:05 if you want to pick between two recipes then you can use PREFERRED_VERSION or PREFERRED_PROVIDER to pick Feb 13 16:34:11 and you can control those in local.conf Feb 13 16:34:29 Ox4: you need to provide context, what is the problem? Feb 13 16:35:53 rburton: thank you Feb 13 16:36:56 is there a way to get a list of tasks and in which order they would run? Feb 13 16:37:11 -g Feb 13 16:37:16 order isn't possible Feb 13 16:37:35 can I use conditionals in the recipe itself? If some env. variable is set then use paritcular file from the recipe? Feb 13 16:37:59 mdnneo: -g will give you a dot file of all tasks and their dependencies Feb 13 16:40:15 hmm, qemu-x86_64: .../build/tmp/work/x86_64-linux/qemu-native/2.8.0-r0/qemu-2.8.0/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. Feb 13 16:40:35 Ox4: read the bitbake user manual Feb 13 16:42:03 Ox4: the environment is practically wiped. if you want to control a recipe, use assignments in local.conf isntead Feb 13 16:45:56 kergoth: why haven't you fixed bb log yet! ;) Feb 13 16:46:28 heh, that one should be pretty trivial compared to the rest Feb 13 16:46:48 haven't had either the time or the gumption for oe work outside of work lately Feb 13 16:52:31 kergoth: which section? Feb 13 16:53:26 did you bother searching for "conditional"? Feb 13 16:53:39 not hard to find what the syntax options are Feb 13 16:56:08 kergoth: thank you Feb 13 17:25:24 so in the task-depends file if I have "myimg.do_image_complete" -> "myimg.do_image" isn't the arrow a bit misleading actually complete must come before do_image, or? Feb 13 17:26:10 it's exactly what it says. do_image_complete deepnds on do_image, and therefore complete runs after do_image Feb 13 19:05:28 rburton: can you re-start the AB again please? I fixed the dnf branch again, and forced pushed, hopefully for real this time Feb 13 19:20:17 we have been changing rpm based O_P_M frontends almost every year, I wonder how it impacts someone who might have deployed feeds using rhse combinations Feb 13 19:20:34 luckily opkg has stayed all along Feb 13 19:26:13 kanavin_home: https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/builds/1121 and 1122 (accidently fired more than once) Feb 13 19:28:47 khem: to be honest, I don't really see why we need rpm support at all Feb 13 19:29:18 for what it's worth, we at least once or twice had things that were completely non-functional with opkg and worked with RPM. Feb 13 19:29:30 I think one of them involved optional dependencies. Feb 13 19:30:35 rburton: the lottery has allocated debian 8 and centos 7 to the build this time :D Feb 13 19:36:35 kanavin_home: I concur Feb 13 19:37:17 seebs: you could also use dpkg/apt Feb 13 19:37:25 which has stayed on better course Feb 13 19:37:33 or enahnced opkg Feb 13 19:38:37 could be. we had historical interest in rpm, as i recall, so that was what we mostly used. Feb 13 19:41:58 I believe wind river would totally veto the idea of dropping rpm support Feb 13 19:42:46 khem: at least now the rpm stack is completely aligned with red hat, so we'll be getting a free ride on their coattails, so to say Feb 13 19:43:23 using smart and rpm5 just wasn't sustainable in the long term, as yocto was the only user of both Feb 13 20:10:41 hi Feb 13 20:10:57 how is possible to pass EXTRA_CFLAGS to out of tree kernel module? Feb 13 20:11:19 I tried to setup ccflags-y := O2 Feb 13 20:11:29 but it seems it's not accepted Feb 13 20:11:58 also I have from out of tree module one pre-compompiled object Feb 13 20:12:18 when this object is in obj-m yocto will complain about no rule to make a target Feb 13 20:56:28 kanavin_home: I am happy with your changes, I dont use rpm for O_P_M so much to worry about but we use rpm during build and that worries me Feb 13 20:56:57 but hopefully it would stay and we wont keep flipping Feb 13 20:57:08 khem: what is O_P_M? Feb 13 20:57:16 Online package management Feb 13 20:57:25 (and rhse?) Feb 13 20:57:55 khem: ^^^ Feb 13 20:57:58 rhse ? oh that was my fat fingers Feb 13 20:58:11 wanted to type 'the' Feb 13 23:38:02 i made a new distro based on poky.conf and now all my build artifacts end up in build/tmp-glibc instead of build/tmp, any idea why? Feb 13 23:40:54 miceopede: you can set the tmp directory name to whatever you like: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-TMPDIR Feb 13 23:41:11 i'm just confused as to why it changed..? Feb 13 23:44:55 miceopede: You could do a diff of the directories to see where the change happened. Tough to say for sure without knowing your setup. Feb 14 00:41:59 stephano: turns out distro/poky.conf has a TCLIBCAPPEND = "" in it Feb 14 00:42:09 no idea what it's for but that does the trick Feb 14 00:45:02 miceopede: nice, glad you found it. TCLIBCAPPEND allows the creation of separate TMPDIRs based on libc implementation (or whathaveyou). Feb 14 00:45:40 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-TCLIBCAPPEND Feb 14 00:47:46 @stephano great. thanks. Feb 14 00:47:53 np **** ENDING LOGGING AT Tue Feb 14 03:00:02 2017