**** BEGIN LOGGING AT Tue Oct 25 02:59:58 2005
Oct 25 04:01:00 <CIA-8> 03hrw 07org.openembedded.dev * r0d7e270c... 10/packages/asterisk/asterisk_1.0.9.bb: asterisk: fixed SRC_URI
Oct 25 04:01:02 <CIA-8> 03hrw 07org.openembedded.dev * r6c74e180... 10/packages/diethotplug/diethotplug_0.4.bb: diethotplug: fixed SRC_URI
Oct 25 04:21:13 <CIA-8> 03hrw 07org.openembedded.dev * r8cef5b08... 10/packages/directfb/directfb_0.9.22.bb: directfb: fixed SRC_URI
Oct 25 04:21:15 <CIA-8> 03hrw 07org.openembedded.dev * r6c88ebf1... 10/packages/dfb++/dfb++_0.9.22.bb: dfb++: fixed SRC_URI
Oct 25 04:21:18 <CIA-8> 03hrw 07org.openembedded.dev * r5bb12b69... 10/packages/dnsmasq/dnsmasq_2.11.bb: dnsmasq: fixed SRC_URI for 2.11 version
Oct 25 04:35:38 <CIA-8> 03hrw 07org.openembedded.dev * rce0e128a... 10/packages/libxml/ (libxml2_2.6.7.bb libxml2_2.6.9.bb): libxml: fixed SRC_URI for 2.6.7, 2.6.9 versions
Oct 25 04:35:41 <CIA-8> 03hrw 07org.openembedded.dev * rfda8cbc2... 10/packages/cyrus-imapd/cyrus-imapd_2.2.5.bb: cyrus-imapd: fixed SRC_URI for 2.2.5 version
Oct 25 04:35:44 <CIA-8> 03hrw 07org.openembedded.dev * rd9127ccc... 10/packages/cyrus-sasl/ (cyrus-sasl_2.1.17.bb cyrus-sasl_2.1.18.bb): cyrus-sasl: fixed SRC_URI for 2.1.17, 2.1.18 versions
Oct 25 04:58:25 <CIA-8> 03rwhitby * 10debian/patches/linux-2.6.14-rc5-nslu2.patch: Copied from -rc4
Oct 25 05:13:45 <dwery> rwhitby: ping
Oct 25 05:15:59 <rwhitby> dwery: gu
Oct 25 05:16:17 <dwery> deepak hasn't answered yet.. have you heard of him?
Oct 25 05:16:47 <rwhitby> I've heard of him, but not from him :-)
Oct 25 05:16:53 <dwery> :)
Oct 25 05:19:35 <CIA-8> 03rwhitby * 10debian/Makefile: Updated to build 2.6.14-rc5, and to package the Debian kernel image.
Oct 25 05:19:54 <dwery> the patches still aren't in git..
Oct 25 05:23:01 <dwery> don't you want to send him an email
Oct 25 05:23:02 <dwery> ?
Oct 25 05:24:05 <rwhitby> He doesn't know me from Adam, so I doubt that would do anything.  He is on the nslu2-developers mailing list, so he knows that you are representing the project consensus in this matter
Oct 25 05:27:10 <CIA-8> 03rwhitby * 10unslung/sources/ufsd/postinst: Updated the md5sum.
Oct 25 05:27:54 <dwery> ok.. so he is simply busy ... i don't want to bother him again...
Oct 25 05:28:24 <CIA-8> 03rwhitby * 10unslung/make/ufsd.mk: Bumped the ipk version.
Oct 25 05:28:45 <rwhitby> yeah, as long as we have sent the patches upstream, and are prepared to answer any questions, then that is really all we can do.
Oct 25 05:29:58 <dwery> i think it's a couple of weeks now..
Oct 25 05:30:30 <rwhitby> he did say that ixp4xx was low priority for him at the moment.
Oct 25 05:36:42 <dwery> well ok, but give that he his the ixp4xx maintainer.. :D
Oct 25 05:38:37 <dwery> .. if he doesn;t care, we have a problem.
Oct 25 05:41:21 <rwhitby> well, we've had an nslu2 kernel for a year now with no upstream push, so a month more won't hurt :-)
Oct 25 05:41:52 <dwery> :)
Oct 25 05:43:53 <rwhitby> dwery: can you join #debian-arm ?
Oct 25 05:44:02 <dwery> now? 
Oct 25 05:44:05 <rwhitby> yep
Oct 25 05:44:09 <dwery> ok
Oct 25 05:55:16 <rwhitby> dwery: The loud silence makes me thing that there is actually no-one upstream waiting for these patches, as was previously reported to us second-hand.
Oct 25 05:55:58 <dwery> i just saw that lenner even answered to the first patch on l-a-k  
Oct 25 05:56:16 <rwhitby> yep, he gave it his support.
Oct 25 07:03:41 <rwhitby> dwery: no response.  your call as to what we do next.
Oct 25 07:04:05 <dwery> i'll write that email...
Oct 25 07:05:20 <rwhitby> ok, make it clear that we are happy to send or happy to wait until deepak has an opportunity to process the second patch.  if there is no-one waiting for them, then we don't need to apply undue pressure.
Oct 25 07:06:25 <rwhitby> the project can continue from the cvs kernel repo, irrespective of the rate of upstream inclusion.  as long as we fulfil our responsibility by sending them and replying to questions, then that's all we can reasonably do.
Oct 25 07:08:10 <rwhitby> meanwhile, I'm off to bed.  night dwery, and thanks.
Oct 25 07:08:19 <dwery> good night!
Oct 25 07:45:40 <CIA-8> 03hrw 07org.openembedded.dev * r58b66421... 10/packages/dash/dash_0.5.2.bb: dash: get debian patch from snapshot.debian.net
Oct 25 07:45:42 <CIA-8> 03hrw 07org.openembedded.dev * rdcbbbac5... 10/packages/enscript/enscript_1.6.4.bb: enscript: switched SRC_URI to Debian mirrors
Oct 25 08:00:57 <jbowler-away> dwery: that redboot.c patch apparently needs to go to someone else (the mysterious 'MTD maintainer') - since it is technically independent of the ixp4xx flash stuff and is definately not NSLU2 specific maybe that should be sent now?
Oct 25 08:01:25 <jbowler-away> Hum, on mtdblock.c: 2000-2003 Nicolas Pitre - he's definately on l-a-k
Oct 25 08:08:48 <dwery> jbowler-away: ack
Oct 25 08:09:06 <dwery> jbowler-away: can you send it?
Oct 25 08:15:38 <CIA-8> 03hrw 07org.openembedded.dev * r24ea45d9... 10/packages/libelf/libelf_0.8.3.bb: libelf: fixed SRC_URI to new location
Oct 25 08:19:20 <jbowler-away> dwery: yes - but what mailing list?
Oct 25 08:19:59 <jbowler-away> If I send it to l-a-k then I guess Nicholas Pitre is there and the context of the ixp4xx patch is there too, so I'll just get told to send it somewhere else...
Oct 25 08:20:45 <jbowler-away> BTW I updated it to remove compiler warnings because __u32 is not the same type as unsigned long (at least on the versions of gcc we use)
Oct 25 08:24:01 <dwery> jbowler-away: I would send it to Nicholas and to any mtd related ml
Oct 25 08:24:18 <dwery> as dictated by the SubmittingPatches guidelines :)
Oct 25 08:24:46 <jbowler-away> What SubmittingPatches guidelines?
Oct 25 08:25:00 <dwery> Documentation/SubmittingPatches
Oct 25 08:25:08 <jbowler-away> Ah, thanks.
Oct 25 09:06:39 <Jacmet> jbowler-away: why don't you just send it to the mtd list?
Oct 25 09:07:52 <Jacmet> jbowler-away: linux-mtd@lists.infradead.org - that's where the mtd related stuff is usually handled
Oct 25 09:31:07 <jbowler-away> jacmet: yes, that's the list in the MAINTAINERS file, along with Jörn Engel
Oct 25 09:55:37 <CIA-8> 03noodles 07org.openembedded.dev * r8c6044d6... 10/packages/radvd/radvd_0.7.2.bb: radvd: Add build time dependancy on flex.
**** BEGIN LOGGING AT Tue Oct 25 12:55:50 2005
Oct 25 13:11:21 <CIA-8> 03jbowler 07org.openembedded.dev * r83e8fa36... 10/packages/ixp4xx/ (ixp-osal_2.0.bb ixp4xx-csr_2.0.bb): ixp4xx: (comments only) fix bad version number in comment for 2.0
Oct 25 13:30:38 <CIA-8> 03rpurdie 07org.openembedded.dev * rf4799c65... 10/packages/linux/ (3 files in 2 dirs): (log message trimmed)
Oct 25 13:30:39 <CIA-8> linux-oz-2.6: Various updates to dev kernel:
Oct 25 13:30:39 <CIA-8> * Add various compile fixes passed to mainline
Oct 25 13:30:39 <CIA-8> * Update pm code to use pxa_pm_ops as discussed on LAKML
Oct 25 13:30:39 <CIA-8> * Add ALSA SoC subsystem patches from Liam Girdwood
Oct 25 13:30:40 <CIA-8> * Add ALSA wm8731 codec driver (as found in c7x0)
Oct 25 13:30:42 <CIA-8> * Update c7x0 defconfig to make OSS drivers modular and enable ALSA drivers (output only for now)
Oct 25 14:22:43 <orda> Im trying to cross comile a little c program, but while compiling, it can't find term.h
Oct 25 14:23:09 <orda> I have the output from the compile here:
Oct 25 14:23:33 <orda> http://pastebin.com/405798
Oct 25 14:24:37 <orda> Ive staged ncurses
Oct 25 14:28:55 <rwhitby-asleep> is term.h in usr/local/src/slug/unslung/staging/opt/include   ?
Oct 25 14:31:51 <rwhitby-asleep> orda?
Oct 25 14:32:07 <orda> sorry , no im right here :)
Oct 25 14:33:00 <orda> no it is not
Oct 25 14:33:37 <orda> sp maybe that why :) but then how should I get term.h ?
Oct 25 14:34:25 <orda> /usr/local/src/slug/unslung/staging/opt/include/ncurses/term.h
Oct 25 14:35:17 <rwhitby-asleep> ok, so you either need to patch the source to include term. from the ncurses subdir (not recommended) or change the .mk file to include .../include/ncurses on the gcc command line.
Oct 25 14:35:26 <rwhitby-asleep> the latter would be the best solution.
Oct 25 14:36:11 <orda> I belive I have http://pastebin.com/405817
Oct 25 14:36:26 <orda> ?
Oct 25 14:37:12 <orda> that is a snippit from my mk file
Oct 25 14:37:19 <rwhitby> but it doesn't seem to be getting onto the gcc command line.
Oct 25 14:37:58 <rwhitby> So there must be a problem with the configure script or upstream Makefile that is not taking notice of  your configure options.
Oct 25 14:38:27 <rwhitby> I agree that it looks like you are doing everything right from an Optware point of view.  The problem is now inside the package you  are building.
Oct 25 14:38:56 <orda> hm :(
Oct 25 14:44:12 <orda> thats not good
Oct 25 14:44:52 <orda> Ill write the program my self then ;) without term.h
Oct 25 14:44:57 <orda> hehe
Oct 25 14:46:03 <rwhitby> or just patch the Makefile or configure script for the package ...
Oct 25 14:50:52 <orda> what should I patch it to ?
Oct 25 14:51:21 <orda> so taht it uses ......./.../ncurses/term.h ?
Oct 25 14:53:08 <rwhitby> up to you which way you patch it
Oct 25 17:19:57 <kolla__> hm, is the ixp425_eth mii compatible?
Oct 25 17:23:10 <kolla__> mii-tool gives me lots of "Operation not permitted"
Oct 25 17:23:34 <jacques> it didn't use to be
Oct 25 17:23:43 <jacques> I Doubt things have changed
Oct 25 17:27:22 <kolla__> ok
Oct 25 17:27:41 <[g2]> kolla__ mii-tool runs fine on OS
Oct 25 17:27:42 <[g2]> ODS
Oct 25 17:28:00 <jbowler-away> Which driver?  1.2 or 1.4?
Oct 25 17:28:05 <kolla__> [g2]: that's what I got the impression of from googling
Oct 25 17:28:07 <[g2]> 1.4
Oct 25 17:28:31 <kolla__> hm.. driver version? :)
Oct 25 17:28:33 <jbowler-away> Ok - then that's the new one (i.e. ixp400)
Oct 25 17:28:47 <[g2]> I think the new one is 2.0
Oct 25 17:29:18 <jbowler-away> No, that's IAL, the ethernet driver is ixp400-eth_1.4 or ixp425-eth_1.2 (or 1.1)
Oct 25 17:29:20 <[g2]> jbowler-away congrats on the 2.0 stuff 
Oct 25 17:29:33 <kolla__> I obviously missed something :)
Oct 25 17:29:35 <jbowler-away> thx
Oct 25 17:30:27 <kolla__> the ethernet module I have is ixp425_eth
Oct 25 17:30:35 <jbowler-away> That's definately the old one.
Oct 25 17:30:51 <kolla__> I see :)
Oct 25 17:31:08 <jbowler-away> (Regardless of the version - the module has the more generic name)
Oct 25 17:31:25 <[g2]> Ok... I'm using the 1.1 patch file
Oct 25 17:31:53 <[g2]> with IAL version 1.4 from ixp400
Oct 25 17:31:58 <jbowler-away> Well, then if mii-tool works on ODS and fails on OE there's something wrong with the OE package.
Oct 25 17:32:32 <[g2]> are you running as root ?
Oct 25 17:32:37 <jbowler-away> kolla__: you could just try grabbing the Debian package and extracting the executable, it will probably work.
Oct 25 17:33:29 <[g2]> loft@Loft:/root$ /sbin/mii-tool 
Oct 25 17:33:29 <[g2]> SIOCGMIIPHY on 'eth0' failed: Operation not permitted
Oct 25 17:33:36 <[g2]> run as a normal user
Oct 25 17:33:59 <kolla__> I get that running as root :P
Oct 25 17:35:39 <[g2]> kolla__ which version ? mii-tool -V
Oct 25 17:36:23 <[g2]> and I'm assuming the ixp modules are loaded and running
Oct 25 17:36:30 <[g2]> are you running af_packet ?
Oct 25 17:36:41 <[g2]> and does dmesg have any errors in it ?
Oct 25 17:36:46 <kolla__> 1.9
Oct 25 17:37:34 <kolla__> af_packet is loaded, and dmesg is full of "ixp425_eth: Error reading MII reg 1 on phy 0" and alike
Oct 25 17:38:44 <kolla__> if I do a "mii-tool eth0" I get 9 lines of "SIOCGMIIREG on eth0 failed: Operation not permitted" and then "eth0: negotiated 100baseT4 flow-control, link ok"
Oct 25 17:40:26 <kolla__> ftp.debonaras.org seems to be down
Oct 25 17:45:35 <[g2]> kolla can you ping on that interface ?
Oct 25 17:45:56 <[g2]> jbowler-away hey congrats again on that l-a-k cleanup patch
Oct 25 17:46:20 <[g2]> I was just going to play with that tonight but just saw it on the l-a-k
Oct 25 17:49:02 <jbowler-away> [g2]: which one - the trivial one or the shutdown?
Oct 25 17:49:28 <[g2]> jbowler-away unfortunately the trivial
Oct 25 17:49:55 <[g2]> the shutdown is important to but the flash reset is tied into the hw reset on the Loft
Oct 25 17:50:22 <[g2]> also there will probably be an external hw watchdog
Oct 25 17:50:56 <kolla> [g2]: yes, everything seems normal, but I only get ~1MB/sec transfers, so I thought I'd check speed and duplexity on the interface
Oct 25 17:51:51 <[g2]> 1MB/sec to what from what ?
Oct 25 17:52:01 <[g2]> is that ssh/scp ?
Oct 25 17:52:23 <kolla> yes... hm, cpu overhead? :)
Oct 25 17:52:24 <jbowler-away> [g2]: so how do you do an arch_reset on loft - via a GPIO line?
Oct 25 17:53:18 <[g2]> I'm not exactly sure what arch_reset is currently doing
Oct 25 17:54:05 <[g2]> I do know that it's been working very well and I haven't needed to look at it
Oct 25 17:54:25 <jbowler-away> well, if it does a hard cpu reset the ixp4xx implementation fires off the internal (broken) watchdog
Oct 25 17:54:45 <jbowler-away> and soft reset (branch to 0) has never worked for me
Oct 25 17:55:51 <jbowler-away> are you going to push the loft changes upstream?
Oct 25 17:56:02 <[g2]> absolutely
Oct 25 17:56:33 <[g2]> I was planning on pushing them as a set
Oct 25 17:56:52 <[g2]> they are split out between common and local to MACH
Oct 25 17:57:04 <jbowler-away> there's probably commonality with the NSLU2 code, some of the board level tests could be merged
Oct 25 17:57:24 <[g2]> and I'll need to forward port from 2.6.11.12
Oct 25 17:57:42 <[g2]> actually there's not a ton of componaility
Oct 25 17:57:54 <[g2]> the stuff that's common is IXP4xx common
Oct 25 17:58:10 <[g2]> but I've got extra PCI busses to scan etc..
Oct 25 17:58:18 <jbowler-away> in general anything derived from ixdp425 really needs a common 'is this like an ixdp425' test
Oct 25 17:59:19 <[g2]> yes I'm gonna push to change the CF/IDE driver to be a common IXP4XX driver instead of board/MACH specific
Oct 25 17:59:49 <[g2]> because anyone on a 4XX plaform could use the code
Oct 25 18:00:09 <[g2]> if one desoldered the flash and added an IDE adapter on the slug it could work
Oct 25 18:00:18 <[g2]> but probably isn't worth all the soldering
Oct 25 18:00:46 <kolla> :)
Oct 25 18:00:50 <CIA-8> 03bzhou * 10unslung/make/py-sqlite.mk: upstream upgrade from 2.0.4 to 2.0.5
Oct 25 18:02:11 <[g2]> kolla so you're seeing 1.0MBs on a 266 ?
Oct 25 18:02:18 <[g2]> for scp ?
Oct 25 18:02:19 <kolla> yes
Oct 25 18:02:24 <kolla> correct
Oct 25 18:02:35 <[g2]> cause the loft runs 2.0MBs at 533
Oct 25 18:03:18 <kolla> aha :)
Oct 25 18:03:20 <[g2]> I was scp'ing some 80-100MB files around and seeing 1.9/2.0
Oct 25 18:03:30 <[g2]> and 100% ish CPU util
Oct 25 18:03:46 <kolla> ok, ah well.. hehe
Oct 25 18:03:58 <[g2]> I was thinking someone should fine the roultine/algo and tune that portion of the code
Oct 25 18:04:09 <[g2]> I haven't played with it at all
Oct 25 18:05:00 <kolla> what is 100baseT4 anyways?
Oct 25 18:05:03 <[g2]> I would think one could comple ssh/dropbear with profiling and see exactly what eating all the CPU goodness
Oct 25 18:05:17 <[g2]> s/comple/compile/
Oct 25 18:08:14 <CIA-8> 03bzhou * 10unslung/make/cherokee.mk: upstream upgrade from 0.4.26 to 0.4.27
Oct 25 18:18:39 <[g2]> kolla 100BaseT ful duplex ?
Oct 25 18:35:46 <kolla> I'm used to 100baseTx-FD
Oct 25 18:37:16 <ByronT> 100BaseTx = 4-wire cabling
Oct 25 18:37:24 <ByronT> 100BaseT4 = 8 wire cabling
Oct 25 18:37:30 <kolla> aha
Oct 25 18:37:32 <ByronT> it was an HP specification
Oct 25 18:38:13 <ByronT> back in the early days of fast ethernet...
Oct 25 21:42:21 <Dsbeerf> Hello all
Oct 25 21:42:34 <Dsbeerf> is possible to use a personal distro for the nslu2 ?
Oct 25 21:43:22 <rwhitby-web> Dsbeerf: define "personal distro"
Oct 25 21:43:42 <Dsbeerf> well since now you can do it with debian i mean like moving it on slackware or freebsd 
Oct 25 21:44:11 <rwhitby-web> Dsbeerf: does slackware or freebsd have arm or armeb binaries available ?
Oct 25 21:44:27 <Dsbeerf> yes
Oct 25 21:44:28 <jbowler-zzz> Changing the kernel is more difficult, Debian bootstraps off the linux kernel, same as OE.
Oct 25 21:45:11 <jbowler-zzz> In principle it's easy - just change the preferred provider of virtual/kernel (in the distro.conf) and add a suitable kernel package.
Oct 25 21:45:52 <Dsbeerf> ok
Oct 25 21:46:12 <jbowler-zzz> not necessary for slackware of course
Oct 25 21:46:28 <jbowler-zzz> (2.6.13 is in testing)
Oct 25 21:46:36 <Dsbeerf> k
Oct 25 21:46:56 <Dsbeerf> so it can be doable
Oct 25 21:47:27 <jbowler-zzz> Then the next step is to work out whether the thing will bootstrap from an initrd without a serial port, that was the tricky bit for Debian
Oct 25 21:49:30 <Dsbeerf> well i added a serial port to make it more easy
Oct 25 21:51:23 <jbowler-zzz> Then slackware might just work - if whatever it needs to start will run against a fairly stock ARM BE or LE Linux kernel.
Oct 25 21:51:52 <Dsbeerf> okay. thanks for the point :)
Oct 25 21:52:01 <Dsbeerf> now i have an idea of where to start
Oct 25 21:53:03 <jbowler-zzz> FreeBSD would be a lot more work - there won't be a flash driver for the kernel so it won't be able to run off flash, so the initrd will be work.
Oct 25 21:54:41 <Dsbeerf> yeah
**** ENDING LOGGING AT Wed Oct 26 02:59:58 2005