[01:16] <Kamping_Kaiser> kees, could the changes to linux-ubuntu-modules-2.6.24-23-386 mean linux-image-* meta packages (such as linux-image-386) need to get rebuilt? http://packages.ubuntu.com/search?keywords=linux-image-386 has different versions for hardy and hardy-updates. all other releases have the same versions in the release and security pockets
[01:18] <infinity> Kamping_Kaiser: Looks like they need a copy, yes.
[01:18] <infinity> kees: Do you want me to copy linux-meta from updates to security?
[01:18] <infinity> kees: (Assuming you've verified that's a good idea...)
[01:19] <Kamping_Kaiser> thanks.
[01:20] <kees> infinity: it's already there, isn't it?
[01:21] <kees> infinity: is that what's still missing?
[01:21] <infinity> kees: linux-meta on hardy still points at -22
[01:21] <infinity> kees: (in security, that is)
[01:22] <infinity> kees: updates has the -23 bump.
[01:22] <infinity> kees: Assuming all of LUM, LBM, etc are happily published, we should copy -meta, yes.
[01:24]  * kees facepalms
[01:24] <kees> infinity: yes please.
[01:24] <kees> aaaargh
[01:25] <infinity> (copying)
[01:25] <Kamping_Kaiser> \o/
[01:26] <infinity> kees: There.  Just pending a publisher run now.
[01:26] <kees> infinity: thanks.  this is actually a serious error on my part.  :(
[01:27] <kees> this means that only really vigilant hardy admins have been running an updated kernel on hardy.
[01:27] <Kamping_Kaiser> infinity, thanks :)
[01:29] <infinity> kees: Well, it'll all resolve itself shortly...
[01:29] <infinity> kees: And if you choose me for a peer reviewer on the next performance review cycle, I'll try not to mention it. :P
[01:30] <kees> infinity: yeah, and hit the datacenter too
[01:32] <Kamping_Kaiser> how often does the publish run happen?
[01:33] <infinity> Next one's at :03
[01:33] <infinity> You should see it mostly pushed to mirrors and such in about an hour and a half.  Ish.
[01:34] <Kamping_Kaiser> ok. Then i'll give it a few hours before trying.
[01:34] <Kamping_Kaiser> tyvm both.
[01:44] <kees> infinity: well, actually, this just means nearly no-one runs with -updates.
[01:44] <infinity> kees: Yeah, almost everyone uses -updates, so it shouldn't be a big deal.
[02:31] <Kamping_Kaiser> gNewSense doesn't officially support -updates, hence I've been chasing this issue here
[03:09] <infinity> Kamping_Kaiser: Oh, that linux-meta thing should be long fixed on pretty much all mirrors by now.
[03:09] <Kamping_Kaiser> infinity, thanks, i'll kick the mirrors here and see if they've picked it up yet
[03:38] <Superdweeb> hey guys, do you know why my system hangs for about .8 seconds and tells me  "IO APIC resources could not be initialized" ?
[03:38] <Superdweeb> I've got my system booting in about 9 seconds now :-D
[13:29] <mvo> smb_tp: re bug #353534 - I can add code in update-manager to transition people, but I need to know for what /proc/cpuinfo values its safe to move to -generic and which ones need to stay on the old kernel
[13:29] <ubot3> Malone bug 353534 in update-manager "dapper->hardy->intrepid upgrade path leaves user with unsupported kernel" [Undecided,New] https://launchpad.net/bugs/353534
[13:31] <smb_tp> mvo, Good question. Everything 586 can go generic... A sec...
[13:35] <smb_tp> mvo, The problem is I cannot say which flags this would be. From the config option everything AMD K5, Cyrix 5x86, Pentium Pro/MMX and newer would be good.
[13:36] <mvo> smb_tp: is there a way to figure that out from the cpu familty or the model number? I would rather not want to do string matching there :) ideally would be the flags I guess, but you said this is problematic
[13:40] <smb_tp> As there is a special option M586TSC for the Pentium-Classic and M586MMX for Pentium-MMX one could thing mmx and tsc might be something, but still would leave the other cpus outside. And I got no 486 / 586. Well not completely true, I got a Pentium-90 laptop but with 64MB memory it is hard to get somehing running...
[20:10] <lamont> rtg: heh
[20:10] <rtg> lamont: dude
[20:11] <lamont> told you you'd be back. :-p
[20:11] <lamont> doing your chowns now
[20:11] <rtg> thanks, you're a pal :)
[21:00] <maco> I know it's not the right time in the release to worry about this bug, but it's one that I'm getting pretty confused by so maybe someone else who understands these things better can help.  Bug 272530
[21:01] <ubot3> Malone bug 272530 in linux "64-bit Intrepid automatic permanent reboot loop related to having exactly 4GB of memory" [High,Triaged] https://launchpad.net/bugs/272530
[21:02] <maco> It's something that occurs only with 4GB of memory.  noacpi gets rid of it. BIOS update gets rid of it, and oh now someone just interjected that in older versions of CentOS it didn't exist at all, so maybe something changed in the kernel to make certain newer kernels incompatible with the BIOS?
[21:03] <dtchen> quite possibly, but you'll need to walk the kernels trees
[21:06] <ogasawara> rtg: fyi https://bugs.edge.launchpad.net/ubuntu/+bug/330824/comments/95
[21:06] <ubot3> ogasawara: Error: Could not parse data returned by Malone: timed out
[21:06] <rtg> ogasawara: I've been following it. In fact, I'm building his config right now
[21:07] <ogasawara> rtg: ok cool
[21:07] <rtg> ogasawara: you could do it as well :)
[21:08]  * ogasawara fires up a build
[21:08] <rtg> ogasawara: I compared it against 32 bit -generic. There are only 4K+ lines different.
[21:08] <ogasawara> heh, only
[21:10] <rtg> ogasawara: hmm, maybe thats because its based on -server since I see PAE is set.
[21:11] <rtg> but, there are only 67 lines between config.generic and config.server that are unique
[21:22] <rtg> ogasawara: do you have a 32 bit installed machine? Everything I have is 64 
[21:23] <ogasawara> rtg: I have a 32 bit, just finished cloning the jaunty tree
[21:24] <rtg> ogasawara: at least that worked. I just changed the privs on zinc
[23:43] <lamont> zinc rebooting, sorry about that
[23:45] <macli> hi, how do I use git to check out latest kernel tree? git clone git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git ?