**** BEGIN LOGGING AT Tue Jan 13 02:59:59 2015
Jan 13 06:39:38 <mranostaj>  /msg NickServ VERIFY REGISTER mranostaj gyzqzdqtahjg
Jan 13 06:39:45 <mranostaj> dammit
Jan 13 07:20:01 <chankit> kergoth: ping
Jan 13 08:14:40 <chankit> how do we enable multilib in yocto?
Jan 13 08:49:14 <mckoan> good morning
Jan 13 09:20:56 <bluelightning> morning all
Jan 13 10:24:38 <jaeckel> lo
Jan 13 10:25:23 <jaeckel> I killed a running bitbake instance because it waited for an SSH key password and there was not dialog
Jan 13 10:25:48 <jaeckel> now I have an error when I try to run bitbake again
Jan 13 10:26:58 <jaeckel> http://pastebin.com/vMadmfZt
Jan 13 10:27:17 <jaeckel> does someone know how to recover from that error?
Jan 13 10:29:27 <bluelightning> jaeckel: find the process that is still running and end it?
Jan 13 10:31:07 <jaeckel> thanks
Jan 13 10:31:26 <jaeckel> o easy
Jan 13 10:31:28 <jaeckel> so
Jan 13 11:36:02 <neverpanic> I think the license in openembedded-core:recipes-devtools/perl/perl_5.20.0.bb should be Artistic-1.0 | GPL-1.0+ rather than Artistic-1.0 | GPL-1.0. Should I file a bug about that, or is that something somebody here is willing to change without the hassle of a bug report?
Jan 13 11:38:33 <neverpanic> Also, openembedded-core:recipes-extended/pigz/pigz_2.3.1.bb should be Apache-2.0 & Zlib, not Apache-2.0 only.
Jan 13 11:39:17 <neverpanic> And finally, libopkg is GPL-2 but links against OpenSSL, so by some interpretations of the GCC system library exceptions needs an OpenSSL Exception; where would I bring this up?
Jan 13 11:47:59 <bluelightning> neverpanic: for the latter one - at least currently, linking to openssl defaults to off
Jan 13 11:48:39 <bluelightning> neverpanic: you could always talk to Paul Barker, the current maintainer of opkg, but I suspect that any relicensing would be difficult based on opkg's history
Jan 13 11:50:32 <neverpanic> Yeah, that's what I expected. I'll try anyway, thanks.
Jan 13 11:55:51 <bluelightning> neverpanic: re pigz, you're right - except here I have "Zlib" as the current value rather than "Apache-2.0" so I guess the latter needs to be added
Jan 13 11:56:25 <neverpanic> Yeah, sorry about that, messed that up in our internal bugtracker and didn't re-check in the file.
Jan 13 12:03:33 <bluelightning> I can verify the perl one as well
Jan 13 12:03:40 <bluelightning> thanks, I will send a couple of patches
Jan 13 13:56:32 <ramose> can any one please point me out reason for this error ,NOTE: <type 'exceptions.ValueError'>:dictionary update sequence element #0 has length 1; 2 is required while evaluating: ${@get_lsb_data(d)['Distributor ID']}
Jan 13 13:56:57 <ramose> I'm trying to build an minimal image
Jan 13 14:00:57 <Metax> Hello
Jan 13 14:01:32 <Metax> i'm looking for the differences between poky and angstrom.
Jan 13 14:02:17 <Metax> i don't know what are the criterions to choose which use.
Jan 13 14:15:23 <kimo_> Hi, how do we remove kernel image from build ?
Jan 13 14:20:27 <RP> kergoth: I think memory resident bitbake just became properly usable :)
Jan 13 14:28:25 <Crofton|work> tomz, does wic refuse to make a partition that is smaller than the rootfs size?
Jan 13 14:32:31 <bluelightning> kimo_: you can do PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
Jan 13 14:33:35 <tomz> Crofton|work: hmm, not explicitly, but I've never tried it.  Wondering why you would want that though.
Jan 13 14:33:55 <Crofton|work> I am tryin gto fit something on a 4G card
Jan 13 14:34:13 <Crofton|work> part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 4 --size 1
Jan 13 14:34:29 <Crofton|work> it feels like no matter how small I make --sie, I get eh same size image
Jan 13 14:34:50 <Crofton|work> testing on 1 now :)
Jan 13 14:37:12 <Crofton|work> I would expect an error, since I am trying to use a too small root partition
Jan 13 14:37:20 <tomz> Crofton|work: try removing --source rootfs
Jan 13 14:37:36 <kergoth> RP: wow, really? I haven't followed it that closely, that sounds fantastic
Jan 13 14:37:40 <Crofton|work> ok
Jan 13 14:39:03 <Crofton|work> is there a good write up on these options?
Jan 13 14:41:15 <RP> Crofton|work: see the last commit message I posted on the bitbake-devel list
Jan 13 14:41:35 <Crofton|work> ok ...
Jan 13 14:41:39 <RP> Assuming nobody objects to the pynotify dependency, it works nicely
Jan 13 14:42:14 <RP> kergoth: sometimes things just feel "right" and this feels like that
Jan 13 14:42:16 <tomz> Crofton|work: well, there's the 'wic help kickstart' but it doesn't say anything about empty partitions, which it should.  i'll add it to my list of wic todo's i.e. create a bug for it
Jan 13 14:42:42 <Crofton|work> what does source rootfs do?
Jan 13 14:42:56 <fray> RP -- using the memory resident does it use the notify to rebuild when changes are made then?
Jan 13 14:43:04 <RP> Crofton|work: we're talking cross purposes btw, sorry
Jan 13 14:43:06 <Crofton|work> I am trying to fit the rootfs in a specifc sized partition, but it lok slike wic is increasing partition size, and not erroring
Jan 13 14:43:08 <RP> fray: yes
Jan 13 14:43:09 <Crofton|work> np
Jan 13 14:43:33 <Crofton|work> if I drop --source, then I et an empty partition?
Jan 13 14:44:21 <tomz> Crofton|work: it creates a partition large enough to populate with the rootfs contents, then populates it.  yeah, if you don't specify a --source then it creates an empty partition
Jan 13 14:44:38 <Crofton|work> no, I need a source
Jan 13 14:44:55 <Crofton|work> so you can't use size and depend on an error to say rootfs is too large?
Jan 13 14:45:34 <tomz> Crofton|work: making it larger than the rootfs would be fine, but it doesn't make sense to make it smaller, right?
Jan 13 14:45:49 <Crofton|work> I am targeting a fixed size card
Jan 13 14:46:05 <Crofton|work> so I ahve an upper limit for total image size
Jan 13 14:47:25 <tomz> Crofton|work: you can use size with --source rootfs to make it larger, but smaller would be wrong.  It would make sense to display an error for that case, surprised it doesn't, should be a bug then
Jan 13 14:47:38 <Crofton|work> ok
Jan 13 14:47:46 <Crofton|work> I will create a bug
Jan 13 14:47:57 <Crofton|work> It appears to make one big enough
Jan 13 14:48:13 <Crofton|work> I was wondering wtf was going on
Jan 13 14:48:22 <tomz> Crofton|work: ok, thanks
Jan 13 14:48:37 <Crofton|work> the alternate question was, "please explain the units of "--size" " :)
Jan 13 14:49:44 <tomz> Crofton|work: that at least is documented in 'wic help kickstart'  ;-)  : --size: The minimum partition size in MBytes
Jan 13 14:49:59 <Crofton|work> yeah
Jan 13 14:50:30 <Crofton|work> I was getting confused when I was fiddling with it, until I realized that changing it didn't change the overall image size
Jan 13 14:52:30 <kergoth> RP: nice, will have to try it out
Jan 13 15:03:55 <darkhorse_> anyone: native version of my recipes does not populate sysroot directory. I do see do_populate_sysroot() has run but the output of the image directory is not copied to native sysroot
Jan 13 15:11:17 <bluelightning> darkhorse_: your do_install is installing things under ${D} right?
Jan 13 15:14:44 <darkhorse_> bluelightning: yes do_install is doing the right thing - populates ${D}
Jan 13 15:15:42 <bluelightning> darkhorse_: how did you make the native version of your recipe? inherit native or BBCLASSEXTEND = "native" ?
Jan 13 15:16:08 <darkhorse_> bluelightning: using 'inherit native'
Jan 13 15:17:29 <Crofton|work> tomz, https://bugzilla.yoctoproject.org/show_bug.cgi?id=7132
Jan 13 15:17:31 <yocti> Bug 7132: normal, Undecided, ---, mark.hatle, NEW , wic not respecting --size parameter when file system contents larger than requested size
Jan 13 15:17:59 <bluelightning> darkhorse_: ok, what paths are you installing files into under ${D} ? are they in standard directories i.e. bindir / libdir or custom?
Jan 13 15:20:12 <ramose> Can any  one tell me where I can find Missing or unbuildable dependency chain was: ['libvirt', '${PYTHON_PN}-native'], '${PYTHON_PN}-native recipe?
Jan 13 15:20:52 <darkhorse_> bluelightning: they are in standard directories, bindir
Jan 13 15:21:10 <tomz> Crofton|work: ok, thanks.  I also added: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7131
Jan 13 15:21:11 <yocti> Bug 7131: normal, Undecided, 1.8 M3, tom.zanussi, ACCEPTED , wic: document empty partition creation
Jan 13 15:21:35 <bluelightning> darkhorse_: and you definitely aren't poking files directly into the sysroot anywhere?
Jan 13 15:22:03 <Crofton|work> yeah, I'm sure that will come up
Jan 13 15:23:08 <bluelightning> ramose: that ${PYTHON_PN} reference should not be there, that suggests PYTHON_PN has not been set and needs to be in whatever context you are attempting to use it
Jan 13 15:23:34 <darkhorse_> bluelightning: nope. my recipe is really simple: inherits native, override do_compile() and do_install() and that's all. within do_install() i pass DESTDIR="${D}" to oe_runmake
Jan 13 15:24:23 <ramose> bluelightning: How should I set it if its not set ?
Jan 13 15:24:26 <darkhorse_> bluelightning: and then after recipe has run,  I can see the output in ${D}/usr/bin but not is <sysroot>/usr/bin
Jan 13 15:24:40 <bluelightning> ramose: is this part of your backporting?
Jan 13 15:27:15 <ramose> bluelightning: yes but its another package
Jan 13 15:27:44 <bluelightning> ramose: just replace ${PYTHONPN} with python then
Jan 13 15:28:12 <bluelightning> darkhorse_: anything under sysroot-destdir/ under the workdir for the native recipe?
Jan 13 15:29:14 <darkhorse_> bluelightning: nope - its empty
Jan 13 15:30:35 <darkhorse_> bluelightning: for some other native recipes which work fine and populate sysroot, I can see a director named 'home/ in sysroot-destdir/
Jan 13 15:30:57 <bluelightning> right, yes
Jan 13 15:31:21 <bluelightning> darkhorse_: I honestly don't know what could be going wrong...
Jan 13 15:32:00 <darkhorse_> bluelightning: the only difference i suppose might be that I am using inherit native as opposed to BBCLASSEXTEND
Jan 13 15:32:11 <ramose> bluelightning: I'm trying to backport https://lists.yoctoproject.org/pipermail/meta-virtualization/2013-April/000384.html package,so I need to make change in ibvirt-python.inc?
Jan 13 15:32:22 <bluelightning> darkhorse_: inherit native definitely works, we use it all over the place
Jan 13 15:32:45 <darkhorse_> bluelightning: and I am working with dylan branch just in case it helps
Jan 13 15:32:55 <bluelightning> ramose: I'm sorry I don't have time to look into that, but probably yes
Jan 13 15:33:04 <bluelightning> darkhorse_: that alone shouldn't make a difference
Jan 13 15:33:45 <ramose> bluelightning: Ok,no issues ,Thanks  :)
Jan 13 15:33:50 <darkhorse_> bluelightning: okay - thanks for your help anyway
Jan 13 15:55:19 <armpit> YPTM: armin on
Jan 13 16:01:38 <joeythesaint> YPTM: Joe Mac on.
Jan 13 16:01:56 <sjolley> YPTM:   Ready-Access Number:    8007302996  Access Code:    2705751
Jan 13 16:02:03 <sjolley> YPTM: Stephen Joined
Jan 13 16:02:11 <tomz> YPTM: tom z on
Jan 13 16:02:12 <Sona_> YPTM: Sona is on
Jan 13 16:02:15 <cristianiorga> YPTM: Cristian joined
Jan 13 16:02:31 <RP> YPTM: Richard joined
Jan 13 16:02:41 <zeddii> YPTM: Bruce is on
Jan 13 16:03:08 <denix> YPTM: Denys is on
Jan 13 16:03:35 <rburton> YPTM: ross joined
Jan 13 16:03:38 <bluelightning> YPTM: Paul Eggleton is on
Jan 13 16:04:14 <RP> sjolley: I'll talk about memres bitbake
Jan 13 16:04:20 <sgw_> YPTM: Saul is here
Jan 13 16:07:29 <fray> YPTM: Mark here now
Jan 13 16:07:58 <AlexG> YPTM: AlexG on the bridge
Jan 13 16:11:37 <halstead> YPTM: Michael here.
Jan 13 16:24:36 <fray> I liek the idea..
Jan 13 16:27:25 <sjolley> YPTM: is over.
Jan 13 16:27:35 <halstead> E-mail michael@yoctoproject.org if you are seeing slow downloads and are willing to help collect stats.
Jan 13 16:31:55 <darkhorse_> bluelightning: just to let you know, that using BBCLASSEXTEND works okay :)
Jan 13 16:44:55 <bluelightning> darkhorse_: ok, great :)
Jan 13 16:48:38 <darkhorse_> bluelightning: one more thing: in a team environment, is it possible to share the sstate-cache among developers. what happens if multiple developers are modifying recipes and building randomly using the same sstate-cache?
Jan 13 16:50:42 <bluelightning> darkhorse_: yes, and that shouldn't be a problem... changing a recipe will almost certainly affect the signature of the appropriate tasks within it; so it shouldn't be possible for one developer to make a change that affects another (because then the results get written out as a separate set of sstate archives)
Jan 13 16:52:54 <neverpanic> but what if two developers are building the same recipe on different hosts? Would that cause conflicts?
Jan 13 16:54:26 <fray> no conflict.. since the checksum is unique to the contents of the item.  If for some reason two developers make IDENTICAL changes, and build at the same time most likely one will overwrite the sstate-cahce of the other.. but the contents will still be the sme
Jan 13 17:01:27 <darkhorse_> fray: and the checksum is done for all files related to a recipe? for example what if nothing has changed in the recepe itself but the package tarball at the source location has changed. or one of the files mentioned in the SRC_URI variable has changed
Jan 13 17:03:40 <fray> all of the items used by the task, if the task has file references (in the proper format) then yes
Jan 13 17:09:13 <jaeckel> when I start qemu through the runqemu script, how can I terminate the process without killing it? ...my kernel crashed...
Jan 13 17:10:43 <fray> ctrl-a x
Jan 13 17:11:20 <jaeckel> nice
Jan 13 17:11:21 <jaeckel> thanks
Jan 13 18:00:04 <kergoth> Hmm. wonder if it'd be kosher to suck in setuptools in recipetool. would add an additional host dep
Jan 13 18:39:06 <JaMa> zeddii: any update on perf failing to build for qemux86-64?
Jan 13 19:02:48 <suzu> i downloaded fsl-release-bsp from freescale , now i need to use "linux-imx-3.0.35" under kernel recipe instead of linux-imx
Jan 13 19:03:02 <suzu> where i need to change this default setting ?
Jan 13 20:13:14 <suzu> i downloaded fsl-release-bsp from freescale , now i need to use "linux-imx-3.0.35" under kernel recipe instead of linux-imx
Jan 13 20:13:24 <suzu> where i need to change this default setting ?
Jan 13 22:18:12 <darkhorse_> anyone please: do_packagedata_setscene fails each time for my kernel build
Jan 13 22:36:43 <Crofton|work> zeddii, ^^^
**** ENDING LOGGING AT Wed Jan 14 02:59:59 2015