[01:19] <zul> whee..
[04:11] <kylem> woohoo. killed my email backlog.
[04:11] <kylem> now i can go back to reading bugs.
[05:43] <infinity> Ooo, can you do my email next?
[05:43] <infinity> I have unread mail from ~3 years ago.
[05:45] <kylem> damn, chief.
[05:45] <kylem> i have this phobia of unread email
[05:47] <infinity> I fear it so much that I never read it, which may explain the above.
[05:47] <kylem> haha.
[05:47] <kylem> so is launchpad ever going to stop having baltix as the default distribution?
[05:47] <kylem> it's really starting to annoy me. :)
[05:47] <infinity> It's alphabetical.
[05:47] <infinity> We've requested many times to get Ubuntu at the top of the list.
[05:48] <infinity> Sort of like all the online shops with "USA, Argentina, Aruba..."
[05:48] <infinity> Perhaps just renaming the distro to Abuntu would be easier.
[05:49] <kylem> haha.
[10:00] <Mithrandir> BenC: lrm ftbfs.
[10:02] <Mithrandir> FATAL: modpost: GPL-incompatible module ath_hal.ko uses GPL-only symbol 'paravirt_ops'
[10:10] <mjg59> Winning.
[10:11] <Mithrandir> you can't call udelay or ndelay if the kernel's built with paravirt..
[10:11] <Mithrandir> winn0r.
[10:20] <Mithrandir> this only hits i386, for additional fun.
[10:33] <mjg59> Non-free modules can't call udelay if the kernel's built with paravirt?
[10:34] <mjg59> Superb.
[10:53] <Mithrandir> indeed.
[10:55] <mjg59> In that case, I think we lose.
[10:56] <Mithrandir> we can make it work as long as you're not using paravirt, can't we?
[10:56] <mjg59> Is madwifi the only problem, or is that just where it bailed?
[10:56] <Mithrandir> unsure, I haven't tried the rest.
[10:56] <mjg59> I haven't looked at the implementation
[10:57] <Mithrandir> it has a #define which is used in the case where PARAVIRT isn't defined
[10:57] <mjg59> Ok, so paravirt_ops gets rewritten on boot if you're not running virtualised
[10:57] <Mithrandir> I don't have any madwifi hardware to test, though
[10:58] <mjg59> So I /think/ we can get away without it
[11:00] <mjg59> Mithrandir: I guess the easiest way to test would just be to badger lrm to #undef CONFIG_PARAVIRT
[11:01] <Mithrandir> yeah, my thought too
[11:01] <mjg59> And see what explodes
[11:08] <mjg59> Mithrandir: Oh, mdelay is just a wrapper around udelay. So it'll be bitten too.
[11:36] <Mithrandir> it blew up differently (slow_down_io being defined in both paravirt.h and io.h)
[11:36] <Mithrandir> how bad would it be to not build madwifi?
[11:38] <mjg59> Mithrandir: I think people would be unhappy
[11:38] <mjg59> Why is paravirt.h getting included?
[11:40] <Mithrandir> io.h includes it, amongst other things.  I could try disabling CONFIG_PARAVIRT across the board, though
[11:42] <mjg59> Ah, yeah, that was what I meant
[12:08] <Mithrandir> mmm, big hammer applied.
[12:09] <fabbione> Mithrandir: hopefully it won't trash the ABI again
[12:11] <Mithrandir> uh, why would it?  It's lrm
[12:12] <fabbione> oh ok
[12:24] <cjwatson> devicescape is switchable on a per-driver basis, isn't it?
[12:24] <cjwatson> if we merge it
[12:27] <Mithrandir> oh, fun, same problem with ltmodem
[12:27] <Mithrandir> BenC: this needs to be solved ASAP after herd 3, I'm just kludging around it for now.
[12:28] <mjg59> cjwatson: Yes
[12:29] <cjwatson> mjg59: do you know specifics of driver status with devicescape?
[12:30] <cjwatson> like, which ones are a significant improvement over ieee80211
[12:30] <mjg59> bcm43xx ought to be
[12:30] <mjg59> Well, frankly, all of them ought to be
[12:30] <mjg59> With the possible exception of zd1211rw
[12:36] <Mithrandir> oh, and fglrx too.  Win
[12:46] <cjwatson> BenC: did you merge the iSight and Apple Remote patches from mjg59? I don't see them in the changelog
[01:00] <Mithrandir> .. and nvidia.
[01:01] <mjg59> Mithrandir: Unsurprising
[01:01] <Mithrandir> mjg59: really annoying nevertheless.
[01:01] <Mithrandir> I just hope this'll work.
[01:04] <fabbione> Mithrandir: i can test nvidia here if you want me to before upload
[01:04] <fabbione> just hand me some -generic i386.deb
[01:04] <Mithrandir> I just need to make it build first, but thanks.
[01:42] <BenC> cjwatson: It's in my local tree only
[01:42] <BenC> cjwatson: you have a powerbook, right?
[01:42] <BenC> because I'm gonna need this tree tested with the new bcm43xx devicescape based driver
[01:43] <mjg59> The dscape bcm43xx driver needs different firmware to the softmac one
[01:45] <cjwatson> BenC: sure, given a binary
[01:45] <BenC> mjg59: Are you serious?
[01:45] <cjwatson> mjg59: huh? as in, not fwcutter?
[01:45] <mjg59> fwcutter, but it needs version 4 firmware
[01:45] <kylem> BenC, yeah, v4 firmware.
[01:46] <BenC> so not different, just new enough
[01:46] <cjwatson> how do I tell if the stuff I have in /lib/firmware/ in v4?
[01:46] <cjwatson> s/in v4/is v4/
[01:46] <mjg59> softmac doesn't work with v4 firmware
[01:46] <mjg59> So
[01:46] <Mithrandir> BenC: have you seen my rants in backlog about the paravirt_ops being marked as GPL-only?
[01:46] <BenC> Mithrandir: Yeah
[01:47] <Mithrandir> can you lart upstream about it?
[01:47] <Mithrandir> (please)
[01:47] <kylem> uh, this should havebeen fixed.
[01:47] <mjg59> Mithrandir: I can't imagine that changing
[01:48] <BenC> paravirt_ops is being split into paravirt_ops and paravirt_module_ops
[01:48] <BenC> just to fix this
[01:48] <mjg59> Oh, right
[01:48] <mjg59> That's handy
[01:48] <kylem> http://lwn.net/Articles/216636/
[01:49] <Mithrandir> that'd make me happy, yes.
[01:49] <Mithrandir> BenC: do you think just undef-ing it all over the lrm tree will allow the modules to work correctly (as long as you're not using paravirt) or will it just blow up?
[01:49] <BenC> Mithrandir: no, that wont fix it
[01:50] <BenC> it'll fail at module load time
[01:50] <Mithrandir> is there a workaround which is quicker than "new kernel"?
[01:50] <BenC> nope :/
[01:50] <Mithrandir> can you give me a new kernel, like, now?
[01:51] <BenC> like "now", I have to take the kids to the bus stop...so give me 10 minutes
[01:51] <Mithrandir> ok
[01:51] <Mithrandir> with either paravirt disabled or that fix from Ingo or something. :-)
[01:51] <Mithrandir> thanks.
[02:16] <BenC> Mithrandir: ok, working on it now
[02:17] <Mithrandir> thanks.
[02:18] <BenC> I like Rusty's patch better
[02:23] <BenC> Nope, they didn't
[02:23] <kylem> fuck.
[02:24] <Mithrandir> could we just back out the paravirt stuff for herd 3 and reintroduce it later?
[02:24] <kylem> ah well, rusty's diff is pretty small.
[02:26] <BenC> Mithrandir: Either way will take me the same amount of time
[02:26] <Mithrandir> BenC: ok
[02:26] <BenC> plus I made some loose guarantee's that it would be enabled for various testing purposes
[02:26] <kylem> lrm has the new madwifi, right?
[02:26] <BenC> it has 0.9.2.1...the "new" madwifi wouldn't compile
[02:27] <BenC> so no, it isn't fixed yet
[02:27] <BenC> but I can do that post Herd 3 without a kernel upload
[02:27] <kylem> ok.
[02:38] <cjwatson> BenC: Scott says Ian has already uploaded the udev pieces needed for driver-device-manager - are you aware of that?
[02:39] <Keybuk> err?
[02:39] <Keybuk> sorry, I got confused
[02:39] <Keybuk> it doesn't need the udev pieces anyway?
[02:39] <cjwatson> Ben thought it did
[02:40] <Keybuk> I can categorically say that the udev pieces won't make it for feisty :p
[02:40] <cjwatson> and I don't think it can meaningfully progress until drivers aren't bound by default, otherwise the UI ain't gonna do much
[02:40] <Keybuk> because I have no intention of doing them until the *start* of a release process, given the big change
[02:40] <cjwatson> thanks for telling us so early :-P
[02:41] <Keybuk> there appears to be some confusion :p
[02:41] <cjwatson> can you and Ben actually talk to each other about this please
[02:42] <Keybuk> the spec doesn't refer at all to the udev changes we've discussed
[02:46] <cjwatson> "The kernel currently has no mechanism to stop from binding a device to an already loaded driver. Upstream suggests unbinding after noticing this, and binding to the preferred driver. This is not ideal, and is the portion that is likely to require kernel changes."
[02:46] <cjwatson> the udev changes are the resolution of that
[02:46] <Keybuk> right
[02:46] <Keybuk> but the sentence includes an "in the meantime"
[02:47] <cjwatson> my understanding from talking to Ben was that he had expected the udev change to be done, and was writing code based on that assumption
[02:47] <Keybuk> the udev change relies on a very experimental patch to integrate modprobe into udev
[02:47] <BenC> cjwatson: Had no idea
[02:47] <Keybuk> as well as one of our own
[02:47] <BenC> cjwatson: is that udev in Herd3?
[02:47] <Keybuk> I hadn't planned it for feisty at all, which is why there wasn't a spec for it
[02:47] <BenC> cjwatson: Because this may be a hell of a test round if it is in udev and enabled
[02:48] <BenC> Mithrandir: In the interest of time, I'm uploading without a build-test, and building while the buildd's do
[02:48] <BenC> Mithrandir: so if there's a build failure, I'll have a quick fix
[02:48] <Mithrandir> BenC: cheers.
[02:48] <BenC> I don't forsee a problem though
[02:48] <Mithrandir> tell me when it's uploaded.
[02:50] <cjwatson> BenC: no, it is not, as Keybuk says
[02:50] <BenC> ok
[02:50] <cjwatson> BenC: when I first came here Keybuk had confused driver-device-manager and udev-device-mapper
[02:51] <cjwatson> BenC: but in any case, in Oslo you seemed to think that udev no-autobinding was going to land, and now apparently it isn't
[02:51] <BenC> cjwatson: No, I had no idea whether the udev parts would or not, since Ian taking over udev was even news to me :)
[02:52] <BenC> the kernel part is done and will be in Herd 3
[02:52] <BenC> Mithrandir: fire in the hole
[02:53] <Mithrandir> BenC: cheers
[02:54] <Keybuk> Ian isn't taking over udev?
[02:54] <Keybuk> he's taken over the bits that touch things like lvm, evms, etc.
[02:55] <BenC> Keybuk: Maybe we could use a "state of the udev address"
[02:55] <BenC> I've no idea what's going on with it
[02:56] <Keybuk> not much :)
[02:56] <Keybuk> in theory, it just maintains itself now; unless we want to make changes to it
[02:56] <Keybuk> it needs someone to keep up with the rules changes, etc.
[02:56] <Keybuk> I'd figured it'd make the most sense to be under the kernel team, as it's tightly coupled to the kernel
[02:57] <Keybuk> it needs a gentle hand, one who can say "no!" to any request for adding "/dev/mylittlepony"
[02:57] <zul> hi
[02:57] <kylem> morning.
[02:57] <Mithrandir> Keybuk: what about /dev/ponies/woody ?
[02:57] <zul> how is going kylem 
[02:57] <kylem> dude. mylittlepony is awesome.
[02:57] <Keybuk> definitely no /dev/ponies
[02:57] <kylem> OMG PONIESS?!!?
[02:57] <Keybuk> you can have /dev/pony0, provided the kernel has a pony subsystem :p
[02:57] <kylem> zul, it's fucking cold. i want to go back to oslo.
[02:58] <zul> kylem: heh
[02:58] <Mithrandir> echo hay > /dev/ponies/woody
[02:58] <zul> kylem: it was colder last week
[02:58] <kylem> suck.
[02:59] <zul> -24 at one point
[02:59] <BenC> I got ENOENT on /dev/pony0
[02:59] <BenC> I think the driver is busted
[02:59] <kylem> file a bug.
[02:59] <kylem> :)
[02:59] <BenC> Assign it to Kurt I guess
[03:00] <kylem> haha.
[03:01] <kylem> oo is bigger i think
[03:01] <Mithrandir> I don't run mdebdiff on that too often
[03:02] <kylem> maybe you should. :P
[03:02] <Mithrandir> anyway, accepted
[03:03] <BenC> Mithrandir: thanks
[03:20] <cjwatson> BenC: please let me know how much extra work it will be in the d-d-m UI to account for udev not disabling auto-binding
[03:21] <BenC> cjwatson: will this feature not make it into feisty at all?
[03:21] <BenC> because not having the udev changes doesn't make it difficult, it makes it impossible
[03:22] <BenC> kills driver-backports too
[03:22] <cjwatson> the spec says "Upstream suggests unbinding after noticing this, and binding to the preferred driver
[03:22] <cjwatson> "
[03:22] <cjwatson> is that definitely not a viable workaround?
[03:22] <BenC> cjwatson: Not safe..in the case of ide drivers, you cannot unload or unbind
[03:22] <cjwatson> I don't think it would kill driver-backports, just limit its scope?
[03:23] <BenC> it would limit driver-backports to hot having updated drivers, just new ones
[03:23] <BenC> cjwatson: If the case of other drivers, binding, unbinding and rebinding to a new driver can have unexpected results that I'd rather not try to find out about
[03:23] <BenC> s/If/In/
[03:34] <cjwatson> can *anything* useful be done with d-d-m without that? like module options?
[03:35] <Keybuk> I'm happy for Ben to take over implementation of the udev side
[03:35] <mjg59> Every module could be hacked and refuse to bind unless passed a magic option
[03:35] <mjg59> But, uh.
[03:35] <Keybuk> I can forward him the modprobe patch which it can be built on
[03:35] <cjwatson> that seems sensible
[03:39] <cjwatson> BenC: driver-backports would work fine even without d-d-m for updated drivers, surely, as long as the backported driver were deterministically installed
[03:40] <cjwatson> BenC: and as long as the backports package *isn't* installed on every system
[03:40] <BenC> cjwatson: Yeah, but deterministically means relying on undocumented ordering, or modprobe patching to prefer a subdir, which we can do
[03:40] <cjwatson> s/deterministically installed/deterministically used/
[03:40] <cjwatson> modprobe already prefers /updates
[03:40] <cjwatson> we can and should use that
[03:40] <BenC> is that on purpose or by accident? :)
[03:41] <cjwatson> that was done by SuSE for essentially the same purpose as we propose
[03:41] <BenC> ah, then yeah, driver-backports is ok
[03:41] <cjwatson> there's enough code in there for it that it's clearly on purpose
[03:41] <BenC> d-d-m is likely to just do module ops and create modrobe.d files
[03:41] <cjwatson> sorry, RH, not SuSE
[03:42] <BenC> s/ops/params/
[03:42] <cjwatson> changelog says
[03:42] <cjwatson> o depmod: updates/ dir overrides (for RH, thanks to Thomas Vander Stichele)
[03:42] <cjwatson> BenC: can we move forward with driver-backports with that approach RSN then?
[03:43] <cjwatson> I'd like you to get your other items out of the way before sinking lots of time into udev changes which may turn out to be too risky to land
[03:44] <cjwatson> BenC: same for ubiquity-driver-updates
[03:45] <cjwatson> BenC: I think at this point it is probably safest to accept that driver-device-manager needs to be feisty+1 and do the other work without reference to it, then have d-d-m ready to land first thing in feisty+1
[03:49] <BenC> cjwatson: Makes sense to me
[03:49] <BenC> d-d-m is only slightly useful without the udev parts
[03:50] <cjwatson> BenC: do you think those two can make FF (with Kyle's help if necessary)?
[03:51] <cjwatson> they're both important so can slip a bit if need be, but I'd rather they could land
[03:51] <cjwatson> (as I said, the vendor process doesn't need to be there for FF)
[03:51] <BenC> driver-backports just needs an upload
[03:51] <cjwatson> ok
[03:51] <BenC> ubiquity can be done pretty easily from my side, if you are doing the ubiquity parts
[03:52] <cjwatson> there are no ubiquity parts
[03:52] <cjwatson> the spec is misnamed because it assumed the implementation before we worked out how it would work
[03:52] <BenC> ah, right, ok, then even less work :)
[03:52] <cjwatson> actually, no, sorry, that's not true
[03:52] <BenC> I thought we passed an option so the initramfs asked for the drivers or something
[03:52] <cjwatson> there are some things that need to be done by ubiquity, but actually they'll probably be done by casper hooks
[03:53] <BenC> ubiquity needs to make sure it copies them over
[03:53] <cjwatson> right, that will be a casper hook
[03:53] <BenC> ok
[03:53] <cjwatson> but same difference I guess
[03:53] <BenC> I can have all that done before Herd 4
[03:53] <cjwatson> it is not entirely clear that I will have time to do the casper work, but I'll work that out and delegate if need be
[03:53] <BenC> ok
[03:54] <mdz> BenC,cjwatson: should we talk this out by phone?
[03:56] <cjwatson> maybe, but perhaps not right now
[03:57] <BenC> yeah, maybe reread the spec and make sure I got everything right
[04:10] <Mithrandir> BenC: ftbfs, due to missing ABI thang.
[04:16] <BenC> doh
[04:16] <Mithrandir> care to fix?
[04:20] <BenC> Mithrandir: fixed and uploaded
[04:21] <Mithrandir> thanks
[04:21] <BenC> np
[04:29] <Mithrandir> BenC: uh, how does that fix it?
[04:29] <Mithrandir> or does the ABI checker read the changelog?
[04:31] <BenC> it reads the changelog
[04:31] <Mithrandir> ok
[04:31] <Mithrandir> accepted
[05:29] <Mithrandir> BenC: http://librarian.launchpad.net/6012650/buildlog_ubuntu-feisty-i386.linux-source-2.6.20_2.6.20-6.10_FAILEDTOBUILD.txt.gz ; ftbfs
[05:30] <BenC> yeah, looks like the best thing is just to make paravirt_ops no a GPL export for this upload
[05:30] <BenC> take out the patch, doing that now
[05:30] <Mithrandir> thanks
[05:30] <mjg59> BenC: Uhm.
[05:30] <mjg59> BenC: Is that a change that's been made upstream?
[05:31] <BenC> mjg59: No, but it's temporary
[05:31] <mjg59> If not, I think we're in murky legal waters.
[05:31] <kylem> not really. the tenuous nature is if a vendor ships a patch which changes an export, they're acknowledging it's a derived work.
[05:32] <BenC> it used to be just EXPORT_SYMBOL, so I could claim that at one point it wasn't _GPL only :)
[05:32] <mjg59> While clearly the GPL allows us to change the symbol name, it implies that the modules we ship are derived works
[05:32] <mjg59> Well, implies more strongly than would otherwise be the case
[05:33] <kylem> heh, i found it hard to believe a court would rule that some other companies code is a derived work because an unrelated linux distro changed an export.
[05:33] <BenC> the case could be made that changing a config option should make the same source bind differently to the GPL or not
[05:33] <mjg59> kylem: The work is the combination of the other company's code and the GPLed kernel code
[05:33] <BenC> shoudn't
[05:33] <kylem> the legal onus isn't on us...
[05:33] <mjg59> kylem: When we're shipping the work, it is
[05:34] <mjg59> module+EXPORT_SYMBOL_GPL = GPL (in theory)
[05:34] <mjg59> If we can't provide the source, we're not permitted to distribute the work
[05:34] <BenC> a) The symbol recently changed, so one could easily claim we are using the old version, b) it's temporary, and c) I don't think we are functionally different than with the paravirt-mod-op patch
[05:34] <kylem> that's not really the case since there's no precedent.
[05:34] <mjg59> BenC: I understand that there's a reasonable technical argument
[05:35] <mjg59> But I'm unhappy about setting a precedent where we'll s/_GPL// in order to get non-free drivers linking
[05:35] <BenC> mjg59: But I do understand your argument
[05:35] <mjg59> Even if it is temporary
[05:35] <kylem> i'm moderately amused they were allowed to change it by linus. i guess since paravirt being EXPORT_SYMBOL() never made it into a real kernel release...
[05:36] <mjg59> Given the alternatives, I think it would make more sense to just disable paravirt for this herd release
[05:36] <kylem> if my laptop wasn't utterly unusuable atm because i'm pruning and repacking ten gig of git trees, i'd try to argue more, but given it's utterly noninteractive.
[05:36] <mjg59> That way we're unarguably in the clear
[05:36] <kylem> er.
[05:36] <kylem> BenC, that's an easy fix to make.
[05:36] <mjg59> And we can fix it in time for the next upload
[05:37] <kylem> oh. you didn't push.
[05:45] <BenC> urg
[05:45] <BenC> I don't want to disable paravirt
[05:47] <zul> http://ozlabs.org/~rusty/paravirt/?cs=cac1791e2d5f
[05:49] <kylem> look at the timestamp.
[05:49] <zul> meh...ill g o back to work then :P
[05:50] <kylem> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0dbe5a111382fd1320ff4b1d889e5b8c41290619;hp=a517b9f9fe8e57437b0b9b50e279220aaf651268
[05:51] <Mithrandir> kylem: since clearly, one sha1 hash in the url isn't enough. :-P
[05:51] <kylem> meh.
[05:53] <lifeless> yknow, linus is clcearly right. thts so much simpler than 'http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1023;hp=1025
[05:53] <kylem> i rightclick, and i hit "open link" what's so hard about that?
[05:54] <BenC> Mithrandir: uploaded
[05:54] <lifeless> didn't say 'hard' ;). said simple.
[05:54] <kylem> :)
[05:55] <BenC> according to that commit, it sounds like the intention of _GPL is just to keep it local until the API settles
[06:08] <Mithrandir> BenC: let's hope it builds fine this time around.
[06:09] <mjg59> BenC: Ok, I'll go with that
[07:42] <zul> meh..
[08:44] <psusi> what is the internal buffer size used for pipes?  I seem to remember hearing it was only 4k on lkml at some point...
[09:07] <Mithrandir> building looks good so far.  I'm hoping it'll be good.
[10:15] <sioux> hi
[10:16] <sioux> what's this story about multimedia kernel?
[10:21] <TheMuso> sioux: There is a low latency kernel for Feisty, but afaik it isn't officially supported.
[10:22] <Mithrandir> it's in universe, yes
[11:13] <BenC> Mithrandir: Have you tried pushing LRM for i386 back through?
[11:18] <Mithrandir> no, since the i386 kernel isn't published yet
[11:33] <Mithrandir> BenC: the ABI should have been stable between all those builds, right?
[11:52] <kylem> doubtful given he was mucking with exported symbols...
[11:53] <Mithrandir> well, that should only have affected i386.
[11:53] <Mithrandir> Let's hope that's true.
[11:56] <kylem> heh.
[11:56] <kylem> indeed.