**** BEGIN LOGGING AT Tue Sep 24 02:59:59 2013 Sep 24 07:06:42 good morning Sep 24 07:56:28 morning all Sep 24 07:57:57 morning Sep 24 08:05:37 gm bluelightning, TuTizz, all Sep 24 08:24:51 morning #oe Sep 24 08:57:27 hi all. I have following situation. In my linux.bb I have defined DEPENDS = "xenomai". However xenomai package is never build, and so build of linux fails. Sep 24 08:58:07 Is it because xenomai.bb is defined in the layer that follows the layer with linux, or something else should be added? Sep 24 08:59:40 i.e. can DEPENDS be used to note package that is in separate layer? Sep 24 09:07:01 any ideas? Sep 24 09:07:53 the layer the other recipe appears in is not an issue Sep 24 09:08:08 provided both layers are in your bblayers.conf Sep 24 09:08:23 yes, they are. But Linux layer comes first Sep 24 09:08:33 then my layer with xenomai recipe Sep 24 09:08:41 that's fine Sep 24 09:08:47 can you pastebin the actual error you are receiving? Sep 24 09:08:50 If I do bitbake xenomai before building linux Sep 24 09:08:52 then it works Sep 24 09:09:29 I will Sep 24 09:09:35 hang on a sec Sep 24 09:09:41 but basically - it did not even do a fetch of xenomai Sep 24 09:09:51 and it already begin configuring Linux Sep 24 09:10:08 and for this configuration it needs xenomai Sep 24 09:10:08 if you do bitbake -e | less and then search for ^DEPENDS= what do you see? Sep 24 09:10:22 perhaps the DEPENDS value you are setting is being overridden Sep 24 09:10:59 btw, if your kernel recipe is actually called linux_.bb you should rename it to something else Sep 24 09:11:01 bluelightning: hmmm... I do not see xenomai Sep 24 09:11:22 bluelightning: it is called linux_3.8.bb Sep 24 09:11:36 why? Sep 24 09:11:54 right, you should definitely rename it, because "linux" is in OVERRIDES and you can get some weird things happening Sep 24 09:12:23 you can call it linux-mainline or linux-custom or whatever, just not linux Sep 24 09:12:47 actually, when I look better it is linux-altera_3.8.bb, so it should be OK Sep 24 09:12:55 ok right, that's no problem then Sep 24 09:13:30 However, I can not see DEPENDS = "xenomai" from my linux-altera_3.8.bb recipe taken into account Sep 24 09:13:48 let me grep a bit Sep 24 09:13:59 so you're doing bitbake -e linux-altera | less ? Sep 24 09:14:09 yes Sep 24 09:14:57 try moving DEPENDS = "xenomai" to the end of the recipe and using += instead of = Sep 24 09:18:13 bluelightning: += did the trick, thanks! Sep 24 09:18:56 great! Sep 24 09:18:58 np Sep 24 09:19:04 What does this error mean? Sep 24 09:19:05 WARNING: QA Issue: gcc-cross-canadian-i586: found library in wrong location: /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/libexec/core2-oe-linux/gcc/i586-oe-linux/4.8.1/liblto_plugin.so.0 Sep 24 09:19:47 s/error/warning/ Sep 24 09:20:22 ok, warning, but still; if it's a warning it's still an issue right? Sep 24 09:21:11 it could be, but if you've not changed anything to do with gcc-cross-canadian I doubt it's an issue Sep 24 09:21:54 jackmitchell: is this with master, dylan or some other version? Sep 24 09:22:15 bluelightning: master Sep 24 09:25:39 it popped up as I was building an SDK, but I do have some custom recipes, but none which should be installing into the gcc folder as it appears above Sep 24 09:32:39 rburton: hi ! Sep 24 09:33:11 rburton: I've done what you said about the bootable usb-key, taken upstream changes but still not writing on the usb key Sep 24 09:41:25 elbc: odd, works for me with current oe-core/poky master. check the mounts when you've booted, you'll probably see overlay mounts putting a tmpfs on top of / (which means it thinks the media is read only, which it isn't) Sep 24 09:42:13 29f869b68a9017502f75915784a924f0fe9d4be1 (oe-core) fixed it for me Sep 24 09:42:18 " init-live.sh: distinguish between a read-only image and a read-write image" Sep 24 09:42:21 rburton: thanks I'll do that ! Sep 24 09:59:37 rburton: I have these commit changes in my patch. However I've found somethind : If I open the terminal and if I do ! mkdir or touch /home/elbc/foo after reboot it is not present, but there is some rootfs.ro and rootfs.rw directory present on the image, and if I do mkdir or touch rootfs.ro/home/elbc/foo it is still present after reboot Sep 24 10:00:09 rburton: so it should be something to do to do an mkdir on an easier way Sep 24 10:04:58 can you pastebin the output of "mount"? Sep 24 10:10:48 jackmitchell: ah, your commit message seemed to be saying that it couldn't find lmsensors-dev, but its lmsensors itself it can't find. another way of fixing that would be to reset the RDEPENDS on the dev packages. Sep 24 10:11:16 I would like to boot small initrd, then loopback mount big ext3 image form USB/SD and then chroot to big image Sep 24 10:11:29 Is support for such a scenario in Yocto? Sep 24 10:12:24 rburton: which would be preffered, I don't really mind either way if there is a precedent for this situation Sep 24 10:13:16 jackmitchell: a lot of the time you see allow empty, but that's the hack solution afaic Sep 24 10:13:45 so how would the RDEPENDS work? RDEPENDS_${PN}-dev = "" ? Sep 24 10:13:49 yes Sep 24 10:14:52 and that would take out the need for the lmsensors package and therefor work, so the error is actually saying it can't find *lmsensors* package, not *lmsensors-dev* Sep 24 10:15:40 rburton: http://pastebin.com/iJjLDhyr Sep 24 10:15:51 jackmitchell: exactly Sep 24 10:16:09 jackmitchell: you might want to review the -dev packaging to verify its doing the right thing too Sep 24 10:17:43 elbc: certainly looks like that fix isn't working for you. works for me though. Sep 24 10:18:48 rburton: ok thanks anyway. You've send a mail to me asking to split my patch in two patches, is there an esay way to do it or not ? Sep 24 10:19:20 elbc: you can use git rebase to do that, see the man page ("splitting a commit") is the section iirc Sep 24 10:19:41 ok thanks ! Sep 24 10:22:35 Krz_: I think that's what our live image support already does Sep 24 10:22:50 Krz_: there was code in oe-classic under recipes/initrdscripts and an initial implementation is now in recipes-core/initrdscripts Sep 24 10:23:10 the old one had the loopback mount Sep 24 10:27:02 ah, yes, the new one as well Sep 24 10:37:05 bluelightning: ant_work: that's great, I think it is called 'dracut' for PC distros Sep 24 10:37:43 Krz_: are you bound to loopback and chroot? Sep 24 10:38:01 ant_work: not yet, If you know any better solution, then I'm all for it Sep 24 10:38:17 Krz_: dracut builds an initramfs from the "main" system, we don't need to do that as we can just build one Sep 24 10:38:36 ant_work: I just need a solution of having ext3 image as a file, to let people use it without having to partition & format SD card Sep 24 10:40:11 Krz_: you do appear to be describing the existing hddimg setup Sep 24 11:02:47 rburton: does the hddimg have a logic to chroot to other image? Sep 24 11:14:13 Krz_: if you have a look at meta/recipes-core/initrdscripts/files/init-live.sh you can see how it is implemented Sep 24 11:14:20 Krz_: it uses switch_root Sep 24 12:04:22 HI all, can I add more SOURCE_MIRROR_URL? I have one package set in one dir, and would like to add some packages which I keep in another dir. Sep 24 12:08:42 hi to all! I've got a recipe A that installs some jar files in target /usr/local/share. How can I install that jar files under sysroot so a makefile-based recipe B can compile using that jar libraries? thanks! Sep 24 12:17:15 soldoKyn: if you install them to /usr/share instead of /usr/local/share I think you'll find they'll end up in the sysroot automatically Sep 24 12:21:57 bluelightning: when I bitbake initramfs-live-boot it creates ipk package instead of image. How do I make an image out of this? Sep 24 12:23:14 Krz_: you don't need to bitbake that recipe; just add "live" to IMAGE_FSTYPES and then build your image as normal Sep 24 12:29:48 bluelightning: and now I've got my jar libraries in sysroot folder! thank you so much!!! This is not the case, but if the /usr/local/share was mandatory, there would be a solution? Sep 24 12:31:23 soldoKyn: not quite sure but you'd have to stage the files manually and then I suspect you'd have to modify java paths to look there as well Sep 24 12:31:45 really, putting things in /usr/local is just the wrong thing to do Sep 24 12:31:57 IMO Sep 24 12:34:10 bluelightning: ok! thanks! Sep 24 13:14:15 bluelightning: I just added 'live' to IMAGE_FSTYPES and Yocto does not create additional image :( Sep 24 13:14:42 Krz_: you don't have a .hddimg file created in tmp/deploy ? Sep 24 13:17:09 bluelightning: no, have no idea why Sep 24 13:17:36 Krz_: perhaps IMAGE_FSTYPES has been overridden elsewhere in your configuration, use bitbake -e to check Sep 24 13:17:38 bluelightning: IMAGE_FSTYPES =+ "ext3 live" Sep 24 13:18:28 bluelightning: good shot, it got overwriten, will fix Sep 24 13:20:24 jwessel: hi there. May I know where did you set the initramfs vars in your tests? in local.conf? Sep 24 13:31:24 ant_work: Yes, I used the local.conf Sep 24 13:32:08 ok, that explains how kernel and image recipes could get the variable Sep 24 13:32:31 in my tests I only tried adding it to the custom kernel and bitbake it Sep 24 13:38:23 Is that something we need to make work? Sep 24 13:39:33 I don't know what can be defined 'general case' Sep 24 13:40:37 but I do care about our recipe, now unbuildable Sep 24 13:44:57 I think we should anyway let people embed their cpio in their custom kernel w/out building extra images Sep 24 13:45:33 just bitbake my-initramfs-powered-kernel Sep 24 13:45:53 oh, more than one Sep 24 13:46:07 so the INITRAMFS_IMAGE should be per-kernel recipe Sep 24 13:46:16 (as it was) Sep 24 13:46:19 The key problem with before was that you could not embed kernel modules using an initramfs recipe. Sep 24 13:46:52 How can I install a library in my meta-toolchain generated sdk? Sep 24 13:47:02 The INITRAMFS_IMAGE change be changed per recipe, at least I think that works. Sep 24 13:48:40 It is too bad bitbake has no way to re-invoke a task later. This is the main reason we have a problem in the first place. Sep 24 13:50:02 In your case it can probably be worked around by echoing the needed variables collected from the image recipe into a file and reading it back in while running inside the kernel recipe context. Sep 24 13:51:18 long ago we had initramfs with kernel modules inside... let me remember Sep 24 13:51:40 then the size of the image was too big so we discarded the shell Sep 24 13:51:54 and wrote our init in C Sep 24 14:06:10 jwessel: yes, it was cgit.openembedded.org/openembedded/tree/recipes/images/initramfs-bootmenu-image.bb Sep 24 14:10:08 I'm creating a simple BSP and I have included tune-atom, which automatically sets the architecture to i586, what variable do I set to force, i686, I can see it listed in tune-atom.inc, I just don't know where to set it in the BSP... Sep 24 14:20:13 bluelightning: I got 'live' into IMAGE_FSTYPES. Yocto throws an error 'cannot satisfy dependencies for initramfs-live-install: grub' Sep 24 14:20:49 Krz_: is this because your grub recipe doesn't produce any packages? Sep 24 14:21:53 it produces two packages: tmp/deploy/ipk/i586/grub-dev_0.97+git0+5775f32a6268dead6939d01cbe72f23972f6d3c0-r0_i586.ipk tmp/deploy/ipk/i586/grub-dbg_0.97+git0+5775f32a6268dead6939d01cbe72f23972f6d3c0-r0_i586.ipk Sep 24 14:22:55 right, but there is no "grub" package Sep 24 14:26:12 bluelightning: I could perhaps change it in bbappend to core-image-minimal-initramfs.bb Sep 24 14:28:40 bluelightning: git grep for initramfs just does not give me any pointer to where is that grub dependency hidden Sep 24 14:31:08 Krz_: "git grep grub" shows meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb:RDEPENDS_${PN} = "grub parted e2fsprogs-mke2fs" Sep 24 14:34:44 Krz_: I suspect if you don't want to use the "install" option from the live image then you could possibly remove that entirely Sep 24 14:36:14 bluelightning: whole do_install function from initramfs-live-install ? Sep 24 14:41:03 HI all, can I add more SOURCE_MIRROR_URL? I have one package set in one dir, and would like to add some packages which I keep in another dir. Sep 24 14:44:22 drasko: I don't think own-mirrors.bbclass supports more than one url, but you can do it by hand using PREMIRRORS (see what meta/classes/own-mirrors.bbclass does) Sep 24 14:48:30 rburton: I'm modifying my patch(es) but how can I cancel the previous one on http://patches.openembedded.org/patch/58639/ ? Sep 24 14:54:00 elbc: it's OK, this one will get marked as superseded when you send your v2 (i.e. if nobody else takes care of it I will) Sep 24 14:55:04 tbh i'm thinking i'll start to maintain a wayland-next branch unless somebody beats me to it Sep 24 14:56:32 rburton: ok thank you very much Sep 24 14:59:48 YPTM: Beth is on the line. Sep 24 14:59:53 YPTM: polk is here Sep 24 15:00:30 YPTM: Michael here Sep 24 15:00:35 YPTM: Scott Rifenbark joined the call Sep 24 15:00:42 YPTM: I'm here Sep 24 15:01:02 YPTM: welcome to the technical meeting. Please let me know who's on the bridge. Thanks, Sep 24 15:01:06 YPTM: Tom Z on Sep 24 15:01:13 YPTM: Björn joined the call Sep 24 15:01:17 YPTM: belen is on the call Sep 24 15:02:18 YPTM: Paul Eggleton is on Sep 24 15:02:21 YPTM: jzhang's on the call Sep 24 15:02:46 YPTM: Nitin on the bridge Sep 24 15:02:47 The Yocto Project Tech Meeting Con-Call is starting Sep 24 15:02:54 Dial-in number: 1.972.995.7777 / Participant passcode: 42001078 Sep 24 15:03:00 This call is open to all and the channel remains open to discuss any topic. Sep 24 15:03:12 YPTM: Saul is on the call Sep 24 15:03:18 YPTM: ross on the call Sep 24 15:03:23 YPTM: Richard is on the call Sep 24 15:03:37 YPTM: Any opens? Sep 24 15:03:56 Song_Liu: I'm guessing we'll talk about where we're at with 1.5? :) Sep 24 15:04:05 YPTM: 1.5 release candidates, where we stand... Sep 24 15:05:30 YPTM: AlexG on the call Sep 24 15:05:43 Song_Liu: can you paste that url? Sep 24 15:05:45 YPTM: Current 1.5 QA STatus: https://wiki.yoctoproject.org/wiki/1.5_QA_Status Sep 24 15:05:57 pidge: https://wiki.yoctoproject.org/charts/combo.html Sep 24 15:05:59 wdds Sep 24 15:06:04 pidge, https://wiki.yoctoproject.org/charts/combo.html Sep 24 15:06:13 https://wiki.yoctoproject.org/charts/combo.html Sep 24 15:06:28 rburton: http://patches.openembedded.org/patch/58679/ and http://patches.openembedded.org/patch/58681/ Sep 24 15:06:44 YPTM: Dropped the call Sep 24 15:06:50 but previous one seems to not to be cancelled maybe because of the commit name I don't know Sep 24 15:07:26 elbc: oe-core's patchwork is a bit broken, don't worry. thanks for posting them, just saw. Sep 24 15:12:53 yeah I don't even have access to change the status of patches on the OE-Core side Sep 24 15:14:44 rburton: ok, see you soon Sep 24 15:15:18 YPTM: Darren has joined (traffic) Sep 24 15:16:02 * zeddii just realized he forgot to dial Sep 24 15:19:34 YPTM: dropped Sep 24 17:35:23 can I define 'do_deploy' inside python anonymous? Sep 24 17:48:33 Anyone here have a poky image running on a Beaglebone Black with attached LCD7 Cape? Sep 24 17:52:01 Krz_: it's a little unusual but you could do it with d.setVar('do_deploy', '...') Sep 24 17:57:04 bluelightning: I think that's the only way to implement 'if/else' logic into recipe. I need to base my if/else logic on SDKMACHINE setting. Sep 24 17:58:12 Krz_: it depends, sometimes you can get away with doing that if/else logic in the anonymous python and setting variable(s) that you use later Sep 24 17:58:20 rather than setting an entire function Sep 24 18:00:19 bluelightning: I know what you mean. In my case I could probably use 'addtask' for that. My logic is simple, if SDKMACHINE=abc add task, else do nothing. Sep 24 18:01:27 Krz_: why not just have the task always added and make it do nothing unless SDKMACHINE is the desired value? Sep 24 18:01:45 you could do that entirely within the do_deploy shell function Sep 24 18:02:56 bluelightning: by using bash if inside do_deploy? or how? Sep 24 18:10:12 Krz_: yes, plus variable references... i.e. if [ "${SDKMACHINE}" = "somevalue" ] ; then Sep 24 18:10:30 bluelightning: great, didn't know it's possible Sep 24 18:11:08 Krz_: note though that the variable references will be evaluated at parse time not at the time the function is executed, which in this case isn't an issue but it is if you expect to be able to use things like ${@...} to do python magic :) Sep 24 20:01:05 ok, travel arranged for dev day and ELCE Sep 24 20:18:37 I've run across what appears to be a naming inconsistency (not sure if it's intentional or a bug) that seems to impact the name given to the ipk file for recipe's "dev" files. Sep 24 20:20:10 Yocto isn't generating the (expected) ipk name (e.g. ${BPN}-dev_${PV}_${PACKAGE_ARCH}.ipk) but rather BPN is being replaced with the base name of a shared library inside the "dev" pacakge. Sep 24 20:20:52 This seems to *only* to be done to the "dev" package. The doc/dbg, etc... ipk's are all named as expected. Sep 24 20:21:28 The package-split directory has the expected folder names. Sep 24 20:22:52 Seems that in package_ipk.bbclass in the do_package_ipk() method a lookup is done (pkgname = localdata.getVar('PKG_%s' % pkg, True)) Sep 24 20:23:55 Normally this results in the expected name - except for my "dev" package. I get the base name of a shared library that's included in the dev package. Sep 24 20:24:34 My only work around is in my recipe I have to add the following: PKG_${PN}-dev = "${PN}-dev" Sep 24 20:25:40 This seems to force the "expect" name. Is there some reason Yocto is choosing the name it's choosing (e.g. mirroring the name of a development shared library in the "dev" folder of the split)? Sep 24 20:29:53 Glenn_: that's deliberate - it's debian-style library package naming Sep 24 20:30:21 So I shouldn't try to override it then? Sep 24 20:30:48 typically you wouldn't, not on a per-recipe basis at least Sep 24 20:31:34 Okay . .. just thought it wouldn't come to mind easily when creating package groups since it's name differently from the other packages. Sep 24 20:32:13 well the names used for specifying packages within recipes are the names before the renaming Sep 24 20:33:19 So in my packagegroup I'd still use something like recipenam-dev if I wanted to "dev" files? How does it get mapped back to the debian name? Sep 24 21:08:45 Glenn_: in most of the code we only ever need to map forwards since we almost always deal with the name before renaming Sep 24 21:08:56 doh Sep 24 22:38:11 Hi Sep 24 22:38:37 I'm having some trouble finding out how to find out to which layer I have to configure certain layers in bblayer.conf Sep 24 22:38:50 let me rephrase that Sep 24 22:39:14 I git cloned meta-fsl-arm and meta-fsl-arm-extra and now I want to add it to bblayers.conf Sep 24 22:40:19 but I don't know to add which to either bsplayer, baselayer, extralayer or to bblayer Sep 24 23:28:50 fenrig: i just have the one bblayers.conf Sep 24 23:29:47 mr_sience: yeah I noticed angstrom divides them but they arent considered tehcnically different Sep 24 23:30:10 afaik there's nothing wrong with that, albeit they are all from meta-openembedded except the pi layer Sep 24 23:30:58 https://github.com/sarnold/meta-raspberrypi <= coincidentally, i just updated the readme if that helps... Sep 25 00:10:45 Hello, I've downloaded and built a Yocto image for an i.MX6 (ARM). I would like to test the image, but I don't have the board handy. Is there a way to a) emulate it with qemu or b) recompile the image, but for x86, so that it can be used in something like VirtualBox? Sep 25 00:15:00 heh b would be pointless Sep 25 00:15:27 and qemu isn't much better **** ENDING LOGGING AT Wed Sep 25 02:59:59 2013