**** BEGIN LOGGING AT Wed Dec 03 02:59:59 2014
Dec 03 07:58:22 <mckoan> good morning
Dec 03 09:08:55 <spaszkoPL> JaMa: Also to recipe meta-qt5/recipes-qt/examples/qt5everywheredemo_1.0.bb is good to add DEPENDS += " qtmultimedia".
Dec 03 09:12:40 <bluelightning> morning all
Dec 03 09:13:09 <spaszkoPL> morning bluelightning 
Dec 03 09:13:17 <bluelightning> morning spaszkoPL
Dec 03 09:19:28 <mago_> morning bluelightning 
Dec 03 09:21:18 <bluelightning> hi mago_
Dec 03 09:21:44 <bluelightning> mago_: I meant to say the other day, please feel free to file a bug relating to the behaviour you discovered if you haven't already
Dec 03 09:22:06 <bluelightning> (the fetching behaviour that is)
Dec 03 09:22:58 <mago_> okay, i will
Dec 03 09:23:10 <mago_> that would go into bugzilla.yoctoproject.org, or somewhere else?
Dec 03 09:23:27 <bluelightning> mago_: yes, bugzilla.yoctoproject.org
Dec 03 09:37:23 * koen WTFs at LIBC_DEPENDENCIES
Dec 03 09:37:47 <koen> I get that for an SDK you want to drag in all of the *libc subpackages
Dec 03 09:38:01 <koen> but listing 'glibc' in there is just crazy
Dec 03 09:38:17 <koen> since the c library will always be present
Dec 03 09:58:56 <mago_> bluelightning_: i put it under Bitbake, even though it may be a oe-core issue (#7019)
Dec 03 10:20:18 <bluelightning_> mago_: no worries
Dec 03 10:23:28 <bluelightning> koen: apparently that has been there for a very long time according to "git blame"
Dec 03 10:23:44 <bluelightning> (doesn't necessarily mean it's right, but it's not a new situation)
Dec 03 11:01:30 <JaMa> spaszkoPL: can you please send patch for both issues?
Dec 03 11:07:28 <koen> bluelightning: I only noticed it because of this: https://git.linaro.org/openembedded/jenkins-setup.git/commitdiff/ca099c869fd75c4451ed1b248d5296ba49c6dfd9
Dec 03 11:17:16 <bluelightning> koen: shouldn't LIBC_DEPENDENCIES be set differently that case though?
Dec 03 11:18:16 <bluelightning> (I have to admit to being very much unfamiliar with how this would need to work in the external toolchain case, it's not a configuration I ever use myself)
Dec 03 11:28:59 <spaszkoPL> JaMa : ok i will send if i will have more time :)
Dec 03 11:54:59 <koen> bluelightning: glibc-* should be RPROVIDED by the external-toolchain, but 'glibc' should never show up in explicit RDEPENDS
Dec 03 12:01:14 <bluelightning> koen: I'd suggest pinging khem...
Dec 03 12:01:26 <bluelightning> assuming you haven't already
Dec 03 12:02:47 <koen> will do
Dec 03 12:37:34 <Crofton|work> Anyone know if there are any wic pacthes in the queue for dizzy?
Dec 03 12:38:44 <koen> didn't armin send an overview for that last week?
Dec 03 12:38:48 <koen> or was that daisy?
Dec 03 12:41:12 <mago_> what's the most appropriate way to create a filesystem that contains another filesystem? for example, i'd like to create FAT partition that holds a linux rootfs in CPIO format. wic seems to be an appropriate tool to create partitions and populate the content, but it requires a rootfs artifact
Dec 03 12:41:31 <mago_> sorry, whats the most appropriate way to create a rootfs that contains another rootfs?
Dec 03 12:41:55 <Crofton|work> the inception class?
Dec 03 12:42:01 * Crofton|work is joking
Dec 03 12:42:05 <mago_> ;-)
Dec 03 12:42:50 <ndec> mago_: you make 2 images, and make them depend on each other.
Dec 03 12:43:17 <ndec> i have an example somewhere. let me find it
Dec 03 12:43:23 <mago_> ndec: appreciate it
Dec 03 12:43:29 <Crofton|work> that would be to easy
Dec 03 12:43:46 <spaszkoPL> Question, probably easy :) : In mesa.inc there's a line PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl virtual/mesa", but when i add to my IMAGE_INSTALL += "virtual/egl" it isn't working :P i have error ERROR: Nothing RPROVIDES 'virtual/egl' .
Dec 03 12:44:25 <JaMa> spaszkoPL: runtime != buildtime providers
Dec 03 12:45:23 <spaszkoPL> JaMa: Could you explain it more?
Dec 03 12:45:36 <ndec> mago_: let's say you have image_A.bb and image_B.bb, and you want to include the rootfs generated by image_B.bb in the rootfs of image_A.bb. then you add "do_rootfs[depends] += "image_B:do_rootfs" "
Dec 03 12:46:02 <ndec> so, essentially, when you are in do_rootfs of image_A you have 'access' to the rootfs of B.
Dec 03 12:46:25 <spaszkoPL> JaMa : or give me any link with bigger description?
Dec 03 12:46:48 <ndec> i have used that to create 'chroot' images inside rootfs, so that we can run command in minimal chroot
Dec 03 12:46:58 <JaMa> spaszkoPL: maybe I'll after you send patches, if I have time :)
Dec 03 12:47:33 <spaszkoPL> JaMa :P
Dec 03 12:49:01 <mago_> ndec: yeah, okay, and then I install image_B's rootfs file into image_A's rootfs using a recipe that does do_install(), and finally set the desired image type using IMAGE_FSTYPES = "vfat" ? (assuming vfat is available)
Dec 03 12:50:30 <ndec> well, now you have the complete rootfs to include which is ready. so you can make an image preprocess command in your 'main' image and manipulate image_B however you want.
Dec 03 12:51:13 <ndec> mago_: here is the complete code snippet i've used: http://pastebin.com/2xuQkc5x
Dec 03 12:51:24 <mago_> if i'm only interested in the final/packaged version of image_B, i should [depends] on image_B:do_deploy, right?
Dec 03 12:51:31 <mago_> thanks
Dec 03 12:51:59 <ndec> iirc, images only have rootfs task. 
Dec 03 12:52:10 <mago_> okay, great
Dec 03 12:53:00 <ndec> i mean the image is deployed already when rootfs task complete
Dec 03 12:56:38 <mago_> this is exactly what i needed, thank you ndec 
Dec 03 13:17:38 <Crofton|work> hmm, it look slike the dizzy maintainers have been drinking
Dec 03 13:19:00 * Crofton|work summons a dizzy maintainer
Dec 03 13:21:25 <Crofton|work> they substituted one wic patch for another :)
Dec 03 13:21:37 <Crofton|work> and the other one is the one I needed ....
Dec 03 13:22:30 <bluelightning> Crofton|work: armpit is the person to talk to, he's not online yet though it seems
Dec 03 13:22:52 <Crofton|work> I need to send an email
Dec 03 13:23:19 <Crofton|work> Looking at tomz resquest, all the patches went in, except one is not on the list :)
Dec 03 13:24:31 <bluelightning> that's odd...
Dec 03 13:25:11 <Crofton|work> oh no, just one of the series missing
Dec 03 13:25:12 <mago_> bluelightning: if you "inherit image", it seems that something automatically installs a bunch of default stuff (/etc/, /lib/, usr/, /var with a small number of files in them). Do you know if thats possible to prevent? I just want an empty image 
Dec 03 13:25:20 <Crofton|work> it is early
Dec 03 13:25:55 <bluelightning> mago_: there's an open bug for that: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6478
Dec 03 13:26:02 <bluelightning> mago_: assigned to me, I'm ashamed to say...
Dec 03 13:26:15 <mago_> busted ;-)
Dec 03 13:26:21 <bluelightning> heh
Dec 03 13:26:48 <mago_> so maybe i should just add a IMAGE_POSTPROCESS_COMMAND that gets rid of them using some good ol' "rm -rf"? :)
Dec 03 13:27:34 <bluelightning> that would be a reasonable workaround for now I guess yeah
Dec 03 13:27:56 <mago_> only my poor non-SSD drive will scream if i give it more I/O
Dec 03 13:29:07 <bluelightning> my build machine doesn't have an SSD either FWIW...
Dec 03 13:29:24 <mago_> at least you seem to have a separate machine for building :)
Dec 03 13:29:59 <bluelightning> I do... my main machine is a laptop, so not really ideal for regular builds
Dec 03 13:31:10 <mago_> same here, it's reasonably fast though, i7 with 6gb of ram. I also have a build server for official builds using jenkins, but i find it difficult to use for hacking 
Dec 03 13:57:39 <mago_> isn't it conceptually weird that a rootfs image depends on the bootloader? i understand why it would depend on the kernel, because we probably can't compile everything in the rootfs without first building the kernel, but the bootloader (like u-boot), shouldn't be required to build the rootfs, right?
Dec 03 14:01:59 <bluelightning> it depends ;)
Dec 03 14:02:35 <mago_> ;-)
Dec 03 14:02:50 <bluelightning> and the dependency is a little bit different than that for parts that go into the image; i.e. the bootloader is usually in the image's EXTRA_IMAGEDEPENDS rather than RDEPENDS/DEPENDS
Dec 03 14:03:06 <bluelightning> which effectively only means it needs to be built alongside it
Dec 03 14:06:01 <mago_> yeah, i guess that's kind of a "convenience" feature of the buildsystem? performing tasks that don't really produce input that any other part of the system needs. Of course it makes sense to build everything in the same tree, since all the files and tools are already there. But when I think of an "image", i think of a single delivery
Dec 03 14:08:43 <peteru> I'd like to see the opposite. The build everything and the kitchen sink option. Well, to be precise, this week I would like an image and a matching SDK in one go. ;-)
Dec 03 14:10:00 <bluelightning> peteru: you could fairly easily create a dummy task that depends on do_rootfs and do_populate_sdk of an image too accomplish that (even make that task the existing do_build of the image, so bitbake imagename will also build the SDK)
Dec 03 14:10:33 <peteru> It's good to see that the mailing list has some traffic related to the SDK and development workflow in general. Can't wait for the improvements to make it in the official tree.
Dec 03 14:11:20 <bluelightning> peteru: if you have any thoughts on that stuff we'd definitely be interested to hear them
Dec 03 14:12:55 <peteru> I've been lurking. So far I like everything I see. About the only suggestion I would have is to perhaps get someone from the documentation side (Jessica?) involved early, in case they are not already watching.
Dec 03 14:13:42 <bluelightning> peteru: right, that would be Scott... yes, we should definitely do that
Dec 03 14:23:07 <peteru> bluelightning: I like that devtool has a deploy option. I wonder if rsync could be an alternative to scp.
Dec 03 14:24:50 <bluelightning> peteru: indeed, I'd wondered the same thing
Dec 03 14:25:19 <bluelightning> at the very least it would be good to have as an option
Dec 03 14:35:28 <mago_> bluelightning: is it expected that changes to a IMAGE_PREPROCESS_COMMAND function doesn't trigger a rebuild?
Dec 03 14:35:29 <peteru> I've had a few instances in the past where scp could not update a file (I think it was an executable that was still running on the target), whereas rsync worked just fine. I think it was a case of scp trying to overwrite an open file vs rsync using a create, rename, delete approach.
Dec 03 14:40:29 <bluelightning> mago_: it's a semi-known issue, due to the way the code that reads those variables has been written
Dec 03 14:40:38 <bluelightning> mago_: we should really explicitly add dependencies to fix it
Dec 03 14:41:33 <bluelightning> I think I will open a bug about that right now actually
Dec 03 14:42:18 <mago_> sorry for nagging so much about these caching things
Dec 03 14:42:44 <mago_> i seem to run into scenarios when build doesn't detect changes all the time
Dec 03 14:43:04 <mago_> (even though i only make changes to the meta files)
Dec 03 14:48:25 <bluelightning> mago_: no problem, we do want to fix these things
Dec 03 14:48:46 <bluelightning> mago_: I think RP_ is working on a fix for the issue now as it happens
Dec 03 14:49:00 <bluelightning> (the file issue you reported earlier)
Dec 03 14:49:21 <mago_> oh, that is very good news
Dec 03 14:57:21 <bluelightning> ok, bug entered: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7024
Dec 03 15:04:40 <mago_> great, excellent
Dec 03 15:06:01 <RP> bluelightning: commented on that, the mechanism exists
Dec 03 15:06:10 <RP> bluelightning: some of the ones you listed are already added
Dec 03 15:06:20 <RP> or there is code to do that at least, it may or may not be working
Dec 03 15:08:36 <bluelightning> RP: right, I completely missed that
Dec 03 15:08:49 <bluelightning> I believe almost all of those are listed, which suggests it may not be working...
Dec 03 15:10:58 <RP> bluelightning: right, just wanted to be clear its supposed to work so we don't get a second implementation!
Dec 03 15:11:57 <bluelightning> RP: right, good point... I've followed up on the bug
Dec 03 15:13:04 <RP> bluelightning: can you put some details about the reports of what isn't working specifically? I just worry the details may get lost
Dec 03 15:15:07 <bluelightning> mago_: ^ can you please comment on the bug?
Dec 03 15:18:47 <mago_> well, i'm not sure if we're talking about the same thing here. My issue is that if I add a preprocess-command, like IMAGE_PREPROCESS_COMMAND += "test; " .. and then later on, make changes to my test() { .. } function, it doesn't get re-run. Perhaps you two are discussing actual changes to the IMAGE_PREPROCESS_COMMAND variable? If not, I can add this as a comment to the bug
Dec 03 15:22:30 <bluelightning> I think my bug report might be completely wrong at this point
Dec 03 15:23:05 <bluelightning> I'm sure I came across another instance of what I did describe, but I don't have the details and now I'm wondering if it's still an issue or not
Dec 03 15:24:24 <bluelightning> mago_: please add your comment
Dec 03 15:24:31 <mago_> okay
Dec 03 15:35:14 <Crofton|work> have I ever mentioned I hate x86
Dec 03 15:36:11 <bluelightning> Crofton|work: nooooo
Dec 03 15:36:18 <bluelightning> ;)
Dec 03 15:36:27 <Crofton|work> so JaMa 's email about pyqt fail
Dec 03 15:36:49 <Crofton|work> I would half expect tthe fail to be 64 bit related, but not 32
Dec 03 15:37:12 <JaMa> 64 bit build isn't finished yet
Dec 03 15:37:15 <JaMa> probably it fails too
Dec 03 15:37:21 <Crofton|work> :)
Dec 03 15:37:54 <Crofton|work> hmm, I need to look at the patch I dropped
Dec 03 15:38:05 <Crofton|work> I think I ahve an idea
Dec 03 16:03:59 <blindvt`> hi
Dec 03 16:06:15 <blindvt`> blindvt`, boost.inc remove BOOST_PARALLEL_MAKE handling; bug requiring capping to -j64 was fixed 2 years ago, 1.56 (current and current in oe) does not need this anymore
Dec 03 16:10:51 <Crofton|work> have I mentioend how scary the boost recipe is?
Dec 03 16:11:32 <blindvt`> blindvt`, bind should be bumped to 9.9.6
Dec 03 16:12:34 <blindvt`> Crofton|work: \"Oh yippee, a new build system, it's sooo cooool I could eat my own foot\"
Dec 03 16:14:33 <blindvt`> Crofton|work: we could increment that. IIRC bjam does not really work too well nowadays either. At least /me thinks of segfaults and frankenstein-patches for bjam. Probably just me though
**** ENDING LOGGING AT Thu Dec 04 02:59:58 2014