**** BEGIN LOGGING AT Wed Aug 23 02:59:57 2006 Aug 23 03:12:39 03bzhou * r3888 10optware/trunk/make/py-turbogears.mk: py-turbogears: fix py-sqlobject dependency Aug 23 03:34:00 hey Aug 23 03:34:03 anyone here? Aug 23 03:34:09 i want to ask some question Aug 23 03:37:05 ask away Aug 23 03:37:28 i want to benchmarking DebianSlug on NSLU2 Aug 23 03:37:50 do you know any tools that i can use? Aug 23 03:38:39 What are you wanting to benchmark? Aug 23 03:39:07 i want to benchmark CPU and RAM Aug 23 03:39:20 You want to measure memory access times? Aug 23 03:39:32 yeah Aug 23 03:39:36 and test some case Aug 23 03:39:45 BTW, have you removed the resistor to make your slug 266MHz/ Aug 23 03:39:46 when process use over RAM Aug 23 03:39:48 ... Aug 23 03:40:01 uhm Aug 23 03:40:10 I think that the kinds of tests you are going to find for this are mathematical in nature. Aug 23 03:40:17 my NSLU2 run with 266MHz now Aug 23 03:40:41 There are suites of tests that execute algorithms such as prime number seives. Aug 23 03:40:51 s/sei/sie/ Aug 23 03:40:52 beewoolie-afk meant: There are suites of tests that execute algorithms such as prime number sieves. Aug 23 03:41:07 ok, can you give me some of that... Aug 23 03:41:10 Are you attempting to find out the memory bandwidth? Aug 23 03:41:19 You'll have to look on line. Aug 23 03:42:06 if i want to test Aug 23 03:42:10 If you are running debian, there are 27 packages that match the keyword benchmark. Aug 23 03:42:22 oh Aug 23 03:42:24 let me check Aug 23 03:42:26 One is called stress. Aug 23 03:42:44 I gotta go now, but I'll be back in an hour... Aug 23 03:42:45 ttfn Aug 23 03:43:11 ok, bye you and thank you Aug 23 03:43:12 :) Aug 23 05:41:01 03bzhou * r3889 10optware/trunk/make/py-urwid.mk: py-urwid: upstream upgrade to 0.9.6 Aug 23 06:20:02 what is the most proper way to build custom openslug firmware images ... apparenlty you can do some things with a local.conf file ... but it looks like i need to actually create my own "${distro}.conf" file to really do what i want ... how does that integrate into the build system though ... i am currently using make openslug-image to build the generic openslug firmware. Aug 23 06:34:11 Caelian|work: you should be able to do most things in local.conf - that was our intention at least. Aug 23 06:36:16 rwhitby-away, ok .. i'll have to have a closer look at that i guess ... want to remove certain kernel support as i don't need it .. but add other tools some of them replacements for what's already included in the default image Aug 23 06:37:24 yep - look in slugos-image.bb to see what variables you will need to override in local.conf Aug 23 06:37:51 we intended to allow you to override the variables which control what goes in the flash image, as that's the most common customisation. Aug 23 06:38:04 hmmmm ... just flashed my first self-built openslug image ... but system seems to be taking an aweful lot of time to come up ... looks like i should really bug our hardware guy to start soldering those serial ports on :) Aug 23 06:39:04 thansk for the hints Aug 23 06:39:28 i wonder if i'm dealing with a broken flash image here ...... Aug 23 06:40:22 hmmm ... it Is responding to pings ... just not done with its full boot cycle .. so sshd isn't running yet Aug 23 06:41:32 the first boot takes a while, cause it needs to generate ssh keys Aug 23 06:42:01 you also need to make sure your ixp modules correspond with the correct kernel version. they don't automatically get rebuilt when the kernel gets rebuilt (if you change kernel versions) Aug 23 06:42:02 aaah .. so my gut feeling was right ... i was just about to ask that :) Aug 23 06:42:27 i haven't changed anything there .. so i am using the default values there so far Aug 23 06:42:35 haven't started modding anything .. Aug 23 06:43:07 and the main reason i wanted to try the 2.6.17 kernels anyway .. was because apparently those seem to have RTC kernel modules .. which seem to not be present for the 3.10-BETA firmware Aug 23 06:48:18 * Caelian|work hops the system will finally get up soon ... it's easily been 8 minutes by now ... (always gets nervous when booting takes this long :)) Aug 23 06:52:46 8 minutes is too long Aug 23 06:53:02 Caelian|work: be aware that HEAD is currently untested Aug 23 06:53:20 (so it could easily be broken at the moment) Aug 23 06:53:37 yes the 2.6.17 have the new RTC and LEDs subsystems Aug 23 06:54:10 i know it's untested ... but it seems to be the only way for me to get a 2.6.17 kernel etc on this box Aug 23 06:54:38 and for our purposes we Need the RTC to work properly Aug 23 06:54:58 have you checked out our svn kernel repo? Aug 23 06:55:08 I know that the head of that boots Aug 23 06:55:19 rwhitby-away, how would i go about just updating the kernel ? Aug 23 06:55:40 and no .. i haven't checked that yet .. didn't even know it existed :) Aug 23 06:55:48 copy the new modules into the rootfs, and use the "reflash" script to flash just the kernel Aug 23 06:56:02 svn co http://svn.nslu2-linux.org/svnroot/kernel/trunk Aug 23 06:56:15 That's where we test new kernel patches before we import them into OE. Aug 23 06:56:44 rwhitby-away, i thought reflash only works froma rootfs other than the internal flash Aug 23 06:56:45 You can also get to it via http://trac.nslu2-linux.org/kernel Aug 23 06:57:05 Caelian|work: turnup ram, then scp up the kernel to /tmp, then run reflash Aug 23 06:57:48 (starting with a known good openslug 3.10 image) Aug 23 06:58:03 but you really do want to have a serial port on there anyway Aug 23 06:58:19 hmmmm ... this is going to be an interesting ride ... (custom firmware images are still the easiest way to work for me though ... but yeah .. unstable can be broken at any moment .. i am well aware of such concepts .. running FreeBSD 7.0-CURRENT myself on a daily basis :)) Aug 23 06:58:29 rwhitby-away, yeah i know :) Aug 23 06:58:54 rwhitby-away, up till now with "known good" firmware it hasn't been a big requirement yet Aug 23 06:59:05 but it's really becoming one now :) Aug 23 06:59:10 yup :-) Aug 23 07:00:41 our biggest problem with the NSLU2 (3.10 BETA firmware) is the fact that it stores its current time upon shutdown .. and restores that same time the next time it boots up ... which means it looses its proper time the second you turn it off Aug 23 07:01:50 and that was one of the primary tasks it is supposed to perform for us ... provide proper time in a scenario where we do not have access to time-servers :( Aug 23 13:04:15 rwhitby-away, ok .. i have a serial console now ... do you want me to put up boot-logs somewhere so you can potentially identify the source of the breakage ? Aug 23 13:04:33 sure - pastebin them Aug 23 13:04:36 rwhitby-away, i am getting usage syntax from a busybox cpio not recognising the -p switch Aug 23 13:04:57 right - that's an OE breakage which we haven't fixed on HEAD yet Aug 23 13:04:59 i am reflashing right now .. as after the initial boot the flash image is busted :) Aug 23 13:05:31 rwhitby-away, aah .. ok .. it's a known breakage in that case ... i'll pastbin a full boot log anyway .. just in case Aug 23 13:06:02 feel free to debug the problem too ;-) Aug 23 13:07:47 ok ... stripping the "script" output of my minicom session ... give me a few minutes :) Aug 23 13:12:13 hmmm ... what would be the easiest way to strip out all the escape sequences for coloring the console output ? Aug 23 13:14:52 never mind .. vim to the rescue :) Aug 23 13:16:10 http://pastebin.ca/146249 Aug 23 13:16:38 that's my (cleaned up) console output ... from initial flash till end of boot Aug 23 13:20:46 rwhitby-away, i wouldn't mind having a closer look at the problem if you can give me some pointers on where to start ... i assume the first stop would be to fix the busybox's cpio to accept the -p switch .. or adjust the rc-scripts to not need it :) Aug 23 13:22:38 S12sysconfsetup seems to be using cpio in a way that the latest version of busybox does not understand Aug 23 13:23:38 that'd be the place to start Aug 23 13:23:48 I think thats in packages/slugos-init/... Aug 23 13:26:18 openembedded/packages/slugos-init/files/sysconf seems to be the culprit on first glance Aug 23 13:26:58 the sysconf _save_conffiles function to be precise Aug 23 13:28:04 what has happened is that this used to work with busybox, but OpenEmbedded updated busybox, and we haven't caught up yet. Aug 23 13:28:33 hehe .. that definitely sounds like a sensible conclusion :) Aug 23 13:29:10 what exactly is the purpose of cpio's "copy-pass mode" (assuming FreeBSD's cpio uses the same commandline switch meaning as busybox' Aug 23 13:29:47 just a way to copy files preserving all attributes (including special files like /dev entries) Aug 23 13:29:57 the rest of the pastebin looks like it stems from that one error Aug 23 13:30:33 yeah .. funny btw how it completely mutilates the image though Aug 23 13:30:49 a second boot is not possible .. kernel panics when it can't find init :) Aug 23 13:31:04 linuxrc is no longer present etc etc Aug 23 13:32:32 i am happy i work at a Research Institute for Information Technology ... there's always somebody around that knows how to handle a soldering iron :) Aug 23 13:33:21 modded two of the 4 NSLUs we have here at the moment ... so we have a spare test-box now Aug 23 13:34:22 so what would you suggest as next step ... check the busybox package to see if we can re-enable the cpio -p switch ? Aug 23 13:37:03 no, work out how to modify the sysconf script to not need it, or why busybox dropped it (maybe it's the default now, or maybe OE forgot to enable it in the busybox defconfig or something) Aug 23 13:41:08 guess i'll ask around in #oe :) Aug 23 13:47:25 hmmmm ... #oe isn't exactly useful at this moment :( Aug 23 13:57:03 rwhitby-away, well ... i checked the different defconfig files on the openembedded.org filebrowser ... and it looks like the missing -p switch may simply be a change in the busybox code Aug 23 13:57:27 busybox code or busybox config? Aug 23 13:57:38 code Aug 23 13:57:59 ok, one thing you can do is peg busybox back to the version which was used in slugos 3.10 Aug 23 13:58:04 as all the defconfig files seem to be identical with regards to CPIO config settings Aug 23 14:01:46 i am building a new firmware image now with PREFERRED_VERSION_busybox=1.01 in my conf/local.conf Aug 23 14:16:27 rwhitby-away, hmmm ... it did build a busybox-1.01 package ... but still used the 1.2.1 version on the actual flash image ... Aug 23 14:16:55 rwhitby-away, do i need to add anything else specifically to my local.conf for a "make openslug-image" to build with the 1.01 busybox ? Aug 23 15:33:36 rwhitby-away, ping Aug 23 15:33:51 Caelian|work: yes? Aug 23 15:34:02 i think i found the source of our cpio problem Aug 23 15:34:21 i checked older busybox sources and noticed those don'thave a -p option either ... Aug 23 15:34:37 i just booted a plain 3.10-BETA firmware ... and ran 'which cpio' Aug 23 15:34:46 ah - we used to put in the real cpio? Aug 23 15:34:50 /usr/bin/cpio Aug 23 15:35:00 not a busybox Aug 23 15:35:35 the new firmware iamges try to use a busybox cpio .. which obviously (demonstrated) won't work Aug 23 15:36:41 rwhitby-away, i am not exactly sure though how to proceed from here :) Aug 23 15:36:52 which real package has cpio in it? Aug 23 15:37:03 that i haven't figured out yet Aug 23 15:37:04 compare slugos-image.bb between 3.10 and now Aug 23 15:38:15 or look in the ipkg status files that end up in /usr/lib/ipkg (or somewhere like that, I forget exactly) for the list of packages installed in 3.10 vs now Aug 23 15:39:20 Hmmmmmm .... SLUGOS_SUPPORT ?= "diffutils cpio findutils udev" Aug 23 15:39:36 this would suggest we Still try to use a non-busybox cpio Aug 23 15:40:18 unless something defines SLUGOS_SUPPORT before we include slugos-image.bb Aug 23 15:42:55 hmm Aug 23 15:43:12 wouldn't SLUGOS_SUPPORT be set using += ? Aug 23 15:43:46 that would make sense .. i am r`just reporting what i am seeing in the .bb files Aug 23 15:44:36 somehow on HEAD the firmware image ends up with a busybox version of cpio .... and that causes trouble ... Aug 23 15:44:51 i am just trying to understand how that happens in the first place Aug 23 15:47:07 i guess the easiest work around would potentially be to replace the current cpio construct with a similar performing tar construct .... but i am not too knowledgeable on cpio to provide the actual alternative Aug 23 15:47:34 but i'd rarther first try to understand how we got as busybox cpio to begin with Aug 23 15:49:38 hmm Aug 23 15:50:04 ./openslug/openembedded/packages/images/slugos-image.bb:# SLUGOS_SUPPORT: set to here, see below, added to the image. Aug 23 15:50:04 ./openslug/openembedded/packages/images/slugos-image.bb:SLUGOS_SUPPORT ?= "diffutils cpio findutils udev" Aug 23 15:50:04 ./openslug/openembedded/packages/images/slugos-image.bb: ${SLUGOS_SUPPORT} \ Aug 23 15:50:19 I'm not near my devbox right now... but have you looked at the update-alternatives priority on cpio vs. busybox? Aug 23 15:50:24 those are the ONLY occurances of "SLUGOS_SUPPORT" in the entire tree Aug 23 15:50:41 NAiL, where would i look for that ? Aug 23 15:50:59 today is basically my first day with "hacking on openslug firmware" :) Aug 23 15:51:17 I can't remember exactly what to look for, but if you look at the cpio .bb, there should be something about update-alternatives in there... Aug 23 15:51:26 I'll see if I can get up the .bb in svn Aug 23 15:52:17 pkg_postinst_${PN} () { Aug 23 15:52:17 update-alternatives --install ${libexecdir}/rmt rmt rmt.${PN} 50 Aug 23 15:52:17 } Aug 23 15:53:07 that's rmt, with a priority of 50 Aug 23 15:53:24 IIRC, lower priority number means higher preference Aug 23 15:53:53 how does this relate to busybox ? Aug 23 15:54:13 busybox installs a symlink to cpio Aug 23 15:54:23 with a certain priority Aug 23 15:54:51 cpio is installed as a binary, which it shouldn't be. It should be a symlink with a higher preference than busybox's cpio Aug 23 15:55:09 ie, a symlink to a binary called cpio.cpio Aug 23 15:55:32 the rmt binary above will be installed as "rmt.cpio", and an "rmt" symlink will point to it Aug 23 15:55:40 Does that make sense? ;) Aug 23 15:56:34 yes that makes sense .. and i have seen that operational ... Aug 23 15:56:43 The correct fix (I believe), would be to add two lines to the cpio .bb Aug 23 15:57:23 one "update-alternatives --install ${libexecdir}/cpio cpio cpio.${PN} 30" Aug 23 15:57:33 and from what i can see in the busybox .bb file ... is that it apparnelty generates symlinks for all "core userland tools" provided by it .. with a default priority of 50 Aug 23 15:57:41 and one "update-alternatives --remove cpio cpio.${PN} Aug 23 15:57:49 yeah Aug 23 15:59:46 i'll try a build with that change ... Aug 23 16:00:01 though i did a make clobber to try to build with an older busybox .... Aug 23 16:00:17 i aborted that ... when i noticed the cpio non-busybox version ... Aug 23 16:00:28 though the now normal rebuild will take a good while Aug 23 16:00:41 it's not the fastest machine :) Aug 23 16:00:54 what made you discover the bug though? Aug 23 16:01:06 the same bug is also in busybox Aug 23 16:01:23 well trying to boot a HEAD firmware image simply didn't work :) Aug 23 16:01:37 managed to find a collegue to solder together a serial port :) Aug 23 16:01:41 oh Aug 23 16:01:50 well, cpio is bugged in 3.10 anyway Aug 23 16:02:07 I'll file a bug so I remember when I get dev stuff up again Aug 23 16:02:40 you said the same bug is also in busybox ... would i need to fix anything there as well ? Aug 23 16:02:45 no Aug 23 16:03:02 replace busybox with slugos 3.10 :p Aug 23 16:03:16 aaah Aug 23 16:03:32 at least 3.10 actually works ... i have a non-busybox cpio there Aug 23 16:04:08 which is what made me realise the problem was not in busybox itself .. but the fact that HEAD firmware somehow ends up with busybox cpio Aug 23 16:04:47 which in itself isn't the worst problem. What triggers the bug during booting? Aug 23 16:05:04 http://pastebin.ca/146249 Aug 23 16:05:07 read and weep :) Aug 23 16:05:33 aaah Aug 23 16:05:33 ok Aug 23 16:05:39 well Aug 23 16:06:01 afterwards the kernel won't even boot any longer as it can't find init any more :) Aug 23 16:06:07 ouch Aug 23 16:06:16 I'm filing two bugs so I remember ;) Aug 23 16:06:24 heheh :) Aug 23 16:06:43 all in all an interesting "first look" at openslug-unstable :) Aug 23 16:07:22 i am used to dealing with these kinds of issues though ... i run FreeBSD 7.0-CURRENT on my private system :) Aug 23 16:11:06 thanks for reporting it :) Aug 23 16:11:13 my pleasure Aug 23 16:11:16 especially the level of detail ;) Aug 23 16:11:54 tickets #15 & #16 are the relevant ones Aug 23 16:12:03 I'll get around to fixing them later ;) Aug 23 16:12:05 hehe .., well it took me about 3/4ths of a work day to get the serial port soldered ... but once that was actually working ... things went fairly fast Aug 23 16:12:12 NAiL, url ? Aug 23 16:12:18 (i keep forgetting ...) Aug 23 16:12:25 trac.nslu2-linux.org/slugos Aug 23 16:13:50 thanks Aug 23 19:48:39 03gda * r3890 10optware/trunk/ (4 files in 3 dirs): spamassassin: new package, cross buildable, version 3.1.4 Aug 23 19:49:18 re Aug 23 19:49:46 spamassassin works on the ds101g :) Aug 23 19:53:20 gda_, cool! Aug 23 19:54:14 the makefile is ugly Aug 23 19:54:47 perl Makefile.PL breaks during cross compile but I patched it until it runs Aug 23 19:55:17 but then it starts configure with the wrong options for cross compile Aug 23 19:55:56 so I let perl break and start configure after Aug 23 19:56:45 should work with native too, because it wouldn't break then and my configure will not run Aug 23 19:57:58 the tricky part is the configure Aug 23 19:58:22 so what are we going to do with perl-spamassasin ? Aug 23 19:58:44 the tricky parts are configure.pl that creates configure and version.h.pl that creates version.h Aug 23 19:59:01 i c Aug 23 19:59:07 currently I have named it spamassassin, it is not pure perl Aug 23 19:59:49 I will soon port amavisd-new, that is what I use on my current server and this needs spamassassin Aug 23 20:00:24 the debian convention is to use perl- or python- if it's a lib Aug 23 20:00:36 otherwise, use its own name Aug 23 20:00:58 but we have not been consistent already Aug 23 20:01:25 and the debian naming would require us to break package(s) into smaller ones Aug 23 20:01:49 then I will fix the setup for postfix and cyrus-imapd and I can move my server to the ds101g Aug 23 20:02:20 good plan Aug 23 20:02:51 yes, I have made rpms for our distro where I have 3 packages for spamassassin, one starts with perl- Aug 23 20:03:58 I hda ported dspam already, is more lightweight than amavis and spamassassin but I have no experiences with dspam Aug 23 20:04:32 i need to find time to do some runtime testing of cross-perl & cross-perl-ipks on nslu2 Aug 23 20:05:00 then we can move nslu2 perl to cross as well Aug 23 20:05:21 i think it basicly works, just need to make sure Aug 23 20:05:41 at least perl-digest-sha1 and perl-html-parser seem to work, because this is used by spamassassin Aug 23 20:06:10 that's good to know Aug 23 20:06:42 okay, on the ds101g, but it shows that cross building should work Aug 23 20:10:11 eno-away: what do you think about kernel modules as optware packages? Aug 23 20:11:18 I have back ported a phillips webcam driver that could be useful, and the nslu2 has a kernel 2.4.22 too, or not? Aug 23 20:12:36 gda_, depends on what firmware you put on it :) Aug 23 20:12:45 gda_, HEAD uses a 2.6.17 kernel Aug 23 20:12:52 for openSlug that is Aug 23 20:13:07 unslung is stuck with 2.4.22, this is what optware runs on Aug 23 20:13:12 I have thought there are no kernels for optware? Aug 23 20:13:23 eeeek .. unslung ... Aug 23 20:13:32 This would make it easy Aug 23 20:14:38 i originally tried unslung myself ... once i tried openslug on one of our NSLU's though ... my first impression was ... i should So have done this Straight from the start to begin with :) Aug 23 20:15:08 there is no openslug for the ds101g Aug 23 20:15:11 Caelian: depends on what you use the slug for Aug 23 20:15:32 gda_, i admit we've only used NSLU2 so far Aug 23 20:15:49 eno-away, mail-server, time-server, bfs-server Aug 23 20:15:54 nfs Aug 23 20:16:19 a kernel module for nfs I have ready too, and I use it currently Aug 23 20:16:56 gda_, you should talk to rwhitby when you see him Aug 23 20:17:17 the original firmware of the ds101g is not so bad, why to replace it: postgresql, mysql, apache, php Aug 23 20:18:08 you are right, but we have a little bit different timezones Aug 23 20:18:36 gda_, i can't speak for the ds101g ... orignial linksys firmware for the NSLU2 is horrid though .;.. and unslung doesn't make it much better either :) Aug 23 20:20:32 Caelian: most people care more about apps, and only care about fw when it's a hinderance Aug 23 20:21:33 :) Aug 23 20:21:38 true Aug 23 20:22:34 the current kernel is a problem, CONFIG_WIRELESS is not activated, so my usb wlan module doesn't work :( Aug 23 20:23:03 I have a kernel ready, but I am too afraid to flash Aug 23 20:23:37 does ds101g has jtag interface? Aug 23 20:23:59 yes, but nobody knows the pinout Aug 23 20:24:05 i c Aug 23 20:25:52 rwithby has bricked his ds101 and he has not find a way to let it run again till now Aug 23 20:27:13 no, it was not rwithby it was NAiL Aug 23 20:29:00 gda_, spamassassin just got in ds101g feed Aug 23 20:30:27 yeah, my DS101 is borked Aug 23 20:30:44 I tried figuring out the jtag pinout for quite some time Aug 23 20:31:06 I also tried using the alternate smd space for a "normal" flash chip Aug 23 20:31:58 unfortunately, I've not been lucky Aug 23 20:32:55 03bzhou * r3891 10optware/trunk/make/py-4suite.mk: py-4suite: upstream upgrade to 1.0rc2 Aug 23 20:34:46 NAiL, i just remote (from home) tried the new firmware image with the "fixed" cpoio Aug 23 20:34:48 cpio Aug 23 20:34:50 Naiu Aug 23 20:34:53 grrrrr Aug 23 20:34:57 yeah Aug 23 20:35:00 did it work? Aug 23 20:35:05 NAiL, nope Aug 23 20:35:15 but you don't have the output from serial yet? Aug 23 20:35:27 NAiL, i lost it Aug 23 20:35:34 hmm Aug 23 20:35:41 NAiL, i do remember most of the details though Aug 23 20:35:52 it still starts a busybox cpio Aug 23 20:36:20 which obviously breaks the sysconf stuff Aug 23 20:36:30 followed immediately bu "Configuring cpio" Aug 23 20:37:18 hmm Aug 23 20:37:23 what prio did you set? Aug 23 20:37:23 which bails out with an unable to setup an alternative cpio for /usr/libexec/cpo (i double checked my .bb file and i did not make any typo's) Aug 23 20:37:27 30 Aug 23 20:37:31 odd Aug 23 20:37:39 i DO have the build logs available from the slugos-image build Aug 23 20:38:15 hmm Aug 23 20:39:48 i think i spotted the potential cause Aug 23 20:39:57 let meput the full do_rootfs log online Aug 23 20:42:20 http://callisto.offis.uni-oldenburg.de:8080/log.do_rootfs.32196 Aug 23 20:43:08 NAiL, the following bit is what i think is causing the problem Aug 23 20:43:12 Configuring busybox Aug 23 20:43:12 (offline root mode: not running busybox.postinst) Aug 23 20:43:12 Configuring cpio Aug 23 20:43:12 (offline root mode: not running cpio.postinst) Aug 23 20:43:55 good point Aug 23 20:44:48 I'll take a look at it later Aug 23 20:44:51 gotta run now Aug 23 20:45:14 i think the easiest solution here would be to have the system install cpio Before installing busybox ... which should (if i understand things correctly) .. skip the generation of the cpio symlink .. since then the binary already will exist Aug 23 20:45:17 ok :) Aug 23 20:45:47 i'll be at it again tomorrow from work ... so i'll probably be here Aug 23 20:52:30 NAiL, if you see this ... it should at the very least not be using ${libexecdir} for the prefix ... as cpio tgether with mt is (in contrary to rmt) located in /usr/bin/ Aug 23 20:53:16 My slug (Unslung 6.x) has stopped getting to the steady green status light (it stays blinking green). However all seems to be fine. Any ideas? pointers? Thanks Aug 23 21:08:20 keving: This could be because a package isn't completing it's startup script which could mean later startup scripts aren't running. The quotacheck is one function that takes longer and longer to run as you fill up the disk. You really need to check with PS what processes are running and see if you can see any startup scripts in the list Aug 23 21:09:14 AdamBaker: thanks for the tip. I will go do that. Aug 23 21:32:00 ok .. i give up trying to understand the update-alternatives syntax ..... Aug 23 21:34:04 i'll just hope rwhitby or NAiL will know how to fix the cpio issue ... the problem at least lies in the (currently missing) update-alternatives definition for /usr/bin/cpio ... but i can't seem to figure out how to precisely add that to cpio\s bb file to make the thing override the symlink added by the busybox port Aug 23 21:43:04 NAiL, i had another closer look ... and actually i think the problem is not with cpio ... it's actually indeed with the new busybox's not having a custom slugos/defconfig like the olderones DO have ... and all the older ones have explicitely disabled the building of the busybox cpio Aug 23 21:44:16 NAiL, now that i actually understand the system a little better ... it makes a lot more sense .. and also explains why there never was a need to add "alternatives" to cpio Aug 23 21:49:57 03gda * r3892 10optware/trunk/ (Makefile make/perl-archive-zip.mk): perl-archive-zip: new ipk Aug 23 21:51:47 one small step for me, one big step for amavisd-new Aug 23 21:57:55 n8t Aug 23 22:02:04 Caelian: Ah, does the old defconfig work with the new version busybox? Aug 23 22:03:03 NAiL, i am backporting the diff between busybox_1.01/defconfig and busybox_1.01/slugos/defconfig ... to a new busybox_1.2.1/openslug/defconfig Aug 23 22:03:20 the new busybox seems to use the directory openslug instead of slugos now Aug 23 22:06:44 NAiL, in the old image RDATE was defaulted to "off" ... in the new image it defaults to "on" ... enable it for openslug as well ? Aug 23 22:07:21 what is rdate? Aug 23 22:07:49 nevermind Aug 23 22:08:15 keep it disabled ? Aug 23 22:08:42 it's so far the only option that i can't necessarily deduce the proper value for :) Aug 23 22:08:45 yeah. We're trying to keep the space usage low, so unless it's *necessary* Aug 23 22:08:58 The rdate utility retrieves the date and time from another machine on your network, using the protocol described in RFC 868. If you run rdate as root, it will set your machine's local time to the time of the machine that you queried. Aug 23 22:09:06 (from freshmeat) Aug 23 22:10:42 NAiL, one final question ... Aug 23 22:10:47 go Aug 23 22:10:59 the old busybox has a sysctl.conf file Aug 23 22:11:08 do i copy that one over to the new busybox ? Aug 23 22:11:16 yes please Aug 23 22:12:10 ok ... i guess now it's hoping it will pick the openslug directory up during builds :) Aug 23 22:12:19 it will Aug 23 22:12:37 bitbake does that automatically, which is basically brilliant ;) Aug 23 22:12:50 ok ... i'll put my defconfig file up for you to have a quick look at Aug 23 22:13:40 http://callisto.offis.uni-oldenburg.de:8080/defconfig Aug 23 22:14:18 NAiL, i basically created a diff between the original defconfig files ... and tried to reapply all the diff-blokcs on a fresh copy of the new defconfig Aug 23 22:16:01 NAiL, the sysctl.conf file i simply copied over ... and the original patch file was already in place it seemed .. i didn't actually check that one Aug 23 22:22:40 NAiL, ok .. something is still broken ... the build completes successfully ... except the install phase bails in the end with the following error Aug 23 22:22:44 /home/pascal/slug/openslug/tmp/work/busybox-1.2.1-r1/image/usr/share/udhcpc: Aug 23 22:22:44 mv: cannot overwrite directory `/home/pascal/slug/openslug/tmp/work/busybox-1.2.1-r1/image/busybox/bin' Aug 23 22:22:44 mv: cannot overwrite directory `/home/pascal/slug/openslug/tmp/work/busybox-1.2.1-r1/image/busybox/sbin' Aug 23 22:22:44 mv: cannot overwrite directory `/home/pascal/slug/openslug/tmp/work/busybox-1.2.1-r1/image/busybox/usr' Aug 23 22:27:56 hmmmm .. one second .. i think i may not have deleted the old tmp dir Aug 23 22:34:22 NAiL, ok ... busybox package now completed successfully :) Aug 23 22:34:44 NAiL, i can't actually test the firmware with this new busybox image until tomorrow though Aug 23 22:35:40 NAiL, but i have been able to confirm that /bin/cpio -> busybox no longer is there now :) Aug 23 22:37:04 anyway ... enough from me for tonight ... i need to go get some sleep .... i'll speak to you tomorrow and let you know if things worked Aug 23 22:46:24 Caelian: great work :) Aug 23 22:49:27 AdamBaker: Bingo! My twonkymedia script started the daemon with -d, not -D. It was the last init script so no harm done ... Thanks again. Aug 24 00:02:15 03bzhou * r3893 10optware/trunk/make/cherokee.mk: cherokee: set index.html as conffile and not to overwrite **** ENDING LOGGING AT Thu Aug 24 02:59:57 2006