**** BEGIN LOGGING AT Thu Dec 14 02:59:57 2006 Dec 14 03:36:31 the newer test image on spitz seems to end up with a pink xterm Dec 14 03:36:37 what is that about? Dec 14 03:37:00 also, issuing "reboot" yields a divide by zero error the first time around Dec 14 03:38:57 and after 'ipkg upgrade' the touch screen no longer works Dec 14 03:39:00 hrmph. Dec 14 03:39:43 jnc: The colours are broken in X, afaik Dec 14 03:55:09 NAbyss: okay Dec 14 03:55:18 NAbyss: what would you suggest to use on spitz? Dec 14 04:39:56 jnc: I don't have a solution, unfortunately.. I just use 'chvt 1', then use the console.. waiting for someone to push a fix Dec 14 04:41:36 aye Dec 14 04:44:45 if someone would suggest a stable base of software that I could hack on and get fixed for spitz, I would Dec 14 07:33:18 hi hrw, hi RP Dec 14 07:58:15 hello Dec 14 08:46:52 koen: BTW where do I sign up to be an official Angstrom developer :-) Dec 14 08:47:27 * koen annoints XorA Dec 14 08:47:46 YAY, I join the annointed ones Dec 14 08:48:00 priv msg me the secret handshake :-) Dec 14 08:48:38 I should get an sl5000 zaurus tomorrow, so you might see Angstrom on collie :-) Dec 14 08:48:39 you'd have to ask mickey|zzZZzz, since he's the closet to bavaria Dec 14 08:49:00 you implemented the gcc workaround? Dec 14 08:49:40 tst lr, #1; moveq pc, lr; bx lr instead of bx? Dec 14 08:49:43 koen: I thought the patch was in OE for that Dec 14 08:49:52 only for armv4t Dec 14 08:49:59 strongarm doesn't have thumb Dec 14 08:50:21 oh, Ill have to look into that then, good thing xmas holiday start soon Dec 14 08:50:29 "Thumb interworking requires every return and indirect function call execute BX instruction (or LDR/LDM on armv5t) to set the core to the correct state. Paul Brook suggested using Dec 14 08:50:30 tst lr, #1; moveq pc, lr; bx lr Dec 14 08:50:30 as an alternative to BX, which should allow running on older, thumbless cores such as StrongArm, with the extra cost of two instructions per indirect call/function return." Dec 14 08:50:37 http://wiki.debian.org/ArmEabiPort Dec 14 08:51:51 is that a conditional return before the bx nstructions? Dec 14 08:52:01 yes Dec 14 08:52:09 bloody hell, I remembered some arm ASM Dec 14 08:52:10 (according to lennert) Dec 14 08:52:23 its been 15 years Dec 14 08:53:07 "A final option would be simply to compile the standard Debian repo --with-arch=armv4 --with-no-thumb-interwork. This would work on all processors without the dangers inherent in modifying GCC and, according to the GCC manual page, saves a slight size and speed overhead caused by being thumb-interworkable." Dec 14 08:53:10 is another option Dec 14 08:53:47 is ANgstrom planning to have different feeds, or a huge combo feed for all machines? Dec 14 08:53:48 that requires some removal of -Werror in *libc Dec 14 08:54:17 see http://www.angstrom-distribution.org/unstable/feed/ Dec 14 08:55:24 koen: cool, so the choice is an arm4 directory or fiddle with gcc Dec 14 08:55:40 yes Dec 14 08:56:17 turning off eabi for armv4(non-t) might be an option as well Dec 14 08:56:29 but one I'd like to avoid Dec 14 08:56:50 yeah, would be nice to keep things as consistant as possible Dec 14 08:57:36 I must say, things are running nice on my terrier, so if that heisenbug can be found, 2007.1 is ready Dec 14 08:58:01 then kick mozilla team to fix arm/gcc 4.1.1 Dec 14 08:59:05 I tried web, it dies very quickly Dec 14 09:03:15 since I remove all stale dbus versions, I hope all remaining dbus bugs will get fixed Dec 14 09:03:47 s/remove/removed/ Dec 14 09:05:33 yay Dec 14 09:05:39 why does 0.72 build for you? Dec 14 09:05:48 it doesn't Dec 14 09:05:59 probably some debian-isms Dec 14 09:06:00 I meant doesnt :-) Dec 14 09:06:05 my bloody typing Dec 14 11:06:03 What's the nature of the GCC bug in the latest images? Dec 14 11:07:28 if I compile it it breaks on zauruses, if Xora compiles it, it works Dec 14 11:10:01 koen you debian based like me ? Dec 14 11:10:19 yes Dec 14 11:12:29 hmm ok Dec 14 12:01:59 dbus exploit fixed: http://www.angstrom-distribution.org/repo/?action=details&pnm=dbus-1 Dec 14 12:02:28 koen: now its time to granulate dbus ;D Dec 14 12:02:49 hrw|work: that's your job ;) Dec 14 12:02:57 D Dec 14 12:03:07 when it will build I will look at it Dec 14 12:04:56 what was the gcc issue in the latest images (I was disconnected after I asked) Dec 14 12:05:40 segfaults Dec 14 12:05:43 and lots of them Dec 14 12:05:48 on zauruses Dec 14 12:05:54 oh Dec 14 12:06:13 I'll flash it, but what kind of output do we want to look at Dec 14 12:06:14 ? Dec 14 12:06:24 * lardman must remember to use question marks more often Dec 14 12:07:58 Packaged contents of dbus-lib into /home/hrw/devel/build/collie-dev/tmp/deploy/ipk/libdbus-1-3_1.0.2-r0_arm.ipk Dec 14 12:09:06 Package: bluez-utils Dec 14 12:09:06 Depends: update-rc.d, libbluetooth2 (>= 3.4), libgcc1 (>= 3.4.4), libc6 (>= 2.3.5+cvs20050627), libdbus-1-3 (>= 1.0.2), libusb (>= 0.1.12) Dec 14 12:15:17 hrw|work: and how does dbus-daemon end up in the images now? Dec 14 12:16:08 koen: install dbus in images Dec 14 12:16:36 so you just broke everything depending on a real session and system bus Dec 14 12:17:23 I don't think that is acceptable Dec 14 12:17:48 hmm Dec 14 12:18:06 I'd leave it so and make dbus RRECOMMEND dbus-session Dec 14 12:18:10 s/dbus/libdbus/ Dec 14 12:19:32 so revert this change Dec 14 12:19:44 libdbus needs a daemon to do anything usefull Dec 14 12:19:53 and ignore any granulation in OE Dec 14 12:20:08 koen: *IF* is used *AT ALL* Dec 14 12:20:10 ? Dec 14 12:20:43 hrw|work: this has nothing todo with granulation, you just broke a nearly every application depending on dbus Dec 14 12:21:13 "libdbus needs a daemon to do anything usefull" is exactly what RRECOMMENDS states imo Dec 14 12:21:28 or even RDEPENDS Dec 14 12:21:33 but more granularity is welcome imo Dec 14 12:21:38 RDEPENDS, not RRECOMMENDS Dec 14 12:21:52 good, then RDEPENDS is a compromise. Dec 14 12:21:58 do we all agree? Dec 14 12:22:03 if I delete dbus-1 from the feeds everything will happily install and be utterly broken Dec 14 12:22:12 pushed fix Dec 14 12:22:14 ok Dec 14 12:22:18 doesn't the RDEPENDS negate the granularity? Dec 14 12:22:27 i don't think so Dec 14 12:22:44 mickeyl: it does Dec 14 12:22:45 but that's a personal feeling Dec 14 12:22:46 if you can't have the one without the other, then why are they seperate? Dec 14 12:23:02 well my idea had been RRECOMMENDS :D Dec 14 12:23:13 I added rrecommends recently Dec 14 12:23:36 might want to put this up to the list Dec 14 12:23:46 let's get some more opinions Dec 14 12:24:49 till then lets unbreak it Dec 14 12:56:56 apps should depend on libdbus, distro/imagetype should REDEPEND on dbus-session Dec 14 12:57:16 as only the distro knows dbus sessions will actually be used Dec 14 13:05:44 but what happens if I build say, gnumeric for sharprom-compatible Dec 14 13:05:58 or install gnumeric inside bootstrap-image Dec 14 13:06:05 how will I get dbus-session? Dec 14 13:07:54 brb, reboot Dec 14 13:09:54 since when gnumeric need dbus? :P Dec 14 13:10:21 hrw|work: I was gonna say that, most apps, can use dbus, many dont "need" dbus Dec 14 13:12:52 Good morning Dec 14 13:14:19 I'd like to try flashing the latest Angstrom build onto my Akita, but I can't tell which file I need to rename to be initrd.bin Dec 14 13:14:44 Angstrom-bah-image-*jffs2* Dec 14 13:15:24 Excellent. Thank you! Dec 14 13:20:34 * XorA hits the problem where initrd is garbaged :-( Dec 14 13:27:47 "sd card not found -- error 1" would indicate that you can't flash off a 1 GB card, right? Dec 14 13:31:27 Can I try altbooting the new build? None of the downloadable files for the akita end in .tar.gz. Dec 14 13:42:13 Would anyone like to hear the results of flashing my akita (I will send out an e-mail to the dev list) Dec 14 13:43:02 sure Dec 14 13:46:33 It appears that the jffs image is bad. It gives me several pages of warnings (empty flash at location x, Magic bitmask not found) before claiming to have mounted the root readonly. Dec 14 13:46:50 Armagon: I see same here Dec 14 13:46:53 Then I'm told it is "Freeing init memory: 80K" and nothing else happens Dec 14 13:46:56 on c860 Dec 14 13:47:59 NOTE: package wireshark-0.99.4-r0: task do_build: completed Dec 14 13:49:10 koen: yeah, Angstrom Z jffs2 images are fscked Dec 14 13:49:20 koen: both yours and one I built Dec 14 13:49:58 well, that's a shame. Dec 14 13:52:38 Is there anything else I can try at the moment, or is that that for now? Dec 14 13:56:25 seems that the flash header never got written to the image Dec 14 14:01:34 XorA: that seems to suggest that z images are broken in .dev Dec 14 14:02:56 NOTE: Executing mkfs.jffs2 --root=/home/gg/zaurus/build-c7x0/tmp/rootfs --output=/home/gg/zaurus/build-c7x0/tmp/deploy/glibc/images/c7x0/Angstrom-gpe-image-test-20061214-c7x0.rootfs.jffs2.bin --little-endian --eraseblock=0x4000 --pad --faketime -n Dec 14 14:03:03 no sign of the cat to add the header Dec 14 14:03:29 stuff in machine.conf is ignored Dec 14 14:03:41 or overwritten somewhere Dec 14 14:03:51 XorA: check include/zaurus-2.6.conf Dec 14 14:04:10 ./include/zaurus-2.6.conf:11:IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2.bin ${EXTRA_IMAGECMD}" Dec 14 14:04:18 ./include/zaurus-clamshell.conf:13:IMAGE_CMD_jffs2 += "; cat ${STAGING_LIBDIR}/sharp-flash-header/header-c700.bin \ Dec 14 14:05:06 hrw|work: machine.conf is right, Angstrom is eating the config somewhere Dec 14 14:05:57 ./include/angstrom.inc:45:IMAGE_NAME = "${DISTRO_NAME}-${IMAGE_BASENAME}-${DISTRO_VERSION}-${MACHINE}" is the only suspicious one Dec 14 14:11:49 bah and heisenbug hasd returned Dec 14 14:17:40 XorA: the zaurus machine includes are buggy Dec 14 14:18:10 XorA: zaurus-clamshell.conf sets IMAGE_CMD += "
" Dec 14 14:18:36 zaurus-2.6.conf, which is included after that does IMAGE_CMD = "" Dec 14 14:18:56 XorA: so anything done in zaurus-clamshell.conf is blown away Dec 14 14:19:02 hrw|work: did you now clean that a couple of days ago Dec 14 14:20:00 the only difference I see is "--faketime" Dec 14 14:20:38 bloody hell Dec 14 14:23:43 I cleaned.. Dec 14 14:23:44 shit Dec 14 14:23:51 could one of the 1337 Z hackers fix it? Dec 14 14:24:34 pushed Dec 14 14:24:42 thanks Dec 14 14:24:45 :-D Dec 14 14:24:52 close 1680 when tested then :-) Dec 14 14:29:30 koen: I think heisenbug might be that zlib bug Dec 14 14:45:46 koen: I get segfault when boot of flash, same image on SD card doesnt, I think you found our culprit Dec 14 14:46:11 koen: you should pass that bug report to RP and it was posted by someone else on arm-kernel and he didnt quite beleive it Dec 14 14:51:25 XorA: could you open a bug in the OE bugtracker about it? Dec 14 14:52:14 another reason to switch to logfs Dec 14 14:52:30 * RP does believe the bug report. I just don't see how it can be zlib at fault Dec 14 14:55:24 RP: oh hello :-) Dec 14 14:59:39 #1684 Dec 14 15:20:08 hrw|work: OOM error on 2.6.19 seems to kill kernel completely Dec 14 15:20:16 hrw|work: Ive gone back to 2.6.18 Dec 14 15:20:33 ops. Dec 14 15:20:42 I wonder which kernel to use for OZ 3.5.5 Dec 14 15:21:19 * XorA boots on SD and sees no segfaults Dec 14 15:25:13 hrw|work: 2.6.18 oopses when inserting a Sandisk Connect+ Dec 14 15:27:40 can you add it into OE bugtracker? Dec 14 15:28:32 XorA: how do you boot off of SD? I am trying CoreDump's modified kernel and It looks like / is getting mounted twice Dec 14 15:28:49 hvontres|poodle: root=/dev/mmcblk0p1 on commandline Dec 14 15:30:08 XorA: That is the same thing I use. but now I get rootfs on / type roofs and /dev/root on / type ext2 Dec 14 15:30:40 hrw|work: #1685 Dec 14 15:30:41 XorA: and if I try to remount / as ro on reboot that screws things up. Dec 14 15:31:02 thx Dec 14 15:31:03 hvontres|poodle: I get that, seems to work Dec 14 15:31:43 XorA: hmmm...every time I reboot I get told that my SD card was not cleanly unmounted :( Dec 14 15:32:24 hvontres|poodle: is that not the divide by zero problem Angstrom has Dec 14 15:32:38 XorA: ?? Dec 14 15:33:57 XorA: actually, I am still running a OZ 3.5.4.2 image. I just noticed you booted from SD and I haven't been able to get a hold of CoreDump in a while Dec 14 15:34:24 hvontres|poodle: I did edit fstab to the right file systems Dec 14 15:34:28 For reference, pxa27x_udc is broken over suspend/resume in 2.6.19 Dec 14 15:35:49 irda is broken in 2.6.18 Dec 14 15:39:36 koen: tied #1684 to Angstrom release metabug Dec 14 15:39:45 thanks Dec 14 15:40:13 koen: and duped 1629 which is same bug, less info Dec 14 15:40:25 nice Dec 14 15:42:05 koen: anyplans to respin the Z images tonight? Dec 14 15:42:54 doing it as we speak Dec 14 15:43:08 it was foolish enough to clean out deploy/ipk Dec 14 15:43:19 so it will take a while Dec 14 15:44:50 koen: build from feeds :-) Dec 14 15:45:19 can't find the patch :( Dec 14 15:45:57 koen: going to make the flash ones boot from SD? Dec 14 15:46:06 good point Dec 14 15:46:06 or force people to debug the issue Dec 14 15:46:24 the latter Dec 14 15:46:29 (or switch to 2.6.17) Dec 14 15:46:43 which presents a problem for people doing 'ipkg upgrade' Dec 14 15:46:51 ~lart kernel partitions Dec 14 15:47:14 2.6.19+2.6.17-going-backwards :-) Dec 14 15:49:45 hrw|work: have you created a oz3.5.5 meta bug yet? Dec 14 15:49:56 hrw|work: if you do we could link in problem bugs Dec 14 15:50:40 XorA: there is one Dec 14 16:19:58 hey pH5 Dec 14 16:20:09 hey koen Dec 14 16:24:05 thats enough debugging today Dec 14 16:24:18 Im off home to meet the Rents and have chinese food Dec 14 16:26:51 mmmm Dec 14 16:26:53 chinese food **** ENDING LOGGING AT Fri Dec 15 02:59:57 2006