[00:50] Sarvatt: thanks [00:53] 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] apw: any chance for CONFIG_TASK_DELAY_ACCT to be enabled for -generic (lucid)? [01:43] crimsun, it's best to make the request on the mailing list [01:49] bjf: right, enqueued [09:06] * PCI: AER: fix aer inject result in kernel oops [09:06] - LP: #unable to handle kernel NULL pointer dereference at 0000000000000350 [09:06] smb, ^^ just noticed that in my printchanges! [09:07] uartlite: ttyUL0 at MMIO 0xc8000100 (irq = 30) is a uartlite [09:07] BUG: unable to handle kernel NULL pointer dereference at (null) [09:07] oops ... seems our LP handling is a bit weak [09:08] apw, you confuse me a bit [09:08] fdr printchanges is picking up BUG: text as a buglink and making it into a -LP :# [09:08] * apw goes fix [09:12] apw, Oh, got it [09:12] apw, Thats is on your latet release? [09:12] smb, yep a stable update has tickled the bug ... strange [09:14] * smb goes looking how that commit message looks in full [09:14] its just that line that matters [09:15] we check that BugLink: has an http* after it, but _not_ that Bug: has a number after it ... silly of us [09:15] easy to fix, except there is a major duplication of code here i think i should fix too [09:18] apw, It could be resulting from that we had something different before. /me is so forgetful. Might it have been Bug: #number? [09:19] yeah its the support for Bug: #nnnn,nnnn,nnnn which is broken [09:19] it matches non numeric forms too which is silly [09:22] apw, Very silly. To assume that "Bug:" R us [09:22] heh indeed :) [09:23] apw, Sounds like another thing I want to slurp in when you have fixed it [09:23] yep [09:27] apw: no new bootcharts for today [09:27] installer still broked [09:27] DAMN the installer [09:29] SAVE THE EMPIRE! [09:30] shame we don't have an alpha- coming up, that would focus minds [10:02] mirsal, that patch looked good, and seems to have gotten the nod, nice [10:03] I am about to pick that up [10:03] Should do no harm, so... [10:03] apw, Rebasing seems evil for git describe --contains... grr [10:04] well it'll always only be in the latest one [10:04] 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] i've heard nothing about it no, but then i don't have a huge number of users either [10:05] but its in stable, so its 'offical' if nothing else [10:06] apw, Just was wondering about taking it in for Karmic [10:06] Even without it being on stable there [10:06] i believe we have a bug from someone with it in karmic right? so we have a test subject at least [10:07] 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] heya [12:08] 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] Hi dholbach [12:10] hey matti [12:35] dholbach, Hmm, it might help slightly to know which kernel version was misbehaving... [12:36] smb: the most recent: 2.6.32-12.17 [12:36] (generic, amd64) [12:36] dholbach, Ahh, so you can slap apw for that. :-P [12:36] I just wonder how I could debug it as there's nothing in any of the logs [12:37] One thing might be to have a watch on memory consumption [12:37] also looking at the HDD led helps sometimes [12:37] maybe it's swapping.. [12:39] 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] but how could that be related to the freeze? [12:39] And if ssh is not working, trying to ping [12:39] shouldn't it just swap and be done with it? [12:40] 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] ok, gotcha [12:41] 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] smb: Free? Need to discuss linux-ports-meta bump in karmic. [12:43] 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] smb: ah, good to know - I'll let you guys know [12:44] slytherin, Yes. It might have been delayed by a mistake in the abi number [12:45] smb: Ok. Just wanted to know if you saw my message about same few days ago. [12:46] 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] 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] 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] great. [12:48] linux-ports-meta | 2.6.31.19.15 | karmic-security | source [12:49] Seems there, just was not copied to updates, which looks strange [12:49] I'll try to find someone to fix this [13:01] slytherin, So it seems its updated, but if you are behind a slow mirror (like me) it looks broken [13:01] slytherin, https://edge.launchpad.net/ubuntu/+source/linux-ports-meta [13:01] Ok. [13:01] My last update was about 8 hours before. [13:01] I will check again when I go home [13:06] slytherin, Atm at least de.archive.ubuntu.com seems to slightly disagree. But launchpad usually knows better (or earlier) [13:07] hmm [13:09] slytherin, But the change was just 3hrs ago, so it just needs time [13:09] know. I didn't actually check if the change was made already. === Hellow_ is now known as Hellow [15:03] apw: quick question regarding 'git fetch' on a remote repo [15:04] 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] ? [15:10] I'm seeing a lot of 'deleting plymouth fixed my issue' bugs... who do I need to ping to look into those? [15:10] :) [15:13] JFo: Keybuk is our plymouth guy ;) [15:14] okey dokey :) [15:23] amitk, I think it depends on how your local repo is defined, e.g., --reference, etc [15:25] tgardner: what did you do to rtg? [15:25] amitk, someone stole my nick, so I had to register [15:27] amitk, yeah it does, though it may link them if you use -s i think it is [15:27] 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] amitk, I'd think it would be smart enough to do the linking correctly [15:29] 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] 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] I'll let you know :) [15:39] We're sure you will :) [15:40] smb: I can't recall the last time where I was sitting there and saving "my work" like every 5 minutes :) [15:40] hehe ... we are making your experience more windows like every day [15:41] oh dear [15:41] :) [15:41] Just reminding people of good work practices :-P [15:41] i blame the triager :) [15:42] * JFo runs away crying [15:44] JFo: I'll let you know when the machine freezes again - no problem! [15:45] heh, thanks dholbach === Hedge|Hog is now known as Hedgehog [15:57] anyone know how stable the sha1's in the lnux-2.6-tip tree are? [15:58] * smb has no clue [16:26] JFo: the two people who know plymouth are the two people who can't replicate the bug [16:27] Keybuk, interesting. hardware specific/related then [16:27] no idea [16:27] people are reporting it on hardware that I have [16:27] odd [16:27] it's at least partially a kernel bug [16:28] since the result is that you end up in a situation that's supposed to be impossible [16:28] right [16:28] but it's kernel code that no engineer dares look at [16:28] (the VT code) [16:28] yikes [16:28] you seem to end up in this strange situation where you're simultaneously on VT1 and VT7 [16:28] with X running [16:28] but what you type into X ends up on the underlying VT [16:29] and you only need Alt+F2 to move out of it, not the Ctrl key [16:29] it's very weird [16:33] sounds like it [16:33] * JFo 's head hurts thinking about it [16:37] howdy! has anybody found a fix for the initramfs-tools issue that just popped up? [16:37] Q-FUNK, what do you mean? [16:38] is that the "update-initramfs fails: ./lib/udev/firmware.sh does not exist" issue? [16:38] yup [16:38] I believe so [16:38] one sec [16:39] Q-FUNK, you should be able to apply http://launchpadlibrarian.net/39011493/udev-firmware.patch and then 'update-initramfs -u' again [16:39] that is the fix I saw earlier [16:40] it is from https://launchpad.net/bugs/519855 [16:40] Malone bug 519855 in udev "update-initramfs fails: ./lib/udev/firmware.sh does not exist" [High,Triaged] [16:42] Q-FUNK, let me know how it turns out [16:44] JFo: seems to help [16:44] ok [16:45] thanks! [16:47] Q-FUNK, np [17:21] 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] go for it then [19:06] 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] and there are no .dsc and orig files [19:30] ne78, those are built kernels. I'm not sure what you are looking for. [19:30] ah, wait [19:30] I just read the rest of the first statement [19:31] ne78, mainline builds are vanilla kernels built from the main source tree. linus' tree [19:31] so there is no debian specific goodness if I am not mistaken [19:53] Could anyone point out me on issues about running .31 kernels on Lucid? [19:59] ne78, JFo: there's ubuntu specific .config AFAIK [20:00] akheron, I was under the impression that they were vanilla builds that we automatically built and uploaded from the -stable branch [20:01] yes my question was, where does the debian/ or debian.master come from ? [20:01] how can i reproduce that build [20:02] JFo: the -stable branch of what? [20:02] of the linux tree [20:02] apparently I was wrong [20:02] we drop a modified debian directory in there [20:03] yes that's what i'm looking for [20:03] JFo, at least thats the way he used to do it. [20:03] I think the plan is to start using the built-in packaging target [20:03] doesn't look like it is there anymore tgardner [20:03] or at least that is what ne78 is saying [20:03] * JFo goes to look [20:04] and the script that does that doesn't seem to be public [20:04] hmm, there is a wiki somewhere about mainline build foo [20:05] * JFo looks for that too (good to bookmark) [20:05] JFo, should also be in teh build scripts repo, but taht appears to have moved [20:05] ok [20:05] thanks tgardner [20:06] found 3 pages in the wiki [20:06] https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds [20:06] JFo, maybe its in kteam-tools.git now [20:06] ah hah, yes because amitk and smb cleaned those up at the sprint [20:07] ne78, git://kernel.ubuntu.com/ubuntu/kteam-tools.git [20:07] Oh, yeah. amitk wrote mail that everybody has ignored apparently :) [20:07] lol [20:07] sorry [20:07] cool [20:07] * JFo has a forgettory instead of memory smb [20:08] maybe a link from the ppa to that git would be useful [20:08] smb, I operate on a 'need to think about it' basis [20:08] tgardner, I am with you there [20:08] Yeah, we figured when the repo suddenly vanished it will make people think [20:09] smb, indeed, your evil plan worked [20:09] Thank you. >:-) [21:01] Could anyone pinpoint me on issues that I'll incur running 2.6.31 kernels on Lucid? [21:47] ogasawara: hi! was any decision reached with smb about that Geode patch? [22:03] 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] ogasawara: ok, so what's the solution then? risking to break support for a sub-architecture on an LTS release? [22:05] Declare geode unsuported? Nobody with the skills to do anything about it seems to be interested in fixing it. [22:06] 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] mjg59: that would be silly. you'd essentially render the whole LTSP project obsolete at the same time. [22:06] Q-FUNK: and the patch that smb had didn't seem like a patch but rather adding debugging printk's [22:06] ogasawara: upstream doesn't have access to similar hardware. [22:07] Yeah. Any approach that's just based on changing timings risks breaking when there's an unrelated kernel change [22:07] 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] ah. [22:08] 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] s/about/r/among [22:11] 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] Q-FUNK: there's the daily-live images - http://cdimage.ubuntu.com/daily-live/current/ [22:14] thanks [23:24] nope. not a corrupt filesystem. booting from lucid alpha on a usb stick also freezes with the same issues.