**** BEGIN LOGGING AT Fri May 06 02:59:58 2016 May 06 12:54:33 rburton: I've seen your recent fix for do_split_packages, have you seen the case where some package names are returned even when the resulting package is empty? May 06 12:55:23 I'm seeing such issue in llvm3.3 which breaks DEBUGFS generation, satisfy_dependencies_for: Cannot satisfy the following dependencies for llvm3.3-dbg: libllvm3.3-lto-dbg * libllvm3.3-llvm-3.3-dbg * May 06 12:57:50 I think I'll just drop split -dbg packages generation, because it interacts badly with automatic FILES_${PN}-dbg May 06 12:58:16 JaMa: hm never seen that before. totally worth merging -dbg into one though. May 06 12:59:24 Hi. I want build nightlies. Can yocto autobuilder do this? May 06 12:59:39 I couldn't find much info about setup and build May 06 13:01:37 rburton: it was split before, because those subpackages are huge and people often use only very small part of it May 06 13:01:49 rburton: like one library for mesa May 06 13:02:40 kteza1: yeah y-a is basically just buildbot, so you can make it do that if you want. or use whatever you prefer, some use jenkins. May 06 13:02:51 40M tmp-glibc/work/i586-webos-linux/llvm3.3/3.3-r0/packages-split/libllvm3.3-llvmanalysis-staticdev May 06 13:02:54 40M tmp-glibc/work/i586-webos-linux/llvm3.3/3.3-r0/packages-split/llvm3.3-dbg May 06 13:02:57 84M tmp-glibc/work/i586-webos-linux/llvm3.3/3.3-r0/packages-split/libllvm3.3-llvmcodegen-staticdev May 06 13:03:00 209M tmp-glibc/work/i586-webos-linux/llvm3.3/3.3-r0/packages-split/libllvm3.3-profile-rt-dbg May 06 13:03:03 c++ eh :) May 06 13:03:20 you probably don't want to install libllvm3.3-profile-rt-dbg just because you're debugging something which depends on mesa May 06 13:03:34 yeah May 06 13:04:23 ah NOAUTOPACKAGEDEBUG = "1" could help May 06 13:22:06 @rburton Can the builder start everything from repo init, repo sync to bitbake image? May 06 13:23:13 kteza1: yeah. you'll just need to hook up the right bits. May 06 13:24:00 rburton: heh it's a mess http://pastebin.com/uaK0saey May 06 13:50:10 llvm is a huge codebase, I think even if it was in C it would not be small but certainly smaller than what you see there May 06 13:50:46 but when I look at webkit or chromium, this is peanuts .. single .o is 250M in chromium May 06 14:26:09 hi May 06 14:26:17 I have poky 2.0 (jethro) and now I would like to add meta-ti to my layers. But it seems it only goes up to 1.8.1 (fido) May 06 14:26:20 does it mean I have to downgrade poky to matching version? or can I mix them? May 06 14:29:45 maciejjo: If there are any bbappends in the meta-ti layer, you may hit issues if you use the meta-ti layer with jethro. I'd suggest starting off with fido. May 06 14:34:29 maciejjo: try it... yocto is pretty good at complaining if it doesn't work :P May 06 14:36:26 ok, now I'm on mobile so don't have transfer for that, but I will try, why not. May 06 14:36:51 I'm just wondering why meta-ti is stuck on older release May 06 14:37:53 the master branch might well work on 2.0 May 06 14:37:54 which enviroment variable points to the directory one level above S May 06 14:38:04 they probaby just failed to branch it May 06 14:38:08 mortderire: WORKDIR May 06 14:38:16 ok, I will try master then May 06 14:38:17 rburton: your fast May 06 14:38:24 obviously you mean what directory does S usually sit in :) May 06 14:38:30 maciejjo: krogoth is pretty new, all external meta probably havn't resynced yet.. May 06 14:38:37 * boucman_work knows a couple of meta that are still on dizzy :( May 06 14:38:52 boucman_work: yeah, I was thinking jethro May 06 14:39:39 I've already started working with jethro and now I learned that all cool stuff for BeagleBone is in meta-ti May 06 14:45:21 rburton, do you know where I can find the build results for the 2.1 release? May 06 14:45:44 armpit: you'll have to dig back on the AB May 06 14:46:37 k, was poking around already.. will dig some more May 06 15:03:17 added a task between patch and configure, doesn't seem to getting called automagically. May 06 15:05:10 g0d'$awAy May 06 15:06:01 mortderire: paste your addtask line? May 06 15:12:04 mortderire: most likely you didn't have 'before do_configure', or perhaps forgot the do_ May 06 15:12:14 we should really make addtask handle either with or without the do_ prefix on all 3 arguments May 06 15:12:18 * kergoth yawns May 06 15:12:47 addtask backport after patch before configure May 06 15:12:57 I presume I need the do_ May 06 15:13:01 you need: addtask backport after do_patch before do_configure May 06 15:13:10 for the 2nd and 3rd aguments, yes, for the first, no May 06 15:13:15 cause we're oddly inconsistent like that.. May 06 15:13:16 * kergoth rolls eyes May 06 15:13:28 kergoth: :-D ... your trying to kill me right May 06 15:13:36 _ May 06 15:26:07 maciejjo: meta-ti is not stuck on fido. it now supports krogoth May 06 15:27:58 maciejjo: how do you even get such an idea??? if you take a look at commits, you'd see master is pretty active May 06 15:28:45 denix: I see it's active, I just didn't see branches for anything later than fido May 06 15:29:14 master only split from krogoth like a day ago or something May 06 15:29:16 maciejjo: so you declare it's stuck in the past... May 06 15:29:22 not having a krogoth branch in a layer doesn't mean a whole lot at this point May 06 15:29:38 kergoth: last week Thursday was the official release :) May 06 15:29:51 yes, but until the past couple days there wasn't much, if any, divergence in the branches May 06 15:29:58 they only recently started merging 2.2 changes May 06 15:30:00 true May 06 15:30:39 denix: sorry for that - I am really happy it is not. I was more asking than declaring. May 06 15:32:01 Does Yocto not bootstrap a separate compiler for the host architecture to compile *-native stuff? May 06 15:32:05 maciejjo: meta-ti skipped jethro as there are no resources to spare for maintaining every release. it follows mostly spring releases - krogoth, fido, daisy, etc (skipped jethro, dizzy) May 06 15:32:18 neverpanic: that's correct, it does not. we assume the host has a functional toolchain May 06 15:32:24 I always had the impression it does that, but giving it a closer look it seems it just uses the host compiler May 06 15:32:36 denix: Ok, thanks for explanation :) May 06 15:32:42 Hm, that leads to problems when newer GCC versions enable new warnings and code is compiled with -Werror May 06 15:32:55 it builds a crosscopmiler toolchain, and for sdks it builds a toolchain that targets the SDKMACHINE to build nativesdk recipes, but thats' about it May 06 15:33:08 yep, we should be disabling Werror for our builds in most cases May 06 15:33:30 neverpanic: people are already testing gcc-6 and fixing errors May 06 15:34:02 Yes, I know, but it also means we have to backport these fixes to whatever release we're using May 06 15:36:00 using -Werror has always been and will always be a Stupid Thing To Do in production builds May 06 15:36:40 so there really shouldn't be many left in oe-core, as previous gcc upgrades caused new stuff to be fatal May 06 15:36:50 (that damned strict-aliasing warning) May 06 15:38:00 neverpanic: or just do your builds in a container, vm, or chroot that's a known quantity May 06 15:39:56 if I want to generate two wic-based output based on the same rootfs, is that possible ? would bitbake run the very-long do_rootfs twice ? May 06 15:40:24 can it be in the same image recipe ? I think the wic config file is a single file IIUC... May 06 15:40:42 boucman_work: you can, but not using the wic image type May 06 15:40:50 you can just run wic separately outside of bitbake May 06 15:40:54 kergoth: disabling Werror ? May 06 15:41:14 see above May 06 15:41:35 do you mean non-target pieces ? May 06 15:41:52 btw. its not only Werror is the problem May 06 15:42:15 its portion of forward upgrade. many cases you have to fix code May 06 15:42:27 kergoth: ok... not good fore streamlining image generation/build-quality, but good enough in my case May 06 15:43:02 kergoth: we already use a container, but it's nice to be aware of what's coming and know ahead of time what we have to backport. May 06 15:43:05 boucman_work: or just add a new task to your image that runs the second one May 06 15:43:14 boucman_work: image recipe, that is May 06 15:43:19 hmm May 06 15:44:10 addtask foo after do_image_wic before do_image_complete, and then do another wic execution in that one with different args. or even force a re-exec of do_Image_wic with a different WKS_FILE May 06 15:44:15 in do_foo, that iss May 06 15:44:17 if I did a patch that allowed a list of config files to be provided to wic, would it have a chance to go upstream ? May 06 15:44:18 s/s$// May 06 15:45:13 this sounds like an usual use case to me, but it doesn't sound liek it'd add a ton of complexity May 06 15:45:20 (btw, wic type images and WKS_FILE are not documented in the mega-manual) May 06 15:46:17 my use case is that I need an image for a usb key+ nand on an imx6... the nand version needs a reserved space between partitions for uboot, the sdcard doesn't May 06 15:46:40 there are still some slight issues with wic images as opposed to the bootimg/live/etc images, unfortunately. i.e. use of an initrd, it'll be included in the bootloader config for an image that comes out of image-live, but not an image built by wic. but that's only an issue for certain bsps May 06 15:46:44 ah May 06 15:46:45 i'm still in the analysis phase of my problem, though May 06 15:46:48 that makes sense May 06 15:47:38 one of the limitation of wic (that I have no idea how to work around) compared to live images is the possibility to "fill up the rest of the space" with a partition May 06 15:47:44 boucman_work: if you're messing with the wic image type, i'd be curious to hear your opinion on the RFC wks.in patch series on the oe-core list, haven't gotten any feedback on it yet May 06 15:48:38 kergoth: I agree with the need to have yocto variables in .wks, but I don't have a good enough view of the general yocto architecture to comment May 06 15:48:43 debian on beaglebone black auto-resizes the partition and rootfs to fill available space when it boots, so the same image can be easily used on different sd card sizes. i've been wanting to set that up as an option, for folks that don't want ot create a bunch of wks files for each sd card size May 06 15:48:50 boucman_work: fair enough, thanks May 06 15:48:59 overall, I think that having some sort of templating system for config files is needed. May 06 15:49:28 something that would expand yocto variables in any file during do_patch (or somewhere around that) May 06 15:49:57 just like *.patch are autotreated as patches, *.in could be treated as yocto templates and have variables expanded May 06 15:50:22 wouldn't really work for images, since they bypass those tasks generally, but that's an interesting idea May 06 15:50:49 kergoth: or in do_fetch, the idea is to expand "early" May 06 15:51:32 yeah, my best idea to do that at this point is to have a post_install command create the partition at first boot May 06 15:52:19 but your approch with .in would allow me to use a yocto variable to do it at build time. wic would need a way to specify a partition size as "fill-up-to" rather than as a size May 06 15:54:28 kergoth: I'll comment on your patch, describing my use-case and dumping my idea (generic templating) if you want... May 06 15:56:01 i'd appreciate that, can be hard to get a discussion going at times May 06 15:58:00 if it makes you feel better, that problem is not limited to the yocto project :) May 06 16:13:34 kergoth: sent May 06 16:30:36 'repo sync' needs auto-stash support May 06 16:31:47 kergoth: then you can play the where f**k did my changes go game. May 06 16:32:35 not really. it works great for git-rebase. if the stash fails to apply, there'll be conflicts to resolve, and the original will still be stashed May 06 16:33:32 kergoth: ah I see, it should apply the stash again after repo is complete, makes sense. May 06 16:33:43 yeah, it stashes, updates, and applies May 06 16:33:45 quite handy May 06 16:33:56 or in the case of rebase, stashes, rebases, and applies May 06 17:13:51 kergoth: oooooo May 06 17:14:04 never knew rebase could autostash May 06 17:14:45 it was added relatively recently, i think. May 06 17:14:46 https://github.com/kergoth/dotfiles/blob/master/git/config#L25-L27 May 06 17:15:17 autosquash is handy too. git ci --fixup :/something-i-fixed-up, git rebase -i origin/master -> auto-squashes the fixup commit into the commit it fixed up May 06 17:15:29 yeah already got that May 06 17:15:34 added autostash thanks May 06 17:15:36 --fixup actually takes a commit, but :/ is awesome since it searches May 06 17:15:37 ah, nice May 06 17:15:38 np May 06 19:28:00 Hmm, I should look into adding handling of musl external toolchains in meta-sourcery, eventually May 06 19:28:22 actually is hould break up meta-sourcery to separate the bits actually specific to sourcery g++ toolchains from teh generic bits **** ENDING LOGGING AT Sat May 07 02:59:58 2016