[02:08] <mjg59> BenC: Hm. You didn't apply the other patches I sent you.
[05:42] <dilinger> mjg59: i don't suppose you have any opinions on http://people.redhat.com/mingo/realtime-preempt/patch-2.6.13-rt12 ?
[12:43] <mjg59> dilinger: Not really I'm afraid, now
[12:43] <mjg59> Uh, no
[01:05] <Mithrandir> BenC: any thoughts on 13834 ?
[01:26] <Mithrandir> apparently, it's turned off, so I should just be able to turn it on.  Does adding modules change the ABI or is that handled automagically?
[02:15] <zul> hey
[03:27] <lamont> we should really add a .deb that has the abi info in it (or deliver it with the kernel) - that way we don't have to go scraping it when we need it...
[03:28] <lamont> of course, launchpad will do that for us.
[03:45] <zul> mjg59: i have a laptop here that says its running on battery when its plugged into the wall
[03:49] <mjg59> zul: Breezy?
[03:55] <zul> yeppers
[03:55] <zul> new acpi and kernel i think
[03:57] <mjg59> What hardware?
[03:57] <mjg59> Can you try with ec_burst=1 ?
[03:59] <fs> mjg59: btw, using ec_burst=1 with 2.6.13 on my turion64 laptop fixes the AE_TIME blurb on every acpi access, thanks for the hint
[03:59] <mjg59> Hm. We should probably make that the default (it was in Hoary)
[03:59] <fs> the acpi patch for 2.6.12 did not need it, but with 2.6.13 it is needed on both vanilla and acpi-patched kernels
[04:01] <BenC> Mithrandir: is that still true for -8?
[04:01] <BenC> 13834 that is
[04:02] <BenC> lamont: I am adding the gzip's abi file into the kernel .deb's next upload
[04:03] <BenC> gzip'd
[04:03] <BenC> it's about 57k compressed
[04:03] <lamont> BenC: WOOT!
[04:03] <BenC> thanks for pushing ia64 through
[04:04] <zul> mjg59: hp dv1170ca
[04:04] <mjg59> zul: Interesting
[04:05] <zul> very
[04:29] <zul> im going to get him to do a ec_burst=1 and he will try it later ill let you know
[04:32] <mjg59> zul: Cool
[04:34] <zul> aieee...need arch ;)
[04:44] <mjg59> BenC: Any chance of being able to push out another new kernel in the near future?
[04:49] <jbailey> mjg59: I need to push one soonish for the update-initramfs changes.
[04:49] <mjg59> Ok
[05:03] <mjg59> BenC: I've mailed you a tarball. 
[05:06] <BenC> mjg59: yeah, hopefully next week
[05:08] <zul> i wonder how many drivers dont have hotplug support?
[05:11] <mjg59> BenC: Did you get the patches I sent?
[05:13] <BenC> yeah, I wasn't able to merge them before doing the upload
[05:13] <BenC> they will be in the next one for sure
[05:13] <mjg59> Ok
[05:13] <zul> BenC: i thought there was hotplug support for buslogic patch?
[05:14] <mjg59> jbailey: Any estimate on the initramfs-tools upload?
[05:14] <mjg59> BenC: Ok, the sky2 driver seems to be a bit flaky
[05:17] <mjg59> BenC: http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff;h=793b883ed12a6ae6e2901ddb5e038b77d6f0c0ac;hp=d7f6884ae0ae6e406ec3500fcde16e8f51642460
[05:18] <mjg59> Supposed to be better, with luck we can get some debug out of it
[05:21] <zul> mjg59: the ec_burst=1 makes no difference
[05:24] <BenC> mjg59: how can I get just the diff from that URL?
[05:30] <jbailey> mjg59: A few hours?  Will that work for you?
[05:31] <jbailey> mjg59: I was trying to incorporate your bits with the fact that modalias doesn't detect ide-generic.
[05:31] <jbailey> (for chipsets that don't have specific drivers)
[05:31] <jbailey> mdz tripped over that last night, and I'm trying to not forcably always load ide-generic, although I might have to even on scsi-only systems.
[05:32] <BenC> shit
[05:33] <BenC> knew I should have made the wiki page with this on it before I trashed my system
[05:35] <BenC> mjg59: never mind, I found the "plain" link
[06:11] <Mithrandir> BenC: yeah, appears to be.
[06:12] <BenC> Mithrandir: no idea how it got turned off
[06:23] <zul> yay
[07:34] <jbailey> mjg59: Around?
[07:42] <Diziet> Hello.  I have some questions about what make-kpkg ought to do.
[07:42] <Diziet> I'm trying to fix 15488, which is to do with the compiler that it chooses and the dependencies in the various packages.
[07:43] <Diziet> While investigating, I discovered that apparently our make-kpkg doesn't arrange for it to choose the right compiler.
[07:43] <Diziet> That is to say, unpacking a stock 2.6.13.1 and running make-kpkg kernel-image on breezy tries to use the default gcc, ie gcc-4.0.
[07:44] <Diziet> Do our kernel source packages have something in our diffs to force the choice of compiler ?
[07:52] <zul> yes...its forced to use gcc-3.4 afair
[07:58] <jbailey> I remember Fabio saying that.  Using gcc-4 on the compiler is insane right now, I suspect.
[07:59] <fabbione> Diziet: make-kpkg is not broken
[07:59] <fabbione> we force legally the compiler to use
[07:59] <fabbione> using normal make vars
[07:59] <fabbione> if they want to build with 4.0, it's their business
[08:31] <fabbione> BenC: ping?
[08:31] <BenC> yes
[08:31] <fabbione> the sky2 driver is FTBFS on sparc...
[08:31] <BenC> odd
[08:31] <BenC> builds on amd64, ia64, and ppc64
[08:32] <fabbione> just a sec.. let see if it is only a missing include
[08:32] <fabbione> did you get the other one liner?
[08:32] <BenC> yes
[08:33] <fabbione> ok
[08:33] <fabbione> that one seems to be required after one of the security patches..
[08:33] <fabbione> if you don't plan to upload before monday, we can have more time to look at it
[08:33] <fabbione> drivers/net/sky2.c: In function `sky2_probe':
[08:33] <fabbione> drivers/net/sky2.c:2476: error: `DMA_64BIT_MASK' undeclared (first use in this function)
[08:33] <fabbione> drivers/net/sky2.c:2476: error: (Each undeclared identifier is reported only once
[08:33] <fabbione> drivers/net/sky2.c:2476: error: for each function it appears in.)
[08:33] <fabbione> drivers/net/sky2.c:2482: error: `DMA_32BIT_MASK' undeclared (first use in this function)
[08:33] <BenC> is that in asm-sparc64 anywhere?
[08:35] <fabbione> include/linux/dma-mapping.h only
[08:35] <fabbione> testing if it is a missing include
[08:35] <BenC> does it include linux/dma-mapping.h?
[08:35] <BenC> other arch's may pull it in from their asm includes
[08:35] <fabbione> not directly
[08:35] <fabbione> exactly
[08:35] <BenC> should be ok to include directly
[08:35] <BenC> in fact, it should be correct
[08:36] <fabbione> well i am testing it including it directly
[08:36] <fabbione> yeah that does it
[08:36] <BenC> I have a patch for sky2, it may have that fixed already
[08:36] <BenC> I'll check though
[08:38] <fabbione> Diziet: the upload you did of kernel-package is WRONG
[08:38] <fabbione> you must not force gcc-3.4 anywhere
[08:38] <Diziet> fabbione: Yes ?
[08:38] <Diziet> (Sorry about my temporary departure.)
[08:39] <Diziet> I'm not forcing it.  I'm defaulting it.
[08:39] <fabbione> Diziet: you don't default it
[08:39] <fabbione> the default is the gcc compiler in the system
[08:39] <fabbione> you are breaking a known behaviour
[08:39] <fabbione> the bug is on something completely different
[08:40] <Diziet> The default gcc compiler in the system can't compile any currently available kernels, right ?
[08:40] <fabbione> the submitter is telling you that "apt-get install linux-source-2.6.12" should Depends on gcc-3.4
[08:40] <Diziet> And compiling your kernel with 3.4 is unlikely to do any harm ?
[08:40] <Diziet> fabbione: Yes, I've fixed that too.
[08:40] <fabbione> and not apt-get source linux-source-2.6.12
[08:41] <fabbione> Diziet: did you commit the change to the baz repo?
[08:41] <fabbione> Diziet: wrong.. gcc-4.0 can compile some kernels
[08:41] <fabbione> it strictly depends on the config and patches you apply to the kernel
[08:41] <fabbione> also.. changinc compiler changes the ABI of the kernel
[08:41] <Diziet> I see.  We had this conversation in #ubuntu-devel because that's where people wanted to talk about it and they said otherwise there.  But they could be wrong of course.
[08:41] <fabbione> that's bad
[08:42] <fabbione> there is only one authority in regards of the kernel and that's the kernel team
[08:42] <jbailey> fabbione, BenC: mkrufky is part of upstream for v4l and dvb
[08:42] <mkrufky> hello
[08:42] <fabbione> hey mkrufky 
[08:42] <mkrufky> how's it goin
[08:42] <mkrufky> bear with me, i'm at work.... 
[08:43] <Diziet> I came here and I asked and no-one answered.  Well, one person did respond to the question I had asked here but they did so on #ubuntu-devel.  But if you're telling me I've done it wrong I'm happy to talk about it and undo it if necessary.
[08:43] <mkrufky> anyhow, yes... jbailey mentioned that there isnt anybody on your kernel team that knows whats going on with v4l / dvb stuff
[08:43] <mkrufky> i'd be willing to help, in this respect
[08:43] <jbailey> AFAIK, anyway. =)
[08:43] <Diziet> It seems to me that it is a bug in make-kpkg that you can download a vanilla kernel.org kernel and expect it to do everything for you but in fact it will select the wrong compiler.
[08:43] <mkrufky> :-)
[08:44] <Diziet> Where `wrong' = `most probably wrong for what you want to do'.
[08:44] <fabbione> Diziet: gcc-4.0 is not a wrong compiler
[08:44] <Diziet> Note that we are being unusual in shipping with gcc-4.0.
[08:44] <fabbione> no we are not..
[08:44] <Diziet> So why should kernel-source depend on gcc-3.4 then if gcc-4.0 is fine ?
[08:44] <fabbione> FC4 is all based on gcc-4.0
[08:44] <jbailey> Diziet: If people are building their own kernels, they ought to have some thoughts as to what compiler they're running, etc.
[08:44] <fabbione> kernel-source doesn't exists..
[08:45] <Diziet> jbailey: I agree with that _more_ if we're talking about kernel-source.deb than if we're talking about using make-kpkg to make an image.
[08:45] <fabbione> linux-source-2.6.12 as package (and not as source) should Depends: gcc-3.4
[08:45] <fabbione> because that's our source with our patches
[08:45] <fabbione> and it in fact needs gcc-3.4
[08:45] <Diziet> Sorry, I mean linux-source, not kernel-source.  People keep changing the names of these damn things.
[08:45] <jbailey> Diziet: I'm really hoping that for dapper we make strong statements against people compiling their own kernels..
[08:45] <fabbione> Diziet: you must revert that change...
[08:46] <fabbione> kernel-package is not the place where to do that stuff
[08:46] <fabbione> BenC: you must be sure to be B-D on a correct version of kernel-package once Diziet revert
[08:46] <Diziet> fabbione: Our source with our patches uses gcc-3.4 by default, right ?
[08:46] <Diziet> That is, our patches patch the makefile ?
[08:46] <fabbione> Diziet: yes. that is correct
[08:46] <fabbione> correct too
[08:47] <Diziet> So if you say `make-kpkg kernel-source' from one of our kernel sources you get a linux-kernel.deb which needs gcc-3.4 installed or it will fall over during compilation.  Right ?
[08:47] <fabbione> Diziet: also.. asking on IRC is fine, but give people time to answer
[08:47] <fabbione> exactly
[08:47] <fabbione> it's one line change in linux-source-2.6.12 control file
[08:48] <Diziet> But if you say `make-kpkg kernel-source' from a kernel.org kernel you get a linux-kernel.deb which needs `gcc' installed and for `gcc' to work and doesn't care about gcc-3.4.  Right ?
[08:48] <fabbione> exactly
[08:48] <Diziet> Now make-kpkg is making the control file for this linux-kernel.deb.  How is it to know what to put in the Depends ?
[08:48] <fabbione> Diziet: you are making hell of a lot of confusion
[08:49] <mkrufky> seriously
[08:49] <fabbione> Diziet: there is a source called linux-source-2.6.12
[08:49] <Diziet> fabbione: Do you want to talk on the phone or something ?  I'm not being deliberately confused here.
[08:49] <fabbione> and a binary package called  linux-source-2.6.12
[08:49] <fabbione> the latter needs a Depends on gcc-3.4
[08:49] <mkrufky> Diziet: does this not cover it all?  http://www.us.debian.org/releases/stable/i386/ch08s05.html.en
[08:49] <fabbione> that's all the submitter is asking
[08:50] <fabbione> Diziet: no, my wife is waiting for me and it's friday night
[08:50] <mkrufky> oh, oops i misunderstood the problem
[08:50] <Diziet> I'll revert my change completely and we can talk on Monday.  Would that suit you ?
[08:51] <fabbione> Diziet: revert the changes, because changing behaviour of the kernel build system is bad
[08:51] <fabbione> we can talk again on monday
[08:51] <fabbione> but the submitter is asking something completely different of what you are thinking.
[08:54] <Diziet> No, I understand what the submitter is thinking, but I think there is a wider problem and just doing as the submitter asks is at best partial and at worst wrong.
[08:55] <Diziet> Anyway, the reversion is in ubuntu4 which has just gone out.
[08:56] <zul> gah?
[08:56] <fabbione> Diziet: given that you just changed the default behavior for something that is not related to what the submitter is asking, gives me the impression that you don't get the difference
[08:56] <fabbione> it is perfectly normal to build a kernel with gcc-4.0
[08:56] <fabbione> that's the default in the system
[08:56] <fabbione> it's our kernel that is special cased
[08:56] <fabbione> and therefor our source takes the appropriate actions to build
[08:57] <Diziet> Why is our kernel special cased ?  Because gcc 4 doesn't build it right, right ?
[08:57] <fabbione> thanks for reverting the change
[08:57] <mkrufky> vanilla kernel is gcc-4.0 compatable
[08:57] <jbailey> Diziet: gcc-4 still sucks in subtle ways.  We use gcc-3.4 for glibc, too.
[08:57] <fabbione> Diziet: it does build it, but portion of the code is miscompiled
[08:57] <fabbione> because we do have HEAPS LOAD of external patches required to make our users happy
[08:58] <Diziet> Indeed.  So if _we_ don't want to compile our kernels with it, why on earth would we make it the default for our users ?
[08:58] <fabbione> mkrufky: exactly
[08:58] <Diziet> mkr: OIC.
[08:58] <zooko> I think Diziet has a good point there.
[08:58] <zooko> But as I am not a devel, I will not shut up.
[08:58] <fabbione> Diziet: gcc-4.0 is NOT the default for our kernel
[08:58] <Diziet> But ours users who are compiling their own kernels are likely to want patches, right ?
[08:58] <jbailey> Diziet: What do we care what users do with their own kernels?
[08:58] <mkrufky> why not just make ubuntu kernel patches gcc-4.0 compatable?
[08:58] <fabbione> we force gcc-3.4 and the use spotted that it is missing a Depends :)
[08:58] <Diziet> jbailey: make-kpkg makes a choice about what compiler to use.
[08:59] <jbailey> Doesn't it just default to gcc?
[08:59] <fabbione> Diziet: the choise is also made via environment vars
[08:59] <Diziet> Yes.  Which we've made (in Breezy) be gcc 4.
[08:59] <BenC> no, the kernel itself defaults to gcc
[08:59] <BenC> make-kpkg doesn't
[08:59] <jbailey> Right, it's the system compiler.  
[08:59] <fabbione> BenC: we did force it to 3.4
[08:59] <Diziet> env vars> Indeed, which still work just fine with my change.
[08:59] <BenC> in linux-source
[09:00] <fabbione> BenC: yes. that
[09:00] <fabbione> BenC: yes. that's right
[09:00] <fabbione> f the user get his kernel from kernel.org
[09:00] <BenC> but make-kpkg by default just uses what the kernel uses by default, correct?
[09:00] <fabbione> he can compile it with gcc
[09:00] <fabbione> (whatever gcc is)
[09:00] <Diziet> benc: That's what I changed and fabbione is disagreeing with.
[09:00] <BenC> but is that a make-kpkg decision, or a kernel Makefile one?
[09:00] <fabbione> kernel makefile
[09:01] <BenC> without user intervention, it lets the kernel source decide, correct?
[09:01] <BenC> and, IMO, that is right
[09:01] <Diziet> make-kpkg has code to make the decision but it didn't do anything of any consequence before I changed it.  Right.
[09:01] <BenC> because some kernel arch's use odd forced CC's
[09:01] <BenC> like sparc64 used to force sparc64-linux-gcc
[09:01] <BenC> because it needed egcs64
[09:01] <Diziet> In the kernel makefile ?
[09:01] <BenC> you're change could break that
[09:01] <BenC> yes
[09:01] <Diziet> Oh.
[09:02] <Diziet> Right, I see that point now and you are correct.
[09:02] <Diziet> (That is, fabbione is correct that it shouldn't do that.)
[09:02] <fabbione> Diziet: happy to see we can agree :)
[09:02] <Diziet> But, separately, I don't  think I agree with fabbione and the submitter of 15488.  Sorry :-).
[09:03] <fabbione> :)
[09:03] <BenC> Diziet: the correct solution is to provide a kgcc symlink to the right gcc to use
[09:03] <BenC> and make-kpkg could use that
[09:03] <Diziet> That is, make-kpkg can be used _both_ to make linux-source.deb's which contain _our_ kernel sources, and ones which contain _stock_ kernel sources.  Right ?
[09:03] <fabbione> Diziet: i am sure what he is asking because it is confusing.
[09:03] <BenC> in that way, each arch can provide it's own, correct and suggested, gcc for the kernel
[09:03] <Diziet> Yes, I know what he's asking but I think it's wrong.
[09:03] <Diziet> benc: Indeed.
[09:03] <mkrufky> sodomotron?  sounds like that vehicle that mr garrison created in south park
[09:03] <fabbione> Diziet: it's not wrong and i can prove it :)
[09:03] <fabbione> mkrufky: eheh
[09:03] <Diziet> Just follow my argument for a bit.
[09:03] <BenC> IIRC, the kernel even supports that, so make-kpkg might not need to do anything
[09:03] <fabbione> Diziet: we do patch the kernel Markfile
[09:04] <Diziet> Do you agree with my comment ...both... above ?
[09:04] <fabbione> to use gcc-3.4
[09:04] <BenC> fabbione: no, we pass env vars, we do not patch it
[09:04] <BenC> s/fabbione/Diziet/
[09:04] <fabbione> therefor OUR linux-source-2.6.12 binary package needs to Depends on gcc-3.4
[09:04] <BenC> we do?
[09:04] <fabbione> BenC: did you make it an env var now?
[09:04] <Diziet> fabbione told me we patch the kernel top-level makefile to make it use gcc-3.4.
[09:05] <BenC> no, I thought it was
[09:05] <fabbione> yes we do patch it
[09:05] <BenC> ok, then I am corrected :)
[09:05] <fabbione> because passing the env var to make-kpkg did fail miserably on some arches
[09:05] <BenC> either way, that's our parogative
[09:05] <BenC> :)
[09:05] <fabbione> ok
[09:05] <Diziet> Right.  But make-kpkg, as we ship in kernel-package.deb, is not just used by us to make the linux-source.deb in our archive, is it ?  It can also be used by the user, for example to turn a stock kernel source tree into a linux-source.deb.
[09:05] <fabbione> BenC: please just make sure now to bump the B-D on the latest kernel-package
[09:06] <fabbione> Diziet: that's right.. that's why we don't change default behaviour in make-kpkg
[09:06] <fabbione> Diziet: and we do special case directly into our kernel
[09:06] <fabbione> make-kpkg is completely netrual
[09:06] <Diziet> No, wait, but 15488 requests that the linux-source.deb that make-kpkg produces should always have a different Depends.
[09:06] <fabbione> nope..
[09:07] <fabbione> he is asking for linux-source-2.6.12 to Depends on gcc-3.4
[09:07] <fabbione> Shouldn't linux-source depend on gcc-3.4? Not build-depend, but Depend. Since it
[09:07] <fabbione> needs gcc-3.4 to compile kernel source.
[09:07] <fabbione> read it again..
[09:07] <Diziet> Yes.  Where did linux-source-2.6.12.deb come from ?  It was make by make-kpkg.  The request is to change make-kpkg to make it generate a different linux-source.deb ?
[09:07] <Diziet> s/was make/was made/
[09:07] <fabbione> we do ship a linux-source-2.6.12 package
[09:08] <Diziet> Yes, but it all came from make-kpkg.
[09:08] <BenC> linux-source isn't made by make-kpkg, is it?
[09:08] <Diziet> That's why make-kpkg is the thing that's supposed to be changed.
[09:08] <Diziet> mdz says `changing the hardcoded dependency
[09:08] <Diziet> in kernel-package should suffice'
[09:08] <fabbione> Package: linux-source-2.6.12
[09:08] <fabbione> Architecture: all
[09:08] <fabbione> Section: devel
[09:08] <fabbione> Priority: optional
[09:08] <fabbione> Provides: linux-source, linux-source-2.6
[09:08] <Diziet> But that's wrong.
[09:08] <fabbione> Depends: binutils, bzip2, coreutils | fileutils (>= 4.0)
[09:08] <fabbione> Recommends: libc-dev, gcc, make
[09:08] <fabbione> Suggests: libncurses-dev | ncurses-dev, kernel-package, libqt3-dev
[09:10] <Diziet> That doesn't look like what make-kpkg produces.
[09:10] <fabbione> that's in our control file
[09:11] <Diziet> Oh, no, just a mo, I'm looking at the wrong stanza in kernel/Control.
[09:11] <Diziet> It came from this, right:
[09:11] <Diziet> Package: =ST-source-=V
[09:11] <fabbione> so one line change there
[09:11] <Diziet> Architecture: all
[09:11] <Diziet> Section: devel
[09:11] <Diziet> Priority: optional
[09:11] <Diziet> Provides: =ST-source, =ST-source-=CV
[09:11] <Diziet> Depends: binutils, bzip2
[09:11] <Diziet> Recommends: libc-dev, gcc, make
[09:11] <fabbione> and bang :)
[09:11] <fabbione> solved
[09:11] <Diziet> But if I do that and you run make-kpkg on a stock kernel, it will produce a package with a wrong dependency.
[09:12] <Diziet> Why don't we talk about this on Monday.
[09:12] <fabbione> how so? 
[09:12] <Diziet> Because it will say  Recommends: ... gcc-3.4 ...
[09:13] <Diziet> But in fact the source in it will just use `gcc'.
[09:13] <Diziet> You see the Recommends has to depend somehow on which compiler the Makefile is dealing with.
[09:14] <Diziet> I think it's too late for this conversation :-).
[09:15] <fabbione> hmmm
[09:15] <fabbione> i disagree
[09:15] <fabbione> or at least partially
[09:15] <fabbione> our linux-source needs gcc-3.4
[09:15] <fabbione> and that's a state of facts
[09:15] <Diziet> Look, I want to have some dinner and I think we should talk about this on the phone 'cos we're going round in circles.
[09:16] <fabbione> other linux-source needs a compiler
[09:16] <fabbione> Diziet: have a good dinner
[09:16] <Diziet> You too.  I'll let you go talk to your wife :-).
[09:16] <fabbione> if we can't figure it out, just send the submitter to hell
[09:16] <Diziet> :-)
[09:16] <fabbione> hounestly
[09:17] <fabbione> you want to compile your own kenrel
[09:17] <fabbione> you must know what you are doing
[09:17] <Diziet> True.
[09:17] <fabbione> hence use the stock kernel
[09:17] <BenC> yeah, you have to read the file that tells you what compiler is suggested
[09:17] <Diziet> We could just take the dependency out altogether :-).
[09:17] <fabbione> i wouldn't even have spend time on that bug
[09:17] <Diziet> mdz seemed to think it was important.
[09:17] <BenC> true, you don't need gcc to use linux-source
[09:17] <BenC> it could just be for reading
[09:18] <Diziet> Anyway _goodnight_ :-).
[09:18] <fabbione> mdz, when we are close to release, believes that even libfoobar is important :)
[09:18] <fabbione> cya
[09:18] <Diziet> ttfn
[09:25] <mkrufky> ok well i guess u guys are gone.... i'll try to pop into this room from time to time.... I repeat, I'd be happy to help in whatever way you need as far as dvb/v4l kernel stuff
[09:26] <fabbione> mkrufky: oh we are spreaded on all TZ
[09:27] <fabbione> and you are more than welcome here
[09:27] <fabbione> if you are a bit familiar with bazaar you can just branch off our tree
[09:27] <fabbione> and we can merge fixes from you
[09:28] <BenC> mkrufky: hit the bts, and search the linux bugs :)
[09:28] <BenC> s/bts/bugzilla/
[09:29] <fabbione> 310523     Asus A7N8X-E Deluxe, nForce2                    1
[09:29] <fabbione> 310617     Asus A8V Deluxe, K8T800Pro, S939                1
[09:29] <fabbione> 320931     AMD Athlon64, 3000+, S939, BOX, Venice          1
[09:29] <fabbione> 330055     Promise ATA133, TX2 Controller, Bulk            1
[09:29] <fabbione> 350889     Kingston DDR400, 1024 MB, CAS 3                 1
[09:29] <fabbione> 820137     ThermalTake 680Watt, Dual Fan, ATX2.0           1
[09:29] <fabbione> YEEEE
[09:29] <fabbione> my spare parts have been delivered
[09:29] <zooko> :-)
[09:29] <zooko> Nice.
[09:30] <zooko> I was looking at an A8V today.
[09:33] <mkrufky> ah, walked away for a minute and the irc page scrolled back 2 pages
[09:33] <mkrufky> i never used bazaar, but i can always learn
[09:33] <fabbione> BenC: the sparc kernel builds with these 2 fixes
[09:33] <fabbione> but it claims an abi change
[09:33] <BenC> cool, they'll be in the next 2.6.12 upload
[09:33] <BenC> really?!
[09:34] <BenC> what lines?
[09:34] <fabbione> plenty
[09:34] <BenC> are you sure you put the abi files in from 8.12?
[09:34] <fabbione> that's what i am thinking about..
[09:34] <fabbione> but yes i did..
[09:34] <fabbione> hmmm
[09:34] <BenC> are there a lot of ocfs2 lines?
[09:35] <BenC> if so, then I don't think you did
[09:35] <fabbione> nope
[09:35] <fabbione> they are not ocfs2 related
[09:35] <fabbione> -vmlinux sbus_unmap_sg 0x7125562d
[09:35] <fabbione> +vmlinux sbus_unmap_sg 0x70da842c
[09:35] <fabbione> most of them are sg related
[09:36] <fabbione> i have the feeling that the sg security fix has a side effect on sparc
[09:36] <fabbione> that doesn't on other arches
[09:36] <fabbione> i will need to test the same fix in hoary and see..
[09:36] <fabbione> but that's sunday work
[09:36] <fabbione> BenC: do you think you can wait monday to upload?
[09:37] <fabbione> bah wife is calling
[09:37] <fabbione> later fellas
[09:37] <BenC> later
[09:50] <zul> right im going home
[10:21] <persia> I'm tracking down an issue with malone bug #379, and believe that the issue is in the kernel rather than gnome-volume-manager.  Specifically, I've seen an error message of the form "Apr 13 10:18:57 localhost kernel:  /dev/scsi/host5/bus0/target0/lun0: p1" when attempting to mount IDE devices.  Could someone suggest activities which would allow me to confirm this for reassignment?
[10:31] <BenC> nothing really bad about that kernel message
[10:31] <BenC> is that the entire kernel message?
[10:32] <BenC> and what exactly is the problem, are the disks not mounting?
[10:33] <persia> BenC: On my workstation, I am only successsful mounting /boot about 10% of the time: the rest of the time I get an error like the above.  In Malone bug #379, the reporter complains that g-v-m doesn't work because their USB drive doesn't mount: looking at the errors reported, it appears they are encountering the same issue.
[10:36] <BenC> I don't think they are
[10:36] <BenC> the above line isn't an error, it's a line showing the partitions for the drive
[10:38] <BenC> the USB drive not mounting _may_ be a kernel bug, but you'd need more info, like does the kernel see the drive?, can you mount it manually (using the mount command), etc.
[10:38] <BenC> if it mounts manually, and just g-v-m doesn't mount it, then it's not a kernel bug
[10:38] <BenC> if it can't be mounted manually, and the drive actually contains a legitimate filesystem, then it may be a kernel bug
[10:38] <persia> BenC: That's what I thought, but it only appears on my workstation when the mount fails, and never during a USB hotplug mount with g-v-m, so I'M wondering if the reported bug is really with g-v-m, as I've seen the same behaviour external.
[10:39] <BenC> persia: it's like that some USB drives (and some hotplug drives) do not have partitions
[10:39] <BenC> so you wont always see that line
[10:39] <persia> BenC: Also, my workstation has the error on /boot, which never fails to boot, and works fine when it mounts, but as I mentioned before, sometimes I have to run `mount /boot` 10 times.
[10:39] <BenC> it's definitely not an error message
[10:40] <BenC> persia: what type of drive is /boot?
[10:40] <BenC> could just be a bad harddisk
[10:40] <BenC> and what sort of error does it say when it fails?
[10:40] <persia> BenC: OK, I can accept it's not an error message, but it's the only mesage reported when I cannot mount.  It's flash on CF, mounted through an IDE interface.
[10:41] <jbailey> What's the difference between generic.ko and ide-generic.ko?
[10:41] <BenC> that line is just the IDE rereading the partition table on insert
[10:41] <persia> BenC: No error is reported, but the partition map is shown in the logs, and reported if I mount from a root login (as opposed to sudu)
[10:41] <jbailey> mdz has a device that doesn't use  a chipset specific driver and it doesn't seem to have a modalias file pointing it to something useful.
[10:44] <BenC> jbailey: does hotplug handle "IDE class" devices with ide-generic?
[10:44] <BenC> might take more than just a modalias entry for that
[10:44] <jbailey> For SCSI/SATA/IDE, usually it does a pass over the PCI bus, which then opens up /sys/bus/scsi or /proc/ide
[10:45] <jbailey> Then we can walk those busses and figure out sd/sh/ide-disk, etc.
[10:45] <jbailey> ide-generic is a bit quirky because you always have to load it with IDE devices, but it *also* will take over those ports if no other ide chipset driver has grabbed it.
[10:45] <jbailey> So it has to be loaded last.
[10:46] <jbailey> The problem is that because it's the generic one, it seems like it's just supposed to be used if you had an IDE chipset for which you have no other driver.
[10:46] <jbailey> So I'm trying to figure out how to detect that. =)
[10:49] <jbailey> I think the problem here is that because it's a generic catch-all driver, but each group will write their own chipset for it, there's no PCI ID that could be matched against.
[10:49] <jbailey> Hmm
[10:49] <jbailey> I wonder if there's some sort of device class I can check against.
[11:55] <mkrufky> ok im goin home.... tty guys later