**** BEGIN LOGGING AT Mon Jan 21 02:59:58 2013 Jan 21 08:21:20 guys, how do I put uclibc for danny in a mirror? after a build I only have u[cC]*.done files in my downloads dir Jan 21 08:24:37 are you building uclibc from git without BB_GENERATE_MIRROR_TARBALLS ? Jan 21 08:27:45 JaMa|Off: not that I am aware of, (and I do get the u-boot tarball) Jan 21 08:29:07 JaMa|Off: I did not set or reset it, will try to set it Jan 21 08:34:07 JaMa|Off: not too much success yet, set in in my distro.inc to 1, did a cleanall of uclibc and a rebuild but still no luck Jan 21 08:34:15 but got this Jan 21 08:34:16 -rw-r--r-- 1 frans frans 0 2013-01-21 09:28 uclibc.org.uClibc.git.done Jan 21 08:36:10 trying to buld 0.9.33 r8 Jan 21 08:37:21 puzzled Jan 21 08:41:06 do_fetch log has cmd to create tarball Jan 21 08:46:53 JaMa|Off: I have to eat my words with the flag in the distro it does seem to work :-) made mistake :-( thanks for your help! Jan 21 09:11:13 good morning Jan 21 09:27:46 what does " PV = "1.0+gitr${SRCPV}"" mean Jan 21 09:28:43 hello all Jan 21 09:34:11 I have a question on package naming on yocto : why build paths use dash in the arch prefix (ex: armv7a-vfp-neon in tmp-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/) and the package names uses underscore (ex : armv7a_vfp_neon in alsa-oss-dev-1.0.17-r1.armv7a_vfp_neon.rpm) Jan 21 09:48:47 anyone know PV = "1.0+gitr${SRCPV}" mean? it seems not the the package's git version is tag 1.0, it seems, the PV 's git version which is newer than 1.0. right ? Jan 21 09:55:54 morning all Jan 21 09:57:08 hello Jan 21 10:15:52 lyang0: Its creating a version string of "1.0" and then adding in a git revision string Jan 21 10:16:11 yes Jan 21 10:16:26 it seems not the the package's git version is tag 1.0, it seems, the PV 's git version which is newer than 1.0. right ? Jan 21 10:18:03 I have a packages which the latest tag is 1.0. and hasn't update for past two years with new tag, the master is very new, can I use PV = "1.0+gitr${SRCPV}" for this Jan 21 10:18:07 RP Jan 21 10:19:04 lyang0: The 1.0 has nothing to do with the git version, its really just a way of saying its later than that Jan 21 10:19:17 ha Jan 21 10:19:20 lyang0: so yes, you can use that Jan 21 10:19:31 That's pretty good Jan 21 10:19:34 thanks Jan 21 10:42:19 Hi! I would like to build the "Yocto Build Appliance" on my own. I've noticed that there is an image recipe "build-appliance-image" to do this. Do I need any aditinal layers? What machine should I select? Jan 21 11:18:32 Joe____: you need to set qemux86-64 in local.conf and then "bitbake build-appliance-image" Jan 21 11:54:58 anyone knows if it's possible to provides only the libs part of a package, and get the headers from another package? In particular I want to install libs from gpu-viv-bin-mx6q but the headers from mesa Jan 21 11:55:27 (installing headers from vivante makes quite a few packages fail to build) Jan 21 11:57:28 markos_: that sounds like it's doomed to fail :) Jan 21 11:57:43 if something builds against mesa headers, it may well be expecting mesa functions to exist Jan 21 11:58:01 blame vivante for redefining many GL defines and ommitting pretty much all mesa ones Jan 21 11:58:12 but do they even support them? Jan 21 11:58:23 maybe they don't define them as they don't support them... Jan 21 12:01:19 markos_: the answer is no, btw. you'd have to write custom staging functions to only write the bits you want. Jan 21 12:01:33 markos_: moan to img, or patch the headers, or don't build stuff that needs mesa when you don't have mesa. Jan 21 12:02:02 if an app *needs* mesa then well, it needs mesa. if it doesn't then it should check at runtime if its going to optionally use mesa extensions. Jan 21 12:03:11 rburton, I've done this thing in Debian actually and was hoping if I could do the same in yocto, apparently I have to find some other solution :/ Jan 21 12:03:37 you *can* but i doubt you'll get the patches into oe-core :) Jan 21 12:04:02 really sounds like you're discovering buggy apps, or just problems you'll have to deal with if you run !mesa. Jan 21 12:04:26 ie mesa-demos assumes it's running against mesa. there's a bug open to conditionalise the mesa-specific extension use. Jan 21 12:04:34 but, to be fair, it is called mesa-demos :) Jan 21 12:05:03 well, I did the trick you told me, set PACKAGECONFIG_pn-xserver-xorg = "udev" so xserver-xorg didn't use glx, so it didn't try to build with vivante Gl headers Jan 21 12:05:45 but then vivante_fbdev didn't find dri.h, then I added a dependency to vivante dri package, but that one depended on vivante xorg driver (cyclic dependency) :) Jan 21 12:06:05 fun Jan 21 12:06:19 I don't blame yocto, it's actually FSL's fault Jan 21 12:06:28 or vivante Jan 21 12:07:06 yeah sounds like you need to harass FSL Jan 21 12:07:13 I've had too much frustration on both amd and vivante drivers the past years :) Jan 21 12:07:25 on both imx5 and imx6 :) Jan 21 12:07:49 * rburton endorses genx Jan 21 12:08:02 maybe this year we'll have genx on atom! Jan 21 12:08:06 :) Jan 21 12:08:43 little known fact: "binary gpu drivers" is an anagram of "ARRRRRRRRRRGGGGGGGHHHHHHHHHHH" Jan 21 12:09:25 yup Jan 21 13:23:45 Hello :-) Jan 21 13:27:08 I have some problem using Yocto/Poky: In successfully created a .jffs2 image but there are all /etc/init.d/* files missing. They all exist in the .tar archive which has been created in parallel. Is this some known issue? Jan 21 13:59:15 <_Lucretia_> is there a variable for the current sysroot dir? I want to get hold of the installed /usr/lib dir there Jan 21 14:54:08 _Lucretia_: I think it might be ${D} Jan 21 14:56:11 _Lucretia_: see bitbake.conf Jan 21 14:56:34 ie STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}" Jan 21 14:58:27 unsinn: not a known issue. Sounds like jffs2 ran out of space or something. Sounds related to the flash tools if the tarball is fine though Jan 21 15:21:23 <_Lucretia_> thanks Jan 21 15:22:08 <_Lucretia_> it's just we need access to those dirs from another recipe as i've set up the ada libs into /usr/lib/ada//ada[lib|include] Jan 21 15:22:31 <_Lucretia_> and to get it working quickly...just gonna hard code it for now, and sort it out properly later Jan 21 15:33:42 walters: " ok so the power plugin makefile runs some source headers through glib-mkenums which generates two .[ch] files, which are then used to compile a native binary gsd-power-enums-update, which then in turn is used to generate a python file" <-- so glad that's not in yocto Jan 21 15:40:19 rburton, yeah, it's silly...there's also a separate perl script which generates a different python file here too Jan 21 15:40:26 hahaha Jan 21 15:40:30 of course perl! Jan 21 15:40:38 clearly you need some lua to glue it all together Jan 21 15:40:46 glib-mkenums is also perl, so we already had perl generating python before too Jan 21 15:41:42 probably the main irritant of this form is having to pull in ruby just to build webkitgtk Jan 21 15:42:13 yes, that was an annoying piece of news. Jan 21 15:47:14 hello everyone! Jan 21 15:54:15 hey Jan 21 15:54:40 how can i see the list of extra_packages like tools-sdk can i Jan 21 15:54:53 how can i see the list of extra_packages that i can add to my image? Jan 21 16:02:39 Good question Jan 21 16:09:31 hi. the docs say FULL_OPTIMIZATION defaults to "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2", but in meta/conf/bitbake.conf this is defined as FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}". was this changed for some reason? Jan 21 16:23:47 i see, these are implied by -O2. i was looking for a good place to set a specific CPU type in a custom machine conf - where and how could this be done best? Jan 21 16:24:10 rburton: when i add x11-base to my image and try to bitbake i got 7 tasks failed.... is there some package in special needed to compile x server through yocto? Jan 21 16:25:42 schramae: see conf/machine/include/ and the machines that include them for examples. see also DEFAULTTUNE Jan 21 16:32:07 kergoth: thanks, i already checked this, but it only contains basic stuff. but TUNE_FEATURES += "core2" seems to be the option i'm looking for Jan 21 16:39:29 and what is required to build a release version? compiling still uses "-g" etc. and EXTRA_IMAGE_FEATURES = "debug-tweaks" is the only thing i found so far Jan 21 16:39:36 schramae: no, that's not what you're looking for Jan 21 16:40:02 TUNE_FEATURES is used by individual tuning configurations to select what the include. the interface for a machine is to define DEFAULTTUNE to an appropriate tuning and to require the appropriate .inc Jan 21 16:40:13 (or .conf, either way from conf/machine/include/) Jan 21 16:40:19 as i already mentioned Jan 21 16:48:10 ok, i'll recheck. but isn't there an easy way to at least get rid of "-g" / DEBUG_FLAGS? or is this implied by "debug-tweaks" or such? Jan 21 16:51:39 gbrennon: helps if you tell me what the errors were Jan 21 16:52:17 this are the tasks that have failed: /home/gbrennon/fsl-community-bsp/sources/poky/meta/recipes-multimedia/pulseaudio/pulseaudio_2.1.bb, do_populate_sysroot /home/gbrennon/fsl-community-bsp/sources/poky/meta/recipes-extended/iptables/iptables_1.4.15.bb, do_compile /home/gbrennon/fsl-community-bsp/sources/poky/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.23.bb, do_compile /home/gbrennon/fsl-community-bsp/sources/poky Jan 21 16:53:17 rburton: one of the errors was "IOError: [Errno 28] No space left on device" Jan 21 16:53:24 but my driver have free space Jan 21 16:55:13 gbrennon: that's a pretty serious problem. double-check the drive its building on and try again. Jan 21 16:56:14 gbrennon: also make sure you haven't run out of inodes Jan 21 16:56:21 df -i Jan 21 16:57:20 df -i output for my home is: /dev/mapper/vg_gbrennon-lv_home 2711552 1417318 1294234 53% /home Jan 21 16:57:36 the first one is the inodes Jan 21 16:57:55 gbrennon: well re-run something like pulseaudio then Jan 21 16:58:03 just knowing it failed in populate_sysroot doesn't let me help you Jan 21 16:58:50 hm Jan 21 16:58:53 i'll rerun Jan 21 16:59:42 same error :/ Jan 21 17:00:32 i have to go Jan 21 17:00:37 tomorrow i'll search more about this Jan 21 17:00:40 thank u guys Jan 21 18:11:45 <_Lucretia_> what's the best simple project to look at to build a host application under yocto, i.e. a build tool Jan 21 18:12:25 _Lucretia_: as in you are picking a build system for an app you haven't started to write yet? Jan 21 18:12:30 _Lucretia_: autotools works well Jan 21 18:13:02 <_Lucretia_> no, I need to add gprbuild to meta-ada, it's for building mixed language Ada, C, C++ applications Jan 21 18:13:32 <_Lucretia_> but it runs on host only and I need my layer to be able to find it in it's PATH Jan 21 18:13:42 <_Lucretia_> similar to how -gcc Jan 21 18:13:44 <_Lucretia_> works Jan 21 18:13:45 install it to the native sysroot, and it just works, surely Jan 21 18:13:55 you'd have a gprbuild-native Jan 21 18:14:14 <_Lucretia_> just name the recipe that? Jan 21 18:14:29 <_Lucretia_> surely, there's something I have to do inside the recipe Jan 21 18:14:37 bbclassinherit=native inside the recipe Jan 21 18:14:57 or inherit native Jan 21 18:15:10 must be differences, but i'm not sure what they are. :) cmake is a reasonable example i guess Jan 21 18:15:21 <_Lucretia_> ok, thanks Jan 21 18:15:32 <_Lucretia_> is this the same for any libs it needs to build? I spose so Jan 21 18:15:52 yeah Jan 21 18:15:58 right, time to bath the kids Jan 21 18:27:37 systemd merge is not playing well with meta-systemd Jan 21 18:31:57 khem: true but after removing dbus-systemd from RDEPENDS it at least builds something Jan 21 18:32:58 not for angstrom Jan 21 18:33:04 it goes into tail chase Jan 21 18:33:39 JaMa: in your case I am sure its still using systemd from meta-systemd Jan 21 18:33:57 you need to add systemd to DISTRO_FEATURES as well Jan 21 18:34:47 yes I'm still using systemd from meta-systemd (intentionally) and I've added systemd to SHR already :) Jan 21 18:36:26 do you know offhand whats missing between what got merged and the one in meta-systemd ? Jan 21 18:37:29 I've compared only systemd recipe and reported some differences on ML (e.g python support) Jan 21 18:42:21 khem: only systemd itself landed last night, more to come this week Jan 21 18:42:32 khem: didn't want to just copy-paste it all Jan 21 18:44:12 rburton: it would have been good to test it with a distro outside oe-core Jan 21 18:44:14 IMO Jan 21 18:56:44 khem: it's very similar to what's in meta-systemd Jan 21 18:59:43 guys, is there a way to prevent a specific package from being installed in the final image? Jan 21 19:01:14 if you are using RPM, you can tell it to 'provide' a package, effectivly telling the system it's already installed Jan 21 19:01:43 or if you wnt to just remove a package from being installed, the easiest answer is use hob.. select you image type.. then modify what is going to be installed Jan 21 19:03:25 In the Yocto Project/OE stuff, you can't "remove" a package.. but you can copy an existing set, and create a new install set w/o that package selected.. (that is what hob does) Jan 21 19:06:49 can the provide-solution be done via some recipe? i know it's not the cleanest solution, but i just figured out i would have to do quite a few changes just to get rid of 2 programs. or is there a way to simply remove a dependency in a .bbappend with sth. like PACKAGES -= "foo"? Jan 21 19:12:23 schramae: there's no -=, but you can use := with oe_filter_out Jan 21 19:14:21 ok, i'll give it a try. btw, the DEFAULTTUNE now works as well, i did not notice before that there already was a .inc for core2. thanks! Jan 21 19:17:13 https://lh3.googleusercontent.com/-xK-FK4pELDE/UP2NpU30oeI/AAAAAAAAGeQ/72GRxD5Rz_I/w497-h373/IMG_20130121_134745.jpg Jan 21 19:17:46 schramae: np Jan 21 19:22:43 gah, we're getting dependency loops and multiline comment failures all over the place in our builds now Jan 21 19:43:53 sounds like time to go home and/or grab a beer ;) Jan 21 19:44:13 heh, indeed Jan 21 23:07:46 fray: the ppc64 issue was due to my image containing both 32bit/64bit packages Jan 21 23:09:10 fray: I wonder how smart deals with multilib Jan 21 23:10:54 khem: hi there Jan 21 23:11:22 khem: in one collie binary... Jan 21 23:11:24 10acc: e12fff1e bx lr Jan 21 23:11:27 :/ Jan 21 23:11:30 hmm Jan 21 23:11:48 does this binary include some hand written assembly Jan 21 23:12:06 no, it's well known binary Jan 21 23:12:29 is it linked with fix-bx flag Jan 21 23:12:34 iirc the LDFLAGS are stripped by some patch in the recipe Jan 21 23:12:43 there we go then Jan 21 23:12:55 I see I fix it i.e. in klibc.bbclass Jan 21 23:13:14 http://paste.debian.net/227234/ Jan 21 23:13:33 I could do that in the single recipes Jan 21 23:14:00 the point is, if I pass CC and LDFLAGS in klibc.bbclass there is a drawback..the size Jan 21 23:20:06 hi, I follow the kernel development manual "2.5. Incorporating Out-of-Tree Modules", copy the "hello-mod_0.1.bb" and "files" folder into my taget layer "meta-intel/meta-jasperforest/recipe-kernel", then add "MACHINE_EXTRA_RRECOMMENDS += "kernel-module-hello" in the conf/local.conf Jan 21 23:20:29 after build and boot, there's no "hello.ko" found Jan 21 23:21:47 khem: btw the assembler is surely in some ioctl Jan 21 23:22:51 export CC_armv4 = "${TARGET_PREFIX}klcc -march=armv4 -mthumb-interwork" Jan 21 23:23:05 why -mthumb-interwork Jan 21 23:23:46 ant_home: klibc.bbclass is wrong place for such a change Jan 21 23:23:55 ant_home: it has to be in tune-arch files Jan 21 23:24:28 hm Jan 21 23:24:35 ok, I see arm-oe-linux-gnueabi-klcc -march=armv4 -mthumb-interwork -DDEBUG -O0 -g -Wall -Wl,--fix-v4bx -o Jan 21 23:24:45 and the binary is ok Jan 21 23:24:53 must be like this Jan 21 23:25:32 EddyLaiTW: the module did not get added to image i believe, may be you should add it explicitly Jan 21 23:25:52 ant_home: yes that flags is absolutely needed on armv4 Jan 21 23:26:20 thanks khem Jan 21 23:26:25 yes, it makes interworking possible on armv4 Jan 21 23:27:07 now, klcc-cross should pass all that stuff ... Jan 21 23:28:29 hmmm todays oe-core/master and bb/master DEBUG: Task 13 (/b/kraj/angstrom/sources/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.60.bb, do_unpack) is not buildable Jan 21 23:28:32 DEBUG: (Complete marker was False and the remaining dependency count was 1) Jan 21 23:28:57 @LDFLAGS = ("\-\-fix\-v4bx"); Jan 21 23:29:30 @OPTFLAGS = ("\-Os", "\-march\=armv4", "\-mtune\=strongarm"); Jan 21 23:30:46 @REQFLAGS = ("\-D__KLIBC__\=2", "\-D__KLIBC_MINOR__\=0", "\-D_BITSIZE\=32", "\-fno\-stack\-protector", "\-fwrapv", "\-fno\-exceptions", "\-mabi\=aapcs\-linux", "\-mno\-thumb\-interwork", "\-nostdinc", "\-iwithprefix", "include", "\-D__KLIBC__\=2", "\-D__KLIBC_MINOR__\=0" Jan 21 23:30:46 , "\-D_BITSIZE\=32"); Jan 21 23:30:51 oops ..sry Jan 21 23:31:12 khem: it seems we teached klcc the right way... Jan 21 23:32:15 still it seems to discard interworking as default... Jan 22 00:03:11 khem: yes, I can force interworking in usr/klibc/arch/arm/MCONFIG Jan 22 00:03:21 I'll send a new version of the patch Jan 22 01:22:59 hi , can I use "bitbake core-image-basic -c devshell" to build a standalone kernel module? Jan 22 01:23:50 looks like "make" will use the host's kernel 3.2.x but not yocto 1.3's kernel 3.4 to build the kernel module Jan 22 02:08:02 http://embeddedlinuxconference2013.sched.org/event/53b201c7ad059284a2add9523a4492c3#.UP30YyZQA24 Jan 22 02:11:40 Jefro, your bof is up against the demo reception :( **** ENDING LOGGING AT Tue Jan 22 02:59:58 2013