[00:50] <MTecknology> Sarvatt: thanks
[00:53] <Sarvatt> no worries, it really doesn't help much for a ext3 to ext4 conversion regarding fsck times though at any rate, my converted one still takes ~3 minutes to fsck vs the 20 seconds of my native ext4 partition thats 4x bigger and I run e4defrag on it all every other month or so for the past year
[01:41] <crimsun> apw: any chance for CONFIG_TASK_DELAY_ACCT to be enabled for -generic (lucid)?
[01:43] <bjf> crimsun, it's best to make the request on the mailing list
[01:49] <crimsun> bjf: right, enqueued
[09:06] <apw>   * PCI: AER: fix aer inject result in kernel oops
[09:06] <apw>     - LP: #unable to handle kernel NULL pointer dereference at 0000000000000350
[09:06] <apw> smb, ^^ just noticed that in my printchanges!
[09:07] <apw>     uartlite: ttyUL0 at MMIO 0xc8000100 (irq = 30) is a uartlite
[09:07] <apw>     BUG: unable to handle kernel NULL pointer dereference at (null)
[09:07] <apw> oops ... seems our LP handling is a bit weak
[09:08] <smb> apw, you confuse me a bit
[09:08] <apw> fdr printchanges is picking up BUG: text as a buglink and making it into a -LP :#<crap>
[09:08]  * apw goes fix
[09:12] <smb> apw, Oh, got it
[09:12] <smb> apw, Thats is on your latet release?
[09:12] <apw> smb, yep a stable update has tickled the bug ... strange
[09:14]  * smb goes looking how that commit message looks in full
[09:14] <apw> its just that line that matters
[09:15] <apw> we check that BugLink: has an http* after it, but _not_ that Bug: has a number after it ... silly of us
[09:15] <apw> easy to fix, except there is a major duplication of code here i think i should fix too
[09:18] <smb> apw, It could be resulting from that we had something different before. /me is so forgetful. Might it have been Bug: #number?
[09:19] <apw> yeah its the support for Bug: #nnnn,nnnn,nnnn which is broken
[09:19] <apw> it matches non numeric forms too which is silly
[09:22] <smb> apw, Very silly. To assume that "Bug:" R us
[09:22] <apw> heh indeed :)
[09:23] <smb> apw, Sounds like another thing I want to slurp in when you have fixed it
[09:23] <apw> yep
[09:27] <Keybuk> apw: no new bootcharts for today
[09:27] <Keybuk> installer still broked
[09:27] <apw> DAMN the installer
[09:29] <Keybuk> SAVE THE EMPIRE!
[09:30] <apw> shame we don't have an alpha- coming up, that would focus minds
[10:02] <apw> mirsal, that patch looked good, and seems to have gotten the nod, nice
[10:03] <smb> I am about to pick that up
[10:03] <smb> Should do no harm, so...
[10:03] <smb> apw, Rebasing seems evil for git describe --contains... grr 
[10:04] <apw> well it'll always only be in the latest one
[10:04] <smb> apw, So that ALPS protocol patch seems to be in since around Jan-27. Heard or seen an angry mop of ALPS users recently?
[10:05] <apw> i've heard nothing about it no, but then i don't have a huge number of users either
[10:05] <apw> but its in stable, so its 'offical' if nothing else
[10:06] <smb> apw, Just was wondering about taking it in for Karmic
[10:06] <smb> Even without it being on stable there
[10:06] <apw> i believe we have a bug from someone with it in karmic right?  so we have a test subject at least
[10:07] <smb> I believe there was something. I just need to check back whether it was "only" the maintainer. But I think it was someone with the problem for real
[12:06] <dholbach> heya
[12:08] <dholbach> I had my amd64 desktop machine freeze a couple of times this morning (music stuttering, X froze, couldn't ssh in, but magic sysrq still worked), but I didn't get anything in any logs, with the 2.6.31-20 kernel the machine is running for over an hour now without any problems - can anybody help me debug this somehow?
[12:10] <matti> Hi dholbach 
[12:10] <dholbach> hey matti
[12:35] <smb> dholbach, Hmm, it might help slightly to know which kernel version was misbehaving...
[12:36] <dholbach> smb: the most recent: 2.6.32-12.17
[12:36] <dholbach> (generic, amd64)
[12:36] <smb> dholbach, Ahh, so you can slap apw for that. :-P
[12:36] <dholbach> I just wonder how I could debug it as there's nothing in any of the logs
[12:37] <smb> One thing might be to have a watch on memory consumption
[12:37] <alex_joni> also looking at the HDD led helps sometimes
[12:37] <alex_joni> maybe it's swapping..
[12:39] <dholbach> I was running 2 or 3 pbuilders, listening to music, fetching mails, surfing the web, so there was definitely some HDD activity and maybe I even ran out of mem (only 2G in there)
[12:39] <dholbach> but how could that be related to the freeze?
[12:39] <smb> And if ssh is not working, trying to ping
[12:39] <dholbach> shouldn't it just swap and be done with it?
[12:40] <smb> Depending on your memory it might swap out for a while and then start killing things or hang if there is something wrong with memory management
[12:40] <dholbach> ok, gotcha
[12:41] <dholbach> the machine was maybe running for 5-10 minutes, but yeah, next time I try using the current lucid kernel I'll have a look at it
[12:42] <slytherin> smb: Free? Need to discuss linux-ports-meta bump in karmic.
[12:43] <smb> dholbach, Can also be a deadlock on something. Thats probably harder to find out. On tight spinlocks the fans on laptops would go up, but desktops are sturdier
[12:44] <dholbach> smb: ah, good to know - I'll let you guys know
[12:44] <smb> slytherin, Yes. It might have been delayed by a mistake in the abi number
[12:45] <slytherin> smb: Ok. Just wanted to know if you saw my message about same few days ago.
[12:46] <smb> slytherin, Hm, a few days ago we were all on a sprint which is prone to miss messages. So it might be worth repeating
[12:47] <slytherin> smb: Nothing special. I just wanted to point out that the wrong kernels were being pulled by security update i.e. -15 instead of -19.
[12:48] <smb> slytherin, Ah, yep. I found out yesterday when going over the current versions. A -19 has been sent for upload yesterday, so I hope this hits today
[12:48] <slytherin> great.
[12:48] <smb> linux-ports-meta | 2.6.31.19.15 | karmic-security | source
[12:49] <smb> Seems there, just was not copied to updates, which looks strange
[12:49] <smb> I'll try to find someone to fix this
[13:01] <smb> slytherin, So it seems its updated, but if you are behind a slow mirror (like me) it looks broken
[13:01] <smb> slytherin, https://edge.launchpad.net/ubuntu/+source/linux-ports-meta
[13:01] <slytherin> Ok. 
[13:01] <slytherin> My last update was about 8 hours before.
[13:01] <slytherin> I will check again when I go home
[13:06] <smb> slytherin, Atm at least de.archive.ubuntu.com seems to slightly disagree. But launchpad usually knows better (or earlier)
[13:07] <slytherin> hmm
[13:09] <smb> slytherin, But the change was just 3hrs ago, so it just needs time
[13:09] <slytherin>  know. I didn't actually check if the change was made already.
[15:03] <amitk> apw: quick question regarding 'git fetch' on a remote repo
[15:04] <amitk> if the remote repo is a local one (on the HDD), does git fetch copy the objects from that remote repo into the local one.
[15:04] <amitk> ?
[15:10] <JFo> I'm seeing a lot of 'deleting plymouth fixed my issue' bugs... who do I need to ping to look into those?
[15:10] <JFo> :)
[15:13] <amitk> JFo: Keybuk is our plymouth guy ;)
[15:14] <JFo> okey dokey :)
[15:23] <tgardner> amitk, I think it depends on how your local repo is defined, e.g., --reference, etc
[15:25] <amitk> tgardner: what did you do to rtg?
[15:25] <tgardner> amitk, someone stole my nick, so I had to register
[15:27] <apw> amitk, yeah it does, though it may link them if you use -s i think it is
[15:27] <amitk> tgardner: the remote is a subsystem maintainers tree that --reference's linux-2.6 in the same dir. So the real objects are in linux-2.6. I guess I need to monitor size of the directories next time I do this.
[15:28] <tgardner> amitk, I'd think it would be smart enough to do the linking correctly
[15:29] <amitk> apw: aah, so I'd end up with linux-2.6 objects in almost every git tree I have since I add a remote to linux-2.6 in them and run a 'git fetch linux-2.6'
[15:39] <dholbach> apw, smb: now I can't reproduce the machine freeze any more - I've been test-pbuilder-ing chromium and the kernel and exposed the machine to some other work and it still hasn't frozen with 2.6.32-12.17
[15:39] <dholbach> I'll let you know :)
[15:39] <smb> We're sure you will :)
[15:40] <dholbach> smb: I can't recall the last time where I was sitting there and saving "my work" like every 5 minutes :)
[15:40] <apw> hehe ... we are making your experience more windows like every day
[15:41] <JFo> oh dear
[15:41] <JFo> :)
[15:41] <smb> Just reminding people of good work practices :-P
[15:41] <apw> i blame the triager :)
[15:42]  * JFo runs away crying
[15:44] <dholbach> JFo: I'll let you know when the machine freezes again - no problem!
[15:45] <JFo> heh, thanks dholbach 
[15:57] <apw> anyone know how stable the sha1's in the lnux-2.6-tip tree are?
[15:58]  * smb has no clue
[16:26] <Keybuk> JFo: the two people who know plymouth are the two people who can't replicate the bug
[16:27] <JFo> Keybuk, interesting. hardware specific/related then
[16:27] <Keybuk> no idea
[16:27] <Keybuk> people are reporting it on hardware that I have
[16:27] <JFo> odd
[16:27] <Keybuk> it's at least partially a kernel bug
[16:28] <Keybuk> since the result is that you end up in a situation that's supposed to be impossible
[16:28] <JFo> right
[16:28] <Keybuk> but it's kernel code that no engineer dares look at
[16:28] <Keybuk> (the VT code)
[16:28] <JFo> yikes
[16:28] <Keybuk> you seem to end up in this strange situation where you're simultaneously on VT1 and VT7
[16:28] <Keybuk> with X running
[16:28] <Keybuk> but what you type into X ends up on the underlying VT
[16:29] <Keybuk> and you only need Alt+F2 to move out of it, not the Ctrl key
[16:29] <Keybuk> it's very weird
[16:33] <JFo> sounds like it
[16:33]  * JFo 's head hurts thinking about it
[16:37] <Q-FUNK> howdy! has anybody found a fix for the initramfs-tools issue that just popped up?
[16:37] <JFo> Q-FUNK, what do you mean?
[16:38] <JFo> is that the  "update-initramfs fails: ./lib/udev/firmware.sh does not exist" issue?
[16:38] <Q-FUNK> yup
[16:38] <JFo> I believe so
[16:38] <JFo> one sec
[16:39] <JFo> Q-FUNK,  you should be able to apply http://launchpadlibrarian.net/39011493/udev-firmware.patch and then 'update-initramfs -u' again
[16:39] <JFo> that is the fix I saw earlier
[16:40] <JFo> it is from https://launchpad.net/bugs/519855
[16:40] <ubot3> Malone bug 519855 in udev "update-initramfs fails: ./lib/udev/firmware.sh does not exist" [High,Triaged] 
[16:42] <JFo> Q-FUNK, let me know how it turns out
[16:44] <Q-FUNK> JFo: seems to help
[16:44] <JFo> ok
[16:45] <Q-FUNK> thanks!
[16:47] <JFo> Q-FUNK, np
[17:21] <Sarvatt> Keybuk: speaking of plymouth, it needs a little lucid only update for lbm-nouveau which will be landing soon - http://sarvatt.com/downloads/patches/plymouth-lbm-nouveau.patch
[17:22] <Keybuk> go for it then
[19:06] <ne78> How can i rebuild the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33-rc7/ , linux-source-2.6.33_2.6.33-020633rc7_all.deb doesn't contain the debian directory where can i get it ?
[19:06] <ne78> and there are no .dsc and orig files
[19:30] <JFo> ne78, those are built kernels. I'm not sure what you are looking for.
[19:30] <JFo> ah, wait
[19:30] <JFo> I just read the rest of the first statement
[19:31] <JFo> ne78, mainline builds are vanilla kernels built from the main source tree. linus' tree
[19:31] <JFo> so there is no debian specific goodness if I am not mistaken
[19:53] <abogani> Could anyone point out me on issues about running .31 kernels on Lucid?
[19:59] <akheron> ne78, JFo: there's ubuntu specific .config AFAIK
[20:00] <JFo> akheron, I was under the impression that they were vanilla builds that we automatically built and uploaded from the -stable branch
[20:01] <ne78> yes my question was, where does the debian/ or debian.master come from ?
[20:01] <ne78> how can i reproduce that build
[20:02] <akheron> JFo: the -stable branch of what?
[20:02] <JFo> of the linux tree
[20:02] <JFo> apparently I was wrong
[20:02] <JFo> we drop a modified debian directory in there
[20:03] <ne78> yes that's what i'm looking for
[20:03] <tgardner> JFo, at least thats the way he used to do it.
[20:03] <JFo> I think the plan is to start using the built-in packaging target
[20:03] <JFo> doesn't look like it is there anymore tgardner 
[20:03] <JFo> or at least that is what ne78 is saying
[20:03]  * JFo goes to look
[20:04] <ne78> and the script that does that doesn't seem to be public
[20:04] <tgardner> hmm, there is a wiki somewhere about mainline build foo
[20:05]  * JFo looks for that too (good to bookmark)
[20:05] <tgardner> JFo, should also be in teh build scripts repo, but taht appears to have moved
[20:05] <JFo> ok
[20:05] <JFo> thanks tgardner 
[20:06] <JFo> found 3 pages in the wiki
[20:06] <JFo> https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds
[20:06] <tgardner> JFo, maybe its in kteam-tools.git now
[20:06] <JFo> ah hah, yes because amitk and smb cleaned those up at the sprint
[20:07] <tgardner> ne78, git://kernel.ubuntu.com/ubuntu/kteam-tools.git
[20:07] <smb> Oh, yeah. amitk wrote mail that everybody has ignored apparently :)
[20:07] <JFo> lol
[20:07] <smb> sorry
[20:07] <ne78> cool
[20:07]  * JFo has a forgettory instead of memory smb
[20:08] <ne78> maybe a link from the ppa to that git would be useful
[20:08] <tgardner> smb, I operate on a 'need to think about it' basis
[20:08] <JFo> tgardner, I am with you there
[20:08] <smb> Yeah, we figured when the repo suddenly vanished it will make people think
[20:09] <tgardner> smb, indeed, your evil plan worked
[20:09] <smb> Thank you. >:-)
[21:01] <abogani> Could anyone pinpoint me on issues that I'll incur running 2.6.31 kernels on Lucid?
[21:47] <Q-FUNK> ogasawara: hi! was any decision reached with smb about that Geode patch?
[22:03] <ogasawara> Q-FUNK: I chatted with him, sounded like he didn't want to submit it for lucid since it's not a proper fix
[22:04] <Q-FUNK> ogasawara: ok, so what's the solution then? risking to break support for a sub-architecture on an LTS release?
[22:05] <mjg59> Declare geode unsuported? Nobody with the skills to do anything about it seems to be interested in fixing it.
[22:06] <ogasawara> Q-FUNK: from reading the upstream bug it seems pretty specific to the hw that you have as upstream is unable to reproduce
[22:06] <Q-FUNK> mjg59: that would be silly. you'd essentially render the whole LTSP project obsolete at the same time.
[22:06] <ogasawara> Q-FUNK: and the patch that smb had didn't seem like a patch but rather adding debugging printk's
[22:06] <Q-FUNK> ogasawara: upstream doesn't have access to similar hardware.
[22:07] <mjg59> Yeah. Any approach that's just based on changing timings risks breaking when there's an unrelated kernel change
[22:07] <Q-FUNK> I fully agree that adding printk's is an odd kuldge, but if it succeeds in making that particular kidn of hardware boot again, why not?
[22:07] <Q-FUNK> ah.
[22:08] <Q-FUNK> the thing is, that particular hardware is rather common about the thin client users covered by LTSP.  if an LTS suddenly drops support for it, that's gonna be a mess.
[22:09] <Q-FUNK> s/about/r/among
[22:11] <Q-FUNK> something just popped into mind:  do we have nightly builds of the upcoming ISO for Lucid?   if we do, I could make a USB stick and see if *that* displays the same symptoms, just  to rule out a progresssive corruptino of the filesstem on that hardware's hdd.
[22:12] <ogasawara> Q-FUNK: there's the daily-live images - http://cdimage.ubuntu.com/daily-live/current/
[22:14] <Q-FUNK> thanks
[23:24] <Q-FUNK> nope.  not a corrupt filesystem.  booting from lucid alpha on a usb stick also freezes with the same issues.