**** BEGIN LOGGING AT Sun Oct 07 02:59:57 2007 Oct 07 04:00:13 03bzhou * r7032 10optware/trunk/ (make/busybox.mk sources/busybox/defconfig): busybox: 1.5.1 -> 1.7.2; changed busybox-links to use update-alternatives Oct 07 04:33:58 eno: busybox links alternatives - nice! Oct 07 04:34:37 i'm still working on the counterparts Oct 07 04:34:48 like coreutils, ... Oct 07 04:34:54 nod Oct 07 04:34:59 it's a big job Oct 07 04:35:35 currently the counterparts conflicts with busybox-links, which is good Oct 07 04:38:54 03bzhou * r7033 10optware/trunk/sources/adduser/defconfig: adduser: move with busybox, 1.5.1 -> 1.7.2 Oct 07 04:52:23 03bzhou * r7034 10optware/trunk/ (make/adduser.mk sources/adduser/defconfig): adduser: CONFIG_MONOTONIC_SYSCALL off unless linux 2.6 Oct 07 04:59:35 I've been optimizing the OE recipe for callweaver (formerly OpenPBX) for a while and it now seems in order. It's building from the SVN 1.2 release candidate branch. Is it worth submitting such a recipe or should fix it to a known stable changeset and/or wait for the 1.2 callweaver release? Oct 07 05:00:30 hillct: you can use SRCREV to fix it to a known stable changeset Oct 07 05:01:11 (look at the sane-srcrevs.inc file, and add the right version there) Oct 07 05:01:23 ah Oct 07 05:01:24 K Oct 07 05:01:42 my question was, more whether a non rev-fixed recipe would be accepted Oct 07 05:02:02 I can certainly set one tho Oct 07 05:02:27 -> #oe Oct 07 05:02:33 yeah Oct 07 05:10:32 03bzhou * r7035 10optware/trunk/make/adduser.mk: adduser: stupid copy-n-paste error, should use ADDUSER_BUILD_DIR Oct 07 05:34:13 03bzhou * r7036 10optware/trunk/ (3 files in 2 dirs): coreutils: use update-alternatives; worked around an update-alternatives bug with coreutils-lbracket in the place of coreutils-[ Oct 07 06:10:44 03bzhou * r7037 10optware/trunk/make/crosstool-native.mk: crosstool-native: use gcc-3.4 instead of gcc as CROSSTOOL-NATIVE_HOSTCC Oct 07 07:32:34 hi -- can somebody give me a hint what that 'zImage' actually is? 'file' doesn't give me anything useful beyond "data" Oct 07 07:32:57 is that something like bzImage on i386/x86-64? Or just ELF to something compressed? Oct 07 07:38:18 ah, ok, just compressed Oct 07 09:01:46 bwalle: it's a gzip compress kernel image Oct 07 09:02:05 with startup code, yes, I found it in Wikipedia Oct 07 09:02:15 * bwalle 's too young for zImage on x86 Oct 07 09:03:58 :) Oct 07 11:14:57 hmmm -- is it intentional that the network interface reads 00:00... for the MAC address with the 2.6.22 kernel? Oct 07 11:16:40 it also sends 00:00:00:00:00:00 to the DHCP server Oct 07 12:16:29 hm, looks like i forgot my admin password... what can i do to recover it/make a new? re-flashing is possible... Oct 07 12:18:59 if i understand correctly just flashing the linksys firmware won't help because the password is stored in another partition, right? Oct 07 12:19:54 ah, telnetintoredboot thingie, forgot that one Oct 07 13:06:43 bwalle: 2.6.22 kernel uses a new network driver that doesn't completely work yet, which is why SlugOS remains at 2.6.21 currently. Oct 07 13:07:20 ok, but the rest works ;) Oct 07 13:08:32 but I'm only experimenting Oct 07 13:10:45 bwalle: Check the archives for linux-arm-kernel for discussions; performance was a critical issue that (I think) has been almost completely addressed, but the show-stopper has been getting the firmware loaded into the driver soon enough (it's done in user-space, which precludes nfs boot with SlugOS) Oct 07 13:11:18 Your feedback, especially if you are using the most recent driver versions, will be appreciated! Oct 07 13:11:44 thanks for the information Oct 07 13:12:50 but shouldn't the MAC problem relatively easy to solve (I saw http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3596/1, but according to the comments that seems to be the wrong approach from the view of elegance) Oct 07 13:29:48 The MAC issue *should* be easy, but there is a conflict between elegance (L-A-K) and practicallity (the NSLU community). Oct 07 13:30:12 yes, but I'm using the NSLU repository ;) Oct 07 13:30:20 the CVS Oct 07 13:30:23 aeeh SVN Oct 07 13:45:30 The NSLU repo may not have the latest version, and it also still has troubles with the MAC address. I'm not sure where/how it gets its firmware, but its not via a means that the L-A-K folks would like (they want an initrd for that), but its still too late in the boot for the network to be useful for NFS boot or netconsole. Oct 07 13:45:58 Hence, SlugOS's next release is still targeted at a 2.6.21 kernel pending resolution of those issues. Oct 07 13:46:50 why is initrd too late for nfs boot? Oct 07 13:47:50 doesn't the initrd fit into the flash? Oct 07 13:49:45 It might fit, it would change the structure and thus require a rework of all the tools, including some of the user-space tools (reflash), and after all that it STILL doesn't solve the problem of nfs booting a device, or using netconsole to debug early boot problems on a console-less device. Oct 07 13:50:46 why? Oct 07 13:50:58 i.e. why it doesn't solve the problem Oct 07 13:51:10 netconsole is clear Oct 07 13:51:36 but in a 'working' environment, it should be possible to use NFS booting Oct 07 13:52:02 (I don't say that I'm a big friend of using a initrd on nslu -- don't get me wrong) Oct 07 13:55:01 bwalle: patches to the build system, the reflash utility, and all other affected places gratefully accepted. :-) Oct 07 13:55:42 ok, you got me wrong ;-( Oct 07 13:56:05 As soon as the last performance issues are resolved making the new driver on a par with the existing opensource driver, and sufficient testing has been conducted, SlugOS will fall into line with what's commited by upstream. Oct 07 13:57:51 I remain skeptical that an initrd solution will solve all the problems, but the general philosophy is to either push our patches upstream, or get rid of them. To date, the firmware loading and MAC address setting remains unresolved. Oct 07 13:59:58 For me personally, as an ex-hardware guy, I get nervous about pushing *more* stuff (like an initrd and user-space processes) in the critical path for the *ONLY* means a device has to communicate with the outside world. It makes me nervous, so I admit to bias on the entire matter. :) Oct 07 14:02:57 yes, I agree that it's bad without a serial console Oct 07 14:03:33 in a PC environment that's a different story -- rescue system, boot from CD, serial console, keyboard/mouse ... :) Oct 07 14:08:53 mwester: but where do I get the latest ixp4xx_eth patches if not from the SVN? Oct 07 14:10:48 the latest ones that nslu2 are using are in SVN. Upstream is in git somewhere (see l-a-k for the location, I forget where). We are not actively working on 2.6.22 - all our activity is on 2.6.21.6 until the ethernet patches are merged upstream. Oct 07 14:53:58 03bzhou * r7038 10optware/trunk/make/ (adduser.mk busybox.mk): adduser & busybox: turn off CONFIG_MONOTONIC_SYSCALL on fsg3v4 Oct 07 15:05:53 03bzhou * r7039 10optware/trunk/make/proftpd.mk: proftpd: 1.3.0a -> 1.3.1 Oct 07 15:49:19 03bzhou * r7040 10optware/trunk/make/netcat.mk: netcat: update-alternatives Oct 07 22:52:37 PING 1191797557 Oct 08 02:56:12 03bzhou * r7041 10optware/trunk/make/qemu-libc-i386.mk: qemu-libc-i386: do not download if crosstool version is the same **** ENDING LOGGING AT Mon Oct 08 02:59:57 2007