**** BEGIN LOGGING AT Tue Oct 04 02:59:57 2005
Oct 04 03:02:36 <dwery> rwhitby: ping
Oct 04 03:36:15 <CIA-8> 03koen 07org.openembedded.dev * r59197559... 10/packages/hicolor-icon-theme/hicolor-icon-theme_0.5.bb: packages/hicolor-icon-theme/hicolor-icon-theme_0.5.bbL fix SRC_URI
Oct 04 03:37:18 <rwhitby> dwery: pong
Oct 04 03:37:37 * rwhitby is around, but cooking dinner - responses may be delayed
Oct 04 03:38:08 <dwery> rwhitby: I catched up with the last emails.. but I haven't understood what I have to do with the idle/busy state :)
Oct 04 03:41:39 <rwhitby> dwery: neither do i :-)   Given that we're flashing between green and off, what do you think looks the best?
Oct 04 03:42:39 <dwery> rwhitby: I would vote for slow blinking = idle, almost steady = busy. But maybe the opposite is more intuitive.
Oct 04 03:43:48 <rwhitby> I like slow blinking idle and almost steady busy.
Oct 04 03:44:12 <rwhitby> does "slow" mean 1Hz ?
Oct 04 03:45:14 <dwery> rwhitby: I don't know what slow means :)
Oct 04 03:47:44 <rwhitby> do you have slow blinking = idle (i.e. timer_led toggling) and almost idle_stop=green now?
Oct 04 03:47:58 <rwhitby> if so, how often does it blink when the slug is idle?
Oct 04 03:49:13 <dwery> I haven't measured it, but I would sey between 1 and 2Hz
Oct 04 03:52:43 <rwhitby> ok, that's close enough
Oct 04 03:53:04 <rwhitby> and what happens when the cpu is 100% on one task now?
Oct 04 03:54:06 <dwery> steady green. but i'd like to modify it as suggested, i.e. the ledd will go off after a while
Oct 04 03:57:33 <rwhitby> how will you do that?
Oct 04 04:08:33 <dwery> dunno.. a mix of led_timer and flags and counter i think.. i'll see after the launch...
Oct 04 04:08:38 <dwery> bye
Oct 04 04:09:32 <dwery-away> maybe busy=blink and idle=steady it's easier...
Oct 04 04:21:43 <rwhitby> dwery-away: idle=steady with slow blink, and busy = faster blink?
Oct 04 05:11:18 <CIA-8> 03hrw 07org.openembedded.dev * r2283efd4... 10/packages/ttf-fonts/ (ttf-dejavu_1.14.bb ttf-dejavu_1.14-20051003.bb): ttf-dejavu: update to newer snapshot - this close bug#365
Oct 04 05:26:25 <CIA-8> 03koen 07org.openembedded.dev * ra05aaf78... 10/packages/gaim/ (files/gaim-OE-branding.patch gaim_2.0.0-cvs-mco1.bb): packages/gaim/gaim_2.0.0-cvs-mco1.bb: Substitute Gaim ad in the irc quit message for some OE branding
Oct 04 05:56:44 <dwery> rwhitby: it's quite hard to do different blink rates :(
Oct 04 05:57:37 <dwery> going to try busy=almost steady
Oct 04 06:01:11 <CIA-8> 03rw 07org.openembedded.dev * r10dc1d65... 10/packages/libsdl/ (libsdl-qpe_1.2.7.bb libsdl-x11_1.2.7.bb): libsdl-(qpe|x11): fix packaging and inherit binconfig. fixes Bug #115
Oct 04 06:24:02 <dwery> rwhitby: i think the current code is the best that I can do without putting a lot of if/else and counters in the code.
Oct 04 06:26:02 <dwery> rwhitby: that means idle -> blinking, fully busy -> steady. imho, if we want something that's strictly related to the cpu load, we need to have the higher level interface do it based on the cpu load value instead of using callbacks from the kernel code.
Oct 04 06:27:07 <rwhitby> dwery: when it's fully busy, doesn't the timer still toggle it ?
Oct 04 06:28:41 <dwery> rwhitby: actually, there's an "if" which make the timer toggle only when idle. I could remove it.
Oct 04 06:30:04 <bullet> busy == steady? that's somehow counter-intuitive to me
Oct 04 06:30:25 <rwhitby> bullet: just like a hard disk activity light
Oct 04 06:30:42 <bullet> right. but the opposite of the led light?
Oct 04 06:30:49 <bullet> err, ethernet led
Oct 04 06:31:57 <dwery> bullet: yep.. it may be counterintuitive. I propose to have the lower lever interface use two colors for busy/idle , so people who do not use openslug can still have a recognizable behaviout. OpenSlug will use the higher level interface.
Oct 04 06:33:28 <rwhitby> dwery: what does it look like with idle_start=green, idle_stop=off, timer=toggle ?
Oct 04 06:33:49 <dwery> rwhitby: timer always toogles?
Oct 04 06:34:02 <rwhitby> yeah
Oct 04 06:34:47 <dwery> with a system fully busy you will end with the same blinking you would have with a fully idle system.
Oct 04 06:35:40 <rwhitby> sounds like we need to add in another colour then.
Oct 04 06:36:43 <bullet> i actually dont really care if the system is idle or burning in hell, as long as it's running :)
Oct 04 06:37:03 <dwery> bullet: then you don't have to define CONFIG_LEDS_CPU :)
Oct 04 06:39:58 <rwhitby> dwery: how about idle_start=green, idle_stop=amber, timer=(if the led is green or amber, then turn it off; if the led is off, then turn it green) ?
Oct 04 06:40:24 <dwery> let me try
Oct 04 06:41:55 <rwhitby> the intent being that slow blinking green is idle, and more amber is added in as more cpu is used, but the timer always takes it back to green so that it is distinguishable from flashing amber by itself
Oct 04 06:44:11 <rwhitby> bullet: did you read the post on how this timer/cpu stuff works?  what's your suggestion?
Oct 04 06:44:35 <bullet> sorry, no, i didnt
Oct 04 06:44:35 <dwery> bullet suggests to burn the cpu :)
Oct 04 06:45:04 <dwery> ..so you won't have any problems with the leds :-D
Oct 04 06:45:09 <rwhitby> bullet: there are three events: idle_start, idle_stop. timer.
Oct 04 06:45:51 <rwhitby> idle_start is called when the slug becomes idle.  idle_stop is called when the slug stops being idle.  timer is called every 50 ticks.
Oct 04 06:46:25 <rwhitby> on each of those calls, you can set the ready/status led to either off or green.
Oct 04 06:46:47 <rwhitby> Design an implementation which shows the difference between a hung slug, and idle slug, and a busy slug.
Oct 04 06:46:52 <bullet> i would make it steady when idle, blinking when non-idle, amber when burning!
Oct 04 06:47:46 <rwhitby> bullet: not possible - all you get is a call when it is no longer idle.  you have no information about how often that  call is being made
Oct 04 06:48:56 <rwhitby> bullet: another idea?
Oct 04 06:48:57 <bullet> ok, so you basically don't know if it's burning
Oct 04 06:49:20 <bullet> not really, no
Oct 04 06:50:02 <dwery> rwhitby: idle_start=green, idle_stop=amber, timer=(if the led is green or amber, then turn it off; if the led is off, then turn it green) does not work: you won't get amber when fully loaded
Oct 04 06:50:35 <rwhitby> don't you get amber/green/off flashing when fully loaded?
Oct 04 06:50:47 <dwery> no, because you have only one idle_stop call
Oct 04 06:51:30 <rwhitby> Hmm.  so we get idle_stop, then timer, timer, timer, timer, etc ....
Oct 04 06:51:34 <bullet> how about having a userspace daemon measuring load and setting led status accordingly?
Oct 04 06:51:44 <dwery> bullet: that's the higher levelinterface :)
Oct 04 06:51:53 <rwhitby> bullet: that is always the fall-back position
Oct 04 06:51:57 <bullet> ah
Oct 04 06:53:16 <rwhitby> dwery: can timer_led sense the current state of the led, and the current state of idle ?
Oct 04 06:53:26 <dwery> rwhitby: yes
Oct 04 06:55:59 <rwhitby> ok, so how do we design the timer_led routine such that we get a transition from green/off to green/amber to amber/off depending on load ?
Oct 04 06:57:17 <dwery> it should be possible. 
Oct 04 06:57:36 <dwery> which transition for whichload status?
Oct 04 06:57:43 <rwhitby> or maybe we want to go from green/off to green/amber/off cause we still need to distinguish it from the userland boot states
Oct 04 06:58:20 <dwery> rwhitby: i think we must develop an interface that it's useful when there's no specifi userspace tools
Oct 04 06:59:01 <dwery> i would do: green/off -> idle, green/amber -> busy
Oct 04 07:01:55 <rwhitby> dwery: I think green/amber is already used in jbowler's scheme
Oct 04 07:02:31 <dwery> with that scheme in action we would have the higher level interface take care of that i think
Oct 04 07:02:53 <rwhitby> I don't understand what you mean by that.
Oct 04 07:03:12 <rwhitby> my understanding is that the init scripts will go as follows:
Oct 04 07:03:14 <dwery> I mean that I want something that can be useful even for a person who do not want to use OpenSlug at all
Oct 04 07:03:52 <rwhitby> red/off, red/amber, amber/off, amber/green, green, release -> our code
Oct 04 07:04:17 <rwhitby> dwery: fully agree that it has to be useful without the init scripts doing any led stuff
Oct 04 07:05:34 <rwhitby> but if we can define it not to collide with the init script led stuff then that is the best solution
Oct 04 07:06:07 <dwery> I agree but can;'t come up with a solution. I don't even know here to tap in the kernel to obtain information abou tall those status changes.
Oct 04 07:06:30 <rwhitby> dwery: those status changes are all done by the init scripts, not the kernel
Oct 04 07:06:43 <dwery> ok
Oct 04 07:06:45 <rwhitby> the kernel only comes into play after the release
Oct 04 07:07:43 <dwery> that also means that a non-openslug user will still have to release the interface
Oct 04 07:08:11 <dwery> I think i will create an option
Oct 04 07:08:20 <dwery> that can be toogled fromn the kernel command line
Oct 04 07:08:28 <dwery> for the initial status
Oct 04 07:09:50 <dwery> so, after the release, we can use green/off and what else?
Oct 04 07:10:07 <rwhitby> good question
Oct 04 07:10:11 <dwery> red/green?
Oct 04 07:10:36 <rwhitby> red/green is upgrade mode, and red indicates a problem, whereas a busy system is not really a problem
Oct 04 07:10:46 <dwery> :(
Oct 04 07:10:49 <dwery> :'(
Oct 04 07:10:57 <rwhitby> is there any way the timer_led event can decide to only toggle every second time it is called?
Oct 04 07:11:14 <CIA-8> 03koen 07org.openembedded.dev * rb91f9b79... 10/packages/udev/ (files/udev.rules udev_070.bb): packages/udev/files/udev.rules: add buzzer, closes #367
Oct 04 07:11:15 <dwery> ugly, but yes, i can made it
Oct 04 07:12:02 <rwhitby> so can we alter the flash rate based on whether we are busy or not  ....
Oct 04 07:12:41 <dwery> yes, i tried that. 
Oct 04 07:12:43 <rwhitby> idle = slow flash rate (toggle once every two calls to timer_led) and busy = fast flash rate (toggle once every single call to timer_led)
Oct 04 07:13:55 <dwery> the slow rate would be very slow and the "fast" rate is too slow to make the user think the system is fully loaded
Oct 04 07:14:11 <rwhitby> or actually, idle = two timers on, one timer off, and busy = one timer on, one timer off.
Oct 04 07:14:56 <rwhitby> any way we can make the "off" time be less than the timer_led interval?
Oct 04 07:15:02 <dwery> no
Oct 04 07:15:57 <dwery> what about using combinations of three colors and/or off?
Oct 04 07:16:03 <rwhitby> so we really need to use another colour, right?
Oct 04 07:16:09 <dwery> yes
Oct 04 07:16:18 <rwhitby> how about green/amber/off ?
Oct 04 07:16:38 <dwery> for idle or for busy?
Oct 04 07:16:45 <rwhitby> green/off/amber/off/green/off/amber/off .... for busy
Oct 04 07:16:57 <rwhitby> green/off/green/off/green/off ..... for idle
Oct 04 07:17:04 <dwery> i'll try
Oct 04 07:31:25 <dwery> the results are:
Oct 04 07:31:47 <dwery> idle : quite noticeable state
Oct 04 07:31:53 <dwery> led is green/off
Oct 04 07:32:08 <dwery> little load
Oct 04 07:32:09 <dwery> :
Oct 04 07:32:19 <dwery> you get amber sometimes, sometimes not
Oct 04 07:32:26 <dwery> from average to high
Oct 04 07:32:41 <dwery> you get amber 
Oct 04 07:32:54 <dwery> i mean gree/off/amber/off
Oct 04 07:33:18 <rwhitby> so the rate of flashing stays the same, just the percent of amber changes?
Oct 04 07:34:35 <dwery> exactly. from green/off/green/off to green/off/amber/off
Oct 04 07:34:56 <rwhitby> so how does that look from a user perspective ?
Oct 04 07:35:33 <dwery> i think it's the most coherent resulkt we have with this interface and the limits we choiced.
Oct 04 07:35:59 <rwhitby> what hoops did you have to jump through with the code?
Oct 04 07:36:22 <dwery> you mean with the current code?
Oct 04 07:36:39 <rwhitby> yeah
Oct 04 07:37:01 <rwhitby> to get the green/off/amber/off and *not* get amber/off/amber/off
Oct 04 07:38:12 <dwery> it is actually quite clean. only a couple of #ifndef in the cpu section in order to have a decent behaviour w/o CONFIG_TIMER,  two arrays for the sequences, a counteer and an "if".
Oct 04 07:39:01 <rwhitby> what is the behaviour now without timer enabled ?
Oct 04 07:39:28 <dwery> green -> idle, amber -> busy
Oct 04 07:40:25 <rwhitby> ok.  I'd say we have the timer enabled by default though ...
Oct 04 07:40:30 <dwery> yes
Oct 04 07:45:13 <rwhitby> ok, so you're happy with the current scheme then?
Oct 04 07:45:21 <dwery> yes
Oct 04 07:45:34 <dwery> I'd say I don't want to touch the code again :)
Oct 04 07:45:53 <rwhitby> I have a spare slug now, so I can test it out (tomorrow).
Oct 04 07:46:11 <dwery> ok, i'll prepare the patch
Oct 04 07:46:12 <rwhitby> night, and thanks for the further prototyping.
Oct 04 07:46:23 <rwhitby> I've sent the proposal to the list.
Oct 04 07:46:24 <dwery> thaks to you too
Oct 04 07:46:26 <dwery> ok
Oct 04 07:49:47 <rwhitby> dwery: one question: what is the startup sequence if the leds start as released?
Oct 04 07:50:55 <dwery> the sequence we just designed will be used immediately
Oct 04 07:50:55 <rwhitby> (i.e. if the led is initialised as solid red, then when does it change from solid red to red/off to green ?)
Oct 04 07:51:40 <rwhitby> ok.
Oct 04 07:52:20 <rwhitby> I wonder if the kernel ever goes idle before the end of booting up ?
Oct 04 07:53:28 <rwhitby> I guess it will go from red to green/off/amber/off and then finally to green/off/green/off when it becomes idle.
Oct 04 07:53:36 <dwery> when waiting for the usb disk probably
Oct 04 07:53:45 <rwhitby> and if the timer is not enabled, then it would go from red to amber to green 
Oct 04 07:54:20 <rwhitby> so you can still use the basic scheme to identify somewhat where you are in the boot sequence
Oct 04 07:54:45 <dwery> well, yes
Oct 04 07:55:33 <rwhitby> so that's a good outcome.
Oct 04 07:56:50 <rwhitby-asleep> Well, my work here is done.
Oct 04 07:57:35 <dwery> rwhitby-asleep: mine too :-D
Oct 04 08:41:18 <CIA-8> 03koen 07org.openembedded.dev * rcec9dd28... 10/packages/hal/hal_0.5.4.bb: udev: add 0.5.4 and package the device-manager seperatly
Oct 04 09:42:32 <CIA-8> 03dlubinski * 10unslung/sources/knock/rc.knockd:
Oct 04 09:46:06 <CIA-8> 03dlubinski * 10unslung/make/knock.mk:
Oct 04 09:53:40 <CIA-8> 03dlubinski * 10unslung/Makefile:
Oct 04 10:08:47 <dwery> yvasilev: ping
Oct 04 10:17:10 <jell1> pong
Oct 04 10:17:17 <jell1> oh. no. not me.
Oct 04 10:23:20 <yvasilev> dwery: ping
Oct 04 10:23:44 <dwery> yvasilev: hi.. it seems ial 2.0 is working le.. did you tried it with the latest .14-rc3?
Oct 04 10:24:42 <yvasilev> dwery: just came online after this long offline weekend, and got the patches but have not tried them
Oct 04 10:25:13 <yvasilev> dwery: have you? any experience/advice/commentary?
Oct 04 10:25:30 <dwery> i posted on the ml.. it works, it requires a one-line fixt in the eth code
Oct 04 10:25:59 <yvasilev> do you have the link to that email?
Oct 04 10:26:19 <dwery> no :(
Oct 04 10:26:29 <dwery> have to go now..
Oct 04 10:26:31 <dwery> see ya!
Oct 04 10:26:31 <yvasilev> -linux or -dev?
Oct 04 10:26:35 <dwery> -dev
Oct 04 10:26:49 <yvasilev> bye, will look for it
Oct 04 11:09:49 <cheef_daniel> hi I tryed to build the unslung-image on my debian, but it fails with this error:
Oct 04 11:10:22 <cheef_daniel> "/usr/bin/install -c -m 755 bin/quilt bin/guards /home/nslu2/slug/unslung/tmp/staging/i686-linux/bin/"
Oct 04 11:10:35 <cheef_daniel> "/usr/bin/install: cannot change ownership of `/home/nslu2/slug/unslung/tmp/staging/i686-linux/bin/quilt': Operation not permitted"
Oct 04 11:10:55 <cheef_daniel> the user has no admin-rights
Oct 04 11:11:09 <cheef_daniel> what could I do?
Oct 04 11:11:13 <CIA-8> 03koen 07org.openembedded.dev * ra6f132d0... 10/packages/kismet/kismet_2005-08-R1.bb: packages/kismet: add 2005-08-R1
Oct 04 11:12:25 <cheef_daniel> to whose user will the script ownership?
Oct 04 11:17:07 <cheef_daniel> I think it has to do with my mount-command, but dont know
Oct 04 11:17:36 <cheef_daniel> the root user, has the same error
Oct 04 12:13:46 <Jacmet> dwery-away: I'll have a look at the LE mtd patch tonight
Oct 04 12:15:01 <[g2]> Jacmet around ?
Oct 04 12:19:28 <Jacmet> [g2]: yes?
Oct 04 12:19:38 <[g2]> debian installer ?
Oct 04 12:19:57 <Jacmet> [g2]: yes?
Oct 04 12:20:21 <[g2]> My Loft proto is loading the kernel from CF and booting directly to debian on sda
Oct 04 12:20:36 <[g2]> so now I'm missing the installer bits
Oct 04 12:20:59 <Jacmet> [g2]: Ok - I'm just using the lart installer
Oct 04 12:21:08 <Jacmet> [g2]: You are using BE, right?
Oct 04 12:21:12 <[g2]> nod
Oct 04 12:21:33 <[g2]> 98% of the installer should be identical right ?
Oct 04 12:21:34 <Jacmet> [g2]: then I guess you need to recompile the installer - I haven't tried that myself
Oct 04 12:21:41 <Jacmet> [g2]: yes
Oct 04 12:22:00 <[g2]> can we take the to #debonaras
Oct 04 12:22:06 <[g2]> s/the/this
Oct 04 12:22:22 <Jacmet> certainly
Oct 04 12:35:49 <joschi_> hi - anybody some knowledge about autoconf / automake?
Oct 04 12:37:03 <joschi_> i wonder how variables, which are determined by automake are actually passed to the compilation process...
Oct 04 12:42:39 <bullet> joschi_: configure generates config.h
Oct 04 12:43:07 <bullet> and CFLAGS/LDFLAGS... those are in the Makefiles, which also get generated
Oct 04 12:44:38 <joschi_> hm
Oct 04 12:44:48 <jp30-work> joschi_, info autoconf is your friend
Oct 04 12:45:00 <joschi_> yes, i already read that
Oct 04 12:45:19 <joschi_> but i yet don't understand completely... :(
Oct 04 12:45:25 <joschi_> it's a bit complicated :)
Oct 04 12:46:14 <joschi_> when i normally build a project, i run configure, then automake, correct?
Oct 04 12:46:27 <bullet> no. you run configure && make ...
Oct 04 12:47:13 <bullet> automake/autoconf is run to generate the configure script and all it's stuff. you would only need to run autotools if you modified configure.in/Makefile.am/... stuff
Oct 04 12:47:14 <joschi_> ok.. sure *think*
Oct 04 12:47:49 <joschi_> may i describe my actual problem in short? i try to build cups for openslug
Oct 04 12:49:51 <bullet> i don't mind. but it's not really the right place to discuss autoblah problems
Oct 04 12:53:42 <joschi_> ok, the problem is that cups always stops when compiling, because it can't find directory definitions, i.e. CUPS_SERVERROOT
Oct 04 12:54:26 <joschi_> i don't fully understand yet where the #define's should come from
Oct 04 12:54:46 <bullet> grep for em :)
Oct 04 12:54:55 <bullet> and have a look in config.h
Oct 04 12:55:06 <joschi_> yep, did that
Oct 04 12:55:56 <jp30-work> joschi_, there are two ways: you can have autoconf rewrite a header like config.h, or you can have it supply the defines in the makefile with -D
Oct 04 12:56:16 <jp30-work> either way you need to make the variables for substitution with AC_SUBST()
Oct 04 12:56:23 <joschi_> yep, the latter isn't the case for sure
Oct 04 12:57:30 <joschi_> a more general question: why does bitbake always run autoconf & automake ?
Oct 04 13:01:11 <joschi_> ok - summary: i have AC_SUBST(CUPS_SERVERROOT) in configure.in
Oct 04 13:01:49 <joschi_> but i DON'T have it in config.h
Oct 04 13:02:06 <jp30-work> have you grepped for "@CUPS_SERVERROOT@"
Oct 04 13:16:46 <joschi_> hm, maybe i found something...
Oct 04 13:16:55 <joschi_> it's also in "config-cups"
Oct 04 13:17:30 <joschi_> maybe this should be called in addition to the normal configure before compilation? i look in the cups readme...
Oct 04 13:27:13 <CIA-8> 03jp30 * 10unslung/make/qemu-libc-i386.mk: qemu-lib-i386: revert to crosstool 0.28 in an effort to fix mystery autobuild failures
Oct 04 13:31:40 <joschi_> hm, maybe i let it alone and continue using the optware version of cups in openslug...
Oct 04 13:32:00 <joschi_> i seem not to have enough knowledge how all this configure-stuff works... :(
Oct 04 14:41:15 <CIA-8> 03koen 07org.openembedded.dev * r3181a893... 10/packages/h2200-bootloader/h2200-bootloader.bb: packages/h2200-bootloader/h2200-bootloader.bb: add firmware extractor for the iPAQ h2200
Oct 04 15:31:14 <CIA-8> 03koen 07org.openembedded.dev * r79e64c2a... 10/conf/machine/h2200.conf: conf/machine/h2200.conf: add bootloader firmware dumper, needed for suspending
Oct 04 15:56:10 <cheef_daniel> is there some way to download the files which should be downloaded by the Makefile manually?
Oct 04 15:57:29 <ByronT> just wget them - place them and the md5 file in the appropriate downloads folder
Oct 04 15:57:51 <cheef_daniel> thats the problem, dont know the URL
Oct 04 15:58:09 <cheef_daniel> I know only the filename, but dont find it with google
Oct 04 15:58:13 <ByronT> check the appropriate .bb file
Oct 04 15:58:24 <ByronT> there should be a source URL in it
Oct 04 15:58:54 <cheef_daniel> thx i will have a loog
Oct 04 15:58:56 <cheef_daniel> k
Oct 04 15:59:30 <dwery> Jacmet: ack.
Oct 04 16:00:10 <cheef_daniel> or is there some way to browse the nslu2-linux.org server?
Oct 04 16:00:42 <cheef_daniel> I need 2.4.22-xfs-nslu2.patch.bzip2
Oct 04 16:01:50 <ByronT> try sources.nslu2-linux.org/sources/foo.bz2
Oct 04 16:03:10 <cheef_daniel> while I building the NSLU2-package from Master Makefile my connection to internet got lost, if I restart it then msg:" can't open input file...
Oct 04 16:03:50 <cheef_daniel> I didn't know in which bb file I must look, because the script started a while ago...
Oct 04 16:03:54 <ByronT> so blow away the tmp folder, wget the needed file and re start the make process
Oct 04 16:04:20 <ByronT> you can also use the make prefetch to pre-download the needed files first
Oct 04 16:04:36 <cheef_daniel> but then the whole makefile-script will start from beginning?
Oct 04 16:05:21 <ByronT> only if you clobber everythign
Oct 04 16:05:38 <ByronT> if something has properly built, it won't rebuild
Oct 04 16:07:18 <cheef_daniel> so I can use make prefetch without any troubles?
Oct 04 16:10:27 <dwery> jbot_, slugtime
Oct 04 16:10:57 <rwhitby-away> ~slugtime
Oct 04 16:10:58 <jbot_> methinks slugtime is 40 hour days 10 hours in 4 timezones with overlap
Oct 04 16:12:09 <dwery> rwhitby-away: thanks :)
Oct 04 16:12:52 <cheef_daniel> ByronT: thx it worked with this URL http://nslu.sourceforge.net/downloads/
Oct 04 16:13:57 <dwery> rwhitby-away: do you have a couple of mins to discuss about the power button?
Oct 04 16:14:10 <rwhitby-away> sure
Oct 04 16:14:46 <dwery> rwhitby-away: it seems the proposal are three currently: signal init, invoke /sbin/shutdown , /proc/acpi/event emulation
Oct 04 16:15:52 <rwhitby-away> how about just signal init. then the user (or distro installer) can put an entry in /etc/inittab which does the right thing.
Oct 04 16:17:05 <dwery> I don't like too much the idea the user or the installer has to instal something nslu2 specific
Oct 04 16:17:31 <dwery> let's ask jacmet about the debian installer
Oct 04 16:17:35 <dwery> Jacmet: ping
Oct 04 16:18:17 <rwhitby-away> dwery: handling ctrl-alt-del in /etc/inittab is not nslu2 specific
Oct 04 16:19:05 <dwery> rwhitby-away: mm.. right. I just noticed that the inittab on my slug hasn't the ctrlaltdel line
Oct 04 16:19:33 <rwhitby-away> running what distro?
Oct 04 16:19:37 <dwery> debian
Oct 04 16:20:00 <dwery> my fault
Oct 04 16:20:02 <dwery> it has the line
Oct 04 16:20:15 <rwhitby-away> ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Oct 04 16:21:25 <dwery> yep, but it is configure to do a reboot by default
Oct 04 16:21:38 <dwery> while the users expects a power off
Oct 04 16:23:08 <rwhitby-away> this user doesn't :-)
Oct 04 16:23:31 <rwhitby-away> my slugs are specifically modified to never power off, but I do want to reboot them sometimes.
Oct 04 16:23:39 <dwery> :)
Oct 04 16:23:56 <rwhitby-away> and I can't reach the reset button at the back ...
Oct 04 16:24:35 <dwery> you;re a worst-case user :-D
Oct 04 16:26:22 <dwery> what about signal init unless the /proc/acpi/event emulation is active?
Oct 04 16:26:35 <rwhitby-away> that works for me
Oct 04 16:27:21 <dwery> I haven't seen jbowler here recently.. I would have liked to ask his opinion in realtime :(
Oct 04 16:32:35 <jp30-work> morning rwhitby-away - i'm hoping to get optware/qemu autobuilding correctly today
Oct 04 16:33:14 <rwhitby-away> jp30-work: cool
Oct 04 16:35:06 <cheef_daniel> is there someway to scroll in a terminal to the top (out of screen) 
Oct 04 16:35:10 <cheef_daniel> ?
Oct 04 17:06:14 <eno-away> jp30-work, do you know what happened to python package? it is no longer in http://ipkg.nslu2-linux.org/feeds/unslung/cross/
Oct 04 17:12:11 <jp30-work> eno-away, i'm looking into it... just a moment
Oct 04 17:15:04 <jp30-work> i think that this may be a temporary problem due to recent problems with autobuild. the autobuild process seems to have build a python package, i expect it will upload it when it has finished building the other packages that were updated over the past couple of weeks
Oct 04 17:15:21 <eno-away> i c, thanks
Oct 04 17:15:33 <jp30-work> i'm watching the autobuilder now, should be able to see if all is OK within an hour or so
Oct 04 17:16:04 <eno-away> cool, look forward to it
Oct 04 17:21:05 <jp30-work> building file list ... done
Oct 04 17:21:05 <jp30-work> ./
Oct 04 17:21:05 <jp30-work> monotone_0.23-1_armeb.ipk
Oct 04 17:21:05 <jp30-work> py-psycopg_1.1.21-1_armeb.ipk
Oct 04 17:21:05 <jp30-work> python_2.4.2-1_armeb.ipk
Oct 04 17:21:06 <jp30-work> qemu-libc-i386_2.3.3-2_armeb.ipk
Oct 04 17:21:12 <jp30-work> ...should be uploaded now
Oct 04 17:21:57 <jp30-work> (only to some mirrors, the rest will follow soon)
Oct 04 17:22:06 <eno-away> excellent
Oct 04 21:26:00 <CIA-8> 03bzhou * 10unslung/make/py-sqlobject.mk: upstream upgrade from 0.6.1 to 0.7.0
Oct 04 21:27:14 <CIA-8> 03bzhou * 10unslung/make/py-turbogears.mk: added py-turbogears
Oct 04 21:30:25 <CIA-8> 03bzhou * 10unslung/make/py-formencode.mk: added py-formencode.mk
Oct 04 21:41:19 <CIA-8> 03bzhou * 10unslung/make/py-turbogears.mk: added py-formencode as dependency
Oct 04 22:33:45 <Jacmet> dwery-zzz: yes?
Oct 04 23:04:44 <jacques> jbot, test
Oct 04 23:04:46 <jbot> Test Failed!
Oct 04 23:11:00 <jacques> jbot, status
Oct 04 23:11:01 <jbot> Since Wed Oct  5 03:05:09 2005, there have been 1 modification, 9 questions, 0 dunnos, 0 morons and 7 commands.  I have been awake for 3h 5m 44s this session, and currently reference 109288 factoids.  I'm using about 15708 kB of memory. With 0 active forks. Process time user/system 203.61/14.76 child 0.08/0.04
Oct 04 23:11:17 <jacques> jbot, weather klft
Oct 04 23:11:20 <jbot> Lafayette, Lafayette Regional Airport, LA, United States; (KLFT) 30-12-08N 091-59-35W 11M; last updated: 2005.10.05 0553 UTC; Dew Point: 68.0 F (20.0 C); Pressure (altimeter): 29.97 in. Hg (1014 hPa); Pressure tendency: 0.01 inches (0.4 hPa) lower than three hours ago; Relative Humidity: 81%; Sky conditions: clear; Temperature: 73.9 F (23.3 C); Visibility: 10 ...
Oct 04 23:11:43 <dwery-zzz> jbot, weather limf
Oct 04 23:11:47 <jbot> Torino / Caselle, Italy; (LIMF) 45-13N 007-39E 287M; last updated: 2005.10.05 0520 UTC; Dew Point: 46 F (8 C); Pressure (altimeter): 30.18 in. Hg (1022 hPa); Relative Humidity: 81%; Sky conditions: mostly cloudy; Temperature: 51 F (11 C); Visibility: 4 mile(s); Wind: Variable at 2 MPH (2 KT)
Oct 04 23:11:52 <dwery-zzz> :-D
Oct 04 23:13:29 <jacques> lol same humidity
Oct 04 23:13:34 <dwery> yep
Oct 04 23:13:51 <dwery> Jacmet: did you read about SIGINT init on the ml?
Oct 04 23:15:33 <Jacmet> dwery: yes I did
Oct 04 23:15:48 <Jacmet> dwery: reading the ml works fine over gmane, it's just posting that doesn't
Oct 04 23:15:54 <Jacmet> that's why I never post ;)
Oct 04 23:15:56 <dwery> Jacmet: ok
Oct 04 23:17:49 <dwery> Jacmet: what do you think about the ctrlaltdel?
Oct 04 23:19:15 <Jacmet> dwery: it sounds good to me - it seems pretty "standard"
Oct 04 23:20:28 <dwery> Jacmet: how do you support changing the ctrlaltdel in inittab from the debian installer?
Oct 04 23:21:31 <Jacmet> dwery: that's a good question - perhaps with some custom postinstall script?
Oct 04 23:21:51 <Jacmet> but the standard behaviour (reboot) isn't that bad either
Oct 04 23:22:06 <dwery> isn't bad but is not what an used probably expects
Oct 04 23:22:23 <dwery> anyway, if it's doeable, it's ok for me.
Oct 04 23:23:28 <Jacmet> dwery: we can always do a nslu2 postinst script like the unslung/openslug dists do
Oct 04 23:23:43 <dwery> i think the acpid event emulation could be even left out at this point, configuring inittab in "nslu2-tools" should be enough
Oct 04 23:24:06 <Jacmet> yes, with this we don't need acpid
Oct 04 23:24:26 <dwery> Jacmet: can you create/maintain such a package?
Oct 04 23:25:06 <Jacmet> dwery: yes, but we're not there yet ;) I'll create a new installer image and test it a bit
Oct 04 23:25:56 <dwery> Jacmet: ok.. I'll suggest which binaries to include at a later time :)
Oct 04 23:26:22 <Jacmet> dwery ;)
Oct 04 23:26:56 <dwery> Jacmet: i'm going now.. thanks!
Oct 04 23:27:58 <Jacmet> dwery-away: mee too - see ya
Oct 05 01:00:50 <hanjo> hi all
Oct 05 01:02:12 <hanjo> has anyone played with cross building postgresql for openslug?
Oct 05 01:04:49 <hanjo> I need the client library so that I can access a psql server from the slugs. Searching the package repository on the wiki only shows an unslung package.
Oct 05 02:37:19 <CIA-8> 03jbowler * 10upslug2/ (5 files): 
Oct 05 02:37:19 <CIA-8> Added support for writing LE NSLU2 images (byte swapping the appropriate
Oct 05 02:37:19 <CIA-8> parts when synthesising an image.)
Oct 05 02:46:08 <CIA-8> 03hrw 07org.openembedded.dev * r5bbecea4... 10/packages/meta/ (meta-opie.bb opie-image.bb): opie-image: add irda and BT tools - close #369
**** ENDING LOGGING AT Wed Oct 05 02:59:56 2005