[01:47] <mvirkkil> The zd1211rw driver is trying to load the firmware from /lib/firmware/zd1211/zd1211b_ub and failing with return code -2
[01:47] <mvirkkil> Any suggestions?
[01:50] <crimsun> well, it's the wrong dir for one
[01:58] <mvirkkil> crimsun: yes, that's what I figured :) I'll bug BenC about it tomorrow. 
[02:45] <BenC> mjg59: ping
[02:46] <mjg59> BenC: Hi
[02:49] <BenC> mjg59: that console patch for that bug, it touches code that I don't even have enabled since I did the console-power patch the last time
[02:49] <BenC> mjg59: should I revert my patch and add this one?
[02:49] <mjg59> BenC: Console patch for which bug?
[02:49] <BenC> 59851
[02:49] <BenC> the one you mentioned earlier
[02:50] <mjg59> Erm, hang on
[02:50] <mjg59> I thought that was just ACPI/SATA integration
[02:50] <mjg59> Oh
[02:50] <mjg59> He's pointed at an entirely unrelated patch
[02:50] <mjg59> Sorry
[02:51] <BenC> should I take the patch anyway? :)
[02:51] <mjg59> Nope
[02:53] <mjg59> http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-5/linux-2.6-sata-ahci-suspend.patch?rev=1.1&view=markup looks like a better bet
[02:54] <mjg59> It's still not the one we want, but we probably /do/ want that one :)
[02:55] <BenC> does it fix that bug?
[02:55] <mjg59> Probably, yeah
[02:55] <mjg59> Though we also want the sata acpi stuff
[03:04] <zul> BenC: when is the t1 connection coming
[03:05] <BenC> zul: 11/02
[03:05] <zul> cool
[03:06] <BenC> can't wait to watch them run copper through the cow pastures
[03:06] <zul> heh you'll have to take pictures
[03:11] <BenC> mjg59: patch applied
[03:12] <mjg59> BenC: Ta
[03:12] <mjg59> BenC: I'm working on the sata-acpi patch
[03:12] <BenC> ok
[03:12] <BenC> Trying to upload by Friday, for reference
[03:12] <BenC> Friday or Saturday
[03:22] <mjg59> Oh argh this is awkward
[03:41] <zul> BenC: ping
[03:41] <BenC> zul: aye
[03:41] <zul> xt_tables_info didnt come until 2.6.16 did it
[03:42] <zul> stupid netfilter
[03:42] <BenC> I think so, yeah
[03:43] <zul> hmmm...then why am i killing myself over this stupid patch (hypothetical) for amd64
[03:17] <mvirkkil> Would anyone be interested in helping me get to the bottom of the issues mentioned at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/60222 ?
[03:23] <zul> Mithrandir: will take a look in a  little bit
[03:23] <Mithrandir> zul: hmm?  You meant mvirkkil ?
[03:31] <zul> Mithrandir: yeah i did
[03:55] <kbyrd> BenC: got a sec?
[03:55] <BenC> yeah
[03:56] <kbyrd> How do you want the vmware-server sources?
[03:56] <kbyrd> Just the sources? or the debian directory too?
[03:57] <mvirkkil> BenC: This is probably of interest to you https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/60222 ?
[03:57] <kbyrd> *click*
[03:57] <BenC> just sources
[03:58] <kbyrd> ok, but remember the resulting player-kernel and server-kernel modules need to conflict with each other.
[03:58] <BenC> yes, that's no problem
[03:58] <kbyrd> I'll have a URL for you in  a  bit.
[04:00] <fabbione> BenC: did you remember to pull/merge from me?
[04:00] <fabbione> BenC: or do you want me to merge from you and re-push?
[04:01] <BenC> fabbione: Got it
[04:01] <fabbione> BenC: thanks
[04:01] <BenC> mvirkkil: will fix it now
[04:02] <mvirkkil> BenC: Any hints what might be causing the trouble I'm having (mentioned in the comment)? 
[04:04] <mvirkkil> I'll gladly debug this as to the best of my abilities, but I just don't have a clue what to do next,
[04:05] <mvirkkil> I've tested the dongle in windows using the same AP and the same settings (afaict), and it works there. 
[04:05] <BenC> MODULE_AUTHOR("Ulrich Kunitz");
[04:05] <BenC> MODULE_AUTHOR("Daniel Drake");
[04:05] <BenC> contact one of them
[04:05] <mvirkkil> BenC: ok.
[04:10] <mvirkkil> BenC: When can I expect the fixed version (re the firmware issue) to be downloadable? 
[04:11] <BenC> I'm uploading on Friday, so sometime after that (day or two)
[04:12] <pitti> hi
[04:12] <pitti> BenC: not sure whether you are aware of it, zul's last breezy kernel has a strange FTBFS
[04:12] <pitti> BenC: do you have some time today to take a look at it?
[04:13] <pitti> BenC: (I bounced you the log, same failure on all arches)
[04:13] <pitti> BenC, zul: I know I'm getting on your nerves, but I'd like to see this update pushed out soon :/
[04:17] <zul> pitti: the patch that we included for the ebtables only one of them applies
[04:18] <BenC> I'll take a quick peek
[04:18] <zul> see this patch http://70.29.61.171/ubuntu/kernel/ebtables-2.dpatch
[04:18] <BenC> pitti: where did you send the email?
[04:19] <BenC> s/where/when/
[04:19] <BenC> I don't seem to have it
[04:19] <zul> this is the one causing the problem the second chunks are causing the problems because the struct doesnt exist
[04:19] <pitti> BenC: some minutes ago
[04:19] <infinity> Is this the part where I (again) beg people to test build before uploading? :)
[04:20] <zul> infinity: probably
[04:22] <BenC> infinity: That doesn't seem to help me when buildd scripts break my broken stuff :)
[04:23] <infinity> BenC: Heh.
[04:24] <kbyrd> infinity, benc: email sent with the URL to the vmware-server-kernel sources, thanks.
[04:25] <BenC> kbyrd: thanks, since next kernel is an ABI bump, it's an opportune time to put it in
[04:25] <BenC> I'll probably include it with the kernel upload on Friday
[04:25] <kbyrd> Nice. If I can get out from underneath my current schedule pressure on a different product, I'll actually get a vmware-server package together, and maybe fix a lot of the mess with vmware-player.
[04:26] <kbyrd> One nice thing about the next vmware-player package, we move the EULA out of the package and into the UI.
[04:29] <BenC> kbyrd: One thing I noticed about vmware-player is that it is a little broken on amd64
[04:29] <BenC> I needed to create some symlinks for gdk stuff to the path it expected so it would work
[04:29] <BenC> but I've been using it since creating those vmware-player-kernel and updated vmware-player packages
[04:29] <kbyrd> If you get a chance, email me the details.
[04:30] <kbyrd> I'm running 64-bit UI but it's from an internal branch.
[04:30] <zul> bbl...need to go to the doctor with the wifey
[04:31] <kbyrd> Before that, I ran the release version and it ran fine with the ia32-libs installed.
[04:31] <kbyrd> Wait. I remember now. Something recently happend with a c++ lib, right?
[04:32] <kbyrd> That is, I had to move a library on my amd64 bit system to force player to use the right library.
[05:16] <BenC> infinity: FYI, I am moving all firmware to lrm next time around
[05:17] <BenC> I think
[05:17] <BenC> It means moving nic-firmware udeb to lrm as well
[05:17] <Mithrandir> that'll cause a lot of systems which work today and which haven't lrm installed to break.
[05:18] <infinity> BenC: Did you discuss this with mdz?  That's a pretty drastic change.
[05:18] <BenC> we discussed it a bit in germany
[05:18] <infinity> BenC: Also, lrm already has a nic-restricted-firmware udeb.
[05:18] <BenC> I need to finalize it with him and you
[05:18] <infinity> So, you'll just be beefing it up, I suspect.
[05:18] <BenC> Mith's argument is my main concern
[05:18] <BenC> so it might just be edgy+1
[05:19] <BenC> but the "Ubuntu GNU/Linux" dream would require this change
[05:21] <Keybuk> couldn't we have a linux-firmware package instead?
[05:21] <Keybuk> that at least makes it obvious
[05:24] <BenC> yeah, would trim down the install base for people that don't need all of lrm
[05:25] <BenC> build it right out of lrm, and have linux-restricted-modules depend on it
[05:33] <Keybuk> JanC: most firmware doesn't even have source code
[05:33] <Keybuk> the binary blob _is_ the preferred form of editing for it
[05:34] <Keybuk> half the time, it had some source, which was compiled, then hand edited for size, and then binary patched subsequently
[05:34] <Keybuk> etc.
[05:34] <Keybuk> I know one firm that do the first version in C, then strip all the calling conventions just leaving the asm
[05:34] <Keybuk> and then edit that from there on
[05:34] <Keybuk> etc.
[05:35] <Keybuk> silly really
[05:35] <JanC> well, even then the assembler source could be "open source"
[05:36] <JanC> even if no one understands anymore what it does  ;-)
[05:37] <Keybuk> assembler source is the binary
[05:37] <Keybuk> it's a 1:1 match
[05:37] <Keybuk> consider a firmware blob to be a .png file
[05:37] <Keybuk> you open it, modify it, and save it again
[05:37] <infinity> In the cases where that's truly the case, it's fine, really.
[05:37] <JanC> except that assembler source _can_ be documented
[05:38] <Keybuk> infinity: I would be very surprised if there were cases where that wasn't the case
[05:38] <infinity> But we ship some firmware without free licenses, and just turn a blind eye, currently.
[05:38] <Keybuk> JanC: true, but hardware companies don't
[05:39] <JanC> well, that's exactly what I was wondering: why don't they release documented assembler source?
[05:39] <JanC> if it's GPL'ed, they could even benefit from it
[05:40] <JanC> people could fix bugs that make even their Windows drivers work better  ;-)
[05:41] <Keybuk> JanC: because they've never written any documented assembler source?
[05:44] <JanC> I guess it's not that difficult to insert the original C-comments into the assembler to start with, but they probably really don't care...
[05:54] <BenC> zul: ping
[05:56] <mdz> BenC: I don't recall the firmware discussion; what's the rationale?
[05:56] <BenC> mdz: It was more of a passing conversation than a discussion :)
[05:57] <mdz> BenC: also, there seems to be a delay in your email; your last couple of replies have been old, and I've received no reply to my most recent emails
[05:57] <BenC> there was talk about Ubuntu GNU/Linux, and the topic of the firmware in the kernel came up
[05:57] <BenC> mdz: It's either my smtp server, or direcway's...I'll see if I can rule out mine
[06:04] <BenC> hmm...smtp.direcway.com is rejecting most of my outgoing mail
[06:05] <BenC> "Contains FortiGuard URL's"
[06:05] <BenC> stupid
[06:09] <BenC> interesting
[06:10] <BenC> I'm being used to bounce emails somehow
[06:12] <JanC> FortiGuard is some anti-virus &anti-spam filter ?
[06:13] <BenC> it's direcway's filter catching emails coming from my smtp server that are being relayed for some outside hosts
[06:16] <JanC> if you don't use FortiGuard, their filter is broken  :-P
[06:18] <JanC> well, my ISP's filter is broken too, but fortunately I can disable it, and i also have a (secured) relay on a dedicated server that I rent with some friends...
[06:21] <BenC> it's not broken, it's absolutely right
[06:21] <BenC> I have email being relayed off my smtp server
[06:21] <BenC> and I don't know why because I have relay hosts set to my internal network only...I think it may be something with my TLS config changes to exim causing it
[07:00] <zul> BenC: pong
[07:42] <lupine_85> hi, quick question about the edgy rt2x00 legacy drivers...
[07:44] <lupine_85> ...is it really necessary to continue to use the July 2005 codebase for them? e.g. rt2400 is "Ralink RT2400 802.11b WLAN driver 1.2.2 - CVS 2005/07/11"
[07:44] <lupine_85> the later code - even the newest beta - is much more stable, especially for the rt2570 driver
[08:32] <zul> BenC: can you revert this patch as well http://kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-2.6.git;a=commit;h=5aae548f78f22a7069342fecad3f9e2e8d308c55
[08:32] <zul> is the via quirks crap
[09:38] <BenC> zul: it should revert from pulling from dapper
[09:38] <BenC> check and make sure it is
[09:45] <BenC> zul: it should revert when I pull from dapper
[09:45] <BenC> zul: check to make sure
[09:45] <zul> ok
[09:55] <zul> its a bit too late for hrtimers isnt it?
[10:03] <mjg59> Lure: Sure
[10:03] <Lure> lupine_85: ^^^ ;-)
[10:04] <lupine_85> hehe
[10:04] <lupine_85> It's about the rt2x00-legacy drivers
[10:04] <lupine_85> according to modinfo, the code is a year old... I was wondering if there was a reason for that?
[10:04] <lupine_85> e.g. Ralink RT2400 802.11b WLAN driver 1.2.2 - CVS 2005/07/11
[10:05] <BenC> because they are legacy and not updated/worked on
[10:05] <lupine_85> they're still worke don
[10:05] <lupine_85> there have been two new betas since then :)
[10:05] <lupine_85> http://rt2x00.serialmonkey.com/
[10:05] <BenC> well, file a bug and I'll see if I can update them :)
[10:05] <lupine_85> ah, a bug...
[10:05] <lupine_85> ...I mentioned it in a specification
[10:05] <BenC> against linux-source-2.6.17
[10:05] <lupine_85> ok, will do :)
[10:09] <lupine_85> ok, bug #60282
[10:12] <lupine_85> thanks for the pointer
[10:58] <zul> ttyl
[11:49] <mjg59> BenC: Just pushed you a patch for fixing some fan-related stuff
[12:01] <Philip5> anyone here know about how the livecd use the casper scripts or know someone who do?
[12:02] <Philip5> or a ubuntu livecd channel?