**** BEGIN LOGGING AT Mon Jul 04 23:59:56 2005
Jul 05 00:17:15 <jbowler-away> The feed http://ipkg.nslu2-linux.org/feeds/openslug/oe seems to be specified twice in OpenSlug now, once as the uncompressed Packages, then again as the compressed Packages.gz
Jul 05 00:20:18 <jbowler-away> Looks like the ipkg-collateral package in the OE feed contains the old hack with the 'src' explicitly in /etc/ipkg.conf
Jul 05 00:22:52 <jbowler-away> The problem seems to be that the NSLU2 change to the rev of ipkg-collateral didn't get in to the monotone stuff...
Jul 05 00:23:06 <jbowler-away> So the feed as 'r3' but the monotone builds have 'r1'.
Jul 05 00:23:18 <giel> wow
Jul 05 00:23:23 <giel> i really need coffee
Jul 05 00:23:32 <giel> i misread "jbowler" as "jbot"
Jul 05 00:23:49 <giel> and i thought: wow, what a story for a bot! when did they put in such ai?
Jul 05 00:24:20 <jbowler-away> Hum.
Jul 05 00:24:23 <jbowler-away> ~debug
Jul 05 00:24:23 * jbot DeBuggers $1
Jul 05 00:24:59 <jbowler-away> ~debug bitbake revision numbers
Jul 05 00:25:14 <jbowler-away> nope, very limited functionality.
Jul 05 00:31:13 <giel> :)
Jul 05 00:31:20 <giel> don't feel offended, please :)
Jul 05 00:31:32 <jbowler-away> ~lart giel
Jul 05 00:31:32 * jbot holds giel to the floor and spanks him with a cat-o-nine-tails
Jul 05 00:32:48 <jbowler-away> I suppose it might be the ~Turing test.
Jul 05 00:34:35 <giel> ~turing
Jul 05 00:34:36 <jbot> ...but I *AM* Turing complete!!!!
Jul 05 00:34:39 <giel> heh
Jul 05 00:34:45 <giel> no, not an answer a human would give
Jul 05 00:48:29 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r53841a61... 10/packages/monotone/ (files/txt2c-cross.patch monotone_0.19.bb): Builds but has bugs in very basic functionality (db init does not work).
Jul 05 01:03:27 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * r891b586f... 10/packages/devio/ (devio-native_r2.bb devio_r2.bb): New version of devio with a progress indicator (-p option)
Jul 05 02:31:50 <CHAOSiTEC> is there any way i can tell it NOT to compile bluez stuff?
Jul 05 02:32:27 <rwhitby> cd openslug ; source setup-env ; bb <package of your choice>
Jul 05 02:33:00 <CHAOSiTEC> i want to be able to do a simple make, without getting it to compile bluez stuff
Jul 05 02:33:24 <rwhitby> openslug, unslung, or optware?
Jul 05 02:33:30 <CHAOSiTEC> openslug
Jul 05 02:33:38 <rwhitby> remove it from openslug-packages.bb
Jul 05 02:34:26 <CHAOSiTEC> ok, thanks ;-) (sems like im the only one where bluez-utils-nodbus fails on, so i might as well try everything else without that
Jul 05 02:37:01 <dyoung-zzzz> he never answered if he needed to be building all of openslug-packages.
Jul 05 02:38:33 <rwhitby> heh, you said "do you need to be making openslug-packages right now?" and I think CHAOSiTEC thought you meant "like at this time of night" as opposed to "do you really want all the openslug packages at once"
Jul 05 02:39:08 <CHAOSiTEC> thats what i though you meant, sorry my bad
Jul 05 02:43:27 <CHAOSiTEC> i am so new to oe that the color green means experience to me lol
Jul 05 02:44:14 <dyoung-zzzz> Hmm, could be eh.
Jul 05 02:44:21 <dyoung-zzzz> ah well.
Jul 05 02:45:03 <dyoung-zzzz> if you just want to make the firmare image, you can bb openslug-image.
Jul 05 02:45:34 <CHAOSiTEC> ok, thanks ;-)
Jul 05 03:14:37 <rwhitby> jp30: transcode optware is not building for me on nudi - seems to require Xvlib.h
Jul 05 04:08:05 <CHAOSiTEC> woa - though turboslug was the number of my own one, someone with access to the turboslug database, please either change it (im terrible sorry) or remove it
Jul 05 08:32:53 <VoodooZ_work> wow. sure is quiet in here! can somebody say something so I can test out my IRC proxy?
Jul 05 08:33:09 <CHAOSiTEC> no i refuse to say anything ;-)
Jul 05 08:33:15 <Tiersten>    
Jul 05 08:33:17 <Tiersten>       
Jul 05 08:33:20 <Tiersten>   
Jul 05 08:33:32 <giel> rha!
Jul 05 08:33:47 <giel> why is bin/bbread missing from a fresh bitbake checkout?
Jul 05 08:33:57 <VoodooZ_work> heheheh. 
Jul 05 08:33:58 <VoodooZ_work> thanks.
Jul 05 08:51:26 * VoodooZ_work kneels before kergoth
Jul 05 08:51:33 <VoodooZ_work> kergoth, How's the man
Jul 05 08:51:52 <kergoth> bleh
Jul 05 08:51:56 <kergoth> got wayyy too much sleep
Jul 05 08:51:57 * kergoth yawns
Jul 05 08:52:11 <VoodooZ_work> well, normally you didn
Jul 05 08:52:18 <VoodooZ_work> didn't get enough.
Jul 05 08:52:43 <VoodooZ_work> I got less than usual last night because the stupid thunderstorm woke me up
Jul 05 08:52:51 <kergoth> ahh
Jul 05 08:53:07 <VoodooZ_work> What have you been up to?
Jul 05 08:53:18 <VoodooZ_work> You kind of vanished there for a while
Jul 05 08:53:35 <kergoth> very, very little.  back in mn at my townhouse with my dad.  unemployed, not feeling all that well.  being broke isnt good fro morale ;)
Jul 05 08:54:13 <VoodooZ_work> yeah, been there. Spent a whole year doing nothing.
Jul 05 08:54:21 <kergoth> :\
Jul 05 08:54:50 <VoodooZ_work> I thought It would be a blast being unemployed but it wasn't. everything cost money so it's no fun.
Jul 05 08:55:11 <kergoth> yeah, indeed
Jul 05 08:55:22 <VoodooZ_work> I didn't ride my bike that much either as the stupid gaz was costing me $$$.
Jul 05 08:56:29 <VoodooZ_work> are the OE guys switching to monotone too?
Jul 05 08:57:50 <kergoth> already has, apparently
Jul 05 08:57:54 * kergoth 's been pretty out of the loop
Jul 05 08:58:10 * VoodooZ_work too.
Jul 05 09:03:50 <kitno455> re all
Jul 05 09:05:40 <kitno455> ping DaKa2
Jul 05 09:07:54 <DaKa2> pong
Jul 05 09:08:09 <DaKa2> kitno455?
Jul 05 09:08:48 <kitno455> right
Jul 05 09:09:01 <kitno455> you say you dont have scanner/slug now?
Jul 05 09:09:27 <DaKa2> well, remote access, with kinda working things yes
Jul 05 09:09:38 <kitno455> right. this is allan btw
Jul 05 09:09:45 <DaKa2> ahh, hi :-)
Jul 05 09:09:49 <kitno455> you get my last mail>
Jul 05 09:09:55 <DaKa2> just read it
Jul 05 09:10:06 <kitno455> right, looking at backend myself now....
Jul 05 09:10:34 <DaKa2> and started looking.. the plustek backend is big..
Jul 05 09:10:40 <kitno455> yes
Jul 05 09:10:45 <DaKa2> 95% is calibration :-)
Jul 05 09:10:46 <kitno455> pp and usb versions
Jul 05 09:10:49 <kitno455> yeap.
Jul 05 09:10:58 <kitno455> cheap scanners require lots of calibration help
Jul 05 09:11:29 <DaKa2> currently looking at plustek-usbscan.c
Jul 05 09:11:42 <kitno455> plustek.c
Jul 05 09:11:50 <kitno455> line 2317
Jul 05 09:12:19 <DaKa2> lol... vi gets segmentationfault when trying to jump there... just have to scroll I guess
Jul 05 09:12:33 <kitno455> haha
Jul 05 09:12:42 <kitno455> try line 2310
Jul 05 09:12:57 <DaKa2> nread = read( s->r_pipe, data, max_length ); ?
Jul 05 09:13:01 <kitno455> yeap
Jul 05 09:13:10 <kitno455> we need to dump that data
Jul 05 09:13:28 <kitno455> and see if it looks 24 bit or 32
Jul 05 09:13:55 <DaKa2> thats is easy, the fourth bit it always 0
Jul 05 09:13:59 <DaKa2> if its wrong
Jul 05 09:14:09 <kitno455> byte you mean
Jul 05 09:14:17 <DaKa2> argh, yes, byte
Jul 05 09:14:21 <kitno455> yes
Jul 05 09:14:36 <kitno455> looking for hexdump implementation....
Jul 05 09:14:57 <kitno455> hmm. not one in plustek.c
Jul 05 09:15:20 <kitno455> ok, code copy time
Jul 05 09:16:02 <DaKa2> ok
Jul 05 09:16:03 <kitno455> backend/fujitsu.c
Jul 05 09:16:10 <kitno455> line 3234
Jul 05 09:16:38 <kitno455> copy that function into plustek.c
Jul 05 09:16:46 <kitno455> just above where we are now.
Jul 05 09:17:14 <DaKa2> done
Jul 05 09:17:39 <kitno455> now, we need to call that function, after the read()
Jul 05 09:17:46 <kitno455> send it the data buffer
Jul 05 09:18:17 <kitno455> DBG macro is defined, so it should work :)
Jul 05 09:19:20 <kitno455> something like:
Jul 05 09:20:11 <kitno455> hexdump(0,'foo',data,nread);
Jul 05 09:20:51 <kitno455> then rebuild, reinstall, and scan something SMALL
Jul 05 09:21:14 <DaKa2> ok.
Jul 05 09:21:23 <DaKa2> build takes about 2 mins
Jul 05 09:21:40 <kitno455> if every 4th byte is 0, then we know to move backwards
Jul 05 09:21:59 <kitno455> figure out where s->r_pipe comes from
Jul 05 09:22:17 <kitno455> bbiab
Jul 05 09:22:29 <DaKa2> ok, thanks :-)
Jul 05 09:24:20 <kitno455> ok. how are you scanning, scanimage?
Jul 05 09:24:42 <DaKa2> scanimage -x50 -y50 > file.pnm
Jul 05 09:24:47 <kitno455> cool.
Jul 05 09:25:20 <DaKa2> oh my.. vi crashing messed up my terminal.. alot
Jul 05 09:25:24 <kitno455> hah
Jul 05 09:25:36 <kitno455> try control v followed by esc c
Jul 05 09:25:49 <kitno455> then enter
Jul 05 09:25:51 <DaKa2> or just reconnect
Jul 05 09:25:54 <DaKa2> :)
Jul 05 09:26:04 <kitno455> reboots are for hardware upgrades
Jul 05 09:26:07 <kitno455> :)
Jul 05 09:26:08 <DaKa2> but Ill remember that one
Jul 05 09:26:31 <kitno455> does not always work on linux
Jul 05 09:27:02 <DaKa2> [plustek] Segmentation fault
Jul 05 09:27:04 <DaKa2> hm...
Jul 05 09:27:57 <kitno455> hmm
Jul 05 09:28:37 <DaKa2> im just running with SANE_DEBUG_PLUSTEK=255, but I guess something was wrong with the call to hexdump
Jul 05 09:28:47 <kitno455> yeah
Jul 05 09:29:14 <kitno455> well, be lazy
Jul 05 09:29:26 <DaKa2> "plustek.c:2345: warning: passing arg 2 of `hexdump' makes pointer from integer without a cast"
Jul 05 09:30:07 <kitno455> odd, arg2 is a string....
Jul 05 09:30:18 <kitno455> shit
Jul 05 09:30:22 <kitno455> double quotes
Jul 05 09:30:27 <kitno455> around the foo
Jul 05 09:30:33 <DaKa2> ahh, hehe
Jul 05 09:30:36 <kitno455> duh
Jul 05 09:30:45 <DaKa2> I should have spotted that
Jul 05 09:30:52 <DaKa2> too used to php..
Jul 05 09:30:54 <kitno455> arg
Jul 05 09:30:59 <kitno455> i gave up on php
Jul 05 09:31:20 <kitno455> wrote a good bit of twig first, heard of it?
Jul 05 09:31:35 <DaKa2> hm.. no
Jul 05 09:31:46 <kitno455> web-based groupware/email client
Jul 05 09:31:59 <kitno455> pretty big following in 1999 :)
Jul 05 09:32:04 <DaKa2> just found it
Jul 05 09:32:15 <kitno455> the 'oldest groupware client in php'
Jul 05 09:33:23 <DaKa2> oh my, the demo is in french
Jul 05 09:33:29 <kitno455> you can change it
Jul 05 09:33:43 <kitno455> something like 20 languages
Jul 05 09:34:19 <DaKa2> ahh, theere, just a bit hard to find where, I havent read french in 8 years
Jul 05 09:35:02 <DaKa2> scanning again..
Jul 05 09:35:16 <kitno455> it was shipped with a couple of the smaller linux distros at one point, including turbo linux
Jul 05 09:35:21 <kitno455> ok
Jul 05 09:35:28 <kitno455> whats on stderr?
Jul 05 09:35:46 <DaKa2> apt-cache search twig
Jul 05 09:35:47 <DaKa2> twig - The Web Information Gateway
Jul 05 09:35:57 <kitno455> right
Jul 05 09:36:08 <kitno455> everything is in debian, it dont count :)
Jul 05 09:36:33 <DaKa2> [plustek] 000: ff ff 4c 00 00 ff a4 00 7e ff a4 00 ff d5 ff 00
Jul 05 09:36:58 <DaKa2> long lines of 00 :-(
Jul 05 09:37:19 <kitno455> there does seem to be a pattern?
Jul 05 09:37:44 <DaKa2> yup, every fourth is 00
Jul 05 09:37:48 <kitno455> ok
Jul 05 09:38:41 <DaKa2> s->r_pipe comes from the other thread?
Jul 05 09:38:56 <DaKa2> created in sane_start?
Jul 05 09:39:12 <kitno455> perhaps before
Jul 05 09:39:18 <kitno455> look for fopen()
Jul 05 09:40:03 <DaKa2> isn't that handled in the sanei part?
Jul 05 09:40:26 <kitno455> the naming of it as r_pipe is plustek
Jul 05 09:40:28 <kitno455> i think
Jul 05 09:41:04 <DaKa2> sanei_lm983x.c is part of plustek 
Jul 05 09:41:18 <kitno455> yeah. boy this thing is big
Jul 05 09:41:42 <DaKa2> but that part was atleast small
Jul 05 09:42:37 <kitno455> do you see where it forks reader?
Jul 05 09:43:04 <DaKa2> s->reader_pid = sanei_thread_begin( reader_process, s ); ?
Jul 05 09:43:28 <kitno455> right
Jul 05 09:43:32 <kitno455> 2276
Jul 05 09:43:53 <DaKa2> right..
Jul 05 09:44:09 <kitno455> so the hunt begins
Jul 05 09:44:51 <kitno455> multiple versions, pthreads, etc
Jul 05 09:44:59 <DaKa2> I understand, well.. not much of this, but a bit more all the time
Jul 05 09:45:13 <kitno455> me either :)
Jul 05 09:45:52 <kitno455> sanei_thread.c line 286
Jul 05 09:46:57 <DaKa2> hm.. wonder if I compiled with or without pthreads
Jul 05 09:46:59 <kitno455> ok, so its running func(args)
Jul 05 09:47:02 <kitno455> likely not
Jul 05 09:47:36 <kitno455> you got config.h?
Jul 05 09:47:53 <DaKa2> ahh, there
Jul 05 09:48:13 <DaKa2>  /* #undef HAVE_LIBPTHREAD */
Jul 05 09:48:33 <DaKa2> actually: /* #undef USE_PTHREAD */
Jul 05 09:48:34 <DaKa2> so, no
Jul 05 09:48:39 <kitno455> ok
Jul 05 09:48:51 <kitno455> do you see how sanei_thre... works?
Jul 05 09:49:43 <DaKa2> actually, no
Jul 05 09:49:44 <DaKa2> or..
Jul 05 09:50:06 <kitno455> if pid is 0, run the named function with the given args
Jul 05 09:50:33 <DaKa2> ah..
Jul 05 09:50:41 <kitno455> so the caller said what?
Jul 05 09:51:12 <kitno455>  sanei_thread_begin( reader_process, s )
Jul 05 09:51:28 <kitno455> so back in plustek.c :)
Jul 05 09:51:55 <DaKa2> well.. run reader_process function as a new thread?
Jul 05 09:52:04 <kitno455> new process actually
Jul 05 09:52:14 <kitno455> line 396
Jul 05 09:52:24 <DaKa2> just found it
Jul 05 09:53:01 <kitno455> sig blah blah....
Jul 05 09:53:56 <DaKa2> usbDev_ReadLine?
Jul 05 09:54:27 <kitno455> right find it
Jul 05 09:54:46 <DaKa2> line 455, where do the data end up?
Jul 05 09:54:59 <DaKa2> in scanner->buf?
Jul 05 09:55:10 <kitno455> nope, thats not an arg....
Jul 05 09:56:09 <DaKa2> in buf?
Jul 05 09:56:28 <kitno455> what does status = usbDev_Prepare( scanner->hw, buf ); do?
Jul 05 09:57:13 <kitno455> if hw has a member that the buf ptr gets stored in, there's your answer.
Jul 05 09:58:40 <DaKa2> plustek-usb.c line 983
Jul 05 09:58:50 <DaKa2> thats usbDev_Prepare
Jul 05 09:58:59 <kitno455> calibration
Jul 05 09:59:42 <DaKa2> first part, I think
Jul 05 10:00:27 <kitno455> yeap
Jul 05 10:00:29 <kitno455> found it
Jul 05 10:00:53 <kitno455> *dev is arg to function
Jul 05 10:00:56 <kitno455> pScanDef  scanning    = &dev->scanning;
Jul 05 10:01:08 <kitno455> scanning->UserBuf.pb = buf
Jul 05 10:01:43 <kitno455> so this function crams a ptr to the buffer into dev->scanning->UserBuf.pb
Jul 05 10:01:51 <kitno455> so we go back
Jul 05 10:02:09 <kitno455> status = usbDev_ReadLine( scanner->hw );
Jul 05 10:02:35 <kitno455> must read, then cram results into scanner->scanning->UserBuf.pb
Jul 05 10:02:48 <kitno455> go forward :)
Jul 05 10:03:22 <DaKa2> hm.
Jul 05 10:03:24 <kitno455>  plustek-usb.c line 1286
Jul 05 10:04:15 <DaKa2> moving forward in the buffer?
Jul 05 10:04:22 <kitno455> keep reading
Jul 05 10:04:37 <kitno455> line 1307
Jul 05 10:05:19 <kitno455> three pointers, moving them forward
Jul 05 10:05:24 <kitno455> one per channel
Jul 05 10:06:05 <DaKa2> rgb.. it has to assemble them somewhere
Jul 05 10:06:19 <DaKa2> or is that in a struct somewhere
Jul 05 10:06:25 <kitno455> i guess this means that plustek units send scan data one color at a time
Jul 05 10:06:42 <kitno455> the shifts make up for that
Jul 05 10:07:23 <DaKa2> well, the cannon lide20 uses leds for lighting, and rotates the colors between r b and g
Jul 05 10:08:21 <kitno455> usb_ReadData
Jul 05 10:09:15 <DaKa2> plustek-usbimg.c
Jul 05 10:09:21 <kitno455> yeap
Jul 05 10:11:04 <kitno455> dumpPic
Jul 05 10:11:18 <DaKa2> nice, we get a file
Jul 05 10:11:38 <kitno455> where is it
Jul 05 10:11:44 <kitno455> usbio
Jul 05 10:11:57 <kitno455> vi backend/plustek-usbio.c
Jul 05 10:12:15 <DaKa2> yup..
Jul 05 10:12:34 <kitno455> if( DBG_LEVEL < _DBG_DPIC )
Jul 05 10:12:34 <kitno455>                 return;
Jul 05 10:13:11 <kitno455> backend/plustek.c:#define _DBG_DPIC      25
Jul 05 10:13:28 <DaKa2> Im running at 255..
Jul 05 10:13:37 <kitno455> so do you see the file now?
Jul 05 10:13:49 <DaKa2> no...
Jul 05 10:14:14 <kitno455> if( NULL == buffer ) {
Jul 05 10:14:14 <kitno455>                                                                                                                       
Jul 05 10:14:14 <kitno455>                 DBG( _DBG_DPIC, "Creating file '%s'\n", name );
Jul 05 10:14:21 <kitno455> that makes no sense.
Jul 05 10:15:14 <kitno455> weird.
Jul 05 10:15:41 <kitno455> makes a pnm if you send no data
Jul 05 10:15:58 <kitno455> do you see:
Jul 05 10:16:07 <kitno455> Can not open file
Jul 05 10:16:15 <kitno455> in your debug output?
Jul 05 10:16:48 <DaKa2> hm.. lets see
Jul 05 10:17:18 <kitno455> does not matter really
Jul 05 10:17:40 <kitno455> just use hexdump in the place it calls dumpPic
Jul 05 10:18:00 <DaKa2> now I got the files
Jul 05 10:18:05 <kitno455> ok
Jul 05 10:18:12 <kitno455> hexedit
Jul 05 10:18:14 <DaKa2> must have run it in some other directory before
Jul 05 10:18:18 <kitno455>  right
Jul 05 10:18:52 <kitno455> i wonder if users know that turning up the debug level will do that. symlink attack...
Jul 05 10:19:18 <DaKa2> haha, maybe should tell someone
Jul 05 10:19:41 <kitno455> only if you run this while sitting in /tmp is it a problem.
Jul 05 10:19:47 <kitno455> and you are root :)
Jul 05 10:20:10 <DaKa2> but still!
Jul 05 10:20:13 <DaKa2> big bug!
Jul 05 10:20:15 <DaKa2> 0000000 ff00 f4ff 576f 5d00 2669 00ff 00ff ffff
Jul 05 10:20:15 <DaKa2> 0000010 00ff 0000 f84a ceff ff39 00d9 b135 0031
Jul 05 10:20:15 <DaKa2> 0000020 ffff a9b0 ff4c a6c8 14ff ffd9 ea00 e5cf
Jul 05 10:20:28 <DaKa2> thats the data, without header
Jul 05 10:21:00 <DaKa2> cannot see any pattern of 00
Jul 05 10:22:22 <kitno455> how does that compare
Jul 05 10:22:28 <kitno455> to the hexdump from before?
Jul 05 10:22:54 <DaKa2> I just have to transfer the file across a couple of firewalls
Jul 05 10:23:09 <kitno455> ff ff 4c 00 00 ff a4 00 7e ff a4 00 ff d5 ff 00
Jul 05 10:23:27 <kitno455> should be rgbxrgbx
Jul 05 10:23:51 <kitno455> the data in thos files might be RRRRRGGGGGBBBBB or GGGGGBBBBBRRRR
Jul 05 10:24:13 <kitno455> this is why doing a solid color scan makes it more obvious
Jul 05 10:24:13 <DaKa2> hm, damn..
Jul 05 10:24:27 <DaKa2> too bad I cant change whats in the scanner
Jul 05 10:24:39 <kitno455> got any co-workers there :)
Jul 05 10:24:52 <DaKa2> not at 19:24
Jul 05 10:25:07 <kitno455> hmm. lunch time here
Jul 05 10:25:11 <kitno455> need food
Jul 05 10:25:14 <DaKa2> I might actually go there tomorrow
Jul 05 10:25:48 <DaKa2> SANE_DEBUG_PLUSTEK=255 scanimage -x50 -y50 > file.pnm 2> debug
Jul 05 10:26:14 <DaKa2> http://david.thg.se/saker/libusb/sane/file.pnm http://david.thg.se/saker/libusb/sane/debug http://david.thg.se/saker/libusb/sane/http://david.thg.se/saker/libusb/sane/plustek-pic.raw
Jul 05 10:26:19 <kitno455> ahahah
Jul 05 10:26:31 <DaKa2> oops...
Jul 05 10:26:42 <DaKa2> http://david.thg.se/saker/libusb/sane/file.pnm http://david.thg.se/saker/libusb/sane/debug http://david.thg.se/saker/libusb/sane/plustek-pic.raw
Jul 05 10:26:44 <kitno455> the piece of code to tear apart is the one that converts from the RRRRGGGGBBBB to rgbrgbrgb
Jul 05 10:27:12 <kitno455> lets see if we can guess...
Jul 05 10:33:03 <DaKa2> there seems to be about 100 Red, then 100 Grean
Jul 05 10:33:19 <kitno455> what dpi is this?
Jul 05 10:33:27 <DaKa2> or.. 98 actually
Jul 05 10:33:29 <DaKa2> 50 dpi
Jul 05 10:33:40 <DaKa2> the lines are 98 pixels long
Jul 05 10:33:50 <DaKa2> so, first a line in R, then G then B
Jul 05 10:33:58 <kitno455> seems normal.
Jul 05 10:34:11 <kitno455> so compare the lines
Jul 05 10:34:16 <DaKa2> lest see what comes later
Jul 05 10:35:15 <DaKa2> well.. 98R, 98G, 98B, 98R, 98G, 98B, no x
Jul 05 10:35:24 <kitno455> right
Jul 05 10:35:39 <kitno455> looks like jbowler gets the cigar :)
Jul 05 10:36:07 <kitno455> arg
Jul 05 10:36:13 <DaKa2> :)
Jul 05 10:36:20 <kitno455> plustek-usb.h
Jul 05 10:36:42 <kitno455> line 113
Jul 05 10:37:41 <kitno455> i bet we've got an array of those somewhere....
Jul 05 10:42:01 <kitno455> gotta run.
Jul 05 10:42:14 <DaKa2> ok
Jul 05 10:42:25 <DaKa2> thanks so far :-)Ill keep looking
Jul 05 10:42:31 <kitno455> look at the code that plays with pb_rgb
Jul 05 10:42:49 <kitno455> scan->UserBuf.pb_rgb[dwPixels]
Jul 05 10:43:20 <kitno455> that code likely works, but at some point after that, something writes that out.
Jul 05 10:43:44 <kitno455> or treats it as a contiguous block of chars
Jul 05 10:43:47 <kitno455> in fact.....
Jul 05 10:45:25 <kitno455> 4 functions in plustek-usbimg.c do that
Jul 05 10:45:50 <DaKa2> "/** do a simple memcopy from scan-buffer to user buffer"
Jul 05 10:45:58 <kitno455> where?
Jul 05 10:46:10 <kitno455> right
Jul 05 10:46:19 <kitno455> your scanner will use one of these 4
Jul 05 10:46:22 <kitno455> not all of them
Jul 05 10:46:38 <kitno455> cause the backend supports a variety of scanners
Jul 05 10:46:52 <kitno455> figure out which one with DBG
Jul 05 10:47:23 <DaKa2> its probably the CIS, but Ill check
Jul 05 10:48:40 <DaKa2> ImageProc is: ColorDuplicate8_2
Jul 05 10:48:58 <kitno455> after the for() loop the copies the bytes, try to dump scan->UserBuf.pb_rgb
Jul 05 10:49:18 <kitno455> might have to copy hexdump to this file
Jul 05 10:49:31 <DaKa2> I could try dumpPic
Jul 05 10:49:35 <kitno455> right
Jul 05 10:49:39 <kitno455> new name, thugh
Jul 05 10:49:43 <kitno455> though
Jul 05 10:49:52 <DaKa2> yup
Jul 05 10:50:20 <kitno455> i am going to heat my lunch, its 14:00 here... i will be back in 10
Jul 05 10:50:30 <DaKa2> :)
Jul 05 10:50:36 <DaKa2> late lunch
Jul 05 10:51:01 <DaKa2> might get something to eat myself
Jul 05 10:53:04 <kitno455> lasagna
Jul 05 10:53:58 <DaKa2> I ate my lunch around 14:00-14:30 too, might be time for something more
Jul 05 10:54:37 <kitno455> i have real work to do, but i prefer this. besides, yesterday was a holiday, and i worked.
Jul 05 10:54:50 <DaKa2> :)
Jul 05 10:55:05 <DaKa2> what was yesterday?
Jul 05 10:55:08 <kitno455> so now the company owes me, right :)
Jul 05 10:55:52 <DaKa2> yup, thats what I think too, I usually stay atleast 2 hours after work to get some actuall work done, when noone bugs me with stuff all the time
Jul 05 10:56:00 <CHAOSiTEC-away> DaKa2 it was the 4th of july yesterday (american holiday)
Jul 05 10:56:11 <DaKa2> ahh, lol.. missed that totaly
Jul 05 10:56:46 <kitno455> i dont know as much about this as jbowler does, but i think something is amiss with the array of 3byte wide structs
Jul 05 10:57:15 <kitno455> that would explain perhaps why gray seems to work
Jul 05 10:57:30 <kitno455> its probably an array of 1 byte structs then.
Jul 05 10:57:37 <DaKa2> hm.. sounds likly
Jul 05 10:57:53 <kitno455> dump scan->UserBuf.pb_rgb
Jul 05 10:57:58 <kitno455> and we should know
Jul 05 10:58:00 <DaKa2> because the dump of scan->UserBuf.pb_rg is bad
Jul 05 10:58:06 <DaKa2> 0000000 ff4e ff00 00d3 ff00 00ff f200 5e00 ff00
Jul 05 10:58:06 <DaKa2> 0000010 ff6f b900 ff36 7700 ffe8 ff00 ffff ff00
Jul 05 10:58:06 <DaKa2> 0000020 62ff ff00 0049 ff00 ff8a ff00 ffbd ff00
Jul 05 10:58:14 <kitno455> right
Jul 05 10:58:14 <DaKa2> nice rows of 00
Jul 05 10:58:23 <kitno455> perfect
Jul 05 10:58:36 <kitno455> i think jbowler and i get to split the cigar
Jul 05 10:58:45 <DaKa2> :)
Jul 05 10:58:55 <CHAOSiTEC> lol, small wager going on?
Jul 05 10:59:09 <kitno455> he does not know it, but yes :)
Jul 05 10:59:14 <CHAOSiTEC> lol
Jul 05 10:59:30 <kitno455> we had differing opinions as to the cause
Jul 05 10:59:54 <CHAOSiTEC> but it seems you both where right more or less then?
Jul 05 11:00:02 <kitno455> he has far more knowlege, i have more chutzpah
Jul 05 11:00:09 <CHAOSiTEC> rofl
Jul 05 11:00:28 <DaKa2> $ dict chutzpah
Jul 05 11:00:31 <DaKa2> ahh...
Jul 05 11:00:37 <kitno455> well, i said alignment in libusb, he said, not alignment, plustek
Jul 05 11:00:46 <kitno455> turns out to be alignment in plustek :)
Jul 05 11:00:55 <CHAOSiTEC> lol
Jul 05 11:01:52 <kitno455> DaKa2, can you find the place it actually writes the buffer out?
Jul 05 11:01:53 <DaKa2> just the problem of what to do to fix it
Jul 05 11:02:55 <kitno455> here you run into my inexperience. you could scrap the idea of the 3byte struct, or you could run a bit of code at the very last
Jul 05 11:03:08 <kitno455> which only copies three bytes at a time out.
Jul 05 11:03:31 <kitno455> thats a hack, but its easier.
Jul 05 11:04:06 <DaKa2> thats what I was thinking, rewriting the whole thing is.. well.. not good
Jul 05 11:04:17 <CHAOSiTEC> i allways start out with a hack, if it works, then i can make it pretier...lol
Jul 05 11:04:56 <jbowler-away> sizeof struct { char r, g, b; } == 4
Jul 05 11:05:04 <kitno455> thanks john
Jul 05 11:05:31 <kitno455> i did not know you could call sizeof on the proto type.
Jul 05 11:05:45 <jbowler-away> Due to the half-implemented GCC packed attribute on ARM it's pretty much impossible to fix in a declaration.
Jul 05 11:05:53 <kitno455> you want half a cigar?
Jul 05 11:05:54 <kitno455> :)
Jul 05 11:05:56 <jbowler-away> ... you need some brackets ...
Jul 05 11:06:56 <jbowler-away> Hum... in fact I think I managed to get it right for reiserfs (Reiser4 has the same abberant thing, big time.)
Jul 05 11:06:59 <kitno455> so do we just do a cheesy loop at the last, and copy three bytes out
Jul 05 11:07:22 <kitno455> and hans wonders why he gets so much flack from the kernel devels....
Jul 05 11:07:28 <DaKa2> damn.. there are atleast 20 different something_Duplicate_something
Jul 05 11:07:34 <kitno455> hahahah
Jul 05 11:07:43 <kitno455> welcome to sane
Jul 05 11:07:56 <CHAOSiTEC> (in)sane
Jul 05 11:07:58 <kitno455> each backend supports dozens of scanners
Jul 05 11:08:02 <jbowler-away> You only care about the cases where a 3 byte struct is used to describe the output.
Jul 05 11:08:05 <kitno455> no- insane is another product
Jul 05 11:08:19 <CHAOSiTEC> thats why i did the () lo
Jul 05 11:08:25 <kitno455> i think now, it just does a memcpy
Jul 05 11:08:33 <kitno455> of the whole array of structs
Jul 05 11:08:59 <kitno455> so instead we need to copy each member, or perhaps first 3 bytes
Jul 05 11:09:02 <jbowler-away> That's fine - in this case the problem arises with ++ptr
Jul 05 11:09:25 <jbowler-away> I.e. struct {char r,g,b;} *ptr; ++ptr; gives the wrong answer.
Jul 05 11:09:37 <kitno455> really?
Jul 05 11:09:53 <jbowler-away> It's truely horrible but ptr = ((char*)ptr)+3; works.
Jul 05 11:09:53 <kitno455> it does not know that the struct is 4 bytes?
Jul 05 11:10:33 <jbowler-away> That's the point - the struct is four bytes, but what I understand is that the userbuf is supposed to be 3 bytes per pixel.
Jul 05 11:10:43 <kitno455> right
Jul 05 11:10:45 <DaKa2> but where does it write the data? I really can't find it
Jul 05 11:10:49 <kitno455> hahahah
Jul 05 11:10:51 <jbowler-away> (Is the code checked in to OE, or optware?)
Jul 05 11:11:04 <DaKa2> think it is in optware
Jul 05 11:11:08 <DaKa2> sane-backends
Jul 05 11:11:57 <kitno455> so if the code makes an array of these structs, it sets aside 4 bytes per. as long as we mess with those bytes via the struct
Jul 05 11:12:00 <kitno455> it is ok
Jul 05 11:12:49 <kitno455> but when we mess with the array as if it was an array of chars, then we get all 4 bytes copied?
Jul 05 11:13:40 <jbowler-away> Problems can only arise if something manipulated as a struct is access as an array of char - then the result depends on what the compiler does with that struct.
Jul 05 11:14:07 <kitno455> thats exactly what this code does, afaik
Jul 05 11:14:25 <jbowler-away> On many compilers (include the original ARM one) struct {char a,b,c} is three bytes with an alignment requirement of 1.
Jul 05 11:14:31 <jbowler-away> ARM gcc never got this right ;-)
Jul 05 11:14:40 <kitno455> what does the alignment requirement do?
Jul 05 11:14:59 <jbowler-away> alignment required <n> means that address mod <n> must be 0.
Jul 05 11:15:26 <kitno455> the adress of which, the start of the struct?
Jul 05 11:15:48 <jbowler-away> The address of the object with the alignment requirement.
Jul 05 11:16:01 <kitno455> right
Jul 05 11:16:38 <jbowler-away> So alignof(char) == 1,and the struct alignment requirement should be no greater, but the compiler is free to make it so (and it does)
Jul 05 11:16:57 <kitno455> doesnt everything align(1)?
Jul 05 11:17:23 <kitno455> ah, so it can bump it up to 2?
Jul 05 11:17:48 <jbowler-away> No, you can't load a quantity >1 byte in size in one load on anything unless it is aligned appropriately.
Jul 05 11:18:17 <jbowler-away> Because the memory bus can only deliever aligned quantities...
Jul 05 11:18:20 <kitno455> ok, gotcha
Jul 05 11:18:46 <kitno455> so x86 pulls too much data and fixes it up?
Jul 05 11:19:00 <jbowler-away> (Hum, that's not quite true - 2 byte loads on a 4 byte bus are possible with alignment offset of 0,1 or 2 - but not 3).
Jul 05 11:19:17 <jbowler-away> x86 does multiple reads when required - but it's slowerly on the later CPUs
Jul 05 11:19:18 <kitno455> cause it wraps
Jul 05 11:19:49 <jbowler-away> Indeed I thought intel had put in alignment trapping on the later CPUs...
Jul 05 11:19:56 <kitno455> right, i just know i never have to worry about this on x86
Jul 05 11:20:25 <kitno455> is there much speed improvement on x86 if you align your structs yourself?
Jul 05 11:22:30 <jbowler-away> Most of the time they are aligned anyway - if you look in libusb for example and count the uint_8 and uint_16 you will see that the uint_16's are alwasy on an even offset.
Jul 05 11:22:49 <kitno455> only because of programmer effort, though
Jul 05 11:23:03 <jbowler-away> That's cause it's easy to get it right - the 100% correct algorithm is to order the struct members by (reverse) size.
Jul 05 11:23:32 <jbowler-away> Which ColorDuplicate is getting called?  (I'm looking at plustek-usbimg.c)
Jul 05 11:23:52 <kitno455> i think DaKa2 said 8_2
Jul 05 11:23:59 <DaKa2> yup
Jul 05 11:24:33 <jbowler-away> Hum, the problem must be in pScanDef
Jul 05 11:25:08 <kitno455> yea
Jul 05 11:25:11 <kitno455> union
Jul 05 11:25:58 <DaKa2> plustek-usb.h, line 554?
Jul 05 11:26:28 <kitno455> UserPtr points to a union
Jul 05 11:26:35 <jbowler-away> AnyPtr, line 643, is, I think, highly dangerous.
Jul 05 11:26:47 <kitno455> point 1 for me :)
Jul 05 11:27:30 <jbowler-away> I'm surprised it doesn't overwrite memory...
Jul 05 11:28:23 <kitno455> i am scared of unions
Jul 05 11:30:01 <kitno455> UserBuf is actually loaded from a char[], then treated as struct {char a,b,c}, then memcpy(char[])
Jul 05 11:30:16 <jbowler-away> I believe hacks as in openembedded/packages/linux/nslu2-kernel/2.6.11-mm/reiser4.patch around line 617 will fix it.
Jul 05 11:30:39 <jbowler-away> I.e.:
Jul 05 11:30:41 <jbowler-away> #define PACKED8  __attribute__ ((packed,aligned(1)))
Jul 05 11:31:02 <DaKa2> line 617? the entire file is 617 lines..
Jul 05 11:31:17 <kitno455> john, you did that earlier
Jul 05 11:31:26 <kitno455> gave a line number that was last line....
Jul 05 11:31:32 <kitno455> whats up with your editor?
Jul 05 11:31:43 <jbowler-away> Stupid vim... 365
Jul 05 11:32:03 <kitno455> excuse my ignorance, but what does that #define do?
Jul 05 11:32:09 <jbowler-away> (I'm used to vi, where ^G gives the current line number at the left...)
Jul 05 11:32:30 <kitno455> vim- its always on the right....
Jul 05 11:32:34 <DaKa2> its used later on the typedefs
Jul 05 11:32:42 <jbowler-away> The #define sets up something 'PACKED8' which, if it placed in the correct place in the typedef, makes the struct size 3, aligned 1.
Jul 05 11:33:34 <kitno455> doing what arm cc does, but arm gcc does not?
Jul 05 11:34:47 <kitno455> cool
Jul 05 11:34:50 <kitno455> gotta run
Jul 05 11:34:58 <kitno455> daka- its all yours man
Jul 05 11:35:20 <DaKa2> dammit.. you mean I have to figure this out myself? :-)
Jul 05 11:35:34 <DaKa2> thank you :-)
Jul 05 11:36:50 <kitno455> hahah, i got you part way there- i got jbowler to wake up :) now you just have to send him treets till it works :)
Jul 05 11:37:18 <DaKa2> lol
Jul 05 11:37:25 <DaKa2> ok.. Ill see
Jul 05 11:37:39 <DaKa2> just have to figure out this plustek-usb.h
Jul 05 11:38:10 <jbowler-away> DaKa2: try this: http://pastebin.com/307928
Jul 05 11:38:51 <jbowler-away> I don't know how to get the optware stuff to recompile something - repeating the make doesn't work - so I don't know if that even compiles.
Jul 05 11:39:08 <kitno455> pastebin, thats neat.
Jul 05 11:40:46 <DaKa2> jbowler-away: ok, rebuilding with that patch
Jul 05 11:44:50 <DaKa2> scanning....
Jul 05 11:45:40 <DaKa2> reading the raw data looks good..
Jul 05 11:46:42 <DaKa2> WOHO!!!!
Jul 05 11:46:50 <DaKa2> IT WORKS!
Jul 05 11:46:58 <jbowler-away> If it doesn't crash it's probably either correct, or unchanged...
Jul 05 11:48:03 <DaKa2> just need to check some bigger scans
Jul 05 11:48:16 <jbowler-away> I suspect that is the only instance of the problem, though there may be other instances in the other backends.
Jul 05 11:48:53 <DaKa2> probably, most people are on x86, I never thought of this problem until now
Jul 05 11:50:20 <DaKa2> but if a couple of 300dpi scans work, that means that openslug works with atleast one scanner model, the cheepest scanners that exists
Jul 05 11:50:48 <DaKa2> witch is a good thing, a cheep scannerserver with saned is a perfect use for the nslu2
Jul 05 11:51:14 <jbowler-away> time for me to get lunch now, bbl
Jul 05 11:51:23 <DaKa2> ok, thank you!
Jul 05 11:53:54 <DaKa2> woho! everything works
Jul 05 11:54:03 <CHAOSiTEC> great!!
Jul 05 11:54:20 <CHAOSiTEC> just shows that jbowler knows his C-fu ;-)
Jul 05 11:54:56 <DaKa2> only thing left is makeing a package for openslug, better start checking out some .bb-files
Jul 05 11:55:01 <DaKa2> :)
Jul 05 11:55:07 <CHAOSiTEC> ;-)
Jul 05 12:14:14 <VoodooZ_work> my first monotone build make died at openslug-image package with this error:
Jul 05 12:14:18 <VoodooZ_work>  File "/local/openslug/slug/openslug/bitbake//bin/bbimage", line 23, in ?
Jul 05 12:14:18 <VoodooZ_work>     from bb import *
Jul 05 12:14:18 <VoodooZ_work> AttributeError: 'module' object has no attribute 'make'
Jul 05 12:14:21 <VoodooZ_work> ANy ideas?
Jul 05 13:44:27 <DaKa2> oh, just thought of something, since SANE works great now (atleast the plustek backend), and SANE uses basically every function in libusb, that means libusb works, i.e. really works
Jul 05 13:55:43 <beewoolie-afk> DaKa2: Are you seeing the spurrious interrupt errors anymore?
Jul 05 13:56:43 <DaKa2> beewoolie-afk: spurrious interrupt error?
Jul 05 13:57:10 <beewoolie-afk> There are some old reports about the kernel reporting that it would receive interrupts and "no body cared".
Jul 05 13:57:18 <DaKa2> cannot recall ever seeing any
Jul 05 13:57:20 <DaKa2> ahh, those
Jul 05 13:57:20 <beewoolie-afk> I'm wondering if you are seeing these.
Jul 05 13:57:47 <beewoolie-afk> IIRC, it's a 2.6 kernel thing and is not present with the 2.4 kernels.
Jul 05 13:57:49 <DaKa2> Jul  5 19:49:02 (none) user.warn kernel: irq26: nobody cared
Jul 05 13:57:58 <beewoolie-afk> Hm.. Still there.
Jul 05 13:58:16 <DaKa2> yup, my /var/log/messages is filled with them
Jul 05 13:58:49 <DaKa2> seems to be when the slug is doing hard work
Jul 05 13:59:18 <beewoolie-afk> Some sort of race in the drivers.
Jul 05 14:00:26 <beewoolie-afk> But, it also sounds like you're not having problems with USB.  which is good.
Jul 05 14:00:43 <DaKa2> things are working great
Jul 05 14:01:55 <beewoolie-afk> ...and did you de-underclock your slug yet?
Jul 05 14:02:05 <DaKa2> yup
Jul 05 14:02:09 <beewoolie-afk> Sweet.
Jul 05 14:02:10 <DaKa2> :-)
Jul 05 14:02:20 <dyoung-zzzz> DeUnderClocK = DUCK ?
Jul 05 14:02:33 <beewoolie-afk> lol
Jul 05 14:02:37 <DaKa2> BogoMIPS        : 266.24
Jul 05 14:02:38 <DaKa2> lol
Jul 05 14:03:43 <DaKa2> only usb-problem was trying to run both a harddisk and a a scanner that draws power from the port
Jul 05 14:04:00 <DaKa2> nothing a powered usb-hub doesnt fix
Jul 05 14:07:17 <jacques> are the latest libusb patches committed somewhere ?
Jul 05 14:07:28 <DaKa2> in optware yes
Jul 05 14:07:38 <DaKa2> in openslug, dont think so
Jul 05 14:08:15 <DaKa2> Patch: http://david.thg.se/saker/libusb/unslung/debian-changes.patch
Jul 05 14:08:52 <jacques> does that include jbowler-away's latest additions ?
Jul 05 14:09:02 <DaKa2> those are in sane
Jul 05 14:09:06 <jacques> ah OK
Jul 05 14:09:12 <DaKa2> and that hasnt been fixed anywhere
Jul 05 14:09:37 <DaKa2> optware is still in the sf cvs?
Jul 05 14:09:59 <jacques> as far as I know
Jul 05 14:10:02 <DaKa2> should I fix SANE there?
Jul 05 14:10:26 <jacques> someone should - you might want to coordinate with the project maintainer
Jul 05 14:11:30 <DaKa2> and that is who?
Jul 05 14:13:19 <DaKa2> I got my slug about a week ago, so I havn't really got into how nslu2-linux works
Jul 05 14:13:24 <jbowler-away> VoodooZ_log: mickeyl checked in bitbake changes earlier today to re-enable some 'make' stuff.  Either your bitbake is too old or too new...
Jul 05 14:45:51 <dyoung-zzzz> SANE_BACKENDS_MAINTAINER=NSLU2 Linux <nslu2-linux@yahoogroups.com>
Jul 05 14:46:15 <dyoung-zzzz> so that means you ought to feel free to apply fixes as you see fit.
Jul 05 14:59:59 * beewoolie-afk celebrates the liberation of another oppressed slug.
Jul 05 15:00:13 <beewoolie-afk> dyoung-zzzz: howdy partner
Jul 05 15:11:05 <dyoung-zzzz> Go G Dawg.
Jul 05 15:11:12 <dyoung-zzzz> s/Go/Yo/
Jul 05 15:14:32 <beewoolie-afk> I'm updating to Openslug 2.0.  It's real nice to have a slug-UNLEASHED.
Jul 05 15:17:15 <dyoung-zzzz> 53 folk have reported performing the de-underclocking procedure.
Jul 05 15:17:35 <NAiL> And I'm #2 ;)
Jul 05 15:17:37 <beewoolie-afk> I'm probably the only one removing R64.
Jul 05 15:17:50 <NAiL> beewoolie-afk: both of us removed R64
Jul 05 15:18:01 <NAiL> I've got one R64 and one R83 removed
Jul 05 15:18:02 <dyoung-zzzz> I ran a worst case scenario torture test, enclosing the whole thing in a non-ventilated plastic box around nslu2-case size.
Jul 05 15:18:03 <beewoolie-afk> :-)  Fair enough.
Jul 05 15:18:13 <beewoolie-afk> I read the page updates.
Jul 05 15:18:17 <dyoung-zzzz> for a couple hours.
Jul 05 15:18:32 <NAiL> dyoung-zzzz: And it came out ok?
Jul 05 15:18:32 <dyoung-zzzz> in that test, it got pretty warm.
Jul 05 15:18:38 <beewoolie-afk> It looks like there's no discernible heap problem.
Jul 05 15:18:41 <beewoolie-afk> ?
Jul 05 15:18:44 <dyoung-zzzz> it stayed under 60degC.
Jul 05 15:18:53 <beewoolie-afk> That's all we can hope for.
Jul 05 15:19:10 <NAiL> Doesn't sound too bad by me
Jul 05 15:19:12 <dyoung-zzzz> so I put it in direct sunlight for a while.
Jul 05 15:19:23 <NAiL> murderer
Jul 05 15:19:27 <dyoung-zzzz> that didnt affect it greatly, Ithink it got up to 61.
Jul 05 15:19:30 <beewoolie-afk> Ack!  I thought that slugs hated sunlight?!
Jul 05 15:20:50 <dyoung-zzzz> so given that amount of torture, I think any thermal concerns are pretty moot.
Jul 05 15:24:18 <beewoolie-afk> And slugs really hate moot most of all.
Jul 05 15:29:26 <AdamBaker> Hi, anyone here any good at escaping meta characters in Makefiles? I'm trying to write a sed script to patch up .la files to work in the staging area and it is getting very messy
Jul 05 15:30:32 <eno-away> AdamBaker, $$ for $, for sed, i tend to not use / as separator
Jul 05 15:31:18 <eno-away> any specific line?
Jul 05 15:35:29 <AdamBaker> it's ok - I think I've got it now, all it needed was
Jul 05 15:35:29 <AdamBaker> QUOTED_STAGING_DIR=`echo $(STAGING_DIR) | sed -e "s/\\\//\\\\\\\\\//g"`; sed -e "s/'\/opt\/lib/'$$QUOTED_STAGING_DIR\/opt\/lib/" <$(STAGING_DIR)/opt/lib/libgpg-error.la >$(STAGING_DIR)/opt/lib/libgpg-error.la.tmp
Jul 05 15:35:55 <AdamBaker> I was missing the $$
Jul 05 15:36:34 <eno> i usually use : as sed separator, reduce line noise a bit
Jul 05 15:38:22 <AdamBaker> that would have made life easier but I'm not sure I can guarantee no-one is going to use : in the path to their build dir - some DOS addicts might have a c: directory
Jul 05 15:39:30 <eno> haha, you're considerate to DOS addicts
Jul 05 15:40:48 <AdamBaker> not always
Jul 05 15:43:07 <eno> but your point is valid, iirc, mac use : as path separator as well. Maybe we should use |
Jul 05 15:43:36 <rwhitby> I always use |
Jul 05 15:43:48 <rwhitby> prevents LTS
Jul 05 15:57:01 <CIA-8> 03daka * 10unslung/ (2 files in 2 dirs): Add patch to plustek backend from jbowler to fix ARM alignment
Jul 05 15:57:47 <DaKa2> nice
Jul 05 15:57:59 * DaKa2 likes CIA
Jul 05 16:00:34 <DaKa2> how would one go about fixing something in monotone?
Jul 05 16:04:28 <NAiL> depends on what needs fixing
Jul 05 16:05:13 <DaKa2> just libusb
Jul 05 16:05:34 <NAiL> You have a patch?
Jul 05 16:05:58 <DaKa2> yup, http://david.thg.se/saker/libusb/unslung/debian-changes.patch
Jul 05 16:06:22 <NAiL> large patch ;)
Jul 05 16:06:59 <DaKa2> it acctually fixes some things in bsd and darwin.c too, that we dont need, but why not be complete .-)
Jul 05 16:08:39 <CHAOSiTEC> ahh Hi NAiL - well, i found out that i can build almost everything, just not bluez-utils-nodbus, and ppp reason: beats me
Jul 05 16:08:58 <NAiL> Probably some distro-specific thing
Jul 05 16:09:27 <CHAOSiTEC> ill setup a build env on my labtop diff proc / distro and try from there
Jul 05 16:09:42 <NAiL> yeah, nice :)
Jul 05 16:10:28 <CHAOSiTEC> only downthing is: its an 850MHz P3 and not a superfast AMD64 3000+ lol
Jul 05 16:12:05 <rwhitby> DaKa2: what do you need to add to what?
Jul 05 16:12:12 <CHAOSiTEC> (im working on bb files for mdadm and lvm2 atm
Jul 05 16:12:40 <DaKa2> libusb, a patch, NAiL is helping right now
Jul 05 16:13:05 <rwhitby> cool.
Jul 05 16:13:10 <rwhitby> thx NAiL
Jul 05 16:13:16 <NAiL> np :)
Jul 05 16:13:39 <rwhitby> NAiL is currently our monotone repo expert :-)
Jul 05 16:13:56 <NAiL> whoa. Now that's an overstatement ;)
Jul 05 16:14:07 <CHAOSiTEC> lol, you told me you where green at it rofl
Jul 05 16:14:23 <DaKa2> :)
Jul 05 16:15:02 <NAiL> I am, sorta. Learning at an astonishing rate though ;)
Jul 05 16:15:07 <CHAOSiTEC> lol
Jul 05 16:17:18 * CHAOSiTEC thinks that "Learning at an astonishing rate" equals lots of coffe, plus trial and err....
Jul 05 16:17:51 <CHAOSiTEC> coffee even
Jul 05 16:18:04 <NAiL> I don't think coffee at all
Jul 05 16:18:25 * CHAOSiTEC thinks NAiL is hopeless ;-)
Jul 05 16:18:28 <CHAOSiTEC> lol
Jul 05 16:19:40 <CHAOSiTEC> ohh well, back to getting perl compiled natively on the slug...lol
Jul 05 16:23:30 <CIA-8> 03nail 07org.openembedded.nslu2-linux * r2ae23e98... 10/packages/libusb/ (libusb-0.1.10a/debian-changes.patch libusb_0.1.10a.bb): 
Jul 05 16:23:31 <CIA-8> Added patch for alignment issues from debian (DaKa2).
Jul 05 16:23:31 <CIA-8> Bumped revision.
Jul 05 16:43:38 <DaKa2> dammit.. that was just damn annoying
Jul 05 16:43:54 <NAiL> heh
Jul 05 16:44:24 <NAiL> libusb/jpeg compiled, waiting for sane-backends to finish compiling (or bomb out ;)
Jul 05 16:44:58 <NAiL> bah
Jul 05 16:44:59 <NAiL> /bin/sh: ../tools/sane-desc: cannot execute binary file
Jul 05 16:45:02 <DaKa2> when detatching and reataching to my screen every chatacter was in, well. some japaneese font
Jul 05 16:45:06 <DaKa2> uhm..
Jul 05 16:45:27 <DaKa2> it shouldn't run that..
Jul 05 16:45:43 <NAiL> nope. Checking the optware make right now
Jul 05 16:46:18 <NAiL> Any idea what sane-desc does?
Jul 05 16:46:28 <DaKa2> I just fixed it in there, testbuilt, and commited
Jul 05 16:46:56 <DaKa2> generate list of supported SANE devices
Jul 05 16:47:05 <NAiL> aha
Jul 05 16:47:11 <DaKa2> from some .desc-file
Jul 05 16:48:56 <NAiL> Not sure how to fix that..
Jul 05 16:49:14 <DaKa2> ahh
Jul 05 16:49:18 <DaKa2> I know
Jul 05 16:49:53 <DaKa2> Makefile.in.patch in the optware package
Jul 05 16:50:19 <DaKa2> nobody whats the documentation on an embedded platform
Jul 05 16:50:39 <NAiL> ok, I'll try with that one
Jul 05 16:51:02 <DaKa2> sane-desc is run from the doc Makefile so that should fix it
Jul 05 16:52:28 <NAiL> Restarting backend build
Jul 05 16:52:44 <NAiL> A moment there it looked like the easiest package add ever :P
Jul 05 16:53:08 <NAiL> but.. libusb being fixed means that gphoto2 should work too, no?
Jul 05 16:53:10 <DaKa2> hehe, now that wouldn't have been any fun, would it?
Jul 05 16:53:14 <DaKa2> probably
Jul 05 16:53:20 <DaKa2> but I have nothing to test it against
Jul 05 16:53:24 * NAiL hugs DaKa2
Jul 05 16:53:28 <NAiL> I've got a Canon IXUS
Jul 05 16:53:36 <DaKa2> could be other faults in gphoto2
Jul 05 16:53:49 <NAiL> Yeah, but it's worth testing for me :D
Jul 05 16:53:51 <DaKa2> hm.. comming to think of it me too
Jul 05 16:54:12 <DaKa2> should test it with my ixus tomorrow
Jul 05 16:54:33 <DaKa2> I should get two nice shiny slugs then
Jul 05 16:54:44 <NAiL> Yeah, I'm gonna see if I can get it to build. And if it builds, I'll try with meh olde ixus
Jul 05 16:55:21 <DaKa2> gphoto2, with automatic emptying in connect would be so sweet
Jul 05 16:56:23 <NAiL> Exactly :D
Jul 05 16:57:08 <NAiL> NOTE: package sane-backends-1.0.15-r0: task do_package: started
Jul 05 16:57:12 <DaKa2> looks like some kind of hotplug is in openslug, so that should be possible
Jul 05 16:57:14 <DaKa2> :-)
Jul 05 16:57:15 <NAiL> Good Sign (TM)
Jul 05 16:57:29 <NAiL> Packaged contents of sane-backends into /home/repvik/nslu2/unstable/openslug/tmp/deploy/ipk/sane-backends_1.0.15-r0_armeb.ipk
Jul 05 16:57:34 <NAiL> Ok, looks good.
Jul 05 16:57:42 <DaKa2> if you want me to test the package, just put it somewhere and I can test it right now
Jul 05 16:58:19 <NAiL> Are you running openslug unstable? It won't work on 2.0
Jul 05 16:58:25 <DaKa2> ah, dammit
Jul 05 16:58:41 <NAiL> glibc change :(
Jul 05 16:58:50 <DaKa2> will install unstable on a slug tomorrow, if I can make it work :-)
Jul 05 16:58:55 <NAiL> Dunno if it's possible to override
Jul 05 16:59:19 <DaKa2> ah well, if it built, and it applied the patches, it should work
Jul 05 16:59:26 <NAiL> yeah, that's what I'm hoping
Jul 05 16:59:43 <jbowler-away> If you are perpared to reflash then it's worth just trying an upgrade from the unstable feed.
Jul 05 17:00:02 <jbowler-away> The worst that can happen is the system will crash and not be able to boot.
Jul 05 17:00:31 <jbowler-away> If you do the upgrade on the disk the flash file system will still be fine.
Jul 05 17:00:36 <DaKa2> I have no physical access to it right now, should probably not make an reflash remotly
Jul 05 17:00:56 <jbowler-away> No, that won't work because shutdown -r will hang.
Jul 05 17:01:02 <NAiL> DaKa2: Where'd the patches to sane-backends come from, btw?
Jul 05 17:01:13 <DaKa2> jbowler made the first one
Jul 05 17:01:24 <DaKa2> the other one was in the optware package
Jul 05 17:02:58 <DaKa2> well, might get to work tomorrow and fetch my slug + big camera, otherwise I just have to hope on getting the new ones
Jul 05 17:07:35 <DaKa2> one for stable use, one for development, one for playing with the hardware (i2c mainly)
Jul 05 17:07:59 <DaKa2> Ill probably find i could use more
Jul 05 17:08:28 <CIA-8> 03nail 07org.openembedded.nslu2-linux * re0f1dff4... 10/packages/sane-backends/ (3 files in 2 dirs): Added package sane-backends.
Jul 05 17:08:43 <DaKa2> fantastic!
Jul 05 17:10:28 <CIA-8> 03repvik * r57 10/trunk/openslug/nslu2-linux/packages/ (jpeg sane-backends): Added jpeg and sane-backends. Required for sane-backends.
Jul 05 17:11:44 <NAiL> I've found I need a heap :P
Jul 05 17:12:29 <NAiL> Trying gphoto2 now
Jul 05 17:12:36 <DaKa2> :)
Jul 05 17:13:17 <DaKa2> libusb atleast works in all the ways sane uses it
Jul 05 17:13:50 <NAiL> hmm... gphoto2 requires libexif and libgphoto2. Wonder if they'll build :P
Jul 05 17:14:08 <DaKa2> libexif is small, should work
Jul 05 17:14:08 <NAiL> Trying to build now. Might work "out of the box"
Jul 05 17:14:16 <NAiL> libexif built
Jul 05 17:14:40 <NAiL> Gonna upgrade my build box later tonight. Builds are too slow :P
Jul 05 17:15:06 <DaKa2> I do my cross-builds on a dual Xeon 2,4 with 1gb ram
Jul 05 17:15:28 <NAiL> tad faster than mine :P
Jul 05 17:15:36 <NAiL> amd 2000+, 1280mb
Jul 05 17:15:49 <NAiL> I've got a 2700+ that I've just freed up
Jul 05 17:15:51 <DaKa2> I want more, but all the better servers at work is used to much
Jul 05 17:16:14 <NAiL> Could try building on my AMD64 3700+ :D
Jul 05 17:16:34 <DaKa2> that would be kindof good
Jul 05 17:17:00 <DaKa2> could kill all our videosurveilance and use our dual opteron..
Jul 05 17:17:03 <NAiL> I've barely touched that box yet. It's my desktop, and it runs Windows
Jul 05 17:17:09 * CHAOSiTEC has some hmm weird observations while creating a bb file for mdadm...
Jul 05 17:17:09 <DaKa2> ugh
Jul 05 17:17:15 <NAiL> I've set aside plenty space for linux though ;)
Jul 05 17:17:26 <NAiL> CHAOSiTEC: what observations?
Jul 05 17:17:36 <DaKa2> my home is a no windows zone :-) all windows closed and curtains down
Jul 05 17:17:41 <NAiL> haha
Jul 05 17:18:13 <CHAOSiTEC> file reports the resulting compiled file mdadm is AMD64_X64 lol
Jul 05 17:18:28 <NAiL> Definitely broken :P
Jul 05 17:18:35 <CHAOSiTEC> u sure? rofl
Jul 05 17:18:44 <NAiL> CHAOSiTEC: Got the .bb anywhere I can check it?
Jul 05 17:18:54 <CHAOSiTEC> i took any other file that i compiled, and they where confirmed for arm
Jul 05 17:18:56 <NAiL> Not that I know what might be wrong, but...
Jul 05 17:19:22 <CHAOSiTEC> its a basic one yet, i have setup... havnt done anything special yet
Jul 05 17:20:08 <NAiL> libgphoto2 compiled
Jul 05 17:20:27 <NAiL> gphoto2 also requires popt, I see
Jul 05 17:20:37 <NAiL> so 2 of 4 compiled so far
Jul 05 17:21:05 <NAiL> If it works, I'll be happy :D
Jul 05 17:21:27 <NAiL> popt compiled
Jul 05 17:21:33 <NAiL> gphoto2 compiling, finally ;)
Jul 05 17:21:39 <CHAOSiTEC> to compile mdadm only thing needed is make, then make install.
Jul 05 17:21:52 <CHAOSiTEC> so either its the makefile or i am at a loss
Jul 05 17:22:06 <NAiL> No idea, I haven't looked at it at all
Jul 05 17:22:14 <NAiL> gphoto2 builds! :D
Jul 05 17:22:42 <NAiL> I'm going hunting for my camera :D
Jul 05 17:22:42 <DaKa2> :)
Jul 05 17:24:58 <CIA-8> 03repvik * r58 10/trunk/openslug/nslu2-linux/packages/ (gphoto2 libexif libgphoto2 popt): Added symlinks required for gphoto2
Jul 05 17:28:28 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * rc7189342... 10/packages/boost/ (3 files in 2 dirs): Changes to make libboost compile and link on uclibc
Jul 05 17:28:51 <NAiL> *just* did a sync 
Jul 05 17:30:58 * NAiL makes sure the current head is nail@nslu2-linux.org :P
Jul 05 17:32:15 <DaKa2> :) well, I should get some sleep, its getting late, bbl
Jul 05 17:32:17 <jbowler-away> 8 certs, 2 revs
Jul 05 17:32:37 * NAiL waits for CIA-8
Jul 05 17:32:40 <SpanKY> sooo i unpacked the unslung image with slugimage because i wanted to tweak the root fs before packing it up and sending it to the slug ...
Jul 05 17:32:46 <SpanKY> file file format is the FlashDisk file ?
Jul 05 17:33:01 <NAiL> DaKa2: nite
Jul 05 17:33:36 <CIA-8> 03nail 07org.openembedded.nslu2-linux * r9a11de92... 10/packages/meta/openslug-packages.bb: Added gphoto2 and sane-backends to packages.
Jul 05 17:34:25 <NAiL> ~emulate rwhitby
Jul 05 17:34:25 <jbot> Well, my work here is done.
Jul 05 17:35:07 <CHAOSiTEC> ~emulate NAiL
Jul 05 17:35:13 <CHAOSiTEC> lol
Jul 05 17:35:25 <NAiL> I cannot be emulated :P
Jul 05 17:35:32 <CHAOSiTEC> that, i figured rofl
Jul 05 17:36:07 <CHAOSiTEC> did you get your camera working with sane then, or havnt you tested yet?
Jul 05 17:36:30 <NAiL> Not tested quite yet. Haven't updated my slug with the current packages. 
Jul 05 17:36:39 <CHAOSiTEC> ahh ok
Jul 05 17:36:58 <CHAOSiTEC> is there any place i can read about, how to create bb files?
Jul 05 17:37:33 <CHAOSiTEC> or should i just train my .bb-fu? lol
Jul 05 17:38:03 <NAiL> There are some links to resources that will increase your .bb fu on the wiki.
Jul 05 17:38:22 <CHAOSiTEC> thanks ;-)
Jul 05 17:38:30 <NAiL> I've basically just looked at other .bb files and based my work off that.
Jul 05 17:38:53 <CHAOSiTEC> thats where i started, then i ran into the problem with mdadm (make install) lol
Jul 05 17:39:13 <CHAOSiTEC> plus the minor 64 bit glitch lol
Jul 05 17:39:31 <CHAOSiTEC> ill figure it out ;-) (i hope lol)
Jul 05 17:39:44 <NAiL> CHAOSiTEC: btw, mind not ending 90% of your sentences with "lol"?
Jul 05 17:39:51 <CHAOSiTEC> sure
Jul 05 17:55:47 <CIA-8> 03repvik * r59 10/trunk/openslug/openembedded/packages/samba/ (5 files in 3 dirs): Make samba work in stable.
Jul 05 17:56:51 <NAiL> ~emulate rwhitby
Jul 05 17:56:51 <jbot> Another Satisfied Customer!
Jul 05 17:56:55 <NAiL> :)
Jul 05 18:17:04 <SpanKY> hrm, bitbake from trunk is failing to install for me because setup.py is looking for bin/bbread which doesnt exist :/
Jul 05 18:17:06 <SpanKY> kergoth: ^^^
Jul 05 18:24:47 <NAiL> [g2]: :)
Jul 05 18:25:01 <[g2]> NAiL, were you sleeping ?
Jul 05 18:25:05 <NAiL> [g2]: got a scanner? running openslug? ;)
Jul 05 18:25:09 <NAiL> [g2]: yes. Twice.
Jul 05 18:25:23 <[g2]> good on the sleep!
Jul 05 18:25:31 <[g2]> congrats on SANE
Jul 05 18:26:03 <NAiL> Still untested though. I don't have any scanner (atleast not yet ;)
Jul 05 18:26:11 <[g2]> it'll get there
Jul 05 18:28:04 <SpanKY> [g2]: you have commit access to bitbake ?  the trunk has a bug in it which keeps it from installing ...
Jul 05 18:28:24 <SpanKY> setup.py wants bin/bbread which isnt in trunk
Jul 05 18:28:33 <NAiL> is bitbake still up?
Jul 05 18:28:34 <NAiL> duh
Jul 05 18:28:47 <[g2]> hey SpanKY !
Jul 05 18:28:47 * NAiL interpreted that as bitkeeper
Jul 05 18:29:13 <[g2]> SpanKY, where are you getting bb from ?
Jul 05 18:29:16 <SpanKY> berlios
Jul 05 18:29:22 <[g2]> svn ?
Jul 05 18:29:32 <SpanKY> yes ...
Jul 05 18:29:33 <NAiL> There was a recent update to bb, wasn't there?
Jul 05 18:29:42 <SpanKY> http://svn.berlios.de/viewcvs/*checkout*/bitbake/trunk/bitbake/setup.py <- refers to bin/bbread
Jul 05 18:30:14 <SpanKY> http://svn.berlios.de/viewcvs/bitbake/trunk/bitbake/bin/ <- no bbread
Jul 05 18:31:00 <[g2]> Did you do the wget from http://www.nslu2-linux.org/Makefile
Jul 05 18:31:18 <SpanKY> i'm using that now to compile unslung
Jul 05 18:31:30 <SpanKY> but i dont see how that's related ;)
Jul 05 18:31:40 <SpanKY> bugs are supposed to be reported :p
Jul 05 18:32:06 <[g2]> I haven't built the full unslung 
Jul 05 18:32:24 <[g2]> I know openslug-build worked earlier today
Jul 05 18:32:38 <SpanKY> well what i wanted to do was tweak the 5.5 image
Jul 05 18:32:54 <[g2]> sounds like a good plan
Jul 05 18:33:05 <SpanKY> i could unpack it with slugimage but i cant quite figure out how to manipulate the Flashdisk file
Jul 05 18:33:57 <[g2]> SpanKY, you know about the ipkg stuff right ?
Jul 05 18:34:32 <SpanKY> i know of ipkg, never used it
Jul 05 18:34:44 <SpanKY> are you implying i use ipkg after i boot up and unsling my slug ?
Jul 05 18:34:49 <SpanKY> ^should
Jul 05 18:35:20 <[g2]> no I'm wondering what you are trying to update
Jul 05 18:35:47 <[g2]> if it's the kernel, changing the defconfig and rebuilding will change it
Jul 05 18:36:15 <[g2]> if it's other packages, then you'll need to be a little careful as the jffs2 is only so big right ?
Jul 05 18:36:17 <SpanKY> i just wanted to edit some config files
Jul 05 18:36:29 <SpanKY> replace the busybox with a newer one i built myself
Jul 05 18:36:36 <SpanKY> replace the kernel with a custom patched ver
Jul 05 18:37:05 <[g2]> ok
Jul 05 18:37:31 <jbowler-away> Run OpenSlug, boot to a disk, use reflash to load the unslung ffs2 into the flash, mount it, edit it, copy it out and put the openslug one back.
Jul 05 18:38:42 <SpanKY> seems like it'd be a lot easier to manipulate the image on the build machine :)
Jul 05 18:38:55 <SpanKY> btw, you review my proposed xstatconv.c jbowler ?
Jul 05 18:39:29 <SpanKY> the reason i want to patch my kernel is because the default unslung kernel contains a patch that screws around with the kernel stat.h ... it was screwing me up before in my uClibc/armeb tests
Jul 05 18:42:39 <jbowler-away> Mike Frysinger posted the official uClibC patch (modified kernel_stat.h) to uclibc@uclibc.org, date on message was Mon 6/27/2005
Jul 05 18:44:12 <SpanKY> http://www.uclibc.org/lists/uclibc/2005-July/012122.html
Jul 05 18:44:17 <SpanKY> that's the one i'm refering to
Jul 05 18:44:53 <SpanKY> the links are broken ... you'll have to s/codepoet.org/www.uclibc.org/
Jul 05 18:46:25 <jbowler-away> The links fine - haven't read that message yet.  I haven't even tested his kernel_stat.h, which has has tested on ARMEB/2.4
Jul 05 18:56:35 <SpanKY> jbowler-away: i am mike frysinger ;p
Jul 05 18:57:45 <SpanKY> ive been testing on armeb/2.4 as well, but i was poking around the unslung 2.4 kernel and noticed that it screws around with stat.h
Jul 05 19:22:58 <jbowler-away> Ok, so unslung natively uses glibc-2.2.5, when I did the original fix I believed it to work on 2.4 kernels, but it didn't - I didn't detect this 
Jul 05 19:23:06 <jbowler-away> because Unslung doesn't use uclibc...
Jul 05 19:23:43 <jbowler-away> So that you pointed out that my fix was broken on armeb/2.4 and I believe it was (on examining the correct kernel headers).
Jul 05 19:24:10 <jbowler-away> The xstatconv.c hack I have should, however, work anywhere so long as the actual position of the fields is not changed.
Jul 05 19:24:48 <jbowler-away> That is checked in to the current OE builds of uclibc 0.9.27.  I haven't looked at any of the other stuff (229 unread messages on uclibc :-(
Jul 05 19:25:23 <jbowler-away> I haven't tested either the kernel_stat.h you emailed to me directly or anything since.
Jul 05 19:26:03 <jbowler-away> I'm almost 100% certain that the kernel_stat.h will work on armeb/2.6 - but I haven't checked st_blocks (I need to find something which actually accesses that field!)
Jul 05 19:26:58 <jbowler-away> So if it works on armeb/2.6, armel/2.6 and armeb/2.4 I don't understand why it would fail on armel/2.4 - but then I don't understand why it works either!
Jul 05 19:37:58 <SpanKY> i dont have any armel/2.4 boxes but i can make some ... all of my armel are running 2.6
Jul 05 23:03:37 <ov2k> hello
Jul 05 23:03:59 <ov2k> I'm not sure I checked my changes to openvpn into cvs properly
Jul 05 23:04:07 <ov2k> was wondering how to check
Jul 05 23:04:20 <ov2k> is anybody around?
Jul 05 23:08:33 <CIA-8> 03jbowler 07org.openembedded.nslu2-linux * rad00e4c2... 10/packages/monotone/ (files/cryptopp-endianness.patch monotone_0.19.bb): 
Jul 05 23:08:33 <CIA-8> Working (db init capable) version of monotone. r1 fixes an endianness
Jul 05 23:08:33 <CIA-8> configuration error in cryptopp - cryptopp was being compiled for a
Jul 05 23:08:33 <CIA-8> little endian host.
Jul 05 23:16:41 <jacques> monotone: warning: doing anonymous pull
Jul 05 23:16:41 <jacques> monotone: connecting to monotone.vanille.de
Jul 05 23:16:41 <jacques> monotone: network exception: failed to connect: Connection refused
Jul 05 23:22:09 <jbowler-away> It apparently drops out on a regular basis.
Jul 05 23:22:50 <ov2k> help /toggle
Jul 05 23:23:00 <jacques> jbowler-away, that's not good
Jul 05 23:23:47 <jacques> this is now oe's repository and it's that unreliable?
Jul 05 23:25:33 <jbowler-away> Curious, viewmtn seems to be ok...
Jul 05 23:26:16 <jacques> could I be doing something wrong? this is a clean attempt just wgot http://www.nslu2-linux.org/Makefile
Jul 05 23:26:23 <jacques> I tried both make and make setup
Jul 05 23:26:47 <jbowler-away> I've been trying to pull over the last couple of hours - no luck.
Jul 05 23:27:13 <jacques> sigh
Jul 05 23:27:39 <jacques> who's responsible for that repos? koen?
Jul 05 23:28:54 <jbowler-away> mickeyl for vanille, but neither he nor koen are on line
Jul 05 23:29:05 <jacques> #oe is dead
Jul 05 23:31:20 <jacques> are we more vulnerable to oe's failures now than before?
Jul 05 23:31:28 <jacques> at least before we had our own repository
Jul 05 23:31:40 <jacques> and that was sufficient to build from
Jul 05 23:32:21 <jacques> oe's failures == oe's infrastructure failures
Jul 05 23:33:25 <jbowler-away> Hand edit monotone.vanille.de --> monotone.nslu2-linux.org in the Makefile
Jul 05 23:34:34 <jacques> ok
Jul 05 23:35:22 <jbowler-away> The only reason for the pull from vanille is to reduce the load on nslu2-linux.org
Jul 05 23:35:45 <jacques> hmmm
Jul 05 23:35:49 <jacques> looking at the makefile
Jul 05 23:36:03 <jacques> right after the monotone.vanille.de pull is a monotone.nslu2-linux.org pull
Jul 05 23:36:21 <jacques> if I do a replace, wont it just pull from monotone.nslu2-linux.org twice?
Jul 05 23:36:36 <jbowler-away> Yes, the second one will be very fast ;-)
Jul 05 23:36:38 <jacques> do I comment out the first pull or the second?
Jul 05 23:36:44 <jacques> oh second is still needed?
Jul 05 23:37:16 <jbowler-away> I can't remember, you want the nslu2-linux defaults though.  It does no harm to do it twice.
Jul 05 23:37:38 <jacques> ok, do I just do 'make' or 'make setup && make' ?
Jul 05 23:38:04 <jbowler-away> make setup, unless someone has updated the makefile on www.nslu2-linux.org (in which case make setup is still ok)
Jul 05 23:38:50 <jacques> ok
Jul 05 23:39:38 <jacques> pulling now
Jul 05 23:45:57 <dyoung-zzzz> jacques, I've had that vanille.de no route to host issue since this morning.
Jul 05 23:46:07 <dyoung-zzzz> I figured it was my crappy cable modem service crapping out.
Jul 05 23:46:38 <jacques> I don't get no route (tho something is seriously fscked with the internet today going by traceroute) I get connection refused
Jul 05 23:46:54 * dyoung-zzzz tries again.
Jul 05 23:48:05 <jacques> hmm, monotone pulled 21.0MB and now is taking 100% cpu for a few minutes now
Jul 05 23:48:16 <dyoung-zzzz> in theory, if I open the right port and start monotone with the server option, you should be able to pull from me (if speed is the issue with pulling the whole 27M from monotone.nslu2-linux.org)
Jul 05 23:48:23 <jacques> it didn't say it was doing anything
Jul 05 23:48:42 <dyoung-zzzz> ah, now I get network exception: connection refused.
Jul 05 23:48:53 <jacques> monotone: [bytes in: 21.0M] [bytes out: 181.1k] [certs in: 565] [revs in: 170]
Jul 05 23:49:01 <jacques> is that normal?
Jul 05 23:49:11 <dyoung-zzzz> "this might take a while" is a understatement.
Jul 05 23:49:18 <jacques> but it didn't say that
Jul 05 23:49:32 <jacques> monotone: connecting to monotone.nslu2-linux.org
Jul 05 23:49:32 <jacques> monotone: rebuilding merkle trees for collection org
Jul 05 23:49:32 <jacques> monotone: [bytes in: 557.6k] [bytes out: 45.8k] [certs in: 565] [revs in: 170]
Jul 05 23:49:32 <jacques> monotone: verifying new revisions (this may take a while)
Jul 05 23:49:33 <jacques> monotone: [bytes in: 21.0M] [bytes out: 181.1k] [certs in: 565] [revs in: 170]  
Jul 05 23:49:44 <jacques> it said it before the 21.0MB pull, but notihng after
Jul 05 23:49:52 <jbowler-away> This is normal
Jul 05 23:50:06 <dyoung-zzzz> that looks around how m ine looked too.
Jul 05 23:50:14 <jacques> ok, how long did you have to wait ?
Jul 05 23:50:20 <dyoung-zzzz> then it sits there for "a while" .
Jul 05 23:50:28 <jbowler-away> How fast is your CPU?
Jul 05 23:50:49 <dyoung-zzzz> brb food.
Jul 05 23:52:15 <jacques> well it's still updating nslu2-linux.db because mod time keeps changing
Jul 05 23:52:54 <jacques> jbowler-away, this is on my laptop - Pentium M 1.7 GHz - slightly faster than my XP3200+
Jul 05 23:54:21 <jbowler-away> Less than 10 minutes then, I think.
Jul 05 23:55:08 <jacques> ok, I just don't remember it taking this long last time (weeks ago) on a much slower machine
Jul 05 23:57:07 <jbowler-away> The database is bigger, there are a lot more revisions and the spaghetti is more, well, tangled.
Jul 05 23:57:26 <jacques> ok
Jul 05 23:59:31 <jbowler-away> Now is a good time to pull monotone, 0.20 is in the db.
**** ENDING LOGGING AT Tue Jul 05 23:59:56 2005