**** BEGIN LOGGING AT Sun Nov 12 02:59:57 2006 Nov 12 03:02:19 <[g2]> in many way Debian is a great and wonderful thing Nov 12 03:02:34 <[g2]> in many ways there is lots of room for improvment Nov 12 03:02:45 <[g2]> s/improvment/improvement/ Nov 12 03:02:47 [g2] meant: in many ways there is lots of room for improvement Nov 12 03:04:48 Hmm - the 2.6.18 patchset in OE right now seems to be parsing the fis directory incorrectly. Nov 12 03:05:26 <[g2]> rwhitby I noticed that earlier today Nov 12 03:05:34 <[g2]> your post Nov 12 03:05:53 is that new 02 patch incorrect? Nov 12 03:06:03 (cause that's all that's changed in that area) Nov 12 03:10:08 <[g2]> rwhitby new as in a couple weeks old 02 patch right ? Nov 12 03:10:13 yep Nov 12 03:10:26 but I haven't tested an OE image in at least three weeks Nov 12 03:10:40 and I don't know if anyone has tested a 2.6.18 kernel built from our repo in that time Nov 12 03:11:24 rwhitby: I was using the 02 patch with a 2.6.18 Debian kernel and it was working Nov 12 03:11:40 hmm, ok. Nov 12 03:14:06 dumfrac: have you any input (from a Debian point of view) where to put the microcode? Nov 12 03:14:18 03bzhou * r4446 10optware/trunk/ (Makefile make/squid.mk sources/squid/control): squid: native -> cross, upgrade to 2.6.STABLE5 Nov 12 03:14:34 I'm currently thinking of putting it at the end of the sysconf area Nov 12 03:14:51 Martin is not putting it in flash at this stage (i.e for etch), so no Nov 12 03:14:57 (then it doesn't get overwritten by a normal flash) Nov 12 03:15:31 not putting it in cause we've not determined it yet, or doesn't want to put it in even if we had decided where and how ? Nov 12 03:15:59 I can test that out with a Debian kernel and apex if you upload a revision of slugimage Nov 12 03:16:34 03g2-tbillman * r570 10kernel/trunk/patches/2.6.19/ (4 files): Nov 12 03:16:34 Update 33-mac patch to handle the case for change the hw addr when the interfaces is down. Update the Loft support Nov 12 03:16:34 to actually copy the MAC via the EEPROM notifier. Nov 12 03:16:38 dumfrac: does your kernel have the patch which reads the microcode directly from mtd? Nov 12 03:17:23 not putting it in because it works loading it from /lib/firmware Nov 12 03:17:46 no - on the patch to read the microcode from firmware - I've never tried it Nov 12 03:17:54 right, but how do you get the microcode into /lib/firmware in the first place? Nov 12 03:18:06 (and still release a dfsg compliant image)? Nov 12 03:18:08 <[g2]> magic Nov 12 03:18:25 <[g2]> black magic :) Nov 12 03:18:41 ah - I'm not sure how Martin is going to conjure that trick :-) Nov 12 03:19:17 cause the installer needs the on-board ethernet up so it can download a package to put it in /lib/firmware Nov 12 03:19:39 unless martin just intends continuing to release debian images through slug-firmware.net Nov 12 03:19:46 yeah, I know Nov 12 03:19:58 I'm not sure - I can find out Nov 12 03:20:08 [g2]: Loft doesn't care, right, cause you just get it out of RedBoot. Nov 12 03:20:27 <[g2]> rwhitby yeah the Loft pull from RedBoot Nov 12 03:20:35 For the NSLU2, we can't put it in FIS, cause redboot or a reflash clobbers it. Nov 12 03:21:06 I think SysConf is the only reasonable place in the NSLU2, given that we want to preserve it across flashes of free images. Nov 12 03:21:31 I agree - right now Martin has a patch to read the MAC address from flash in the Debian kernel Nov 12 03:21:36 <[g2]> rwhitby linksys reflash may trash that too Nov 12 03:21:50 nope Nov 12 03:21:59 he didn't really care that it wan't going to be accepted upstream - he just wanted something that worked for now Nov 12 03:22:28 so I suspect that a patch to read the microcode from flash would be accepted into the Debian kernel (for now) Nov 12 03:23:19 unless, as you say, he plans to keep on distribution the installer through slug-firmware.net Nov 12 03:23:34 s/distribution/distributing Nov 12 03:24:16 rwhitby: would you like me to find out from Martin ? Nov 12 03:25:09 sure. he's certainly welcome to keep distributing through slug-firmware.net - we're not trying to push him out or anything. Nov 12 03:26:05 ok - I'll get back to you - I'm interested too :-) Nov 12 03:26:19 for the NAS100d, it has real fis dir support, so it doesn't really matter where we put the microcode Nov 12 03:26:35 what are our other targets? Nov 12 03:26:55 dsmg600? what's the fis layout for that, and does it have fis support in redboot? Nov 12 03:40:46 03bzhou * r4447 10optware/trunk/Makefile: promote squid for fsg3 and ds101g Nov 12 03:47:00 03rwhitby * r76 10slugimage/trunk/slugimage: Moved the debug message for finding unallocated pseudo partitions inside the validation check Nov 12 03:57:29 FSG-3 mtd partition map is: Nov 12 03:57:32 ~ # cat /proc/mtd Nov 12 03:57:33 dev: size erasesize name Nov 12 03:57:33 mtd0: 00040000 00020000 "RedBoot" Nov 12 03:57:33 mtd1: 00180000 00020000 "kern1" Nov 12 03:57:33 mtd2: 00180000 00020000 "kern2" Nov 12 03:57:33 mtd3: 00020000 00020000 "RedBoot config" Nov 12 03:57:35 mtd4: 00020000 00020000 "FIS directory" Nov 12 04:09:20 Creating 5 MTD partitions on "IXP425 Flash": Nov 12 04:09:20 0x00000000-0x00040000 : "RedBoot" Nov 12 04:09:20 0x00080000-0x00200000 : "kern1" Nov 12 04:09:20 0x00200000-0x00380000 : "kern2" Nov 12 04:09:20 0x003c0000-0x003e0000 : "RedBoot config" Nov 12 04:09:21 0x003e0000-0x00400000 : "FIS directory" Nov 12 04:09:38 Looks like there is a spare 256KB after RedBoot, before kern1. Nov 12 04:10:21 Will need to look at the fsg-3 upgrade scripts to see if changing the mtd numbering will confuse it ... Nov 12 04:14:23 rwhitby: dsmg600: http://pastebin.com/822309 Nov 12 04:15:18 mwester: what is preserved on a flash upgrade? Nov 12 04:16:29 and how big is the data in sysconfig? Nov 12 04:18:44 No flash upgrade utility; all done manually using xmodem, and the fis write commands. Currently, only the "kernel" and "filesystem" partitions are used. "sysconfig" is not used/recognized by openslug; I don't know how much the native firmware actually uses. Frankly, I don't know of anyone who has ever tried to put back the original firmware; it may not even work (I've saved it, but I... Nov 12 04:18:46 ...don't know if I did it correctly, and I've also never decoded what D-Link's format for the flash.bin file is... Nov 12 04:19:36 It has double the flash, and doesn't seem to make any effort to use it efficiently -- kinda like the firmware equivalent of "urban sprawl" Nov 12 04:21:05 * mwester can try to reload the original fw and see what the sysconfig partition looks like... Nov 12 04:30:52 mwester: sysconfig should be able to be used in slugos by sysconf preserve Nov 12 04:31:14 then it can save and restore all your network information and ssh keys and config files over reflashes of the kernel and rootfs Nov 12 04:31:35 then we can also put the microcode in there too. Nov 12 04:33:35 I've never tried, actually -- does sysconfig have a specific "format" for the data stored, such that slugos won't overwrite the Linksys info on the NSLU2? Is the concern then that we not overwrite D-Link's equivalent? Nov 12 04:40:07 good question Nov 12 04:40:20 can you flash stock and dump that mtd partition? Nov 12 04:41:01 for the NSLU2, we preserve the information in sysconfig, and people *can* flash back Unslung and still have the basic settings intact Nov 12 04:42:45 * mwester thinks he has a dd of that partition lying about... Nov 12 04:43:06 What do you need from it? Nov 12 04:48:03 Ok, I just decoded the DSM's firmware format. Nov 12 04:48:31 The filename gives it away ;) :D "DSMG600_firmware_101.tar" Nov 12 04:50:40 The content is: ip-ramdisk, version.msg, usr.cramfs, and rootfs.gz Nov 12 04:51:00 Ok, yes, I do have an image of the sysconif partition as well. Nov 12 04:56:27 03bzhou * r4448 10optware/trunk/make/squid.mk: squid: disable-epoll Nov 12 05:00:33 what's a hexdump of the sysconf partition reveal? Nov 12 05:00:45 mwester: is it just a length followed by null-terminated strings? Nov 12 05:03:15 00000000 00 99 00 00 67 72 6f 75 63 68 00 30 00 00 00 00 |....grouch.0....| Nov 12 05:03:41 00000030 00 00 4c 49 4d 42 4f 00 4f 55 50 00 00 00 00 00 |..LIMBO.OUP.....| Nov 12 05:03:58 make sure your password is not in the paste :-) Nov 12 05:04:07 grouch is the hostname. LIMBO is the workgroup. Nov 12 05:04:29 is the 00 99 a length ? Nov 12 05:04:34 :) Yeah, that starts in byte 0x9d Nov 12 05:04:47 Followed by my WEP key as well :D Nov 12 05:04:52 Lemme count the 99... Nov 12 05:06:17 Hard to tell. Might be garbage, but it has data (with lots of 0x00s in there) up to 0x33F, then 0xFF to the end (erased data, I presume) Nov 12 05:06:54 so nothing that couldn't be restored through the web interface Nov 12 05:07:37 does it get deleted if you do a stock firmware upgrade Nov 12 05:07:37 ? Nov 12 05:07:37 No, it's preserved. Nov 12 05:08:20 BTW, it also appears that there's /dev/mtdblock4, which corresponds to a hole in the "fis list" command output -- 256KB Nov 12 05:08:39 It's empty. Nov 12 05:08:42 can you put some data at the end of it, then see if that data is preserved if you make a change in the web config ? Nov 12 05:08:47 (at the end of sysconfig) Nov 12 05:09:08 I'll have to reload the stock FW, and try that. Nov 12 05:10:36 * mwester goes to fire up xmodem Nov 12 05:11:16 mwester: so we could potentially create a DSMG600_firmware_101.tar as an upgrade image? Nov 12 05:12:29 I think we might. I'll dig into that a bit when I get the stock fw reloaded and see just how general the interface might be. Nov 12 05:13:50 we can get OE to write out that file Nov 12 05:19:33 First glance - there is no header info on the files in the tarball - rootfs.gz is just burned directly to the flash, bit for bit. Nov 12 05:20:07 No kernel included in the tar file, so I don't know how that's done - I'll poke around to figure that out. Nov 12 05:21:02 * mwester needs a way to tell dd to strip off trailing 0xff sequence from a file... Nov 12 05:25:25 ip-ramdisk is not the kernel? Nov 12 05:26:56 Errr, um... Nov 12 05:27:12 Yes. it most certainly is. What a strange name for a kernel. Nov 12 05:28:06 named after it's kernel cmdline options Nov 12 05:29:53 so are you going to construct an upgrade file and try it out? Nov 12 05:29:54 Good grief. The kernel is <1MB; flash has room for 2MB. The filesystems total 6.3MB, flash has room allocated for 12.5MB. Nov 12 05:30:34 Yep, I'll give it a shot. Nov 12 06:08:07 mwester: in packages/images/slugos-image.bb, we can change SLUGOS_FLASH_IMAGE from 'yes' to 'nslu2' and then add additional code to support a 'dsmg600' option for that variable. Nov 12 06:08:07 I'll do the first bit if you want to do the second bit. Nov 12 08:26:14 Hi guys, can someone please help me figure out why my hdd keeps spinning up and down all the time? I want it to stay spinned down. Nov 12 08:26:25 drif: Are you awake? Nov 12 08:30:35 I've moved /var/log and /dev to ramdisk Nov 12 08:30:46 I've disabled most cron jobs Nov 12 08:31:02 I've disabled swapping Nov 12 08:31:30 What more do I need to do to make it stop accessing the disk? Nov 12 08:34:53 Tobbe: there is a technique on the wiki to find out what is causing that Nov 12 08:35:46 I'm running unslung, and it says it doesn't work there (and that seems to be true, because I couldn't see anything in dmsg) Nov 12 08:40:14 oh, dunno then. Nov 12 08:40:49 does it do it when you disable optware (i.e. ugo-x on rc.optware) ? Nov 12 08:41:59 I haven't tried that Nov 12 08:44:08 where would I find rc.optware? Nov 12 08:44:34 in /etc/init.d/ or something like that Nov 12 08:44:40 maybe rc.d Nov 12 08:44:44 there are two files called rc.optware-start and rc.optware-stop in /etc/rc.d Nov 12 08:44:52 that's them Nov 12 08:45:03 I don't have a /etc/init.d/ directory btw... Nov 12 08:45:46 right, that's slugos Nov 12 08:49:08 ok, permissions changed, now let's see if it makes any difference :) Nov 12 08:55:38 FYI all: Both SlugOS and Unslung images build under CentOS 4 Nov 12 08:57:36 Hmm - svn kernel repo 2.6.19-rc5 finds fis partitions fine, whereas OE 2.6.18 kernel doesn't Nov 12 09:36:25 The hdd span down now Nov 12 09:41:49 And now it's spinning up again... Nov 12 09:42:10 rwhitby: I guess it didn't help... Nov 12 09:46:05 http://www.cs.cmu.edu/~mukesh/hacks/spindown/x82.html Nov 12 09:49:18 I don't think I want to mess with kernel patches... (I wouldn't even know how to on my slug...) Nov 12 09:55:30 Tobbe, I was only refering to the "sources of I/O" :) Nov 12 13:12:05 <[g2]> GPSFan fyi r 570 has all the bits for the Loft/Avila to load the MAC addresses from EEPROM, an upstream compatible solution is under investigagtion Nov 12 13:12:56 [g2]: morning, well I guess i missed it. Have to look again when I wake up a bit more. ;>) Nov 12 13:20:21 [g2]: no wonder I missed it, I was still looking for the patch in my un-updated patches dir :P thanks.. Nov 12 13:21:02 <[g2]> GPSFan np. Nov 12 13:23:07 <[g2]> GPSFan I think we are in good shape. I don't think there are any open issues right now. There are some upstream merge issues regarding the GPL NPE drivers, but those will get worked out over time. Nov 12 13:28:26 [g2]: that's great, I've been playing with quilt, and today will try to apply the 570 patch set to a clean kernel. We should just fine when 2.6.19 is released. Nov 12 13:29:51 <[g2]> GPSFan nod. It been like this for many of the 2.6 kernel releases since .11 Nov 12 13:31:36 [g2]: well as stuff becomes more stable and gets merged into mainline, the bug squashing should decrease a bit.;>) Nov 12 13:32:27 <[g2]> GPSFan actually it's a process, there are often new things Nov 12 13:32:58 <[g2]> like now the LED needs to be turned on. That's the next open thing Nov 12 13:33:00 [g2]: sure, new features, whether desired or not, often bring breakage. Nov 12 13:33:37 <[g2]> and BE testing for mw Nov 12 13:33:44 <[g2]> s/mw/me/ Nov 12 13:33:44 [g2] meant: and BE testing for me Nov 12 13:50:04 hmm Nov 12 13:50:29 * NAiL notes that the optware makefile isn't really set up for building anything in buildroot if it isn't mipsel. Nov 12 13:54:31 <[g2]> NAiL are you familiar with the openwrt build-ng ? Nov 12 13:54:51 not at all, I haven't touched openwrt for a couple of years ;) Nov 12 13:55:15 <[g2]> they been working on a new build system, just menuconfig the processor and off you go Nov 12 13:55:23 neat Nov 12 13:55:26 <[g2]> I've built for the ixp4xx Nov 12 13:55:58 <[g2]> I haven't gone back and tweaked the kernel to match, but the rootfs runs in chroot Nov 12 13:56:17 <[g2]> they were 2.6.17 based a couple weeks ago Nov 12 13:59:21 there's no config option for powerpc, I can see Nov 12 14:02:58 I guess I'll have to add ;) Nov 12 14:29:00 [g2]: just built the 2.6.19-rc5 from a clean tarball with the latest 570 patches. I'm not seeing the mac address being set from the eeprom. is there a config setting to enable this? Nov 12 14:33:41 GPSFan: does the ad7418 driver works fine for you? Nov 12 14:37:36 [g2]: ping Nov 12 14:37:54 dwery: no, it looks like it is missing, but the rtc is ok and the eeprom shows up in /sys/devices/platform/IXP4XX-I2C.0/i2c-0/0-0051 Nov 12 14:38:09 can you try compiling and loading it? Nov 12 14:39:50 dwery: the hwmon is missing 'cause it was set as a module. hold on a min.. Nov 12 14:39:56 ok Nov 12 14:43:54 <[g2]> dwery pong Nov 12 14:44:35 <[g2]> GPSFan oh, did you copy the loft_defconfig over the defconfig ? Nov 12 14:44:41 [g2]: can you check the ad7418 driveR? Nov 12 14:45:13 <[g2]> modprobe ad7418 Nov 12 14:45:13 <[g2]> ad7418 0-0028: chip found, driver version 0.2 Nov 12 14:45:19 <[g2]> dwery what should I check Nov 12 14:45:49 does the sensors utility give any output? Nov 12 14:46:26 <[g2]> 52500 Nov 12 14:46:34 <[g2]> doh!... Nov 12 14:46:41 can you paste me the complete output? Nov 12 14:46:43 <[g2]> "/sys/bus/i2c/devices/0-0028# cat temp1_input Nov 12 14:46:44 <[g2]> 52500 Nov 12 14:47:17 * [g2] gets out the multimeter Nov 12 14:47:30 what /usr/bin/sensors is saying? Nov 12 14:47:48 that would be 52.500 celsius... Nov 12 14:47:54 quite hot :) Nov 12 14:48:10 <[g2]> umm not really Nov 12 14:48:28 ok, so the driver is working fine :) Nov 12 14:48:30 <[g2]> there's about 33 C headroom Nov 12 14:48:43 <[g2]> dwery I should check the temp Nov 12 14:48:45 I want to check if sensors and libsensors are working too Nov 12 14:48:57 <[g2]> I think the box was running all night Nov 12 14:49:41 * [g2] reboots topless Nov 12 14:58:05 <[g2]> cat temp1_input Nov 12 14:58:05 <[g2]> 44000 Nov 12 14:58:23 * [g2] touches temp probe to chip Nov 12 15:00:12 <[g2]> dwery I get 43 C around the center of the chip Nov 12 15:00:23 ok Nov 12 15:00:31 and bin/sensors ? Nov 12 15:01:16 dwery: mine is reading 35500, seem to be working. [g2] my mistake, I think the mac is getting set properly, the mac address I saw inifconfig is different than it used to be, but that was on another board. what's in the /sys/devices/platform/IXP4XX-I2C.0/i2c-0/0-0051/eeprom matches the mac address. ;>) Nov 12 15:01:22 [g2]: sorry for the confusion. Nov 12 15:01:28 dwery: mine is now reading 40500 so the temp is rising. Nov 12 15:01:51 <[g2]> http://pastebin.ca/246697 Nov 12 15:02:20 ok, sensors needs to be instructed. Nov 12 15:02:20 <[g2]> GPSFan np. Nov 12 15:02:37 * [g2] hits sensors with a cluestick Nov 12 15:02:38 bbl Nov 12 15:02:45 :-D Nov 12 15:02:53 <[g2]> dwery instructed how ? Nov 12 15:03:08 probably a few lines of C code Nov 12 15:03:13 added to its source Nov 12 15:03:41 <[g2]> sensors looks neat! Nov 12 15:04:04 <[g2]> is a command line C program that dumps the sensor information ? Nov 12 15:04:10 yes Nov 12 15:04:13 <[g2]> awesome Nov 12 15:06:24 care to patch it? :) Nov 12 15:06:38 <[g2]> sensors ? Nov 12 15:06:42 yes Nov 12 15:07:53 * [g2] doesn't know where to begin Nov 12 15:07:58 should be pretty easy but I don;'t have the time :( Nov 12 15:08:19 by downloading the source. apt-get source sensors :) Nov 12 15:08:26 <[g2]> dwery I figured that Nov 12 15:08:30 :-D Nov 12 15:10:03 <[g2]> dwery I'd guess the ad7418 and the RTC driver should be updated in sensors Nov 12 15:10:43 yes. a definition should be added to tell him of the features of the ad7418. I don't think sensors handles rtc chips. Nov 12 15:10:53 basically, it's a definition and a print routine Nov 12 15:11:46 eventually sensors-detect can be patched to recognize the chip. Nov 12 15:12:35 what sensors-detect is saying on the loft? Nov 12 15:14:49 <[g2]> http://pastebin.ca/246702 Nov 12 15:15:07 :-D Nov 12 15:15:11 please unload the drivers :) Nov 12 15:15:19 except rtcm which is probably builtin.. Nov 12 15:15:25 <[g2]> the eeprom driver is built-in Nov 12 15:16:20 in theory there's a method to unbind a driver froma device at runtime, but it's probably dangerous. Nov 12 15:16:32 I think you can redo the test with just the ad7418 unloaded Nov 12 15:16:51 <[g2]> http://pastebin.ca/246704 Nov 12 15:17:25 good. it is not misidentifying the chip Nov 12 15:17:49 I'll try to come up with a detection routine, it should be pretty easy Nov 12 15:18:53 bbl Nov 12 15:32:46 03bzhou * r4449 10optware/trunk/make/tar.mk: tar: upstream upgrade to 1.6 Nov 12 16:30:28 03bzhou * r4450 10optware/trunk/make/tar.mk: tar: workaround the lacking of wchar on wl500g Nov 12 17:09:06 03bzhou * r4451 10optware/trunk/ (3 files in 3 dirs): bogofilter: native -> cross Nov 12 17:36:01 03bzhou * r4452 10optware/trunk/make/bogofilter.mk: bogofilter: specify ACLOCAL and AUTOMAKE Nov 12 19:23:42 Anyone feel like helping me add a new target to optware? Nov 12 19:23:48 * NAiL could throw a couple of $ to a helping hand ;) Nov 12 19:26:11 I need a little help getting buildroot set up. I've only used crosstool in optware so far :-\ Nov 12 20:48:21 NAiL: i'd like to, but i'm not familar with buildroot either, maybe oleo or dyoung can help Nov 12 20:49:08 03bzhou * r4453 10optware/trunk/ (make/bogofilter.mk sources/bogofilter/configure.ac.patch): bogofilter: upgrade to 1.1.1 Nov 12 20:50:15 03nail 07slugos-3.10-beta * r383 10slugos/openembedded/packages/asterisk/asterisk-1.2.13/ (4 files): asterisk: Add forgotten patches for 1.2.13 Nov 12 21:01:36 NAiL: just shoot. I worked with buildroot up to the time I switched to OE. Nov 12 21:02:12 NAiL: but don't throw anything at me please. Nov 12 21:07:42 I'm not quite sure where to start ;) Nov 12 21:08:11 NAiL: you just want to build? Nov 12 21:08:50 NAiL: which buildroot exactly? From which project? Nov 12 21:09:06 optware Nov 12 21:09:40 The target is the ts-101. So I need to set up a toolchain for ppc uClibc Nov 12 21:13:28 NAiL: The first buildroot just was started with "make menuconfig" Nov 12 21:13:41 but I am downloading the optware one now, co from svn Nov 12 21:14:56 I'm working myself through the menuconfig right now Nov 12 21:16:10 Is there a way to figure out which compiler was used to compile uClibc? Running /lib/libc.so doesn't work like it does on glibc Nov 12 21:16:26 NAiL: not that I know Nov 12 21:18:47 NAiL: Did you have to edit the Makefile beforehand? My "make" is downloading GCC versions before I could tell which toolchain I wanted. Nov 12 21:19:15 NAiL: this is the not the original buildroot from busybox.net Nov 12 21:19:32 no, the makefile pulls and builds buildroot Nov 12 21:19:38 but you need to set the correct target Nov 12 21:19:48 I've made a simple ts101 target Nov 12 21:20:36 try OPTWARE_TARGET=wl500g to see how it works Nov 12 21:21:13 that target uses buildroot Nov 12 21:21:41 ie, OPTWARE_TARGET=wl500g make Nov 12 21:24:11 NAiL: oleo did the buildroot package I think Nov 12 21:24:22 yeah, his name is a couple of places there Nov 12 21:24:36 it appears to be made for mips *only* though Nov 12 21:25:12 yep - that was his target set Nov 12 21:25:39 back later (off to work) Nov 12 21:27:34 NAiL: I would use crosstool to build a powerpc toolchain. Then just override cross.bbclass and try OE. Nov 12 21:28:59 likewise: does crosstool work with uclibc nowadays? Nov 12 21:29:41 http://www.kegel.com/crosstool/current/doc/crosstool-howto.html#uclibc Nov 12 21:30:27 ah Nov 12 21:30:55 still have the problem of baking it all into the optware Makefile though :-\ Nov 12 21:33:40 NAiL: What's your aim? Nov 12 21:34:01 NAiL: toolchain? or complete target image? (or both? :-) ) Nov 12 21:35:03 Being able to automatically build a toolchain and a set of packages Nov 12 21:35:31 Building an image is irrelevant at this point :-P Nov 12 21:36:45 I don't need to build an image until I get a custom kernel running. And that's a little while into the future ;) Nov 12 21:38:05 NAiL: I just downloaded the original buildroot, that one can make powerpc toolchains and packages. Nov 12 21:38:15 with uclibc Nov 12 21:38:24 http://buildroot.uclibc.org/subversion.html Nov 12 21:38:30 ah Nov 12 21:39:13 NAiL: that's the original buildroot (it was later forked by projects such as optware, and openwrt if I'm not mistaken Nov 12 21:43:50 NAiL: I think the trick still is, to find a proper set of versions for the toolchain, kernel, uclibc, etc. that work. Nov 12 21:50:53 kernel should be 2.6.12.3, uClibc 0.9.27. I don't know about the toolchain yet Nov 12 21:52:09 NAiL: I just started a 4.1.1/2.17/2.6.18/uClibc-cvs build for powerpc... Needed to install the unifdef package on my host. Nov 12 21:53:05 NAiL: we are probably on the wrong channel :-) Nov 12 21:54:02 not really ;) Nov 12 21:54:09 what other channel would you suggest= Nov 12 21:54:10 ? Nov 12 21:54:21 no, never mind, just kidding. Nov 12 21:54:26 best devs are here :-) Nov 12 21:54:32 morning Nov 12 21:54:36 morning Nov 12 21:54:43 (irc)morning szafran. Nov 12 21:55:08 timesys going down: http://landley.net/notes.html Nov 12 21:55:15 read Rob's 6 nov entry Nov 12 21:55:39 not exactly news ;) Nov 12 21:55:53 I read it the 6th, I think Nov 12 21:56:11 <[g2]> likewise what that the implosion one ? Nov 12 21:56:24 <[g2]> s/what/was/ Nov 12 21:56:24 [g2] meant: likewise was that the implosion one ? Nov 12 21:56:36 03bzhou * r4454 10optware/trunk/make/php.mk: php: use latest template to trigger a rebuild, should recover lost secondary ipks Nov 12 21:56:47 [g2]: last toolchain dev 2 weeks notice Nov 12 22:05:07 likewise: waddayouknow.. Crosstool is included in the source tarball from qnap Nov 12 22:05:43 NAiL: good. didn't know they releases sources already? Nov 12 22:05:54 s/releases/releasede Nov 12 22:06:02 s/releasede/released :-) Nov 12 22:06:58 [g2]: did you do any iperf testing on the loft using 802.11g? I'm curious as to what you got, if you did any. Nov 12 22:07:50 likewise: http://www.qnap.com.tw/download_detail.asp?pl=1&p_mn=TS-101&ct_name=Technical%20Document Nov 12 22:07:50 <[g2]> GPSFan I'm playing with busybox right now Nov 12 22:07:50 It's not up-to-date though Nov 12 22:08:16 <[g2]> I think I just found my issue regarding networking and busybox with glibc Nov 12 22:08:32 [g2]: I didn't mean for you to go off and do it now, I thought you might have eone some a week or so ago. Nov 12 22:08:36 Latest released firmware is 1.2.1, released 2006/8/29. Sources from 2006/05/08. Nov 12 22:08:44 NAiL: ok Nov 12 22:08:49 I've got firmware rev. 1.3.0 and 2.0.0 ;-) Nov 12 22:13:25 * NAiL hopes the kernel sources aren't too far from vanilla Nov 12 22:17:06 I've asked the .no distributor to try to get as much as possible of the sources Nov 12 22:21:48 the kernel sources are only 4kb different in size Nov 12 22:32:53 03bzhou * r4455 10optware/trunk/make/php.mk: php: upstream upgrade to 5.2.0 Nov 12 22:34:49 the kernel sources included in the tarball is vanilla 2.6.12.3 Nov 12 22:38:17 wow Nov 12 22:38:27 It looks like they actually include the sources for the webinterface Nov 12 22:45:24 NAiL: original buildroot seems to create a nice toolchain for me. I had to select to *not* use the latest busybox snapshot in order for it to compile. Nov 12 22:46:15 NAiL: I'm now stuck at a missing file at some server for the hdparm package, but the toolchain part passes nicely. Nov 12 22:46:47 Yeah, but you've build with a newer kernel/uClibc, right? Nov 12 22:47:14 Sure, but I could step back. Nov 12 22:47:24 because 0.9.28 isn't binary compatible with 0.9.27 :-\ Nov 12 22:48:39 anyone know about "mkimage"? Nov 12 22:48:54 Ie, is it a thing qnap has written, or is it "out there"? Nov 12 22:49:29 mkimage -n 'QNAP RAM Disk' -A ppc -O linux -T ramdisk -C gzip -d initrd.bin build/initrd.boot Nov 12 22:49:57 NAiL: sounds like uboot mkimage Nov 12 22:50:08 NAiL: but have zero experience with uboot Nov 12 22:50:20 not me either Nov 12 22:50:36 NAiL: but the answer is: "out there, with u-boot" Nov 12 22:50:42 thanks :) Nov 12 22:51:04 It does look like it's mostly possible to recreate the image with the provided sources Nov 12 22:51:06 NAiL: You're welcome. I'm most interested to walk the PowerPC path as well :-) Nov 12 22:51:07 even the webif Nov 12 22:51:37 NAiL: Do you know if the device is for sale without drive? I do not want to spend $$$ for yet another drive... Nov 12 22:51:41 Soo... It could be possible to upgrade the whole thing to a recent kernel/busybox/uClibc etc :) Nov 12 22:51:50 uh, mine came without a drive Nov 12 22:51:57 where are you located? :) Nov 12 22:52:01 NAiL: from your distributor? Nov 12 22:52:04 .nl Nov 12 22:52:11 likewise: yeah Nov 12 22:52:33 I'm interested in a bare device, if you help me with that. All shops I found so far deliver it with an ($$) drive... Nov 12 22:52:50 I've got plenty of SATA disks at my office... Nov 12 22:53:53 here in .no it costs ~260 EUR without a disk/postage Nov 12 22:56:52 03bzhou * r4456 10optware/trunk/make/php.mk: php: exclude ldap for wl500g Nov 12 22:57:08 rwhitby: the ts101 looks like a fun target. It seems like most of the sources is available, even the webinterface :-) Nov 12 22:58:01 03bzhou * r4457 10optware/trunk/make/php.mk: php: removed a trailing backslash Nov 12 22:58:04 NAiL: Ah, ok I just found one shop for 274 without disk, and 395 with a 250 GB disk Nov 12 22:58:22 It also looks like it uses uboot's mkimage tool to create the firmware images, making it possible to upgrade the bugger with a firmware with optware pre-installed :) Nov 12 22:58:45 isn't an high price for a device w/o a disk? Nov 12 22:58:55 dwery: yeah Nov 12 22:59:04 ok :) Nov 12 22:59:08 but it it very nice software-wise Nov 12 22:59:27 NAiL: ts101 URL ? Nov 12 22:59:31 it beats the othe NAS'es I've tried Nov 12 22:59:37 NAiL: I'll run debian :) Nov 12 22:59:42 rwhitby: http://www.qnap.com.tw/pro_detail_feature.asp?p_id=67 Nov 12 22:59:50 dwery: yeah, of course ;) Nov 12 22:59:56 NAiL: how many megs? Nov 12 23:00:02 dwery: then a device like the ds101g+ is cheaper Nov 12 23:00:09 64mb ram Nov 12 23:00:18 there's solder pads for another set of chips though Nov 12 23:00:26 I need something fast with 64 or more ram Nov 12 23:00:34 so it might be possible to upgrade to 128 without hassle Nov 12 23:00:34 should make no nois, if possible ;) Nov 12 23:00:41 it's fanless Nov 12 23:00:42 this one makes no noise ;) Nov 12 23:00:50 ah.. I forgot, must be cheap ;) Nov 12 23:01:49 NAiL: what SDRAM part no? Nov 12 23:01:59 NAiL: we need photo's :-) Nov 12 23:02:19 yeah NAiL, open her up and put the nudi photos in gallery Nov 12 23:02:46 dwery: it runs powerpc, which is nice by itself. We really should make sure rwhitby's work comes in useful here :-) Nov 12 23:03:09 * rwhitby 's ex-work Nov 12 23:03:13 rwhitby: I have, I can upload photos in a little while if they're ok Nov 12 23:03:22 likewise: I agree ;) Nov 12 23:03:26 likewise: PC133, don't have partnumbers right now Nov 12 23:03:27 So USD$260 Nov 12 23:03:36 rwhitby: "work" as-in results of your work. Nov 12 23:03:38 rwhitby: What's the status of dovecot ssl support for the fs3? Nov 12 23:03:57 marceln: haven't had time to work on it Nov 12 23:05:05 rwhitby: did you see, work with, or recommend any of the powerquicc ii or iii dev boards? Nov 12 23:05:24 likewise: nope Nov 12 23:05:32 different department Nov 12 23:06:04 another NAS seems interesting is http://linkstationwiki.net/index.php?title=Information/HGOverview Nov 12 23:06:06 rwhitby: so you haven't touched the powerpc's from a hobby point of view? Nov 12 23:06:11 likewise: nope Nov 12 23:06:44 eno: no sata Nov 12 23:07:19 eno: but it does state 128MB (<=dwery) Nov 12 23:07:51 nice Nov 12 23:08:14 likewise: I don't have any good photos, but tomshardware has: http://www.tomsnetworking.com/2006/08/11/qnap_ts101_nas_review/page6.html Nov 12 23:08:14 http://www.amazon.com/gp/product/B0002ICEIQ Nov 12 23:08:16 $175 Nov 12 23:08:41 likewise: they've apparently changed the network controller in the hardware revision after the one tomshardware got, but the rest looks more or less the same Nov 12 23:09:21 bbiab Nov 12 23:09:47 guys, i do have a mipsel buffalo linkstation hd-hlan250 right here sitting next to my slug, it has 64 megs of ram, not 128 megs Nov 12 23:11:29 kfm82: http://linkstationwiki.net/index.php?title=LS_Hardware_and_Software_information Nov 12 23:11:38 * NAiL unfortunately has to go to bed Nov 12 23:11:40 nite all Nov 12 23:12:05 maybe that's the difference between hdhlan and hd-hglan Nov 12 23:12:24 nite nail Nov 12 23:12:54 nite] Nov 12 23:13:23 eno, i thought the "g" was mostly meant to signify "gigabit" Nov 12 23:14:27 all my knowledge for linkstation comes from that wiki page Nov 12 23:15:45 eno, i've been busy compiling a pretty standard gnu userland on the mipsel linkstation for the last two weeks... certainly packs more of a processing punch than the slug @ 400 mhz... not to mention drive access latency Nov 12 23:16:20 the joys of interal ATA controllers, heh Nov 12 23:18:31 I forgot to add 8/10 usb ports to the requirement :) Nov 12 23:19:03 dwery, for what? flash drives? external HDs? rs232 adapters? Nov 12 23:19:51 3 printers, usb audio, modem and something I've surely forgot :) Nov 12 23:19:56 bluetooth Nov 12 23:19:59 gotta go sleep some, too bad. cya guys Nov 12 23:20:21 03bzhou * r4458 10optware/trunk/make/php.mk: php: let 5.1.6 rebuild finish for all platforms, upgrade later Nov 12 23:20:49 * kfm82 wishes there was a dedicated channel on freenode for linkstation matters Nov 12 23:21:03 too many dedicated channels are annoying Nov 12 23:21:18 yep, you risk loosing people here and there Nov 12 23:21:27 nbd, where then do you suggest i go with openlink/freelink related problems? Nov 12 23:21:29 * eno wishes mv nslu2-linux nas-linux Nov 12 23:21:46 eno, that's what i already sort of figured Nov 12 23:23:46 so many compilations from raw source tarballs fail on the slug and the linkstation, it's not even all that funny anymore... always something missing or some odd errors Nov 12 23:25:11 wanted to build the most recent release 3.5.6 of lftp on the slug today... failed... worked fine on osx tiger and linkstation/mipsel/openlink Nov 12 23:25:34 ./configure && make off of the very same source tarball Nov 12 23:25:47 kfm82: what build env? Nov 12 23:25:56 eh, native?! Nov 12 23:26:05 unslung 5.5 beta!? Nov 12 23:27:08 i remember lftp 3.5.4 can build native/cross, there was runtime problems Nov 12 23:27:22 with optware lftp.mk Nov 12 23:28:12 lftp configure comes with options for gnu readline and openssl, i just went with the default without any extra command line switches Nov 12 23:28:43 the plain inetutils ftp client without tab completion and wildcards really sucks Nov 12 23:29:04 ncftp is ok for interactive use Nov 12 23:29:31 lftp is nice because it can do sftp Nov 12 23:30:22 nbd, also, it can detach, has reasonable wildcard-matched mget expansion and progress bars, etc etc Nov 12 23:30:29 yeah Nov 12 23:31:35 i do have ncftp on the slug, installed via ipkg binary, i would still prefer lftp for consistency's sake, i've got it pretty much everywhere else Nov 12 23:32:26 can you try build with optware env? it should build, i'm just not sure about runtime Nov 12 23:33:02 kfm82, is there an option to re-attach to a detached session in lftp? Nov 12 23:33:31 eno, i am afraid it has been a few months since i unslung (close to a year), how do i setup the optware env natively again? it must be in the wiki i suppose Nov 12 23:33:56 EvilDevil, i don't think so, you could simply use screen for that Nov 12 23:34:09 EvilDevil, it mostly finishes the currently active download session Nov 12 23:34:56 svn co http://svn.nslu2-linux.org/svnroot/optware/trunk Nov 12 23:35:31 kfm82, ok, i was already afraid that I was to blind to find that option ;) I already was using screen with lftp to do that. IMHO that re-attach option should be implemented Nov 12 23:35:32 or start with Master Makefile Nov 12 23:36:11 eno, any guesses on how many hundreds of megabytes a full mirror will eat? i am somewhat tight with space on the slug right now, need to free some first Nov 12 23:36:12 eno there's no suitable monotone for unslung Nov 12 23:36:56 oh that's right, so just start with svn co Nov 12 23:37:43 Monotone on the NSLU2? It's slow on my 2.8Ghz P4 ;) :D Nov 12 23:38:29 $ du -s make/ sources Nov 12 23:38:30 18732 make/ Nov 12 23:38:30 42696 sources Nov 12 23:38:30 mwester-laptop, ARM is more efficient than the P4's netburst architecture ;) Nov 12 23:38:41 waiting for it to do stuff on the slug would be very .... monotone :) Nov 12 23:40:19 kfm82: you don't need to download/mirror/build everything Nov 12 23:40:20 eno, 60 megabytes? seems bearable Nov 12 23:41:01 + the space for your make target and its dependencies Nov 12 23:41:28 eno, i realize that Nov 12 23:42:13 in related news, i have extracted full netbsd-pkgsrc-2006q3, wonder if those will be of any use on unslung and openlink Nov 12 23:46:39 ok, cleared about 3 gigs on the slug, should suffice for optware Nov 13 00:03:50 tightvnc is in the optware trunk, so people have successfully built the Xvnc server? Nov 13 00:04:49 i did, but it was not fully functioning Nov 13 00:05:15 eno, what was the problem? i have used Xvnc with great success on a number of openbsd systems Nov 13 00:06:02 at first it was some missing fonts Nov 13 00:07:08 and then? Nov 13 00:07:21 then the screen was redrawn correctly Nov 13 00:07:49 i could open an xterm and it sorta worked, just not quite Nov 13 00:08:04 besides, it was slow Nov 13 00:09:14 after using xvnc & ion wm on my debian slug, i pretty much gave up on that idea Nov 13 00:09:22 eno, it is always slow, i've run it on a 50mhz microsparc, so the 133mhz can't be that bad Nov 13 00:09:50 so i have navigated to optware/trunk/sources/tightvnc, now what do i do to build? Nov 13 00:10:03 there are three patchfiles, but no makefile or configure script Nov 13 00:11:18 you should issue "make tightvnc-ipk" at optware/trunk (but probably not a good idea do native build) Nov 13 00:11:32 eno, because it would take days to build_ Nov 13 00:11:33 ? Nov 13 00:12:03 right, even with the help of distcc, it will take quite some time Nov 13 00:12:47 a day or two might be OK, as long as it's not a week as some native X11 on hardware servers seem to do Nov 13 00:12:53 also i did it using x-build, not sure about whether native build works for that package (should work, but not sure) Nov 13 00:13:20 it will pull in tons of x11 stuff Nov 13 00:13:28 guess i will just have to try... optware will build in place, not auto-stage into root and hence requiring root permissions, correct? Nov 13 00:14:32 yes. i suggest you try a smaller package such as 'make which-ipk' first Nov 13 00:15:17 because the stock /opt/bin/which sucks? i was thinking along the lines of zoo or unarj Nov 13 00:15:44 what exactly is the difference between "make foo" and "make foo-ipk" ? Nov 13 00:15:47 yeah any small package will do Nov 13 00:16:18 eno, the former just builds the sources, the latter will package them up as well? Nov 13 00:16:20 read make/template.mk and you'll know, basically foo only build, foo-ipk packages Nov 13 00:16:55 do i need to manually ipkg install foo-ipk after building in order to stage it into my DESTROOT? Nov 13 00:17:32 make foo-ipk will result a foo_x.y.z-arch.ipk Nov 13 00:17:34 also, i wonder why there is no prebuilt tightvnc in the binary repo Nov 13 00:18:01 i don't think it's usable, so i did not put it in the feed Nov 13 00:18:29 you can manually install by "ipkg install foo_x.y.z-arch.ipk" Nov 13 00:20:10 seems the make scripts and the svn checkout don't create the necessary builds/ and tmp/ directories, hence all make attempts will fail Nov 13 00:21:22 do a "make directories" first Nov 13 00:21:46 seems to work with the two dirs i just manually created, but will run that target just to make sure, thx. Nov 13 00:22:26 unarj now builds succesfully... trying zoo... Nov 13 00:22:43 oops, make bombs out for zoo Nov 13 00:22:54 make[1]: *** No rule to make target `/usr/include/stdio.h', needed by `addfname.o'. Stop. Nov 13 00:23:20 ok, who's the authority on optware? :) Nov 13 00:24:02 i am supposed to be the optware package manager now Nov 13 00:24:03 from the looks of it on the qnap firmware, I think optware can be completely integrated from the vendor side Nov 13 00:24:27 nice Nov 13 00:24:45 eno, it seems to just keep spewing various error messages on my unslung 5.5 installation here, strange Nov 13 00:24:52 ie, I should be able to get patches into the released firmware so that optware can be fully supported Nov 13 00:25:43 qnap is interested, as long as there's no more RMA's than before (and probably interested if "someone else" does the work) Nov 13 00:25:45 is the qnap another funky NAS gadget? Nov 13 00:25:59 It's not that "funky", but it's a NAS ;) Nov 13 00:26:21 for adding target, you better talk to rwhitby, esp when it has vendor involved Nov 13 00:26:23 175mhz ppc, 64mb ram, internal+external s-ata, 64mb ram, 16mb flash, fanless Nov 13 00:26:58 we should probably provide some big disclaimer up front Nov 13 00:27:08 Nail, nice, how much is it and where to purchase internationally? Nov 13 00:27:25 eno, another problem with "make unarj-ipk": Nov 13 00:27:25 ipkg-build: No such file or directorymake: *** [/share/flash/data/optware/trunk/builds/unarj_2.65-1_armeb.ipk] Error 127 Nov 13 00:27:34 runs what appears to be a 2.6.12.3 vanilla kernel, with a proprietary module for the rtc (which IIRC dwery has written a version of) Nov 13 00:27:42 how to build ipkg-build? Nov 13 00:27:58 dwery: did you write the rs5 rtc stuff? Or was that someone else? :) Nov 13 00:28:06 kfm82: some packages are probably cross-only, native build not tested Nov 13 00:28:19 kfm82: bit expensive imho, I got one from the .no distributor Nov 13 00:28:23 NAiL: I wrote a rc5 something Nov 13 00:28:30 but there are at least two something :) Nov 13 00:28:33 haha Nov 13 00:28:57 NAiL, got pictures of the hardware? there was an unidentified NAS gadget with a mock-macmini-case recently on ebay Nov 13 00:29:32 http://www.tomsnetworking.com/2006/08/11/qnap_ts101_nas_review/page6.html Nov 13 00:29:39 kfm82: try "make toolchain" Nov 13 00:29:50 eno, will do Nov 13 00:29:54 I've got some lousy pics of the internals. tomshardware's pics are better Nov 13 00:30:00 is that going to rebuild the compiler!? Nov 13 00:30:01 (although slightly outdated) Nov 13 00:30:17 dwery: rc5s372 or thereabouts? Nov 13 00:30:25 kfm82: i don't think so Nov 13 00:30:31 I keep forgetting what the damn chip is called :-P Nov 13 00:30:37 NAiL: me too ;) something like that Nov 13 00:30:46 hehe Nov 13 00:31:07 from what I can see, that chip is the only thing that doesn't have gpl'd source in the firmware Nov 13 00:32:53 $ grep ipkg-utils Makefile Nov 13 00:32:55 eno: what do you mean with the disclaimer? Like.. If you install stuff, you might be screwed. Don't contact qnap if you screw up? ;) Nov 13 00:32:56 $(PACKAGES_IPKG) %-ipk : directories toolchain ipkg-utils Nov 13 00:33:07 NAiL: yes Nov 13 00:33:28 obviously we will want that :) Nov 13 00:33:30 kfm82: "make ipkg-utils" Nov 13 00:33:56 sorry, i did that quite some time ago and don't remember anymore Nov 13 00:35:23 Packaged contents of /home/bzhou/slug/optware/builds/lftp-3.5.6-ipk into /home/bzhou/slug/optware/builds/lftp_3.5.6-1_armeb.ipk Nov 13 00:36:37 seems like the ticket Nov 13 00:37:43 ah, qnap used gcc 3.4.2 Nov 13 00:38:09 uClibc 0.9.27, gcc 3.4.2, linux 2.6.12.3. Nov 13 00:38:19 lftp still has the same segfault Nov 13 00:38:45 suspect it's an upstream problem Nov 13 00:38:59 since the build is native Nov 13 00:40:53 kfm82: maybe you can setup optware native build on your linkstation? Nov 13 00:41:10 eno, i would absolutely want to do that Nov 13 00:41:28 are the patches in the trunk somehow arm-related? my linkstation is mipsel Nov 13 00:42:41 which patch? Nov 13 00:43:25 eno, nevermind which one, so the entire optware tree is totally architecture-generic? no assumptions whatsoever? Nov 13 00:43:39 the one under sources/package-name usually are for cross build Nov 13 00:45:14 we try to be as much as possible arch-independent Nov 13 00:45:42 i'd certainly be interested in trying, but it seems i first need to build svn on the linkstation in order to check out the repo Nov 13 00:45:59 in places where we cannot avoid arch specific stuff, we use ifeq ($(OPTWARE_TARGET), ...) Nov 13 00:46:32 i'd strongly suggest you setup a cross optware env Nov 13 00:47:18 eno, on a speedier x86 box that is? athlon xp or pentium 4 perhaps? Nov 13 00:47:30 right Nov 13 00:47:49 i really should Nov 13 00:47:52 i know there were ppl successful in setup native build for ds101g Nov 13 00:49:50 actually since most optware packages are cross built anyway, once you have a cross env, you probably don't even need a native env Nov 13 00:49:51 that's a powerpc board, right? Nov 13 00:50:03 ds101g is powerpc Nov 13 00:50:56 is your linkstation toolchain uclibc? Nov 13 00:51:51 * NAiL thinks not Nov 13 00:52:38 then the closest existing optware target probably is mss Nov 13 00:52:39 eno, i don't think so, how do i quickly verify that assumption? Nov 13 00:53:14 uname -ap: Linux kfm82links.local 2.4.20_mipsel_linkstation #3 Thu Apr 20 14:38:55 JST 2006 mips unknown Nov 13 00:53:47 if there's any uclibc files in /lib Nov 13 00:55:02 or try executing /lib/libc.so Nov 13 00:55:03 ls: /lib/*uc*: No such file or directory Nov 13 00:55:41 92453 -rwxr-xr-x 1 root root 1.6M May 11 2005 /lib/libc-2.3.2.so* Nov 13 00:55:41 92428 -rwxr-xr-x 1 root root 1.4M Aug 5 2005 /lib/libc-2.3.5.so* Nov 13 00:55:41 92475 lrwxrwxrwx 1 root root 13 Nov 1 01:04 /lib/libc.so.6 -> libc-2.3.5.so* Nov 13 00:55:50 yeah, gnu glibc Nov 13 00:56:27 i've already had some fun when an alpha ipk of midnight commander relinked that last libc symlink, breaking half my remaining userland in the process Nov 13 00:58:11 kfm82: gcc --version ? Nov 13 00:58:34 gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) Nov 13 00:58:42 nice, seems to be almost identical to unslung Nov 13 00:59:56 subversion-1.4.2 and dependencies extracts to 53 megs of sources, so i will have to build this just to check out the optware trunk? *sigh* Nov 13 01:02:09 kfm82: so you're already using debian, what's the need for optware? Nov 13 01:03:21 eno, no, that is misleading, there are openlink (merged with stock web interface) and freelink (debianized) rootfs images for the mipsel linkstation, i am using the buffalo, non-debian variant Nov 13 01:03:27 * NAiL tries building a toolchain for the ts-101 Nov 13 01:04:30 eno, i have extracted the freelink / debian image to another dir, wonder if i may just chroot into that to use it... and how might a chroot affect already running processes? Nov 13 01:08:22 looks like: toolchain: crosstool # if glibc Nov 13 01:08:33 and toolchain: buildroot # if uclibc Nov 13 01:08:54 yeah Nov 13 01:09:05 you have to patch an old version of crosstool to get it to build uclibc Nov 13 01:09:24 and the optware makefile doesn't look like it was designed to cope with crosstool building uclibc at all Nov 13 01:10:03 NAiL: and the problem is the current buildroot is very mipsel specific? Nov 13 01:10:08 yes Nov 13 01:10:23 I've got no idea where to change all that stuff Nov 13 01:10:34 (without breaking the other builds) Nov 13 01:10:45 kfm82: you probably want to look at make/crosstool.mk and even make/crosstool-native.mk Nov 13 01:11:02 eno, i will look into it Nov 13 01:12:11 kfm82: look at how the mss target handles it Nov 13 01:13:24 i found this interesting URL in the makefile header: http://kegel.com/crosstool/ Nov 13 01:18:48 kfm82: http://forum.linkstationwiki.net/index.php?action=vthread&forum=7&topic=1684#msg17121 Nov 13 01:20:04 cross binutils built.. now starting with gcc :) Nov 13 01:20:58 NAiL: cool Nov 13 01:24:28 the binutils version used when building shouldn't matter (much), should it? Nov 13 01:24:43 I've matched uClibc, kernel and gcc versions with the original firmware Nov 13 01:25:24 NAiL: i don't have a clear idea Nov 13 01:26:06 can always try Nov 13 01:39:58 gcc complete Nov 13 01:40:05 but uClibc failed miserably Nov 13 01:40:46 gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -funit-at-a-time -fpic -DUCLIBC_RUNTIME_PREFIX=\"/\" -fno-builtin -nostdinc -D_LIBC -I../../ldso/include -I. -I../../include -isystem /usr/lib/gcc/i486-linux-gnu/4.0.3/include -I../libdl -c powerpc/resolve.S -o powerpc/resolve.o Nov 13 01:40:51 powerpc/resolve.S: Assembler messages: Nov 13 01:40:53 powerpc/resolve.S:16: Error: no such instruction: `stwu 1,-64(1)' Nov 13 01:40:54 loads of unknown instructions Nov 13 01:41:12 * NAiL will have to look at that tomorrow Nov 13 01:41:13 nite Nov 13 01:44:05 nite NAiL Nov 13 02:01:17 rwhitby: for now (etch) the NPE-B microcode will be copied from the unofficial image to the target system (/lib/firmware) Nov 13 02:04:01 dumfrac: ok, so initial debian installation is always from slug-firmware.net, and upgrades from that are dfsg-compliant Nov 13 02:04:20 yup Nov 13 02:04:41 it works for now - but obviously a better solution is desirable down the line Nov 13 02:08:09 eno, thanks, will have to go to sleep now, back soon Nov 13 02:25:05 03bzhou * r4459 10optware/trunk/ (2 files in 2 dirs): bogofilter: downgrade back to 0.93 for wl500g only Nov 13 02:38:55 03bzhou * r4460 10optware/trunk/make/py-sqlalchemy.mk: py-sqlalchemy: upstream upgrade to 0.3.1 **** ENDING LOGGING AT Mon Nov 13 02:59:57 2006