**** BEGIN LOGGING AT Mon Dec 21 02:59:59 2015 Dec 21 09:04:49 Hi, how to get more logs our of "satisfy_dependencies_for: Cannot satisfy the following dependencies for foobar"? Can't see why certain packages can not be installed.. Dec 21 11:46:41 hi all Dec 21 11:47:19 someone with issues building beecrypt-4.2.1 ? Dec 21 11:57:37 joshuagl: bad news: debian 7's dd doesn't support sparse Dec 21 12:02:04 rburton: ugh Dec 21 12:02:09 * joshuagl shakes fist at Debian! Dec 21 12:04:33 yeah Dec 21 12:04:56 its oldstable now so there's a rationale for removing it from the supported list, like we're doing with centos 6 Dec 21 12:05:04 but debian 8 is fairly fresh still Dec 21 12:06:41 what I'm hearing is we can't backport my sparse changes to Jethro but they're good for Jethro + 1 ? ☺ Dec 21 12:07:21 yes Dec 21 12:07:48 (assuming we can drop debian7 from the supported list) Dec 21 12:27:53 Hi, anyidea how to get more details out of satisfy_dependencies_for task? One package group is refusing to install and I can't see any details. Dec 21 15:01:19 * kergoth yawns Dec 21 15:06:02 * paulg_ passes kergoth the coffee Dec 21 15:06:15 thanks, much needed this morning Dec 21 15:06:30 will probably be a quiet week with a lot of ppl doing the extended holidays. Dec 21 15:06:30 think i got woken up in the middle of a sleep cycle Dec 21 15:06:32 hate those days Dec 21 15:10:33 anybody know why I can't set permissions to 000 within a BitBake task? Dec 21 15:50:15 karobar: i think pseudo enforces user-read to ensure ownerships isn't crazy. what purpose does 000 serve that root owned 0600 doesn't already help with? Dec 21 15:54:20 rburton: I just wanted to understand the underlying reason and how to change it. i wasn't being practical Dec 21 15:54:54 well, i know pseudo has a "take the requested ownership, ensure it's somewhat sane" logic Dec 21 15:54:57 so maybe you're hitting that Dec 21 15:55:18 where is that configured? Dec 21 15:56:19 that's where the ownerships of packages is maintained Dec 21 15:56:24 as you don't actually do a build as root Dec 21 15:59:59 rburton: hmm, sorry, I'm still not sure what file I should change. I understand that bitbake uses pseudo user during the build process. Dec 21 16:02:41 yes Dec 21 16:02:59 i'm not telling you how to fix it, i'm telling you what is likely stopping you have mode 0000 Dec 21 16:03:07 is there a good reason you want mode 000? Dec 21 16:07:49 I'm only interested in understand the process by which bitbake changes it. Thanks for the help, I'll look into sanity checking stuff Dec 21 16:08:26 its pseudo that does the mode changing Dec 21 16:33:04 There's some problem if you enable the pulseaudio and alsa into DISTRO_FEATURES? Dec 21 17:46:57 In upgrading from Fido->Jethro, it looks like one of my .bbclass files in my custom layer's 'classes/' isn't being pulled in -- any tips wrt which logs might be most useful? Dec 21 17:47:26 I'm not entirely sure when the .bbclass files get loaded Dec 21 17:55:19 Ah... maybe I'm missing an IMAGE_CLASSES definition, as it's a class to define IMAGE_CMD_myimage Dec 21 23:56:03 * paulg tries to make arch specific appends like this work: RDEPENDS_somepkglist_append_x86-64 = " grub" Dec 21 23:56:19 i.e. avoid grub for arm, ppc etc. Dec 21 23:57:52 based on these lines in core, it should work.... Dec 21 23:57:57 meta/recipes-core/packagegroups/packagegroup-base.bb:RDEPENDS_packagegroup-base-zeroconf_append_libc-glibc = "\ Dec 21 23:57:57 meta/recipes-core/packagegroups/packagegroup-self-hosted.bb:RDEPENDS_packagegroup-self-hosted-sdk_append_libc-glibc = "\ Dec 22 00:00:00 it's not 'somepkglist', it's the package name Dec 22 00:00:09 i.e. '${PN}' Dec 22 00:00:29 well, in this case it is a hand crafted pkglist I've created. Dec 22 00:00:54 aking to packagegroup_base above etc. Dec 22 00:01:36 i.e. sth like this is what I'm trying to append grub to: Dec 22 00:01:44 RDEPENDS_packagegroup-builder-extended = "\ Dec 22 00:01:44 bash-completion \ Dec 22 00:01:44 bzip2 \ Dec 22 00:01:46 [...] Dec 22 00:01:56 and then I add: Dec 22 00:02:20 RDEPENDS_packagegroup-builder-extended_append_x86 = " grub" Dec 22 00:02:20 RDEPENDS_packagegroup-builder-extended_append_x86-64 = " grub" Dec 22 00:03:05 seems sane at 1st glance but when I added the two lines, it didn't rebundle my rootfs with grub in it for x86-64. Dec 22 00:03:35 did you actually examine the value of RDEPENDS_packagegroup-builder-extended with bitbake -e ? Dec 22 00:05:37 I tried that but oddly it doesn't appear _at_all_ Dec 22 00:05:47 figured it just wasn't exported or similar... Dec 22 00:06:02 bitbake -e doesn't only show exported variables Dec 22 00:06:12 it won't show *unexported* vars, but it shows other vars exported or not Dec 22 00:08:24 Seems I only get to snoop a couple internal yocto pkglist vars.... Dec 22 00:08:45 $ bitbake -e cube-builder |grep RDEPENDS_packagegroup Dec 22 00:08:46 # $RDEPENDS_packagegroup-core-boot [2 operations] Dec 22 00:08:46 # $RDEPENDS_packagegroup-core-full-cmdline-sys-services Dec 22 00:09:16 sounds like you've got other problems, then, if your changes aren't taking effect at all Dec 22 00:09:23 i.e. that bbappend is in the wrong location so isn't parsed Dec 22 00:10:16 could be ; it is right underneath the main definition, so that seems sane Dec 22 00:10:38 I'll strip the _x86-64 suffix and see if just a bare _append works, as an intermediary test. Dec 22 00:10:50 maybe I've got the arch var wrong. Dec 22 00:10:55 if the main definition isn't showing up in bitbake -e, something is seriously broken, override or not Dec 22 00:11:01 if so, I'll blame fray_ :) Dec 22 00:13:26 ooh. that seems to have triggered a re-do of the do_rootfs step. Dec 22 00:13:59 (unfortunately that takes ages) Dec 22 00:17:43 ok, grub is now bundled in, so I've got the arch var wrong. (independent of wtf is happening with "bitbake -e") Dec 22 01:03:05 Hi, when building the kernel from meta/recipes-kernel/linux, how does yocto know whether it has to provide a 32 bit configuration or a 64 bit one? [I tried setting the $MACHINE variable in the local.conf to x86_64, but when I build my custom kernel with no defconfig file provided, it by default takes the 32 bit config] Dec 22 01:14:02 megha_dey, I'm using the bleeding edge yocto-dev kernel, and I use this to piggy back off the existing sane config... Dec 22 01:14:17 MACHINE ?= "genericx86-64" Dec 22 01:14:17 # linux-yocto-dev won't get a sensible .config w/o the below Dec 22 01:14:17 KMACHINE_genericx86-64 ?= "common-pc-64" Dec 22 01:14:30 that is in my local.conf of course. Dec 22 01:26:36 paulg: thanks Dec 22 01:27:20 however i use MACHINE to be qemux86_64, I get the error: [ERROR] No configuration fragments found, this typically is a misconfigured BSP. Dec 22 01:27:20 | Check that fragments (or defconfigs) are referenced by the board description. Dec 22 01:27:21 | config of "standard/qemux86-64" failed Dec 22 01:35:19 odd Dec 22 01:35:34 qmeu 64 is standard boilerplate bsp in tree. Dec 22 01:36:20 i.e. you shouldn't need to do any extra magic when selecting that as your MACHINE. Dec 22 01:43:47 * paulg still cant figure out why BLAH_append works but BLAH_append_${TRANSLATED_TARGET_ARCH} doesn't Dec 22 01:44:03 with the expanded version of TTA of course. Dec 22 01:44:20 double check that OVERRIDES has the expected value? Dec 22 01:44:24 in this case it is "x86-64" as seen expanded in OVERRIDES. Dec 22 01:44:27 :) Dec 22 01:44:38 could be there's a bug in the new overrides application at expansion-time rather than end-of-parse Dec 22 01:44:52 but i'd expect it to have come up before now Dec 22 01:44:55 still, thats a possibility Dec 22 01:45:02 yeah, I can't be the only sap trying to do this. Dec 22 01:45:19 will have to head out soon ; will investigate more tomorrow. Dec 22 01:45:23 kergoth, thanks for the input. Dec 22 01:45:44 np. not sure how you'd verify it though, short of trying to revert those changes Dec 22 01:46:15 would be funny if the same time I was trying to do arch specific stuff was coincident with unrelated breakage. Dec 22 01:46:24 at least then I wouldn't feel so stoopid. Dec 22 01:46:46 just for the hell of it, could try just using teh override without append Dec 22 01:47:07 interesting ; might try that when I get home in ~1/2hr Dec 22 01:47:53 * paulg waves Dec 22 02:22:57 Hi all, I’m trying to write a yocto recipe for VTK but I’m having trouble doing so. I’ve found this layer https://github.com/mferland/meta-vtk but it’s an old version of VTK and many things changed. Does anybody has been successfull at cross-compiling VTK or writting a recipe? Note that my yocto target is an x86_64 Intel NUC so the cross-compilation is simply x86_64 -> x86_64… Thanks! Dec 22 02:47:31 * armpit sigh.. 5 accidents between here and home Dec 22 02:49:37 * armpit Cal can't handle rain **** ENDING LOGGING AT Tue Dec 22 02:59:58 2015