**** BEGIN LOGGING AT Tue Mar 15 02:59:58 2016 Mar 15 07:26:54 good morning Mar 15 08:31:21 Hi all. Mar 15 08:31:52 Anticom: hello Mar 15 08:32:24 Can i have (and is it sensible) to have DEPENDS in an image recipe? do_rootfs is failing due to missing dosfstools-native and mtools-native. Of course this can be easily fixed by baking it manually but when i think towards CI long term this will get nasty Mar 15 08:45:20 Anticom: you would do that by do_rootfs[depends] += "dosfstools-native:do_populate_sysroot mtools-native:do_populate_sysroot" Mar 15 08:45:43 how are you hitting a situation where you need those and the dependencies aren't added automatically? Mar 15 08:49:07 rough guess, missing deps on an image built with wic Mar 15 08:51:47 bluelightning: yes, they aren't Mar 15 08:54:07 So for future-proofing is there a way to _append it to do_rootfs w/o using += when it might get added some time in the future? Mar 15 08:54:23 or doesn't that matter? Mar 15 08:54:57 just wondering, but you would not usually require dosfstools or mtool for rootfs, sounds more like a depedency for do_image Mar 15 08:59:25 mborzecki: well bitbake reports "Error: The image creation script '<...>/my-img/temp/create_image.wic' returned 1" and in 3rd line from bottom it says "Error: Function failed: do_rootfs" Mar 15 09:00:01 so is it rather do_image[depends] += "..." ? Mar 15 09:04:52 Anticom: can you post a complete log? Mar 15 09:05:44 mborzecki: you mean the log where it says "Logfile of failure stored in .../log.do_rootfs.xxxx" ? Mar 15 09:05:50 or the stdout of bitbake? Mar 15 09:05:59 stdout of bitbake Mar 15 09:09:31 mborzecki: https://gist.github.com/Anticom/0e8fb6a663972a09e66c Mar 15 09:10:15 for mtools-native `sed 's/dosfstools/mtools/' Mar 15 09:10:45 try putting this in your local.conf: IMAGE_DEPENDS_wic_append = " mtools-native dosfstools-native e2fsprogs-native" Mar 15 09:11:11 mborzecki: i was looking for a solution i could share in the repo Mar 15 09:12:22 well, idealy this should be in the same place where IMAGE_FSTYPES is set Mar 15 09:18:05 mborzecki: i only got wic set in IMAGE_FSTYPES Mar 15 09:19:07 Anticom: that's why you get this problem, you're apparently building an image for sdcard, where at least one partition is a FAT partition Mar 15 09:19:30 wic needs dosfstools for mkfs.vfat and mtools for mcopy Mar 15 09:19:41 mborzecki: okay so simply appending fat (case sensitive?) to my IMAGE_FSTYPES should fix the issue? Mar 15 09:20:29 nope, IMAGE_FSTYPES a is different thing Mar 15 09:21:03 what you need to do is tell that the 'wic' image type requires dosfstools-native and mtools-native, that's what IMAGE_DEPENDS_wic.. line does Mar 15 09:21:04 Okay so the IMAGE_DEPENDS_wic_append is the way to go? Mar 15 09:21:39 what is the difference to do_image[depends] += "..." ? Or is it just a matter of personal preferences? Mar 15 09:22:12 i suppose do_image[depends] doesn't care, whether i'm building an image using wic or not (?) Mar 15 09:22:38 do_image[depends] sets task dependencies, so before do_image is run the depdnencies must be finished Mar 15 09:22:52 and yes, it does not care if you're building a wic image or not Mar 15 09:23:02 so your solution is the prefered one? Mar 15 09:24:36 yes, the same thing is done in image_types.bbclass for other images Mar 15 09:24:58 mborzecki: one last question: what's the e2fsprogs-native good for? Mar 15 09:25:07 bitbake wasn't complaining about it but you where suggesting it Mar 15 09:25:10 it's just wic only finds out what tools will be needed once the *.wks file is parsed Mar 15 09:26:18 Anticom: long shot but your image may likely contains an ext[234] partition, if it does not you can skip e2fsprogs Mar 15 09:27:45 fdisk -l just says "Linux" to the other patitions. afaik it is ext4 Mar 15 09:28:00 however bitbake didn't complain about that one missing Mar 15 09:29:02 perhaps it's already there through some other dependency Mar 15 09:29:08 you can ping edbart for additional insight on how wic builds images, iirc he's the current maintainer, i've merely contributed a couple of fixes and bootimg-parition plugin :) Mar 15 09:30:01 Okay thanks mborzecki and also bluelightning Mar 15 10:01:15 PC back up. Mar 15 10:41:01 hi guys, I'm trying to achieve the fastest boot time on an embedded board (yocto jethro), my init system is systemd and I read somewhere (general fast boot slides) that is possibile to pre-configure or eliminate udev Mar 15 10:41:24 some of you have never performed a similar operation? Mar 15 10:57:26 zero_note: iron out the usual suspects prior to such extreme measures :-) Mar 15 10:57:56 zero_note: find a good lot of inspiration here: https://www.youtube.com/watch?v=KTRA1PRJWH8 Mar 15 10:59:22 LetoThe2nd, thank you :-) Mar 15 11:06:38 rburton: hello Mar 15 11:07:25 rburton: please apply the fix you prefer in jethro, the libsdl-native is breaking framebuffer distros completely. I think we ought to continue the discussion but this is a master topic than Mar 15 12:46:19 Where would i typically configure my repository channels? Mar 15 13:15:46 Anticom: in a recipe you ship (or use PACKAGE_FEED_URIS in your distro config) Mar 15 16:08:03 hi folks, on the same build machine (ubuntu 14.04.4, gcc 4.8.4) I've cloned 2 git repos: one for my yocto project and the latter is the u-boot repo, so I bitbake the sdk, install it and source it, but I can't compile u-boot due to an error related to a missing tool Mar 15 16:08:18 arm-poky-linux-gnueabi-ld: cannot find -lgcc Mar 15 16:12:47 but I can't understand why the same u-boot source code compile with no problems using yocto recipes, while when I try to compile "manually" u-boot I get this error Mar 15 16:15:36 anyone have any clue about this? thanks in advance Mar 15 17:56:01 Anyone else running into illegal instruction building intel-corei7-64 from the qemu user mode bits? Seems the -cpu Nehalem,check=false isn't cutting it for this machine Mar 15 17:56:21 hitting gobject-introspection failures as a result, along with the expected postinst failures Mar 15 18:00:03 rburton: ever hit this one? i saw it was your patch that added the qemu options Mar 15 18:02:13 hi guys Mar 15 18:07:29 is there any way to avoid the "conflicts between attempted install of" error msg while do_rootfs? i have two packages that provides the same library. I'd like to have a preferred one. I took a look at the update-alternative class but i'm not sure if it is the proper way to do it Mar 15 18:10:25 lazao: either use update-alternatives to avoid the conflict, use runtime provides to avoid them both being pulled into the same image in the first place, or configure rreplaces (probably with rconflicts and rprovides) to let one replace the other entirely (only valid if there's a clear case of one superceding the other) Mar 15 18:10:42 Hmm, think I might split out parts of bitbake-layers into a module in lib/bb/ Mar 15 18:13:38 is it possible to have a rreplaces only for one specific lib in the package? actually there are several libraries provided by this pkg. Mar 15 18:14:39 and i don't want the entire package to be replaced by the other one but i just want to replace a specific library provided by both packages. Mar 15 18:15:32 you'd likely have to break it up into multiple packages to handle that Mar 15 18:15:54 though rreplaces without rconflicts might let one overwrite the other without *uninstalling* the other, i'm not certain as to the behavior of the package managers in that case Mar 15 18:16:15 roughly familiar with the debian policy manual, whicha pplies to opkg and dpkg, but even there i'm unsure, and i have no idea how rpm handles it :) Mar 15 18:22:22 Hmm, we do logger setup in way too many places right now Mar 15 18:24:23 I wonder if my qemu issues are due to running in a VM, maybe it doesn't support all the features needed to emulate nehalem Mar 15 18:36:03 kergoth: VM on VM ? Mar 15 18:36:19 it works for me in most of cases Mar 15 18:36:31 but have seen some vconsole related problem Mar 15 18:36:39 which dont happen otherwise Mar 15 20:05:34 kergoth: that's interesting! g-i works here with that machine. can you pastebin the full log, and bonus points if you can get the core dump from qemu (which does magic to give you the emulated binary's dump) Mar 15 20:07:46 kergoth: (building again to verify…) Mar 15 20:20:36 interesting, i'm guessing it's something to do with running in a vmware vm, but other machines run qemu fine. guess i should try running manually with check and see what it says Mar 15 20:23:10 ah, in a vm Mar 15 20:23:17 that might make an interesting differnce Mar 15 20:23:37 well just verified that intel-corei7-64 builds gtk+3 and python-pygobject here Mar 15 20:23:48 (not that modern xeon host) Mar 15 20:23:57 k, thanks Mar 15 20:24:21 not that you made me panic for a bit Mar 15 20:24:22 i'll see about opening a bug in the bts in case it's something that needs addressing, or at least documenting Mar 15 20:24:25 no siree Mar 15 20:24:28 hehe Mar 15 20:24:34 yeah bug please Mar 15 20:24:39 and bonus points for as much log as possible Mar 15 20:24:55 * kergoth nods Mar 15 20:24:59 but a more pressing issue is where the bloody hell did i put that beer Mar 15 20:34:21 If any gluttons for punishment are around, could use another set of eyes on https://github.com/MentorEmbedded/poky/compare/master...kergoth:shallow-simplify. the commit message on the third commit documents the variables and usage Mar 15 20:37:36 I keep wanting to make it cleaner, but i'm honestly out of ideas. I don't like that it's so much special cased logic, but I can't see a way around it. I'd like the fetch core to better handle the mirror tarballs in a generic way, with a new method for the preparation of the tarball, but git shallow would still need special casing due to the fact that shallow tarballs are unpacked directly, without using clonedir at all Mar 15 20:42:44 khem: do you have any opinion on #9201? Mar 15 21:04:31 do we have a POKYDIR variable or something like that?, I know we've got TOPDIR, but I want the one where poky resides Mar 15 21:06:35 see COREBASE Mar 15 21:15:48 kergoth: thanks! Mar 15 21:18:16 np Mar 15 21:18:24 kergoth: by any chance do you know how to get the location of a recipe given a PN?, I saw something but it requires a reference to the cooker Mar 15 21:18:36 in what context? Mar 15 21:18:59 and I already have a bitbake instance running, idk how to get a reference to its cooker Mar 15 21:19:00 from python in a standalone script, cooker is the way to do it, via tinfoil. from the metadata, just use the FILE variable Mar 15 21:19:16 yeah it ownt let me call tinfoil Mar 15 21:19:23 "won't let me call"? Mar 15 21:19:43 it complains about the instance of bitbake thats already runnig Mar 15 21:20:02 I can try with FILE Mar 15 21:20:16 to run both a standalone script and a build at the same time, regardless of what script is in use, you'd have to use the memory resident bitbake server Mar 15 21:20:19 then both would interact with that Mar 15 21:20:23 afaik anyway Mar 15 21:20:36 kergoth: oh alright, thanks! Mar 15 21:20:42 aehs29: what are you attempting to do, out of interest? Mar 15 21:22:49 bluelightning: basically I run -c testimage, which runs a test, and I need to get the output via ssh, and ideally put it on the recipe's foder to use it via SRC_URI Mar 15 21:23:29 bluelightning: I could just ut it somewhere else and use FILESEXTRAPATHS, but its dirtier Mar 15 21:24:13 using the output of the test as input to the recipe? that sounds a bit unusual... Mar 16 00:06:16 Can I use yocto recipes to build application software for my desktop linux distro, in addition to my embedded distro? **** ENDING LOGGING AT Wed Mar 16 02:59:58 2016