**** BEGIN LOGGING AT Mon Jan 18 02:59:58 2016 Jan 18 03:25:04 this can be quite fickle, hunting down build problems is like scanning through a heystack Jan 18 03:25:08 haystack* Jan 18 08:57:27 good morning Jan 18 12:42:12 <_4urele_> hello everyone Jan 18 13:27:05 People of the toaster, I have some questions Jan 18 13:27:45 I have a working OE build and have started toaster in it, but it seems to ignore my existing confiles Jan 18 13:28:30 Hi, how do I get rid of the "[...] tainted from a forced run" message? Jan 18 13:33:32 If I use toaster to setup a config, will it overwrite existing files? Jan 18 13:39:50 Crofton: it will add couple of lines to bblayers.conf and create conf/toaster.conf Jan 18 13:41:40 hmm, but I already have bblayers Jan 18 13:41:58 * Crofton|work is anooyed it doesn't figure out existing conf Jan 18 13:42:05 but the demo must go on Jan 18 14:03:05 Hi, updated git branches for poky, and now all work must be redone in work folder "cortexa7hf-neon-vfpv4-poky-linux-gnueabi," instead of the old "cortexa7hf-vfp-vfpv4-neon-poky-linux-gnueabi". Does anyone have a clue what is going on? Jan 18 14:11:20 mrKonge, neon support was added in the build for your arch Jan 18 14:32:42 fsdun: Thank! Do you which meta data file contains this information? Jan 18 14:34:17 mrKonge, somwhere in the machine includes Jan 18 14:34:43 TUNE_FEATURES Jan 18 14:40:42 Weird, can't find any recent changes Jan 18 14:42:25 if you updated oe-core/poky master then there's been lots of recent changes to the arm tune setup Jan 18 14:44:15 rburton: Ok, that is most likely what has happened Jan 18 14:45:06 yes, the TUNE_CCARGS should be the same but TUNE_PKGARCH was changed Jan 18 14:45:24 almost the same, except duplicate -mvfp Jan 18 14:47:03 So... if I just renamed the existing work folder, would that fuck everything up or work? Jan 18 14:47:21 don't do that Jan 18 14:47:30 it won't help with anything Jan 18 14:47:41 and it can break rebuilds Jan 18 14:48:03 bitbake will still rebuild it, because valid stamps are for different architecture Jan 18 14:48:14 WORKDIR content is irelevant for that Jan 18 14:56:37 hmm, toaster will not let me save an empty DISTRO value :) Jan 18 14:56:52 looks like I need to start filing bugs Jan 18 15:02:17 hmm, I can't even add layers Jan 18 15:03:47 How would I get bitbake to spit out a tarball of all the sources? Jan 18 15:04:32 WarheadsSE: check archiver.bbclass Jan 18 15:05:47 Will do asap. Jan 18 15:06:24 Looks like we have archive-patches-sources.bbclass atm. Jan 18 15:06:52 Which is all dandy, of course, but the results are lacking the other necessary, say, git checkouts that aren't patched Jan 18 15:08:52 http://dpaste.com/3KYB01F Jan 18 15:09:06 which, looks like it just pulls form archiver. Jan 18 15:31:16 JaMa: I see the issue, since we'd rather need archive-configured-sources. Jan 18 15:34:43 Looks like I will have to cause a full rebuild if I want that, at this point. Jan 18 15:34:49 you should be able to just configure to do that Jan 18 15:34:54 true Jan 18 15:35:02 right, but I need it to configure _everything_ Jan 18 15:35:25 I didn't think -c configure would let me tell it to do that for everything Jan 18 15:49:33 I'd love to be wrong though JaMa Jan 18 15:51:46 WarheadsSE: see do_fetchall. copy-paste the entire block to a new bbclass in your layer, search/;replace fetch with configure, add that class to INHERIT, run bitbake -c configureall foo Jan 18 15:52:42 * WarheadsSE snaps to it Jan 18 15:56:18 hmm, though that might not force a *rebuild* if they were already built, just make sure they were configured at all. in which case you could set do_configure[nostamp] = "1" as a temporary measure, possibly? *shrug* Jan 18 15:56:22 * kergoth hasn't had enough caffeine yet :) Jan 18 15:56:57 well its better than telling it to outright rebuild everything. Jan 18 15:57:47 or you could bitbake -g and use pn-buildlist to script it above the bitbake level Jan 18 15:58:05 I have an image, completely built, that i need to get the necessary gpl tarball of sources. Welcome to %$#%-ville when I realized I only had the items where patched. And aboutr 30 recipes from a bit hash. Jan 18 15:58:13 s/bit/git/ Jan 18 16:01:56 Looks like without doing the the nostamp, it is tripping fetch/patch/configure Jan 18 16:10:19 heh, yeah, some cimpiling happening too, but at least it is progress! Jan 18 16:48:59 RP: http://git.openembedded.org/openembedded-core/commit/?h=jethro&id=bc458ae9586b45b11b6908eadb31e94d892e698f this isn't the right fix Jan 18 16:49:19 RP: it breaks gudev dependencies again, because even in jethro systemd has separate libgudev Jan 18 17:06:28 * kergoth grumbles Jan 18 17:07:16 we are all cranky today Jan 18 17:07:34 it's Monday :( Jan 18 17:17:03 * WarheadsSE offers irish coffee Jan 18 17:31:44 anyon efamiliar with the current toaster process? Jan 18 17:52:46 quiz: how long does it take to git clone git://git.yoctoproject.org/linux-yocto-4.4.git ? Jan 18 18:03:10 after half hour: Receiving objects: 0% (41745/4486007), 17.84 MiB | 32.00 KiB/s Jan 18 18:05:04 JaMa, are you in a museum of ancient technology? Jan 18 18:05:59 or free WiFi in the Hotel lobby? Jan 18 18:07:38 how about a 300baud dialup? Jan 18 18:07:46 fsdun: 200Mbit, the issue isn't on my side.. Jan 18 18:08:27 fetching http://sources.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-4.4.git.tar.gz is better, around 6MB, but that's not in default PREMIRRORs Jan 18 18:08:33 6MB/s Jan 18 18:09:14 I don't know why all upstream kernels can live in one repository and linux-yocto needs new one for every kernel version Jan 18 18:09:54 time to PNBLACKLIST[linux-yocto] and use nice vanila kernel recipe with linux.inc again Jan 18 18:14:06 JaMa, IIRC I can blame you for qt5 build errors :P Jan 18 18:18:49 fsdun: or you can send patches if you want to be more productive :P Jan 18 18:19:44 my PC is to slow because it runs bitbake all the time :P Jan 18 19:40:17 JaMa: I've started doing kernel source releases for the layer I manage as a .tar.xz file as git clones can be so slow Jan 18 19:42:16 * zeddii shrugs Jan 18 19:59:22 yes, they are slow from some git servers.. 2 hours later: Receiving objects: 12% (538543/4486007), 208.69 MiB | 17.00 KiB/s **** ENDING LOGGING AT Tue Jan 19 02:59:58 2016