[12:05] <lamont> dilinger: btw, would you happen to know: debian/2.6.12/ia64: working or no?
[12:36] <BenC> lamont?
[12:37] <lamont> si?
[12:41] <BenC> nevermind :)
[12:42] <BenC> lamont: do you know anyone besides neuro and elmo that handle the debian buildd's?
[12:43] <lamont> depends on what you mean by 'handle'
[12:43] <lamont> I do hppa/ia64
[12:43] <BenC> someone that can setup auric as a sparc buildd
[12:43] <lamont> infinity is involved in m68k
[12:43] <lamont> sparc is elmo, iirc
[12:43] <BenC> ok
[12:43] <lamont> and auric would certainly be DSA-types
[12:44] <BenC> elmo has been MIA all day
[04:10] <zul> evening
[04:10] <BenC> yo
[04:10] <zul> whats up
[04:18] <zul> i think we could try updating spca5x driver this weekend ;)
[04:49] <infinity> BenC : We have 1001 offers for sparc buildds, several of which are much beefier than auric, but I need to talk to elmo so see if we can get any going.
[06:38] <fabbione> morning guys
[06:38] <crimsun> morning
[06:38] <fabbione> BenC: sparc kernel is up :)
[06:59] <BenC> infinity: we have 2 buildd's now
[07:00] <BenC> infinity: and none of the offers I saw were worth anything
[07:00] <BenC> infinity: elmo already has auric going
[07:00] <BenC> fabbione: cool
[07:00] <BenC> auric is steadily building packages as we speak
[07:12] <fabbione> BenC: when do you plan to put your e3k back online?
[07:12] <BenC> after I move
[07:12] <BenC> hopefully in the next week
[07:12] <fabbione> ah cool
[07:12] <fabbione> i was expecting a 2 months movement ;)
[07:12] <fabbione> hmm i need to add the other buildd online 
[07:12] <fabbione> we got 2 offered, but one (pretty fast) keep crashing
[07:13] <fabbione> i need to check on this on
[07:13] <fabbione> +e
[07:13] <fabbione> Setting up linux-image-2.6.12-9-sparc64 (2.6.12-9.14) ...
[07:17] <fabbione> vultus5:/# debootstrap breezy /mnt http://mirror.int.fabbione.net/ubuntu
[09:11] <infinity> BenC : Well, one offer I saw was for a machine pretty much identical to auric, but with 2G of RAM.
[09:11] <infinity> Anyhow, it's the matter's well in hand, I don't much care. :)
[11:30] <mjg59> Bestest kernel EVAR.
[02:15] <mjg59> BenC: Uhm. Did you actually enable sk98lin in the .config?
[02:30] <BenC> mjg59: that's a damn good question
[03:00] <BenC> and the answer would be no, but the upside is, 9.15 is going to upload in about 30 minutes
[03:01] <BenC> I forgot to enable ndiswrapper on amd64 aswell
[03:01] <mjg59> Ha
[03:01] <mjg59> BenC: Have you spoken to kamion?
[03:02] <BenC> no
[03:07] <mjg59> BenC: Nothing should be uploaded to main at the moment unless you have clearance
[03:11] <fabbione> BenC: hold on.. wouldn't be an idea to do a test build around with that config change first?
[03:11] <fabbione> are we sure that driver build everywhere?
[03:11] <BenC> sk98lin?
[03:12] <BenC> it will only be building everywhere skge and sky2 were building
[03:12] <BenC> well, that's probably everywhere except hppa, atm
[03:12] <fabbione> that includes sparc too
[03:12] <BenC> I'm talking to Kamion first
[03:12] <zul> hey
[03:12] <BenC> I know it builds on sparc
[03:13] <BenC> used it before on sparc64
[03:13] <BenC> hey zul
[03:13] <fabbione> BenC: hmm ok
[03:13] <fabbione> should i run a test build for the sake of god?
[03:13] <BenC> hold a sec
[03:13] <fabbione> sure
[03:17] <BenC> well, green light for 9.15 upload
[03:17] <BenC> fabbione: changes commited
[03:17] <fabbione> BenC: did you add the drivers to the udebs?
[03:17] <fabbione> so that also the installer can actually use it?
[03:17] <BenC> no, wasn't aware of that...let me do that
[03:18] <fabbione> do you know how?
[03:18] <fabbione> otherwise i can do it on the fly
[03:18] <BenC> got it
[03:18] <BenC> nic-modules, right?
[03:19] <BenC> is that the only place?
[03:19] <BenC> also, what does the question mark in "foo ?" mean in that file?
[03:19] <fabbione> debian/d-i/shared/something...
[03:19] <fabbione> foo <- the module MUST be there
[03:19] <BenC> ah
[03:19] <fabbione> foo ? <- include it if it's there otherwise skip it.. no failure
[03:19] <fabbione> so you must add a ?
[03:20] <fabbione> since not all arches will ship this module, right?
[03:20] <BenC> right
[03:21] <BenC> ok, got that in too
[03:22] <fabbione> updating the local tree
[03:23] <BenC> too about 15 minutes to collect the abi files for all 6 arches
[03:23] <BenC> took*
[03:24] <fabbione> given that all of them do actually build. otherwise you are in trouble :)
[03:24] <fabbione> oh crap
[03:24] <fabbione> i forgot to switch archive
[03:27] <BenC> fabbione: so you said 2.6.14 should be done like 2.6.14-2.6.13.90-X.Y until 2.6.14 final, right?
[03:27] <fabbione> no i suggest you use something like 2.6.13.90
[03:28] <fabbione> as major upstream
[03:28] <fabbione> never put the final, until it's final
[03:28] <BenC> well, I was going to call it linux-source-2.6.14
[03:28] <BenC> but the version would start at 2.6.13.90
[03:28] <fabbione> hmmm oh yeah
[03:28] <fabbione> sorry.. that's right
[03:28] <BenC> ok
[03:29] <fabbione> just be sure that other than source, there is nothing that shows up as 2.6.14
[03:29] <BenC> actually going to do .92 for -rc2, .93 for -rc3, etc
[03:29] <BenC> right
[03:29] <fabbione> otherwise people will harass you badly
[03:30] <fabbione> BenC: it's a good idea after you branch, to do baz cachereb
[03:30] <fabbione> meh
[03:30] <fabbione> cacherev
[03:30] <fabbione> otherwise it takes ages to switch/checkout
[03:31] <BenC> does changelog Closes entries actually close bugzilla bugs?
[03:32] <fabbione> nope
[03:32] <fabbione> bugzilla does nothing
[03:33] <BenC> ok, it's uploaded, I had to get it quickly so Kamion wasn't holding off Colony 5 forever
[03:34] <fabbione> ah ok
[03:34] <fabbione> well than i won't bother to build
[03:34] <fabbione> we will see what the buildd will say
[03:35] <fabbione> if it breaks, you better get ready to upload again :)
[03:35] <zul> meh...i have to fix that audigy bug
[03:35] <BenC> for some reason, I knew I was going to have to do a 9.15 today
[03:35] <fabbione> zul: what bug?
[03:35] <fabbione> i have a audigy here...
[03:36] <fabbione> BenC: it's always like this ..
[03:36] <fabbione> specially when you approach release
[03:36] <zul> fabbione: some pci ids were removed from the audigy driver in 2.6.12 they are back in 2.6.13
[03:37] <fabbione> zul: ENOCARE :) works for m
[03:37] <fabbione> +e
[03:37] <fabbione> including remote control
[03:37] <zul> and my boss uses audigy on his computer at home and he knows im on the kernel team
[03:37] <zul> blah..
[03:38] <fabbione> zul: tsk :P
[03:38] <fabbione> tell your boss to buy a better card
[03:38] <BenC> everyone that's on the "kernel team" needs to add themselves to the KernelTeam wiki page so I know who you all are :P
[03:38] <zul> i did :)
[03:38] <fabbione> BenC: he is on the kernel team
[03:38] <fabbione> speaking of which
[03:39] <fabbione> we need to clean it up a bit
[03:39] <BenC> I did a little
[03:39] <fabbione> can you remind me the URL?
[03:39] <BenC> I don't see any names on the KernelTeam page other than fabbione and myself
[03:39] <BenC> wiki.u.c/KernelTeam
[03:40] <fabbione> that's right...
[03:40] <fabbione> soon to be only yoouuuUUUUU
[03:40] <fabbione> but WTF
[03:40] <fabbione> we had a completely different page
[03:41] <fabbione> with a lot of links and shit
[03:41] <fabbione> where did it all go?
[03:41] <BenC> there's a diff URL in the topic
[03:41] <BenC> http://www.ubuntulinux.org/wiki/KernelTeam
[03:41] <BenC> I didn't see that one
[03:41] <BenC> same page
[03:41] <BenC> that's the way I found it
[03:42] <BenC> only thing I changed was s/fabio/ben/
[03:42] <fabbione> yeah i know
[03:42] <fabbione> it must have been when the wikis fetish BDSM guys did move to YET another WIKI
[03:42] <fabbione> we had all the policy and crap
[03:43] <BenC> http://udu.wiki.ubuntu.com/LinuxKernelRoadmap
[03:43] <BenC> there's that too
[03:43] <fabbione> yeah that's the specs from UDU
[03:44] <fabbione> https://wiki.ubuntu.com/KernelTeamTasks?highlight=%28kernel%29 <-
[03:44] <fabbione> just search for kernel
[03:44] <fabbione> it will spit out shit
[03:45] <BenC> ok
[03:45] <BenC> need to get all those links in the KernelTeam page
[03:45] <BenC> KernelTeam is supposed to be the main page, right?
[03:45] <fabbione> they were there :/
[03:45] <fabbione> yes
[03:45] <BenC> ok
[03:46] <fabbione> if you can, try to kill the links on how to build custom kernels
[03:46] <BenC> hopefully with 9.15 out, and Colony 5 building, I can take some time to do that
[03:46] <fabbione> ehehe
[03:46] <fabbione> it can wait after Breezy
[03:46] <fabbione> so we might be able to assimilate more people
[03:46] <BenC> I got a lot of stuff I need to document, so I don't lose/forget it
[03:46] <BenC> the whole ABI-changing-upload
[03:47] <BenC> do I still need to do klibc?
[03:47] <fabbione> jbailey is looking at it
[03:47] <BenC> ok
[03:47] <fabbione> klibc is not extremely important
[03:47] <fabbione> because an ABI change doesn't break it
[03:47] <fabbione> or purge it
[03:47] <BenC> d-i, linux-meta, and lrm should be done
[03:47] <fabbione> it makes klibc unbuildable
[03:47] <fabbione> yeah it's all done i think
[03:48] <BenC> btw, auric's been chugging away at packages
[03:48] <BenC> I think sparc is safe from the arch-police for etch
[03:48] <fabbione> afaik sparc is going to be SCC because the installer didn't get any love in sarge
[03:49] <BenC> SCC?
[03:49] <BenC> the installer worked great for me from sarge
[03:49] <fabbione> BenC: Secondary Crappy arCh
[03:49] <jbailey> Eh?  Sparc was working when I beat on it last year.
[03:49] <BenC> I did the auric install with a sarge tftp image
[03:49] <fabbione> that's what i was told
[03:49] <fabbione> so..
[03:49] <fabbione> relax :)
[03:49] <fabbione> BenC: if we can get your machine to build breezy in a serious way
[03:50] <BenC> I think if sparc32 gets dropped, things will be a lot better
[03:50] <BenC> we can't keep feeling sorry for the sun4c folks
[03:50] <fabbione> than i can dedicate my sparc for testing
[03:50] <jbailey> Already done for breezy. =)
[03:50] <fabbione> breezy doesn't support sparc32
[03:50] <BenC> yeah, debian needs to do the same
[03:50] <fabbione> BenC: you said you have like 6 CPU/6GB of RAM
[03:50] <BenC> netbsd runs so much better on the sparc32 hardware anyway
[03:50] <fabbione> that could run but it self 5 instances of buildd :)
[03:51] <jbailey> That was at the advice of the aurora and the slackware for sparc or wahtever they're called.
[03:51] <BenC> fabbione: yep, it can do some serious damage to a build list
[03:52] <BenC> anyone ever looked at taking advantage of smp on larger packages?
[03:52] <BenC> mozilla, openoffice, kernel, X, gnome, kde, etc.
[03:52] <jbailey> It's hard to do predictable in a generic way.
[03:52] <BenC> gcc too
[03:52] <jbailey> glibc does it.
[03:53] <fabbione> kernel does
[03:53] <BenC> yeah, I saw that the kernel does
[03:53] <fabbione> X can't
[03:53] <jbailey> Even with autoconf?
[03:53] <fabbione> and there is no need anymore anyway
[03:53] <jbailey> It ought to be able to.
[03:53] <BenC> I know my e3k can -j a kernel build in like 5 minutes or less
[03:53] <fabbione> jbailey: it's splitted in 3M pkgs..
[03:53] <jbailey> BenC: Is that with or without ccache
[03:53] <jbailey> ?
[03:53] <fabbione> BenC: eheheh
[03:53] <BenC> without
[03:53] <jbailey> sweet
[03:53] <fabbione> ehehe
[03:53] <fabbione> with ccache is going to fly
[03:54] <fabbione> and if you are cool with the setup, with shared ccache between chroots it flies even more :)
[03:54] <BenC> how hard is that to setup
[03:54] <jbailey> trivial
[03:54] <jbailey> install ccache
[03:54] <fabbione> easy
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:57 cc -> /usr/bin/ccache
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 g++ -> /usr/bin/ccache
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 g++-3.3 -> /usr/bin/ccache
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 g++-3.4 -> /usr/bin/ccache
[03:55] <BenC> nice
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 g++-4.0 -> /usr/bin/ccache
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 gcc -> /usr/bin/ccache
[03:55] <fabbione> BenC: when you are ready to do it, i will give you the chroots ready for you
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 gcc-3.3 -> /usr/bin/ccache
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 gcc-3.4 -> /usr/bin/ccache
[03:55] <fabbione> BenC: with all the setup and stuff
[03:55] <jbailey> lrwxrwxrwx   1 jbailey jbailey   15 2005-05-16 17:52 gcc-4.0 -> /usr/bin/ccache
[03:55] <jbailey> Do that in ~/bin
[03:55] <jbailey> Add it to your path.
[03:55] <fabbione> BenC: you will only need to allocate space that can be bind mounted
[03:55] <fabbione> jbailey: there are much easier way than that
[03:56] <fabbione> if [ -d /usr/lib/ccache ] ; then
[03:56] <fabbione>    export PATH=/usr/lib/ccache:"${PATH}"
[03:56] <fabbione>     export CCACHE_DIR=/usr/src/.ccache
[03:56] <fabbione>     export CCACHE_NLEVELS=8
[03:57] <fabbione>     if [ -n "$(which distcc)" ] ; then
[03:57] <fabbione>         export CCACHE_PREFIX="distcc"
[03:57] <fabbione>         export DISTCC_HOSTS="localhost foo bar"
[03:57] <fabbione>     fi
[03:57] <fabbione> fi
[03:57] <fabbione> no symlinks
[03:57] <fabbione> no mess
[03:57] <fabbione> and ready for distcc :)
[03:59] <jbailey> debuild won't see that, I don't think will it?
[03:59] <fabbione> it does
[04:03] <infinity> Yeah, /usr/lib/ccache is love.  elmo pointed it out to me the other day, and I felt dumb for having created the links manually.
[04:11] <Yagisan> nice
[04:25] <BenC> great, the sk98lin driver is failing to build at all, has nothing to do with the arch
[04:27] <mjg59> BenC: Hmm. My patch appeared to build here.
[04:28] <mjg59> BenC: It's missing the -I statement pointing it at its includes
[04:30] <BenC> got it
[04:30] <BenC> it still had -Ia/drivers
[04:30] <BenC> no idea why
[04:38] <BenC> wow, that's broken
[04:38] <infinity> Do I smell ANOTHER upload?
[04:39] <BenC> fabbione: the sparc64 breezy tftp image told me that I didn't have a ethernet interface, but that I _did_ have a firewire device :)
[04:39] <BenC> which is odd considering that I have no PCI on this e3k :)
[04:40] <BenC> but I do have a happymeal card
[04:40] <fabbione> BenC: no idea.. 
[04:40] <fabbione> i didn't test breezy installer at all
[04:40] <fabbione> but all the modules should be there
[04:40] <BenC> yeah, I loaded it manually
[04:41] <fabbione> BenC: for me the breezy installer is completely untested
[04:41] <fabbione> so it might fry stuff
[04:41] <fabbione> be aware
[04:41] <BenC> ok
[04:41] <fabbione> if it works is a plus :)
[04:43] <BenC> is the smp kernel for sparc64 tested well?
[04:43] <fabbione> we did test it only on one machine
[04:43] <BenC> the breezy installer must be using the broken version of libdetect
[04:43] <fabbione> i don't have SMP here
[04:43] <BenC> it's not seeing my sbus devices
[04:44] <BenC> that bug was in debian too, but it got fixed
[04:44] <fabbione> it depends when it got fixed
[04:44] <BenC> libdetect ignores > 1 sbus buses
[04:44] <BenC> was awhile ago
[04:44] <fabbione> we should compare the versions
[04:44] <BenC> like 3-6 months
[04:44] <fabbione> if the fix is not in and it's not intrusive, we might be able to push it
[04:44] <BenC> I'm having to manully load hme and esp modules
[04:45] <fabbione> i see
[04:45] <fabbione> annoying
[04:45] <BenC> it only affects machines like mine that have things on other than sbus0
[04:45] <fabbione> i guess that problem is only in the installer, right?
[04:46] <fabbione> BenC: anyway i need to stop for one hour or so
[04:46] <fabbione> my brain is melting
[04:46] <BenC> well, if it uses detect for initramfs, then it will be there too
[04:46] <fabbione> no it doesn't
[04:46] <fabbione> afaik at least
[04:46] <fabbione> jbailey: ???
[04:46] <fabbione> i need to stop for a while
[04:46] <fabbione> bbl
[04:49] <jbailey> libdetect?
[04:49] <jbailey> What's that?
[04:50] <jbailey> Ubuntu's d-i uses hotplug / udev
[04:50] <BenC> what does it uses to scan the sbus on sparc?
[04:51] <jbailey> No idea, I don't think hotplug has magic for that.
[04:51] <BenC> somehow it needs to I guess
[04:51] <jbailey> Is the sbus driver sysfs enabled?
[04:52] <jbailey> I could add that to initramfs-tools at least.
[04:52] <BenC> the debian installer handles it somehow
[04:52] <BenC> yes, it is
[04:52] <jbailey> Debian's installer uses discover1
[04:52] <BenC> discover, that's what I meant, not detect
[04:52] <jbailey> Ah. 'k
[04:53] <jbailey> I've just asked Colin to double check.
[05:05] <jbailey> Yep.  discover is only used for X autoconfiguration.
[05:05] <jbailey> So possibly nothign does sbus detection at all.
[05:06] <jbailey> Cookingup hotplug patches for sbus isn't hard, but I don't know that it could be done for breezy.
[05:06] <jbailey> Best bet might be to do a plugin on sparc only.
[05:06] <jbailey> If you can get a machine installed with Breezy (or if I can this weekend now that I have a nullmodem cable)
[05:07] <jbailey> I can get the hack in for initramfs-tools to do any detection you need there.
[05:10] <BenC> something on debian loads hme(ethernet) and esp(scsi) modules
[05:10] <BenC> I don't know what it is
[05:11] <spayne> i'm back to discuss my ndiswrapper problem :_
[05:11] <spayne> i'm back to discuss my ndiswrapper problem :)
[05:13] <jbailey> Heya spayne, mkrufky 
[05:31] <fabbione> re
[05:31] <fabbione> BenC: how is the installation going?
[05:31] <fabbione> BenC: i am pretty sure you can manage to install ubuntu-standard
[05:31] <fabbione> but not ubuntu-desktop
[05:31] <spayne> BenC: ping
[05:33] <BenC> well, it's headless, so desktop isn't needed anyway
[05:33] <BenC> spayne: ?
[05:33] <fabbione> BenC: yeah so it's mine, but i still test full installability :)
[05:34] <spayne> BenC: can you talk about the ndiswrapper problem and see if it can be traced to something?
[05:34] <fabbione> BenC: there is one package too much in ubuntu-desktop Depends: that makes it fail
[05:34] <BenC> fabbione: I read that as "instability" :)
[05:34] <BenC> spayne: sure, refresh me on what the issue is
[05:35] <fabbione> BenC: lol :)
[05:35] <fabbione> i think i will just build it manually and get over it
[05:35] <fabbione> buildd is choaking on hoary-security
[05:37] <spayne> BenC: right, the bug related is http://bugzilla.ubuntu.com/show_bug.cgi?id=14147
[05:37] <spayne> BenC: when i have installed and loaded up ndiswrapper, the kernel module isn't being loaded
[05:37] <spayne> it is weird
[05:38] <spayne> because if the device is plugged in (it is USB), the system hangs on 'Loading Modules' and/or 'Starting Hotplug'
[05:38] <BenC> ndiswrapper isn't loaded, or some other module
[05:38] <spayne> and when i remove the device
[05:38] <spayne> i get this error
[05:38] <spayne> Sep 22 21:21:14 amarillo kernel: [4294699.242000]  ndiswrapper
[05:38] <spayne> (usb_reset_port:633): usb_reset_device() = -19
[05:38] <spayne> Sep 22 21:21:14 amarillo kernel: [4294699.242000]  ndiswrapper
[05:38] <spayne> (usb_reset_port:633): usb_reset_device() = -22
[05:38] <spayne> Sep 22 21:21:14 amarillo kernel: [4294699.242000]  ndiswrapper
[05:38] <spayne> (ndiswrapper_add_one_usb_dev:312): Windows driver couldn't initialize the device
[05:38] <spayne> (C0000001)
[05:38] <spayne> Sep 22 21:21:14 amarillo kernel: [4294699.242000]  ndiswrapper: probe of 3-3:1.0
[05:38] <spayne> failed with error -22
[05:39] <spayne> which makes me think it is a USB problem
[05:40] <BenC> -22 == -EINVAL
[05:40] <spayne> what?
[05:40] <BenC> that's the error code it is returning
[05:40] <BenC> no idea what EINVAL means in this case
[05:41] <BenC> does it work under windows or any other linux dist
[05:41] <BenC> ?
[05:41] <spayne> yes
[05:41] <spayne> all other distros
[05:41] <spayne> be it suse, fedora
[05:41] <spayne> it works fine
[05:41] <spayne> SUSE 10 works the best and that has a 2.6.13 kernel
[05:41] <BenC> what version of the ndiswrapper module?
[05:42] <spayne> 1.1 - the standard one
[05:43] <BenC> is that the same version as in suse?
[05:44] <spayne> no
[05:44] <BenC> what version is in suse
[05:44] <spayne> give me a mo
[05:45] <spayne> 1.2-2
[05:45] <mjg59> We can't upgrade ndiswrapper at this point
[05:45] <spayne> why?
[05:45] <spayne> also, it works fine on my Dell laptop with a MiniPCI card
[05:45] <mjg59> Because userspace needs to be kept in synchronisation with the kernel, and we're deep into freeze
[05:46] <infinity> BenC --
[05:46] <infinity> applying patch external-drivers-net-sk98lin to ./ ... failed.
[05:46] <infinity> make[1] : *** [debian/monolith/patch-2.6.12-9.17]  Error 1
[05:46] <infinity> \o/
[05:46] <BenC> mjg59: that's your patch failing to apply :)
[05:46] <BenC> neither of the sk98lin patches is working
[05:46] <fabbione> hmmm
[05:47] <fabbione> ok let's stop and focus one second...
[05:47] <BenC> zul's fails to build with some errors in skge.c
[05:47] <fabbione> we can't keep uploading this way
[05:47] <BenC> I'm done uploading
[05:47] <BenC> Kamion is going with 9.14 for Colony 5
[05:47] <fabbione> did you upload .18 ?
[05:47] <fabbione> ok
[05:47] <BenC> sk98lin will be an errata
[05:47] <dilinger> i really don't think it's ndiswrapper
[05:47] <mjg59> BenC: There's a one character fix to zul's patch
[05:48] <dilinger> since it hangs during init when ndiswrapper isn't even loaded
[05:48] <spayne> dilinger: i thought it might be the USB Stack
[05:48] <spayne> dilinger: hi btw
[05:48] <dilinger> hello
[05:48] <spayne> did you get anything from the kernel log?
[05:49] <infinity> hey dilinger.
[05:50] <BenC> fabbione: btw, after adding esp and sunhme to /etc/mkinitramfs/modules and dpkg-reconfigure, my e3k is booting ubuntu
[05:50] <fabbione> COOL
[05:50] <fabbione> hey dilinger 
[05:50] <fabbione> BenC: i am talking with Kamion already to fix it (as jbailey did too)
[05:51] <fabbione> so i think we can get it fixed for breezy
[05:52] <dilinger> spayne: i haven't checked the bug report, i should probably add myself to the cc list or something
[05:52] <spayne> dilinger: I pasted the kernel log which gave some interesting errors http://bugzilla.ubuntu.com/show_bug.cgi?id=14147
[05:54] <BenC> Linux zachery 2.6.12-9-sparc64 #1 Fri Sep 23 01:07:46 UTC 2005 sparc64 GNU/Linux
[05:54] <BenC> time to test smp :)
[05:54] <fabbione> BenC: yuo
[05:54] <zul> fabbione: its cum...:)
[05:55] <BenC> mjg59: what is the fix for zul's patch?
[05:55] <zul> gets ndiswrapper working for amd64
[05:55] <zul> i believe..
[05:55] <spayne> it doesn't even work on i386
[05:55] <spayne> never mind amd64!
[05:56] <mjg59> BenC: Just remove the a/
[05:56] <mjg59> From the EXTRA_CFLAGS statement
[05:56] <BenC> mjg59: already tried that
[05:56] <mjg59> BenC: Oh, christ, Dunno, then.
[05:56] <mjg59> spayne: It works fine on i386
[05:56] <mjg59> It doesn't work *for you*
[05:56] <BenC> it still fails in skge.c because of some weird errors
[05:56] <mjg59> BenC: Shrug.
[05:56] <spayne> mjg59: it does work on some machines, not USB devices
[05:57] <spayne> does anyone have any ideas?
[05:57] <mjg59> BenC: The patch I sent applied fine here (working against an older tree, obviously) and built
[05:57] <mjg59> BenC: My suspicion is that it's failing to patch because you've dropped sky2, and so there's a different hunk in Kconfig
[05:57] <mjg59> Or the Makefile
[05:57] <fabbione> spayne: buy better hw that doesn't need crappy windowss dll? ;)
[05:58] <spayne> fabbione: that is not the answer - i have had this bug for 2 months
[05:58] <spayne> and every time i try and get help, nothing happens
[05:58] <dilinger> what's recommended for controlling cpufreq from userspace?  cpudyn?  powernowd?
[05:58] <mjg59> We ship powernowd
[05:59] <dilinger> alright, thanks.  i'll play around w/ that one
[05:59] <mjg59> spayne: Frankly, ndiswrapper for USB stuff is a low priority
[05:59] <spayne> really? so people who use Ubuntu with Laptops (cough)Laptop Testing Scheme(cough) can't do anything?
[05:59] <fabbione> spayne: because these kind of drivers are extremely hard to support.
[05:59] <spayne> it isn't a driver problem!
[06:00] <fabbione> given that if they fail in the .dll crap, there is no way we can get it fixed
[06:00] <mjg59> spayne: People with USB devices are always at liberty to get one that has native Linux drivers
[06:00] <spayne> it is nearly impossible
[06:00] <mjg59> spayne: That's *not* true of most of the problems we're dealing with here
[06:00] <mjg59> spayne: No, it really isn't
[06:00] <spayne> why did it work with Hoary then?
[06:00] <mjg59> There are several supported USB wireless devices
[06:00] <mjg59> I've *no fucking clue*
[06:00] <BenC> spayne: one issue is that it is nearly impossible for us to really do anything about it
[06:00] <BenC> I cannot reproduce it
[06:00] <fabbione> spayne: luck
[06:01] <spayne> luck?
[06:01] <fabbione> that's probably why it did work
[06:01] <mjg59> spayne: And maybe I'll have time to look at it once I'm finished dealing with the higher priority issues
[06:01] <BenC> spayne: can you try hand building the newest ndiswrapper and see if that works?
[06:01] <spayne> will do
[06:01] <mjg59> spayne: The USB devices that *Maplin* sell are supported, for christ's sake
[06:02] <spayne> that isn't the point, they point is that ndiswrapper is broken for some USB devices
[06:02] <mjg59> Right. And that's a bug.
[06:02] <mjg59> It's a low priority bug,
[06:02] <fabbione> spayne: there is always something broken for somebody
[06:02] <spayne> i thought one of the aims for Breezy was that any laptop would just work :)
[06:02] <fabbione> spayne: do you have a patch to fix the problem?
[06:02] <mjg59> spayne: The aim is to support as much as we can. If I have time, I will see if I can reproduce the problem.
[06:02] <spayne> that's fine
[06:03] <spayne> thanks mjg59
[06:03] <BenC> spayne: it may not even be an ndiswrapper bug, it sounds to me like ndiswrapper isn't able to communicate with the USB device, which could be a USB stack bug
[06:03] <spayne> yes, but who do i contact?
[06:03] <BenC> spayne: I'm hoping that trying a different ndiswrapper version will tell us if this is the case
[06:04] <spayne> i just came here because the bug was assigned to you
[06:04] <fabbione> spayne: you did open the bug. that's enough
[06:04] <BenC> you talk to me, but all I can tell you right now is that the ball is largely in your court, because this is such a specialized problem
[06:04] <fabbione> spayne: coming around to push developer is of no help
[06:05] <BenC> spayne: if this were "ndiswrapper is broken for 99% of the people", I'd get right on it
[06:05] <BenC> but as it is now, it's just you, and I've no confirmations that it is affecting anyone else
[06:05] <spayne> fair enough
[06:05] <BenC> not saying you aren't important, but I have to get the bugs that affect the most people first :)
[06:06] <BenC>  * Starting hotplug subsystem...
[06:06] <BenC> fabbione: smp kernel stops there
[06:07] <BenC> hard lock, have to powercycle
[06:07] <fabbione> crap
[06:07] <BenC> odd that there is no kernel output
[06:07] <fabbione> can you try to boot without quiet/splash options?
[06:07] <fabbione> i don't think they get added on sparc
[06:07] <BenC> this thing is far from quiet
[06:08] <fabbione> so you get full boot log
[06:08] <BenC> yeah
[06:08] <fabbione> christing bananas
[06:08] <fabbione> hmm i wonder if you try to boot UP and disable hotplug and see if it boots -SMP
[06:09] <BenC> I can try
[06:09] <BenC> update-rc.d -f hotplug remove ?
[06:09] <fabbione> than try to load hotplug manually and perhaps you can get something out
[06:09] <fabbione> i would just add an exit 0 at the beginning of the script :)
[06:09] <BenC> if I boot to single, is that before hotplgu?
[06:09] <fabbione> hmm i think so
[06:09] <fabbione> i can't remember
[06:09] <BenC> I'll try that first
[06:09] <BenC> sucks, hard power cycles on this machine takes 8 minutes
[06:10] <fabbione> ehehe i know :)
[06:10] <BenC> as opposed to the 2 minutes for a soft reset
[06:10] <fabbione> the E10K was like 45 minutes
[06:10] <fabbione> just powering down the domain
[06:10] <fabbione> and powering it up again
[06:10] <BenC> the POST on sparc's is just too damn thorough
[06:10] <fabbione> better that way
[06:11] <fabbione> but later i found a trick...
[06:11] <BenC> yeah, it's why sparc's are so good :)
[06:11] <BenC> please tell me :)
[06:11] <fabbione> does the e3k supports hw partitioning?
[06:11] <fabbione> like having 2/3 execution domains..
[06:12] <BenC> no
[06:12] <BenC> only starfire hardware can do that
[06:13] <BenC> IIRC, a 32way e10k can compile a kernel in 28 seconds flat
[06:13] <fabbione> ok
[06:13] <fabbione> yeah...
[06:13] <fabbione> i know :)
[06:13] <fabbione> too bad i don't have access to it anymore
[06:14] <fabbione> otherwise we would be building dapper already
[06:14] <BenC> woulda made a nice buildd :)
[06:14] <BenC> I've got two bad simms on this e3k
[06:14] <fabbione> yeah
[06:14] <BenC> kills a gig of my memory
[06:15] <BenC> maybe just need to reseat them
[06:15] <fabbione> i didn't want to install a buildd there, because i knew i was going away
[06:17] <BenC> mjg59: your patch fails to apply 1 hunk to skge.c
[06:17] <fabbione> it's years that's broken and i can't find 400USD to get it fixed
[06:17] <BenC> a very large hunk
[06:17] <fabbione> but with that amount i could just buy another one
[06:17] <BenC> what's broken?
[06:19] <fabbione> either the mobo or the CPU
[06:20] <fabbione> but for that money i can just buy another full U60
[06:20] <BenC> guessing it isn't a dual cpu
[06:20] <fabbione> e merge them into one
[06:20] <fabbione> no it's not
[06:21] <BenC> weird
[06:21] <BenC> it booted this time
[06:22] <fabbione> ah
[06:22] <fabbione> well sorry that's a problem with your e3k
[06:22] <fabbione> she isn't used to such a cool kernel
[06:22] <BenC> lol
[06:22] <BenC> Linux zachery 2.6.12-9-sparc64-smp #1 SMP Fri Sep 23 01:36:07 UTC 2005 sparc64 GNU/Linux
[06:22] <fabbione> show me /proc/cpuinfo :)
[06:23] <BenC> even crappier, only 4 cpus active
[06:23] <BenC> cpu             : TI UltraSparc II  (BlackBird)
[06:23] <BenC> fpu             : UltraSparc II integrated FPU
[06:23] <BenC> promlib         : Version 3 Revision 2
[06:23] <BenC> prom            : 3.2.29
[06:23] <BenC> type            : sun4u
[06:23] <BenC> ncpus probed    : 4
[06:23] <BenC> ncpus active    : 4
[06:23] <BenC> need to reseat that whole cpu/mem board
[06:23] <fabbione> doh
[06:23] <fabbione> that could probably be the reason why it failed before?
[06:24] <BenC> well it got as far as userspace
[06:24] <fabbione> i don't recall that the kernel needs any special config option to support more than 4cpus
[06:24] <fabbione> not on sparc at least
[06:24] <BenC> it would just not boot to userspace at all if there was a problem with that
[06:25] <BenC> might have been that the cpu's went offline while it was booting
[06:25] <BenC> at the power cycle left them that way
[06:25] <fabbione> hmm crack
[06:35] <jbailey> mjg59: err.  You there? =)
[06:41] <mjg59> jbailey: HI
[06:41] <mjg59> Uh
[06:41] <mjg59> Hi
[06:41] <infinity> Argh.
[06:42] <infinity> Alright, who broke my vesafb?
[06:43] <jbailey> mjg59: Are you using bzr or apt-get source to fetch initramfs-tools when you hacked it?
[06:44] <infinity> jbailey : Do I blame you or the kernel for this one?
[06:44] <jbailey> infinity: No habla inglis Seor.
[06:44] <jbailey> Try de gringo over 'dere.
[06:44] <infinity> jbailey : After the kernel update, vga=xxx on the command line leaves me with blank/unuseable VTs, and vesafb doesn't seem to be loaded at all.
[06:44] <infinity> \o/
[06:44] <BenC> infinity: I saw a similar bug report
[06:44] <jbailey> infinity: When was the last initramfs-tools you updated?
[06:45] <BenC> nothing should have messed with that though
[06:45] <jbailey> Or rather the last initramfs-tools that you used in your previous thing?
[06:45] <jbailey> I found a rather amusing bug.
[06:45] <jbailey> Like none of the initramfs-tools hook scripts are marked executable.
[06:45] <jbailey> It's a wonder it boots at alll...
[06:45] <mjg59> jbailey: bzr
[06:45] <infinity> -rw-r--r--   1 root root 1262680 2005-09-16 08:53 vmlinuz-2.6.12-8-686
[06:45] <infinity> -rw-r--r--   1 root root 1262749 2005-09-23 07:53 vmlinuz-2.6.12-9-686
[06:45] <jbailey> mjg59: Right.  Time to lean on them a bit more about preserving the chmod +x bit. =)
[06:46] <infinity> So, -8- was probably generated with 0.26... -9- was generated with 0.28
[06:48] <infinity> jbailey : So, if I just chmod +x /usr/share/initramfs-tools/hooks/* and regenrate, you say this may resolve my problem? :)
[06:49] <jbailey> infinity: It may.
[06:49] <jbailey> It seems to have fixed this other guy's bootup speed problems.
[06:53] <infinity> jbailey : You win.  I have a console again.
[06:53] <infinity> Now I get chatty junk from the ide driver that I've never seen before
[06:53] <infinity> [4294672.679000]  ide0: I/O resource 0x1F0-0x1F7 not free.
[06:53] <infinity> [4294672.679000]  ide0: ports already in use, skipping probe
[06:53] <infinity> [4294672.679000]  ide1: I/O resource 0x170-0x177 not free.
[06:53] <infinity> [4294672.679000]  ide1: ports already in use, skipping probe
[06:53] <infinity> But at least I have a console. :)
[06:55] <zul> BenC: got a question for you..
[06:55] <BenC> zul: shoot
[06:56] <zul> large chunks were removed from emu101k in 2.6.12 but were put back into 2.6.13, should I backport everything 2.6.13 into our 2.6.12 or how would you handle it?
[06:57] <BenC> I'm not so sure it will get into breezy, so might aswell just leave it, since 2.6.14 will have it
[06:57] <zul> ok
[06:58] <mkrufky> there's a bunch of stuff that was removed right before 2.6.12 was released for stability purposes... most of those haven't been fixed until 2.6.14
[06:58] <infinity> Yeah, who has SBLive/Audigy cards anyway?
[06:58] <zul> my boss for one
[06:59] <mkrufky> heh
[06:59] <mkrufky> there was some debate about whether or not to support those cards
[06:59] <mkrufky> because they have some features that cannot be supported at this point in time
[06:59] <mkrufky> and those features happen to be the major selling-points of those cards
[07:00] <mkrufky> but since basic support worked, they ended up being included (more recently)
[07:14] <BenC> mjg59: your sk98lin patch is compiling now, it was conflicting order with an acpi update that touched skge.c
[07:14] <mjg59> Ok
[07:15] <BenC> your patch just removed all the stuff that patch put in, so I killed the skge.c edits in there, and rediffed your patch
[07:15] <mjg59> Hrm?
[07:15] <mjg59> My patch shouldn't have been touching skge
[07:15] <BenC> acpi added suspend/resume
[07:15] <BenC> sk98lin/skge.c
[07:15] <mjg59> Unless you mean the one in sk98lin/skge.c ?
[07:15] <mjg59> Ah, right
[07:15] <mjg59> Ok
[07:46] <BenC> ncpus probed    : 6
[07:46] <BenC> ncpus active    : 6
[07:47] <BenC> much better
[07:56] <fabbione> BenC: cool. i started uploading the chroot.. it will take a while.. i am gonna send you an email with the details when it's done
[07:56] <fabbione> s/d$/r
[08:01] <BenC> ok
[08:26] <BenC> is there something with the arch/bzr style revision control model that says we can't use head (kernel-debian--mainline--2.6.12) for our main development area, and just branch tags for each release?
[08:28] <dilinger> grumble.  hoary's lm-sensors detect all kinds of false alarms on these shitty asus boards
[08:44] <infinity> BenC : No, and I'd prefer it.  Different people have different workflows, that's all.
[08:44] <BenC> you'd prefer just having a single head?
[08:45] <infinity> Yeah, that works better for me.  But I'm probably just too CVS/SVN oriented, and therefor not cool enough for baz. :)
[08:45] <BenC> I must not be cool either :)
[08:45] <BenC> I think I might go with that
[08:46] <BenC> as it is now, we have two branches for each release, the dev branch, and the tag
[08:46] <infinity> Hey, it's your kernel now, bugs and all.  YOu get to force whatever model you want on your minions.
[08:46] <BenC> and I don't think baz is zero overhead for a non-changes branch
[08:46] <infinity> I'm more likely to contribute if I'm more comfortable with the development model, mind. :)
[08:48] <zul> im not a minion im a free dude
[08:49] <infinity> MINION!
[08:49] <zul> NO!
[08:49] <infinity> SUBMIT!
[08:51] <BenC> is there a way to remove a wiki page?
[08:51] <infinity> Probably, but I'm not wiki-friendly.
[08:51] <infinity> Another area where I lack cool.
[08:52] <infinity> Erm, wait.
[08:52] <jbailey> BenC: baz is the suck.  You can use bzr.  It's quick.  It's snazzy.  It's also not terribly sharable and doesn't have centralised commit, but hey.. =)
[08:52] <infinity> It's right there in the drop down "More Actions" box.
[08:52] <infinity> Last option: "Delete Page"
[08:52] <infinity> (If you don't have that box, or that option, you're probably not logged in)
[08:53] <infinity> I'd suggest we move the kernel to SVN, but then I'd get fired.
[08:53] <infinity> So I didn't suggest it.
[08:53] <infinity> Shhhh.
[08:57] <zul> NEVER!
[09:02] <zul> meh...i dont want to learn another version control system
[09:03] <BenC> svn is so easy though
[09:04] <BenC> what was the fix for the blank console with vga=XXX?
[09:11] <infinity> BenC : Upgrade to jbailey's latest initramfs-tools crack and remake your initrd.
[09:11] <infinity> (or chmod +x /usr/share/initramfs-tools/hooks/* and regenerate)
[09:16] <BenC> jbailey: 16118 is initramfs bug then?
[09:17] <zul> BenC: meh...its your call :)
[09:17] <jbailey> No idea.  What does vga=791 do?
[09:18] <infinity> Big, pretty vesafb console.
[09:18] <infinity> And yes, 16118 is the exact bug I had earlier.
[09:18] <infinity> Fix it with one of the two above methods.
[09:19] <infinity> Shall I post an update?
[09:20] <BenC> zul: i'd never switch to svn for the kernel
[09:20] <BenC> infinity: yea, please
[09:21] <zul> BenC: *shrug* ;)
[09:22] <infinity> Done.
[09:27] <zul> i dont want to get into a pissing match over version control software
[09:29] <infinity> Not likely to be one. :)
[09:29] <infinity> baz is the canonical Canonical revision control system, so we use it.
[09:29] <zul> then again maybe i might :)
[09:29] <zul> infinity: i know 
[09:29] <infinity> bzr should suck a lot less when it's actually feature-complete.
[09:29] <infinity> Or, so I keep hearing.
[09:30] <infinity> And I'll continue to use SVN for non-work stuff, and just not tell anyone about it. :)
[09:30] <infinity> (Hey, SVN is the whole reason I started maintaining apache2...)
[09:43] <BenC> I use svn for everything I can
[09:55] <jbailey> infinity: bzr already sucks less for the use cases it covers.
[09:55] <jbailey> infinity: group development just isn't one of those use cases.
[10:21] <zul> later folks