**** BEGIN LOGGING AT Wed Nov 06 02:59:58 2013 Nov 06 07:17:14 hi all i got the following error while compiling a rootfs using yocto http://pastebin.com/dFNCE4Sk can you help me what is that issues Nov 06 07:55:14 I've created the sdk for the fsl-image-gui...everything seems to be ok but when I try to compile qt with that sysroot I get perl errors Nov 06 07:55:33 it seems many .pm files are missing from /opt/poky/1.5/sysroots/i686-pokysdk-linux/usr/lib/perl/5.14.3 Nov 06 07:55:43 for example English.pm and many others Nov 06 08:21:57 good morning Nov 06 08:22:43 mrAlmond: please pastebin your output Nov 06 08:57:36 what is the recommended way to check what went into a package? Nov 06 08:58:49 LetoThe2nd: which package manager are you using? Nov 06 08:58:55 ipk so far. Nov 06 08:59:10 you can use dpkg -c .ipk Nov 06 08:59:29 or respectively, whats the best practise for packaging a relatively trivial library? Nov 06 08:59:55 built with autoconf/automake? Nov 06 09:00:16 yeah Nov 06 09:00:28 do i actually even need Nov 06 09:00:30 FILES_${PN} = "${libdir}"? Nov 06 09:00:43 so, that should be trivial. if you add inherit autotools, it should do most of the work. Nov 06 09:00:54 or if upstream is well-behaved, shouldn't inhereit autotools alone be enough to do the trick? Nov 06 09:01:27 FILES_${PN} have sane defaults, which are set in oe-core/meta/conf/bitbake.conf Nov 06 09:01:37 ok, thanks Nov 06 09:01:58 so, for any well behaved, trivial package, you should'nt have anything to do. Nov 06 09:02:09 bitbake will warn you about files not packaged anyways Nov 06 09:02:22 yes, the defaults seem to produce the vanilla packae, as well as -dbg, -dev and -doc Nov 06 09:02:54 indeed. Nov 06 09:04:26 and dpkg -c shows kind of sane contents, so i guess this should be enough. thanks. Nov 06 09:42:32 hi all i got http://pastebin.com/dFNCE4Sk this error while compiling yocto, can you help me what is that issues? Nov 06 09:53:17 linu1: well, you're not really compiling "yocto", but rather poky + meta-ateml probably. Nov 06 09:53:24 linu1: and what does /clancor/atmel/poky/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/72xx-sdk/1.0-r3/temp/log.do_rootfs.25976 say? Nov 06 09:53:33 like told in the error message? Nov 06 09:59:50 LetoThe2nd, /clancor/atmel/poky/build-atmel/tmp/work/at91sam9x5ek-poky-linux-gnueabi/72xx-sdk/1.0-r3/temp/log.do_rootfs.25976 shows that http://pastebin.com/c7Dvhyxj Nov 06 10:00:48 LetoThe2nd, and one more thing i have added those 4 packages externally ussp-push openobex and obexd obexftp,it all compiled successfully Nov 06 10:04:07 linu1: line 188. you probably got your dependencies or something not quite right. Nov 06 10:06:47 morning all Nov 06 10:36:30 here evening Nov 06 10:36:59 linu1: http://www.total-knowledge.com/~ilya/mips/ugt.html ;) Nov 06 10:44:53 bluelightning: ++ Nov 06 13:12:07 when trying to build core-image-directfb, i hit: ERROR: Nothing PROVIDES 'core-image-directfb' Nov 06 13:12:10 ERROR: core-image-directfb was skipped: FEATURE "x11" is in DISTRO_FEATURES, Please remove "x11" from DISTRO_FEATURES, use "directfb" instead of it Nov 06 13:12:26 how can i find out what causes this? Nov 06 13:12:42 tbh, not sure why it does that. Nov 06 13:12:53 the problem is that "x11" is in your DISTRO_FEATURES Nov 06 13:13:03 and you should remove x11 and replace it with directfb instead Nov 06 13:13:14 really, those would be mutually compatible, like wayland and x11 Nov 06 13:13:46 * rburton generally surprised both that directfb exists still, and as it's clearly around still, why nobody appears to want to fix anything that uses it Nov 06 13:13:57 hrhrhr Nov 06 13:14:15 if you're using Dora you can do DISTRO_FEATURES_remove="x11" DISTRO_FEATURES_append="directfb" (in your distro or local.conf) Nov 06 13:14:15 i don't have anything specific in mind right now, i'm just tinkering around a bit. Nov 06 13:14:28 rburton: " directfb" ... Nov 06 13:14:35 might be worth filing a bug to see if we can make that requirement disappear, i don't know why Nov 06 13:14:41 rburton: I suspect that check dates from the time when that image was for gtk+-directfb Nov 06 13:14:41 no, still dylan ATM Nov 06 13:14:42 oh yes, what bluelightning said Nov 06 13:15:10 bluelightning: yeah, me too Nov 06 13:15:45 so, that does mean now... what? Nov 06 13:16:01 shall i file a bug? Nov 06 13:16:08 LetoThe2nd: please Nov 06 13:16:57 if you want to build a directfb image, you can probably just delete that test from the image recipe. if it works, the test is clearly redundant. Nov 06 13:17:03 * rburton -> food Nov 06 13:18:24 ok, will do so. Nov 06 14:40:54 HI all. Where does my kerne .config come from? Nov 06 14:41:28 I can see here that if defconfig is present, then it is copied to .config : https://github.com/openembedded/oe-core/blob/master/meta/classes/kernel.bbclass Nov 06 14:41:39 But I provide no defconfig. Nov 06 14:41:51 Does Yocto do make defconfig at some point? Nov 06 14:42:54 drasko: which machine and kernel recipe are you using? Nov 06 14:43:29 ARM, custom recipe that just fetches kernel from git Nov 06 14:44:07 drasko: its generating it with "make oldconfig" most likely then Nov 06 14:44:22 Yes, it is calling make oldconfig Nov 06 14:44:36 but is it generating .config if it does not exist? Nov 06 14:44:46 drasko: try it in a kernel tree but I suspect so Nov 06 14:45:10 let me try... Nov 06 14:49:58 RP, nope, with oldconfig as a make target I get a bunch of questions and accepting the defaults I get .config that is different then one that Yocto creates... Nov 06 14:50:10 is it possible that kernel.bbclass doing defconfig? Nov 06 14:51:16 drasko: ah, it answers y to them all ;-) Nov 06 14:51:29 drasko:  yes '' | oe_runmake oldconfig Nov 06 14:51:55 ah... Nov 06 14:53:07 heh, might be better if that used the defaults for prompted stuff, eh? Nov 06 14:54:34 It uses actually defaults Nov 06 14:54:48 RP, yes '' takes defaults Nov 06 14:54:57 i.e. presses "enter" Nov 06 14:55:33 it is different than `yes y` Nov 06 14:55:40 or `yes yes` Nov 06 14:56:09 drasko: ok, you have your answer though :) Nov 06 14:56:14 kergoth: I wonder how old that code is Nov 06 14:57:30 I'm betting as old as the class, from when we were first populating the initial metadata :) Nov 06 15:55:35 if I build an image...and then a build a single package manually will that package automatically put into that image rootfs? Nov 06 16:15:04 Working though the section 2.2.1 of the Kernel Development Manual, and the build ain't doing it what I tell it. ;-) OK so I've told it wrong. I'm building for the raspberry pi so created a new layer and reciepes-kernel/linux in there I've created a bbappend file linux-raspberrypi_3.6.11.bbappend Nov 06 16:16:01 All I do in that append is do the prepend to the search path: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}" Nov 06 16:16:47 and tell the build to pull in my default config for the kernel: KERNEL_DEFCONFIG = "defconfig" Nov 06 16:17:29 inside the linux-raspberrypi directory is my defconfig file. Simple as. Nov 06 16:18:36 but the build can't see any default kernel configuration and bombs out. Nov 06 16:23:15 Both my meta-raspberrypi and meta-mylayer have the same priority of 6 but the Developer Manual is unclear stating that "The BBFILE_PRIORITY variable then assigns a priority to the layer. Applying priorities is useful in situations where the same package might appear in multiple layers and allows you to choose what layer should take precedence." Nov 06 16:23:32 are you using linux-yocto? if not, afaik KERNEL_DEFCONFIG isn't a standard mechanism Nov 06 16:24:14 kergoth: Nope Raspberry has it's own kernel recipe. Nov 06 16:24:52 it's recipe has the line:KERNEL_DEFCONFIG = "bcmrpi_defconfig" Nov 06 16:25:21 I was hoping that my bbappend would trump that. Nov 06 16:27:08 What I was about to say was unclear from the manual is whether 6 is of higher priority then 5 or vice versa. Maybe there's consensus but I'm never sure. Just saying that the field assigns the priority of the layer is close but... Nov 06 16:29:45 if its using a .bb, and you have a .bbappend, then priority is irrelevent, since appends are always appended ot a recipe Nov 06 16:29:52 if its using bbappend, then yes, its a factor Nov 06 16:29:59 higher number == higher priority Nov 06 16:32:05 I'm using a bbappend it's just using a bb Nov 06 16:34:09 then priority is irrelevent, because bbappends, by definition, are appended to the end of a recipe Nov 06 16:34:26 use bitbake -e to examine the metadata an dmake sure variables are set to what you think they are Nov 06 16:35:36 kergoth: thanks a million I'll try that out. I'm running a -c clean on it presently thinking it's good to be starting from a clean slate. Nov 06 16:36:37 couldn't hurt, certainly Nov 06 16:36:38 np Nov 06 16:37:06 bitbake -e is really helpful to check assumptions and see what's really happening. with recent bitbake, it also shows where the values got defined, in what files, in what order Nov 06 16:37:16 so you'll be able to see that it was set to this in the .bb, and then change dot that in the bbappend Nov 06 16:46:42 wow bitbake -e is a Swiss army knife! Nov 06 16:46:55 it's giving me the line from my bbappend: KERNEL_DEFCONFIG="defconfig" Nov 06 16:47:45 so that's correct but the error message I'm getting is: Nov 06 16:47:47 build/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.6.11+git63b69a8806ce1890711ff55280c90673ea415933-r7/git/arch/arm/configs/defconfig Nov 06 16:48:21 now i'd examine do_configure in bitbake -e, or hte recipe itself, so you can see exactly what it's doing. clearly it's not just using KERNEL_DEFCONFIG Nov 06 16:51:39 I was just looking at that and scratching my head ;-) seems that even though the original linux-raspberrypi recipe uses the variable it's not actually used. the do_configure has got: Nov 06 16:51:41 do_configure() { Nov 06 16:51:41 install -m 0644 /home/john/raspberrypi/poky/build/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.6.11+git63b69a8806ce1890711ff55280c90673ea415933-r7/git/arch/arm/configs/defconfig /home/john/raspberrypi/poky/build/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.6.11+git63b69a8806ce1890711ff55280c90673ea415933-r7/defconfig || die "No default configuration for raspberrypi / defconfig available." Nov 06 17:03:06 so I removed my append file and cleaned up and rebuilt: The above install line seems to be correct as in the straight version give the same basic output but is looking for the file bcmrpi_defconfig after it's recipe declared KERNEL_DEFCONFIG = "bcmrpi_defconfig" Nov 06 17:03:46 I'll do some more investigation in bitbake -e Nov 06 19:11:14 rburton: the directfb build succeeded after i removed the check Nov 06 19:11:36 i'm not sure how to check directfb functionality inside qemu, though Nov 06 21:14:07 zeddii, ping. My email is hosed (not receiving new mail it seems). I removed the eg20t feature entirely, still happens. Nov 06 21:24:17 halstead, ping - any known issues with mail delivery from the linux-yocto or other yp lists? Nov 06 21:24:46 dvhart, I haven't noticed any. I'll look at the logs now. Nov 06 21:25:14 thanks - I never received zedd's response to my 3.10.10 thread on linux-yocto Nov 06 21:28:42 halfhalo, looks like it might be PEBKAC Nov 06 21:28:46 halstead ^ Nov 06 21:29:31 The logs look normal. Nov 06 21:30:47 dvhart, It's still good to check on things now and then. So everything is fine on my end then? Nov 06 21:30:49 found it, for some reason I was not receiving duplicates (so only got the response in my Inbox, not to the list folder) and my merged inbox search was broken.... sigh Nov 06 21:30:56 bad combination of circumstances Nov 06 21:31:18 halstead, yup, yp infrastructure appears to be running beautifully as usual :-) Nov 06 21:31:21 sorry for the noise Nov 06 21:31:59 dvhart, No problem at all! Nov 06 21:32:13 Oh and the archives are at https://lists.yoctoproject.org/pipermail/linux-yocto/2013-November/date.html if you want to see if the server received the mail. Nov 06 21:33:05 yup, checked those, that's how I knew I was missing something :-) Nov 06 21:35:35 so, apparently IT just bought a bunch of firewall appliances and we just a major disruption in the software team because said vendor told IT it was okay to do X on a production network Nov 06 21:36:07 killed all my builds due to the git recipes we pull from the outside... Nov 06 21:36:46 *I* would cross that vendor off my list and send everything back, but somehow i don't think IT will do that Nov 06 21:37:14 pretty damn poor engineering support tho Nov 06 21:38:52 ugh Nov 06 21:38:57 heh, you'd think IT would have checked with engineering to see just what they need connectivity to, before buying them, regardless of what the vendor said Nov 06 21:39:21 yeah, i had that same thought Nov 06 21:39:40 nobody talked to me first, they just trusted the vendor... Nov 06 21:41:25 * kergoth rolls eyes Nov 06 23:29:40 * kergoth wonders why systemd.bbclass is limited to supporting a single service file Nov 06 23:29:44 (per package) Nov 06 23:58:13 The thing I hate about how we're doing read-only-rootfs is the boot time hit due to copying the /var/lib contents Nov 06 23:58:16 hrm Nov 07 00:00:15 kergoth: is that your own custom image doing that? Nov 07 00:01:13 * mr_science not so happy with his own custom image/backported ro-rootfs support Nov 07 00:02:09 mr_science: No, it's the default behavior of sysvinit in oe-core, see https://github.com/openembedded/oe-core/blob/master/meta/recipes-core/initscripts/initscripts-1.0/read-only-rootfs-hook.sh#L31-L36 Nov 07 00:02:20 well, technically I'm using a different solution for systemd, but it's the same concept Nov 07 00:03:04 https://github.com/kergoth/meta-ro-rootfs/blob/revamp-binds/recipes-core/volatile-binds/volatile-binds.bb - generates a service file for each copy + bind mount Nov 07 00:03:36 https://github.com/kergoth/meta-ro-rootfs/blob/revamp-binds/recipes-core/volatile-binds/files/volatile-binds.service.in Nov 07 00:03:39 heh Nov 07 00:03:41 work-in-progress Nov 07 00:07:46 haven't really played with it in oe-core yet Nov 07 00:08:10 just stole some of the patches for our arago classic... Nov 07 00:08:54 sounds like i should make an rpi image with ro-rootfs Nov 07 00:37:11 whats the difference between meta-toolchain and meta-toolchain-sdk? Nov 07 00:54:03 meta-toolchain-sdk is pretty small, so it has pretty minimal set of headers/libs Nov 07 00:54:49 if you want an SDK based on a particular image build, then use the do_populate_sdk thing Nov 07 00:55:00 so if i want to do some kernel development for my platform, should i use meta-toolchain or meta-toolchain-sdk Nov 07 00:55:40 meta-toolchain-sdk, but only if it has kernel headers Nov 07 00:56:11 you can try bitbake -c do_populate_sdk Nov 07 00:56:36 that made a 900 MB tarball for my rpi image Nov 07 00:56:44 whats diff between that and meta-toolchain-sdk? Nov 07 00:57:13 AFAICT meta-toolchain-sdk doesn't care about any particular image Nov 07 00:57:23 oh Nov 07 00:57:40 so it's essentially just the toolchain and some small set of system libs/headers Nov 07 00:57:58 i've built it but not really played with it yet Nov 07 00:58:16 ok, ill try both and see what i get Nov 07 00:58:17 you can download one that i built and unpack it... Nov 07 00:58:29 if you just want to see what;s in it Nov 07 00:58:33 sure Nov 07 00:59:17 http://www.gentoogeek.org/files/poky-eglibc-x86_64-arm-toolchain-gmae-1.4+snapshot-20130806.sh Nov 07 01:00:12 cheers **** ENDING LOGGING AT Thu Nov 07 02:59:58 2013