**** BEGIN LOGGING AT Mon Jul 18 23:59:57 2005
Jul 19 03:21:25 <bwalle> OT: Anybody using xchat here?
Jul 19 03:24:30 <bwalle> Already done, sorry
**** BEGIN LOGGING AT Tue Jul 19 05:08:40 2005
Jul 19 05:14:31 <CIA-8> 03rwhitby * 10unslung/sources/miau/miau.conf: Changed the default channel to nslu2-general.
Jul 19 05:14:56 <CIA-8> 03rwhitby * 10unslung/make/miau.mk: Bumped the IPK version.
Jul 19 06:36:06 <kitno455> re
Jul 19 06:52:20 <VoodooZ_Work> does glibc uses lookup tables for sin() & cos()?
Jul 19 06:53:14 <VoodooZ_Work> I've got a function (hough transform) which calls those two funcs LOTS in a loop for every pixels in an image and I'm trying to see if there's a way to optimize it.
Jul 19 06:54:17 <Tiersten> it does calculations on the angle
Jul 19 06:54:35 <Tiersten> as for whether it uses tables for part of it *shrug* you'll have to look it up yourself
Jul 19 06:56:37 <VoodooZ_Work> I guess it would make for a huge lookup table too.
Jul 19 06:56:52 <VoodooZ_Work> But I don't care much about memory usage, just raw speed.
Jul 19 06:56:53 <Tiersten> If you wanted to be accurate for all possible input values since it's a double yes...
Jul 19 06:57:08 <Tiersten> How accurate do you need it to be?
Jul 19 06:57:19 <VoodooZ_Work> I'd sacrifice precision for speed though.
Jul 19 06:57:30 <Tiersten> You can download fixed point implementations
Jul 19 06:57:32 <VoodooZ_Work> not much really. 
Jul 19 06:57:38 <Tiersten> That should speed it up
Jul 19 06:57:41 <VoodooZ_Work> ah!
Jul 19 06:57:53 <VoodooZ_Work> Any particular names in mind?
Jul 19 06:58:35 <Tiersten> Nope
Jul 19 06:58:36 <VoodooZ_Work> brb
Jul 19 07:01:13 <Tiersten> Are you using floating point in your code?
Jul 19 07:01:28 <VoodooZ_Work> well, that particular function forces me to.
Jul 19 07:01:41 <VoodooZ_Work> Are you familiar with the hough transform?
Jul 19 07:01:44 <Tiersten> Nope
Jul 19 07:01:54 <VoodooZ_Work> It's my first stab at it.
Jul 19 07:02:16 <Tiersten> Converting everything to fixed point will help a great deal.  You can download various fixed point implementations of the trig functions it appears.  It is in lots of libraries you can download
Jul 19 07:02:16 <VoodooZ_Work> you basically try to fit a line segment to a bunch of point of an image.
Jul 19 07:02:28 <VoodooZ_Work> ok.
Jul 19 07:02:34 <VoodooZ_Work> That's what I'll try first then.
Jul 19 07:02:45 <Tiersten> This is assuming the loss of precision is okay for you
Jul 19 07:02:48 <VoodooZ_Work> I don't need any extreme precision anyways.
Jul 19 07:02:53 <VoodooZ_Work> yeah.
Jul 19 07:03:10 <VoodooZ_Work> Thanks for the tip.
Jul 19 07:03:13 <Tiersten> np
Jul 19 07:12:14 <jbowler-zzz> VoodooZ_Work: you only need precision of 1 part in 10000 for calculations in linear light space.
Jul 19 07:12:40 <jbowler-zzz> If you use a logarithmic space you only need about 1 part in 500 (iirc)
Jul 19 07:13:01 <jbowler-zzz> The basic requirement is 1% precision (over the whole calculation),
Jul 19 07:14:06 <jbowler-zzz> (And the standard mistake is to do processing in gamma encoded space - if you do that you get 20% or more errors anyway...)
Jul 19 07:16:23 <rwhitby-away> bob_tm: good post.
Jul 19 07:17:25 <VoodooZ_Work> jbowler-zzz, ouch! You scare me! :)
Jul 19 07:17:49 <VoodooZ_Work> I guess you know what a hough transform is then. more than me too!
Jul 19 07:18:13 <VoodooZ_Work> I'm no expert but I'm trying to make it practical for my roboslug's limited processing power. 
Jul 19 07:18:14 <bob_tm> rwhitby-away: Thanks.
Jul 19 07:18:15 <jbowler-zzz> No... I've never had to do that
Jul 19 07:18:39 <VoodooZ_Work> I'm using a 320x240 image which could probably be made smaller to speed things up.
Jul 19 07:18:57 <VoodooZ_Work> I'm just trying to extract the major line segment in a segmented image.
Jul 19 07:19:06 <jbowler-zzz> Well, if you're using sin or cos for an image transform and using the standard FP implementation (which is incredibly precise) that's going to be slow...
Jul 19 07:19:24 <VoodooZ_Work> The firefighting competition I'm aiming for has white walls and black floor (most of the time!) so it should be easy to pick up the edges.
Jul 19 07:19:37 <VoodooZ_Work> yep! real slow! like 2 seconds!
Jul 19 07:19:38 <kitno455> bob_tm, kudos
Jul 19 07:19:42 <jbowler-zzz> How many ms do you have to process the image?
Jul 19 07:19:54 <jbowler-zzz> (I mean, if the speed is acceptable)
Jul 19 07:20:02 <VoodooZ_Work> it's not really a rush but I'd like to keep it under 500ms.
Jul 19 07:20:53 <VoodooZ_Work> it basically does a sin & cos for all 180 degrees for each and every pixels in the image so just switching to a lookup table would mamke a huge diff.
Jul 19 07:21:03 <jbowler-zzz> That shouldn't be a problem.  Use a table, convert the input data to linear by squaring the values, use maybe 11 or 12 bit LUTs.
Jul 19 07:21:20 <jbowler-zzz> ... i.e 2^11 entries
Jul 19 07:22:01 <VoodooZ_Work> I better take note...
Jul 19 07:22:21 <jbowler-zzz> If you were using the native (unsquared) values before the precision improvement from that will more than offset any loss in the LUT.
Jul 19 07:23:45 <jbowler-zzz> (I'm assuming the 320x240 data is from a CCD web cam and has been through the normal processing - which applies sRGB encoding to the original data, approximately 2^1/2.4 plus an offset).
Jul 19 07:24:15 <VoodooZ_Work> actually, I use YUV which is better for segmentation
Jul 19 07:24:52 <VoodooZ_Work> irregardless, the image will be edge-extracted so the hough transform function only has to deal with a binary image.
Jul 19 07:25:21 <VoodooZ_Work> so a pixel is either 1 or 0. If it's 1 hough will try to fit it to a line segment.
Jul 19 07:26:31 <VoodooZ_Work> I can paste the code to #flood if you are curious
Jul 19 07:27:09 <jbowler-zzz> I've got a reference here.
Jul 19 07:27:27 <VoodooZ_Work> which one?
Jul 19 07:27:49 <jbowler-zzz> So that's a different set of values to the one I was thinking of, but are the (x,y) you have integers?
Jul 19 07:27:58 <jbowler-zzz> http://rkb.home.cern.ch/rkb/AN16pp/node122.html
Jul 19 07:27:59 <VoodooZ_Work> unsigned chars.
Jul 19 07:28:59 <jbowler-zzz> Right, so just the original pixel coordinates - no extra data from the edge extraction (that's what I'm used to).
Jul 19 07:29:02 <VoodooZ_Work> here's the inner loop: for (omega = 0; omega < 180; ++omega)
Jul 19 07:29:02 <VoodooZ_Work>                    {
Jul 19 07:29:02 <VoodooZ_Work>                         r = (i - center_y) * sin((double)(omega*conv))
Jul 19 07:29:02 <VoodooZ_Work>                            + (j - center_x) * cos((double)(omega*conv));
Jul 19 07:29:34 <VoodooZ_Work> no, the pixel value is the result of the edge extraction. Then again, I don't have that done yet.
Jul 19 07:29:44 <jbowler-zzz> So the precision on (x,y) is just 0.5:320, 0.5:240 (i.e. +/-0.5 in 0..319 and 0..239)
Jul 19 07:30:19 <VoodooZ_Work> I guess. I don't see thing that way. 
Jul 19 07:30:55 <VoodooZ_Work> but even the line fitting is not that precise. I just need to know roughly if there's a line and at what angle.
Jul 19 07:30:57 <jbowler-zzz> Anyway, from that code fragment, sin(...) and cos(...) are expression in which the only variable is 'omega' - conv doesn't change.
Jul 19 07:31:11 <jbowler-zzz> So that's just a 180 entry LUT for each expression.
Jul 19 07:31:22 <VoodooZ_Work> right. conv = 3.1415926535/180.0;      // Deg/Rad conv. factor.
Jul 19 07:32:15 <VoodooZ_Work> that loops fills up a histogram with 180 lines and rmax collum which is later parsed to find the bin with the highest count.
Jul 19 07:32:43 <VoodooZ_Work> I forgot that from the inner loop: z[omega][rmax+r] += 1;
Jul 19 07:33:07 <VoodooZ_Work> which increases the bin matching the current line/point.
Jul 19 07:34:23 <VoodooZ_Work> so I guess it's easier than I thought then right? two 180 entries LUTs basically?
Jul 19 07:34:32 <jbowler-zzz> Yes
Jul 19 07:34:39 <VoodooZ_Work> I would still need to convert the floats to integers though
Jul 19 07:35:13 <jbowler-zzz> Make the LUTs signed char values - may -1..+1 to -127..+127
Jul 19 07:35:19 <VoodooZ_Work> the general hough transform is even more demanding as it can be used to fit ellipse and other equations. ouch!
Jul 19 07:35:25 <VoodooZ_Work> ok.
Jul 19 07:36:04 <VoodooZ_Work> to represent the radians?
Jul 19 07:36:27 <jbowler-zzz> To make the tables smaller.  You don't care about arbitrary scaling of the result
Jul 19 07:36:39 <VoodooZ_Work> i c
Jul 19 07:36:55 <jbowler-zzz> I'm counting in 1:256 precision being adequate, I think it must be.
Jul 19 07:37:24 <jbowler-zzz> Part of the problem is the range of [rmax+r] - the size of 'z' will have a fundamental affect on performance.
Jul 19 07:37:29 <VoodooZ_Work> ok. I'll have to try it as I'm not too clear on the details right now. 
Jul 19 07:38:06 <VoodooZ_Work> z? it's: center_x = image->info->nc/2;
Jul 19 07:38:06 <VoodooZ_Work>         center_y = image->info->nr/2;
Jul 19 07:38:06 <VoodooZ_Work>         rmax = (int)(sqrt((double)(image->info->nc * image->info->nc + image->info->nr * image->info
Jul 19 07:38:06 <VoodooZ_Work> ->nr))/2.0);
Jul 19 07:38:42 <VoodooZ_Work> and the image is 320x240 so rmax would be the hypothenuse.
Jul 19 07:39:28 <jbowler-zzz> I would just write the equations out long hand and try to simplify them.
Jul 19 07:39:56 <VoodooZ_Work> yeah.
Jul 19 07:40:04 <jbowler-zzz> I.e. re-arrrange them to get the terms which are in the actual image data in an obvious place.
Jul 19 07:40:36 <jbowler-zzz> Math sends some people to sleep of course.
Jul 19 07:40:44 <VoodooZ_Work> yes, I'm one of them.
Jul 19 07:41:02 <VoodooZ_Work> the irony is that I work for the math&stat dept of the University of Ottawa! :)
Jul 19 07:41:09 <VoodooZ_Work> As a sys. admin though so...
Jul 19 07:41:37 <VoodooZ_Work> My math skills are a bit lacking so it's holding me back when trying to learn more complex stuff.
Jul 19 07:43:20 <jbowler-zzz> It looks like this stuff can be done with algebra and code hacking though - my advanced math skills are pretty much absent but I can rearrange code and algebraic equations.  That's enough.
Jul 19 07:43:35 <VoodooZ_Work> Anyways, thanks for all the suggestions. I have to do maintenace on our beowulf so I'll be back later.
Jul 19 07:43:39 <VoodooZ_Work> true.
Jul 19 07:43:53 <VoodooZ_Work> bbl
Jul 19 07:49:22 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r37a0ff9e... 10/ (conf/distro/openslug.conf packages/linux/nslu2-kernel.inc): 
Jul 19 07:49:22 <CIA-8> Support for disabling irq debug messages - slugbug 109.
Jul 19 07:49:22 <CIA-8> This allows a simple local.conf change to re-enable the debug messages
Jul 19 07:49:22 <CIA-8> simply by setting CMDLINE_DEBUG to ""
Jul 19 07:50:31 <NAiL> jbowler-zzz: ping?
Jul 19 07:51:34 <NAiL> re irq, is this at all relevant? http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2005-July/030195.html
Jul 19 07:54:08 <jbowler-zzz> I think it's the same issue - it's do_level_IRQ on irq26 (I suspect the FP stuff is irrelevant).
Jul 19 07:54:33 <Tiersten> The FP stuff is just in there because it received the spurious interrupt whilst it was doing some FP op
Jul 19 07:55:56 <jbowler-zzz> Either level triggered interrupt handling is globally broken (unlikely) or the ehci_hcd handling is unable to clear the interrupt without it getting re-issued - quite possible.
Jul 19 07:56:20 <jbowler-zzz> Anwyay, the latter is the current assumption.  It's only ever irq26, at least on NSLU2.
Jul 19 07:57:18 <Tiersten> Or the NEC chip is just screwed up in yet another way
Jul 19 07:58:02 <jbowler-zzz> Although in that message the interrupt handler is different - CAN_Interrupt, whereas in NSLU2 it's usb_hcd_irq.
Jul 19 07:59:00 <jbowler-zzz> NAiL: slugbug 175: do you want to fix it or defer it?
Jul 19 08:00:20 <NAiL> Not sure where to fix it actually
Jul 19 08:01:08 <NAiL> I fixed it on my slug, by getting the correct file from my debian box
Jul 19 08:01:10 <jbowler-zzz> I think uclibc supports looking at /etc/TZ
Jul 19 08:01:16 <NAiL> yeah
Jul 19 08:01:32 <NAiL> uclibc has a solution that works better in this case, since it has to be small
Jul 19 08:01:52 <NAiL> ie, uclibc uses a "simple" string that defines the TZ
Jul 19 08:02:00 <jbowler-zzz> Hum... have to think about it some more - I think there must be something small which works for both glibc and uclibc
Jul 19 08:02:30 <jbowler-zzz> Apart from that so far as I am concerned OpenSlug-2.3-beta is ready to go.
Jul 19 08:02:42 <jbowler-zzz> (After, maybe, a little bit of testing).
Jul 19 08:04:39 <NAiL> Just let me sneak in that feed change of mine, and I'm happy with 2.3-beta as well
Jul 19 08:04:50 <jbowler-zzz> Ah right.  I had forgotten about that.
Jul 19 08:05:06 <ByronT> so should I be gearing up for a beta release?
Jul 19 08:05:12 <jbowler-zzz> Yes
Jul 19 08:05:13 <ByronT> assuming 20 alpha users
Jul 19 08:05:20 <ByronT> ok
Jul 19 08:05:32 <ByronT> I'll create my staging...
Jul 19 08:06:05 <ByronT> 2.3?
Jul 19 08:06:30 <jbowler-zzz> Unless something goes wrong.  NAiL needs to update the feeds - does that still need significant work?
Jul 19 08:06:43 <ByronT> any changes to the README?
Jul 19 08:06:51 <NAiL> jbowler-zzz: no, it's kind of a small task. I just haven't gotten around to it yet
Jul 19 08:07:07 <jbowler-zzz> I don't think there will be any README changes.
Jul 19 08:07:23 <ByronT> k
Jul 19 08:07:56 <ByronT> when we hit 20 alpha, let me know and I'll update the appropriate places
Jul 19 08:08:02 <jbowler-zzz> Need to get a signoff from [g2], and it would be good if hanjo confirms that the NFS stuff works for him.
Jul 19 08:09:33 <CIA-8> 03nail 07org.openembedded.nslu2-linux * rfd2bac75... 10/conf/distro/openslug.conf: Split the feeds into cross/native and ${DISTRO_VERSION}/unstable
Jul 19 08:09:35 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r71af6d66... 10/ (24 files in 18 dirs): 
Jul 19 08:09:35 <CIA-8> propagate from branch 'org.openembedded.dev' (head a84100b19e514d33f6c1ebe63173f106d9b09026)
Jul 19 08:09:35 <CIA-8>  to branch 'org.openembedded.nslu2-linux' (head 37a0ff9ee9b45b44e556016ce81b5cba475a2b3f)
Jul 19 08:11:05 <[g2]> jbowler-zzz, I'd like to have the irq26 issue patched in the kernel for the 2.3 release if that's ok with you
Jul 19 08:11:43 <jbowler-zzz> [g2]: that was done about 15min ago
Jul 19 08:12:06 <[g2]> in the kernel.inc from 10:49 
Jul 19 08:12:58 <jbowler-zzz> In the openslug.conf from then - nslu2-kernel.inc was just changed to make it easier to add extra kernel command line options.
Jul 19 08:16:42 <jbowler-zzz> bbl
Jul 19 08:16:42 <[g2]> jbowler-zzz, do we lose all the other debugging info too ?
Jul 19 08:16:51 <[g2]> nite
Jul 19 08:17:03 <NAiL> That's just the noirqdebug thing, isn't it?
Jul 19 08:17:05 <[g2]> thx
Jul 19 08:17:17 <jbowler-zzz> That disables the report_bad_irq logging
Jul 19 08:17:44 <[g2]> you just added noirqdebug to the cmd line ?
Jul 19 08:17:55 <jbowler-zzz> So, specifically, it disables logging of a return code != IRQ_HANDLED from an irq handler.
Jul 19 08:18:24 <[g2]> nod.
Jul 19 08:18:25 <jbowler-zzz> So you should probably put CMDLINE_DEBUG="" into local.conf
Jul 19 08:19:27 <[g2]> with APEX I can just reboot and pass it to the kernel
Jul 19 08:19:59 <jbowler-zzz> Yes, assuming there is some way of cancelling the built in command line (or maybe 'irqdebug' will cancel it).
Jul 19 08:20:32 <[g2]> APEX passes the cmd line params properly to the kernel
Jul 19 08:21:21 <[g2]> I think you may be right however, the kernel may just ignore them
Jul 19 08:21:35 <[g2]> no.... it uses them
Jul 19 08:35:54 <jbowler-zzz> hanjo: the current head of the monotone tree is a candidate for OpenSlug-2.3-beta
Jul 19 08:36:17 <jbowler-zzz> There are two NFS root related bug fixes in there (checked in about 8 hours ago)
Jul 19 08:36:49 <hanjo> Jbowler, I have problems with the head
Jul 19 08:37:06 <hanjo> turnup nfs -i gives error on creation of linuxrc.new
Jul 19 08:37:22 <hanjo> says read-only file sytem etc..
Jul 19 08:37:51 <hanjo> The image was build ~ 2-3 hours ago
Jul 19 08:37:51 <VoodooZ_Work> I noticed someone changed the optimization parameter for openslug's build.
Jul 19 08:38:10 <VoodooZ_Work> When it says it's better with -Os does it mean better in terms of space or speed?
Jul 19 08:39:00 <DaKa2> space
Jul 19 08:39:03 <hanjo> I beleive -Os is optimized for space. At least it is so on the TIMSP430 microcontrollers
Jul 19 08:39:34 <NAiL> yes, -Os is space
Jul 19 08:39:57 <NAiL> but that does not necessarily mean that it runs slower
Jul 19 08:40:13 <VoodooZ_Work> hopefully not.
Jul 19 08:40:42 <VoodooZ_Work> although I'm probably the only one that runs off the onboard flash I care mostly about speed.
Jul 19 08:41:01 <VoodooZ_Work> but what caused the change?
Jul 19 08:42:30 <hanjo> The only drawback of -Os is that it has a tendency of exposing strange gcc bugs :) Especially with regards to volatile vars etc. 
Jul 19 08:42:41 <VoodooZ_Work> not good!
Jul 19 08:43:38 <hanjo> One has to be more carefull, that is all.
Jul 19 08:44:05 <hanjo> Mind you, this is from my msp430 experience, I have no idea about the arm
Jul 19 08:47:47 <VoodooZ_Work> those freaking 3-way merges!!! arrrgghh!
Jul 19 08:48:10 <jbowler-away> hanjo: either you are not up to date or there is something wrong with my fix for slugbug 207
Jul 19 08:48:11 <VoodooZ_Work> I'm still getting them for no reason. I didn't even touch base-files and it is complaining about it.
Jul 19 08:48:29 <hanjo> hmm
Jul 19 08:48:32 <hanjo> I get:
Jul 19 08:48:33 <hanjo> root@LKG7F6525:~# turnup nfs -f 192.168.1.2:/var/nslu2/exports/rootfs/full/LKG7F6525
Jul 19 08:48:37 <jbowler-away> Your /etc/default/functions should contain both mountflashand umountflash (sp?) if you have thefix.
Jul 19 08:48:37 <hanjo> /usr/sbin/turnup: umounting any existing mount of /dev/mtdblock4
Jul 19 08:48:37 <hanjo> /usr/sbin/turnup: 888: cannot create /tmp/flashdisk.1011/linuxrc.new: Read-only file system
Jul 19 08:48:37 <hanjo> turnup: boot_rootfs: failed to write /tmp/flashdisk.1011/linuxrc.new
Jul 19 08:49:29 <CIA-8> 03jp30 * 10unslung/ (Makefile make/emacs.mk): move emacs back to native, promote ocaml, taged
Jul 19 08:50:18 <jbowler-away> There's something wrong with the fix then.  It sounds like the umount is not working (and producing no errors).
Jul 19 08:50:25 <hanjo> I have mountflash() and unmountflash()
Jul 19 08:51:04 <jbowler-away> After the turnup errors out there should be no mounts on the system of /dev/mtdblock4 - is there anything strange in /proc/mounts?
Jul 19 08:51:40 <hanjo> it is still there
Jul 19 08:51:53 <hanjo> "/dev/mtdblock4 on / type jffs2 (ro,noatime)"
Jul 19 08:54:39 <jbowler-away> Do you know how / got mounted read only?
Jul 19 08:54:58 <NAiL> mount -o remount,ro / ?
Jul 19 08:55:05 <NAiL> duh
Jul 19 08:55:09 <NAiL> just ignore me :P
Jul 19 08:55:10 <hanjo> I did a shutdown -r now
Jul 19 08:55:24 <hanjo> this is the second boot after the flashing
Jul 19 08:56:07 <hanjo> on the first I've tried turnup nfs -i,  it failed, and I did shutdown -r now, and this is the state I am in now.
Jul 19 08:56:12 <jbowler-away> Well, a read-only, flash, / will stop the linuxrc being changed (and there is no way round this that I can see).
Jul 19 08:56:31 <jbowler-away> What does /etc/fstab have in it?
Jul 19 08:56:32 <hanjo> ok
Jul 19 08:57:04 <hanjo> "rootfs          /               jffs2   defaults        1  1"
Jul 19 08:58:06 <hanjo> I'll reflash again with upslug and check the state after the first unsucessfull turnup command
Jul 19 08:58:54 <jbowler-away> Check the state before turnup - / should be mounted rw.
Jul 19 09:09:07 <hanjo> turnup is leaving /dev/mtdblock4 mounted ro
Jul 19 09:09:16 <hanjo> before turnup it is rw
Jul 19 09:11:47 <hanjo> have to go now. bbl
Jul 19 09:12:48 <CIA-8> 03jp30 * 10unslung/make/unslung-devel.mk: add file to unslung-devel
Jul 19 09:24:28 <CIA-8> 03nail 07org.openembedded.nslu2-linux * r0788484c... 10/packages/samba/samba_3.0.14a.bb: Added smb.conf to CONFFILES
Jul 19 09:37:21 <NAiL> [g2]: ping?
Jul 19 09:37:26 <CIA-8> 03jp30 * 10unslung/make/ (gdbm.mk libdb.mk libgc.mk): libtool fixes
Jul 19 10:05:03 <CIA-8> 03jp30 * 10unslung/ (Makefile unslung-check-package.pl): check for host paths
Jul 19 10:07:29 <CIA-8> 03jp30 * 10unslung/make/pcre.mk: libtool fixes
Jul 19 10:18:12 <CIA-8> 03jp30 * 10unslung/make/cyrus-sasl.mk: libtool fixes, strip
Jul 19 10:25:31 <[g2]> NAiL, pong
Jul 19 10:26:13 <jbowler-away> hanjo_log: fixed in 3a43238b0a602039ba26a7418ed911eaee3d4748, it effectively prevented turnup when the flash file system was root.  The only changed file is /etc/default/functions.
Jul 19 10:27:46 <DaKa2> [g2]: should I update PackageStatus with my build from today?
Jul 19 10:28:01 <[g2]> DaKa2, is it a full build ?
Jul 19 10:28:04 <DaKa2> yep
Jul 19 10:28:11 <[g2]> excellent then sure
Jul 19 10:28:53 <DaKa2> ok, updated
Jul 19 10:29:00 <DaKa2> just a few package version changes
Jul 19 10:29:38 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r3a43238b... 10/packages/openslug-init/ (openslug-init-0.10/functions openslug-init_0.10.bb): 
Jul 19 10:29:39 <CIA-8> unmountflash would make /dev/mtdblock4 on / ro, this only affects a turnup
Jul 19 10:29:39 <CIA-8> when the flash file system is mounted on /, but it causes the edit of the
Jul 19 10:29:39 <CIA-8> /linuxrc to fail.
Jul 19 10:43:22 <VoodooZ_Work> [g2], interesting thread.
Jul 19 10:43:32 <VoodooZ_Work> Especially the JFFS2 summary patch.
Jul 19 10:43:39 <VoodooZ_Work> Ever heard of it?
Jul 19 10:43:43 <VoodooZ_Work> What about JFFS3?
Jul 19 10:50:46 <NAiL> [g2]: Did you see the mail on the ml re apache/php?
Jul 19 10:52:10 <[g2]> NAiL, http://groups.yahoo.com/group/nslu2-linux/message/7591
Jul 19 10:53:13 <NAiL> yes
Jul 19 10:53:41 <VoodooZ_Work> [g2], do you think the JFFS2 patch  will make it in the kernel? Or should I install it in openslug myself?
Jul 19 10:53:55 <NAiL> You're the one who knows an ETA :P
Jul 19 10:54:01 <VoodooZ_Work> http://www.inf.u-szeged.hu/jffs2/index.php
Jul 19 10:54:03 <NAiL> VoodooZ_Work: What jffs2 patch?
Jul 19 10:54:18 <NAiL> oh
Jul 19 10:54:31 <VoodooZ_Work> the one suggested in a thread on lak to speed bootups.
Jul 19 10:54:39 <NAiL> ah, yes
Jul 19 10:54:50 <VoodooZ_Work> apparently is part of JFFS3 but there is a patch to speed mounts.
Jul 19 10:55:06 <NAiL> I thought jffs2 already did BBC? Thought that was one of the features that was added from jffs1?
Jul 19 10:55:19 <VoodooZ_Work> I have no clue how much of a difference it makes but anything that speeds up the boot of the slug is good!
Jul 19 10:55:24 <NAiL> yes :)
Jul 19 10:55:51 <[g2]> NAiL, I wish I knew the answer to the ETA
Jul 19 10:56:23 <[g2]> there are issues to work out with the individual packages as DaKa2 pointed out and the conflicts
Jul 19 10:56:36 <NAiL> aha, the conflict list
Jul 19 10:56:37 <[g2]> and that's just the proper setup for now
Jul 19 10:57:08 <[g2]> I'm checking out whether just file or file and libtool are required for building perl
Jul 19 10:57:39 <VoodooZ_Work> what type of flash do we have on the slug?
Jul 19 10:57:44 <[g2]> NOR
Jul 19 10:57:49 <VoodooZ_Work> ok
Jul 19 10:57:59 <[g2]> VoodooZ_Work, dunno about including that patch 
Jul 19 10:59:21 <[g2]> It does look quite interesting though
Jul 19 11:00:14 <NAiL> the mount time stuff only works on nand right now, doesn't it?
Jul 19 11:00:23 <NAiL> so it's only the BBC part that is relevant
Jul 19 11:00:38 <[g2]> dunno
Jul 19 11:02:29 <VoodooZ_Work> yeah, unfortunately it looks like a NAND thing only. crap!
Jul 19 11:03:17 <NAiL> I don't think that the BBC patch should go in just before a release either
Jul 19 11:04:17 <DaKa2> [g2]-away: forgot to say, tested with new libtool and file, same problem, Im thinking some problem in toolchain, gcc seems to be using functions in libc.a but not libc.so, but, don't really know anything about stuff like that...
Jul 19 11:04:17 <NAiL> There was talk about this BBC stuff over at wrt54g about a year ago
Jul 19 11:05:00 <VoodooZ_Work> don't worry, I only cared for the Summary patch.
Jul 19 11:05:01 <NAiL> VoodooZ_Work: You might wanna check with the people over in #wrt54g, and hear if they added the patch, and their experience
Jul 19 11:05:04 <NAiL> aha
Jul 19 11:05:13 <NAiL> well.. then it doesn't matter much :P
Jul 19 11:05:25 <VoodooZ_Work> 60 seconds is way too long of a boot.
Jul 19 11:06:39 <NAiL> yeah
Jul 19 11:06:39 <Tiersten> RedBoot waits a few seconds itself
Jul 19 11:08:09 <jbowler-away> Where does the time go?
Jul 19 11:08:21 <ByronT> it sneaks away
Jul 19 11:08:44 <VoodooZ_Work> hard to tell. I know redboot takes a good chunk of it.
Jul 19 11:09:14 <VoodooZ_Work> I'm too chicken to switch to Apex quite yet but I'll eventually do.
Jul 19 11:09:36 <Tiersten> It's a max of about 5 seconds so I wouldn't say it was that huge
Jul 19 11:09:46 <jbowler-away> If there is a single problem it should be obvious from the console output.
Jul 19 11:10:45 <NAiL> hmm
Jul 19 11:14:10 <NAiL> aha
Jul 19 11:14:13 <VoodooZ_Work> I tried a few months ago but it was not obvious.
Jul 19 11:14:22 <NAiL> That's why jffs3 isn't used by wrt
Jul 19 11:14:25 <VoodooZ_Work> perhaps I'll try again.
Jul 19 11:14:30 <NAiL> It's basically for nand
Jul 19 11:14:35 <VoodooZ_Work> i see.
Jul 19 11:14:58 <NAiL> But the BBC patch would be interesting for jffs2, if it isn't already in there
Jul 19 12:09:04 <macsat> hi
Jul 19 12:19:07 <CIA-8> 03nail 07org.openembedded.nslu2-linux * r76ec428e... 10/packages/samba/samba_3.0.14a.bb: Back out CONFFILES change that only worked in my imagination
Jul 19 14:47:57 <DaKa2> dammit.. not again
Jul 19 14:48:12 <DaKa2> 3-way merge I cannot do..
Jul 19 14:48:22 <DaKa2> monotone: trying 3-way merge
Jul 19 14:48:22 <DaKa2> monotone: misuse: no unique private key for cert construction
Jul 19 15:11:34 <[g2]> Jacmet, hey congrats on the article ! http://www.linuxdevices.com/news/NS6152296875.html
Jul 19 15:15:07 <[g2]> couldn't we just used the rootdelay option to boot straight to the usb too ?
Jul 19 15:29:58 <jbowler-away> Daka2: fixed
Jul 19 15:30:12 <jbowler-away> or even DaKa2: fixed
Jul 19 15:30:33 <jbowler-away> JBowler-Away wonders whether ID matching is case sensitive
Jul 19 15:30:46 <[g2]> jbowler-away, is there a good way to clone a monotone db ?
Jul 19 15:30:52 <jbowler-away> ;-)
Jul 19 15:30:53 <jbowler-away> cp
Jul 19 15:31:02 <[g2]> I was wondering about that
Jul 19 15:31:22 <jbowler-away> cp and bk clone are equivalent
Jul 19 15:31:23 <[g2]> there are no absolute paths in the db ?
Jul 19 15:31:28 <jbowler-away> no
Jul 19 15:31:36 <[g2]> excellent... the way it should be
Jul 19 15:31:41 <DaKa2> ahh, fantastic
Jul 19 15:31:45 <jbowler-away> the only thing to be aware of is that that private key in the db is used by the server as its id
Jul 19 15:32:13 <DaKa2> "cvs update: [22:32:03] waiting for jp30's lock in /cvsroot/nslu/unslung/sources/poptop"
Jul 19 15:32:13 <jbowler-away> so if you copy it around without killing the private key you may end up with indistiguisable servers
Jul 19 15:32:59 <[g2]> that's a good point to note, but for right now just doing pulls shouldn't be an issue should it ?
Jul 19 15:33:39 <jbowler-away> You can serve from that - it's only an issue if you do monotone serve
Jul 19 15:34:16 <[g2]> I don't think I'm currently serving anything
Jul 19 15:34:21 <jbowler-away> To avoid errors drop the private key on any database which contains stuff you don't want to get out.
Jul 19 15:35:12 <jbowler-away> Of course, dropping the private key stops you adding anything to it too...
Jul 19 15:35:35 <[g2]> well I do play around changing stuff locally
Jul 19 15:35:40 <jbowler-away> (This is why DaKa2 can't merge - no private key - but that's nice and safe.)
Jul 19 15:36:33 <[g2]> BTW... what do you think about that rootdelay option ?? with ext2 we should be able to boot straight to a usb device
Jul 19 15:37:38 <jbowler-away> which rootdelay option?
Jul 19 15:38:11 <[g2]> there's one mentioned in http://peter.korsgaard.com/articles/debian-nslu2.php
Jul 19 15:38:25 <[g2]> it's supposed to be in 2.6.11+
Jul 19 15:39:45 <[g2]> Documentation/kernel-parameters.txt:    rootdelay=      [KNL] Delay (in seconds) to pause before attempting to
Jul 19 15:40:44 <jbowler-away> I don't see the point.
Jul 19 15:40:46 <[g2]> sho'nuf it looks like it's in 2.6.12 :)
Jul 19 15:40:55 <[g2]> boot straight to usb devices
Jul 19 15:41:12 <[g2]> no pivot root from jffs2
Jul 19 15:41:16 <jbowler-away> What does that achieve?
Jul 19 15:42:19 <[g2]> simple not writes to the jffs2 needed except for replacing the kernel
Jul 19 15:42:26 <[g2]> no writes
Jul 19 15:43:34 <jbowler-away> You can achieve that simply enough by mounting the root readonly
Jul 19 15:43:35 <[g2]> an ipkg update with a post install of re-writing the kernel would be a full upgrade
Jul 19 15:43:56 <[g2]> ipkg upgrade
Jul 19 15:44:13 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r9ce79f68... 10/packages/ (7 files in 6 dirs): 
Jul 19 15:44:13 <CIA-8> propagate from branch 'org.openembedded.dev' (head 4ebdb5bb78b28c6a866bf5b6492e5fc7c9a839b9)
Jul 19 15:44:13 <CIA-8>  to branch 'org.openembedded.nslu2-linux' (head aa532a4ba0ea2a76e4470138c314b376c07c7751)
Jul 19 15:44:33 <jbowler-away> I still don't see what the point is to not writing to the flash if the method of achieving it involves not using the flash...
Jul 19 15:45:32 <jbowler-away> Just seems like a waste of 6MByte of flash...
Jul 19 15:45:33 <[g2]> you lost me there
Jul 19 15:45:46 <jbowler-away> What is the point in not writing to the flash?
Jul 19 15:45:47 <[g2]> the first one not the second one
Jul 19 15:46:32 <[g2]> I'd see it as 4-6MB of non-volatile storage
Jul 19 15:46:52 <[g2]> keep all the config/persistent files there
Jul 19 15:47:47 <[g2]> we're doing a watchdog reset now right ?
Jul 19 15:47:57 <jbowler-away> switchbox - can be made to fit in one block (the one currently wasted with the emtpy ram file system), can boot to usb.
Jul 19 15:48:18 <jbowler-away> and permits recovery when the rootfs gets damaged
Jul 19 15:49:05 <jbowler-away> use the remaining blocks of the now unused Flashdisk partition for whatever you want.
Jul 19 15:49:44 <[g2]> right
Jul 19 15:49:53 <jbowler-away> doesn't require compiling a specific file system driver into the kernel - so doesn't require a different kernel for every root file system type.
Jul 19 15:50:28 <[g2]> well there's the network drivers issue
Jul 19 15:50:40 <jbowler-away> there's enough space in the payload for support for a couple of file system types.
Jul 19 15:51:07 <jbowler-away> the network drivers fit in the payload, but it gets cramped
Jul 19 15:51:45 <[g2]> one interesting idea would be this....
Jul 19 15:51:46 <jbowler-away> it's easier just to make a small initrd with whatever is required in /lib/modules
Jul 19 15:52:01 <[g2]> just tweak the kernel to do the following
Jul 19 15:52:14 <[g2]> if the reset button isn't depressed boot to usb
Jul 19 15:52:29 <[g2]> if it is... boot from flash which has the default image
Jul 19 15:53:09 <jbowler-away> well, if we can get the nslu2-io.c driver written then it's easy to read the reset button from a linuxrc
Jul 19 15:53:12 <[g2]> rwhitby-treo, hey... did you see http://peter.korsgaard.com/articles/debian-nslu2.php#requirements
Jul 19 15:53:14 <jbowler-away> now that would help...
Jul 19 15:53:46 <[g2]> rwhitby-treo, less the #requirements part
Jul 19 15:54:21 <[g2]> the nslu2-io.c used to read the button
Jul 19 16:09:20 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r80a8130b... 10/conf/distro/openslug.conf: 
Jul 19 16:09:20 <CIA-8> OpenSlug-2.3-beta
Jul 19 16:09:20 <CIA-8> Tagged revision to capture OpenSlug-2.3-beta
Jul 19 16:09:22 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * rf7ca9da6... 10/conf/distro/openslug.conf: The head is OpenSlug-2.4-beta to avoid confusion.
Jul 19 16:17:05 <jbowler-away> OpenSlug-2.3-beta:  The release is now available for alpha test in the monotone database.  To check out this release:
Jul 19 16:17:12 <jbowler-away> monotone --db=/home/nslu2/mt/jbowler.db co --revision=t:OpenSlug-2.3-beta OpenSlug-2.3-beta
Jul 19 16:18:16 <[g2]> COOL
Jul 19 16:18:43 <jbowler-away> To update an existing working tree to this release:
Jul 19 16:18:47 <jbowler-away> monotone update --revision=t:OpenSlug-2.3-beta
Jul 19 16:21:20 <[g2]> jbowler-away, so OpenSlug-2.3-beta is a global name ?
Jul 19 16:30:44 <jbowler-away> [g2]: apparently, yes
Jul 19 17:18:56 <[g2]> jbowler-away, what's the command for converting and old monotone db with 21 ?
Jul 19 17:19:29 * [g2] can't type for crap these days
Jul 19 17:19:53 <rwhitby-web> mt db migrate
Jul 19 17:21:19 <[g2]> mt migrate ?
Jul 19 17:23:46 <rwhitby-web> monotone db migrate
Jul 19 17:25:08 <rwhitby-web> monotone -db=nslu2-linux.db db migrate if you're not using the master makefile
Jul 19 17:25:17 <[g2]> hmmm... I think I'm was at 0.18
Jul 19 17:25:40 <jbowler-away> I think that will be ok.
Jul 19 17:25:49 <rwhitby-web> yeah, that's fine
Jul 19 17:27:36 <[g2]> cool... I've got perms issues
Jul 19 17:27:41 <[g2]> fixing right now
Jul 19 17:28:29 <[g2]> disks and computers never seem fast enough :)
Jul 19 19:05:54 <SpanKY> [g2]: awake daddy-o ?
Jul 19 19:06:06 <SpanKY> that reflash script ... you cant use it to flash *just* the kernel ?
Jul 19 19:07:19 <[g2]> SpanKY, one can but I don't know which version you've got
Jul 19 19:07:38 <[g2]> we are getting ready for the next binary release
Jul 19 19:07:59 <[g2]> you may want to wait a few days or a week and just use that
Jul 19 19:08:36 <[g2]> you know....
Jul 19 19:08:48 <SpanKY> i used the source tarball ... so whatever day i d/l-ed it
Jul 19 19:08:48 <[g2]> there should be an OE ebuild in gentoo
Jul 19 19:08:53 <SpanKY> read my mind and tell me when that was
Jul 19 19:09:14 <[g2]> today's ?
Jul 19 19:09:22 <SpanKY> brr wrong
Jul 19 19:09:38 <SpanKY> looks like i d/l-ed it like 3 weeks ago
Jul 19 19:09:44 <SpanKY> guess i should switch to monotone
Jul 19 19:10:12 <[g2]> jacques, said that addded the ebuild for version 21 yesterday
Jul 19 19:10:22 <[g2]> ~x86 I'd guess
Jul 19 19:11:37 <[g2]> but with a simple ebuild that had some deps on some packages all in portage it'd be easy for gentoo users to build
Jul 19 19:12:59 <[g2]> http://www.nslu2-linux.org/wiki/OpenEmbedded/RequiredSoftware
Jul 19 19:13:20 <[g2]> in the Gentoo section that plus monotone
Jul 19 19:14:08 <[g2]> then one can just wget http://www.nslu2-linux.org/Makefile; make build-openslug
Jul 19 19:14:44 <[g2]> it takes a long to on the first monotone pull though
Jul 19 19:18:23 <SpanKY> i imagine so
Jul 19 19:18:28 <SpanKY> i'm gonna start that and get some f00d
Jul 19 19:18:29 <SpanKY> thanks
Jul 19 19:18:31 <Tiersten> It's a better now with 0.21
Jul 19 19:18:40 <Tiersten> Still slow but not as bad
Jul 19 19:18:59 <SpanKY> btw, i dont know who controls the busybox config, but enabling 'tab completion' is the #1 feature i wish was added ;)
Jul 19 19:20:58 <SpanKY> heh, too bad pysco sucks on amd64
Jul 19 19:21:13 <[g2]> runs fine on mine
Jul 19 19:21:19 <SpanKY> lies !
Jul 19 19:21:26 <SpanKY> mmm that note about bitkeeper should be removed
Jul 19 19:21:31 <[g2]> but I'm running debian on the amd64 :)
Jul 19 19:21:32 <SpanKY> especially since you cant even run it anymore
Jul 19 19:21:43 <SpanKY> it'll error 'No free version after July 1 !'
Jul 19 19:21:43 <[g2]> nod on the bk
Jul 19 19:21:58 <SpanKY> hmm i can edit it
Jul 19 19:22:30 <[g2]> it's a wiki right :)
Jul 19 19:22:47 <[g2]> only the top level pages are controlled
Jul 19 19:22:52 <SpanKY> hrm, the note about requiring X was wrong anyways
Jul 19 19:23:04 <SpanKY> installing bitkeeper would pull X only if you have X in USE
Jul 19 19:23:13 <SpanKY> and if that's an error it's your own damned fault
Jul 19 19:24:01 <SpanKY> bbiab, grub
Jul 19 19:25:00 <[g2]> cheers
Jul 19 19:25:10 <[g2]> jbowler-away, are you away ?
Jul 19 19:26:56 <[g2]-amd64> monotone --db=monotone/nslu2-linux.db co --revision=t:OpenSlug-2.3-beta OpenSlug-2.3-beta
Jul 19 19:26:57 <[g2]-amd64> monotone: expanding selection 't:OpenSlug-2.3-beta'
Jul 19 19:26:57 <[g2]-amd64> monotone: expanded to '94612cda9b64223716ba5b9c5dadc1fa29d554af'
Jul 19 19:26:57 <[g2]-amd64> monotone: misuse: revision 94612cda9b64223716ba5b9c5dadc1fa29d554af is not a member of branch org.nslu2-linux.dev
Jul 19 19:30:09 <rwhitby-web> [g2]: why are you trying to check out an openembedded revision tag into a nslu2-linux master makefile branch?
Jul 19 19:30:40 <rwhitby-web> (or maybe it's monotone trying to do that ....)
Jul 19 19:30:55 <[g2]> monotone is probably trying to do that
Jul 19 19:31:19 <rwhitby-web> in any case, the error message is correct - that tag is not a member of org.nslu2-linux.anything - it's a member of org.openembedded.dev or org.openembedded.nslu2-linux
Jul 19 19:32:04 <[g2]> ok.. So the command jbowler gave wasn't correct
Jul 19 19:32:30 <[g2]> I don't know the differene, I"m just trying to test the OpenSlug tagged release
Jul 19 19:32:48 <[g2]> what would the proper command be
Jul 19 19:33:04 <[g2]> (it makes sense that it's an OE tag
Jul 19 19:33:09 <[g2]> )
Jul 19 19:37:15 <rwhitby-web> maybe add a --branch=org.openembedded.nslu2-linux to it ...
Jul 19 19:37:37 <[g2]> ok
Jul 19 19:37:43 <rwhitby-web> cause you're probably doing it in /home/slug which is by default the org.nslu2-linux.dev branch
Jul 19 19:38:18 <rwhitby-web> (probably stores that default in /home/slug/MT somewhere ..)
Jul 19 20:03:31 <SpanKY> damn, monotone is still going heh
Jul 19 20:14:40 <jbowler> [g2]: that's correct, the command will work if you aren't in a monotone directory (neither any parent of the directory nor the directory itself contains MT)
Jul 19 20:15:32 <jbowler> If you are in /home/nslu2 then just cd to openembedded and use the 'update' command (then run 'make openslug-build' - a make update will put the latest revision again.)
Jul 19 20:17:20 <jbowler> BTW if you try to run builds in parallel and you run ccache at some point the two builds will end up building the same thing at the same time and one or both will fail.
Jul 19 22:33:51 <Jacmet> jbowler-zzz: regarding rootdelay - it was just so I didn't need an initrd/jffs2 partition to boot from USB ..
Jul 19 23:03:48 <jbowler-zzz> because the kernel didn't support jffs2?
Jul 19 23:05:04 <jbowler-zzz> I guess if you remove the jffs2 support it's possible to put more stuff into the kernel (given the 1MByte compressed size restriction).
Jul 19 23:10:59 <Jacmet> jbowler-zzz: well, it was for my Debian setup, so I didn't need jffs2 for anything else
Jul 19 23:11:29 <jbowler-zzz> right, the mtd drivers can go too I believe.
Jul 19 23:11:33 <Jacmet> jbowler-zzz: http://peter.korsgaard.com/articles/debian-nslu2.php
Jul 19 23:11:55 <jbowler-zzz> yes, I've seen it - I realised what the context is.
Jul 19 23:12:15 <Jacmet> it's on Linuxdevices now btw - might be nice with a bit of publicity for nslu2-linux: http://peter.korsgaard.com/articles/debian-nslu2.php
Jul 19 23:12:23 <Jacmet> argh, http://linuxdevices.com/news/NS6152296875.html
**** ENDING LOGGING AT Tue Jul 19 23:59:56 2005