**** BEGIN LOGGING AT Tue May 17 02:59:58 2011 May 17 06:54:48 kergoth__: pong May 17 06:57:26 03Eyal Reizer  07org.openembedded.dev * r16fcbc6a76 10openembedded.git/recipes/ti/ti-wifi-utils_git.bb: May 17 06:57:26 ti-wifi-utils: update to use the latest release May 17 06:57:26 * Change to a newer calibrator version supporting latest mac80211 release. May 17 09:51:03 good morning May 17 09:51:47 ericben: hi May 17 09:52:24 ericben: have you experience with QT/e -display transformed:Rot90 ? May 17 10:13:17 hmm... qt4-embedded.inc sets -qt-gfx-transformed which is fine May 17 10:39:06 03Christian Betz  07master * re0d2de398e 10openembedded.git/recipes/acpid/acpid-1.0.10/netlink.diff: (log message trimmed) May 17 10:39:06 acpid-1.0.10: fix compiler warning on some platforms May 17 10:39:06 Task compile fails with the following error. **** ENDING LOGGING AT Tue May 17 10:44:26 2011 **** BEGIN LOGGING AT Tue May 17 10:44:26 2011 **** ENDING LOGGING AT Tue May 17 10:45:25 2011 **** BEGIN LOGGING AT Tue May 17 10:45:53 2011 May 17 12:34:28 Hello May 17 12:37:56 hi otavio May 17 13:04:01 hello May 17 13:04:34 what is the difference between qte and qt/x11 packages? May 17 13:06:41 brolin: qte (Qt Embedded) uses the framebuffer directly May 17 13:06:51 Qt/x11 uses X11 May 17 13:11:00 03Philip Balister  07org.openembedded.dev * rb167a9a9e5 10openembedded.git/recipes/networkmanager/ (3 files in 2 dirs): May 17 13:11:00 networkmanager_git : Fix more build issues. May 17 13:11:00 Failed for a clean build finding rtnl.h again. I think I have fixed for May 17 13:13:25 what is the difference between Vesa and fbdev drivers May 17 13:17:37 uhmm May 17 13:18:42 thanks bluelightning May 17 13:19:37 then the toolchains are differents? May 17 13:50:51 brolin: the tools should be the same, only the libs should differ May 17 13:51:14 for the libs we append E for embedded so the libs from embedded & x11 can coexist May 17 14:22:21 03Yu Ke  07master * r92701d4c53 10bitbake.git/lib/bb/fetch2/git.py: (log message trimmed) May 17 14:22:21 git fetcher: add support for rebaseable git repo May 17 14:22:21 Some upstream git repo may rebase in the future, which means current May 17 14:34:44 heh, it worries me that we cared. rebase vs merge shouldn't have mattered in our fetcher context May 17 15:04:52 kergoth: heh, true May 17 15:08:49 https://github.com/kergoth/homefiles/blob/master/bin/git-cached-clone - wonder if itd be better to treat our DL_DIR/git as just an object cache, similar to how this script does it May 17 15:19:16 kergoth: did you have any further opinions on what has been discussed on the ML re layer tooling? May 17 15:21:28 i'm rather torn on the remote layers bit, i can't decide if i like it more in bitbake or outside of it. leaning toward the latter. i definitely like some of the ideas you brought up for future tools. maybe we should consolidate them into a todo somewhere May 17 15:25:21 kergoth: there's http://wiki.pokylinux.org/wiki/Layer_Tooling May 17 15:26:20 ah, cool May 17 15:26:25 as to whether it's inside or outside, most people I have spoken to are leaning towards outside also... it avoids the whole environment reparse thing at least May 17 15:29:59 I'm rather torn. part of me is inclined to say retrieval of layers is something that doesn't belong in the tool, and we should punt on it and let people deal with it using whatever tools they prefer (e.g. git-submodule, including all the layers in clearcase or svn, or whatever). but on the other hand, that implies a lack of consistency in what tools are used for this May 17 15:36:29 we should really teach the bb.parse.ast to emit back out into recipe format May 17 15:36:40 would be useful to be able to parse to an ast, modify and write back out May 17 15:38:36 kergoth: that would seem to be a pre-requisite for the recipe maintenance tools idea May 17 15:38:42 at least, for the right way to do it... May 17 15:38:57 agreed May 17 15:39:23 probably woudln't be too painful to add. what we do need, though, is a new bb.parse api function to parse a file and return the ast nodes May 17 15:40:39 i have an embedded system and i am trying to kmalloc 900KB and the kernel is not giving me the memory. Is there an alternative to kmalloc i can use for large amounts? May 17 15:41:17 this isn't the best channel for that question May 17 15:41:23 this channel is about a specific project May 17 15:41:55 thought you guys with know with embedded and limited resources May 17 15:42:17 this is true, but it doesn't make it the right place to ask. i'd suggest #elinux or #edev May 17 15:44:36 thanks May 17 15:51:30 np May 17 15:57:04 I am noticing that binaries that get packaged are different than the originals. I saw that package class is stripping binaries but even after performing this I can't get my binaries to match the original, is there another step I am missing May 17 15:58:12 What are the differences you're seeing? May 17 15:58:47 the file sizes are different not sure how they are different internally May 17 15:59:42 roza: it's working as intended. is there some actual problem you're hitting, or are you just investigating? May 17 16:01:09 i just want to verify that I can get the files in the same state outside the build system May 17 16:01:27 and you're stripping with the exact same arguments we do? May 17 16:01:33 see package.bbclass May 17 16:01:47 I don't really see the point of what you're doing, but that class will show you what we do May 17 16:02:38 i was using the same arguments as package.bbclass was using but it was still different after - just thought it maybe something else in addition to stripping May 17 16:03:44 huh. not that i'm aware of, anyway, maybe someone else knows May 17 16:05:00 I am getting binaries that are built outside the build system so I am just trying to verify the binaries are the same after the packaging is done May 17 16:08:05 anyone know of a way to override opkg when installing directly from the ipk (no download) so that it won't complain about md5sum mismatch with the package index? May 17 16:20:08 esbenh: addhook looks cute. implemented dependencies between event handlers, basically, right? so don't have to worry about when this anonfunc runs vs that one.. May 17 16:20:23 bluelightning: WRT remote layering. What do you mean environment reparse thing? Just curious. May 17 16:21:16 ReaperOfSouls: well, if you fetch down one or more layer(s) then you've almost certainly changed the value of some variables (the "environment") May 17 16:21:29 ReaperOfSouls: so you really need to reparse everything from scratch after that May 17 16:21:56 Wouldn't that be true for all layering? May 17 16:22:24 * ReaperOfSouls notes in the patch I posted, it fetches all the layers first, then does the standard layer parse. May 17 16:22:42 Or am I missing something. May 17 16:22:58 ReaperOfSouls: right, the catch being you're currently hardcoding a bunch of variable values to make the fetcher work May 17 16:23:11 which I think we'd rather avoid if possible May 17 16:23:49 bluelightning: one possibility that i mentioned at some point for that would be to parse bitbake's conf/bitbake.conf, from its installation, which is already essentially a minimal subset.. but i agree, its pretty ugly May 17 16:24:37 * ReaperOfSouls thinks he noted that in the patch header that I wasn't happy with it. OTOH you do need a subset of things defined otherwise the fetchers just don't work. May 17 16:25:10 yes, they have to be defined somehow May 17 16:26:48 just a general downside to the use of our fetchers, and how bitbake is configured. i've sometimes thought it might be nice to separate configuration of bitbake itself (bits that might belong in an rc file) from the global metadata that flows into the recipes May 17 16:27:03 Ulimately though, I am not sure why having the things the fetchers need set to a resonable default as set if not set is a bad thing really. May 17 16:28:23 that sort of default probably doesn't belong in the fetcher, if we're going to have sane defaults for things, it would be nice to implement it generally. either scattered where they're used, or perhaps as a part of the BBConfiguration class May 17 16:28:30 * kergoth ponders May 17 16:29:29 kergoth: agree. Actually I don't think I set it their, but thats neither here nor there. :) May 17 16:29:31 (aside, i'd really like to see bbconfiguration extract all the options *bitbake* obeys from the datasmart object into attributes of the class, so that further bitbake configuration goes purely from it, rather than from the datasmart object) May 17 16:29:34 * kergoth nods May 17 16:40:43 kergoth: Perhaps we could provide something like init.conf since every set of layers provides a full out bitbake.conf. Reduce the overloading of the config and make its purpose a bit more clear or something along those lines. May 17 17:04:21 khem, whats getting lost? May 17 17:05:52 hi ka6sox May 17 17:07:08 hi woglinde May 17 17:10:53 doo doo doo May 17 17:11:02 ??? May 17 17:11:26 ka6sox-away: description file that I added to git repo May 17 17:11:32 I dont know how it got deleted May 17 17:11:53 what? May 17 17:15:52 khem, hmmm...all we did was reboot it per your request. May 17 17:22:49 hm ha core works again May 17 17:22:56 so that was it about May 17 17:52:16 ka6sox-away: yes I still dont understand why they got lost May 17 17:58:45 khem, if its in the repo it shouldn't have May 17 17:59:00 nothing changed in the config...I verified that. May 17 18:01:57 these files live inside the repos May 17 18:02:21 lunch! May 17 18:02:24 ka6sox-home: I wonder if there is some other interface which can overwrite them I dont know May 17 18:02:37 woglinde: how was LinuxTag May 17 18:11:54 khem, I added a repo yesterday but that shouldn't have messed with it...and I verified that I didn't change anyhing to make it not work. May 17 18:30:46 ka6sox-home: ok, May 17 18:31:12 hi jconnolly May 17 18:31:22 hi woglinde May 17 18:31:28 do we want a layer for minimal ? May 17 18:31:46 I think angstrom fills in well May 17 18:31:58 with angstrom-bleeding is exactly what minimal was May 17 18:41:37 hm I should start with openjdk May 17 18:41:40 for meta-oe May 17 18:42:39 woglinde: btw with old oe.dev I cannot get cacao building anymore (always ends with no class found for java.lang.Object, have you seen it before? May 17 18:42:59 jama 2011.03? May 17 18:43:02 we need meta-java May 17 18:43:19 khem decision of tsc? May 17 18:43:22 woglinde: I didn't change anything java related in our distro config, but since last rebuild from scratch all my 3 buildhost are failing the same May 17 18:43:46 woglinde: no May 17 18:43:54 woglinde: I am just throwing out idea May 17 18:44:23 * JaMa also things that java bits in meta-java would be nice May 17 18:44:27 thinks May 17 18:44:41 as it was with jalimo May 17 18:44:49 hm I would be fine with it too May 17 18:45:02 and step forward as maintainer May 17 18:45:09 meta-python would be nice too so all python runtime and utilities can be put there May 17 18:45:21 khem can you ask it on the next tsc meeting? May 17 18:45:27 yes I will May 17 18:45:38 we need folks to maintain them May 17 18:45:39 maybee stefan will be maintainer too May 17 18:45:49 I will ask him next time May 17 18:45:54 I see him May 17 18:46:18 jama hm which version of cacao is it? May 17 18:46:28 cacao target? May 17 18:46:47 0.99.3? May 17 18:46:59 khem: don't know about meta-python as some parts are definetely -core and the rest are dependencies of recipes usually not strictly related to python, so imho almost everybody will end with meta-python included May 17 18:47:05 woglinde: mmt let me check May 17 18:47:20 jama set the java_runtime right May 17 18:47:23 JaMa: still its a logical separation May 17 18:47:26 so cacao target isnt build May 17 18:47:50 woglinde: yup, target cacao-0.99.3 May 17 18:48:05 yes May 17 18:48:14 set openjdk as java2_runtime May 17 18:48:19 than its not build May 17 18:48:54 woglinde: so sane-toolchain-java.inc + angstrom-jalimo.conf is not sane enough anymore? May 17 18:49:09 so the split is good May 17 18:49:14 it is May 17 18:49:29 depends on you what you want as java2_runtime preffered May 17 18:49:55 cacao is before openjdk in the alphabet so its took May 17 18:50:57 muromec sure with meego and linaro/cannonicals arm efforts we got some more contenders May 17 18:51:30 woglinde: so why not set java2_runtime in sane-toolchain-java.inc to something what builds (openjdk as you suggested)? May 17 18:51:58 woglinde: because it's target and doesn't belong to *toolchain* or is there any other reason? May 17 18:53:08 right May 17 18:53:24 woglinde: and IIRC PREFERRED_PROVIDER doesn't work with *runtime* providers, is it? May 17 18:53:25 jama feel free to commit it May 17 18:53:42 hm let me see which var it is May 17 18:54:06 or run bitbake -DDD openjdk-6 yourself and look at which place cacao target is choosen May 17 18:55:15 jama btw. the problem of cacao building is with the nasty workaround to start the java compile again when cacao-hg-native segfaults May 17 18:55:50 robert noticed it as well May 17 18:56:21 so blacklisting cacao is not best solution, right? May 17 18:57:36 ah nice May 17 18:57:45 khem uclibc with my patches works now May 17 18:58:06 because RDEPENDS on "virtual" wont work properly if you don't replace it with something like DISTRO_JAVA_RUNTIME or VIRTUAL-RUNTIME_java-runtime (in oe-core) May 17 19:01:11 khem ping May 17 19:01:17 khem I will commit it than May 17 19:01:43 *sigh* the packagename May 17 19:01:45 git-r35.10+gitr0+71d63ed75648da9b0b71afabb9c60aaad792c55c.9 May 17 19:01:48 aeh rev May 17 19:03:43 woglinde: DEBUG: sorted providers for java2-runtime are: ['/OE/dev/recipes/cacao/cacao_0.99.4.bb', '/OE/dev/recipes/jamvm/jamvm_1.5.3.bb', '/OE/dev/recipes/openjdk/openjdk-6_6b18-1.8.5.bb'] May 17 19:07:08 hmm btw, there's no java virtual machine available in SHR repos? May 17 19:07:52 I'd like to try it there. May 17 19:07:55 pespin, look for icedtea or openjdk May 17 19:08:06 not now because cacao started to fail during last rebuild from scratch May 17 19:08:11 at least there is java in oe May 17 19:08:27 and openjdk depends on it when cacao is picked as java2-runtime May 17 19:09:01 ok, thanks for the info ;) May 17 19:10:03 woglinde: and the same sorted providers after adding PREFERRED_PROVIDER_java2-runtime = "openjdk-6" :) May 17 19:24:29 jama hm let me see what I am using here May 17 19:25:05 jama try PREFERRED_PROVIDER_openjdk-6-jre = "openjdk-6-jre" May 17 19:25:11 I know it looks silly May 17 19:25:15 but worked somehow May 17 19:26:50 I've already blacklisted jamvm and cacao here May 17 19:27:57 hm okay May 17 19:32:37 woglinde: but cacao built ok before, don't know what was changed and maybe openjdk-6 will fail for me too, now May 17 19:32:47 I already said May 17 19:32:57 it has todo with the fix we build in May 17 19:33:17 which tries to build up to five when a javac died May 17 19:33:24 okay later May 17 19:33:29 need to read for my son May 17 19:33:37 thanks May 17 19:53:12 woglinde: yeah, so that is indeed the right way to silence those kind of errors and it is a little funny looking May 17 19:55:08 re May 17 19:59:55 Tartarus: the preferred provider thing? May 17 20:00:07 ya May 17 20:07:44 ah nice the path origin patch is working May 17 20:08:22 jo florian May 17 20:08:34 re May 17 20:18:30 03Henning Heinold  07org.openembedded.dev * r2a1c9e1ee5 10openembedded.git/ (14 files in 10 dirs): May 17 20:18:30 ulibc: bump git to version 71d63ed75648da9b0b71afabb9c60aaad792c55c and add some features May 17 20:18:30 * enable backtrace support and put libubacktrace into own package, needed by firefox May 17 21:29:07 good nite May 17 22:35:17 khem: ping May 17 22:40:06 khem: maybe I'm missing smthg obvious but it looks like there are missing modules in the rootfs May 17 22:41:54 (the modules are built and packaged in the modules-2.6.3xxx.tgz) May 17 23:02:08 ant__: which distro May 17 23:02:15 ant__: I am missing context May 17 23:02:26 kergoth: ping May 17 23:08:04 03Christian Charreyre  07master * r562661512f 10openembedded.git/recipes/python/python-numpy_1.1.1.bb: (log message trimmed) May 17 23:08:04 python-numpy: add missing runtime dependencies May 17 23:08:04 Without these runtime dependencies there are errors on the target when executing `mypaint`, because `python-numpy` code calls `import` from the distinct packages. May 17 23:08:14 03Christian Charreyre  07master * r29e70a3033 10openembedded.git/recipes/mypaint/ (files/scons-adapt.patch mypaint_0.9.1.bb): (log message trimmed) May 17 23:08:14 mypaint: Add version 0.9.1 (initial recipe) May 17 23:08:14 This version is build tested using `angstrom-2008.1`, `angstrom-2010.x` and `minimal{,-uclibc}` and run tested using `angstrom-2008.1` each time for `MACHINE = "beagleboard"`. May 17 23:11:19 khem: pong May 17 23:16:07 kergoth: FILESPATHPKG is not there in oe-core May 17 23:16:17 kergoth: as you did it originally May 17 23:16:33 would you mind proposing it to oe-core May 17 23:16:33 yeah, i know, they still use base_set_filespath :\ May 17 23:16:38 sure May 17 23:16:59 it would ease porting recipes from oe into various layers May 17 23:17:01 i do think we need to handel the common case a bit better in some way, for filespathpkg though May 17 23:17:12 the common case isn't to prepend or append, its to shove it in the middle :) May 17 23:17:20 which makes me think we need another variable, or something May 17 23:17:30 would be best if recipes didn't have to override the pkg var entirely the way they do May 17 23:17:33 (some) May 17 23:17:51 anyway, as is is definitely an improvement over the base_set_filespath crap May 17 23:17:54 can improve from there May 17 23:17:55 FOO_sandwichspread = ... :) May 17 23:18:05 hehe May 17 23:18:09 it would be nice if we had real lists May 17 23:18:26 foo[2:2] = [this, that] May 17 23:18:27 ;) May 17 23:19:01 kergoth: why in middle May 17 23:19:39 khem: most of the time waht you want to do is add something more specific than 'files', and '.', but less specific than, say ${P} or ${PF} May 17 23:20:05 course, if we trim down the filespath as was discussed on the lists, we could sidestep the issue May 17 23:20:16 kergoth: oh like overrides May 17 23:20:38 order of evaluation May 17 23:22:24 kergoth: another thing is that today I updated bitbake snapshot May 17 23:22:35 and its considerably slower in preparing runqueue May 17 23:22:45 bisect? :) May 17 23:22:50 haven't touched that code in quite some time May 17 23:25:32 yeah i like to whine more May 17 23:25:36 got other stuff May 17 23:26:30 hehe May 17 23:26:35 khem: fwiw angstrom May 17 23:26:48 KERNEL_MODULES and DISTRO_KERNEL_MODULES seem dead vars May 17 23:27:22 (only in task-openprotium and obsolete nylon) May 17 23:28:43 just check in your rootfs May 17 23:29:36 ant__: is it with oe-core May 17 23:29:44 no, classic May 17 23:37:07 hm.. it looks like I only have the modules listed in task-base May 17 23:39:33 and the ones added as 'module_autoload_' are missing **** ENDING LOGGING AT Wed May 18 02:59:57 2011