[12:04] <WebMaven> This *could* have been fixed prior to Dapper's release.
[12:05] <crimsun_> lots of issues /could/ have been. Resource limits are problematic.
[12:06] <WebMaven> I'm very grateful that it is supposedly fixed now, but I won't stop worrying until I can verify it for myself.
[12:07] <WebMaven> crimsun_: sure, I understand. I also understand that the squeaky wheel gets the grease.
[12:07] <WebMaven> So, I'm squeaking.
[12:07] <WebMaven> I'll try to squeak more quietly, thoguh.
[12:08] <WebMaven> 'though'
[12:28] <BenC> WebMaven: First reported: 2006-06-03 
[12:28] <BenC> two days after release
[12:29] <BenC> the dupes, did not contain enough info to triage the bug
[02:36] <infinity> BenC: We build kernels for breezy-sparc because we always have?
[02:37] <infinity> BenC: sparc wasn't officially supported in breezy, but it was released (same as hppa and ia64, both of which built fine, BTW)
[02:37] <BenC> infinity: will a security update be held back because of sparc FTBFS?
[02:37] <BenC> not sure if we introduced anything in the last breezy update that would have caused that
[02:37] <infinity> BenC: If it can't be easily fixed, then I suppose not.  We only support amd64/powerpc/i386 on breezy.  That doesn't mean we shouldn't attempt occasionally to make sure the others work.
[02:38] <zul> no i dont think anything touched those files
[02:38] <infinity> BenC: Yes, it was FTBFS last time too, and I bounced you the log, you don't recall?
[02:38] <infinity> (You told me you'd fix it for the next update)
[02:40] <BenC> damn, guess I forgot :)
[02:41] <infinity> Looks like the last one that built successfully was 10.26
[02:41] <infinity> At least, that's the last one that's in the archive.
[02:41] <zul> hmm....should i try to fix it?
[02:42] <infinity> zul: I'd like it if someone did, but it's not the end of the world if no one does, I guess.
[02:42] <infinity> I just dislike dropping a security fix on the floor just because an arch is unsupported (unless it's WAY too much effort)
[02:42] <zul> ill track a crack at it
[02:44] <infinity> Launchpad should have a resonable source history here, if you need to track back through the changes, since this was pre-git:
[02:44] <infinity> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.12
[02:44] <infinity> I know that 10.26 is the last version in the archive.  I'll have to dig a bit to see if that was actually the last version to build correctly.
[02:47] <infinity> Okay, the first time I saw it fail was 10.32, since before that, Fabio was building sparc/security, not me.
[02:47] <infinity> So, it broke bwteen 10.26 and 10.32 (not that helpful, I know, but I imagine the nature of the breakage won't make it that hard to track down which revision was responsible)
[02:52] <mjg59> BenC: How do you get a git tree on kernel.org?
[02:53] <infinity> Sleep with Linus.
[02:53] <infinity> (again)
[02:54] <mjg59> I told him how to make his Mac work
[02:57] <infinity> That may be close enough.
[02:57] <BenC> mjg59: email ftp-master@ftp.kernel.org I believe
[02:58] <BenC> or maybe just @kernel.org
[02:58] <mjg59> You need a kernel.org address?
[02:58] <mjg59> Uh, account
[03:02] <zul> sorry i didnt realized i wasnt registered :(
[03:15] <BenC> mjg59: yeah, you'd get a kernel.org email, ssh account, and access to your own area(s) in the ftp tree
[03:16] <BenC> I'm not sure of their criteria, but I was like "hey biatch, I'm Ben Collins, give me an account foo"
[03:16] <BenC> and they were like "yeah dude, here ya go"
[03:17] <zul> lol
[03:17] <BenC> well, it went something like that :)
[03:18] <BenC> we're getting way too many compiler and MODPOST (linker) warnings
[03:18] <BenC> and there's a lot of modules that cannot even load on smp machines, so I need to disable them
[03:37] <zul> BenC: you did an upload for dapper?
[03:54] <BenC> yeah
[03:58] <zul> cool
[03:59] <zul> ill put up the diffs for breezy/hoary tomorrow morning unless if i can do the uploads myself
[04:10] <zul> anyays night night
[04:10] <BenC> did you do anything besides the i387 for hoary?
[04:10] <zul> what do you mean?
[04:13] <zul> if you mean the other 3 patches that were there yes
[04:14] <BenC> ok, you may want bump the hoary version
[04:14] <zul> yeah i did..
[04:14] <BenC> because I uploaded one after you for the i386 build failure on amd64
[04:14] <BenC> one more than your last one :)
[04:15] <zul> linux-source-2.6.10 (2.6.10-34.19) hoary-security; urgency=low
[04:17] <zul> thats wgat i have in the changelog
[04:17] <BenC> I did a .19
[04:17] <BenC> so maybe make it .20
[04:17] <zul> ok..ill do it tomorrow morning...same for breezy?
[04:18] <zul> oh and i have a couple of patches that im testing right now if they compile alright ill forward them tomorrow
[04:18] <zul> toodles
[04:42] <WebMaven> BenC: You said " the dupes, did not contain enough info to triage the bug"
[04:43] <WebMaven> BenC: But the main dupe had all 'requested' info, ibncluding the information that this was still a problem in the then-current Beta.
[04:44] <WebMaven> The *only* reason my bug eventually had more info is because I kept asking "is there any other info you need" about twice a day.
[04:45] <WebMaven> And becasue I didn't accept people blaming the ralink module.
[04:49] <WebMaven> Only when another user volunteered the info that 'acpi=off' caused the network problems to go away was the problem solved.
[04:52] <WebMaven> Without that info coming to light I'd probabaly still be asking "is there any furter info you need?" at irregular intervals.
[05:10] <BenC> WebMaven: users were asked to try the stuff on the wiki, which included acpi=off
[11:25] <pitti> hi
[11:25] <fabbione> yo
[11:25] <fabbione> BenC: the problem is that for some fucked up mind logic behind -updates
[11:25] <fabbione> if you start using it, you will need to upload the kernel twice each time you do a security or bug fix
[11:25] <fabbione> i personally don't care
[11:26] <fabbione> but pitti can explain the details to you
[11:26] <fabbione> i would prefer to keep all in one pocket for the sake of baby jesus
[11:26] <fabbione> but you decide
[11:26] <BenC> ok
[11:26] <pitti> fabbione: it's not a fucked up logic, it's simply creating another branch we have to care for
[11:27] <BenC> i can do security
[11:27] <fabbione> BenC: do you want me to rephrase something to make it look like security?
[11:27] <pitti> BenC: which changes do we talk about?
[11:27] <fabbione> i am goo at that ;)
[11:27] <BenC> pitti: random fixes from malone
[11:27] <pitti> BenC: are they just some sparc bug fixes, or that sort?
[11:28] <pitti> BenC: safe fixes with obvious patches are fine for me for -security
[11:28] <BenC> no, they touch arch-indep code
[11:28] <pitti> BenC: and since we should not be less careful with -updates, it doesn't really matter which one we break :)
[11:28] <BenC> simple fixes
[11:29] <fabbione> all i care is to get the sparc stuff in asap
[11:29] <fabbione> i don't care how.. beacuse afaik we will need to push d-i into updates due to ogre model build system
[11:31] <pitti> BenC: I'd avoid branching if at all possible
[11:31] <pitti> BenC: so for me the question is not really -security vs. -updates, but rather whether a patch is appropriate for stable or not
[11:31] <BenC> so stick with -security?
[11:31] <pitti> yes
[11:32] <fabbione> did we fix already all the known -security issues?
[11:32] <BenC> yes
[11:33] <fabbione> hmm ok
[11:33] <fabbione> give me 2 minutes
[11:33] <fabbione> i will give you a USN with a fix
[11:36] <BenC> lol
[11:36] <fabbione> BenC, pitti: see /msg
[11:37] <pitti> BenC, fabbione: we don't need to invent anything :) we didn't release the current dapper kernel yet, so just update the currently pending one
[11:38] <fabbione> right
[11:38] <fabbione> that would work too
[11:39] <fabbione> BenC: i leave up to you what you prefer.. 
[11:39] <BenC> so can you reject that and I can merge .41 back to .40 and reupload .40?
[11:40] <fabbione> you will need .41
[11:40] <fabbione> sources for .40 have been accepted and processed
[11:40] <fabbione> only the binaries are sitting in NEW
[11:41] <BenC> ok
[11:42] <fabbione> i guess we will still need the ABI files...
[11:42] <BenC> yeah, gotta have those
[11:42] <fabbione> yeha
[11:42] <fabbione> infinity, Kamion, mdz and elmo are not around
[11:42] <fabbione> our only hope is Znarl
[11:43] <fabbione> or to start waking up people
[11:43] <mjg59> Colin's on holiday
[11:44] <fabbione> mjg59: yeah, that doesn't change that is not around :P
[11:46] <mjg59> It was more "If you try to wake him up, really bad things would happen"
[11:47] <fabbione> mjg59: yeah thanks :) i was told :)
[01:00] <zul> heylo
[02:39] <zul> BenC: i should have the updates for you by lunch time at the earliest
[05:07] <zul> BenC: -20 is up
[05:07] <zul> for hoary at least
[06:19] <bradb> Is there an updated orinoco driver that supports WPA?
[06:43] <mdz> fabbione,BenC: I'll accept the upload
[06:44] <cjb> bradb: Are there orinoco *cards* that support WPA?
[06:44] <mdz> hmm, that's odd, it claims it's been in the queue for 5 days? that seems unlikely
[06:45] <mdz> oh, different upload
[06:45] <mdz> fabbione,BenC: so does linux-source-2.6.17_2.6.17-1.1 need processing or no?
[06:46] <BenC> mdz: Yes, it does, thanks
[07:18] <bradb> cjb: Hm, good question. :)
[08:07] <zul> wheee...iso training is fun
[08:20] <fabbione> mdz: are you driving .15 upload trough dapper-security NEW process?
[08:22] <mdz> fabbione: I was not aware that it needed driving
[08:22] <mdz> I thought you were talking about edgy
[08:23] <fabbione> .15 in dapper-security needs NEW in katie. I am not sure .41 is there already
[08:23] <fabbione> mdz: and pitti doesn't have privileges to do it
[08:25] <fabbione> anyway i am heading off for dinner and football
[08:25] <zul> c ya fabbione 
[08:25] <fabbione> mdz: if there is anything, please just text me
[08:25] <fabbione> cya zulligno ;)
[08:25] <mdz> fabbione: processing it now
[08:25] <mdz> fabbione: done
[08:25] <fabbione> mdz: ok cool. thanks
[08:25] <zul> good luck with ghana
[08:25] <fabbione> zul: thanks
[08:25] <mdz> if .41 builds the same binaries it should go right through
[08:26] <fabbione> mdz: yes, it will and .40 accepted is fine, since it stops at amber checkpoint ;)
[08:27] <fabbione> later guys
[09:06] <Alatius> Not sure if I've come to the right place here, but I wonder, what is the difference between the 386 kernel that is default and the 686 kernel you can download?
[09:06] <Alatius> I mean, is there different patches applied to it, different compile settings, apart from the target platform?
[09:12] <BenC> Alatius: 686 is tuned for 686 CPU's, while 386 will run on 486 and better (it's more generic)
[09:12] <BenC> also the 686 version is SMP enabled
[09:14] <Alatius> Yeah, I tried the 686 instead, since I have a PIII, but I have an issue with the 686 kernel that I didn't have with the 386...
[09:15] <Alatius> My computer will now not shut down itself completely, instead it stays on the message "Will now halt". With the  386 kernel it worked perfectly.
[09:15] <alex_joni> Alatius: sounds like ACPI is not working
[09:15] <Alatius> I guess there's some issue with ACPI, yes.
[09:18] <Alatius> But I wonder, is there any reason why the two kernels would handle it differently?
[09:19] <Alatius> I read on the forums (right before they went offline) that I could try to start with "acpi=force lapic", but it didn't help.
[10:01] <zul> later
[10:27] <zul> heylo
[10:47] <zul> crimsun_: ping
[10:48] <crimsun_> zul: pong
[10:48] <zul> have you seen this? http://www.kernel.org/hg/linux-2.6/?cs=c7a4c2b71aa7
[10:48] <crimsun_> no, looking
[10:49] <crimsun_> ah, I saw that changeset, but no one complained so it wasn't backported
[10:49] <crimsun_> do we have a related bug report now?
[10:50] <zul> yeah..#11149
[10:50] <zul> i was going to grab it
[10:50] <crimsun_> ok, if you want to, that's fine, else I'll queue it for this evening
[10:50] <zul> ok ill will be in my tree tonight
[10:51] <crimsun_> keep an eye on the struct vs. xxx_t changes
[10:53] <zul> ill send you the patch 
[10:54] <crimsun_> ok, thanks.  crimsun at ubuntu
[10:54] <zul> ok
[11:28] <blahblah> can somebody answer a simple question for me regarding kernel update frequency?
[11:28] <zul> blahblah: it should be soon
[11:29] <blahblah> how regularly does it happen?  daily/weekly/monthly?
[11:29] <blahblah> I need a wireless driver and the stock installed kernel doesn't have it
[11:29] <zul> what wireless driver?
[11:30] <blahblah> broadcom, model number I forget
[11:30] <blahblah> system is at work
[11:30] <crimsun_> the bcm43xx has a native driver which works for some values of "works"
[11:31] <blahblah> anyhow I'm just curious because I probably do'nt want to use a distro that has kernel updates quarterly or semi-annually :)
[11:31] <[g2] > I think some of the OpenWRT have played with/worked on that driver
[11:31] <blahblah> I've been using fedora on my laptop for the past two years but I want something less cutting edge
[11:32] <blahblah> and something a bit more cohesive
[11:33] <zul> well we dont do quarerly updates or semi-anual updates if that is what you are asking
[11:33] <blahblah> well, I am asking the frequency............
[11:34] <blahblah> is there a repository that has testing kernels that don't make it into the main repo?
[11:34] <crimsun_> the frequency depends on the accumulation of fixes, generally. Security issues have highest priorities.
[11:34] <blahblah> sure sure
[11:34] <blahblah> but still, are we talking days, weeks or months in general?
[11:35] <crimsun_> well, none of us can predict the future, but weeks to month{,s} is a decent range
[11:35] <blahblah> ok so is it safe to say that there will be a kernel update monthly-ish ?
[11:35] <blahblah> I can live with that
[11:36] <zul> crimsun_: ttp://zulinux.homelinux.net/ubuntu/kernel/patches/cs46xx.patch
[11:36] <crimsun_> I have no idea. I believe LTS wrt kernels is on the agenda at the Paris conf.
[11:36] <crimsun_> zul: danke
[11:37] <BenC> blahblah: if you are talking about stable (released), then monthly is probably worst case
[11:37] <blahblah> ah good deal
[11:37] <BenC> blahblah: however, if you are talking about following our development cycle, I can definitely put a hurt on your b/w with kernel updates
[11:37] <blahblah> if everything worked, I'd be happy with a stock kernel that updated rarely
[11:38] <blahblah> but right now I'm using ndiswrapper w/ fedora and dapper has broken support for the wireless
[11:38] <BenC> which wireless card?
[11:38] <blahblah> apparently the newer kernel versions have fixed drivers so that's what I'm hoping to get
[11:38] <blahblah> it's some broadcom model, forget which
[11:38] <BenC> bcm43xx?
[11:38] <blahblah> yeah
[11:39] <BenC> if it is, you can blacklist bcm43xx and use ndiswrapper just the same as you used to
[11:39] <blahblah> ah
[11:39] <blahblah> can you point me to a doc on how to do that?
[11:39] <blahblah> I do'nt want to kludge my system, but if it's a clean way of doing it I'll be happy with it
[11:40] <blahblah> is there a modules.conf or something to tell it to avoid that module?
[11:40] <BenC> (as root) echo blacklist bcm43xx > /etc/modutils/bcm-blacklist
[11:40] <blahblah> ah excellent
[11:40] <BenC> that'll keep udev from loading it up automatically
[11:40] <blahblah> excellent
[11:41] <blahblah> thanks for the tip
[11:41] <BenC> np
[11:41] <blahblah> adios
[11:42] <zul> i think he was just looking for support
[11:57] <cjb> Hrr.  My machine's been killing itself about once a week since I upgraded to the dapper release.  Maybe it's the temperature or something.