[00:00] <jjohansen> running and errand
=== bjf is now known as bjf[afk]
[03:30] <bjf[afk]> :w
[03:58] <vanhoof> :w!
[04:20] <achiang> ZZ
=== lan3y is now known as Laney
[09:52] <diwic> smb, when I open "computer janitor" nothing shows up as being cleaned away, and "sudo apt-get autoremove" does not show any kernels either...
[09:53] <smb> diwic, It usually only shows up excess kernels, so if you have more than 3 or so
[09:53] <smb> and autoremove would not work with kernels
[09:54] <smb> as it only cleans packages automatically installed as dependencies and the primary packages removed
[09:55] <diwic> seems like I have here 35-23, 35-22, 35-20 and 35-19 installed
[09:56] <diwic> btw, when we talk abi bump, we mean the "20" digit of "2.6.35-20.29", right? 
[09:56] <smb> diwic, right, 20 is abi and 29 the upload number
[09:57] <diwic> but -20 and -19 does not have the ubuntu icon in front of them (in synaptic), shouldn't they then show up in the janitor?
[09:58] <smb> Hm, when I run it here I get only one of 6, so 5 seems to be the threshold
[10:00] <diwic> ok
[10:03] <diwic> smb, for autoremove, it would seem wise of dpkg/apt to be able to detect that the dependency is now removed, since linux-meta moved on?
[10:06] <smb> diwic, Not completely sure but I think it depends on how the package was pulled in. I think I see it happen for the headers, but cannot remember to have seen it with the image
[10:06] <smb> It might be something to think of
[10:06] <smb> Or at least to trigger a message on install
[10:07] <diwic> smb, that's true. Interesting
[10:36] <diwic> bug #672964
[10:36] <ubot2> Launchpad bug 672964 in linux (Ubuntu) "udevadm trigger is not permitted while udev is unconfigured (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/672964
[11:53] <simar> Hi there
[11:54] <simar> I want to contribute in kernel bug triaging. I was reading the documents at wiki pages. I got most of it except using arsenal?
[11:54] <simar> Is there anyone avaliable forhelp
[12:02] <cking> simar, I think mentioning this to JFo would be useful. He comes online in a few hours
[12:04] <simar> cking, ya I know that. I tried to ping him but he isn't available yet. So I thought asking openly in the channel might help.
[12:06] <cking> simar, well, JFo is your best bet really
[12:07] <simar> cking, Lets hope that he will come online soon. Thanks a lot though, for attending me..
[12:11] <diwic> simar, thanks for wanting to help out, we need you! :-) So "arsenal" is a tool used to change bug reports in an automatic fashion, e g expiring them or adding comments to them based on specific criterias.
[12:11] <nigelb> so, that's how jfo comments on a lot of bugs at the same time :D
[12:11] <diwic> simar, so if you want to use that method, probably the easiest way is to talk to JFo or bjf[afk] 
[12:12] <cking> yep, bjf can help too - forgot that
[12:12] <diwic> nigelb, yes, that's correct
[12:13] <nigelb> isn't bryce nifty with arsenel?
[12:13] <nigelb> diwic: I was impressed that he managed to catch the name of the poster too (not any more thought :p)
[12:14] <diwic> nigelb, I think bryceh wrote the arsenal scripts originally, but bjf[afk] and JFo are the ones carrying it out for the kernel.
[12:14] <nigelb> diwic: oh, ok :)
[12:15] <diwic> simar, what page is it that references "arsenal"?
[12:27] <simar> hi diwic
[12:27] <simar> hi nigelb
[12:27] <simar> I want to start triaging kernel rightaway .. do i need to know what is arsenal just now?
[12:30] <diwic> simar, no, just get started :-)
[12:30] <simar> diwic, ok thanks
[12:31] <simar> diwic, So what should be my first job? Assigning right subsystem tags...
[12:32] <diwic> simar, it depends on what you know about the kernel 
[12:33] <diwic> simar, making sure all relevant information is present is a good thing e g
[12:33] <simar> diwic, I work on touchpad ... in xserver-xorg-input-synaptics and handle some kernel related stuff also..
[12:33] <diwic> simar, but adding subsystem tags doesn't hurt either
[12:34] <simar> diwic, here my lp page https://launchpad.net/~simar
[12:34] <simar> diwic, I have a strong feeling that i can help something in kernel..
[12:36] <diwic> simar, so there are many things you can do so choose a task you find fun/rewarding to do 
[12:39] <simar> diwic, Is there anything that I need to follow, that is different from normal triaging, while triaging in kernel .. like input subsystem tags etc...
[12:40] <diwic> simar, the only thing that comes to mind is to try to avoid marking things as duplicates unless you're sure both hardware and symptom is exactly the same
[12:40] <simar> diwic, that one i already know
[12:44] <diwic> simar, also, if you're interested in particular subsystems, there were triaging classes held a month or so ago
[12:44] <diwic> I held one about audio
[12:47] <simar> diwic, ya but before that I think I must get myself accustomed to the triaging practises in the kernel team.. 
[12:48] <simar> May I know where are the logs .. anyhow?
[12:50] <diwic> simar, http://irclogs.ubuntu.com/2010/09/11/%23ubuntu-classroom.html
[12:53] <simar> diwic, thanks
[13:28] <simar> diwic, Thanks a lot, these logs are really very helpful
=== jdstrand_ is now known as jdstrand
=== bjf[afk] is now known as bjf
[15:27] <yann2> hello! I am stuck with a kernel problem on hardy, and wanted to know what risk I would be taking installing a lucid kernel on hardy... is it like safe, rather safe, rather not safe, or totally insane :) (it's for a critical server)
[15:27] <yann2> related to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/353070
[15:27] <ubot2> Launchpad bug 353070 in linux (Ubuntu) "BUG: soft lockup - CPU#2 stuck for 11s! [kswapd0:332] (affects: 4) (heat: 8)" [Undecided,Confirmed]
[15:28] <yann2> (which isn't that great either, and justifies that I would take some risk to solve it... not sure how long ext3 will enjoy hard power resets..)
[15:28] <smb> yann2, I'd say somewhere between not safe and insane
[15:31] <yann2> I guessed so... I don't have that many options sadly :(
[15:31] <bjf> smb, sconklin, as far as my thinking goes, it doesn't matter if the bug/patch comes in via a support issue or via a linaro request, the patch needs a bug and the bug needs to be verified in a given -proposed or it's reverted
[15:32] <smb> yann2, afaik the sysfs layout changed to quite some amount and all the kernel drm could be quite a problem. Is upgrading to the next lts a non-option?
[15:32] <bjf> ##
[15:32] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:32] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:32] <bjf> ##
[15:32] <smb> bjf, That would be my understanding
[15:32] <yann2> smb,  yes, it is for a Zimbra server, support for lucid only announced for late january
[15:33] <sconklin> smb: agreed. The new policy is that unless you can verify it we don't take it.
[15:33] <yann2> and the server is crashing like every 5-6 days, with a hard reset needed
[15:33] <smb> yann2, is there by chance any network bonding involved?
[15:34] <yann2> not yet
[15:34] <smb> yann2, Ok, just was thinking it sounded like an old bug report which may or may not be fixed. 
[15:46] <apw`> bjf, to confirm ... the meeting is in 1 hour and 15 minutes ... correct
[15:46] <yann2> alright sent a few options to my boss... looks very close to http://www.youtube.com/watch?v=C9f1TYyvEx8 :)
[15:48] <smb> I guess the make the options so that the right one is picked. Even if it means to reboot at a relative safe time each x days
[15:48] <smb> apw`, I think that is correct
[15:49] <smb> tgardner, You around? Would something obvious strike you when glancing at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415353 ?
[15:49] <ubot2> Launchpad bug 415353 in linux (Ubuntu Lucid) (and 1 other project) "karmic/lucid installation slow on "detecting network hardware" with bnx2x (affects: 2) (dups: 1) (heat: 27)" [Medium,Confirmed]
[15:51]  * apw` notes that google (as always) is showing the thing in the wrong place at least in the US
[15:52]  * smb wonders which us timezone this thing follows
=== apw` is now known as apw
[15:53] <cking> apw, it's a double whammy of daylight saving times changing in US and UK over a space of a couple of weeks that can be so confusing to google calender
[15:54] <apw> cking, yeah cause its _so_ complex to track the location of a calendar entry in a UTC based calendar like the fridge
[15:54] <bjf> apw, yes, meeting in 1 hr, 7 minutes
[15:55] <cking> I make it 1hr 6 mins :-)
[15:55] <apw> bjf, damn google cal.
[15:56] <cooloney> yeah, date -d '17:00 UTC' will tell you the result
[15:56] <cking> nice
[15:57] <sconklin> bjf, apw: when a kernel goes from proposed to updates, isn't it supposed to be pocket copied to -security as well?
[15:57] <apw> sconklin, nope
[15:57] <bjf> sconklin, didn't think so
[15:57] <sconklin> ok.
[15:58] <apw> sconklin, they are overlays only
[15:58] <ogasawara> apw: the day 0 kernel/missed ABI bump regression, was there a bug # for that?  and do you need me to look into helping with a bisect?
[15:58] <smb> sconklin, only security will go into security and updates at the same time
[15:59] <sconklin> smb: ok. Then in the past for your kernel team meeting report, why is there one column for Updates/Security when the versions may differ?
[16:00] <sconklin> is that the more recent of the two?
[16:00] <smb> sconklin, Yes, I tried to save space by making that assumption (always latest updates which is either updates or security)
[16:00] <sconklin> smb: ok, that makes sense
[16:01]  * smb tries to remember what he was thinking last...
[16:02] <apw> ogasawara, the machine turned out to be unreliable phyically, an overheating fault, so the 'worked in -release' 'failed with day-0' is likely related to that and not a real testable case ... so we can ignore it
[16:02] <sconklin> smb: in your verified nnn/mmm did you count the SRU tracking bugs in the mmm total?
[16:03] <smb> sconklin, Yes mmm is the total number of bug reports as seen on the proposed tracking page
[16:03] <sconklin> easy, thanks
[16:03] <tgardner> smb, what was the change that made Maverick so much faster then Lucid? Was it purely installer bits, or was there a timing change in the driver?
[16:03] <ogasawara> apw: ah ok.  I did a palm->face maneuver when I realized I'd forgot to bump the ABI.
[16:03] <smb> tgardner, You are assuming I know that?
[16:04] <apw> smb, you know everything
[16:04] <smb> apw, I know that I do not know that
[16:04] <apw> ogasawara, heheh, not the end of the world
[16:04] <tgardner> smb,  hmm, frankly I'm assuming its your problem :)
[16:04] <tgardner> server dude....
[16:04] <smb> tgardner, Well I hoped the network dude would know something. :)
[16:05] <smb> Ok, it has a wire
[16:05] <tgardner> smb, I'm sure its just some stupidly long delay in the driver.
[16:06] <smb> tgardner, It seems to run into a timeout at some point. Did not see something immediately when scanning over the changes there, so I thought, maybe you may have stumbled over that somehow
[16:07] <smb> tgardner, I guess i will then have a closer look :)
[16:12] <bjf> smb, i probably missed it but did you send out any announcement that your stable tree was up-to-date w.r.t. greg's latest and that we could come and get it?
[16:14] <smb> bjf, You did not miss that. There was no wide announcement yet. Just some verbal, "ok" if at all. I pushed it out to include .32.25 but I am not really sure to remember whether the mainline builds build it
[16:14] <smb> bjf, It is ready without the drm patches though
[16:15] <bjf> smb, ack, thanks
[16:16] <smb> apw, Hm, seems for some reason it did not get build for mainline...
[16:17] <smb> ugh, I might have forgotten to push the tag
[16:23] <ogasawara> smb, bjf, sconklin: couple questions regarding the cve scripts...
[16:23] <ogasawara> smb, bjf, sconklin: I've been using cve-item-start <CVE-####-####> to checkout the CVE's I'm working.
[16:24] <ogasawara> smb, bjf, sconklin: I notice this checks out a separate branch for each CVE.  Is there a different script I should use so that they all live on the same branch, for ex. a "security" branch?
[16:24] <ogasawara> smb, bjf, sconklin: Also, is there a script to then push my patches somewhere, even if I've not ran cve-item-save nor built or tested them yet.  I sorta like having a remote backup of all my work just in case.
[16:24] <bjf> ogasawara, your doing it the way that i do it
[16:24] <smb> ogasawara, Its meant to be a branch on its own, so that one can later pull the seperate branches together
[16:24] <sconklin> ogasawara: no, when you run the scripts at the end of all your work they get assembled
[16:25] <ogasawara> ah, ok
[16:25] <smb> ogasawara, cve-item-save is it
[16:25] <sconklin> you can run cve-item-save multiple times
[16:25] <smb> ogasawara, will push to your repos on zinc so one can get them with cve-item-pull (or cve-release-start)
[16:26] <apw> smb, bad you
[16:26] <smb> sconklin, ogasawara The only downside is that when you have not done work on some release yet it is over eager and sets the status to not-needed for some time
[16:27] <apw> bjf, can we drop none-kernel-n-misc from the meeting -- there are no items on it yet
[16:27] <smb> apw, Doh! Why always me. :-P
[16:27] <bjf> apw, can / will do
[16:28] <apw> bjf, thanks :)
[16:28] <bjf> apw, done
[16:30] <ogasawara> bjf, sconklin: just fyi, I've started working my way up from the bottom of the CVE list.  I'm going to stop for a bit and throw together a compat-wireless-2.6.37 LBM prototype for Lucid and Maverick and then resume CVE work.
[16:30] <sconklin> ogasawara: sounds great, thanks!
[16:30] <bjf> ogasawara, cool, was planning on going top down
[16:31]  * bjf is currently working on maverick stable upstream update
[16:33]  * bjf is running full natty on his x301 and it's working just fine
[16:33] <cking> gobsmacked
[16:34] <smb> apw is working on filling my inbox
[16:34] <cking> denial of service attack?
[16:35] <smb> more of a report of service attack. All these blueprint updates
[16:35] <apw> smb, heh
[16:38] <bjf> sconklin, in my public repo, i've applied the latest upstream stable patches, they build and boot, will send out the announcement with tracking bug shortly
[16:44] <bjf> tgardner, ericm, is talking to me about mvl-dove changes for lucid and i seem to recall you making a support decision about that in the last two weeks
[16:49] <tgardner> ericm|ubuntu, why do we care about mvl-dove in Lucid? There are no shipping products based on it as far as I know.
[16:54] <ericm|ubuntu> tgardner, I need to base hedley on top of that
[16:55] <ericm|ubuntu> tgardner, or I can keep all the crap within hedley
[16:56] <bjf> ##
[16:56] <bjf> ## Ubuntu Kernel Team Meeting - in 5 minutes - #ubuntu-meeting
[16:56] <bjf> ##
[16:56] <smb> sounds like a new meaning of no-project-uses to me...
[16:57] <ericm|ubuntu> smb, heh
[16:58] <ericm|ubuntu> tgardner, what do you think?
=== yofel_ is now known as yofel
[16:59] <tgardner> ericm|ubuntu, you'll have to remind me offline what hedley is and why I should care.
[17:00] <bjf> ##
[17:00] <bjf> ## Meeting starting now
[17:00] <bjf> ##
[17:46] <apw> bjf, confusing, a meeting with discussion
[17:47] <smb> unheard of for quite some time
[17:47] <bjf> apw, agreed, lets not do that again :-)
[17:47] <bjf> so remind me, whey do we have uds?
[17:48] <apw> bjf, heheh well put
[17:48] <smb> So we have about 12 minutes before I get distracted by the server team meeting
[17:49] <sconklin> I have a lunch appointment, so we can either do this in 12 minutes or schedule another meeting
[17:49] <jjohansen> smb: which will have discussion too ...
[17:49] <smb> sconklin, Not sure we manage that in 12 minutes... but we could try
[17:50] <sconklin> For discussion of stable schedule, I'd like to have the people responsible for testing present
[17:50] <apw> a most of us are in the US right now we could do it a little later
[17:50] <smb> Yes we should. It was more about how physically removing the patches not tested
[17:50] <sconklin> but I'm game for discussion of process, such as whether to revert or drop patches
[17:51] <smb> I can drop what I think and then run
[17:51] <sconklin> go ;-)
[17:52] <smb> IMO anything involving a force push should not be part of a standard process. 
[17:52] <smb> But I can see the problem with the changelog
[17:52] <smb> We have done one upload with buglinks and all
[17:53] <smb> Doing another upload to proposed will require to include _all_ changelog entries from the version in updates to current
[17:53] <achiang> can someone educate me on what the abi-<version> file does in the kernel package?
[17:53] <smb> The add and revert is split into two uploads and the janitor unlikely knows how to handle reverts
[17:54] <smb> We might get away by hand-removing the bug numbers from the changelog for the reverted patches
[17:54] <smb> (or script that)
[17:55] <smb> though sometimes the sru team complains about changelog entries without bugnumbers
[17:56] <smb> completely removing the patch comments from the old and new changlog (for the reverts) might end in an upload without apparent patches
[17:56] <smb> So I am not sure I really can offer a good solution atm
[17:56] <ogasawara> I think you can keep the bug number, just remove the "BugLink" string right?
[17:56] <sconklin> While we're planting flags in the ground - I am fundamentally opposed to introducing any more processes which rely on hand-applying things such as this. Every bit of new process we add should be scriptable, even if we have to abuse or redefine tags and changelog text to implement it. The number of human errors we have is way too high.
[17:56] <smb> Except the inherit fear of evil when I hear drop and force-push
[17:57] <smb> ogasawara, The buglink in the patch may not need removal
[17:57] <smb> ogasawara, just the lp # entry in the changelog
[17:57] <sconklin> It seems that we could come up with a solution that reverts and drops buglinks in the changelog
[17:57] <apw> yeah i can see that working
[17:57] <ogasawara> smb: right, and I thought the lp janitor searches for the "BugLink" string
[17:57] <smb> sconklin, right and do scripting for that
[17:57] <ogasawara> smb: so if we just remove that string from the changelog
[17:57] <sconklin> One thing tha worries me is our lack of any way to test these changes before we push the first proposed kernel
[17:58] <jjohansen> smb: you don't have credentials to upload EC2 kernels yet do you?
[17:58] <sconklin> smb: agreed - it could be scripted
[17:58] <smb> ogasawara, I thought not, it searches for the thing generated in the changes file generated from the lp: # strings generated from the buglink
[17:59] <smb> jjohansen, Not that I conciously know about any
[17:59] <sconklin> we will probably find some assumptions that exist such as "no bug will ever go from fix committed and in proposed to wontfix"
[17:59] <jjohansen> smb: okay, I'll bug smoser
[17:59] <smb> sconklin, right, that might be another thing
[18:00] <smb> We have it in fix-committed, it won't go to released after removing the bug references in the changelog
[18:00] <smb> but also not go into won't fix
[18:01] <smb> Though i think thats just what sconklin said
[18:01] <sconklin> going to wontfix is the manual (scripted) step we'll take when it's not verified at the end of the window for verification
[18:01] <bjf> we need a script to put the final comment onto the bug, that can just as easily change the state while it's at it
[18:01] <sconklin> bjf: ack
[18:02] <smb> ack, and by using reverts you have a sensible (at least to me) forward flow from one upload to the revert upload
[18:02] <sconklin> in fact, I'd like to run a script, have it close all unverified bugs wontfix with a text explaining it, then generate a list of reverts to apply so that I can feed that into git
[18:02] <bjf> interesting email from pitti that we are going to be dropping changelogs from packages
[18:03] <smb> sconklin, bjf Probably needs some training or talking to pitti about their archive admin scripts and how they like that
[18:03] <sconklin> One thing I'm afraid of is that reverts make it too easy to put things back in, and I want them really very dead
[18:04] <bjf> sconklin, i don't see how a revert makes it easier to get back in (revert a revert?)
[18:04] <sconklin> yeah, ugly idn't it?
[18:04] <sconklin> isn't it. I'm not that redneck yet ;-)
[18:05] <smb> sconklin, Probably trying to bite yourself while saying it. :)
[18:05] <bjf> sconklin, the policy is that we don't revert a revert, a new, full sru request must be made
[18:05] <sconklin> although it looks like reverting is the concensus, and I'm ok with that. We just have to figure out the tools
[18:05] <skaet> bjf, sconklin - wontfix has the semantics of closed, so shouldn't it really be moved back to "In progress"?   
[18:05] <sconklin> My intention is closed.
[18:06] <bjf> skaet, no, if they can't be bothered to test, it's not a bug we care about
[18:06] <sconklin> what he said
[18:06] <skaet> bjf, sconklin - define "they"
[18:06] <sconklin> The people who file bugs
[18:06] <bjf> skate, "they" is the original bug submitter
[18:07] <skaet> and if the original submitter is on vacation for a week....   seems a bit harsh.
[18:07] <kamal> idea? change it to "Incomplete" and let it auto-expire if "they" don't take further action.
[18:07] <sconklin> if they don't care enough about having it fixed to test a proposed kernel, we're done with it
[18:07] <bjf> skaet, agreed, i think i mentioned that at UDS
[18:07] <smb> interesting question would be what if it is verified by someone else?
[18:08] <sconklin> so - if we are to allow re-inclusion of a patch - who decides?
[18:08] <bjf> smb, i don't think we look closely enough to tell so that would get in
[18:08] <sconklin> Two more acks from the kernel team?
[18:08] <smb> bjf, sounds reasonable
[18:08] <bjf> sconklin, full SRU process, new bug, two acks, etc.
[18:09] <sconklin> I don't care whether it's verified by the exact reporter - I'll take anything that's the correct kernel on the correct hardware
[18:09] <bjf> sconklin, but how do you verify that? I could just write a script which marks all the "verification-needed" to "verification-done"
[18:09] <sconklin> bjf: I can support that, but be aware that our commit logs are going to be horrendous.
[18:10] <sconklin> bjf: I can;t verify anything that I haven't put my hands on. At a certain level, we have to trust people
[18:11] <bjf> sconklin, that was my point w.r.t. "I'll take anything that's the correct kernel on the correct hardware"
[18:11] <sconklin> And I expect that at some point, we'll have to make a value call on something for which the hardware is no longer available.
[18:11] <bjf> sconklin, bottom line is that you'll just have to trust people
[18:11] <sconklin> "I'll take anything for which someone has claimed to have tested the proposed kernel on the specific hardware in the bug"
[18:11] <sconklin> better?
[18:12] <bjf> heh
[18:12] <smb> At least this should make "they" clearer for skaet 
[18:12] <skaet> :)
[18:12] <sconklin> If we don't trust people, all bets are off, and we may as well give up.
[18:13] <smb> "In god we trust, but you pay cash" :)
[18:14] <sconklin> I have to run to a lunch appt. This needs more discussion, want to set a time?
[18:14] <bjf> did we decided anything or just continuing to stir the pot?
[18:15] <sconklin> if we decided anything tentatively I think it is to:
[18:15] <sconklin> use reverts
[18:15] <bjf> if reverts become an issue we can always revisit the issue
[18:15] <sconklin> close bugs either wontfix or incomplete and requrie a new SRU and ack process to repoen
[18:16] <sconklin> investigate the side effects of what we want to do on archive admin scripting
[18:16] <sconklin> make sur ethat what we do is scriptable
[18:16] <sconklin> anything else?
[18:16] <bjf> sounds like a good summation 
[18:16] <smb> ack
=== bjf is now known as bjf[afk]
[18:17] <smb> I think more discussion will come as implementation comes closer if so
[18:17] <sconklin> I suspect that our workload from processing repeat requests will increase in the short term until people figure out that we a re serious about reverting patches - for the first few cycles.
=== sconklin is now known as sconklin-lunch
[18:18] <smb> Yes, that sounds like to be expected
=== BenC__ is now known as BenC
=== bjf[afk] is now known as bjf
=== bjf changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - November-16 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
=== sconklin-lunch is now known as sconklin
[20:29] <manjo> apw, can you install dos2unix on tangarine ? 
[20:30] <apw> manjo, which package is that in
[20:31] <manjo> I think if you do apt-get install dos2unix it works .. it does on my local machines atleast
[20:31] <manjo> manjo@lazy:~$ apt-cache search dos2unix
[20:31] <manjo> dos2unix - convert text file line endings between CRLF and LF
[20:31] <manjo> manjo@lazy:~$
[20:33] <manjo> apw, can you find it ? 
[20:34] <manjo> strangely dos2unix has no package on tangerine... might be in multiverse ?
[20:35] <manjo> apw, I have multiverse on mine ... 
[20:35] <apw> multiverse ... gah
[20:35] <manjo> sorry
[20:36] <manjo> apw, also what do you think of sending rtl8192se to staging ? we are currently carrying that weight around in ubuntu-delta
[20:36] <manjo> apw, I can also send the fw to woodhouse now that they have re-distributable licence for it 
[20:37] <manjo> apw, ofcouse I will check with realtek before I do any of this.. currently I am trying to get it integrated in mainline kernel 
[20:37] <manjo> build
[20:38] <skaet> apw, can you send me a link to the page you and Allison were discussing last week?
[20:42] <apw> manjo, are you sure its not already carried, see tgardner's email
[20:49] <manjo> apw, yep I see what he is saying.. can you install dos2unix ... I have already pulled the latest for Natty, but I need to clean it up before I add and commit 
[20:50] <tgardner> manjo, use tofrodos on tangerine
[20:50] <manjo> ok
[20:51] <sconklin> does this ring any bells with anyone? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/672964
[20:51] <ubot2> Launchpad bug 672964 in linux (Ubuntu Lucid) (and 1 other project) "2.6.32-26 unbootable: does not find root file system (affects: 1) (heat: 8)" [Critical,New]
[20:51] <manjo> tgardner, command not found 
[20:52] <sconklin> Stefan said it looks a bit like a dependency problem from before that was never found
[20:52] <tgardner> manjo, 'man tofrodos'
[20:52] <sconklin> from Stefan earlier - "sort of the kernel gets configured before a udev or inittools update and when that is ready the kernel is not reconfigured"
[20:53] <manjo> tgardner, goit
[20:57] <tgardner> sconklin, did you look in his dmesg? there are a boatload of errors. I think maybe he's got HW problems, or his disk is full.
[20:58] <sconklin> hmm. His misfortune would make me happy if that's the case. Does that make me a bad person?
[20:59] <tgardner> sconklin, hmm, looks like those are cdrom issues.
[20:59] <tgardner> this does not appear to be systemic. I think its something specific to his machine.
[21:00] <sconklin> tgardner: he does state that using the previous kernel works
[21:02] <tgardner> sconklin, right, but it could also be a partial initramfs update.
[21:02] <sconklin> yes
[21:03] <sconklin> I'm finding earlier reports of similar problems
[21:03] <tgardner> bummer
[21:04] <sconklin> The last few comments of this bug could relate https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/358654
[21:05] <ubot2> Launchpad bug 358654 in watershed (Ubuntu) (and 9 other projects) "udevadm trigger is not permitted while udev is unconfigured (affects: 31) (dups: 2) (heat: 161)" [Medium,Fix released]
[21:07] <sconklin> also a long forum thread http://ubuntu-ky.ubuntuforums.org/showthread.php?t=1567147
[21:07] <godber> has this ticket reached anyones eyeballs? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422
[21:07] <ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New]
[21:08] <godber> oh, nice bot
[21:09] <sconklin> jjohansen: ^^
[21:11] <sconklin> godber: thanks, we'll have someone look at it
[21:11] <jjohansen> sconklin: looking
[21:11] <sconklin> see? ;-)
[21:12] <godber> thank you, you guys are magic
[21:12] <sconklin> jjohansen: thanks
[21:33] <godber> uhm, something I did has just stopped the segfaulting in 659422
[21:35] <godber> I installed a bunch of the -25 kernels that might work for my platform {generic,virtual,386}
[21:35] <godber> then I went back and installed linux-image-2.6.32-24
[21:36] <godber> to verify that that worked like the reporter said
[21:36] <godber> it worked, then I rebooted into the -25 (which previously segfaulted), and it worked too
[21:38] <godber> and the console login now says "Ubuntu lucid (development branch)
[21:40] <apw> bug #659422
[21:40] <ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New] https://launchpad.net/bugs/659422
[21:40] <godber> oh, I may have installed from a lucid development iso
[21:41] <godber> I will fix that
[21:41]  * jjohansen -> lunch
[21:41] <godber> apw, yes, thats what I mean
[21:41] <godber> AFAIK it only happens when running as a guest in VMware ESX 4.1
[21:41] <apw> godber, and no idea what you changed which made this work
[21:41] <godber> yeah me neither
[21:42] <godber> unless maybe its related to initrd maybe?
[21:43] <godber> oh, I misread you
[21:44] <godber> the only thing I did was install the previous kernel, reboot to that, then reboot again to the most recent kernel
[21:44] <godber> I am trying to recreate that again
[21:45] <godber> though I am annoyed to discover I am not on 10.04 proper, though I know that fails as well
[22:21]  * ogasawara late lunch
[23:06] <xelister> how to get the ubuntu kernel (checksummed/signed) sources?
[23:07] <xelister> in order to patch it (with parts of grsecurity) and build it
=== bjf is now known as bjf[afk]
[23:17]  * manjo checking out