**** BEGIN LOGGING AT Thu Dec 15 02:59:57 2011 Dec 15 06:33:21 Aaargh, I cant override a '=' in a .bb with an '=' in a .bbappend. This defies the logic of imperative programming. Any 'good' reasons for this ? Dec 15 08:32:53 d4ny: it should override. Have you more context? Dec 15 08:33:43 RP__: I'm trying to do this override http://patchwork.openembedded.org/patch/14363/ in edison via a .bbappend. Dec 15 08:34:08 RP__: git://git.o-hand.com/qemugl.git;protocol=git is broken Dec 15 08:34:33 d4ny: right, you should be able to override SRC_URI Dec 15 08:36:35 the .bbappend is located in a different layer. I'll retry with another clean build and file a bugreport if I'm unable to do so. Dec 15 10:50:21 JaMa: I put my current status of the opkg preinst issues into bug 1711. Its a more invasive solution than I'd really like :/ Dec 15 10:50:50 thanks Dec 15 10:51:25 JaMa: I'll continue to try and clean that code up. I think we're going to need to integrate some of the recent opkg upstream changes too Dec 15 10:51:27 I haven't tried it yet, hopefully I'll be able to test it next week Dec 15 10:51:47 JaMa: ok, thanks Dec 15 12:45:17 RP__: I will work on the connman fix for the if_alg.h header tomorrow or next week Dec 15 12:45:44 RP__: dvhart and I found the reason and I will try to get it on upstream Dec 15 13:05:58 otavio: cool, thanks Dec 15 13:06:54 RP__: I am preparing another pull request ... did you see the three trivial patches that drop priority field? Dec 15 13:07:08 RP__: if you did, i will drop it from the next one Dec 15 13:10:44 otavio: I saw them Dec 15 13:11:08 otavio: Just got distracted deep into some code trying to fix the opkg preinst issues ;-) Dec 15 13:11:20 RP__: no problem ... Dec 15 13:11:28 RP__: those are just cleanups Dec 15 13:11:40 yes, I'll merge them Dec 15 13:11:45 RP__: opkg is indeed more important Dec 15 13:11:56 RP__: I will drop them from my queue then Dec 15 13:12:29 RP__: one important patch, that is trivial but critical to meta-oe, is a PE bump for dropbear Dec 15 13:12:38 RP__: I'll send it in a minute Dec 15 13:13:06 RP__: meta-oe had a broken version for a dropbear-systemd package Dec 15 13:13:47 otavio: I just merged the priority ones Dec 15 13:13:55 RP__: good Dec 15 13:14:19 RP__: just sent the dropbear one Dec 15 13:19:31 RP__: ignore the dropbear patch; Phil has just gave me a good way of fixing it Dec 15 13:23:35 otavio: how is PKGE better then PE? Dec 15 13:23:54 JaMa: well, we won't change it for all binaries Dec 15 13:24:01 JaMa: this can then go to meta-oe Dec 15 13:24:01 except bumping only dropbear-systemd which is imho more confusing Dec 15 13:24:19 JaMa: since this is meta-oe specific it can go there now Dec 15 13:24:35 hmm good that I'm using openssh-systemd :P Dec 15 13:25:51 JaMa: I don't like this or any solution for it et all Dec 15 13:26:06 JaMa: the better would it have been done properly versioned Dec 15 13:26:10 JaMa: but was not Dec 15 13:26:21 shouldn't qemux86-64 have x86 in OVERRIDES? Dec 15 13:26:59 # MACHINEOVERRIDES=${MACHINE}${@bb.utils.contains("TUNE_FEATURES", "m32", ":x86", "" ,d)}:${MACHINE_CLASS} Dec 15 13:27:03 MACHINEOVERRIDES="qemux86-64:" Dec 15 13:28:20 hmm so this probably won't work mesa/mesa-dri.inc:DRIDRIVERS_append_x86-64 = ",i915,i965" Dec 15 13:54:31 Hum it seems PKGE_${PN}-systemd doesn't work Dec 15 13:55:55 any hint what can cause so long package-index times? Dec 15 13:56:10 atime changes? Dec 15 14:17:09 what do you mean by that? Dec 15 14:35:06 otavio: I meant what's described in this thread: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-November/013143.html Dec 15 14:37:34 bluelightning: qt 4.8 released Dec 15 14:38:00 otavio: yep, am currently fixing/testing the recipes Dec 15 14:38:20 JaMa: yes I recall this thread and looking at the code changes it is a black magic heheh Dec 15 14:40:18 JaMa: the changes are fairly small Dec 15 14:40:31 JaMa: and nothing related as it seeems... Dec 15 14:41:25 otavio: yes, exactly, that's why I'm looking for hints here :) Dec 15 14:42:08 JaMa: did you check spaces/tabs mix? Dec 15 14:47:15 otavio: where? Dec 15 14:47:25 JaMa: on the files Dec 15 14:47:35 JaMa: just laud thinking Dec 15 14:47:57 JaMa: python has this issues and once I took 3 days to find a bug that was due that Dec 15 14:48:55 I have tried even older python-2.6, but it was the same Dec 15 15:05:28 RP__: are you going to merge nitink1 fix to dosfsutils soon? Dec 15 15:05:43 RP__: I have few meta-ti fixes depending on this Dec 15 15:05:55 otavio: I just did? Dec 15 15:06:00 oh Dec 15 15:06:04 didn't notice Dec 15 15:10:25 RP__: thx a lot Dec 15 16:39:04 gm all Dec 15 16:43:21 hi zenlinux Dec 15 16:44:45 bluelightning, do I hear you'll be in Germany soon? Dec 15 16:45:02 zenlinux: just for christmas, yes :) Dec 15 16:45:09 nice Dec 15 16:46:07 zenlinux: are you heading away anywhere for christmas? Dec 15 16:47:21 yeah, back to New Hampshire for the last week in Dec Dec 15 16:47:43 will likely see some snow Dec 15 16:49:08 RP__: around ? Dec 15 16:50:03 RP__: why do we install gxx-headers in /c++/ and not in /c++/GCCVER Dec 15 17:01:00 RP__: eglibc assumes the default install for c++ headers which is /c++/GCCVER Dec 15 17:01:20 I dont know of other packages that do the sam Dec 15 17:12:09 khem: No idea. I've tried to make the system consistent though Dec 15 18:26:23 RP__: would you be open to accept a patch to change it to /c++/GCCVER Dec 15 18:27:22 hmmm but that might also mean that whenever we bump up the version of gcc say from 4.6.2 to 4.6.3 the install location changes Dec 15 20:06:25 khem: right, its a tricky one Dec 15 21:17:26 RP__: I have decided to patch eglibc instead Dec 15 21:17:46 RP__: the code inside eglibc assumes standard installation for c and c++ headers Dec 15 21:18:03 khem: right, sounds like a reasonable fix **** ENDING LOGGING AT Fri Dec 16 02:59:56 2011