**** BEGIN LOGGING AT Thu Jan 14 02:59:57 2010 Jan 14 07:54:21 anyone here Jan 14 07:55:12 ?? Jan 14 08:02:11 good morning Jan 14 08:30:39 Morning all ! Jan 14 08:34:26 noglitch: gm Jan 14 08:37:53 03Khem Raj  07org.openembedded.dev * r0776baa885 10openembedded.git/recipes/uclibc/uclibc-nptl/uClibc.distro: Jan 14 08:37:53 uclibc-nptl/uClibc.distro: Enable stubs for libnsl and libresolv Jan 14 08:37:53 * This furthers native-sdk-image compilation on uclibc nptl. Jan 14 08:37:53 Signed-off-by: Khem Raj Jan 14 08:37:55 03Khem Raj  07org.openembedded.dev * ra82e402892 10openembedded.git/recipes/gcc/gcc-4.4.1/ (139 files in 4 dirs): Jan 14 08:37:59 gcc-4.4.1: Delete unused patches. Jan 14 08:38:01 Signed-off-by: Khem Raj Jan 14 09:22:17 morning all Jan 14 09:22:29 RP: moin Jan 14 09:22:50 RP: btw is there something you want to finish before new bitbake 1.8 release? Jan 14 09:23:23 RP: with new release in sanity check, I'll try to ping SRCPV on list again.. Jan 14 09:29:15 JaMa: I was hoping to move on to bitbake 1.10 Jan 14 09:29:21 JaMa: but its not ready yet :( Jan 14 09:30:48 RP: ah OK.. I'm just hoping to merge srcpv branch before stable/2010 is created :/ Jan 14 09:41:56 can smeone tell me the best way to learn oe Jan 14 09:42:18 i have an overo Jan 14 09:49:55 JaMa: Did we have everything that was needed for srcpv in bitbake 1.8 in git? Jan 14 09:53:01 morning Jan 14 09:53:33 hrw: gm Jan 14 09:55:04 RP: LOCALCOUNT is only in master and git fetcher improvement is backported only to 1.10 Jan 14 09:56:56 JaMa: stable/2010 first has to be decided on create it or not and also when to create it Jan 14 09:57:08 mckoan: how goes at91sam9263ek work? Jan 14 09:58:08 hrw: ok then maybe I should hope to get it merged before stable/2011 too :) Jan 14 09:59:59 actually it's a bit difficult to keep track with oe.dev in srcpv branch.. so maybe I'll have to create new one or recheck all older changes when merge will be possible :/ Jan 14 10:05:24 JaMa: ok, so more work is needed :/ Jan 14 10:06:38 RP: I can backport it to 1.10 and 1.8 if you want (actually iirc I sent it first for 1.8 so I have that patch somewhere..) Jan 14 10:15:19 JaMa: I'm not worried about that atm Jan 14 10:15:30 JaMa: More worried about 1.10 not being ready :/ Jan 14 10:16:14 RP: oki, I'll wait.. thanks Jan 14 10:17:17 hrw: xtscal work is intermittent due to other activities Jan 14 10:17:44 hrw: each time I open vi phone rings Jan 14 10:18:01 hrw: now I try using emacs :-D Jan 14 10:18:04 ;) Jan 14 10:23:19 mckoan: Oh what do you intend to change in xtscal? I have made some changes as well... Jan 14 10:24:27 Maemo 5 51.1 uses bootsplash which looks like psplash ;D Jan 14 10:29:04 hrw: is it easier to configure than psplash Jan 14 10:31:56 ? Jan 14 10:32:33 no idea Jan 14 10:36:28 florian: xtscal doesn't work with at91sam9263ek and ronetix-pm9263 for example Jan 14 10:37:46 florian: bsically it was used to work with xserver-kdrive but no longer with xserver-xorg Jan 14 10:49:00 03Koen Kooi  07org.openembedded.dev * r91bb5a44bf 10openembedded.git/recipes/tasks/angstrom-task-gnome.bb: angstrom-task-gnome: fix thinko with XSERVER Jan 14 10:49:01 03Koen Kooi  07org.openembedded.dev * r0e587fdead 10openembedded.git/recipes/fltk/fltk_1.1.10.bb: fltk: fix build by defining XFT_MAJOR Jan 14 10:49:02 03Koen Kooi  07org.openembedded.dev * rdb227d6183 10openembedded.git/recipes/images/angstrom-gnome-image.bb: angstrom-GNOME-image: add image that gives you gdm + gnome desktop Jan 14 10:49:04 03Koen Kooi  07org.openembedded.dev * r2a8420f21b 10openembedded.git/ (conf/checksums.ini recipes/giac/giac_0.8.4.bb): giac: add 0.8.4 Jan 14 10:49:16 03Koen Kooi  07org.openembedded.dev * r9e01279160 10openembedded.git/recipes/images/angstrom-x-image.bb: angstrom-X-image: add image that has gdm + gnome + xfce + e17 selectable as login sessions Jan 14 10:55:05 mckoan: sounds like i should try this here too. I remember some problems with my git version on one device too. Jan 14 10:55:55 mckoan: I have the sources with all my changes in the "tools" repo at git.labs.kernelconcepts.de. Jan 14 11:07:19 Is it possible to hook updatercd_postinst ? Jan 14 11:33:27 hi all Jan 14 11:34:46 hi pb_ Jan 14 12:58:45 Hi, I try to make opencpn code work on beagleboard. There are some double word alignment problems. I have solved some of them but there are more. As I have tested it doesn't matter word alignment but double word. When this happens program freezes. There is no exception. Jan 14 12:59:13 Is there a way to make Linux handle this stuation? Jan 14 12:59:32 I mean any library or kernel? Jan 14 13:26:58 | Exception occured while printing exception (java/lang/OutOfMemoryError)... Jan 14 13:26:58 ;D Jan 14 13:39:03 heh Jan 14 13:39:11 what are you doing with these crazy languages? Jan 14 13:39:34 use C++, or Vala, or Python Jan 14 13:39:38 :) Jan 14 13:40:33 mickeyl: Don't point people using crazy languages to C++... they _will_ start to do crazy things! Jan 14 13:41:11 hehehe Jan 14 13:41:17 true Jan 14 13:41:36 this recommendation was just added because i know he's familiar with it Jan 14 13:42:02 heh Jan 14 13:42:24 I dunno, I am almost starting to like java nowadays. Jan 14 13:42:26 * pb_ shoots self in head Jan 14 13:43:03 In contract to C++ its a language with a design concept :) Jan 14 13:43:07 uh oh Jan 14 13:43:08 eh contrast Jan 14 13:43:23 mickeyl: have you ever used scala? Jan 14 13:43:29 pb_: never heard about that one Jan 14 13:43:36 * florian admires the crashed board on his desk... Jan 14 13:44:16 interesting! Jan 14 13:44:20 mickeyl: it's a java-compatible language (i.e. compiles to java bytecode and will interoperate with java classes) but sucks a little bit less in some ways. Jan 14 13:44:33 A function named "tmpa910_nand_wait_dma_complete" sounds like a misunderstanding ;) Jan 14 13:44:35 it's a little bit funky, but it does have some nice features. Jan 14 13:45:38 our previous java expert found it for me after I kept complaining about the lack of functional programming support in java. :-} Jan 14 13:46:26 heh Jan 14 13:46:51 pb_: have you used it? I was reading a bit, apparently twitter is using it for the queue management Jan 14 13:47:00 re Jan 14 13:47:02 ya, no doubt. the return of functional constructs and advanced control flow constructs are important devices these days to be able to manage complex algorithms in a readable form Jan 14 13:47:14 i think it's exciting what happens in C#, Python, and Vala Jan 14 13:47:40 zecke: some of our server software is written in scala. I have used it a bit although I find the lack of scala support in eclipse to be a bit annoying. Jan 14 13:49:08 mickeyl: yeah, indeed. Jan 14 13:49:11 mickeyl: the fun is that javavm was what failed Jan 14 13:49:21 sadly I am still spending most of my time writing objective C, but still. :-} Jan 14 13:49:37 objective C... thats crazy Jan 14 13:49:57 actually I quite like it. it's much more of a light touch object system than c++. Jan 14 13:50:32 the lack of multiple inheritance and virtual classes is slightly annoying at times, but apart from that I am pretty happy with it. Jan 14 13:51:19 I think that this is also because I started coding when c++ existed not before Jan 14 13:51:46 pb_: same here, i like it quite a lot Jan 14 13:52:00 pb_: actually there's one feature i tend to miss in lots of languages Jan 14 13:52:03 which is the named arguments Jan 14 13:52:12 [foo WithTarget:target ByName:name]; Jan 14 13:52:14 is pure poetry ;) Jan 14 13:52:39 so much more readable than foo( target, name ) Jan 14 13:52:49 yeah, absolutely Jan 14 13:52:53 although it tends to get messy when you concatenate calls Jan 14 13:54:49 pb_: yeah, objective C is fun... I looked into Etoile/GNUstep and I'm overwhelmed with the choice of runtimes Jan 14 14:21:12 03Koen Kooi  07org.openembedded.dev * rc7fea056f9 10openembedded.git/ (conf/checksums.ini recipes/sdr/hamlib_1.2.10.bb): hamlib: update to 1.2.10 Jan 14 14:21:23 03Koen Kooi  07org.openembedded.dev * r2b835db69e 10openembedded.git/recipes/udev/ (udev-141/cache udev-141/init udev_141.bb): Jan 14 14:21:23 udev 141: move creation of /etc/dev.tar to after checkroot Jan 14 14:21:23 * / isn't always mounted rw when udev runs, so lets create /etc/dev.tar after checkroot has run Jan 14 14:21:23 Acked-by: Graeme Gregory Jan 14 14:21:24 Acked-by: Marcin Juszkiewicz Jan 14 14:21:42 sound good Jan 14 14:39:00 morning Jan 14 14:39:09 After upgrading the kernel the modules are not being found because of the new version number. What recipe is creating the /lib/modules/2.6.25.20 directory? Jan 14 14:39:58 hi kergoth Jan 14 14:40:05 hey RP Jan 14 14:47:50 jovox: any with kernel module Jan 14 14:49:57 ok, so somewhere I need to tell what version of kernel I'm using? Jan 14 14:53:47 ${KERNEL_VERSION}, right? Jan 14 14:58:26 When I switched to a different kernel, all I did was to add DEFAULT_PREFERENCE_x86 = "1" to the linux_2.6.29.bb Jan 14 14:59:43 * kergoth reviews the mvl6 relocation fixups Jan 14 15:00:41 Laibsch: hi, do you remember when I asked how conditionally use ie inherit? pb_ pointed me to using inherit ${INHERIT}, then you said that you have also an idea, what did you think? Jan 14 15:01:28 Laibsch: usage of that variable had flaw, that you had to use one or another inherit, but cannot deal with no inherit at all case Jan 14 15:05:44 kergoth: Thinking of pushing to OE? Jan 14 15:06:02 yeah. some are .. not ideal .. though :) wrapper scripts and the like Jan 14 15:06:14 morning kergoth Jan 14 15:06:24 kergoth: I'd be interested to see the series Jan 14 15:06:34 i'll see about cleaning it up Jan 14 15:08:10 I don't see where KERNEL_VERSION is being set really Jan 14 15:08:46 jovox: kernel.bbclass, generally Jan 14 15:10:11 JaMa|W: What was the condition again? Jan 14 15:10:24 or maybe I should call it the conditional Jan 14 15:10:31 pb_, KERNEL_VERSION = "${@get_kernelversion('${S}')}" Jan 14 15:10:37 indeed Jan 14 15:11:04 I find this a little confusing :/ Jan 14 15:11:41 could be a result of four days drinking beer in Berlin Jan 14 15:11:59 can you expand on why you are confused at all? Jan 14 15:12:33 Laibsch: override for distro or machine Jan 14 15:14:17 Laibsch: what pb proposed I used in gpe-icons.inc, but I pushed too soon and then found out that its not optimal for gpe-theme-neo_git.bb Jan 14 15:14:34 mom Jan 14 15:15:02 pb_, well, I still don't really understand where the kernel version number is specified in the first place. To me it looks like kernel.bbclass reads out the version from somewhere else. Jan 14 15:15:11 Laibsch: ok.. I'll read it later.. now going home.. thanks .. Jan 14 15:15:43 jovox: kernel recipe is named linux_2.6.29.bb? so kernel_Version is 2.6.29 Jan 14 15:16:02 jovox: that's correct. KERNEL_VERSION is set based on the kernel that has been built; it doesn't control the selection of which kernel should be built. Jan 14 15:16:36 if you are trying to influence the version of the kernel that you get in your image, KERNEL_VERSION is not the variable that you want. Jan 14 15:18:16 JaMa|W: I'd try adapting something with base_conditional: http://paste.debian.net/56660/ Not sure how that would work in the case of "inherit nothing", but I'm confident that it would present a workable route Jan 14 15:19:32 thinking of it, http://paste.debian.net/56660/ could probably be rewritten more easily as DEPENDS_om-gta02 ;-) Jan 14 15:19:58 But I remember using it locally in other situations where overrides don't apply (like inherit) Jan 14 15:20:27 pb_ right. It's already building the version of the kernel I want. 2.6.29 that is. I made it build this kernel by adding DEFAULT_PREFERENCE_x86 = "1" to the linux_2.6.29.bb. But the problem now is that it still creates the "old" /lib/modules/2.6.25.20 Jan 14 15:25:49 jovox: where exactly does that directory get created? Jan 14 15:26:48 you mean from which recipe? Jan 14 15:28:05 I don't know who's creating it, but it appears in my image Jan 14 15:28:12 well, which package is it in? Jan 14 15:29:37 I don't know. I did a 'opkg search' on the files in /lib/modules/2.6.25.20 without finding any package Jan 14 15:30:01 check your log.do_rootfs to see which packages are actually getting installed into the rootfs Jan 14 15:30:09 then, check those .ipk files to see which one contains the offending directory Jan 14 15:32:21 Ok, will do Jan 14 15:32:44 03Rolf Leggewie  07org.openembedded.dev * r736f5ea176 10openembedded.git/conf/distro/minimal.conf: conf/distro/minimal.conf: minimal should have a generic OE splash Jan 14 15:32:51 03Rolf Leggewie  07org.openembedded.dev * r2e3f7f9726 10openembedded.git/ (4 files in 2 dirs): Jan 14 15:32:51 images: set SPLASH to "" as sane default Jan 14 15:32:51 Acked-By: Michael 'Mickey' Lauer Jan 14 15:32:51 Acked-by: Koen Kooi Jan 14 15:32:54 03Rolf Leggewie  07org.openembedded.dev * r80e40b8633 10openembedded.git/ (7 files in 2 dirs): qpf-fonts: move SRC_URI from ewi to Openzaurus mirror. Partly closes #5295 Jan 14 15:38:53 pb_, I searched through the recipes and found ti/ti-cmem-module_2.23.bb for example. It uses "/lib/modules/${KERNEL_VERSION}" and I'm sure there are many more Jan 14 15:40:34 pb_ my point it that it's being used from many places and modules will be installed in the wrong dir because KERNEL_VERSION is incorrect. I.e KERNEL_VERSION it probably still 2.6.25.20 even though the kernel that is being built is 2.6.29 Jan 14 15:40:54 jovox: how do you reach that conclusion? Jan 14 15:42:02 pb_, because there is no /lib/modules/2.6.29 Jan 14 15:42:09 But I might be wrong.. Jan 14 15:42:16 saying that KERNEL_VERSION is "probably" still 2.6.25.20 is not very illuminating. I think you need to verify what it actually is. Jan 14 15:42:28 did you perform the check that I suggested above? Jan 14 15:42:43 pb_ I'm still seaching for the log Jan 14 15:43:05 searching Jan 14 15:43:09 righto Jan 14 15:44:09 why not just use bitbake -e to inspect the value of it? Jan 14 15:45:41 kergoth, All I get out from that is "2.6" Jan 14 15:47:00 you're definitely looking at KERNEL_VERSION, not MACHINE_KERNEL_VERSION? Jan 14 15:47:27 pb I was looking at MACHINE_KERNEL_VERSION Jan 14 15:47:29 Laibsch: I have noticed your commit got a wrong URL: Jan 14 15:47:38 oh Jan 14 15:47:44 URL: http://gitweb.openembedded.net/?p=openembedded.git&a=commit;h=2e3f7f97267390bd0c70a41a9f58948f860bc66b Jan 14 15:47:44 did it? Jan 14 15:47:44 gm Jan 14 15:47:49 should be Jan 14 15:47:50 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=2e3f7f97267390bd0c70a41a9f58948f860bc66b Jan 14 15:47:57 s/gitweb/cgit/ Jan 14 15:48:12 s/net/org/ Jan 14 15:48:20 commit? Jan 14 15:48:33 I think it's CIA Jan 14 15:48:34 khem: good morning Jan 14 15:48:46 ftp://symstore.longisland.com/Symstore/services_download/wirless_prod//MC&DriverOnlyInstallers.zip bitbake is timing while downloading it Jan 14 15:48:47 ant_work: I'm not sure I'm following you Jan 14 15:49:02 see the mailing list Jan 14 15:49:13 look for your SPLASH commit Jan 14 15:49:18 try to open the link Jan 14 15:49:44 pb_ I don't see the KERNEL_VERSION in there at all Jan 14 15:49:47 I guess that would be an error of the mailing list hooks Jan 14 15:49:56 I see Jan 14 15:50:00 and that would then probably be incorrect for all mails Jan 14 15:50:10 I think mickey would be the one to talk to, then Jan 14 15:50:18 I'm not reading -commit Jan 14 15:50:18 it is, 404 Jan 14 15:50:45 yeah, that is nothing to do with laibsch personally. you need to take it up with the git administrators. Jan 14 15:51:04 wow Jan 14 15:51:12 I did bother Laibsch because he has better idea who is administering which server Jan 14 15:51:19 sure Jan 14 15:51:21 no problem Jan 14 15:51:34 it's always appreciated when people point out problems Jan 14 15:51:36 i think cbrake did not yet implement the redirect i had @ amethyst Jan 14 15:51:59 mickeyl: In fact, I remember now that we disabled that redirect Jan 14 15:52:12 IIRC it wasn't going to the right place Jan 14 15:52:22 and neither cbrake nor I felt like fixing it ;-) Jan 14 15:52:25 Let 's see Jan 14 15:52:26 heh, well Jan 14 15:52:52 It would certainly be easier to change the git hook Jan 14 15:53:03 but if gitweb's still been used Jan 14 15:53:04 ... Jan 14 15:53:58 no, it's cgit Jan 14 15:54:10 As far as I can see there is no KERNEL_VERSION being outputed from bitbake -e Jan 14 15:54:19 ant_work: voila, your URL is working again Jan 14 15:54:36 * Laibsch now wonders why cbrake and I decided to disable the vhost Jan 14 15:54:36 thx ;) Jan 14 15:59:33 jovox: there is for me; I guess you would need to debug why that isn't working for you. see: Jan 14 15:59:34 pb@mill:/srv/mill/pb/oe/build-qemuarm$ bitbake -e -b ~/oe/org.openembedded.dev/recipes/linux/linux_2.6.29.bb |grep ^KERNEL_VERSION Jan 14 15:59:34 KERNEL_VERSION="2.6.29.6" Jan 14 16:04:31 pb_, you're right. That prints 2.6.29 Jan 14 16:06:42 gr Jan 14 16:09:01 I'm wondering what would be the correct procedure to validate a patch Jan 14 16:09:21 for example I see a good patch in patchwork Jan 14 16:09:40 How ould I activate it in the repo? Jan 14 16:09:53 Do I have to test it before? Jan 14 16:10:43 How you do this kind of task? Jan 14 16:10:44 mckoan, apply the patch from patchwork and test as best you can Jan 14 16:10:53 especially if it has acks Jan 14 16:11:10 Crofton|work: thx, and after that? suppose it was ok Jan 14 16:11:11 pb_: about kernel versions and comparing those ...base_less_or_equal uses the 'simple' vercmp and fails Jan 14 16:11:13 good patches can be downlaoded from pw and applied via git am Jan 14 16:11:25 you have commit access ritght? Jan 14 16:11:34 Crofton|work: yes Jan 14 16:11:37 I made RP aware, now I'd try with kergoth and mickey... Jan 14 16:11:42 so push it Jan 14 16:12:03 I'm assuming it fixes something you are experincing? Jan 14 16:12:48 Crofton|work: I never tried pushing third parties patches, if I push it, does it maintain the proper and original signed-off-by name? Jan 14 16:13:06 if you dl from pw and apply it via git am Jan 14 16:13:09 try it :) Jan 14 16:13:25 if the patch is well done, eveything just works Jan 14 16:13:31 Crofton|work: ok, I have to learn git am Jan 14 16:13:36 yeah Jan 14 16:13:46 once you try it, you will be happy Jan 14 16:14:03 I think downloading the patch in mbox format works best Jan 14 16:16:04 mckoan: you don't need to.. use contrib/patchwork/pw-am.sh instead :) Jan 14 16:16:17 pb_ I am a complete idiot! sorry for taking up your time... I have been looking at the incorrect image :-( Jan 14 16:16:20 * jovox hides Jan 14 16:17:07 I forgot about that Jan 14 16:17:21 but he should go through the process once to make sure he understands it :) Jan 14 16:21:06 Crofton|work, JaMa|W : I appreciate both of your hints :-) Jan 14 16:22:25 also, make suer you change the aptch state in pw after you push it Jan 14 16:25:03 Crofton|work: looks like I've lost my patchwork password Jan 14 16:26:06 * mckoan wonders if exist a "send me my password" in patchwork system Jan 14 16:26:14 I don't think so Jan 14 16:26:45 Crofton|work: I can't create a new account because my email account is altready used Jan 14 16:27:04 try again Jan 14 16:27:08 I deleleted it Jan 14 16:27:34 pw is really handy, but the management interface sucks Jan 14 16:27:54 Crofton|work: This email address is already in use. Please supply a different email address. Jan 14 16:28:38 it may be a cachhing issue? Jan 14 16:28:53 in the meantime, just keep notes of what you apply Jan 14 16:28:58 and I can mark the patches later Jan 14 16:29:46 Crofton|work: I reloaded firefox Jan 14 16:29:49 same problem Jan 14 16:30:03 Crofton|work: BTW my email was m.cavallini... Jan 14 16:30:16 ok Jan 14 16:30:23 I'll look again later today Jan 14 16:30:28 lunch soon :) Jan 14 16:31:28 Crofton|work: thank you very much Jan 14 16:32:09 can somebody from the top of their head quickly name me a machine that does not have screen in MACHINE_FEATURES? Jan 14 16:33:46 ngw100 maybe Jan 14 16:34:11 atngw100 for sure even Jan 14 16:34:18 right Jan 14 16:34:57 mpc8323e-rdb wrap wrt54 wl500g stb225 Jan 14 16:35:09 grep MACHINE_FEATURES conf/machine/*|grep -v screen Jan 14 16:37:51 thanks, hrw and florian Jan 14 16:38:21 hrw: That grep fails when MACHINE_FEATURES has multiple lines :-p Jan 14 16:39:26 Laibsch: sure, but helps anywya Jan 14 16:40:27 yes Jan 14 16:46:26 03Michael 'Mickey' Lauer  07org.openembedded.dev * rbc68ed7c92 10openembedded.git/ (3 files in 2 dirs): Jan 14 16:46:26 serial-forward: catch up with conversion to autotools Jan 14 16:46:26 pty-forward-native: dito Jan 14 17:12:57 I have problems building webkit-gtk from latest git: http://oe.pastebin.ca/index.php Jan 14 17:13:57 oops wrong pastebin..: http://oe.pastebin.ca/1751185 Jan 14 17:22:42 have a nice rest of the day Jan 14 17:31:59 bye Jan 14 17:36:39 can anyone help me with the webkit issue? Jan 14 17:36:58 when it's something with autotools I always get depressed Jan 14 17:37:17 if autotools had a color it would be very dark gray Jan 14 17:38:06 th1, there is a pdf for understanding autotools basics Jan 14 17:38:25 I understand the basics but there is something of the night about them Jan 14 17:38:41 03Holger Hans Peter Freyther  07org.openembedded.dev * rad3f7776e7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs.inc: Build more recent versions of qtwebkit-performance-utilities Jan 14 17:38:42 03Holger Hans Peter Freyther  07org.openembedded.dev * re0ce766db2 10openembedded.git/recipes/webkit/qtwebkit-performance-utilities.inc: Jan 14 17:38:42 qtwebkit-performance-utilities.inc: Use += to not undo qt4e Jan 14 17:38:42 Append to the extra qmake variables instead of assigning it. This Jan 14 17:38:44 means that the original qt4e extra variables will be passed to qmake Jan 14 17:38:46 it helps if you look into m4 directly, in my opinion Jan 14 17:38:46 and we will link to the QtE libraries again. Jan 14 17:38:48 03Holger Hans Peter Freyther  07org.openembedded.dev * r3b6c02e986 10openembedded.git/recipes/memusagestat/memusagestat_2.11.bb: Jan 14 17:38:51 memusagestat_2.11.bb: Add memusagestat Jan 14 17:38:53 This is a small tool that can turn the memory trace of glibc Jan 14 17:38:54 and then poke at the default macros Jan 14 17:38:55 into a nice graph. Jan 14 17:38:57 03Holger Hans Peter Freyther  07org.openembedded.dev * r88f4d12d2c 10openembedded.git/recipes/webkit/qtwebkit-performance-utilities.inc: Jan 14 17:38:58 get a feel for what underlies it all Jan 14 17:39:00 qtwebkit-performance-utilities.inc: Remove memusagestat from the build Jan 14 17:39:02 * It is bad to require either Qt/X11 or Qt/E to just build Jan 14 17:39:04 this small helper. A new recipe should be created instead. Jan 14 17:39:06 03Holger Hans Peter Freyther  07org.openembedded.dev * r08fe78fa32 10openembedded.git/classes/qmake_base.bbclass: (log message trimmed) Jan 14 17:39:34 qmake_base.bbclass: Unexport STRIP from the environment Jan 14 17:39:34 The Makefile's generated by Qt are using this variable and the Jan 14 17:39:34 assignment of STRIP = $(OE_QMAKE_STRIP) will be overturned by Jan 14 17:39:34 this export. One option would be to set STRIP = $OE_QMAKE_STRIP Jan 14 17:39:35 in the bb file but this would break striping in package.bbclass. Jan 14 17:39:37 With the unset STRIP we are able to generate proper -dbg packages Jan 14 17:39:43 th1, http://www.lrde.epita.fr/~adl/autotools.html Jan 14 17:40:23 kergoth, you're right and I have done that many years ago, but it seems that the worst breakages are always from autotools because there are so many layers of substitutions and redirections that when something breaks it's very hard to get that overview of *why* it broke Jan 14 17:40:50 in my case with webkit I was just hoping someone else had had the same problem :) Jan 14 17:40:55 heh, true. it doesn't help that the people making the configure.in/ac scripts don't understand the stuff Jan 14 17:41:08 i know the autotools stuff, and even i can still get bitten by quoting issues Jan 14 17:41:09 * kergoth shudders Jan 14 17:41:16 :) Jan 14 17:41:51 GNUtoo|oeee, thanks I'll have a read through that ASAP Jan 14 17:41:56 ok Jan 14 17:42:58 in the pase I already spent several full days against some autotools breakage Jan 14 17:43:02 *past Jan 14 17:43:34 GNUtoo|oeee, 557 slides :) Jan 14 17:43:39 I guess my point is made Jan 14 17:44:24 it's great when it works though .. and it does in 95% of the cases.. but the last 5% are killers Jan 14 17:44:28 th1, the slides are individualy very quick to read Jan 14 17:44:59 ah they're "animated" there's really only 162 Jan 14 17:45:10 I will certainly read it, because it looks quite well done Jan 14 17:47:26 jovox: ah, heh Jan 14 17:54:40 03Koen Kooi  07org.openembedded.dev * r5afc7e0e86 10openembedded.git/recipes/linux/linux-omap-zoomsync/omapzoom2/defconfig: linux-omap-zoom-sync 2.6.31: Turn on wifi and bt usb drivers Jan 14 18:03:27 th1: I think, that it's easy :) Just disable that line with ENABLE_ORIENTATION_EVENTS Jan 14 18:03:37 re Jan 14 18:03:48 th1: it's not defined in that file anyway, so it can't work... Jan 14 18:09:43 compiling for atngw100 results in some ugly parse errors Jan 14 18:33:14 03Rolf Leggewie  07org.openembedded.dev * r7ae59ed4b9 10openembedded.git/conf/distro/minimal.conf: conf/distro/minimal.conf: don't set SPLASH for headless machines Jan 14 18:33:53 ynezz, then why is it there in the OE git :) Jan 14 18:34:07 it must have worked for someone Jan 14 18:42:57 03Graham Gower  07org.openembedded.dev * re426517ed7 10openembedded.git/ (3 files in 2 dirs): (log message trimmed) Jan 14 18:42:57 e2fsprogs: add 1.41.9 Jan 14 18:42:57 FYI, here is the patch that was submitted upstream: Jan 14 18:42:57 http://sourceforge.net/tracker/?func=detail&aid=2813809&group_id=2406&atid=302406 Jan 14 18:42:57 The issue with 1.41.5 went away for me when I installed 32bit compatibility Jan 14 18:42:59 libs on my pure 64 bit system. Jan 14 18:43:03 -Graham Jan 14 18:43:06 03Koen Kooi  07org.openembedded.dev * r733b7de550 10openembedded.git/recipes/mplayer/ (files/fix-addrinfo.patch files/fix-exp.diff mplayer_svn.bb): mplayer svn: add patch for addr_info, add some metadata to exp patch) Jan 14 18:52:05 I get the message "request_module: runaway loop modprobe binfmt-fe6f" when booting. It's being printed five times and then it hangs. Any suggestions what that could be?`I have googled and got some hits about kernel being compiled for 32bit and the rest 64bit which moste likely isn't the case.. Jan 14 19:00:38 * kergoth ponders Jan 14 19:03:05 th1: does ENABLE_ORIENTATION_CONDITIONALS, in fact, appear in an AM_CONDITIONAL()? Jan 14 19:03:10 it should be in configure.ac somewhere Jan 14 19:03:24 er, sorry, ENABLE_ORIENTATION_EVENTS Jan 14 19:03:35 likewise for the MATHML thing Jan 14 19:05:08 I'm not quite sure what point ynezz was trying to make about it not being defined, but removing the conditional doesn't seem like the right answer. Jan 14 19:06:22 anyone happen to know if the DISTRO_FEATURES and MACHINE_FEATURES values are documented anywhere? Jan 14 19:06:27 if not, we should really do so Jan 14 19:06:49 No, and really should Jan 14 19:07:52 kergoth: no, they're not; and yes, we should Jan 14 19:08:07 i wonder where the best place would be. Jan 14 19:08:09 re Jan 14 19:08:13 ideally we'd not let it get out of sync Jan 14 19:08:16 dunno. wiki somewhere? Jan 14 19:08:41 aside: we could really use the ability to define multi-line variables without function syntax Jan 14 19:09:34 yeah Jan 14 19:10:22 could shove it into the doc flag with that.. course then we'd have to actually use the doc flag for something :) Jan 14 19:18:39 another possibility would be to avoid the flag and do some sort of doxygen-like comment based documentation of variables and functions.. hmm Jan 14 19:19:00 wiki will for now of course :) Jan 14 19:19:05 erm, will do Jan 14 19:39:19 Laibsch: the opie-taskbar issue seems to be narrowing down to binutils/ld Jan 14 19:40:23 btw. we use -mthumb -mno-thumb freely and gcc 2.95 does not know about these options Jan 14 19:40:49 I wish we had a better way of handling this Jan 14 19:41:26 may be a check by invoking the cross compiler to see if a given option we are interested in is supported to begin with or not Jan 14 19:45:02 03Frans Meulenbroeks  07org.openembedded.dev * r3fd04f71ad 10openembedded.git/: Jan 14 19:45:02 Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Jan 14 19:45:02 Conflicts: Jan 14 19:45:02 recipes/linux/linux-kirkwood_2.6.33-rc1.bb Jan 14 19:45:12 03Frans Meulenbroeks  07org.openembedded.dev * rc2fbdf2d3a 10openembedded.git/recipes/linux/linux-kirkwood_2.6.33-rc1.bb: linux-kirkwood_2.6.33-rc1: fix SRC_URI typo Jan 14 19:45:13 03Frans Meulenbroeks  07org.openembedded.dev * rb5b3d83a6f 10openembedded.git/ (5 files in 5 dirs): Jan 14 19:45:13 linux-kirkwood_2.6.33-rc1.bb: added patch for SD and uart support Jan 14 19:45:13 added a lot of modules to openrd client Jan 14 19:45:15 added a change in openrd-base defconfig for SD Jan 14 19:45:26 hi! can somebody help me one problem? I try build x11-image and on last stages I get "Cannot find package locale-base-de-de." but I have set ENABLE_BINARY_LOCALE_GENERATION = "0". What is this? Jan 14 19:52:57 alexondi, what distro? what image? Jan 14 19:53:06 ah ok x11-image sorry Jan 14 19:54:30 distro - is mine (linux) Jan 14 19:56:31 ah you're making your own oe distro? Jan 14 19:56:44 anyway look into the place where the ipk are Jan 14 19:56:46 yes :) Jan 14 19:57:03 and look at the *-de-de Jan 14 19:57:05 files Jan 14 19:57:45 and if it's like SHR-image look if there is a python script in your image Jan 14 19:57:49 .bb file Jan 14 19:57:57 then modify the locales thing accordinly Jan 14 19:58:46 that error sounds like you are trying to install the -de locale in your image, but you have selected locale generation to off. depending on what you are trying to achieve, you need to either remove de from the set of locales to install, or enable the generation of the appropriate packages. Jan 14 20:02:42 but I set ENABLE_BINARY_LOCALE_GENERATION = "0" in my local.conf. This don't disable generation locales? Jan 14 20:10:23 khem: Thank you for sharing your findings. Jan 14 20:10:50 What can be done about opie-taskbar, then? Jan 14 20:11:12 Is the binutils/ld in OE too new for opie-taskbar? Jan 14 20:11:21 I guess we could get bluelightning to change that Jan 14 20:11:37 on the thumb topic Jan 14 20:12:05 Would it be possible to only conditionally activate that? Jan 14 20:17:40 any opinion on making alsa-utils rdep on the alsa-utils-* packages? Jan 14 20:33:29 Laibsch: regarding opie-taskbar, the problem cropped up in binutils 2.20 Jan 14 20:34:27 I have to dig more as its not in opie-taskbar but it happens when libqpe-opie is linked Jan 14 20:34:54 Laibsch: I also verified that the issue is still there on binutils cvs trunk Jan 14 20:35:38 Laibsch: for now let woglinde's workaround be in there Jan 14 20:35:52 I will try to delve into binutils and see whats wrong Jan 14 20:36:23 sure Jan 14 20:36:36 for the moment I'm more than happy with woglinde's hack Jan 14 20:36:41 thumb issue, I dont know Jan 14 20:36:48 You think it's actually a binutils bug? Jan 14 20:36:59 2.95 support is still far fetched in current times IMHO Jan 14 20:37:17 Laibsch: yes I think its ld issue until now Jan 14 20:37:25 OK Jan 14 20:37:32 thank you for investigating Jan 14 20:37:44 I'll update the bug report Jan 14 20:37:44 unless I find something contrary Jan 14 20:37:51 regarding thumb Jan 14 20:37:58 Is that a configure option or what is it? Jan 14 20:38:11 or a flag for gcc Jan 14 20:38:19 I don't quite understand Jan 14 20:38:24 Laibsch: yes its a flag to gcc Jan 14 20:38:40 would it be possible to strip out just for sharprom? Jan 14 20:38:53 IOW, don't issue that flag when building sharprom? Jan 14 20:39:05 I know we have +=, but not -= Jan 14 20:39:06 possibly I havent looked into it though yet Jan 14 20:39:26 OK Jan 14 20:39:29 thanks for the update Jan 14 20:39:42 where is the call to gcc assembled? Jan 14 20:39:52 IOW, where to look? Jan 14 20:41:22 grep -r "mno-thumb" * in conf/ dir Jan 14 20:41:41 er Jan 14 20:41:50 it should be a matter of setting the variables right in the distro conf Jan 14 20:42:00 machine/include/tune-thumb.inc or so has it Jan 14 20:42:03 afk a few Jan 14 20:42:55 actually it tune-thumb should not be included on machines which dont have thumb support Jan 14 20:44:02 Laibsch: whats machine conf used for sharprom Jan 14 20:44:36 but at the distro policy level you can say no thumb or yes thumb Jan 14 20:44:47 (ok, now afk i think) Jan 14 20:44:56 Tartarus: how Jan 14 20:45:05 read the conf file, it's got the variables Jan 14 20:45:10 distro could not force features that machines dont support Jan 14 20:45:17 khem, yes Jan 14 20:45:17 that wud be wrong Jan 14 20:45:19 khem: I build for qemuarm, om-gta02, spitz and collie. qemuarm being kind of "the default" Jan 14 20:45:36 khem, it's both really Jan 14 20:45:44 if the distro does not ever want thumb, it needs to set it Jan 14 20:45:54 and the machine says if it will do it Jan 14 20:46:02 one way could be that distro has machine specific overrides Jan 14 20:46:12 that way distro has leg up Jan 14 20:46:28 but then whats the use of machine confs Jan 14 20:46:31 for exampe Jan 14 20:46:34 angstrom sets thumb stuff Jan 14 20:46:57 yeah does it care for machines before deciding Jan 14 20:47:04 in the code Jan 14 20:47:42 Laibsch: I am interested in the distro/machine combo where gcc 2.95 is selected Jan 14 20:48:52 khem: DISTRO=sharprom-compatible Jan 14 20:49:16 for MACHINE in qemuarm collie spitz om-gta02; do ... ; done Jan 14 20:50:13 khem: Can you take a quick look at conf/distro/sharprom-compatible.conf Jan 14 20:50:18 Laibsch: I see and the toolchain used is external one ? Jan 14 20:50:19 Is there an obvious variable Jan 14 20:50:23 Yes Jan 14 20:50:30 Provided by Sharp Jan 14 20:50:37 And can't be changed AFAIK Jan 14 20:51:00 FULL_OPTIMIZATION? Jan 14 20:51:10 BUILD_CPPFLAGS? Jan 14 20:51:27 TARGET_CC_ARCH? Jan 14 20:51:34 TARGET_CC_KERNEL_ARCH and TARGET_CC_ARCH Jan 14 20:52:14 should I add -mno-thumb there and try rebuilding? Jan 14 20:53:03 no no Jan 14 20:53:10 ARM_INSTRUCTION_SET=arm Jan 14 20:53:13 THUMB_INTERWORK=no Jan 14 20:53:16 in the distro conf Jan 14 20:53:18 that wont help either Jan 14 20:53:32 because it will add -mthumb or -mno-thumb Jan 14 20:53:40 and 2.95 groks neither? Jan 14 20:53:42 khem: what do you suggest? Jan 14 20:53:43 both may be problem Jan 14 20:53:58 well, what I said is the right way to find out if we'll have a toolchain issue next :) Jan 14 20:54:04 Tartarus: mno-thumb would be introduced after -mthumb is added :) Jan 14 20:54:42 * khem groks 2.95 sources Jan 14 20:54:54 gcc 2.95 doesn't do thumb at all, does it? Jan 14 20:56:21 pb___: thats what I remember but it was such a long time ago I might have disk error in that part of brain/meory :) Jan 14 20:56:50 oh, it does have some early thumb support, but you need to select it explicitly at configure time. Jan 14 20:56:56 configure --target=thumb-elf, that kind of thing Jan 14 20:57:05 I don't think there is any support for switching ISAs dynamically. Jan 14 20:57:27 so, if that's the case, all that -mthumb -mno-thumb stuff should be harmless: you will just get ARM code all the time. Jan 14 20:57:49 that should be OK Jan 14 20:57:58 yeah Jan 14 20:57:59 All Sharps were ARM, I think Jan 14 20:58:00 pb___: right it was configure time option not runtime Jan 14 20:58:06 if you're targetting collie then arm code is what you need anyway Jan 14 20:58:14 thumb-interwork was selectable Jan 14 20:58:16 the early sharps can't run thumb at all Jan 14 20:58:27 when using gcc but not thumbness Jan 14 20:58:39 yeah, you need that off. Jan 14 20:59:06 pb___: Laibsch's problem is that build system is sending -mno-thumb to gcc Jan 14 20:59:12 and gcc 2.95 is bailing out Jan 14 20:59:13 khem: why is that a problem? Jan 14 20:59:27 oh, does gcc 2.95 object to -m switches that it doesn't understand? Jan 14 20:59:36 its not known option to the oldie :) Jan 14 20:59:39 I thought all versions of gcc would just ignore them, but maybe that is not true. Jan 14 21:00:29 pb___: no they dont ignore them Jan 14 21:00:41 unrecognized command line option is spewed Jan 14 21:00:50 ah. oh well. I don't quite understand why he should be getting -mno-thumb anyway, isn't it just tune-thumb.inc that adds that? Jan 14 21:00:59 yes Jan 14 21:01:14 qemuarm is armv5te defaulting Jan 14 21:01:21 which means it will include this tune file Jan 14 21:01:41 oh, I see, this is a qemu build. Jan 14 21:02:23 I'm not quite sure why we even do that "-mno-thumb" thing in the first place. isn't ARM-mode the default for all versions of gcc? Jan 14 21:02:35 I would have thought it would be safe to just omit that flag when arm code is wanted. Jan 14 21:03:27 If qemuarm is a problem, I could more than happily live without that machine for sharprom-compatible. Of course, I'm only really interested in collie and spitz, there. But I assume it would be the same problem, right? Jan 14 21:03:49 Laibsch: collie shouldn't have the problem. I'm not sure about spitz offhand, what cpu is that? Jan 14 21:04:04 pxa270? Jan 14 21:04:07 wildly guessing Jan 14 21:04:27 hm. that sounds unlikely, but I could believe pxa250. Jan 14 21:04:42 let me look at the configs Jan 14 21:05:17 it's sometimes best to be explicit Jan 14 21:05:20 unless that causes problems Jan 14 21:05:31 see pixman & older crap way of doing NEON Jan 14 21:05:41 oh, maybe it really is pxa270 Jan 14 21:06:04 anyway, it's some kind of xscale, and it does include tune-thumb, so it will have the same issue as qemuarm Jan 14 21:06:11 seems like I guessed right: http://forum.brighthand.com/showthread.php?t=234294 Jan 14 21:06:52 How about a conditional include of tune-thumb? Include it unless building for sharprom? Jan 14 21:06:53 yeah, spitz must be newer than I thought it was Jan 14 21:07:07 ibot, spitz/ Jan 14 21:07:09 ibot, spitz? Jan 14 21:07:10 hmm... spitz is the Sharp SL-C3000, or a dog Jan 14 21:07:17 I think the machines had quite advanced HW when they came to market Jan 14 21:07:40 ibot: true, but not as helpful as it could have been Jan 14 21:08:04 If I remove the tune-thumb include locally is the problem likely to go away? Jan 14 21:08:13 I'd be happy with that for now until a proper fix is found Jan 14 21:08:18 yeah, that should work Jan 14 21:08:32 Do I need to recompile all of tmp or just binutil? Jan 14 21:08:38 I don't intend to use the binaries Jan 14 21:08:48 spitz: Processor : XScale-PXA270 rev 4 (v5l) Jan 14 21:08:50 Right now, it's about getting things compiling again Jan 14 21:09:02 JaMa|W: wb. Are you working on fltk2? Jan 14 21:09:08 I saw something on tinderbox Jan 14 21:09:17 Laibsch: just applied Koen's patch Jan 14 21:09:41 Laibsch: but dillo fails (not really fltk related .. autoconf issues..) Jan 14 21:09:55 Laibsch: you shouldn't need to recompile anything. Jan 14 21:09:55 Laibsch: so I cannot test it properly and haven't pushed yet because of that Jan 14 21:10:03 hi, has anyone tried to build illume-image recently? Jan 14 21:10:25 03Denys Dmytriyenko  07org.openembedded.dev * r7749c8477b 10openembedded.git/recipes/mythtv/myththemes_0.22.bb: myththemes: fix parsing error from previous commit Jan 14 21:10:51 without libefso,essential-dialer and elementary-sms it builds fine Jan 14 21:10:57 ibot, no, spitz is the Sharp SL-C3000 (pxa270 cpu), or a dog. Jan 14 21:10:58 okay, pb___ Jan 14 21:11:00 but libefso never build Jan 14 21:12:01 http://pastebin.com/m2939a574 Jan 14 21:12:02 JaMa|W: koen's patch? The one he committed for fltk earlier during the day? Jan 14 21:12:05 it is very broken Jan 14 21:12:11 any objection for removing it Jan 14 21:12:20 (it lacks a lot of includes etc...) Jan 14 21:14:00 Laibsch: yes the one with XFT version is enough to compile fltk2 again.. if it works ok with dillo then I guess that both bugs can be closed Jan 14 21:14:03 AFAICS, collie does not include the thumb include file, right? Jan 14 21:14:47 JaMa|W: fltk2 currently fails to build, so you could push that changeset Jan 14 21:14:49 Laibsch: right Jan 14 21:15:03 there would be no reason for it to include that file, since collie can't run thumb code Jan 14 21:15:30 the issue with spitz and qemuarm is that the hardware _can_ run thumb, it's just that your compiler happens to be incapable of generating it. Jan 14 21:16:02 "# Include tune file for thumb support, it defaults to off so DISTROs can turn it on if they wish" from conf/machine/include/tune-xscale.inc Jan 14 21:16:07 is that still true? Jan 14 21:16:07 right Jan 14 21:16:22 Ah, error in my thoughts Jan 14 21:16:33 yes. the only reason you're having a problem is that the result of "turning it off" is to add -mno-thumb to the CFLAGS, and that causes gcc-2.95 to choke. Jan 14 21:16:41 2.95 has a problem not with on or off, but with the flag being called one way or another Jan 14 21:16:56 for newer gccs, it will work fine: -mno-thumb causes you to get 32-bit code, as you'd expect Jan 14 21:17:04 OK Jan 14 21:17:59 So, if the compilation runs successfully we "just" need to figure out a way to distinguish between situations when we want to include the thum include file (99% of the cases) and when we don't (currently sharprom-compatible only) Jan 14 21:18:08 thumb include Jan 14 21:18:13 +b Jan 14 21:19:20 Laibsch: right, but maybe I'll bump also SRCREV for fltk2 if it will help dillo2_2.1.1.bb Jan 14 21:34:55 Laibsch: yes, exactly Jan 14 21:35:13 you have an idea? Jan 14 21:35:20 I think it's probably only external gcc-2.95-based toolchains that have the problem. Jan 14 21:36:02 no, I don't have any very elegant solution. removing -mno-thumb from tune-thumb.inc would perhaps be the easiest, but I guess that might be undesirable. Jan 14 21:36:27 introducing some new variable like THUMB_CAPABLE_TOOLCHAIN is probably the lowest-impact, though not very pretty. Jan 14 21:36:37 is there something like -= ? Jan 14 21:37:01 oe_filter_out()? Jan 14 21:37:08 oh yeah Jan 14 21:37:16 may be that can be used to prune out Jan 14 21:37:27 TARGET_CC_KERNEL_ARCH and TARGET_CC_ARCH Jan 14 21:37:32 from distro conf Jan 14 21:37:53 I mean prune thumb from those variables Jan 14 21:38:11 yeah, something like that could work. Jan 14 21:41:00 I wanted to use oe_filter_out in mptl stuff in distro conf but I could not because it was too early in the expansion of variables Jan 14 21:42:43 actually bitbake supporiting deleting from strings wud help a great lot in such cases Jan 14 21:43:01 like _append Jan 14 21:43:16 may be there should be something like _prune Jan 14 21:45:27 pb_: oe_filter_out sounds good. It would only apply to sharprom-compatible.conf and thus not many people would bother if it was ugly Jan 14 21:45:37 It should get the job done, no? Jan 14 21:45:53 TARGET_CC_KERNEL_ARCH and TARGET_CC_ARCH as khem said Jan 14 21:46:32 Laibsch: if it wud work Jan 14 21:46:42 you have doubts? Jan 14 21:47:22 Laibsch: I wanted to delete an option from gcc configure same like this Jan 14 21:47:28 in a distro conf file Jan 14 21:47:32 :-( Jan 14 21:47:35 I see Jan 14 21:47:37 I couldnt use this function Jan 14 21:47:43 Well, at least we know what the problem is now Jan 14 21:47:49 the shell and python interwork :) Jan 14 21:47:54 yeah Jan 14 21:47:56 I can fix things locally until a proper solution is found Jan 14 21:54:11 hi,which recipe builds that: gst-plugin-modplug. Jan 14 21:54:13 ? Jan 14 21:54:26 bad,ugly? Jan 14 21:54:35 or good? Jan 14 21:55:11 * kergoth picks at his various scattered bits of prototype code for oe Jan 14 22:00:33 ok seems the bad Jan 14 22:00:47 I downloaded an ipk from angstrom,extracted it and looked into the control file Jan 14 22:00:53 for the patches Jan 14 22:01:01 and only bad has theses patches Jan 14 22:19:11 JaMa|W: there are reports of build failure for efltk as well. Do you think the same patch may cure them? Jan 14 22:24:28 Laibsch: I'll try later Jan 14 22:24:37 great Jan 14 22:26:25 man, there has to be a way to leverage these directory monitoring bits i played with to facilitate better traceability of our tasks.. but I've yet to work out just how Jan 14 22:55:49 how does OE know that patch XY is outdated? Jan 14 22:56:02 I looked at classes/patch.bbclass but could not figure it out Jan 14 22:56:26 Seems like OE is doing something clever here and I'd like to understand Jan 14 22:57:14 you probably want roughly line 544 in patch.bbclass, if "maxrev" in parm Jan 14 23:26:12 jo Jan 14 23:28:15 actually I think it's mindate and maxdate. And I did not understand where those were set. Looks like it's part of SRC_URI. Interesting and powerful thing. Jan 14 23:31:22 yes, parm is the parameters from the url, like patch, pnum, etc Jan 14 23:52:04 03Martin Jansa  07org.openembedded.dev * r4e65fa120b 10openembedded.git/recipes/navit/navit-icons_svn.bb: Jan 14 23:52:04 navit-icons: use PACKAGE_ARCH all as it has only icons Jan 14 23:52:04 Signed-off-by: Martin Jansa Jan 14 23:52:05 03Martin Jansa  07org.openembedded.dev * r966ae0bc49 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Jan 14 23:52:06 preferred-shr-versions: prefer QT 4.6 as Angstrom does Jan 14 23:52:08 Signed-off-by: Martin Jansa Jan 14 23:52:10 03Martin Jansa  07org.openembedded.dev * r26ccf336d4 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Jan 14 23:52:13 sane-srcrevs: bump EFL_SRCREV a bit for sliders fix see http://trac.enlightenment.org/e/ticket/36 Jan 14 23:52:15 Signed-off-by: Martin Jansa Jan 14 23:52:17 03Andreas Kemnade  07org.openembedded.dev * rb71a9d4bcf 10openembedded.git/ (conf/checksums.ini recipes/dillo/dillo2_2.1.1.bb): Jan 14 23:52:20 dillo2: add fltk2 based version 2.1.1 (from bug #4726) Jan 14 23:52:22 Signed-off-by: Martin Jansa Jan 14 23:52:26 03Martin Jansa  07org.openembedded.dev * ra99479dc22 10openembedded.git/recipes/dillo/ (5 files in 2 dirs): Jan 14 23:52:29 dillo: moved shared files (dillo.desktop, dillorc, dillo.png) to files Jan 14 23:52:33 directory Jan 14 23:52:35 Signed-off-by: Martin Jansa Jan 14 23:52:37 03Michael Pilgermann  07org.openembedded.dev * ra91a2ce913 10openembedded.git/recipes/openmoko-3rdparty/ (pisi_0.4.7.bb pisi_0.4.9.bb): Jan 14 23:52:40 pisi: remove old releases Jan 14 23:52:42 * Only minor updates.. so probably nobody would have P_V for that. Jan 14 23:52:44 Signed-off-by: Martin Jansa Jan 14 23:52:48 03Martin Jansa  07org.openembedded.dev * rcbd7025530 10openembedded.git/recipes/gpe-icons/ (gpe-icons.inc gpe-icons_0.25.bb gpe-theme-neo_git.bb): Jan 14 23:52:51 gpe-icons: cleanup include file a bit, don't inherit update-alternatives, just do it in postins/prerm with distro override Jan 14 23:52:54 Signed-off-by: Martin Jansa Jan 14 23:52:56 03Martin Jansa  07org.openembedded.dev * rfbf760ce9d 10openembedded.git/conf/distro/shr.conf: Jan 14 23:53:03 shr.conf: blacklist update-alternatives except opkg implementation Jan 14 23:53:05 Signed-off-by: Martin Jansa Jan 14 23:53:07 03Martin Jansa  07org.openembedded.dev * r2797305100 10openembedded.git/ (2 files in 2 dirs): Jan 14 23:53:10 fltk2: update SRCREV, fix build and packaging Jan 14 23:53:12 * fix build by defining XFT_MAJOR, the same as koen's commit for fltk1 Jan 14 23:53:14 * update SRCREV to version recommended for dillo-2.1.1 Jan 14 23:53:18 * fix libfltk2-images packaging (missing .so, only links were in that Jan 14 23:53:20 package) Jan 14 23:53:22 Signed-off-by: Martin Jansa Jan 15 00:13:22 03Martin Jansa  07org.openembedded.dev * rdf1a84d34d 10openembedded.git/recipes/fltk/efltk_2.0.7.bb: Jan 15 00:13:22 efltk: fix build with newer, stricter gcc Jan 15 00:13:22 Signed-off-by: Martin Jansa Jan 15 00:20:32 Laibsch: fltk/dillo/eflkt should be fixed now, bugs closed.. you can try if you want :) Jan 15 00:20:42 awesome, thanks Jan 15 00:20:54 wow, you were productive Jan 15 00:23:38 that's because xora advised me how to reorganize my git folders :) Jan 15 00:23:57 now I can stash longer patch queue before pushing :) Jan 15 00:25:53 2AM.. time for bed.. gnite **** ENDING LOGGING AT Fri Jan 15 02:59:57 2010