**** BEGIN LOGGING AT Mon Nov 02 02:59:56 2009 Nov 02 05:42:30 any idea what the proper bsd-mailx/dotlockfile permissions/ownership are? Nov 02 05:42:54 mailx can't open a lockfile like: open("/var/mail/.lk031681dht-walnut", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EACCES (Permission denied) Nov 02 05:44:29 should it exec 'dotlockfile' ? and liblockfile should be sgid to the group ownership of /var/spool/mail ..? Nov 02 05:44:37 erm, dotlockfile Nov 02 05:55:57 Can the FILESPATH be defined using WORKDIR for locating patches in source tree? -- IOW can I say FILESPATH += "${WORKDIR}/${PN}-${PV}/debian/patches" and expect the do_patch task to find the referenced patches? Nov 02 06:01:52 i will just think of it as 'hardening' for now Nov 02 06:01:53 ... Nov 02 08:05:19 good morning Nov 02 08:21:56 morning Nov 02 08:25:46 good morning Nov 02 08:27:09 mckoan, good morning ! Nov 02 08:27:16 ping pb__ , pb___ Nov 02 08:32:29 gremlin[it]: hello Nov 02 08:32:53 hi pb___ , didyou receive my mail about OEDEM (I cannot attend) Nov 02 08:33:37 gremlin[it]: ah, yes, I did. thanks for letting me know. Nov 02 08:33:54 pb___, ok ;) ... Nov 02 08:36:42 cardiac pacing session sounds fairly painful, rather you than me. Nov 02 08:39:16 pb___, hahaha it's my work ... i HAVE to attend cause will presented (again) a my work ... Nov 02 09:08:29 we need to populate avr32 site file ;( Nov 02 09:09:15 hrw, yep :) Nov 02 09:10:03 | /home/hrw/devel/build/stable/tmp/staging/armv5te-angstrom-linux-uclibcgnueabi/usr/include/libxml2/libxml/encoding.h:136: error: expected specifier-qualifier-list before 'iconv_t' Nov 02 09:13:36 5 Nov 02 09:13:54 uclibc builds in stable/2009 are a bit broken... Nov 02 09:20:26 hrw: hi, I'm not a stable reviewer should I still comment on the uclibc backport? Nov 02 09:23:02 you can but not have to - patch is from .dev and fixes stable/2009 builds Nov 02 09:31:07 pb___: may I abuse you once more? Nov 02 09:33:52 is sane to have thumb enabled by default for armv4t? arm920 in neo freerunner? pb found first issue why image cannot boot and it was fixed with bd449d860fac2948f0d9109f1cdefd0d2d4a5200, but we have still some issues in other code (like dbus_1.3.0/libx11 segfaulting with thumb) Nov 02 09:35:53 zecke: of course Nov 02 09:38:03 pb___: I finally write some ARM assembly and asking you appealed to be faster than searching the ARM ARM Nov 02 09:39:03 pb___: can I do something like "tst r0, #32" and then do "subsge r0, #32"? will the subs change r0 when the test failed? will the conditional flags be updated? Nov 02 09:57:24 morning all Nov 02 09:57:50 zecke: You pinged? Nov 02 09:58:08 03Holger Hans Peter Freyther  07stable/2009 * rcc73958551 10openembedded.git/recipes/uclibc/ (4 files in 3 dirs): (log message trimmed) Nov 02 09:58:08 uclibc-initial_0.9.30(.1).bb: Fix do_stage for ubuntu karmic Nov 02 09:58:08 gcc4.4 and glibc 2.10 complain that getline already has Nov 02 09:58:08 a different signature. Rename the version in the unidef.c. Nov 02 09:58:08 Hrw's note: patch is also needed on recent Debian system and is not related to Nov 02 09:58:11 version of GCC (I have 4.3.x). As stable/2009 uses 0.9.30 by default I patched Nov 02 09:58:13 that version too. Nov 02 09:58:15 03Robert Schuster  07stable/2009 * r7d8346ea04 10openembedded.git/recipes/servlet-api/ (4 files): Nov 02 09:58:18 jsp2.0 5.5.26: New recipe (from Jalimo SVN). servlet2.3 4.1.37: Dito. servlet2.3-native 4.1.37: Dito. servlet2.4 5.5.26: Dito. Nov 02 09:58:21 Signed-off-by: Marcin Juszkiewicz Nov 02 09:58:23 Acked-by: Koen Kooi Nov 02 09:59:29 good morning Nov 02 09:59:33 RP: oh yeah, it is on the list now Nov 02 09:59:59 RP: I think putting the checksums.ini file in the recipe dir is a good solution too... it works overlays and suchs Nov 02 10:00:42 zecke: we already have "collect checksums.ini from BBPATH" working Nov 02 10:01:25 I still favour finding a way to allow them from recipes too Nov 02 10:01:45 I don't like having assocaited metadata spread around different files :/ Nov 02 10:02:00 sure Nov 02 10:03:40 pb___: Hi, could you please explain me why there are undefined instructions when dbus is compiled with thumb enabled? (left one is output of cross/armv4t/bin/arm-oe-linux-gnueabi-objdump -d usr/lib/libdbus-1.so.3 built with thumb enabled and segfaults) Nov 02 10:04:16 pb___: http://pastebin.ca/1652769 Nov 02 10:07:48 zecke: yes, something like that, though you need to be a bit careful with what TST actually means Nov 02 10:08:04 also, some versions of the assembler spell it "subges", not "subsge" Nov 02 10:08:19 I didn't understand the last part of your question. Nov 02 10:09:39 JaMa: in the plt? that section is somewhat special, it contains a mix of arm and thumb. Nov 02 10:09:53 I think the "undefined" bits are actually the thumb shims. Nov 02 10:11:13 pb__: ah, then they're undefined but still should work, would be whole diff usefull for you? Nov 02 10:11:35 JaMa: they're undefined in arm mode, and should never be called in arm mode. if you disassemble them in thumb mode then they should become defined. Nov 02 10:12:00 a complete diff between the arm and thumb binaries? I don't think that will be very useful: virtually everything will be different. Nov 02 10:14:03 pb__: sorry, I don't understand arm asm at all :/, but what whould you advise to check? (I don't even have usable backtrace from neo with -dbg packages installed and eglibc/dbus recompiled with -O0 -g3 -ggdb :/ Nov 02 10:14:54 pb__: what i noticed from strace is that it segfaults when opening file, if that file doesn't exist.. Nov 02 10:15:21 JaMa: about the only way to proceed is to find out where it's actually segfaulting and then debug it from there. Nov 02 10:15:42 if you can get a register dump by whatever means (debug_user, gdb, catchsegv, ...) then that would be the place to start. Nov 02 10:16:09 don't worry too much about a backtrace to start with. Nov 02 10:16:12 03David-John Willis  07org.openembedded.dev * r995cb3cbff 10openembedded.git/conf/machine/omap3-pandora.conf: omap3-pandora.conf: Merge in latest machine file. Nov 02 10:16:12 03David-John Willis  07org.openembedded.dev * r1095768c5f 10openembedded.git/recipes/u-boot/u-boot-omap3pandora_git.bb: u-boot-omap3pandora: Bump SRCREV to fix issue with loading without an EXT board attached. Nov 02 10:16:12 03David-John Willis  07org.openembedded.dev * r648409319f 10openembedded.git/conf/machine/omap3-pandora.conf: omap3-pandora.conf: Line endings. Nov 02 10:16:14 03David-John Willis  07org.openembedded.dev * rfd778a7191 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): xserver-xorg-conf: Update xorg.conf for the omap3-pandora. i.e. cut out a load of cruft. Nov 02 10:16:18 03David-John Willis  07org.openembedded.dev * r86c5af3596 10openembedded.git/ (4 files in 2 dirs): avahi: Bump packages to 0.6.25 (security fix) and add checksums. Nov 02 10:16:23 03Koen Kooi  07org.openembedded.dev * r1f8db8932e 10openembedded.git/conf/checksums.ini: checksums: merge in checksums from openpandora repo Nov 02 10:19:54 some other things to try as background activities: does the same binary work on an armv5te system (e.g. qemu)? if yes, that would suggest that it's armv4t specific lossage; if no, it would suggest that it is a generic thumb bug. Nov 02 10:20:02 does it work if you use regular glibc rather than eglibc? Nov 02 10:21:09 morning lrg Nov 02 10:21:25 he pb__ Nov 02 10:21:28 hey Nov 02 10:21:45 pb__: info registers, http://pastebin.ca/1652785 ok I'll try this binary on my zaurus (armv5tel) Nov 02 10:22:49 lrg: tax question for you, how does slimlogic deal with the withholding tax on invoices that you write to US customers? I have been struggling to get a straight answer out of HMRC as to how much I can get back from them. Nov 02 10:23:23 JaMa: okay, that looks like it's in the dynamic linker. can you disassemble the corresponding bit of ld.so? Nov 02 10:23:30 pb__: move to Poland - no tax on US IT invoices Nov 02 10:23:40 pb__: do you mean VAT Nov 02 10:24:06 lrg: no, the withholding tax that the us government seems to want to apply to invoices for services. Nov 02 10:24:13 hrw: ah, good plan Nov 02 10:25:00 pb__: ehm, no idea on US tax. not been charging any Nov 02 10:25:26 lrg: ah, fair enough. and your us customers are paying your invoices gross, without deducting any? Nov 02 10:25:32 yes Nov 02 10:25:32 pb__: with objdump? Nov 02 10:25:36 good-o Nov 02 10:25:54 JaMa: yeah Nov 02 10:25:56 or gdb Nov 02 10:26:02 pb__: iirc, due to the service being performed out in the UK Nov 02 10:26:12 in the UK Nov 02 10:26:14 lrg: right, makes sense. thanks. Nov 02 10:28:22 pb__: one more question. Imagine I do this: "mov r1, #16, subs r1, #32", is it likely that stmgeia will be executed after this test? Nov 02 10:31:14 zecke: GE is signed greater-or-equal, which translates to (N == V). in that case, N will be set but I think V will be clear, so the answer is no. Nov 02 10:32:02 pb__: thank you so much... knowing about the existance of conditional execution and knowing the actual cpu flags is so different :) Nov 02 10:35:56 pb__: (gdb) disass 0x2a046a04 - No function contains specified address. Nov 02 10:36:39 JaMa: do "disass 0x2a046900 0x2a046b00" Nov 02 10:37:09 0x2a046900: Cannot access memory at address 0x2a046900 Nov 02 10:38:33 what binary are you running gdb on? Nov 02 10:38:42 if this is ld.so itself then you will have to adjust the addresses Nov 02 10:39:25 /usr/bin/dbus-daemon as before Nov 02 10:49:11 was it running when you did that? Nov 02 10:49:20 you need to let it run at least far enough to load up the interpreter. Nov 02 10:49:55 actually, the interpreter loading might work a bit differently under gdb anyway, it might be best to invoke it explicitly. Nov 02 10:50:02 pb__: thanks... I wrote stmgeia when I wanted stmneia :) Nov 02 10:50:06 do "gdb /lib/ld-linux.so.3" then "run /usr/bin/dbus-daemon" Nov 02 10:50:28 zecke: aha. Nov 02 10:52:18 pb__: then it says Cannot access memory at address 0x226a8 Nov 02 10:52:39 Starting program: /lib/ld-linux.so.3 /usr/bin/dbus-daemon --system --nofork Nov 02 10:52:55 ah, silly gdb Nov 02 10:53:00 oh well, forget that then, just use objdump Nov 02 10:54:08 ok, i have it dumped but I have no idea how to modify that address Nov 02 10:56:28 if you can put the disassembly online somewhere, plus the output of "ldd /usr/bin/dbus-daemon", I'll have a look at it presently. Nov 02 10:56:49 I need to go to a meeting in roughly 3 mins and 20 seconds though so it might have to wait until a bit later. Nov 02 11:11:03 pb__: http://jama.homelinux.org/org.openembedded.shr/dbus/ Nov 02 11:14:30 pb__: and this binary seems working on armv5tel (debian with eglibc-2.9) Nov 02 11:49:55 03Marcin Juszkiewicz  07org.openembedded.dev * rdcf95eb20f 10openembedded.git/recipes/linux/ (linux-bug/defconfig linux-bug_2.6.27.2.bb): linux-bug: bump SRCREV, enable more modules Nov 02 11:50:06 03Marcin Juszkiewicz  07org.openembedded.dev * r63f37cd4a8 10openembedded.git/ (3 files in 3 dirs): matchbox-config-gtk: sync with Poky Nov 02 12:11:05 hm, trying to make a new recipe for myththemes, it runs without error, but it does not run configure despite an explicit rule in the recipe Nov 02 12:11:10 see http://www.pastie.org/679865 for the recipe Nov 02 12:11:19 anyone an idea what I am doing wrong? Nov 02 12:11:42 it does load, expand, $(S} is ok etc Nov 02 12:12:05 but do_configure.log is emtpy and also no trace of e.g. log.status or so Nov 02 12:22:18 03Koen Kooi  07org.openembedded.dev * r7e6ad01cd0 10openembedded.git/recipes/abiword/abiword_2.8.1.bb: abiword: fix shlib packaging Nov 02 12:22:19 03Koen Kooi  07org.openembedded.dev * r645ea6a568 10openembedded.git/recipes/abiword/abiword_2.8.1.bb: abiword 2.8.1: package abicollab certs as well Nov 02 12:22:19 03Koen Kooi  07org.openembedded.dev * r9b6180b762 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: fix typo Nov 02 12:22:20 03Koen Kooi  07org.openembedded.dev * r16f0ec1835 10openembedded.git/recipes/mozilla/firefox_3.5.4.bb: firefox 3.5.4: fixup .pc files Nov 02 12:22:22 03Koen Kooi  07org.openembedded.dev * rb1b029537f 10openembedded.git/ (17 files in 3 dirs): firefox: add 3.5.4 Nov 02 12:22:25 03Koen Kooi  07org.openembedded.dev * re03a0d9069 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: clean iso-codes as well Nov 02 12:22:30 03Koen Kooi  07org.openembedded.dev * ree94e37cf8 10openembedded.git/recipes/gnome-mplayer/gecko-mediaplayer_0.9.8.bb: gecko-mediaplayer: update for ff 3.5.4 Nov 02 12:38:42 JaMa: does it run on the zaurus using the glibc binaries from oe? Nov 02 12:39:16 also, can you capture the output from /proc/maps while the program is running? the ldd output doesn't seem to show what is at 0x2axxxxxxx. Nov 02 12:40:37 eFfeM: are you certain that ${S} is correct? this problem is usually symptomatic of that variable not actually pointing to the directory where the configure script is. Nov 02 12:40:42 03Brijesh Singh  07org.openembedded.dev * ra355c055c8 10openembedded.git/recipes/ti/ (3 files in 2 dirs): gstreamer-ti svn: bump up svn rev and add boot script Nov 02 12:40:43 03Brijesh Singh  07org.openembedded.dev * r5eae1a8b24 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: libgles-omap3.inc: use libpvrPVR2D_FRONTWSEGL.so Nov 02 12:40:45 03Brijesh Singh  07org.openembedded.dev * r5a9d128fc9 10openembedded.git/recipes/tasks/task-gstreamer-ti.bb: task-gstreamer-ti: do not install gst-ti on am3517 platform Nov 02 12:40:46 03Brijesh Singh  07org.openembedded.dev * r239ca8ddd9 10openembedded.git/ (6 files in 3 dirs): Nov 02 12:40:47 bc-cat-omap 0.1.0: add recipe to build bc-cat module. Nov 02 12:40:49 * adjust libgles-omap3 staging to stage more headers for thisi Nov 02 12:40:51 * bc-cat module complains about unresolved symbols during modprobe hence Nov 02 12:40:53 using modprobe -f to force the module loading. Nov 02 12:40:57 03Brijesh Singh  07org.openembedded.dev * r549bda4de6 10openembedded.git/recipes/ (images/ti-demo-x11-image.bb tasks/task-demo-x11.bb): ti-demo-x11-image: add task and image for build x11 based demo image for TI platforms. Nov 02 12:46:09 pb__ I know if S is wrong you get these things then again configure is in myththemes-0.21+0.22rc2-r0/myththemes-0.22rc2/configure and I have S = "${WORKDIR}/mythplugins-0.22rc2" (and invoke configure with ${S}/configure Nov 02 12:46:44 btw: should do_configure not complain or at least give an error message if it cannot find/execute configure?) Nov 02 12:47:05 oh right, I see, you have a custom do_configure(). yes, in that case you should get an error. Nov 02 12:47:19 might be worth inspecting the output of "bitbake -e" to make sure your do_configure() is indeed what bitbake is trying to execute. Nov 02 12:50:31 bitbake -e indeed has my configure in its output Nov 02 12:54:26 afk, back in 30-60 min's Nov 02 12:57:41 bye Nov 02 13:02:03 pb__: http://jama.homelinux.org/org.openembedded.shr/dbus/maps Nov 02 13:03:00 pb__: with glibc binaries from oe.. I can test later.. I left my zaurus at home and wrong sd card is in it.. Nov 02 13:03:13 hm, weird, so there is nothing at 0x2aXXXXXX. Nov 02 13:03:23 you're still getting the same pc and lr addresses as before when it crashes, right? Nov 02 13:04:00 oh, wait, I think you have shown me the maps for gdb itself, not for dbus-daemon Nov 02 13:04:03 pb__: yes.. Nov 02 13:04:06 heh Nov 02 13:04:20 yes was about same pc and lr :) Nov 02 13:04:28 right Nov 02 13:05:34 pb__: check maps.. now from dbus :) Nov 02 13:05:47 aha, better :-) Nov 02 13:06:03 it is weird that your dbus-daemon is linked at this crazy address, but still Nov 02 13:06:29 i can check if its different with non-thumb binary.. Nov 02 13:07:14 don't worry, it probably isn't very significant Nov 02 13:08:11 just in case.. maps.arm Nov 02 13:09:42 do you have an unstripped copy of the dbus-daemon binary? Nov 02 13:12:43 hmm probably no.. its just oe build Nov 02 13:13:24 you should be able to fish it out of the actual build directory Nov 02 13:13:28 i.e. ${WORKDIR}, not the install/ tree Nov 02 13:13:40 ok mmt Nov 02 13:13:58 make sure you get the actual binary, not just the libtool wrapper script :-} Nov 02 13:14:09 the binary might be concealed in a ".libs" directory or suchlike Nov 02 13:15:44 something like this? dbus-dbg/usr/bin/.debug/dbus-daemon Nov 02 13:16:24 that looks like you are still in the install/ tree Nov 02 13:16:32 or image/ Nov 02 13:16:45 go up one level and then into the dbus-... source tree Nov 02 13:17:22 dbus-1.3.0/bus/.libs/dbus-daemon Nov 02 13:17:27 jackpot Nov 02 13:17:28 that's the one Nov 02 13:18:24 dbus-daemon.debug on web Nov 02 13:18:55 thanks Nov 02 13:19:21 you're welcome :) Nov 02 13:20:00 I have no idea what can be wrong.. so all shr users are counting on you... :) Nov 02 13:21:28 ah, now that dbus-daemon.debug seems to be an arm binary Nov 02 13:22:12 ahh :( sorry for that.. rebuilding now Nov 02 13:22:46 righto Nov 02 13:23:22 I've checked it before, but then behave like Moss in it crowd if you know that show.. (when he should check if solder is off and because it was off, he turned it on).. Nov 02 13:23:51 should be there Nov 02 13:39:28 03Michael Smith  07org.openembedded.dev * r00993186da 10openembedded.git/recipes/fastjar/ (5 files): Nov 02 13:39:28 fastjar 0.98: add non-native recipe Nov 02 13:39:28 Signed-off-by: Michael Smith Nov 02 13:39:28 Signed-off-by: Henning Heinold Nov 02 13:43:48 hm, that binary is a bit of a disaster, it includes a whole pile of non-armv4-safe return instructions. Nov 02 13:44:06 hard to say offhand whether that is the direct cause of your crash but it certainly doesn't look very good.# Nov 02 13:44:41 even libgcc seems to be getting that wrong which is rather sad. Nov 02 13:45:24 re Nov 02 13:45:30 pb__: hmm, so would you advise to disable thumb again? Nov 02 13:45:46 well, that depends on what you are trying to accomplish. Nov 02 13:45:55 long-term I would certainly like to see thumb both enabled and working. Nov 02 13:46:07 in the short term, if you need a binary that works right now, disabling thumb probably is the most expedient way to get one. Nov 02 13:46:36 I'm sure the thumb problems are fixable, it will just take a little bit of work to patch them all. Nov 02 13:48:21 shr distribution is preparing merge with oe.dev so we updated configs/libs/gcc etc to be quite up2date, but users wants new images and we don't want to maintain old shr/import for long.. but as you can see I'm not expirienced enough for fixing it myself (but I can disable thumb manually in packages which will fail here) Nov 02 13:48:33 I guess the particularly frustrating thing is that it used to work much better than this, so clearly this is all somewhat recent breakage. Nov 02 13:49:09 last time I tried thumb on my gta01 (which admittedly was probably the best part of a year ago) it worked well enough that I could build an all-thumb fso-base-image and have it boot without anything segfaulting. Nov 02 13:49:33 and I also expect that if we disable thumb now.. then nobody will invest enough time later to switch it on again Nov 02 13:50:04 this is old thumb, not new thumb? Nov 02 13:50:29 that probably is true. I think shr is about the only project still actively using armv4t right now, so if you turn it off then I suspect armv4t will just be left to rot. Nov 02 13:50:45 pb__: btw older dbus seems working even with thumb enabled... would it help somehow? but old is much older 1.2.3 instead of 1.3.0 Nov 02 13:50:49 not that leaving v4t to rot is necessarily a problem, but it would be a shame for shr not to get it working. Nov 02 13:51:24 since, based on my previous measurements, it seems to give you noticeable improvements in both speed and binary size. Nov 02 13:51:40 JaMa: that is interesting but probably not directly useful. Nov 02 13:51:57 I'll see if I can find a bit of time to fix at least the libgcc issues this afternoon, then we can see where that leaves us. Nov 02 13:52:27 it is annoying that qemu doesn't have a v4t emulation, that would make it less tedious to debug. Nov 02 13:52:37 I guess I could try to find out where I put my gta01 and use that. Nov 02 13:53:17 pb__, we need some "interns" that we can assing the task of de-bitrotting old hw :) Nov 02 13:53:24 pb__: ok, your help is very appreciated, thank you Nov 02 13:53:56 Crofton|work: heh, that would be nice. unfortunately though I am not sure that debugging this sort of problem is really an intern kind of task. Nov 02 13:54:03 Crofton|work: you can never have enough interns assigned to unrotting cool hardware :) Nov 02 13:54:33 pb__: some would have a good go at it in my experance, just not sure we can grab any :( Nov 02 13:55:01 pb__: I'll try to disable thumb for packages needed now for usable image and then maybe later enable some one by one if someone fix them Nov 02 13:55:08 JaMa: righto Nov 02 13:55:08 BlueProbe is a little GPE side project, it is really maintained any more? Nov 02 13:55:59 DJWillis: not really. blueprobe was basically a single-purpose tool to deal with a particular ipaq issue, I suspect it is fairly irrelevant on modern hardware. Nov 02 13:56:22 its only purpose was to tell the difference between ipaq h3950 and h3970 (one of which had bluetooth and one of which didn't) so that the UI could do the right thing. Nov 02 13:57:09 since then it seems to have sort of expanded to be a general dumping place for machine specific bluetooth parameters, but I think there are better ways of solving that particular problem. Nov 02 13:57:09 pb__: well it seems relevent for helping to bring up embedded Bluetooth on other platforms. The INIT script bit that is. I suspect the init script should be seperated out as that is used for a number of devices. Nov 02 13:58:15 * DJWillis would like to get a cleaner way of bringing up a BT embedded chip. Hmmm, what to do.... Nov 02 13:58:58 I added PR committee to the eV section of OEDEM, so we can talk about applications for things like FOSDEM Nov 02 13:59:13 DJWillis: well, if you know what your bluetooth parameters are, you can just ship a suitable /etc/sysconfig/bluetooth and forget about that script. Nov 02 13:59:50 all that blueprobe.init does is create the file in sysconfig if it didn't previously exist, and it is a little bit silly to have that done by this script with a big switch statement in it. Nov 02 14:00:44 pb__: True, then I guess I could just prohibit blueprobe for the Pandora, that would work and not break anything else I guess. Nov 02 14:01:17 DJWillis: blueprobe won't overwrite sysconfig/blueprobe if it already exists, so there shouldn't be any prohibiting needed. Nov 02 14:01:26 everything in that script is wrapped in "if [ ! -f ...]", iirc Nov 02 14:02:00 pb__: Good plan, i'll just ignore it and claim it never happened ;-) Nov 02 14:02:41 yeah, that sounds like your best option. Nov 02 14:09:38 good morning Nov 02 14:09:43 gm Nov 02 14:10:07 Crofton|work, will i see you this weekend? Nov 02 14:10:12 I am talking to a "relationship manager" .... Nov 02 14:10:16 yes! Nov 02 14:10:27 awesome, looking forward to it. Nov 02 14:10:42 when r u leaving? Nov 02 14:11:16 ok I am on hold waiting for him/her .... Nov 02 14:11:52 stupid credit card co is giving me heartburn over renewing some domains Nov 02 14:17:23 * Crofton|work grumbles and hopes the credit card works again Nov 02 14:21:17 Crofton|work: I tend to have several so that when they play these games, the other ones work Nov 02 14:21:59 * RP has emailed the dev list about the staging process and how I'd like to rip it up and start again Nov 02 14:22:45 Crofton|work, leaving friday morning, arriving in c Nov 02 14:22:53 Cambridge late Friday Nov 02 14:25:08 03Koen Kooi  07org.openembedded.dev * r15704b460b 10openembedded.git/recipes/ti/ti-dsplink-module_1.61.3.bb: dsplink: remove reference to asm/page.h Nov 02 14:32:20 RP, yeah me too, but i do not want to put personal expenses on the biz card Nov 02 14:32:42 kgilmer, interesting flight choice Nov 02 14:34:04 i hope that's a good interesting and not a bad interesting Crofton|work. When do you arrive? Nov 02 14:34:31 I'll be in Cambridge Friday afternoon/evening Nov 02 14:34:50 I arrive in UK Wed AM, and will visit family and maybe be a tourist Nov 02 14:35:52 very nice! I wish I had the time... 6-month old baby has taken over my life :P Nov 02 14:36:20 yeah Nov 02 14:38:10 Crofton|work: I'd like to be able to sighteeing a bit once I arrive at 14 at train station Nov 02 14:38:33 kgilmer: glad to know you're on board with us ;-) Nov 02 14:38:38 hi mckoan I will see you there as well :) Nov 02 14:38:58 hopefully it will be a little warmer than brussles was... Nov 02 14:39:12 kgilmer: I hope Nov 02 14:39:36 kgilmer: how is your baby ;-D Nov 02 14:40:23 she is very active mckoan thanks for asking. Nov 02 14:40:37 can she move on her own yet? Nov 02 14:41:25 Crofton|work: obviously you have no kids (LOL) Nov 02 14:41:47 she can roll over. and she can scream really loud. :) Nov 02 14:41:59 only god daughters Nov 02 14:42:08 I can hand them back when they become trobulesome Nov 02 14:42:26 kgilmer: heh, that is about where my daughter is at as well. Nov 02 14:42:27 it is worse when they can move and think clearly :) Nov 02 14:42:49 then you have my friend with the 13 year who thinks she is like 20 Nov 02 14:43:35 Crofton|work: hehe, if she asks if her boy friend can sleep over :) Nov 02 14:43:41 nice pb__ ! Nov 02 14:44:01 one day at a time Crofton|work, one day at a time. Nov 02 14:44:05 :) Nov 02 14:50:02 Crofton|work: Ah, that problem. I have an understanding manager and could get away with the personal card if need be... Nov 02 14:51:24 Hi RP, hope to see you this weekend as well! Nov 02 14:53:14 kgilmer: I plan to be there, looking forward to it! Nov 02 14:53:38 excellent Nov 02 14:58:01 RP, I am my own manager and makes my taxers more annoying :) Nov 02 14:59:26 Crofton|work: :) Nov 02 15:02:18 Crofton|work: same here :-) Nov 02 15:05:50 I work for a real dick :) Nov 02 15:08:33 haha, one that doesn't use IRC too much I suspect Crofton|work... Nov 02 15:14:02 kgilmer, I am self employed :) Nov 02 15:14:27 ouch Nov 02 15:14:52 ;) Nov 02 15:26:39 03Koen Kooi  07org.openembedded.dev * r447e30da5d 10openembedded.git/recipes/angstrom/ (4 files in 2 dirs): angstrom uboot scripts: change to mem=99M for omap3 since gst-ti is less hungry nowadays Nov 02 15:35:58 * Crofton|work grumbles about the whole mem=xxxM for dsplink ... Nov 02 15:41:06 Hmm, bash doesn't like recursive functions :} Nov 02 15:57:08 03Frans Meulenbroeks  07org.openembedded.dev * r1bae341f04 10openembedded.git/ (conf/checksums.ini recipes/mythtv/myththemes_0.21+0.22rc2.bb): myththemes: created recipe Nov 02 16:05:53 03Koen Kooi  07org.openembedded.dev * r34ee51c144 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): xserver-xorg-conf: simply touchbook config Nov 02 16:07:01 re Nov 02 16:09:29 hi, is there a clean way to install some kernel-module-xyz in the rootfs image without installing the kernel image (which is in a dedicated flash partition) ? Nov 02 16:11:19 03Marcin Juszkiewicz  07stable/2009 * r011d932ac8 10openembedded.git/recipes/classpath/ (classpath.inc classpath_0.98.bb files/fix-gmp.patch): Nov 02 16:11:19 classpath: depend on gmp (for libjavamath) and do not use system one Nov 02 16:11:19 Signed-off-by: Marcin Juszkiewicz Nov 02 16:11:19 Acked-by: Koen Kooi Nov 02 16:17:46 03Frans Meulenbroeks  07org.openembedded.dev * rf340409005 10openembedded.git/ (2 files in 2 dirs): Nov 02 16:17:46 cdparanoia: created svn recipe Nov 02 16:17:46 the 10.2 version exports a header file with a field called private Nov 02 16:17:46 g++ 4.3.3 and up fail on that Nov 02 16:17:46 this problem is resolved in svn Nov 02 16:53:58 03Marcin Juszkiewicz  07stable/2009 * r3b2e29c3d3 10openembedded.git/ (3 files in 3 dirs): Nov 02 16:53:58 matchbox-config-gtk: sync with Poky Nov 02 16:53:58 Signed-off-by: Marcin Juszkiewicz Nov 02 16:53:58 Acked-by: Koen Kooi Nov 02 16:54:09 03Marcin Juszkiewicz  07stable/2009 * rfdfedf718d 10openembedded.git/recipes/linux/ (linux-bug/defconfig linux-bug_2.6.27.2.bb): Nov 02 16:54:09 linux-bug: bump SRCREV, enable more modules Nov 02 16:54:09 Signed-off-by: Marcin Juszkiewicz Nov 02 16:54:09 Acked-by: Koen Kooi Nov 02 16:54:11 Signed-off-by: Marcin Juszkiewicz Nov 02 17:12:57 bye Nov 02 17:18:59 mickey|zzZZzz: ping? Nov 02 17:20:06 mickey|zzZZzz: In autotools_stage_all there is a load of pkgconfig stuff attributed to you? It would appear it doesn't do anything as the total contents of the directories is unconditionally staged elsewhere? Nov 02 17:33:15 pb__ yesterday you suggested me to do echo "INCLUDEPATH += ${STAGING_INCDIR}/taglib" >> ./mythmusic/mythmusic/config.pro Nov 02 17:33:15 in mythplugin configure, but apparently STAGING_INCDIR yields and empty string while running configure, what did I misunderstand ? Nov 02 17:58:39 pb__ decided as the alternate fix to take taglib-config --cflags and pipe through sed Nov 02 18:10:30 jo Nov 02 18:10:41 ~seen hrw Nov 02 18:10:42 hrw was last seen on IRC in channel #maemo, 57m 40s ago, saying: 'bye'. Nov 02 18:17:46 what is STCNE instruction? I found only STC, its in libfontconfig.so and on armv4t it fails with illegal instruction.. Nov 02 18:18:47 hm seems armv5 Nov 02 18:19:49 hm ah combined Nov 02 18:19:56 stumble some time over it Nov 02 18:20:03 stc is right Nov 02 18:23:01 so stc=stcne? Nov 02 18:23:09 good morning all Nov 02 18:23:23 hey khem Nov 02 18:23:27 morning khem Nov 02 18:23:50 JaMa: stcne is stc with conditional execution Nov 02 18:24:05 JaMa: this instruction is supported on armv5 and above Nov 02 18:24:18 he khem Nov 02 18:24:43 and check your sources this instruction is not scheduled by gcc so it must be hand written assembly somewhere in sources Nov 02 18:24:44 khem where one can find which combined instrcution works on which armvX? Nov 02 18:24:56 khem: ah then I should find out how it gets to my armv4t binary Nov 02 18:25:01 woglinde: ARM architecture reference manual if you have one Nov 02 18:25:16 hm I can download it Nov 02 18:25:20 woglinde: I implemented a simulator from scratch once for arm Nov 02 18:25:26 khem haha Nov 02 18:25:29 so somethings are engraved :) Nov 02 18:25:31 I downloaded it and there is just about STC Nov 02 18:25:34 you guru Nov 02 18:25:40 jama yes Nov 02 18:25:41 stc Nov 02 18:25:45 but not combined Nov 02 18:25:57 thats the problem sometimes Nov 02 18:25:59 hurray Nov 02 18:26:02 oh hmm stc should be everywhere Nov 02 18:26:05 boost building with cmake Nov 02 18:26:14 its other stc2 which is armv5t Nov 02 18:26:19 http://www.arm.com/miscPDFs/14128.pdf better link for reference manual? Nov 02 18:26:22 and above Nov 02 18:26:44 oh its on the website now thats cool let me see Nov 02 18:27:02 ah stc2 is there too and marked >v5 as you're saying.. ok Nov 02 18:27:05 khem since some times Nov 02 18:27:19 cool Nov 02 18:27:52 hm its from 2005 Nov 02 18:29:01 btw here is the workdir for this binary.. http://jama.homelinux.org/org.openembedded.shr/fontconfig/ Nov 02 18:29:13 hm Nov 02 18:29:25 the manual says stc with condition is in all Nov 02 18:29:36 maybe stc isnt in thumb? Nov 02 18:29:37 stcne is used with thumb and olso without (but much less) Nov 02 18:29:58 i mean in this libfontconfig.. Nov 02 18:31:51 yes stc is arm mode only Nov 02 18:32:04 JaMa: where is the source code Nov 02 18:33:10 ah hehe Nov 02 18:33:16 so I read the manual right Nov 02 18:33:22 wasnt sure Nov 02 18:33:29 khem: its from oe so: http://fontconfig.org/release/fontconfig-${PV}.tar.gz Nov 02 18:33:40 khem: its from oe so: http://fontconfig.org/release/fontconfig-2.6.0.tar.gz Nov 02 18:35:46 JaMa: there is no stc instruction used in fontconfig srcs you pointed out Nov 02 18:35:49 where do you see it Nov 02 18:36:04 sometimes when you disassemble stripped thumb binaries Nov 02 18:36:12 objdump is utterly confused Nov 02 18:36:34 because it relies upon mapping symbols to do the right disassembly Nov 02 18:36:39 and they are stripped out Nov 02 18:37:19 and when you disassemble it assumes default arm mode and you can get a lot of interesting weird looking disasm Nov 02 18:37:56 khem: it was shown by gdb just after i received illegal instruction Nov 02 18:38:13 JaMa: ok. Nov 02 18:38:30 khem: and with thumb disabled it seems working ok Nov 02 18:38:37 JaMa: ok Nov 02 18:38:57 but failed a bit later in libfreetype :/ http://pastebin.ca/1653442 Nov 02 18:39:00 JaMa: are you able to find which binary/solib is it in when the illegal instruction happen Nov 02 18:39:14 but maybe the cause is simillar Nov 02 18:39:24 mm I'll install thumb binary back Nov 02 18:39:31 ah this snippet is thumb code disassembled as arm Nov 02 18:39:38 so dont believe this disasm Nov 02 18:40:30 *g* Nov 02 18:40:41 JaMa: use objdump -M force-thumb Nov 02 18:40:50 so force thumb disasm Nov 02 18:41:00 ah fine Nov 02 18:41:08 boost building with cmake is so much better Nov 02 18:41:17 the reason not to use thumb is that its a PITA to debug because of lack of tools support Nov 02 18:41:23 JaMa: "stc" is a coprocessor instruction, not specific to any particular version of the architecture Nov 02 18:41:47 it would be equally well supported on v4 as on v5 if you have the right copro but apparently you do not in this instance :-} Nov 02 18:41:58 pb intressting Nov 02 18:41:58 khem: http://pastebin.ca/1653444 Nov 02 18:41:58 hi pb_ yes stc2 as it is said in the manual is armv5+ Nov 02 18:42:15 okay Nov 02 18:42:17 dinner now Nov 02 18:42:27 JaMa: oh, right, that code is just garbage Nov 02 18:42:40 you are executing either thumb as arm, or just random binary junk Nov 02 18:42:48 JaMa: what mode is gdb in Nov 02 18:42:56 when the trap happens Nov 02 18:42:58 khem: how can i check it? Nov 02 18:43:17 if it is in arm mode then you know somewhere the change of mode happened wrongly Nov 02 18:43:29 info regs Nov 02 18:44:02 yeah, that is most likely the problem. we were talking earlier about the continuing abundance of busted return sequences. Nov 02 18:44:10 khem: http://pastebin.ca/1653449 Nov 02 18:44:33 both libgcc and glibc seem to still have quite a few that are wrong Nov 02 18:46:47 T flag is set to 0 in the reg dump Nov 02 18:46:56 which means its executing thumb code in arm mode Nov 02 18:47:19 pb_: libgcc and glibc that will be a serious problem Nov 02 18:47:39 bbiab, emma's bathtime now Nov 02 18:47:51 JaMa: what binutils ver are you using Nov 02 18:48:03 eglibc_2.10 and gcc-4.4.2, should I try older? or glibc instead of eglibc? binutils 2.20 Nov 02 18:48:37 JaMa: hmmm that seems a sane combination to me Nov 02 18:49:15 khem: if I use -M force-thumb, then it just says Aborted Nov 02 18:49:34 objdump ? Nov 02 18:49:50 yes but from cross on buildhost if its ok Nov 02 18:51:44 khem: but it works on target, nvm Nov 02 18:52:40 khem: ah no.. it says Aborted too.. after few decompiled lines.. Nov 02 18:53:27 http://pastebin.ca/1653462 Nov 02 18:55:56 the same .so before stripping http://jama.homelinux.org/org.openembedded.shr/fontconfig/workdir-thumb/fontconfig-2.6.0-r1/fontconfig-2.6.0/src/.libs/libfontconfig.so.asm Nov 02 18:58:22 JaMa: I think the problem is probably some linker veneer got wrong Nov 02 19:05:09 JaMa: it seems the plts dont switch the mode correctly here Nov 02 19:05:22 JaMa: Could you try using older version of binutils ? Nov 02 19:05:29 say 2.19.51 Nov 02 19:05:37 ok, mmt Nov 02 19:05:46 that worked well once upon a time Nov 02 19:06:16 JaMa: is this the only problem you have or you are seeing many crashes like these Nov 02 19:06:22 JaMa: if you use a newer binutils then the "aborted" thing will go away Nov 02 19:06:31 you might need the cvs trunk for that though, not sure Nov 02 19:06:43 pb_: he is already at 2.20 Nov 02 19:06:47 yeah, 2.20 is too old Nov 02 19:06:54 oh :) Nov 02 19:07:06 it seems to work for me with the trunk, I'm not sure if that fix is on the 2.20 branch or not Nov 02 19:07:17 could be Nov 02 19:07:24 khem: lots of crashes.. Nov 02 19:07:43 mickeyl: good morning Nov 02 19:07:48 JaMa: OK that would mean some fundamental toolchain issue Nov 02 19:07:53 JaMa: let me have a look and see if my v4 build has completed Nov 02 19:08:04 I launched it earlier this afternoon but I didn't have time to keep an eye on it Nov 02 19:08:06 khem: it segfaulted somewhere in dbus-daemon which pb_ tried to fix.. Nov 02 19:08:23 I see Nov 02 19:08:35 yeah, that was the libgcc bad return instruction thing Nov 02 19:08:52 pb_: which function in libgcc Nov 02 19:09:05 muldf3, maybe. I don't remember exactly. Nov 02 19:09:19 pretty sure it was one of the fp support funcs though Nov 02 19:09:20 morning pb_ Nov 02 19:09:22 pb_: hmm I am suspecting binutils/ld Nov 02 19:09:47 possibly, but that wouldn't explain the broken return sequence, ld doesn't generate those Nov 02 19:10:00 the plt looked ok from a quick inspection although I didn't check it in detail Nov 02 19:10:16 pb_: if plts are ok then yes Nov 02 19:10:33 right, v4 toolchain is built, I'll try compiling dbus now Nov 02 19:10:34 usually returns should not be ld's issues Nov 02 19:10:57 pb_: use 1.3.0, as 1.2.3 seems ok Nov 02 19:11:34 righto Nov 02 19:11:54 task 337 of 532 Nov 02 19:11:58 * pb_ waits patiently Nov 02 19:12:29 * JaMa is checking binutils build twice/sec :) Nov 02 19:13:03 -cross finished Nov 02 19:15:00 Hi, sorry to interject, I've a quick question: is it a bad idea to use a newish toolchain (gcc 4.2.4) to build an oldish kernel (2.6.19.7)? It builds ok, but fails to boot (all I get is "Uncompressing Lin" - then hang) Nov 02 19:16:38 the kernel does tend to lag behind the rest of the world in embracing new compilers, though it isn't quite as bad as it used to be. Nov 02 19:16:46 I'm using distro angstrom-2008.1, whose toolchain I expect to be rock-solid, but kernel (which boots fine with gcc 3.4) doesn't Nov 02 19:17:08 greyback, what machine? Nov 02 19:17:31 Crofton|work: a "neuros-osd" - not very well supported Nov 02 19:18:14 it is a defined machine in OE, but the config only works if you use Neuros' external toolchain to build stuff Nov 02 19:18:19 what cpu architecture is that? Nov 02 19:18:27 dm320 = armv5te Nov 02 19:18:45 yeah Nov 02 19:18:58 x86 generally seems relatively tolerant of newer gccs. arm has a less good track record in that respect, particularly for relatively fringe machines. Nov 02 19:18:59 neuros kernel support is going upstream though Nov 02 19:19:03 so that might help Nov 02 19:19:37 it wouldn't surprise me much if it was busted with gcc 4.x in 2.6.19.7, and I wouldn't be totally shocked (although slightly surprised) if it was still busted for gcc 4.x today. Nov 02 19:19:38 Crofton|work: sorry? You thinking of OSD2? Nov 02 19:20:17 oe does support using different compiler versions for the kernel than everything else, for more-or-less exactly this reason. Nov 02 19:20:24 pb_: ok, this is at least comforting to my ears. I've tried 3 different modernish toolchains to no avail Nov 02 19:20:39 pb_: I did not know that, hmmm Nov 02 19:20:41 so, if gcc 3.4 works for you, I would be tempted to just set KERNEL_CCSUFFIX appropriately, grit my teeth, and live with it. Nov 02 19:21:08 greyback, possibly, I'd have to check Nov 02 19:21:11 pb_: that's a place to start, great! thank you Nov 02 19:21:32 Crofton|work: I do know work is being done for OSD2 upstream. It's a davinci-based machine so lots of work is already done Nov 02 19:21:37 if you poke around in recipes/linux you should find plenty of examples of other kernels that need to do the same thing Nov 02 19:21:53 pb_: magic, thanks Nov 02 19:22:06 This "Uncompressing Lin" was driving me nuts Nov 02 19:22:28 actually... linux-neuros_2.6.15.bb does already have a commented-out KERNEL_CCSUFFIX = "-3.4.6" Nov 02 19:22:29 heh Nov 02 19:23:08 so, it would seem that you are not the first to face this issue on neuros. :-} Nov 02 19:23:17 pb_: true, which does make me worry too :) Looks like Neuros' original toolchain was made with crosstool Nov 02 19:23:31 pb_: no, I'm not. gremlin[it] ping! :) Nov 02 19:24:32 hey greyback ! Nov 02 19:24:34 well, count yourself lucky, it doesn't seem like all that long ago that the arm kernel h4x0rs refused to touch anything newer than gcc 2.7.2.1 Nov 02 19:24:52 pb_: lol yikes Nov 02 19:25:07 greyback, you need help ? i would like to continue with OSD support Nov 02 19:25:11 gremlin[it]: heya! I've been playing with your work on the Neuros OSD in OE for the last few weeks Nov 02 19:25:32 gremlin[it], it barelly work ... Nov 02 19:25:42 gremlin[it]: well I've been trying to get a working toolchain & kernel Nov 02 19:26:25 greyback, if i remember correct i used the toolchain from Neuros ... Nov 02 19:27:13 greyback, which OSD ? 1 or 2 ? Nov 02 19:27:14 So far, it fails miserably. "turran" has ported some hardware to a slightly newer kernel, and Cadenux open sourced their kernel to us (2.6.4 I think). I was hoping I could port these drivers up a bit Nov 02 19:27:31 gremlin[it]: OSD1, yes you used Neuros' toolchain Nov 02 19:27:49 greyback, 'to us' mean all or only neurso guys ? Nov 02 19:28:15 gremlin[it]: I think they released it OSS, so to everyone I believe Nov 02 19:28:58 greyback, wow good ... that make it a really nice devel device again ... Nov 02 19:29:13 gremlin[it]: http://tinyurl.com/yabaquc Nov 02 19:29:18 greyback, there is a site / forum about it ? Nov 02 19:29:34 gremlin[it]: yes, I think it would be nice to get the hardware working properly Nov 02 19:29:52 greyback, yes i read about usb .. but the main issue is the DSP ... Nov 02 19:30:15 gremlin[it]: heh, yes. That is a problem alright Nov 02 19:30:29 I doubt we'd ever get that unlocked Nov 02 19:31:07 We have a c54x compiler (no debugger), but how to interface with the closed-source modules remains a mystery Nov 02 19:31:20 khem: I've rebuilt binutils-cross,binutils to 2.19, then fontconfig, reinstalled binutils and libfontconfig on neo and looks the same, but somewhere else.. http://pastebin.ca/1653513 Nov 02 19:31:21 Not sure of the legality of reverse engineering them either Nov 02 19:31:22 greyback, without DSP is about un useful ... just a arm9 board ... Nov 02 19:31:46 gremlin[it]: fair point Nov 02 19:33:02 khem: should i try 2.20.51.0.2 with "11. Improve arm support." from 2.20.51.0.1? Nov 02 19:33:43 heh, crazy hj binutils. worth a go I guess, but you might be better off with the latest snapshot from sourceware. Nov 02 19:34:23 ftp://sourceware.org/pub/binutils/snapshots/binutils-2.20.51.tar.bz2 Nov 02 19:34:25 both workdirs for this build added to http://jama.homelinux.org/org.openembedded.shr/fontconfig/ Nov 02 19:34:32 which, paradoxically, is probably newer than 2.20.51.0.2 Nov 02 19:35:11 oh drat, it seems I have accidentally built for uclibc Nov 02 19:35:16 heh Nov 02 19:35:56 btw: would be uclibc better choice for freerunner? :) Nov 02 19:36:13 that's an interesting question. it might be, yeah. Nov 02 19:36:17 we switched glibc->eglibc just because its default when using sane-toolchain.. Nov 02 19:36:45 uclibc would certainly be worth a look, it's not as crazy as it once appeared. Nov 02 19:38:21 and IRC the system worked before this switch.., then it could not boot, which was fixed with that missing armv4t-interworking.patch, then I disabled thumb again and it segfaults everywhere.. so maybe all this segfault are still just because of eglibc? Nov 02 19:38:59 that's possible. eglibc does seem to have many fewer patches than glibc 2.10 which is slightly suspicious. Nov 02 19:39:14 armv4t-interworking was one of the missing ones, I haven't checked what others are different Nov 02 19:39:27 well, looking at my dbus binary it does seem like muldf3 is correct at least Nov 02 19:39:46 I can start a glibc build now (doh) but it will probably not be finished before my bedtime. Nov 02 19:39:56 i said it wrong.. first i disabled thumb it worked, then the patch was added and it booted (probably worked too), so I enabled thumb Nov 02 19:40:11 you're using gcc-4.4.2, right? Nov 02 19:40:16 right Nov 02 19:40:22 ok, that's the same I have Nov 02 19:40:31 it's interesting that yours doesn't seem to be doing interworking correctly whereas mine is Nov 02 19:40:42 could you fish out a copy of your libgcc.a from staging and put it on the web? Nov 02 19:41:37 sure Nov 02 19:42:11 it'd be interesting to see your log.do_compile from gcc, too Nov 02 19:42:20 cross/armv4t/lib/gcc/arm-oe-linux-gnueabi/4.4.2/libgcc.a Nov 02 19:42:31 no libgcc.a in stagging dir.. Nov 02 19:42:32 yup, that's the on Nov 02 19:42:35 one Nov 02 19:42:40 oh, hm. it must be in there somewhere. Nov 02 19:42:54 ah, sorry, cross is effectively part of staging Nov 02 19:42:57 http://jama.homelinux.org/org.openembedded.shr/fontconfig/libgcc.a Nov 02 19:42:57 so, yeah, that one is the right file Nov 02 19:51:22 well, that looks fine. and, weirdly, I now can't find the original offending sequence in your dbus-daemon either. Nov 02 19:51:23 pb_: binutils-uclibc-300-012_check_ldrunpath_length.patch is just for uclibs or usable for all? cannot apply to that 2.20.51.. Nov 02 19:51:28 maybe I was somehow looking at the wrong file before. Nov 02 19:52:38 JaMa: it doesn't look uclibc specific, but it doesn't look very important either Nov 02 19:53:04 seems to be intended to make ld ignore an empty LD_RUN_PATH, which I guess is a somewhat fringe pursuit Nov 02 19:54:42 pb_: the same for binutils-arm-non-empty-know.patch Nov 02 19:55:31 I've no idea what that one is about. Nov 02 19:55:45 looks like it would be for a compilation failure of some kind, so if you can build without it I imagine you do not need it Nov 02 19:59:00 03Frans Meulenbroeks  07org.openembedded.dev * r82a82feb0a 10openembedded.git/recipes/taglib/taglib_1.5.bb: taglib: also install .tcc files in staging Nov 02 19:59:01 03Frans Meulenbroeks  07org.openembedded.dev * rcfe13877e4 10openembedded.git/recipes/mythtv/ (mythplugins/configure.patch mythplugins_0.21+0.22rc2.bb): Nov 02 19:59:01 mythplugins: added mythmusic; fixed configure patch, remove unneeded MythBackend patch Nov 02 19:59:01 still some issues wrt staging Nov 02 20:03:04 pb_: -cross compiled fine but some patch is still needed http://pastebin.ca/1653581 Nov 02 20:12:14 pb_: configure.ac:26: error: Please use exactly Autoconf 2.64 instead of 2.63. Nov 02 20:17:52 doh Nov 02 20:17:54 crazy autotools Nov 02 20:18:59 i've set libelf include dir manually in configure and its built now.. :) Nov 02 20:23:29 pb_: recompiled fontconfig ends with SIGILL, Illegal instruction. again Nov 02 20:24:59 03Koen Kooi  07org.openembedded.dev * re8af03d37b 10openembedded.git/recipes/gstreamer/gst-plugins.inc: gst-plugins: blacklist -static for meta packages as well Nov 02 20:26:43 pb_: and it also ends with Abort when decompiling with thumb forced Nov 02 20:27:14 drat Nov 02 20:27:28 did you have a register dump for that SIGILL crash? Nov 02 20:30:40 pb_: http://pastebin.ca/1653650 Nov 02 20:34:35 thanks. and /proc/maps output? Nov 02 20:37:48 pb_: http://jama.homelinux.org/org.openembedded.shr/fontconfig/enlightenment_start.maps Nov 02 20:37:53 JaMa, hi Nov 02 20:37:59 Gnutoo: hi Nov 02 20:38:08 btw does someone knows where the ggdb3 is ? Nov 02 20:38:20 because it seems to have disapeared from bitbake.conf Nov 02 20:42:05 hm, that is a bit weird. what does gdb say if you do "disassemble 0x405572f0 0x40557300"? Nov 02 20:43:00 oh, wait, no, forget that. I was looking at the wrong place :-} Nov 02 20:43:08 http://pastebin.ca/1653684 Nov 02 20:45:30 03Richard Purdie  07rpurdie/work-in-progress * rc45ce742fe 10openembedded.git/classes/ (base.bbclass binconfig.bbclass pkgconfig.bbclass): Nov 02 20:45:30 binconfig/pkgconfig.bbclass: Convert staging functions into SYSROOT_PREPROCESS_FUNCS operating on SYSROOT_DESTDIR Nov 02 20:45:30 Signed-off-by: Richard Purdie Nov 02 20:45:31 03Richard Purdie  07rpurdie/work-in-progress * r579a84a1d2 10openembedded.git/classes/ (base.bbclass packaged-staging.bbclass): Nov 02 20:45:33 packaged-staging.bbclass: Use a variable for the location of the staging lock file (from Poky) Nov 02 20:45:35 Signed-off-by: Richard Purdie Nov 02 20:45:37 03Richard Purdie  07rpurdie/work-in-progress * r3d6dbf25ed 10openembedded.git/classes/ (base.bbclass packaged-staging.bbclass): Nov 02 20:45:41 base.bbclass: Rework staging function to use a DESTDIR style configuration based Nov 02 20:45:42 on the data from the do_install step (from Poky). This falls back to any Nov 02 20:45:44 standard do_stage function if defined, see the mailing list for more info. Nov 02 20:45:46 Signed-off-by: Richard Purdie Nov 02 20:45:48 03Richard Purdie  07rpurdie/work-in-progress * r4808cbdb87 10openembedded.git/classes/native.bbclass: Nov 02 20:45:51 native.bbclass: If do_stage isn't overridden, allow do_install to run for native packages (from Poky) Nov 02 20:45:53 Signed-off-by: Richard Purdie Nov 02 20:45:59 03Richard Purdie  07rpurdie/work-in-progress * r79753577a9 10openembedded.git/classes/base.bbclass: Nov 02 20:46:02 base.bbclass: Note legacy staging packages in debug output Nov 02 20:46:04 Signed-off-by: Richard Purdie Nov 02 20:46:06 03Richard Purdie  07rpurdie/work-in-progress * rb8837168de 10openembedded.git/classes/ (autotools.bbclass base.bbclass): Nov 02 20:46:11 autotools.bbclass: Separate out useful staging functions into base.bbclass and call from autotools classes (from Poky) Nov 02 20:46:14 Signed-off-by: Richard Purdie Nov 02 20:48:41 wew Nov 02 20:49:07 took me a moment to see rp's changes went into a branch :) Nov 02 20:49:13 We now have a branch of crazy patches to review :} Nov 02 20:49:23 does OE provide its own init script(s)? If so, how difficult is it to override that? Nov 02 20:49:32 Crofton|work: I thought a branch might be safest for this Nov 02 20:49:39 neale: Quite often and not that difficult Nov 02 20:50:00 great, I'll start playing with it then :) Nov 02 20:50:02 thanks Nov 02 20:51:44 pb_: I'm going off for a while and then to bed.. if you need something to test, leave me message and I'll read log tomorrow.. and http://jama.homelinux.org will be down too Nov 02 21:29:39 good evening, i'm setting up oe in opensuse 11.1 i followed wiki instructions, but i always get error from sanity check saying i dont have texi2html and makeinfo. Nov 02 21:29:57 install 'em Nov 02 21:30:10 mm. but they seem installed Nov 02 21:30:23 i installed: subversion git python help2man diffstat wget gcc gcc-c++ libstdc++ glibc-devel texinfo automake patch Nov 02 21:31:00 which texi2html makeinfo Nov 02 21:31:08 run this command Nov 02 21:31:49 they don't exist. ok.. i'll search them. thought they were in automake and texinfo Nov 02 21:31:57 qsp: http://sakrah.homelinux.org/Public/OE-on-suse-notes.txt Nov 02 21:32:04 btw Nov 02 21:32:17 those are some notes I took when I muddles with OpenSuse few months Nov 02 21:32:18 back Nov 02 21:32:22 khem, qsp: place that info on OE wiki please Nov 02 21:32:40 khem: thank you , i'll read. Nov 02 21:32:49 http://wiki.openembedded.net/index.php/OEandYourDistro Nov 02 21:32:51 here Nov 02 21:33:14 Jay7: yes I intended to but memory did not serve long enough Nov 02 21:33:21 yep, i was reading that, Jay7 so something is missing to get these 2 packages. i'll read khem's notes thanks Nov 02 21:33:23 and I dont use suse in general Nov 02 21:34:34 khem: I finally put those layout changes into a branch for OE.dev Nov 02 21:36:10 RP: cool. Nov 02 21:36:54 03Richard Purdie  07rpurdie/work-in-progress * rf457954a28 10openembedded.git/classes/autotools.bbclass: Nov 02 21:36:54 autotools.bbclass: Fix a typo Nov 02 21:36:54 Signed-off-by: Richard Purdie Nov 02 21:36:54 03Richard Purdie  07rpurdie/work-in-progress * r79bcf0a846 10openembedded.git/classes/canadian-cross.bbclass: Nov 02 21:36:54 canadian-cross.bbclass: Fix circular references after layout_ changes Nov 02 21:36:58 Signed-off-by: Richard Purdie Nov 02 21:37:00 RP: rpurdie/work-in-progress Nov 02 21:37:10 cool. Nov 02 21:37:16 I will have a look into it Nov 02 21:37:43 khem: yes. it also has the staging changes I'm proposing too Nov 02 21:38:10 staging overhaul in general ? Nov 02 21:38:15 khem: yes Nov 02 21:38:29 ah nice, let me read on my emails Nov 02 21:38:34 did you send it to ml Nov 02 21:38:36 * RP is writing up an email about the details now. Its the end of do_stage with any luck :) Nov 02 21:38:53 khem: I sent part 1 with the high level summary Nov 02 21:38:57 that will be wonderful Nov 02 21:39:22 so what do you propose for staging now Nov 02 21:39:52 khem: We use whatever happened in do_install Nov 02 21:40:35 do we copy it over ? Nov 02 21:40:53 right now install happens to a local dir in build tree right Nov 02 21:40:54 thank god for the staging overhaul, it's been a long time coming :) Nov 02 21:41:11 kergoth: Can you help with the review and testing please :) Nov 02 21:41:14 sure Nov 02 21:41:30 kergoth: I know I'm going to get complaints when this breaks ;-) Nov 02 21:41:36 RP: any opinion on making the 'check' flag more useful, at some point? right now it only applies to shell functions, iirc. i'm thinking if we move it up a level it may actually be of use Nov 02 21:41:43 of course :) Nov 02 21:41:54 kergoth: What does the check flag do? Nov 02 21:41:54 * khem reads RPs mail Nov 02 21:42:12 i didn't implement it, and apparently you didn't, i wonder who did.. Nov 02 21:42:29 it lets you specify a function to be executed to check if the task needs to be executed, and if not, immediately returns rather than running it Nov 02 21:42:44 i was thinking you could inject a function there to check if the pstage package exists, and avoid the stamp mangling Nov 02 21:43:12 kergoth: hmm, I wonder if that was me? :/ Nov 02 21:43:17 kergoth: Where is that in the code? Nov 02 21:43:51 build.py ? Nov 02 21:44:23 RP: your approarch is nice (staging) Nov 02 21:46:44 RP: yep. it would probably be more useful yet to move it even higher up into the cooker, to be able to check if the task needs to be run at all rather than it acting like its running it Nov 02 21:46:50 i wonder who added this thing.. blame is a pain at times Nov 02 21:47:06 have to blame, see it was just a rearrangement commit, then blame at the commit before that one, check again.. Nov 02 21:47:11 i want a blame history Nov 02 21:47:20 RP: do_populate_staging why do we need it. Nov 02 21:47:22 kergoth: I'm trying to look at the history but cgit is painful for that Nov 02 21:47:34 kergoth: git blame Nov 02 21:47:40 khem: To copy from the destdir to the sysroot Nov 02 21:47:42 i know what blame is Nov 02 21:47:47 khem: Nov 02 21:47:55 RP: why not install in sysroot directly Nov 02 21:48:00 but often when you do a blame, you find that the line was just modified, not was who added in the first place Nov 02 21:48:01 s Nov 02 21:48:01 o th Nov 02 21:48:01 en Nov 02 21:48:01 yo Nov 02 21:48:01 u h Nov 02 21:48:03 av Nov 02 21:48:05 er, stupid computer Nov 02 21:48:07 t Nov 02 21:48:09 hen Nov 02 21:48:11 Nov 02 21:48:16 * kergoth shakes fist at osx Nov 02 21:48:33 kergoth: check was in the initial import from OE Nov 02 21:48:44 kergoth: Which means I wasn't responsible for that one :) Nov 02 21:48:57 hah, interesting Nov 02 21:49:20 well, i still think it could be useful to run a snippet to determine if a task needs to be run, but it would be better done in the cooker, not build.py, if it should exist at all Nov 02 21:49:20 khem: and then how do you know what to remove if you want to uninstall? Nov 02 21:49:36 khem: This gets us into the same mess as packaged-staging is in atm Nov 02 21:50:20 RP: yeah may be having packaged_staging all the time would be nice Nov 02 21:50:32 yes, pstage should be mandatory Nov 02 21:50:46 damnit, i thought i had this bitbake git repo history going back farther than this.. Nov 02 21:50:48 hrm Nov 02 21:51:08 i know i did.. Nov 02 21:51:10 * kergoth sighs Nov 02 21:51:12 kergoth: Its not in my implementation so far. Its assumed to still be optional but we just take some overhead for it Nov 02 21:51:20 * kergoth nods Nov 02 21:51:24 kergoth: You did but its git rename tracking thats a pain Nov 02 21:51:31 good point Nov 02 21:51:34 kergoth: pstage should become mandatory though Nov 02 21:52:05 git log --follow Nov 02 21:52:13 --follow only works on a specific file Nov 02 21:52:19 and even then its not ideal Nov 02 21:52:35 consider the case where content was moved or copied from one file to another, not the entire file Nov 02 21:53:14 RP: anyway, was thinking that with something like that feature, you could avoid the need to include stamps in the pstage archive and playing games with them, and just not run the core tasks if the package already exists Nov 02 21:53:17 * kergoth shrugs Nov 02 21:54:08 RP: with your approarch do_install should finish before do_package or do_populate_staging Nov 02 21:54:30 yep Nov 02 21:55:02 khem: correct Nov 02 21:55:38 nice. eglibc currently has do_stage like your proposal but it races sometimes because bitbake does not follow the task order as of now Nov 02 21:55:45 kergoth: It seems it was in the initial import into OE Nov 02 21:55:54 kergoth: I can't get any further back Nov 02 21:56:16 kergoth: I think I tried something like this but it had issues that I never resolved Nov 02 21:58:43 kergoth: Haiving to call that deeply into as many check() calls could require a lot of forking Nov 02 21:59:02 I remember making the stamp code so we could check without any forks for speed Nov 02 21:59:17 * kergoth nods Nov 02 21:59:30 hmm. Nov 02 21:59:47 re ant Nov 02 21:59:52 well, i think the way pstage has to mess with them to be awfully ugly, itd be nice to find a cleaner mechanism, if it's possible to do so without horribly breaking performance Nov 02 22:00:07 kergoth: agreed Nov 02 22:00:30 kergoth: I'm not saying no, just trying to remember why it ended up like this Nov 02 22:00:34 * kergoth nods Nov 02 22:00:58 hi all Nov 02 22:01:11 it's obviously one of those things that's so deeply embedded in the operation of the system that the intrusiveness of any changes is such that it would require a great deal of thought and testing, performance and otherwise.. Nov 02 22:01:59 kergoth: check function just checks if a task needs to be rerun or not ? Nov 02 22:02:12 RP: haha, wow.. that check stuff has been there since jun 17, 2003 Nov 02 22:02:17 RP: f8580dfc74fcc153a28eb9def98bdc2a55bd3380 Nov 02 22:02:23 kergoth: yes :) Nov 02 22:02:28 bin/oebuild.. yikes Nov 02 22:02:54 kergoth: I think I even tried to remove that check call and something exploded :/ Nov 02 22:03:27 mickeyl: ping? Nov 02 22:04:45 weird Nov 02 22:05:29 kergoth, mickeyl: http://git.pokylinux.org/cgit.cgi/poky/tree/bitbake/lib/bb/build.py - is playing with builtins like that evil? Nov 02 22:05:41 It removes the need to "import bb" in every python function Nov 02 22:06:26 that feels wrong, but i'm not really sure what the alternative would be.. Nov 02 22:06:29 heh Nov 02 22:06:39 kergoth: I don't like it but it does work nicely Nov 02 22:06:46 and probably has a speed benefit Nov 02 22:07:10 * RP wonders if mickeyl has a better idea Nov 02 22:08:06 one amusing thing i ran into a while back was that often ${@} blocks use bb and os and stuff, but it's not explicitly made available to them. depending on when they're evaluated and what else is run, they could be expanded without those in the globals, and blow up Nov 02 22:08:11 iirc, anyway. Nov 02 22:08:32 * kergoth grumbles, can't concentrate today Nov 02 22:09:11 kergoth: Exactly Nov 02 22:09:32 kergoth: I had similar problems when I tried to fix the anonymous function mess Nov 02 22:09:37 ah Nov 02 22:09:48 * RP added all the functions to the methodpool and the played games to make things faster Nov 02 22:11:38 i saw that, looks like an excellent move. which reminds me, i was thinking it might be nice to merge python foo() & def functions.. there's no reason they have to be two different things. we could start allowing actual function signatures in the () in the python function declarations, and insert them all into the methodpool, not just the anonymous ones.. Nov 02 22:12:27 is the week over yet? :\ Nov 02 22:12:58 kergoth: We do insert them all into the methodpool already? Nov 02 22:13:07 kergoth: It was just the anonymous ones we didn't Nov 02 22:13:47 ah, we do? cool. well, if we let the user put a signature, we could deprecate the 'def' style functions entirely, would probably be less confusing, one less way of doing things Nov 02 22:20:25 * kergoth reads the new patches Nov 02 22:22:53 RP: wonder if we could/should use shutil.copytree() or something like it instead of forking off a cp, so we get nice exceptions rather than having to parse cp output Nov 02 22:23:03 not specific to this of course, we fork off a cp in a lot of hte python code, just musing Nov 02 22:23:46 i think that on the whole, there should be more 'forking off' Nov 02 22:23:53 :) Nov 02 22:24:10 hehe Nov 02 22:25:06 RP: packagedstageing_fastpath, should fix the typo ;) patchset looks good to me. Nov 02 22:25:08 nicely done Nov 02 22:28:46 kergoth: Yes, that would probably be good Nov 02 22:29:04 (copytree) Nov 02 22:29:10 * kergoth nods Nov 02 22:30:20 kergoth: If you could ack on the mailing list that'd be good. The question is now really how/when to merge assuming nobody comes up with a strong objection... Nov 02 22:31:04 and gah on the typo. I even C&P'd it Nov 02 22:31:47 given your implementation, i'd be inclined to say it should just go directly into .dev after acks as soon as possible, assuming personal sanity check builds succeed. thanks to the legacy bits, it probably breaks only a very small minority of recipes Nov 02 22:32:41 I'm running builds now to check things still work Nov 02 22:35:14 03Richard Purdie  07rpurdie/work-in-progress * r665bbc976e 10openembedded.git/classes/ (base.bbclass packaged-staging.bbclass): Nov 02 22:35:14 base.bbclass: Add stubs for functions when package-staging isn't active and fix a typo Nov 02 22:35:14 Signed-off-by: Richard Purdie Nov 02 22:40:53 RP: any thoughts on a removal of BBPATH and BBFILES in favor of direct bitbake support for projects and collections/overlays, in the long term? I think it would reduce some confusion Nov 02 22:41:10 kergoth: I love the idea Nov 02 22:41:36 hell yeah Nov 02 22:41:39 okay, just need to think about how to transition to such a thing.. Nov 02 22:41:54 they are a frakking nuisance :) Nov 02 22:42:05 kergoth: or add a new method and create those variables internally Nov 02 22:42:10 * kergoth nods Nov 02 22:42:23 * kergoth wanders off to pick up his gf from work Nov 02 22:42:30 kergoth: Interally they make sense and bitbake devs can cope with them :) Nov 02 22:51:52 03Thomas Kunze  07org.openembedded.dev * r0e9b71b72a 10openembedded.git/conf/machine/include/tune-strongarm.inc: tune-strongarm.inc: add EXTRA_FEED_ARCHS Nov 02 23:49:03 03Richard Purdie  07rpurdie/work-in-progress * r882364c0e4 10openembedded.git/classes/base.bbclass: Nov 02 23:49:03 base.bbclass: Fix reversed parameter typo Nov 02 23:49:03 Signed-off-by: Richard Purdie Nov 03 00:39:12 03Richard Purdie  07rpurdie/work-in-progress * r54d5f30832 10openembedded.git/classes/base.bbclass: Nov 03 00:39:12 base.bbclass: Fix staging for non-native packages Nov 03 00:39:12 Signed-off-by: Richard Purdie **** ENDING LOGGING AT Tue Nov 03 02:59:57 2009