**** BEGIN LOGGING AT Thu Oct 10 02:59:58 2013
Oct 10 07:24:17 <mckoan> good morning
Oct 10 08:58:23 <bluelightning> morning all
Oct 10 09:56:46 <n01> guys, any suggestion on how to generate a custom tarball with inside rootfs, modules, kernel, and such?
Oct 10 09:58:50 <ndec> n01: it's not quite clear what you want to do.
Oct 10 10:02:16 <n01> ndec: now in deploy dir I have separate files for rootfs,modules,u-boot,kernel ... what I want is having as output one single tarball containing pretty much everything
Oct 10 10:02:57 <ndec> n01: you can define IMAGE_POSTPROCESS_CMD that runs after the image is done.
Oct 10 10:03:13 <ndec> you should be able to combine them from this function
Oct 10 10:05:41 <n01> ndec: tnx
Oct 10 12:06:35 <zaif> When I add 'Libeigen' to my image, then build fails. It says 'Function failed: do_rootfs' and 'Unable to resolve package libeigen | ERROR: some packages were missing'. Any idea where I am doing wrong?
Oct 10 12:09:11 <JaMa> did you use capital L in IMAGE_INSTALL?
Oct 10 12:10:03 <zaif> no
Oct 10 12:10:07 <zaif> libeigen
Oct 10 12:20:51 <n01> any idea why using core-image-minimal my kernel isn't copied in /boot?
Oct 10 12:25:47 <n01> nvm, solved
Oct 10 12:59:13 <beuh> does anyone already have this issue with perl? Can't locate feature.pm in @INC (@INC contains: /etc/perl /usr/lib/perl/site_perl/5.14.3/ .........
Oct 10 13:08:59 <zaif> When I add 'libeigen' to my image, then build fails. It says 'Function failed: do_rootfs' and 'Unable to resolve package libeigen | ERROR: some packages were missing'. Any idea where I am doing wrong?
Oct 10 13:17:07 <rburton> the library probably gets renamed to libeigen1 or something, after the soname
Oct 10 13:17:41 <rburton> have a look in tmp/deploy/(rpm/ipk/deb) and you'll see the final package names
Oct 10 13:23:03 <zaif> :rburton: libeigen.rpm is empty
Oct 10 13:23:45 <zaif> it looks like the package is not downloaded.
Oct 10 13:24:49 <rburton> sounds like your recipe isn't building what you expect
Oct 10 13:24:55 <rburton> if you have bb, use bb contents libeigen
Oct 10 13:25:23 <rburton> otherwise, you can look in tmp/work/[machine]/.../packages-split/
Oct 10 13:25:29 <rburton> to see what went where
Oct 10 13:32:33 <oneQubit> I'm getting a .so in my -dev package, any things that I can quickly check?
Oct 10 13:38:05 <Garibaldi|work> oneQubit: is that unusual?
Oct 10 13:38:25 <oneQubit> Garibaldi|work, yes, it should be in the main package (this is a new recipe)
Oct 10 13:38:56 <oneQubit> I've even tried manually adding it FILES_${PN}
Oct 10 13:42:31 <Garibaldi|work> oneQubit: by default, .so files go in the -dev package
Oct 10 13:42:50 <Garibaldi|work> .so.X would go in ${P}
Oct 10 13:42:55 <Garibaldi|work> where X is some version number
Oct 10 13:44:13 <Garibaldi|work> it is changable, but you'd be going outside the norm to do it
Oct 10 13:44:37 <oneQubit> ahhh, yes, I see now (been a while since I've been playing with library recipes). There's no version numbers, so the .so isn't a link, it's the library itself
Oct 10 13:46:35 <oneQubit> how should I fix it? rename the .so to .so.0, or somehow force the library into ${P}?
Oct 10 13:48:23 <rburton> if its a *library* you tell the authors to version their library
Oct 10 13:48:40 <rburton> if its a module then you can unset FILES_${PN}-dev to ignore it
Oct 10 13:49:14 <oneQubit> it's a gnuradio Out of Tree module
Oct 10 13:51:05 <oneQubit> so I guess that answers that
Oct 10 13:53:35 <oneQubit> Crofton|work, I'm curious your opinion since this is sure to come up sooner or later, for gnuradio OOT modules should we nix -dev?
Oct 10 13:53:55 <n01> in my machine file I have defined KERNEL_DEVICETREE and the dtb is correcly generated. the problem is that it is not copied in /boot as indicated in do_install_append() in linux-dtb.inc
Oct 10 13:54:25 <n01> in my kernel recipe I have  require recipes-kernel/linux/linux-dtb.inc
Oct 10 13:54:31 <Crofton|work> hmm, I need to see a recipe and see what happens :)
Oct 10 13:55:52 <Crofton|work> I also need to review https://github.com/balister/meta-oe/commit/c0ce9272723f095b324e9f018765e7f0cacd6412
Oct 10 13:55:57 <Crofton|work> semi afk atm
Oct 10 13:56:48 <oneQubit> Crofton|work, http://pastebin.com/er3r1sbf
Oct 10 13:58:03 <oneQubit> ooh, nice commit, gonna be a lot nicer
Oct 10 14:00:18 <Crofton|work> drop PR btw
Oct 10 14:00:20 <Crofton|work> bbl
Oct 10 14:00:26 <oneQubit> Crofton|work, disregard the pastbin, https://gist.github.com/jawilson/6918841
Oct 10 14:09:02 <TuTizz> n01, IMAGE_INSTALL += " \	${CORE_IMAGE_BASE_INSTALL} \ install uImage in /boot for me
Oct 10 14:10:34 <n01> TuTizz: I solved for u-boot now the problem is dtb
Oct 10 14:16:27 <zaif> rburton: under tmp/work/[machine]/.../packages-split/ libeigen dir is empty and in 'libeigen-dev' source is extracted.
Oct 10 14:16:50 <zaif> libeigen-dbg is also empty
Oct 10 14:19:27 <jackmitchell> what is the easiest way to provide a root password? Override the shadow file?
Oct 10 14:22:50 <rburton> zaif: so have a look in package/ and see what got installed, and see if anything is missing.  sounds like your do_install is broken.
Oct 10 14:37:21 <zaif> rbuton: what is package/ path? (Sorry for basic question) and how do i repair do_install?
Oct 10 14:38:23 <rburton> package/ is alongside packages-split
Oct 10 14:40:26 <zaif> rbuton: in /package these files are present /usr, /include, /eigen3, /Eigen(Source is extracted here)
Oct 10 14:42:22 <zaif> Source I mean /src files
Oct 10 14:44:09 <rburton> so you probably need to package /eigen3 into your package, in FILES_*
Oct 10 14:44:19 <rburton> you should have got a warning about that
Oct 10 14:45:12 <rburton> also installing into /eigen3 is horrible.
Oct 10 14:46:17 <zaif> in .bb FILES_${PN} = "${includedir} ${libdir}"
Oct 10 14:46:25 <zaif> is it here I need to make changes?
Oct 10 14:46:55 <rburton> assuming you can't stop it putting files into /eigen3/, yes
Oct 10 14:49:20 <zaif> so, i guess i should change it to this: FILES_${PN} = "${includedir}
Oct 10 15:57:16 <tlwoerner> "OpenWRT, the most used Linux distribution for embedded devices" ??
Oct 10 15:57:21 <tlwoerner> http://blog.arduino.cc/2013/05/18/welcome-arduino-yun-the-first-member-of-a-series-of-wifi-products-combining-arduino-with-linux/
Oct 10 16:00:00 <bluelightning_> hmm, seems a little bit optimistic
Oct 10 16:00:24 <bluelightning> I wonder if you could practically measure that...
Oct 10 16:00:29 <bluelightning> it wouldn't be easy
Oct 10 16:02:00 <rburton> this is why we need to get a ntp pool for yocto
Oct 10 16:02:09 <rburton> so every instance pings that
Oct 10 16:02:20 <tlwoerner> and if you have an embedded board running linux what would be the purpose of tacking on the atmega on the side?
Oct 10 16:03:06 <tlwoerner> rburton: that'd only work if the target device is network enabled, and can route to the internet
Oct 10 16:03:44 <rburton> tlwoerner: sure, but it would set an interesting lower bound
Oct 10 16:03:50 <tlwoerner> (not that i'd be in favour of this, but...) maybe a modification to the build so that it pings something with every run of "bitbake"?
Oct 10 16:04:20 <tlwoerner> hook into do_rootfs :-)
Oct 10 16:04:32 <rburton> that doesn't tell you how many deployments that bitbake run caused
Oct 10 16:05:42 <tlwoerner> rburton: true, if you wanted to count deployments. if you wanted a "feel" for how much it's "used", however... :-)
Oct 10 16:54:06 <Crofton|work> look at hits omn the source mirrors :)
Oct 10 17:41:27 <mr_science> bluelightning: apparently there's some clean-up to do
Oct 10 17:41:44 <mr_science> probably should've scrubbed the recipe first...
Oct 10 17:42:39 <bluelightning> mr_science: no problem at all
Oct 10 17:44:07 <mr_science> i followed the patch submission stuff from that link you provided bu apparently there are some issues there too
Oct 10 17:44:40 <mr_science> so maybe you could explain a couple of those comments later?
Oct 10 17:48:37 <bluelightning> ah, sure
Oct 10 17:48:49 <bluelightning> I have to get a train home now but will be online later
Oct 10 17:50:55 <mr_science> i'll be at work for several hours...
Oct 10 18:04:37 <otavio> Hi there; how I can make a 'class' to be picked from a layer, not poky one?
Oct 10 18:04:42 <otavio> it is not working in my case
Oct 10 18:10:38 <kergoth> just put it in classesa nd mkae sure your layer.conf is correct (adds layer to BBPATH)
Oct 10 18:10:42 <kergoth> and make sure its priority is higher
Oct 10 18:10:51 <kergoth> erm, no, make sure its before poky in BBLAYERS
Oct 10 18:24:08 <otavio> kergoth: ahhhhhhhhhhhhhhhhhh
Oct 10 18:24:25 <otavio> kergoth: so classes does not respect the priority right?
Oct 10 18:24:32 <otavio> bad bad bad :-(
Oct 10 18:24:34 <otavio> ok
Oct 10 18:26:44 <mario-goulart> Isn't the priority for recipe files? (assuming you are talking about BBFILE_PRIORITY)
Oct 10 18:27:56 <evanp> tlwoerner: bitbake already phones home when you use it--the I-can-download-something sanity check
Oct 10 18:29:13 <tlwoerner> evanp: good point. are these "phone home" stats available somewhere?
Oct 10 18:31:39 <kergoth> yeah, layer priority only controls recipes and bbappend order, conf/classes obey BBLAYERS order
Oct 10 18:31:42 <kergoth> unfortunately
Oct 10 18:32:20 <kergoth> otavio: at mentor, our setup scripts control the included layers, and it automatically reorders them by recipe priority, to avoid this, but that has other complications..
Oct 10 18:32:23 <kergoth> heh
Oct 10 18:33:12 <otavio> Oh got it
Oct 10 18:33:20 <otavio> other? which?
Oct 10 18:33:49 <kergoth> well, it means manual bblayers.conf editing wouldn't get reordered, since its done at a layer above/before bitbake, so it forces us to use the setup script interface to add additional layers
Oct 10 18:34:01 <otavio> kergoth: mind to share more info?
Oct 10 18:35:08 <kergoth> https://github.com/MentorEmbedded/meta-mentor/blob/master/scripts/bb-determine-layers - uses a glob pattern and a list of default and additional layer names, along with the machine name, to determine what layers to include, then handles their dependencies (auto-includes dependent layers where appropriate) and reorders by priority
Oct 10 18:35:59 <kergoth> still not 100% happy with it, but it's working for now. https://github.com/MentorEmbedded/meta-mentor/blob/master/scripts/setup-mel-builddir#L85-L101 uses it
Oct 10 18:36:34 <kergoth> i'd rather avoid the 'locate hte layers that include this machine .conf' logic in favor of including all the bsp layers, but not all bsp layers work well with others :)
Oct 10 18:41:53 <otavio> kergoth: cool; will check it :-) thanks a lot
Oct 10 18:45:14 <kergoth> np
Oct 10 19:37:14 <mr_science> if i start to squawk like a chicken, please shoot me...
Oct 10 23:09:30 <ant_home> here with default distro:
Oct 10 23:09:31 <ant_home> WARNING: The recipe shadow-native is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
Oct 10 23:09:31 <ant_home>    /oe/oe-core/build/tmp-eglibc/sysroots/i686-linux/bin/login
Oct 10 23:09:31 <ant_home>    Matched in manifest-i686-util-linux-native
Oct 10 23:09:31 <ant_home> Please verify which package should provide the above files.
**** ENDING LOGGING AT Fri Oct 11 02:59:58 2013