[12:03] <mkrufky> so, deadline or no deadline........
=== spayne is training to become a MOTU as well!
[12:03] <mkrufky> MOTU ?
[12:03] <spayne> Universe Packager?
[12:03] <mkrufky> oh
[12:03] <crimsun> universe/multiverse maintainers
[12:04] <crimsun> see #ubuntu-motu
[12:04] <mkrufky> i'm what they call an "upstream guy"
[12:04] <crimsun> you're more than welcome to join, mkrufky
[12:04] <mkrufky> hmmm
[12:05] <mkrufky> until that last comment i was GOING to say, "heh..  i just like to write code.... i'll leave the packaging to you guys" .... but since u put it this way
[12:05] <mkrufky> maybe i might just have to investigate ;-)
[12:05] <mkrufky> crimsun: i dont think we've met yet, btw
[12:05] <crimsun> well the ideal situation is of course if the coder packages it, since (s)he can deal directly with bug reports ;-)
[12:05] <mkrufky> i am a maintainer of upstream v4l & dvb kernel subsystems
[12:06] <mkrufky> im not *THE* maintainer... just one of the few
[12:06] <crimsun> mkrufky, excellent. Pleased to meet you. I help out with ALSA in Ubuntu.
[12:06] <mkrufky> great
[12:06] <mkrufky> i told them i would help to backport newer code to their next kernel....
[12:07] <mkrufky> but i dont think this involves any packaging
[12:07] <crimsun> probably not, I think lamont and benc will handle that
[12:07] <mkrufky> but there's always new stuff to learn, and im always interested
[12:09] <mkrufky> anyway, its about that time to go home now... nice to meet u crimsun and spayne .... 
[12:09] <mkrufky> tty guys later... good luck
[12:09] <spayne> keep in touch :)
[12:09] <crimsun> thanks, cya 'round
[12:10] <mkrufky> :-)... i can always be found in both #v4l and #linuxtv ... (and usually here as well)
[12:10] <mkrufky> ttyl
=== mkrufky [n=mk@68.160.103.77]  has left #ubuntu-kernel [] 
[12:15] <spayne> BenC: ping me if you are back :)
[12:22] <lamont> mjg59: care to take a guess as to which acpi patch breaks ia64?
[12:22] <lamont> as in. most invasive patch, etc.
[12:24] <lamont> jbailey: any reason not to throw out initramfs for ia64 as well as hppa?
[12:36] <spayne> BenC: ?
[12:40] <jbailey> Throw out, like not use?
[12:40] <jbailey> The biggest reason is that those machines are then stuck with 2.6.12 until you get it working.
[12:41] <jbailey> So you're only buying yourself 2 weeks or so.
[01:10] <BenC> spayne?
=== mkrufky [n=mkrufky@user-12lcl1s.cable.mindspring.com]  has joined #ubuntu-kernel
[02:07] <BenC> anyone know why isapnp would be reserving memory that was reserved for a PCI device?
[02:08] <BenC> user has an 8139 that has 0xde00-0xdeff reserveed for I/O, and isapnp grabs 0xde00-0xde03 on bootup
[02:08] <BenC> if they boot with noisapnp, the device works ok
[02:08] <BenC> otherwise, it complains about not being able to reserve the io region
[02:11] <mkrufky> this may or may not help:
[02:11] <mkrufky> recently, on lkml, there was talk about pci memory allocation to the wrong memory area....
[02:12] <mkrufky> something to do with overwriting memory thats SUPPOSED to be reserved for the bios
[02:12] <mkrufky> i believe the talk was before 2.6.13 got rreleased, so i dont know if its related or not
[02:12] <mkrufky> but i remember that it was GregKH that was talking about it.... you may want to search lkml
[02:13] <mkrufky> i know that isnt the exact situation that you're describing, but it COULD be related
[02:13] <jbailey> mjg59: Around?
=== calc [n=ccheney@ip70-185-4-246.ma.dl.cox.net]  has joined #ubuntu-kernel
[02:28] <BenC> mkrufky: well the same memory area is listed for 2.6.10 (where it's working) and 2.6.12 (where pnp grabs part of it)
[02:29] <BenC> the only difference is that in 2.6.12, isapnp beats 8139 to reserving the memory, even though /proc/ioports clearly knows that the memory region is for the PCI device
[02:29] <BenC> and lspci -v shows it too
[02:29] <mkrufky> hmm
[02:30] <BenC> 16371 if you want to look at it
[02:30] <BenC> I think isapnp is just broken in this case, unless the guys bios is setup wrong
[02:30] <mkrufky> i'll take a look... but i think this means that the bug *i* was talking about is probabl;y unrelated
[02:30] <mkrufky> ...sorry
[02:30] <BenC> yeah, sounds like it
[02:30] <BenC> no problem
[02:33] <mkrufky> hmm... he didnt include dmesg without noisapnp
[02:33] <mkrufky> oops... i see it
[02:35] <BenC> doesn't seem that isapnp was disabled like i thought it would be
[02:35] <BenC> 2.6.10 dmesg shows isapnp just not doing anything since there are no pnp devices
[02:35] <BenC> just the parallel port
[02:35] <BenC> at 0x378, like it should be
[02:35] <mkrufky> ya
[02:37] <mkrufky> hmmm... what a mess
[02:37] <BenC> maybe I need to disable pnpacpi
[02:38] <mkrufky> that could be something to try
[02:41] <mkrufky> hmmm.... it's not really clear what is going on in the inline dmesg output... i assumed that was 2.6.12 without the noisapnp
[02:42] <mkrufky> and then you said, "doesn't seem that isapnp was disabled like i thought it would be"
[02:42] <mkrufky> i assume that you're referring to:
[02:42] <mkrufky> [4294670.791000]  isapnp: Scanning for PnP cards...
[02:42] <mkrufky> [4294671.145000]  isapnp: No Plug & Play device found
[02:43] <BenC> that's 2.6.10
[02:43] <mkrufky> ah
[02:43] <mkrufky> so does he show us 2.6.12 nywhere?
[02:43] <BenC> there's a 2.6.12 inline, original, and a 2.6.12 with isapnp (attachment)
[02:43] <BenC> ...
[02:43] <mkrufky> looks like he is only showing 2.6.12 with noisapnp
[02:43] <BenC> "dmesg output whit noisapnp"
[02:44] <BenC> that's all we need
[02:44] <BenC> 2.6.10 works
[02:44] <BenC> 2.6.12 with noisapnp I meant
[02:44] <BenC> just asked him to try some other options
[02:44] <mkrufky> ok
=== TheMuso [n=luke@dsl-202-173-132-131.nsw.westnet.com.au]  has joined #ubuntu-kernel
[05:40] <fabbione> morning guys
=== crimsun [n=crimsun@pdpc/supporter/silver/crimsun]  has joined #ubuntu-kernel
=== JaneW [n=JaneW@wbs-146-181-185.telkomadsl.co.za]  has joined #ubuntu-kernel
=== Yagisan [n=jamie@60-240-35-96.tpgi.com.au]  has joined #ubuntu-kernel
=== Yagisa1 [n=jamie@60-241-38-168.tpgi.com.au]  has joined #ubuntu-kernel
=== spayne [n=spayne@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
[09:01] <spayne> mornin' all
[09:01] <spayne> BenC: ping
[09:06] <fabbione> spayne: BenC is asleep at this time
[09:08] <spayne> fabbione: where abouts is he?
[09:08] <fabbione> US
[09:09] <fabbione> so i guess he will be around in 6 hours + o -
[09:09] <spayne> fabbione: thanks
[09:09] <spayne> fabbione: i'm just darn excitied to get this bug squashed
[09:09] <spayne> :)
[09:17] <infinity> spayne : Which bug is that?
=== chmj [n=chmj@196.36.161.235]  has joined #ubuntu-kernel
[09:22] <spayne> the ndiswrapper one
[09:23] <infinity> Oh, dang.  I was hoping it would somehow relate to USB being goofy.
[09:24] <spayne> right, well
[09:25] <spayne> the newest version released yesterday (1.4rc1) fixes the bug as the whole USB layer has been rewrittrn to work better with the 2.6.12 kernel as well as fixing hundreds of bugs since 1.2
[09:25] <spayne> 1.3 was never released
[09:26] <spayne> so...
[09:26] <spayne> the solutions arer
[09:26] <spayne> a.) Do Nothing - Will cause problems when Breezy released as many others way have this sort of problem which is fixed in 1.4rc1
[09:27] <spayne> b.) Wait until 1.4 is released - This could be a week or just a few days
[09:27] <spayne> c.) Put it into the Kernel - not a good idea as it has had little testing and bugs will/may be found
[09:28] <spayne> d.) Make a Seperate Universe Packaging for 1.4 - This seems a good comprimise as this could be updated before Breezy is released with 1.4 final and means those who need it can use it
[09:28] <spayne> infinity: what do you think?
[09:33] <infinity> Hrm.  How would the seperate universe package work?... dpkg-divert the USB modules from the kernel?
[09:33] <infinity> Icky, but I guess it's not technically difficult.
[09:33] <spayne> a single package which will install both the modules and the utils
[09:33] <infinity> Right, but we also have USB module in the kernel package, so you'd need to divert those elsewhere.
[09:35] <Mithrandir> that'll be fun
[09:36] <spayne> well, what are your suggestions?
[09:41] <spayne> infinity: what would you do?
[09:42] <Mithrandir> diverting the modules will work, it's just ugly.
[09:43] <spayne> brb
[09:44] <infinity> Hey, if diverting modules works for lrm-nvidia-legacy (it diverts modules from lrm), it can work for this, too. :)
[09:44] <spayne> i wouldn't know where to begin
[09:44] <spayne> i'm JUST learning how to package from Debian :-)
[09:44] <spayne> s/Debian/Ubuntu
[09:45] <infinity> I do have an interest in having the USB stuff not be buggered, but perhaps the better answer is to get it in the kernel proper and get VERY widespread testing in the next week.
[09:45] <infinity> On my machine, USB seems to magically take out my PCI NIC, which is pretty cool.
[09:46] <spayne> infinity: shall we see what BenC says? (or do you have the power?
[09:47] <infinity> It'll be up to BenC as a first line approval, and mdz to swat it down after that.
[09:47] <infinity> Both of whom ar ein the US, so wait for them to wake up and get to work. :)
[09:47] <spayne> i got a day off school :) Speech Day this evening :)
[09:47] <infinity> This close to a release, we're obviously rather cautious, but this is a pretty nasty regression for some.
[09:48] <spayne> i know
[09:48] <infinity> I just wish I'd noticed it earlier.  I hadn't booted or upgraded that machine for a couple of months, so I have no idea when the bugs started hitting it.
[09:48] <spayne> sigh - it is very difficult
[09:48] <spayne> but 1.4rc1 was only released yesterday which solved these bugs
[09:49] <spayne> look at http://sourceforge.net/mailarchive/forum.php?thread_id=8321710&forum_id=36471
[09:50] <infinity> Oh, wait, you were just talking about ndiswrapper-usb, not the general kernel USB layer.
[09:50] <infinity> That may not be my bug anyway, then. :)
[09:50] <spayne> yes
[09:51] <infinity> Since ndiswrapper shouldn't even be loaded on my system.
[09:51] <spayne> lol
=== spayne thought he had a mutal friend
[09:51] <infinity> Including an updated ndiswrapper would be much less scary than an updated USB layer.
[09:51] <spayne> oh yeh
[09:51] <spayne> just i think this is importnat - the Laptop Testing Scheme
[09:52] <spayne> so laptops should work better
[09:52] <spayne> USB works fine for me :)
[09:52] <spayne> for everything else
[09:54] <spayne> just moving to my workstation
[09:54] <spayne> brb
=== spayne [n=spayne@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
[09:58] <spayne> back
[10:09] <spayne> infinity: all we can done is wait
=== Yagisan [n=jamie@60-241-39-173.tpgi.com.au]  has joined #ubuntu-kernel
=== spayne [n=spayne@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
[11:29] <spayne> back
=== jorgp2 [n=jorgp@bnet-dial-224.bartnet.net]  has joined #ubuntu-kernel
=== spayne| [n=spayne@i-195-137-120-148.freedom2surf.net]  has joined #ubuntu-kernel
[01:15] <spayne|> ping anyone
=== \sh [n=sh@server3.servereyes.de]  has joined #ubuntu-kernel
=== doko_ [n=doko@dsl-084-059-079-189.arcor-ip.net]  has joined #ubuntu-kernel
[02:17] <BenC> hey spayne
[02:17] <fabbione> hey BenC 
[02:18] <spayne> BenC: at alst! been waiting all morning :-)
[02:18] <fabbione> pitti said to wait with that security patch
[02:18] <fabbione> BenC: linus rejected it
[02:18] <spayne> BenC: did you get my emails?
[02:19] <spayne> BenC: i spent around two hours talking with the main ndiswrapper about this problem
[02:21] <spayne> BenC: what do you think?
[02:23] <fabbione> BenC: sparc is fully installable now
[02:23] <fabbione> (at least ubuntu-desktop is)
[02:24] <fabbione> BenC: are you aware of any problem runnign discover on it?
[02:24] <fabbione> it seems that it can't find PCI video cards...
[02:24] <fabbione> (discover1)
[02:24] <spayne> ubuntu works on sparc?
[02:24] <fabbione> yes
[02:24] <fabbione> as of today
[02:25] <fabbione> but it's not a supported architecture
[02:25] <spayne> will this be another archiecture
[02:25] <spayne> oh right
[02:25] <fabbione> it's there.. but it won't be supported
[02:25] <spayne> this isn't going to be another debian>
[02:29] <BenC> fabbione: only thing to make sure of is that ubuntu discover or upstream discover has the sbus patches
[02:29] <\sh> http://bugzilla.ubuntu.com/show_bug.cgi?id=16539 <- if somebody can confirm this...it's really strange
[02:29] <BenC> fabbione: right now the installer doesn't autodetect the network driver and scsi driver on my e3k
[02:30] <BenC> spayne: I think updated ndiswrapper will have to wait
[02:30] <fabbione> BenC: ok
[02:30] <spayne> BenC: not even an extra package idea?
[02:32] <fabbione> \sh: buy better hw
[02:32] <\sh> fabbione: har har ;) that's ogra not me
[02:33] <\sh> fabbione: the sony is new :)
[02:33] <\sh> fabbione: and it's not mine actually :(
[02:33] <BenC> spayne: well, I don't have time for the extra package, so someone else would have to do it
[02:34] <spayne> BenC: what about if i write a Wiki doc (i am joining the Wiki team) on this problem and how to install ndiswrapper 1.4rc1
[02:34] <spayne> BenC: and something in the release notes?
[02:41] <BenC> spayne: an errata would be called for, yes
[02:41] <BenC> probably talk to mdz about it
[02:41] <spayne> will do
[02:42] <spayne> you mean an update once breezy is released?
[02:42] <BenC> hopefully
[02:43] <fabbione> sorry BenC .. you said that discover1 in Debian fixes the sparc problems_?
[02:43] <BenC> want the release to be solid and tested, and we can try to get some testing on ndsiwrapper v1.4 afterwards and backport it to breezy's kernel
[02:43] <BenC> fabbione: yes, I know it works
[02:43] <fabbione> ok thanks
[02:43] <BenC> don't know if upstream got the patches
[02:43] <fabbione> i have pci devices so i can check
[02:43] <fabbione> here it detects nothing
[02:44] <BenC> odd, it used to detect PCI on my blade 100
[02:50] <fabbione> the one from debian works
[02:50] <fabbione> the one on ubuntu segfaults badly
[02:50] <fabbione> the point is to figure how intrusive the changes are
[02:50] <fabbione> our version is very old
[02:52] <fabbione> otherwise we need to think something really hoorible to get it into the archive
[02:52] <fabbione> hell everything is working
[02:52] <fabbione> we can't crap out on one package
[03:03] <BenC> it wouldn't be so bad if the installer would add the modules I manually selected to /etc/initramfs/modules
[03:03] <BenC> atleast the storage module
=== Yagisan [n=jamie@60-241-39-173.tpgi.com.au]  has left #ubuntu-kernel [] 
[03:22] <\sh> BenC: hmmm....#16539 <- AltGR is also not working on the console...so which is the right package?
=== Yagisan [n=jamie@60-241-39-173.tpgi.com.au]  has joined #ubuntu-kernel
[03:28] <BenC> \sh: console keyboard mappings are handled by the kernel, but it's a userspacr tool that loads the keymap based on what keyboard you selected during install
[03:28] <BenC> which I _think_ is console-tools
[03:29] <infinity> console-tools and console-data, yes.
[03:29] <infinity> (tools does the work, data has the keymaps)
[03:30] <BenC> then it's probably -data that has the bug, but I'll let the maintainer take care of that
[03:30] <\sh> BenC: funny thing about it, that it's working on my horrible broken breezy install...but not on a new warty->hoary->breezy upgrade...I'll do a new install of breezy tonight on my other laptop so if this is issue reoccur then I can confirm this issue for sure...
[03:31] <BenC> \sh: sounds like an upgrade issue with console-data
[03:31] <BenC> \sh: you should add that to the bug report, it would be very helpful in pinpointing it
[03:31] <infinity> \sh : Can you fix it with dpkg-reconfigure console-data?
[03:32] <infinity> (Note that after reconfiguring it, you may have to reboot, as the kernel is sometimes a bit anal about hanging onto a loaded keymap)
[03:32] <\sh> infinity: I don't have the sony here anymore (colleague went home...tomorrow I can check it) and this evening with the new install..yes..
[03:33] <infinity> Yes, reconfiguring it works?
[03:34] <infinity> Or, "yes, this yes doesn't belong at the end of my sentence, I just put it there for dramatic effect"?
[03:34] <\sh> infinity: that I can test it this evening -> yes , right now I don't have the possibility..
[03:34] <\sh> infinity: that the point...dramatic effect ,-)
[03:36] <infinity> Alright.  If you can get the output of "debconf-show console-data" on a broken system, then try to dpkg-reconfigure it, and if that fixes your issue, the debconf-show afterward too?
[03:37] <\sh> infinity: will do 
[03:37] <infinity> (Attach both to the bug)
=== Yagisan [n=jamie@60-241-39-173.tpgi.com.au]  has left #ubuntu-kernel [] 
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
=== JaneW [n=JaneW@wbs-146-156-89.telkomadsl.co.za]  has joined #ubuntu-kernel
[07:49] <\sh> BenC: I just did a new install...this strange keyboard behaviour doesn't appear for me...(todays iso)
[07:49] <\sh> BenC: so something else must be wrong...upgrade issues?
[07:50] <fabbione> an upgrade issue doesn't affect the kernel
[07:50] <fabbione> the kernel image is the same either via installing or upgrading
[07:51] <\sh> fabbione: yes I know...so could it be the console-*? during upgrade?
[07:51] <\sh> hmmm....w8
[07:51] <\sh> I'm using uk layout on my laptop...lets check after dinner how it behaves with german keyboard layout ;)
[07:54] <fabbione> yes.. console-data relies on config files
[07:55] <fabbione> something the kernel doesn't for the keyboard
[07:56] <\sh> sounds like I have to reinstall the sony tomorrow
[07:56] <\sh> or take it with home over the weekend...to check properly what's wrong...
=== crimsun [i=nobody@warped.bluecherry.net]  has joined #ubuntu-kernel
[09:10] <lamont> SCORE!
[09:10] <lamont> if I start with our kernel, and debian's 2.6.12 config, and hit return to every question, it appears to boot.  Now to find the evil option
[09:15] <jbailey> lamont: Still initrd or with initramfs too?
[09:15] <lamont> initrd
[09:15] <lamont> jbailey: first we get a booting kernel, then we worry about initramfs
[09:15] <lamont> since I have a trivial workaround for the latter, and no workaround for the former
[09:15] <jbailey> No prob, I'm just tracking what's going on. =)
[09:19] <fabbione> BenC, jbailey: ping?
[09:20] <jbailey> fabbione: 'sup?
[09:20] <fabbione> meh
=== mkrufky [n=mk@68.160.103.77]  has joined #ubuntu-kernel
=== BenC [n=bcollins@debian/developer/bcollins]  has joined #ubuntu-kernel
[09:42] <fabbione> hey BenC 
[09:42] <fabbione> BenC: can you please test on the fly the discover1 pkg and lib from http://people.ubuntu.com/~fabbione/
[09:42] <fabbione> it has the sparc bug fixes
[09:42] <fabbione> it works for me
[09:42] <fabbione> but i need you to check with multiple sbus thing
[10:06] <fabbione> BenC: please?
[10:06] <fabbione> can you test it
[10:13] <BenC> hold a sec
[10:15] <fabbione> sure
[10:15] <fabbione> if you can test
[10:15] <fabbione> discover all
[10:15] <fabbione> with both the old and the new
[10:15] <fabbione> you should be able to see the difference
[10:16] <lamont> btw, CONFIG_ACPI_TC1100 is going to need to be added in more than just i386/amd64 configs....
[10:17] <lamont> and I assume it wants to be a module everywhere
[10:18] <lamont> any reason I shouldn't make it =m on hppa/ia64/sparc/ppc?
[10:18] <fabbione> sparc doesn't have ACPI?
[10:18] <fabbione> like ppc...
[10:18] <lamont> ah, that could do it...
[10:18] <lamont> ia64 does though, but I'm overhauling that config atm
[10:19] <fabbione> :)
[10:20] <lamont> # unless you want to implement ACPI on PA-RISC ... ;-)
[10:20] <lamont> config PM
[10:20] <lamont>         bool
=== lamont giggles
[10:22] <BenC> fabbione: waiting for the e3k to boot
[10:22] <fabbione> BenC: no rush
[10:22] <fabbione> i am pretty sure the fix is right
[10:22] <fabbione> but i want to be triple sure since discover1 is main
[10:22] <fabbione> so one upload > two uploads
[10:24] <BenC> wow, minicom reports it was compiled on my birthday
[10:24] <BenC> I feel special :)
[10:25] <fabbione> ahahah
[10:29] <BenC> ok, the new one sees my happy meal
[10:29] <BenC> but neither listed my esp scsi
[10:30] <fabbione> that's weird
[10:30] <fabbione> because i have SBUS stuff here
[10:30] <fabbione> and the new one can see them
[10:31] <fabbione> the SBUS code is identical to debian
[10:31] <BenC> it sees my scsi drive
[10:31] <BenC> but esp is already loaded
[10:36] <fabbione> BenC: can you check using the debian one from sid
[10:36] <BenC> --module only shows sunhme
[10:36] <fabbione> and see if it can actually see the esp?
[10:36] <BenC> yeah
[10:36] <fabbione> i am curious.. becuae they might as weel force esp to load
[10:39] <BenC> 1.7.13 doesn't, and it sees my sunhme
[10:39] <BenC> 1.7.7 from debian doesn't see either one
[10:40] <fabbione> so the output from 1.7.13 is the same as mine...
[10:40] <fabbione> right?
[10:40] <BenC> yes
[10:40] <fabbione> perfect
[10:40] <BenC> esp is listed in the discover db
[10:40] <fabbione> in both of them?
[10:40] <fabbione> i mean both debian and mine.
[10:41] <fabbione> i wonder if that could be a problem solved by discover1-data
=== fabbione uploads discover1 in the meantime
[10:47] <fabbione> # wrapper for discover command that can distinguish Discover 1.x and 2.x
[10:47] <fabbione> discover_hw () {
[10:48] <fabbione>         1)
[10:48] <fabbione>                 case "$SUBARCH" in
[10:48] <fabbione>                   sparc/*) sbus=",sbus" ;;
[10:48] <fabbione> the hack is in hw-detect
[10:48] <fabbione> (in the installer
[10:49] <fabbione> i will need to talk with Kamion about it
[10:49] <fabbione> anyway i am off for a sleep
[10:49] <fabbione> thanks Ben
=== mkrufky is now known as mkrufky-isnt-her
=== mkrufky-isnt-her is now known as mkrufky-not-here