**** BEGIN LOGGING AT Tue Oct 09 02:59:59 2012 Oct 09 07:14:52 Hi folks ! Oct 09 07:15:22 Chat francophone ? Oct 09 07:15:27 Salut les copains ! Oct 09 07:20:24 no, we prefer english here. Oct 09 07:20:57 ok Oct 09 07:21:08 np Oct 09 07:22:16 I do not undestand everything about oe in english as well as in french ;) Oct 09 07:25:29 Actually, I am looking for a way to find where a receipe is executed from. Oct 09 07:26:26 I mean that I see useless packages for my application (bluetooth, quilt, m4 ...) but can't figure out where they come from Oct 09 07:31:21 * dm8tbr hasn't built this for a while, but IIRC you can get it to show you the dependency tree Oct 09 07:48:26 hi! while building latest oe-core+meta-oe (only) I see the following error: Oct 09 07:48:30 Parsing of 1195 .bb files complete (0 cached, 1195 parsed). 1538 targets, 24 skipped, 0 masked, 0 errors. Oct 09 07:48:32 ERROR: No recipes available for: Oct 09 07:48:34 /home/gizero/src/meta-openembedded/meta-oe/recipes-connectivity/connman/connman_1.0.bbappend Oct 09 07:48:36 ERROR: Command execution failed: Exited with 1 Oct 09 07:48:40 I know almost nothing about systemd, but, from my understanding there is a dedicated layer for supporting it. Here connman_1.0.bbappend looks to be a systemd bbappend. What's the proper way to fix it in meta-oe? Can we simply drop it? I see oe-core now includes connman-1.4 and meta-systemd does have its own bbappend for that version. I'm currently BBMASKing to get further (need to test unrelated new recipe)... but I think it Oct 09 07:48:42 should be fixed... or is building just oe-core+meta-oe an "unsopported" path? Oct 09 07:56:58 morning all Oct 09 07:58:38 morning silvio! Oct 09 07:59:12 'morning ! Oct 09 08:03:53 generating the dependency graph functions, but, unfortunately, the graph is too big to be generated. Oct 09 08:04:28 browsing the dot file shows that no difference is made between build dependencies and run dependencies :( Oct 09 08:14:09 morning all Oct 09 08:14:26 good morning Oct 09 08:14:58 hi bluelightning hi mckoan Oct 09 08:23:46 gm Oct 09 08:27:59 hi Oct 09 08:50:03 NOTE: multiple providers are available for runtime lighttpd-module-fastcgi (libav, lighttpd) Oct 09 08:50:06 NOTE: consider defining a PREFERRED_PROVIDER entry to match lighttpd-module-fastcgi Oct 09 08:50:07 auch... Oct 09 08:52:33 sorry for the noise about connman_1.0.bbappend: it was my sandbox being dirty... :-( Oct 09 09:02:15 hrw: libav provides fastcgi? Oct 09 09:02:34 hrw: or something horribly broken? Oct 09 09:02:47 likewise: it's libav metadata fault Oct 09 09:02:56 otavio already send patch to fix that Oct 09 09:03:23 hrw: likewise http://patchwork.openembedded.org/patch/37867/ Oct 09 09:03:32 another symptom of us assuming PACKAGES_DYNAMIC is a glob instead of a regex Oct 09 09:03:41 we really need to fix that Oct 09 09:08:13 thx JaMa Oct 09 09:10:00 hmm, actually in this case the libav PACKAGES_DYNAMIC value was insane... Oct 09 09:13:10 I need to set own linux-libc-headers as preferred one in metadata (instead of config). DEFAULT_PREFERENCE = "1" does not work Oct 09 09:15:31 hrw: is this in an additional layer on top of OE-Core? Oct 09 09:15:39 bluelightning: yes Oct 09 09:15:53 bluelightning: oecore uses 3.4.3 and I need 3.7 tree Oct 09 09:16:05 is the layer priority set higher than 5 ? Oct 09 09:16:24 just 5 - bump? Oct 09 09:17:03 it may help, although I have to say if the version is greater I would have expected it to be picked unless we are explicitly setting PREFERRED_VERSION_linux-libc-headers somewhere Oct 09 09:17:47 ../openembedded-core/meta/conf/distro/include/tcmode-default.inc:LINUXLIBCVERSION ?= "3.4.3" Oct 09 09:17:52 ../openembedded-core/meta/conf/distro/include/tcmode-default.inc:PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}" Oct 09 09:18:35 and I have this ver floating as 3.7+git${SRCPV}. can set it as PV=3.7 PR=r1+git${SRCPV} but thats hack Oct 09 09:19:27 the only way to override that will be to set LINUXLIBCVERSION or PREFERRED_VERSION_linux-libc-headers Oct 09 09:19:47 you can use "3.7+git%" to match your recipe Oct 09 09:22:19 is 'danny' the new release-branch? Oct 09 09:25:01 bluelightning: thanks Oct 09 09:26:40 ensc|w: yes Oct 09 09:27:54 I understand that oe builds every package, then only select some to make the images. Is this correct ? Oct 09 09:28:13 yes Oct 09 09:28:47 so the huuuuge size of the build directory ... Oct 09 09:29:39 define huge Oct 09 09:29:56 16 Gb so far Oct 09 09:30:14 16GB? not so bad Oct 09 09:30:27 I work with a virtual machine and the drive was too small Oct 09 09:30:41 add second one Oct 09 09:31:03 how big should I increase ? Oct 09 09:31:25 hard disk space should be considered as a build dependency ! Oct 09 09:32:00 I had builds for 250GB even Oct 09 09:32:38 but I do builds on 500GB disk and do not care too much about used space Oct 09 09:33:12 my coworker achieved to build, in the end the rootfs was ~150 Mb. Oct 09 09:34:03 It is strange that a build system which works on dependecy makes so much useless work Oct 09 09:34:37 I building under chroot enviroment, which is the right umask to set? Oct 09 09:38:58 I found that opkg is build. Can this be the cause of so many packages to be build ? Oct 09 09:40:09 ascor: you can always try to compose rootfs from Debian packages ;) Oct 09 09:40:40 ascor: OE builds lot of stuff due to build dependencies and needs of having control over those. Oct 09 09:41:23 ascor: you can create 20KB image with OE which will boot just fine as well. will just write 'hello world' anyway Oct 09 09:44:06 ascor: to clarify, we don't build absolutely everything; all of the things that get built are needed either as part of the build process or on the target in some way Oct 09 09:44:55 so where do all that stuff come from ? Oct 09 09:45:34 even after removing bluetooth I get warning messages about V3 beeing removed Oct 09 09:45:34 source code for all of the things that get built and all of the binaries and intermediate files that are produced from them turn out to be quite large, there's not really any way around it... Oct 09 09:46:05 you can add INHERIT += "rm_work" to your local.conf, that should delete files as the build progresses Oct 09 09:46:24 FYI, you can build a full system including X with under 40GB, so it's not that bad... Oct 09 09:46:39 (even without rm_work) Oct 09 09:47:03 Is there something like the kconfig mechanic used in buildroot ? So that I can browse simply package list and check/uncheck to match my needs ? Oct 09 09:47:46 there is Hob: http://www.yoctoproject.org/projects/hob Oct 09 09:47:51 it comes with bitbake Oct 09 09:48:06 the rm_work trick may help to build, thanks Oct 09 09:59:19 I can't find hob in bitbake pacakge :'( Oct 09 10:00:06 ascor: which version of bitbake and OE are you using? Oct 09 10:01:14 I downloaded 1.8.19 on berlios Oct 09 10:01:42 But we work with a module, and everything is downloaded from the module provider Oct 09 10:01:46 antique version Oct 09 10:02:16 ascor: 1.16.0 is current Oct 09 10:02:59 I am just starting to work on the project, and I intend to get those informations Oct 09 10:03:25 only 1.12 on berlios Oct 09 10:03:39 ignore berlios Oct 09 10:04:54 git clone git://git.openembedded.org/bitbake Oct 09 10:04:59 ascor: OE has transitioned to a layered approach using OE-Core Oct 09 10:05:00 ascor: http://www.openembedded.org/index.php/OpenEmbedded-Core Oct 09 10:05:37 so if you're starting something new I would suggest you base it on OE-Core rather than OE-Classic Oct 09 10:06:05 the point is that I don't know if the module provider has switched to the new version Oct 09 10:06:47 OE-core = layered approach and OE-classic = classic approach ? Oct 09 10:07:10 still no hob binary with bitbake 1.16 :( Oct 09 10:07:15 ascor: yes... OE-Classic had everything in one large repository, which was forked by everyone Oct 09 10:07:28 ascor: you won't be able to use hob (or indeed current bitbake) with OE-Classic Oct 09 10:07:47 ascor: depending on how exotic the device is it shouldn't be too hard to move support for it to OE-Core Oct 09 10:08:43 everywhere I look so far in that projetct, it looks exotic ! Oct 09 10:09:32 thanks for your advices. S Oct 09 10:09:37 np Oct 09 10:09:42 I'll see you later Oct 09 10:09:59 time to lunch ... Oct 09 10:10:38 adding support for device in OE is not that hard Oct 09 10:10:50 even new arch is not complicated Oct 09 10:11:26 I really like layered stack - bbappend makes life much easier Oct 09 10:12:24 it's been a sometimes difficult road to get here, and we're by no means finished, but yes... I think it's much better than everyone forking OE as they used to Oct 09 10:23:51 I can't rebuild image, or better 2 of mi recipes give me error, but I can't understand why, could be becouse I delete some files in a wrong way or permission right? Oct 09 10:23:57 q:q Oct 09 10:24:20 http://paste.ubuntu.com/1269015/ Oct 09 10:31:41 silvio: did you check whether those packages were actually non-empty and produced? Oct 09 10:37:40 qdbusnetworkmanager is done right in package-split Oct 09 10:39:11 morning all Oct 09 10:40:08 silvio: if you do a "bitbake -c clean" for both recipes and then build the image again does it help? Oct 09 10:42:53 bluelightning, I did also -c cleanall Oct 09 10:43:16 nothing change :( Oct 09 10:43:36 silvio: does a package file exist under tmp/deploy/ipk? Oct 09 10:45:37 bluelightning, sorryu afk Oct 09 10:46:28 bluelightning, qtcardiopad yes, qtdbudnetman no Oct 09 10:46:40 bluelightning, sorry afk Oct 09 10:47:26 silvio: can I see find tmp/deploy/ipk -name "qbusnetwork*" -o -name "qtcardiopad*" Oct 09 10:47:55 i.e. please pastebin the output of that Oct 09 10:57:45 Is it feasible to set BB_SIGNATURE_HANDLER on a per-recipe basis, or does it need to be the same everywhere? Oct 09 11:05:10 * pb_ stabs cairo for wanting glesv2.pc Oct 09 11:38:11 uf. killed libav with COMPATIBLE_HOST Oct 09 11:38:29 WARNING: explode_dep_versions(): Item gnutls appeared in dependency string 'gnutls-xx gnutls (>= 2.12.20) pkgconfig eglibc (>= 2.16) gnutls-openssl gnutls (= 2.12.20-r8.3) gnutls-extra' multiple times with different values. explode_dep_versions cannot cope with this. Oct 09 12:23:04 I have a product that is based on angstrom-2010.x.conf, I can see many references to packagin : ipkg opkg ... Oct 09 12:23:20 but where is it included ? Oct 09 12:23:59 I mean where is the dependecy written ? Oct 09 12:25:27 ascor: this is handled by package*.bbclass Oct 09 12:26:11 ascor: it's worth noting that OE's rootfs construction depends on the package manager, so it cannot easily be prevented from building if that's what you're aiming to do Oct 09 12:26:40 ascor: however package management is not at all mandatory on the target Oct 09 12:31:29 I want to remove it for several reason : main reason is to learn how to find things in OE (which is a maze), second is that I suppose that package management depends on packages themselves. So I hope build time and space will be both better Oct 09 12:32:34 ascor: sure, but if you intend to do that you will basically need to replicate the functions of the package manager to cover assembling the image Oct 09 12:32:35 So somwhere in all that conf files, there must be that line "inherit package*.bbclass" ? Oct 09 12:33:11 The image is build using the package manager ? Oct 09 12:33:23 yes Oct 09 12:33:43 So the package manager is not cross compiled, and never in the target ? Oct 09 12:34:03 that's separate and entirely optional, yes Oct 09 12:34:05 But I saw it on the rootfs. Oct 09 12:34:33 "inherit package.bbclass" isn't actually valid syntax in a .conf file; it would be INHERIT += "package*" Oct 09 12:35:06 ascor: it's optional, but your configuration might be requesting it. Oct 09 12:35:33 ascor: in OE-Classic you would set ONLINE_PACKAGE_MANAGEMENT = "0" to disable; in OE-Core it would be done by ensuring "package-management" is not in IMAGE_FEATURES Oct 09 12:36:50 I can not understant how OE works and where to look, because I can not find the "big picture" somewhere. Whatever I look, I only find that its hard to get in and more powerfull than BR. Oct 09 12:39:21 ascor: you may find looking at the Yocto Project documentation helpful; that covers OE-Core but does give some overview Oct 09 12:39:23 Is there some documentation that I have obviously not read ? Oct 09 12:39:40 http://www.yoctoproject.org/documentation Oct 09 12:41:27 I'm on it Oct 09 12:41:37 yocto = oe ? Oct 09 12:45:14 the Yocto Project is an umbrella project that helps to maintain OE-Core Oct 09 12:45:31 (among other things) Oct 09 12:46:06 Like intel has developpers who contibute to linux kernel ? Oct 09 12:49:16 ascor: kind of yes Oct 09 13:11:42 Does oe-core have any convenient script for pruning stale data from sstate-cache? Oct 09 13:12:42 I seem to have 41G of data in there at the moment (even after deleting about 6G of old webkits) which seems excessive. Oct 09 13:13:58 pb_: scripts/sstate-cache-management.sh Oct 09 13:14:11 ah, very good. thanks. Oct 09 13:17:13 5.1G now! that's better. Oct 09 13:22:36 good grief, why is bitbake suddenly recompiling my kernel? Oct 09 13:22:48 I guess that script must have removed rather more files than I wanted. Oct 09 13:24:04 * pb_ waits patiently Oct 09 13:24:05 hmm, it deletes stamps as well, perhaps it's being a bit overzealous there :( Oct 09 13:24:17 yeah, it seems Oct 09 13:24:29 really these tools need to not assume they know how the build system works, they need to call into it and make it do the work instead Oct 09 13:24:46 there does seem to be a certain random component to the amount of work that bitbake chooses to do in any given invocation, though in this particular case I'm pretty sure it is something that the script removed and shouldn't have. Oct 09 13:25:36 if you're ever surprised by a rebuild, you can use bitbake-diffsigs to check why it happened Oct 09 13:25:45 I did "../oe-core/scripts/sstate-cache-management.sh --cache-dir sstate-cache -d" which appeared to be the right sort of thing. Oct 09 13:25:45 if the data exists it will indicate what changed Oct 09 13:26:24 right, yeah, I should try that. Oct 09 13:27:31 mostly it's fairly harmless, though I have had a few instances where it seems to have decided to recompile my entire graphics stack (gl driver up to webkit) which is a bit painful Oct 09 13:28:45 ideally I would like to be able to exclude webkit from automatic rebuilds when one of its dependencies changes, since in 99% of cases there is no need to recompile it. Oct 09 13:29:10 that kind of exclusion is fairly easy to do I think Oct 09 13:29:22 do you happen to know how? Oct 09 13:29:28 just checking, one moment Oct 09 13:30:39 so, if the recipe should never be rebuilt for any dependency changing, add it to SIGGEN_EXCLUDERECIPES_ABISAFE - that's a huge hammer though Oct 09 13:30:53 there's a more targeted way, just digging a bit further Oct 09 13:35:50 pb_: there's also SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS - just add "a->b" to it to exclude the dependency of a on b from the signature Oct 09 13:36:46 failing that, you can extend the signature generator itself, see meta/lib/oe/sstatesig.py and bitbake/lib/bb/siggen.py Oct 09 13:39:53 slight correction, I think SIGGEN_EXCLUDERECIPES_ABISAFE is for the dependent, so that wouldn't apply in this situation Oct 09 13:45:21 Good afternoon everyone, I'm looking into dabbling with NEON instructions for the BeagleBone but I cannot find the arm_neon.h include header in my meta-toolchain sysroot, does anyone have any experience with this? Oct 09 13:46:09 bluelightning: okay, cool, thanks Oct 09 13:46:14 I'll give that a go later. Oct 09 13:47:55 on another topic, does anybody know what the state of the art is in terms of using cairo on top of cogl? Oct 09 13:48:35 it looks like cairo-cogl-surface.c is a bit rotten and doesn't work anymore because the cogl APIs that it uses have apparently gone away. Oct 09 13:49:00 cairo-gl-surface.c could presumably be made to work on top of cogl-gles2 with a bit of hacking but I would rather not get into that right now if there is an easier alternative. Oct 09 13:49:41 (and, right now, I only have cogl 1.10 anyway although I guess I could upgrade.) Oct 09 13:53:56 pb_: asking my colleagues now Oct 09 13:56:14 re: NEON - I found it in the x86_64 sysroot, any idea why it was thier and not in the ARM sysroot as I expected? Oct 09 14:00:00 pb_: the answer is "I think the BKM is still just to use the software renderer and upload the result to a Cogl texture. bob made a Cogl backend for Cairo and it is in Cairo core AFAIK, but I don't think it ever got complete enough to use in a real product" Oct 09 14:00:26 ah, that is a bit sad Oct 09 14:01:38 pb_: I'm sure help would be appreciated if you chose to complete the backend... Oct 09 14:01:53 yeah, I'll have a look at how hard it would be to at least make it compile again Oct 09 14:02:17 the main problem seems to be that cogl_primitive_draw() no longer exists and there doesn't seem to be an obvious replacement. Oct 09 14:02:34 it sort of looks as though the whole CoglPrimitive interface is in the process of going away. Oct 09 14:03:36 I could certainly do with some level of accelerated drawing, the software renderer doesn't seem to be performing very well. Oct 09 14:05:56 is there a tool to clean sstate-cache from deprecated entries? I have 55GB of files there Oct 09 14:06:10 hrw: yeah, we talked about that an hour or so ago :-) Oct 09 14:06:17 scroll up Oct 09 14:06:41 ok, will Oct 09 14:06:42 thanks Oct 09 14:07:16 bluelightning: oh, I remember now, the other bad thing about the cogl backend is that it introduces a ghastly dependency loop Oct 09 14:07:53 cogl depends on (inter alia) pango, which depends on cairo. if I enable the cogl backend then cairo depends on cogl. Oct 09 14:09:15 that said, though, it isn't totally obvious to me why cogl actually depends on pango in the first place. maybe that could be eliminated. Oct 09 14:09:24 pb_: it might be worth joining #clutter on irc.gnome.org, both of the main cogl developers hang out there and I'm sure would be much more qualified than me to answer questions on it :) Oct 09 14:10:23 good idea :-) Oct 09 14:13:04 38349 files on remove ;) Oct 09 18:15:29 hi Oct 09 18:15:40 jo **** ENDING LOGGING AT Wed Oct 10 02:59:58 2012