[12:12] <pitti> rebooting, brb -- hopefully ;)
[12:13] <bf> thanks all
[12:13] <mdz> BenC: is there a problem with the candidate kernel?
[12:14] <mdz> I was just about to test it
[12:14] <BenC> mdz: There's an issue showing up on some systems where the revalidation of the drive shows bogus native size
[12:14] <BenC> mdz: caused by my change to keep from bumping the ABI...reverting back to the original patch from kyle fixes it
[12:15] <BenC> mdz: but it means an ABI bump
[12:16] <BenC> mdz: I'm assuming we have no choice, so I'll just get this uploaded and punt lrm/linux-meta/backports right behind it
[12:16] <BenC> pitti: good?
[12:17] <BenC> sweet
[12:17] <dholbach> yoohoo
[12:17] <BenC> pitti, dholbach: thanks for testing
[12:17] <dholbach> np at all
[12:17] <dholbach> keybuk's network-manager change works nicely for me too
[12:17] <pitti> BenC: looks a bit weird in dmesg, but seems to work
[12:18] <pitti> BenC:
[12:18] <pitti> [   35.107711]  ata1.00: ata_hpa_resize 1: sectors = 25408559, hpa_sectors = 25410672
[12:18] <pitti> ^ small disk, looks reasonable
[12:18] <pitti> [   35.475432]  ata2.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = -1348362576
[12:18] <BenC> I want to keep the debug messages just in case of issues, but I think we are stable with this now
[12:18] <pitti> ^ large disk, looks like a signedness issue?
[12:18] <BenC> ooh, I can fix that printk
[12:18] <BenC> looks like a lld instead of an llu
[12:18] <pitti> oh, if it's just a %i vs. %u in the printk, then it's no problem
[12:19] <mdz> BenC: sigh
[12:19] <kylem> it's a u64, the bit 63 should not be set.
[12:21] <mdz> dholbach: what's your network setup?
[12:21] <kylem> pitti, hda is 12GB?
[12:21] <pitti> yay, n-m is good for me as well; /me replies to u-devel@
[12:21] <pitti> kylem: yes
[12:21] <dholbach> mdz: one network interface using dhcp via cable - it had the "broken network icon" before
[12:22] <Kmos> n-m works fine here too
[12:22] <kylem> pitti, ok, output looks slightly suspicious. i suspect the lba28 codepath is less well tested.
[12:22] <stgraber> n-m is now working for me too (ethernet/wireless)
[12:22] <kylem> pitti, i'll doublecheck it.
[12:22] <pitti> kylem: want the full dmesg?
[12:22] <kylem> pitti, please.
[12:23] <pitti> kylem: http://people.ubuntu.com/~pitti/tmp/dmesg.txt
[12:23] <kylem> pitti, thanks. brb. gotta grab food.
[12:23] <pitti> kylem, BenC: cd's fine as well
[12:24] <pitti> ok, that means bedtime, I think
[12:25] <ajmitch> night pitti
[12:31] <mdz> BenC: do you have a new i386 kernel for testing?
[12:33] <mvo> nm looks good for me
[12:35] <heno> BenC: new kernel works on two amd64 systems here, including the one that broke earlier
[12:37] <BenC> heno: thanks
[12:37] <BenC> mdz: No, the one there seems to be working for everyone though
[12:37] <dholbach> n-m works ok on the laptop (wifi and cable) too
[12:37] <BenC> kylem: why are we using u64 for libata sectors when ide uses unsigned long long?
[12:44] <dholbach> night guys - see you tomorrow, I'm happy with the new kernel and the new network-manager
[12:44] <somerville32> :D
[12:51] <mvo> BenC: new kernel boots/works fine for me so far (amd64)
[12:52] <BenC> mvo: thanks
[12:55] <mvo> good night, see you tomorrow. new kernel + NM are good for me as well
[01:05] <seb128> n-m update works fine on my desktop (using a static config on wired eth) and on my laptop (using the wireless connection)
[01:06] <BenC> anyone experienced the amd64 problem with my first kernel?
[01:25] <BenC> infinity2: ping?
[02:15] <mheily> Greetings.. I was just in #ubuntu-bugs and they told me to come here to discuss escalating the resolution of bug # 104332 for either feisty or feisty-updates.  There is a grave problem with the rdesktop package that causes segfaults when connecting to Windows 2000 servers in 8bpp mode or to some Windows 2003 servers.  I prepared a simple one-line patch that fixes the problem and has been committed into the upstream CVS.  If anyone would b
[02:17] <jk-> hi
[02:17] <jk-> anyone here with ps3 mojo ?
[02:18] <cjwatson> jk-: a bit
[02:18] <jk-> ah, hi cjwatson.
[02:18] <jk-> was wondering if I could sort out some integration with the ps3 iso and petitboot.
[02:18] <cjwatson> oh, petitboot will probably be post-feisty for s
[02:18] <cjwatson> us
[02:19] <cjwatson> anything specific/easy you're looking for? :)
[02:19] <mheily> brb
[02:19] <jk-> ah, i'm just wondering if we can include some icon directives in the kboot.conf
[02:20] <jk-> actually, the kboot.conf isn't really suitable for extending in that way
[02:20] <jk-> but petitboot supports other bootloader configi files.
[02:20] <jk-> -i
[02:21] <cjwatson> jk-: are older kboots liable to ignore that?
[02:21] <jk-> cjwatson: no, so i'd suggest using a different config file format (eg yaboot.conf, or petitboot.conf)
[02:22] <jk-> I believe kboot will happily ignore those :)
[02:22] <cjwatson> ok, that we won't be changing for feisty
[02:22] <jk-> ok, no probs :)
[02:23] <cjwatson> but you can certainly let me know in a week and I'll change it for gutsy :-)
[02:23] <jk-> so for post-feisty, you'd look at putting both config files on the one iso?
[02:23] <cjwatson> sure
[02:23] <jk-> neat.
[02:24] <cjwatson> changing to just yaboot.conf would actually be pretty good, save us effort
[02:25] <cjwatson> Ben had mentioned petitboot to me already, though I haven't checked it out in any detail
[02:26] <cjwatson> jk-: good idea to have it parse existing configuration files. Out of interest, can it do grub2?
[02:26] <jk-> yeah, I take it you folks have more important things on your plate at the moment :)
[02:26] <jk-> not at the moment, but we can add a grub2 parser...
[02:26] <mheily> The essence of the rdesktop bug is that the program passes an invalid parameter to Xlib when creating an image under certain circumstances.  Previous versions of Xlib would ignore the invalid parameter and just "do the right thing".  The new version of Xlib rejects the entire operation and returns a NULL pointer, which rdesktop fails to check, thus causing a segfault. My patch merely changes the parameter to 0, which means "do the right t
[02:27] <cjwatson> not critical at the moment, just 'cos switching to grub2 has been one of the things on our theoretical plate for a while
[02:27] <jk-> the only problem is that the existing formats don't have any facility for specifying icons for boot options
[02:27] <jk-> (AFAIK)
[02:27] <cjwatson> pretty sure at least yaboot.conf should ignore unknown keys
[02:27] <jk-> we can add icon=blah.png directive for yaboot.conf, as they'll be ignored
[02:27] <jk-> snap
[02:28] <cjwatson> actually I'd thought that kboot basically shoved keys into the environment
[02:29] <cjwatson> but I haven't really looked at its config file parsing in any detail
[02:31] <jk-> yeah, the format is basically label="stuff"
[03:12] <kylem> BenC, can you name a platform where unsigned long long isn't u63?
[03:12] <kylem> er, u64
[03:13] <BenC> kylem: I know it is, but usually on 64-bit platforms that use "unsigned long" for u64...just wondering why one subsystem went one way and the other used the explicit unsigned long long
[03:14] <kylem> well, it's a 64bit quantity and i'm pedantic, i guess...
[03:15] <BenC> the rest of libata uses u64, so it makes sense to keep it consistent...I was just being curious :)
[03:15] <kylem> yeah.
[03:16] <BenC> I've narrowed down the problem a bit
[03:16] <_ion> I want a computer where unsigned long long is u63.
[03:17] <mheily> my PDP/8 has a 63-bit unsigned long long..
[03:17] <BenC> the first call to ata_exec_internal() to get the native size returns ok, but subsequent calls leave values in tf.hob_lba[lmh]  that match the tf.lba[lmh]  ones
[03:18] <kylem> sounds like LBA48 is disabled somehow.
[03:18] <kylem> hmm, no. hrm.
[03:18] <BenC>         printk("%02x %02x %02x %02x %02x %02x: %016llx \n",
[03:18] <BenC>                tf->hob_lbah, tf->hob_lbam, tf->hob_lbal,
[03:18] <BenC>                tf->lbah, tf->lbam, tf->lbal, sectors);
[03:18] <BenC> that printk in ata_tf_to_lba48() produces this...
[03:18] <jdong> _ion: I have a 16-bit chip that randomly "forgets" to account the 16th bit in operations.... maybe if you do 4 operations in a row 25% of the times you end up with 63-bit :)
[03:19] <BenC> [   67.980468]  00 00 00 f9 4b af:<PHONE_NUMBER>f94baf
[03:19] <_ion> jdong: That sounds like fun. :-)
[03:19] <BenC> the second call shows this:
[03:19] <jk-> you guys need a System-i machine, with 65-bit addressing :D
[03:19] <BenC> [   67.992430]  f9 4b af f9 4b af: ffffffffaff94baf
[03:19] <jdong> _ion: oh, it's lovely :)
[03:20] <BenC> I think the second call happens after revalidation
[03:20] <jdong> _ion: I swear they developed that controller to mess with our minds :D
[03:20] <BenC> then it thinks that it has a hpa area to account for, and extends it to some ungodly amount
[03:20] <kylem> yeah.
[03:20] <BenC> so things continue to work, but the device appears overly large
[03:20] <_ion> jdong: Was one of the platform's developers perhaps behind INTERCAL, too? :-)
[03:21] <jdong> _ion: Microchip Inc... go torch their building :D
[03:21] <kylem> damn, no _Anarchy_ on irc.
[03:21] <BenC> not sure why the last 8 bits are getting 0xff aswell, that bothers me too
[03:22] <kylem> oh.
[03:25] <ajmitch> BenC: the last set of kernels you're pushing through provides kvm-api-9?
[03:26] <BenC> ajmitch: yes
[03:26] <xtknight> Version: 2.6.20-14.23 ?
[03:26] <ajmitch> great
[03:26] <xtknight> that one didnt fix kvm for me though i haven't rebooted.
[03:28] <BenC> it wont fix kvm, because it doesn't have the kvm-18 drivers
[03:28] <BenC> that will come a few days after release
[04:33] <jk-> hi Hobbsee.
[04:34] <Hobbsee> hi jk- :)
[04:34] <Hobbsee> hm.  i'm presuming the kernel that needs testing is the one coming thru the updates now
[06:25] <fabbione> morning
[06:27] <Mithrandir> doko: python-defaults is depwait; can you please get that fixed ASAP?
[06:27] <Mithrandir> (probably just loosen the build-deps a little bit)
[06:39] <doko> Mithrandir: uploaded
[06:40] <Mithrandir> cheers
[06:43] <ajmitch> hi doko
[06:43] <ajmitch> & Mithrandir
[06:45] <Mithrandir> hiya Andrew
[06:57] <fabbione> Mithrandir: #79204 looks pretty serious to me
[06:59] <fabbione> pitti was able to hit it yesterday again
[06:59] <Mithrandir> fabbione: thanks, and ARGH.
[07:00] <fabbione> Mithrandir: no more bugs reported from hw-cert since yesterday. so we are with those 2 on n-m and 1 on kernel (not RC at all)
[07:00] <fabbione> Mithrandir: the 2 from NM should be fixed by Keybuk update
[07:01] <fabbione> but i can't confirm it
[07:01] <Mithrandir> he has so far failed to actually upload a package to the archive
[07:02] <ajmitch> there seem to be a few reports of unbootable machines with 14.23 on the users list
[07:04] <Mithrandir> doko: you uploaded a new version of screem to get it rebuilt a while ago, it seems this version ftfbfs.  Could you take a look at it, please?
[07:22] <doko> Mithrandir: ugh, that was just a rebuild try
[07:22] <doko> no-change upload
[07:22] <Mithrandir> doko: yes, I saw, but it still broke, so I wondered if you have any idea about it and could take a look at it.
[07:22] <doko> Mithrandir: doing today
[07:22] <Mithrandir> thanks.
[08:34] <dholbach> good morning
[08:35] <_ion> Hi
[08:35] <mdke_> morning dholbach
[08:35] <dholbach> hey _ion, hey mdke_
[08:37] <dholbach> hum - does anybody know if a new kernel upload is in the works?
[08:37] <dholbach> I'm sure that whatever BenC fixed in the amd64 version on http://people.ubuntu.com/~bcollins/kernels/feisty-release/ would make things better
[08:38] <dholbach> at least the kernel boots for me (in contrast to the one in the archive)
[08:38] <_ion> 2007-04-13 05:45:14 status installed linux-image-2.6.20-14-generic 2.6.20-14.23
[08:38] <_ion> There was a kernel update this morning.
[08:38] <dholbach> _ion: that's the broken one
[08:39] <_ion> Heh, ok
[08:39] <dholbach> _ion: BenC fixed something in the amd64 variant on people.u.c but didn't bump the version number
[08:39] <dholbach> and according to the post on ubuntu-devel-discuss@ it seems to screw up some other people's boxes too
[08:41] <Mithrandir> dholbach: uh, it's supposed to be the same kernel.
[08:41] <Mithrandir> apart from one built on BenC's machines, one on the buildds.
[08:43] <fabbione> Mithrandir: time to wake up Ben?
[08:43] <fabbione> i am sure he will love a phone call at 3 am :)
[08:47] <dholbach> Mithrandir: what do you mean?
[08:48] <Mithrandir> dholbach: 14.23 and the one on BenC's page should be the same
[08:48] <dholbach> not the amd64 one
[08:48] <dholbach> hang on
[08:49] <dholbach> Apr 12 23:45:29 BenC    pitti, dholbach: Give me a little bit to rebuild a new kernel
[08:49] <Mithrandir> where was that?  Here?
[08:49] <dholbach> Apr 13 00:01:35 BenC    pitti, dholbach: Ok, built and uploading...should be 5 minutes
[08:49] <dholbach> yes
[08:49] <dholbach> Apr 13 00:08:16 BenC    9008b8fe14597a713fd0b8778b3638a8  linux-image-2.6.20-14-generic_2.6.20-14.23_amd64.deb
[08:49] <dholbach> Apr 13 00:08:18 BenC    same location
[08:49] <Mithrandir> I should stop sleeping so I can watch IRC more closely.
[08:49] <Treenaks> Argh, what's killing the panel on upgrades?
[08:50] <dholbach> Apr 13 00:14:34 BenC    mdz: There's an issue showing up on some systems where the revalidation of the drive shows bogus native size
[08:50] <dholbach> Apr 13 00:14:54 BenC    mdz: caused by my change to keep from bumping the ABI...reverting back to the original patch from kyle fixes it
[08:50] <dholbach> Apr 13 00:15:00 BenC    mdz: but it means an ABI bump
[08:50] <dholbach> Apr 13 00:16:12 BenC    mdz: I'm assuming we have no choice, so I'll just get this uploaded and punt lrm/linux-meta/backports right behind it
[08:50] <dholbach> bug 106110 was just filed and see one of the last posts on ubuntu-devel-discuss@
[08:50] <ubotu> Malone bug 106110 in linux-meta "Kernel 2.6.20-14-generic faild to boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106110
[08:52] <Mithrandir> yes
[08:52] <Mithrandir> it's not in unapproved, however.
[08:55] <pitti> Hello everyone
[08:55] <_ion> Bono estente.
[08:55] <dholbach> heya pitti
[08:56] <pitti> dholbach: oh, you're already up; bah, sleep is so overrated... :)
[08:56] <Mithrandir> sleep, schmeep.
[08:56] <dholbach> pitti: i was already running this morning
[08:57] <pitti> Mithrandir: so, kernel and nm ==  now?
[08:57] <Mithrandir> no
[08:57] <Mithrandir> nm isn't uploaded, kernel is busticated on AMD64, it seems.
[08:57] <dholbach> pitti: the kernel in the archive does not have BenC's quickfix (it'll mean bumping the ABI)
[08:57] <pitti> Mithrandir: *sniff*
[08:57] <Mithrandir> pitti: indeed.
[08:57] <pitti> Mithrandir: oh, still busticated? BenC's late night version was quite well
[08:58] <pitti> I see
[08:58] <Mithrandir> pitti: iz not in ze archive.
[08:58] <dholbach> Mithrandir: according to the post on ubuntu-devel-discuss@ it screws i386 too (IBM X32) - we were only able to reproduce the problem on amd64 yesterday
[08:58] <Mithrandir> nor in any queue
[08:58] <Mithrandir> and we still have problems on any machines with smart batteries.
[09:07] <mdke_> :)
[09:12] <desrt> bad news ubuntu dudes
[09:12] <desrt> -14 broke sata on macbooks again
[09:12] <Mithrandir> desrt: known.
[09:12] <mdz_> morning
[09:12] <Mithrandir> hi mdz.
[09:12] <desrt> Mithrandir; got a #?
[09:13] <dholbach> desrt: bug 106110 is one of them - i guess there are dupes
[09:13] <ubotu> Malone bug 106110 in linux-meta "Kernel 2.6.20-14-generic faild to boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106110
[09:14] <desrt> buh
[09:14] <desrt> the fact that the "search" field, when viewing bug reports, searches on "projects" is very interesting
[09:19] <desrt> dh; https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106063
[09:19] <ubotu> Malone bug 106063 in linux-source-2.6.20 "Computer will not boot after 2.6.20-14.24 kernel upgrade" [Undecided,Confirmed]
[09:20] <pitti> hey mdz_
[09:25] <pygi> hi golks
[09:25] <siretart> hi pygi
[09:26] <pitti> moin pygi
[09:30] <TheMuso> c
[09:30] <TheMuso> gah
[09:31] <_ion> Hi pygi
[09:31] <pygi> morning _ion, siretart and pitti
[09:31] <pygi> s/golks/folks
[09:33] <_ion> Cool, apparently xfdesktop4 4.4.0-0ubuntu3 didn't FTBFS anymore. :-)
[09:34] <bluefox> anyone know what facility the LiveCD uses to configure X, and how I can invoke it
[09:34] <desrt> dholbach; i think there are a few unrelated -14 problems...
[09:34] <dholbach> desrt: aha?
[09:34] <desrt> my problem is very much sata related... but this person doesn't even have sata...
[09:35] <bluefox> as soon as I get X back I'm filing a bug >/
[09:35] <dholbach> desrt: I hope the kernel team will awake soon and shed more light on this
[09:36] <desrt> i hope :)
[09:36] <desrt> this is some pretty serious business for release candidate time :)
[09:38] <desrt> pitti; i'm looking at a kernel with a whole whack of piix/ata fixes in it... are those the ones you refer to?
[09:39] <pitti> desrt: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[09:39] <pitti> desrt: those are the fixed ones I tested last night, and they unbreak booting for me
[09:39] <desrt> ya.  that's the one on the mirrors
[09:39] <pitti> desrt: no, they are not
[09:39] <pitti> desrt: it's an updated 14.24
[09:39] <pitti> erm, 14.23
[09:39] <desrt> so it's like 14.23.1....
[09:40] <pitti> right
[09:40] <dholbach> pitti: only the amd64 one does I guess
[09:40] <pitti> desrt: oh, right, the i386 is the old one
[09:40] <desrt> buh :p
[09:41] <desrt> in that case i will simply go to bed and wake up tomorrow when this is all worked out already :)
[09:41] <desrt> cheerio, gents.
[09:42] <pitti> desrt: sleep well!
[09:49] <cjwatson> Mithrandir: Ben was still trying to figure out what the hell was wrong, last I heard
[09:49] <cjwatson> Mithrandir: it seemed to be spurious 64-bit-specific breakage - 0xffffffff00000000 being or-ed into the HPA max size for no good reason
[09:49] <cjwatson> or something along those lines
[10:01] <bluefoxicy> finally fucking fixed.  I think.
[10:06] <shawarma> Do we have any Python code anywhere that parses /etc/network/interfaces ?
[10:07] <shawarma> update-manager never touches it, does it?
[10:08] <dholbach> system-tools-backends parses it
[10:08] <dholbach> but that's perl
[10:10] <shawarma> Oh, please don't make me read perl. :-)
[10:11] <dholbach> kde-guidance is python, but it does not seem to touch etc/network/interfaces
[10:12] <shawarma> dholbach: Come to think of it... I may not need this at all.
[10:12] <shawarma> dholbach: No, I can totally work around it.
[10:12] <shawarma> dholbach: Never mind. Thanks for your suggestions, though.
[10:13] <dholbach> np
[10:27] <Tonio_> hi
[10:27] <bluefoxicy> gnomefreak:  when you see keybuk tell him I need network-manager to actually log into wireless networks during boot ;)
[10:28] <Mithrandir> iwj: have you had a chance to look at https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/79204 ?
[10:28] <ubotu> Malone bug 79204 in initramfs-tools "boot on md raid drives fails" [Critical,Confirmed]
[10:28] <sladen> joy
[10:37] <stgraber> bluefoxicy: It's impossible, the wireless networks and password are stored in the user's gconf DB
[10:38] <torkel> bluefoxicy: should hopefully be fixed in n-m 0.7 (whenever that will be released...)
[10:42] <tepsipakki> bluefoxicy: to reconfigure X you run "sudo dpkg-reconfigure -phigh xserver-xorg" as suggested in xorg.conf
[10:46] <pitti> iwj: wrt. #79204, I still have the broken installation here; I'm happy to help debugging
[10:52] <jsgotangco> hey sabdfl
[10:52] <highvoltage> morning sabdfl. I'm very excited about the super-free Ubuntu edition :)
[10:53] <ajmitch> evening
[10:54] <jsgotangco> heya ajmitch
[10:57] <Mithrandir> seb128: https://bugs.launchpad.net/ubuntu/+source/gnome-cups-manager/+bug/91218 seems fixed for me now.
[10:57] <ubotu> Malone bug 91218 in gnome-cups-manager "MASTER: [apport]  gnome-cups-manager crashed with SIGSEGV in g_signal_emit_valist()" [High,Confirmed]
[10:57] <Mithrandir> I used to be able to reproduce it, I no longer can.
[10:57] <seb128> Mithrandir: ok, good, let's drop the milestone then
[10:58] <seb128> doing the change
[10:58] <Mithrandir> mark it as fix released?
[10:58] <seb128> well, we build it with -O0 as a workaround
[10:58] <seb128> it's not really fixed
[10:58] <seb128> I'll lower the severity and drop the milestone
[10:58] <dholbach> seb128: works for me too
[10:59] <seb128> dholbach: thank you
[10:59] <dholbach> seb128: hi btw :)
[10:59] <seb128> hey ;)
[10:59] <Mithrandir> seb128: fine
[10:59] <seb128> dholbach: why do you drop milestone of closed bugs?
[10:59] <dholbach> seb128: because it was a dup of another bug that was fix released
[10:59] <pitti> seb128: I seldomly had gnome-cups-manager crashes, I'll play around with it a big
[10:59] <dholbach> seb128: i can milestone the master bug, if you like
[10:59] <pitti> seb128: s/big/bit/
[11:00] <seb128> dholbach: no, but I thought we didn't care about dup, they were like closed
[11:00] <seb128> pitti: thank you
[11:00] <dholbach> seb128: it was on the milestone list anyway
[11:00] <seb128> looks like a launchpad bug
[11:00] <seb128> that's another good reason to reject dups :p
[11:00] <Mithrandir> seb128: yes, please do reject dups.  Malones handling of duplicates and milestones is less than optimal.
[11:01] <pitti> I usually un-milestone them
[11:01] <pitti> rejecting dups looks bad to the submitter
[11:01] <pitti> as if we reject their bug
[11:01] <seb128> I do it on purpose
[11:01] <Spads> pitti++
[11:01] <seb128> to discourage them to open dups
[11:01] <seb128> like, look before opening a bug
[11:02] <Spads> it's not always obvious when a bug is a duplicate, and often two bugs reporting entirely different things will be merged
[11:05] <cjwatson> pitti: have you seen bug 96244?
[11:05] <ubotu> Malone bug 96244 in tzdata "Mongolia is not DST anymore" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96244
[11:06] <pitti> cjwatson: no, didn't see it yet; will take a look later after raid debugging
[11:06] <cjwatson> thanks
[11:35] <Riddell> Mithrandir: I've milestoned bug 104794, it's a significant problem with a one line fix
[11:35] <ubotu> Malone bug 104794 in kde-guidance "guidance-power-manager shows dischanging if battery full" [Undecided,Fix committed]  https://launchpad.net/bugs/104794
[11:36] <Mithrandir> Riddell: then why is it undecided priority and not at least high, if not critical?
[11:36] <Riddell> Mithrandir: fixed
[11:51] <ogra> Keybuk, did i mention yesterday that everything is fine with ltsp and your NM packages ?
[12:01] <seb128> Mithrandir: did you figure what happened to the vte binaries?
[12:01] <Mithrandir> seb128: I half-reprocessed them, cjwatson did the other half
[12:01] <Mithrandir> LP ate them for a moment, then chewed and spat them back out again.
[12:02] <seb128> hum
[12:02] <seb128> when did you do that?
[12:03] <cjwatson> should have gone through in the last publisher run
[12:03] <seb128> ah, right, I've them now
[12:03] <seb128> cjwatson, Mithrandir: thanks
[12:08] <Tonio_> Mithrandir: hi ;)
[12:08] <Tonio_> Mithrandir: I'm just uploading digikam to edgy-updates, to close my long time pending SRU
[12:09] <Tonio_> Mithrandir: whatever I do the upload is rejected for SHA1 sum of uploaded file does not match extant file in archive
[12:09] <Tonio_> Mithrandir: I didn't touch at the tarball at all, and also tried just to upload the dsc and diff (debuild -S, no -sa)
[12:09] <Tonio_> Mithrandir: rejected whatever I do, so I must say I don't understand
[12:10] <Mithrandir> Tonio_: can you please talk to another archive admin? I'm a bit busy with other stuff.  Try seb128.
[12:10] <Tonio_> Mithrandir: sure :)
[12:10] <Tonio_> seb128: ping ?
[12:10] <seb128> Tonio_: reading
[12:10] <Tonio_> thanks
[12:10] <Mirv> pitti: looks like the software properties is now fixed in the latest langpacks, thanks! I assume I can now close bug 105280.
[12:10] <ubotu> Malone bug 105280 in software-properties "software-properties translation incorrectly in language-pack-kde packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105280
[12:11] <seb128> Tonio_: is your upload available somewhere?
[12:11] <pitti> Mirv: great, thanks for checking
[12:11] <Tonio_> seb128: wanna look at the source package ? gimme a minute
[12:11] <seb128> Tonio_: no, I want a copy of what you upload somewhere
[12:13] <Tonio_> seb128: okay
[12:14] <Tonio_> seb128: http://tonio.homelinux.org/digikam
[12:15] <Tonio_> seb128: those are the uploaded files
[12:18] <seb128> Tonio_: https://launchpad.net/ubuntu/+source/digikam/1:0.8.2-2ubuntu1.1
[12:18] <seb128> Tonio_: that version has already been used
[12:18] <Tonio_> hum okay
[12:18] <seb128> Tonio_: it's already used to edgy-proposed
[12:19] <Tonio_> seb128: sorry that's my first SRU upload so I'm a bit confused.... should I change to 2ubuntu1.2 ?
[12:19] <seb128> yes
[12:19] <Tonio_> great, will do thanks ;)
[12:19] <seb128> you can't have 2 uploads using the same version
[12:20] <Tonio_> I didn't knew the rule was the same whatever is the section
[12:21] <seb128> Tonio_: https://wiki.ubuntu.com/StableReleaseUpdates
[12:21] <seb128> Tonio_: it's documented there
[12:21] <seb128> "#
[12:21] <seb128> Include a changelog entry with:
[12:21] <seb128>     *
[12:21] <seb128>       A new version number (the same cautions apply regarding the choice of version number)
[12:21] <seb128>     *
[12:21] <seb128>       Confirmation of the above testing, including the name of the tester in each case
[12:22] <seb128> #
[12:22] <seb128> Make no other changes relative to the version in -proposed.
[12:22] <seb128> "
[12:22] <seb128> ups, sorry, wiki copy does work correctly
[12:23] <Mithrandir> +t
[12:24] <seb128> Mithrandir: thanks ;)
[12:34] <pitti> cjwatson: #96244 taken, will do an SRU for that and check with the upstream db
[12:35] <pitti> cjwatson: thanks for the pointer; I subscribed to the package bugs now
[12:43] <pitti> seb128: just played around with g-cups-mgr, didn't crash once; OTOH it was reasonably stable for me before, too
[12:43] <seb128> pitti: ok, thank you
[12:43] <Tonio_> seb128: yes, I missed the "new version number" line when reading the doc :)
[12:43] <Tonio_> seb128: will do thanks
[12:43] <seb128> np
[12:45] <Keybuk> damn
[12:45] <Keybuk> err, ww
[12:56] <pitti> Mithrandir: are feisty doors now generally closed for things like tzdata updates?
[12:57] <Mithrandir> pitti: yes, -updates would be better for that, I think
[12:57] <pitti> Mithrandir: alright
[12:57] <Mithrandir> dholbach: you have a machine with the HPA patch running, don't you?  Can you run fdisk on the disk and see if it gives you a sensible size?
[12:57] <pitti> Mithrandir: I have as well, checking
[12:57] <Mithrandir> thanks.
[12:58] <Mithrandir> with the one where you suddenly had a huge disk, right?
[12:58] <cjwatson> also parted please
[12:58] <pitti> Disk /dev/sdb: 160.0 GB,<PHONE_NUMBER>96 bytes
[12:58] <pitti> that looks right
[12:58] <dholbach> Mithrandir: in a bit
[12:59] <cjwatson> pitti: did you have the sector discrepancy in dmesg that Ben was looking at?
[12:59] <pitti> [   28.677055]  ata2.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = -1348362576
[12:59] <pitti> that's just a printk bug
[12:59] <cjwatson> negative? joy
[12:59] <cjwatson> ah
[01:00] <pitti> %lld instead of %llu
[01:01] <pitti><PHONE_NUMBER>
[01:01] <pitti> right, seems so
[01:01] <cjwatson> pitti: architecture?
[01:01] <pitti> amd64
[01:01] <pitti> [   28.317323]  ata1.00: ata_hpa_resize 1: sectors = 25408559, hpa_sectors = 25410672
[01:01] <pitti> ^ my 13 GB disk
[01:01] <cjwatson> surely<PHONE_NUMBER>2361189040 then
[01:01] <pitti> (sda)
[01:01] <cjwatson> it's an unsigned long long => 64 bits
[01:01] <cjwatson> in fact just a u64
[01:02] <cjwatson> which, yes, is<PHONE_NUMBER> sign-extended
[01:02] <pitti> cjwatson: I had that in the boot text with the previous broken kernel http://people.ubuntu.com/~pitti/tmp/14.23-boot-failure.jpg
[01:03] <elmo> you guys saw the thread about this on LKML, right?
[01:03] <cjwatson> elmo: URL
[01:04] <cjwatson> or subject line or anything
[01:04] <elmo> looking, sorry
[01:04] <elmo> my local archives are pathetically short apparently
[01:05] <elmo> http://www.ussg.iu.edu/hypermail/linux/kernel/0704.0/2333.html
[01:05] <elmo> it was a followup to that
[01:05] <elmo> http://www.ussg.iu.edu/hypermail/linux/kernel/0704.1/0423.html
[01:06] <cjwatson> ok, trying to track it down ..
[01:07] <dholbach> Mithrandir: the size looks ok (fdisk and parted)
[01:07] <Mithrandir> dholbach: ok, thanks.
[01:08] <Keybuk> isn't that fix the 0002 one?
[01:09] <cjwatson> it is, I'd just tracked it to that
[01:09] <cjwatson> http://people.ubuntu.com/~kyle/feisty/0002-2.6.21-fix-lba48-bug-in-libata-fill_result_tf.txt
[01:09] <cjwatson> which never got applied
[01:11] <cjwatson> Mithrandir: please interrupt your build and apply ^-- that
[01:11] <mdz> rebooting, brb
[01:11] <cjwatson> works for mjg59 apparently
[01:11] <Mithrandir> cjwatson: in addition to your patch?
[01:11] <cjwatson> yes
[01:12] <Mithrandir> building.
[01:16] <Mithrandir> Riddell: kde-guidance is approved by you, right?
[01:16] <Hobbsee> Mithrandir: it's working fine here.  i think he approved it earlier
[01:17] <Riddell> Mithrandir: yes
[01:18] <Mithrandir> accepted.
[01:18] <Riddell> thanks
[01:26] <ogra> Mithrandir, if i upload to the queue now, will it automatically go to -updates or do i have to keep my upload back until after release day ?
[01:27] <ogra> (and file an SRU etc)
[01:27] <Mithrandir> ogra: updates never automatically go to -updates.
[01:27] <ogra> will they go manually to -updates if i upload now ?
[01:28] <ogra> (i just want to know if i should keep the g-p-m package here or upload it )
[01:28] <Mithrandir> before you do anything like that, you should read up on the SRU policy, it seems. :-P
[01:29] <ogra> oh, do we have something for the case where the archive is frozen =
[01:29] <ogra> ?
[01:30] <Mithrandir> if you're uploading to -proposed, assume we have released and follow the regular SRU
[01:31] <ogra> well, we havent released yet thats why i was asking
[01:32] <dholbach> Mithrandir: ok to upload http://codebrowse.launchpad.net/~dholbach/launchpad-integration/bug.103974/changes (rev 87 and 88)? (introducing an icon, that's why a diff does not work so well :-))
[01:35] <Mithrandir> dholbach: I'm not sure I want to take those kinds of fixes any more, we're too close.
[01:42] <dholbach> Mithrandir: did you say anything about bug 103974? (i had net problems)
[01:42] <ubotu> Malone bug 103974 in Ubuntu "dialog-warning is blurry and pixelated" [Undecided,Confirmed]  https://launchpad.net/bugs/103974
[01:42] <Mithrandir> 13:35 < Mithrandir> dholbach: I'm not sure I want to take those kinds of fixes any more, we're too close.
[01:43] <dholbach> :-(((
[01:43] <Mithrandir> it can easily go in an SRU update.
[01:43] <Mithrandir> s/update//
[01:45] <mvo> Mithrandir: I have a pending upload for gnome-app-install (dekstop data update + one trivial patch) and a updated release-upgrader. ok to upload those? or do you want to see the debdiff first?
[01:45] <Mithrandir> mvo: go ahead.
[01:46] <mvo> thanks
[01:48] <ogra> Mithrandir, i assume you wont let http://paste.ubuntu-nl.org/15354/ in  (thats why i asked about -updates initially)
[01:49] <Mithrandir> please wait while I boot my web browser.
[01:49] <ogra> sure :)
[01:49] <ogra> the original patch fixed it only for half of the people ... this one fixes bug 81227 for all of them
[01:49] <ubotu> Malone bug 81227 in hal "Logout screen appears twice [Feisty] " [Medium,In progress]  https://launchpad.net/bugs/81227
[01:50] <Kmos> feisty final will have gnome v2.18.1 ?
[01:51] <ogra> feisty has 2.18.1 aready ...
[01:51] <seb128> Mithrandir: the lpi change should be no problem, the stock icon use is buggy and overwrite the normal stock icon (try to close gedit with a change and notice how blurry the icon is, happens on random apps)
[01:51] <pitti> hi Kmos
[01:51] <Kmos> pitti: hi, you saw my e-mail =)
[01:51] <pitti> yes, I did
[01:51] <seb128> Mithrandir: that's a lack of polish and could go to -updates though
[01:51] <Kmos> ogra: nice
[01:51] <Kmos> pitti: u've updated firmware?
[01:52] <pitti> no, no hurry to do so
[01:52] <Kmos> :))
[01:52] <pitti> and busy with release stuff :)
[01:52] <Kmos> yeah, later
[01:52] <Mithrandir> seb128: hm, ok then, get it in.
[02:01] <doko> Mithrandir: uploaded screem fixing the ftbfs
[02:01] <Mithrandir> doko: \o/
[02:01] <Mithrandir> ogra: get it in now and it's ok.
[02:01] <ogra> yay
[02:01] <seb128> Mithrandir: thank you
[02:03] <Mithrandir> seb128: does the rescued vte fix bug 85575?
[02:03] <ubotu> Malone bug 85575 in vte "gnome-terminal reacting very sluggishly" [High,Confirmed]  https://launchpad.net/bugs/85575
[02:04] <seb128> Mithrandir: I've no idea "sluggishly" is not easy to mesure
[02:04] <Mithrandir> mvo: where's the new g-a-i ?
[02:04] <seb128> Mithrandir: drop the milestone anyway, few people have complained, it has got better and we will not change it now anyway
[02:04] <Mithrandir> seb128: please do so you.
[02:04] <seb128> Mithrandir: ok
[02:04] <mvo> Mithrandir: just uploaded, should be there any second
[02:04] <Mithrandir> mvo: ok, thanks.
[02:05] <mvo> Mithrandir: update-manager follows in a bit, I just want to run one additional test to make sure its good
[02:05] <Mithrandir> mvo: sure
[02:10] <mvo> seb128: vte is generally pretty fast for me these days, it used to be bad, but it is not anymore
[02:12] <saispo> hi seb128 :)
[02:12] <seb128> lu saispo
[02:12] <seb128> mvo: ah, cool
[02:13] <mvo> seb128: I'm a heavy user of tabs in the terminal and switching between them is fast as well
[02:13] <seb128> mvo: do you know around when it started being better again?
[02:13] <mvo> not sure, sorry.
[02:15] <Riddell> Mithrandir: new version of knetworkmanager uploaded for bug 105234
[02:15] <ubotu> Malone bug 105234 in network-manager "Network manager says disconnected but is connected and working" [Critical,Fix released]  https://launchpad.net/bugs/105234
[02:17] <BenC> pitti, dholbach: Can you guys retest the image I have, same location, basically a rebuild with what I'm about to upload?
[02:17] <pitti> BenC: can do; it's different from cjwatson's recent build?
[02:17] <dholbach> BenC: is it different from ...^ :)
[02:18] <BenC> it's basically the same, but it's with the source that will actually get uploaded, so just being cautious :)
[02:18] <pitti> right, downloading
[02:18] <dholbach> downloading
[02:18] <dholbach> BenC: won't you bump the ABI?
[02:18] <pitti> BenC: hmm, still 14.23?
[02:19] <BenC> it's sans ABI bump, but yes there will be one
[02:19] <pitti> ooooorrllright
[02:19] <cjwatson> (only amd64 is updated there)
[02:20] <BenC> right
[02:21] <dholbach> BenC: looks good
[02:21] <dholbach> hang on, I booted -15
[02:21] <pitti> BenC: 866f11ae96887917202a577839347033 <- correct md5sum?
[02:22] <BenC> yep, that's it
[02:22] <poningru> I just got pwnt
[02:22] <poningru> 403 Forbidden [IP: <IP_ADDRESS> 80]
[02:22] <dholbach> BenC: your -14 looks good too
[02:22] <poningru> for downloading the 14.23 from apt
[02:23] <pitti> poningru: intentionally disabled, it's broken
[02:23] <poningru> is that intentional?
[02:23] <poningru> ah ok
[02:23] <poningru> thanks
[02:23] <pitti> BenC: booting, brb
[02:23] <poningru> BenC: anything I can help test?
[02:23] <BenC> poningru: amd64?
[02:24] <poningru> :( sorry
[02:24] <poningru> i386
[02:24] <BenC> I don't have i386 test images, but colin does
[02:24] <jdub> seb128: http://svn.gnome.org/viewcvs/pango?view=rev&revision=2225 <-- ZOMG.
[02:25] <jsgotangco> BenC: you have a kernel for amd64 to test?
[02:25] <BenC> jsgotangco: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[02:25] <BenC> I should delete the i386 one
[02:25] <jsgotangco> cheers
[02:25] <seb128> jdub: interesting, no for feisty now though
[02:26] <pitti> BenC: booted fine
[02:26] <BenC> pitti: great, can you paste the lines related to hpa in dmesg?
[02:26] <pitti> BenC: just about to do that :)
[02:26] <BenC> there should also be a couple with hex dumps
[02:26] <jdub> seb128: fisty fonts need love too!
[02:27] <pitti> numbers still don't match perfectly, though
[02:27] <cjwatson> pitti: if they don't match perfectly it probably means you actually have an HPA
[02:27] <pitti> what is a HPA, BTW?
[02:27] <cjwatson> host protected area, used for recovery partitions and such
[02:27] <pitti> BenC: http://pastebin.ca/438080
[02:27] <BenC> yeah, I think your 13G drive has a 1Meg HPA :)
[02:27] <cjwatson> http://en.wikipedia.org/wiki/Host_Protected_Area
[02:28] <pitti> 3v1l spy
[02:28] <pitti> cjwatson: thanks
[02:28] <seb128> jdub: they can still get with -updates if required ;)
[02:28] <BenC> your second drive matches perfect
[02:29] <pitti> fdisk shows sane sizes for both drives
[02:29] <cjwatson> all looks lovely
[02:29] <BenC> pitti: nice, thanks
[02:29] <pitti> rock
[02:32] <cjwatson> Mithrandir: bug 105998 is nasty
[02:32] <ubotu> Malone bug 105998 in gfxboot-theme-ubuntu "Selecting keyboard layout hangs up the system" [Undecided,Unconfirmed]  https://launchpad.net/bugs/105998
[02:32] <cjwatson> I bet it's just one keymap name being really long
[02:33] <Mithrandir> cjwatson: ugh.
[02:33] <Mithrandir> cjwatson: any fix in sight?
[02:33] <cjwatson> I bumped it to Confirmed/High
[02:33] <cjwatson> just looking
[02:33] <pitti> cjwatson: sure that it's really hanging? it messes up the screen for me, but it continues to work
[02:34] <pitti> bug 105529
[02:34] <ubotu> Malone bug 105529 in gfxboot "Keyboard selection (F3) corrupts the screen" [Medium,Confirmed]  https://launchpad.net/bugs/105529
[02:34] <cjwatson> pitti: yes, it's not a hang for me, but it's not usable either
[02:34] <cjwatson> oh, I didn't see that one
[02:35] <cjwatson> I'll dup it to the one that's already in the right state, if you don't mind :)
[02:35] <cjwatson> actually, no, will dup the other way
[02:35] <pitti> I don't mind, I didn't file it :) (just confirmed)
[02:37] <BenC> dholbach: did the kernel work for you?
[02:40] <BenC> cjwatson: I have an upload ready, but I want to make sure dholbach's reboot went ok :)
[02:40] <cjwatson> ok
[02:44] <Tonio_> BenC: hey ;)
[02:44] <BenC> Tonio_: hello
[02:44] <Tonio_> BenC: is the new kernel supposed to fix the /dev/disk/by-uuid...... thing ?
[02:44] <Tonio_> BenC: I was just reopening the bug concerning macbook pro machines...
[02:44] <Tonio_> BenC: I can test if you want
[02:44] <BenC> what bug number?
[02:45] <Tonio_> BenC: bug 91940
[02:45] <ubotu> Malone bug 91940 in linux-source-2.6.20 "2.6.20-10 regression from 2.6.20-9, Macbook Pro no longer boots" [Undecided,Fix released]  https://launchpad.net/bugs/91940
[02:45] <Tonio_> BenC: today's update broke this again....
[02:45] <BenC> today's update probably broke for some other reason
[02:45] <BenC> Tonio_: using amd64 kernel?
[02:46] <Tonio_> BenC: no, generic
[02:46] <BenC> it's all generic, but is it for amd64 and i386?
[02:46] <BenC> s/and/or/
[02:46] <Tonio_> i386 (macintel)
[02:47] <BenC> Tonio_: dpkg -l | grep linux-image-2.6.20-14
[02:47] <Tonio_> BenC: ii  linux-image-2.6.20-14-generic              2.6.20-14.23                           Linux kernel image for version 2.6.20 on x86
[02:48] <BenC> you've probably been bitten by some other bug that the next kernel will fix
[02:48] <Tonio_> BenC: well if you have packages ready, I'll test them :)
[02:49] <BenC> I have one for amd64, not i386
[02:49] <Tonio_> okay....
[02:50] <imbrandon> hrm i am on a 64bit proc ( pent-d 930 ) but i386 kernel and seem to have been bitten by it to ( not a mac )
[02:50] <Tonio_> BenC: then I'm reopening the bug, I'll close if published upgrade fixes this
[02:50] <BenC> Tonio_: it's not the same bug
[02:50] <BenC> please do not reopen it
[02:50] <Tonio_> BenC: hum, okay ;) hard to figure out since the error message is exactly the same :)
[02:50] <BenC> is it?
[02:51] <Tonio_> BenC: yes, exactly the same
[02:51] <dholbach> BenC: yes yes it was fine
[02:51] <BenC> odd because nothing changes in the last upload to affect that
[02:51] <BenC> dholbach: great, was getting worried :)
[02:51] <BenC> dholbach: thanks
 BenC: your -14 looks good too
[02:51] <Tonio_> BenC:
[02:51] <Tonio_> Check root= bootarg cat /proc/cmdline or missing modules, devices: cat /proc/modules ls /dev
[02:51] <Tonio_>  ALERT! /dev/disk/by-uuid/228d13f9-92fd-4569-836b-9c7f75cb94c6 does not exist. Dropping to a shell.
[02:51] <Tonio_> same error as in the closed bug
[02:51] <cjwatson> that error just means "oh my god something went wrong"
[02:51] <BenC> dholbach: wow, missed that
[02:52] <BenC> Tonio_: that's not the actual error in that bug report
[02:52] <BenC> the error it shows is the qc timeout failures, failed to set xfermode
[02:52] <BenC> Tonio_: your error would match the problem I'm talking about, which will be fixed soon
[02:52] <Tonio_> okay perfect :)
[02:53] <BenC> mdz, cjwatson, Mithrandir: upload done
[02:53] <BenC> cjwatson: do you already have linux-meta, lrm and backports ready, or should I get them?
[02:54] <Tonio_> cjwatson: ah... didn't knew that was kind of a generic error... thanks for the info
[02:54] <cjwatson> BenC: lrm's nearly ready here (took a while to download the new orig), go ahead with the others
[02:54] <BenC> ok
[02:55] <cjwatson> lrm uploaded
[02:55] <cjwatson> Mithrandir: http://codebrowse.launchpad.net/~ubuntu-core-dev/gfxboot-theme-ubuntu/mainline/revision/208
[02:56] <cjwatson> ok to upload that? I'd run into similar problems before, just needed to add a couple more keymaps to the list of special cases
[02:56] <BenC> linux-meta away
[02:56] <Mithrandir> cjwatson: looks sensible.
[02:57] <BenC> is it appropriate that today is Friday 13th?
[02:57] <cjwatson> YES
[02:57] <wm_eddie> Heh
[02:57] <Mithrandir> look at the bright side of it, Breezy is EOL-ed today.
[02:57] <pitti> oh, yay
[02:58] <ogra> yippie
[02:58] <Hobbsee> BenC: :D
[02:58] <Mithrandir> mvo: could you please change meta-release and set Breezy as 'Supported: 0'?
[02:59] <mvo> Mithrandir: sure!
[03:00] <mvo> Mithrandir: done
[03:00] <Mithrandir> cheers.
[03:04] <ogra> pitti, why do i see php4-sqlite in the archive ? wasnt that dropped ?
[03:04] <Hobbsee> hi jono
[03:04] <pitti> ogra: I dropped php4 itself and a few packages, probably I didn't drop that one
[03:04] <BenC> and linux-backports-modules done
[03:05] <BenC> Mithrandir: the balls in your court now, my friend
[03:05] <ogra> seems its the only one left with php4 in its name
[03:05] <Mithrandir> BenC: thank you.
[03:06] <cjwatson> Mithrandir: I'll upload debian-installer now too - but of course please make sure not to accept it until all the linux-source-2.6.20 binaries are accepted
[03:06] <Mithrandir> cjwatson: ack.
[03:07] <cjwatson> and the usual seed change will be needed. Want me to do that now, since you're probably not going to do any CD builds in the meantime?
[03:07] <geser> ogra: I didn't file a remove request for php4-sqlite as gallimimus still depends on it
[03:07] <ogra> ah
[03:07] <ogra> but does it wrok without php4 available even ?
[03:07] <Mithrandir> cjwatson: yes, please.
[03:07] <StevenK> Surely gallimimus is uninstallable since the archive is sans php4
[03:07] <ogra> right
[03:08] <pitti> I'm fine with killing it
[03:08] <ogra> it makes it clearer if you apt-cache search php4 :)
[03:08] <StevenK> pitti: Would you mind killing php5 while you're at it? :-P
[03:08] <ogra> haha
[03:09] <pitti> StevenK: 'whooops, typo' :)
[03:09] <StevenK> pitti: :-D
[03:10] <StevenK> pitti: Or, "Hrm, who commited the re.sub('4', '5') in remove-package.py? :-P
[03:11] <geser> ogra: as php4-sqlite isn't installable, gallimimus isn't either but I didn't dare to request the removal of php4-sqlite when other packages still depend on it
[03:11] <StevenK> geser: And? php4 was killed when it still had plently depending on it.
[03:11] <heno> BenC: I've tested on two amd64 systems here. Works fine
[03:11] <pitti> geser: won't make a difference, since php4-sqlite is uninstallable
[03:11] <ogra> geser, well ...
[03:13] <geser> StevenK: I'm a simple MOTU and pitti is an archive admin :)
[03:15] <StevenK> I wonder if php has a (sh -n/perl -c) run-a-like
[03:17] <geser> StevenK: if http://www.die.net/doc/linux/man/man1/php.1.html is uptodate try php -l
[03:18] <StevenK> -l? What the heck?!
[03:18] <StevenK> Does it expand to --lie-to-me-please ?
[03:18] <toodles> lol!!
[03:18] <ogra> who wants to be in bed with phph ?
[03:19] <ogra> -h
[03:19] <StevenK> ogra: pph? :-P
[03:19] <ogra> :P
[03:20] <StevenK> Ah. -l is lint. I suppose I can accept that.
[03:26] <pitti> BenC, cjwatson: since one of you certainly uploads linux-meta soon, any chance that you could fix the uninstallability of linux-backports-modules-lowlatency? it depends on linux-backports-modules-2.6.20-14-lowlatency which apparently doesn't exist
[03:26] <pitti> oh, wait, it's in universe
[03:26] <ogra> that would at least help the reports :)
[03:26] <cjwatson> linux-backports-modules-lowlatency should be in universe too
[03:27] <cjwatson> there should be nothing seeding it
[03:27] <pitti> right, it's in anastacia
[03:27] <cjwatson> wow, anastacia looks good, nice work
[03:27] <ogra> well, i have it in my dvd report for today
[03:27] <pitti> :)
[03:27] <cjwatson> ogra: how old is the dvd?
[03:27] <pitti> cjwatson: I just fixed everything except the kernel stuff
[03:28] <ogra> cjwatson, yesterday i think
[03:28] <ogra> i have it in supported here
[03:28] <ogra> oh, wait, thats -debug
[03:28] <ogra> err
[03:28] <ogra> ignore me i'm talking rubbish ...
[03:29] <ogra> what i see is backports-modules
[03:31] <pitti> cjwatson: I'm afraid I'm not educated enough to sensibly decide the fate of all those -di things in anastacia
[03:34] <Mithrandir> pitti: can you top off the CDs for all derivatives with langpack, leaving a megabyte or two to spare?
[03:34] <cjwatson>  * Kernel-Version: 2.6.19-7-386
[03:34] <cjwatson> whoa
[03:35] <pitti> Mithrandir: with pleasure
[03:35] <cjwatson> that would tend to explain why germinate ignored them
[03:35] <Mithrandir> cjwatson: where?
[03:35] <Mithrandir> pitti: thanks a lot
[03:35] <cjwatson> Mithrandir: supported. fixed.
[03:36] <cjwatson> pitti: right, I think I've deconfused germinate wrt those -di things
[03:36] <pitti> cjwatson: yay, thanks
[03:36] <cjwatson> let me know if not
[03:36] <cjwatson> linux-backports-modules-2.6.20-14-server
[03:36] <cjwatson> is that needed?
[03:37] <cjwatson> zope3-dbg? I thought I'd asked doko about that a while back
[03:37] <Mithrandir> cjwatson: -15, I'd thought?
[03:37] <pitti> cjwatson: python-zope3 doesn't exist
[03:37] <cjwatson> Mithrandir: wouldn't have thought anastacia would have noticed yet
[03:37] <cjwatson> hmm, there's no linux-backports-modules-server
[03:38] <Mithrandir> cjwatson: a publisher run just finished, but I didn't think I accepted anything in time for it.
[03:38] <cjwatson> can I upload linux-meta again to fix that?
[03:38] <Mithrandir> cjwatson: yes, please.
[03:41] <Kmos> bug 106214
[03:41] <ubotu> Malone bug 106214 in gnome-panel "network-manager icon disappears when deactivating wireless network" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106214
[03:45] <Hobbsee> it appears that they're mostly sitting idle...
[03:45] <cjwatson> Mithrandir: in unapproved
[03:45] <cjwatson> Hobbsee: it can take a while for certain cron jobs to notice unfortunately
[03:45] <Mithrandir> Hobbsee: because the publisher is still running
[03:45] <Hobbsee> cjwatson: pedal faster :P
[03:45] <Hobbsee> Mithrandir: ahhh.  point
[03:46] <Mithrandir> and because I've told them to stay so I can make the kernel build on palmer and not the other buildds
[03:46] <Kmos> bug 106213
[03:46] <ubotu> Malone bug 106213 in linux-source-2.6.20 "kernel 2.6.20-14.23 crashed at begining of boot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106213
[03:46] <cjwatson> ah, hadn't noticed that you had the publisher on manual
[03:46] <Mithrandir> it's not on manual, I'm just sneaking in an extra cycle
[03:47] <cjwatson> Kmos: almost certainly a dup of a million other bugs - please retry with 2.6.20-15.24 when it's available (some hours)
[03:47] <cjwatson> Mithrandir: heh
[03:47] <Hobbsee> Mithrandir: palmer's the fastest machine?
[03:47] <Kmos> cjwatson: i found it, i'm not the bug reporter
[03:47] <Mithrandir> Hobbsee: yes
[03:47] <Hobbsee> neat :)
[03:47] <Kmos> cjwatson: can I put fix released on it ?
[03:48] <Mithrandir> it's about doble the speed of the other buildds, something which is significant when we're looking at three-hour build times
[03:48] <Hobbsee> Mithrandir: indeed.
[03:48] <ScottK> Kmos --> #ubuntu-bugs
[03:48] <Hobbsee> Mithrandir: should i ask how much universe stuff is sitting in unapproved, or is all that just going thru?  (it's unmet deps)
[03:48] <cjwatson> Kmos: not enough info, bug reporter will have to retry
[03:49] <cjwatson> Hobbsee: http://people.ubuntu.com/~ubuntu-archive/queue/feisty/unapproved/
[03:49] <Mithrandir> Hobbsee: I shove it through whenever I see it; it was empty five minutes ago
[03:49] <Hobbsee> cjwatson: wow, we can see that!  when'd that happen?
[03:49] <Hobbsee> Mithrandir: great, thanks
[03:49] <cjwatson> Tollef set that up a little while back
[03:49] <Hobbsee> nice :)
[03:49] <cjwatson> Hobbsee: that's different from the LP +queue pages which you probably still can't see
[03:49] <Mithrandir> I need to hook up an RSS feed and IRC bot to it.
[03:50] <Hobbsee> cjwatson: indeed.  binary new is still hidden, etc.
[03:50] <Mithrandir> Hobbsee: no, it's not.
[03:50] <Hobbsee> was last i checked.  info may well be out of date
[03:50] <Mithrandir> http://people.ubuntu.com/~ubuntu-archive/queue/feisty/new/
[03:50] <cjwatson> new was the one you could always see, I thought
[03:50] <Hobbsee> like i say, out of date info
[03:50] <Hobbsee> cjwatson: source new - not binary new
[03:50] <Mithrandir> it's the same queue
[03:50] <cjwatson> Mithrandir: actually, that isn't mirroring binaries
[03:51] <cjwatson> Hobbsee: https://launchpad.net/ubuntu/feisty/+queue - should be two binary uploads visible there
[03:51] <cjwatson> refpolicy and drupal
[03:51] <Hobbsee> cjwatson: mmm...so it is.  must be new, or i'm blind.  maybe both :P
[03:52] <Mithrandir> cjwatson: hm, that's a bug, then.
[03:52] <cjwatson> Mithrandir: shall I fix? I think it's obvious
[03:52] <Mithrandir> QIDS=$(queue -Q ${QUEUE} -s "${DISTRORELEASE}" info | awk '$3 ~ /^[SB] -$/ { print $1 } ' | tr '\n' ' ' )
[03:52] <cjwatson> /^[SB] -$/ should be something that matches S- or -B
[03:52] <cjwatson>  /^[SB] -$/ should be something that matches S- or -B
[03:52] <Mithrandir> oh, it's -B
[03:52] <Mithrandir> yes, please fix.
[03:53] <pitti> ogra: where to put langpacks for edubuntu? server or serveraddon? or do you prefer to handle that yourself?
[03:54] <ogra> pitti, ?
[03:54] <ogra> they are defined in the seeds
[03:54] <ogra> ship: * Languages: es xh pt de fr ca cs el
[03:54] <cjwatson> Hobbsee: OK, http://people.ubuntu.com/~ubuntu-archive/queue/feisty/new/ shows binaries now, thanks for that
[03:54] <pitti> ogra: alright; ok for me to fill them up?
[03:55] <ogra> ogra@edubuntu:~/seeds/edubuntu.feisty$ grep language ship-addon
[03:55] <ogra>  * /^language-pack-[^-] +$/
[03:55] <ogra>  * /^language-pack-gnome-[^-] +$/
[03:55] <ogra>  * /^language-pack-kde-[^-] +$/
[03:55] <Hobbsee> cjwatson: very nice.  thanks!
[03:55] <pitti> ogra: oh, no need to then, I guess :-P
[03:55] <ogra> yeah :)
[03:55] <Mithrandir> dear archive, work faster.   :-P
[03:56] <Hobbsee> Mithrandir: you can kill http://people.ubuntu.com/~ubuntu-archive/testing-ports/breezy_probs.html too
[03:56] <Hobbsee> Mithrandir: :P
[03:56] <cjwatson> that would be something that still lives in drescher:~cjwatson/
[03:56] <cjwatson> I'll kill it
[03:57] <Hobbsee> cjwatson: ahh.  go for it :)
[03:57] <Mithrandir> cjwatson: can you transition it to be generated by lp_archive or something instead?
[03:57] <cjwatson> testing/data/dapper/breezy
[03:57] <cjwatson> testing/data/edgy/breezy
[03:57] <cjwatson> blink, something went wrong there
[03:57] <cjwatson> Mithrandir: it's on the to-do somewhere ...
[03:57] <pitti> Mithrandir: done; {ed,x}ubuntu already have the complete collection, kubuntu is full, ubuntu filled up
[03:58] <cjwatson> Hobbsee: done
[03:58] <Hobbsee> cjwatson: great :)
[03:59] <dholbach> hi danielk
[03:59] <danielk> hey
[03:59] <Mithrandir> pitti: thanks a lot
[03:59] <danielk> http://danielkitta.org/images/ubuntu-kernel-panic.jpg
[03:59] <dholbach> BenC: ^ that seems to happen with your newest amd64 kernel still
[04:00] <danielk> linux-image-2.6.20-14-generic_2.6.20-14.22_amd64 works
[04:00] <danielk> 14.23 doesn't
[04:00] <danielk> and neither do the packages by cjwatson and bcollins, unfortunately
[04:01] <pitti> dholbach: Friday 13th
[04:01] <BenC> "This is not a software problem"
[04:01] <dholbach> pitti: apparently
[04:01] <danielk> well it works with the prior kernel
[04:01] <BenC> danielk: I can't see how -14.22 will work and my package wont
[04:01] <danielk> BenC: but that's what happens
[04:01] <BenC> there's nothing there affecting sata_nv directly
[04:02] <pitti> bad memory?
[04:02] <danielk> I'm running 2.6.20-14.22 right now
[04:02] <danielk> don't think so
[04:02] <BenC> it's not even a sata_nv error
[04:02] <danielk> perfectly reproducible
[04:02] <danielk> BenC: it seems related
[04:02] <pitti> danielk: could you run memtest from grub?
[04:02] <danielk> if I boot with nomce on the kernel command line, it just hangs without the message
[04:03] <danielk> I could
[04:03] <danielk> ok, that will take a while
[04:03] <danielk> later
[04:03] <dholbach> BenC: anything else he could to debug?
[04:03] <dholbach> oh... there he goes
[04:04] <BenC> scary part is, it looks like at the very point where hpa would be checked
[04:05] <mjg59_> BenC: No, it's 15 seconds later
[04:05] <dholbach> if you know of anything he could try, I can phone him
[04:05] <mjg59_> Sorry, 5 seconds later
[04:05] <BenC> the SATA link up prints right before hpa check
[04:05] <mjg59_> BenC: Look at the timestamps
[04:05] <BenC> and then there's 5 seconds of hang
[04:06] <BenC> mjg59_: right, what if it is an exception waiting for hpa check to return?
[04:06] <mjg59_> That's not how MCEs are handled
[04:07] <BenC> mjg59_: hpa is the only thing changes between -14.22 and -14.23 that would affect him
[04:07] <mjg59_> Well, assuming that his hardware hasn't died in the meantime
[04:07] <mjg59_> Has anyone run that through mcelog?
[04:07] <BenC> if he can reliably go back to -14.22 without problems, then there's a good indication...
[04:07] <BenC> that's what I want to see
[04:07] <dholbach> he logged in with -14.22 or -13.x
[04:07] <BenC> dholbach: can you ask him to run "mcelog --ascii"?
[04:08] <dholbach> ok
[04:08] <dholbach> he doesn't know how to access the kernel logs, if the machine does not boot properly
[04:08] <dholbach> or should he do that with a working kernel?
[04:09] <Hobbsee> pitti: http://people.ubuntu.com/~pitti/langpacks/daily/breezy-updates/ can go too, (when you're not busy)
[04:09] <pitti> Hobbsee: done 10 seconds ago :)
[04:09] <Kmos> pitti: i told him that already
[04:09] <Kmos> :)
[04:09] <Hobbsee> pitti: ahh
[04:10] <dholbach> BenC: ^
[04:10] <BenC> dholbach: mcelog is not the same, it's stored in hardware, so is good across reboots
[04:10] <jsgotangco> bye bye Breezy
[04:10] <BenC> probably even get it from BIOS event log viewer
[04:11] <fabbione> it's probably time to dist upgrade to dapper then
[04:12] <bddebian> Heya
[04:13] <cjwatson> seeds updated to 2.6.20-15 and merged to all derivatives
[04:19] <danielk> hey
[04:19] <danielk> so
[04:19] <pitti> danielk: welcome back
[04:19] <danielk> BenC: mcelog --ascii </dev/mcelog doesn't output anything
[04:21] <danielk> pitti: I aborted the memtest after the 4th pass ran without errors
[04:21] <pitti> danielk: ok, thanks for checking
[04:21] <danielk> no prob
[04:22] <BenC> danielk: Maybe your BIOS even viewer has more info?
[04:22] <danielk> hmm
[04:23] <BenC> event
[04:23] <danielk> where would that be? somewhere accessible from the BIOS config?
[04:23] <BenC> danielk: did you run mcelog as root?
[04:23] <danielk> yes, with sudo
[04:24] <BenC> danielk: </dev/mcelog wont work with sudo
[04:24] <danielk> sudo -s
[04:24] <BenC> ah ok
[04:24] <danielk> anyway, just typing "mcelog" (as root) doesn't output anything either
[04:24] <BenC> danielk: it definitely looks like a hw problem, but it's likely that something is just now triggering it
[04:25] <danielk> oh well
[04:25] <BenC> danielk: If you can find some info from the hw, then hopefully we can get something out of it
[04:25] <BenC> danielk: Try booting the newer kernel with libata.ata_ignore_hpa=0
[04:26] <BenC> danielk: if you could please
[04:26] <danielk> cool
[04:26] <danielk> thanks, will try
[04:26] <danielk> later
[04:39] <Keybuk> a turtle
[04:39] <Keybuk> knowing robey
[04:43] <elmo> what's the bug number for 'zomg, this kernel broke the world'?
[04:43] <elmo> Mithrandir: ^--
[04:44] <cjwatson> elmo: bug 106063
[04:44] <ubotu> Malone bug 106063 in linux-source-2.6.20 "MASTER: Computer will not boot after 2.6.20-14.24 kernel upgrade" [Critical,Fix committed]  https://launchpad.net/bugs/106063
[04:44] <elmo> cheers
[04:44] <danielk> back again from my N800 now
[04:44] <kylem> elmo, fixed in -15.
[04:45] <kylem> elmo, the problem was the patch i committed to fix MBP got reverted unintentionally.
[04:45] <danielk> BenC: libata.ata_ignore_hpa=0 doesn't help
[04:45] <elmo> kylem: yeah, I know, just got someone complaining at me about the 000 perms on the mirror of the existing binaries
[04:45] <jdong> "How exactly do you propose getting dmesg output from a kernel that doesn't boot?"
[04:45] <kylem> yeah. i'm hitting that now. ;-P
[04:45] <BenC> danielk: There goes the only known thing that changed between kernels for you
[04:46] <kylem> danielk, we still attempt to read the HPA, don't we?
[04:46] <kylem> s/danielk/BenC/
[04:46] <danielk> well, as I said .22 does work
[04:46] <BenC> kylem: I didn't check the code path thoroughly...maybe
[04:46] <danielk> and .23 doesn't
[04:47] <kylem> yeah, we do. bleh.
[04:48] <BenC> kylem: maybe we shouldn't call ata_hpa_resize() when ata_ignore_all=0
[04:48] <BenC> either way I still think it's a hw issue, just triggered by this
[04:48] <danielk> hmm
[04:48] <kylem> yeah, the taskfile failing to execute wouldn't cause a MCE.
[04:48] <kylem> unless libata-eh is broken on sata_nv.
[04:48] <BenC> it's an easy fix
[04:49] <cjwatson> I don't mind if it breaks by default (at this point) as long as a workaround is possible
[04:49] <danielk> the mcelog manpage says something about  bogus mce
[04:49] <kylem> BenC, might as well not touch the existing thing, and add a libata.no_hpa_support=1
[04:49] <danielk> being not that rare, that is
[04:49] <BenC> cjwatson: it's not possible with current code
[04:49] <BenC>                         if (ata_id_hpa_enabled(dev->id))
[04:49] <BenC>                                 dev->n_sectors = ata_hpa_resize(dev);
[04:50] <BenC> kylem: we can just change that if to check ata_ignore_hpa
[04:50] <cjwatson> BenC: I understand
[04:50] <danielk> this is an Asus A8N-E mainboard btw
[04:50] <BenC> there's really no reason to call that if we're not ignoring hpa
[04:51] <BenC> s/change it to check/make it check ata_ignore_hpa as well/
[04:51] <BenC> Solarion: if (ata_ignore_hpa && ata_id_hpa_enabled(dev->id))
[04:51] <cjwatson> we should be able to get a kernel for danielk to try fairly quickly?
[04:51] <BenC> s/Solarion/so/
[04:51] <mjg59_> Anyone else with sata_nv having the same issue? Or anyone with it working?
[04:51] <BenC> danielk: Can you test in 30 minutes?
[04:51] <danielk> ooh that would rock
[04:51] <desrt> word up guys
[04:51] <desrt> <- testcase
[04:51] <BenC> mjg59_: have seen no other reports of it
[04:52] <kylem> where is the -15 kernel?
[04:52] <danielk> BenC: yup
[04:52] <cjwatson> desrt: ?
[04:52] <kylem> it's not in the archive yet
[04:52] <BenC> nor reports of it working
[04:52] <kylem> i have an A8N-e
[04:52] <kylem> danielk, is this socket 939 athlon64?
[04:52] <desrt> er... -14 isn't booting for me because of sata problems.  hpa stuff.  is that what you're looking for?
[04:52] <cjwatson> kylem: danielk's using a non-ABI-bumped version from http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[04:52] <BenC> kylem: you can test my kernel at http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[04:52] <kylem> ok
[04:52] <BenC> desrt: I believe we have that fixes, test my kernel above if you have amd64
[04:52] <cjwatson> desrt: try http://people.ubuntu.com/~bcollins/kernels/feisty-release/ (warning: will break restricted modules)
[04:52] <danielk> kylem: yup
[04:52] <desrt> BenC; 32bit here
[04:52] <kylem> danielk, ok. i have that board.
[04:53] <BenC> I'll get a kernel ready in any case
[04:53] <danielk> kylem: now it gets interesting
[04:53] <BenC> danielk: Copy the URL above, the kernel will be there shortly...I'll ping when it's ready
[04:53] <kylem> i'm pretty sure i tested on that board.
[04:54] <kylem> seeing as it's one of the very few i have.
[04:54] <danielk> BenC: thanks
[04:54] <kylem> rebooting now
[04:55] <kylem> reproduced.
[04:56] <mjg59_> Oh, fun.
[04:56] <danielk> rock!
[04:56] <kylem> christ.
[04:57] <danielk> well I'm glad it's not *my* hardware :P
[04:57] <kylem> ok.
[04:58] <desrt> kylem; you can cross-compiled with distcc :)
[04:58] <cjwatson> * kylem's house lifts off
[04:59] <kylem> desrt, while i have like 16 parisc cpus of varying speeds sitting under my desk, they aren't as fast as c2d. :P
[04:59] <pitti> StevenK: thanks for gallinimus; I'm going to kill php4-sqlite then
[04:59] <desrt> kylem; fair.
[05:00] <BenC> kylem: so you get an exception too?
[05:00] <kylem> BenC, yup. exact same failure. exact same hw.
[05:00] <BenC> crazy
[05:00] <BenC> should we dmi blacklist that board?
[05:00] <kylem> this is new.
[05:01] <BenC> kylem: Can you narrow down exactly where in the code it occurs?
[05:01] <kylem> yup.
[05:02] <BenC> kylem: the only thing I'm worried about is that maybe it's the bit twiddling, which is different in my patch because it got rid of the signed extension bullshit we saw while testing last night
[05:02] <BenC> but it's exactly the same thing as what's in IDE, so I'm not sure how it could be that
[05:02] <kylem> it's not that.
[05:03] <BenC> I have a sata_nv board, but it's running 32-bit kernel
[05:03] <BenC> I wonder if a 64-bit kernel will boot ok on it
[05:04] <BenC> build is just about done
[05:05] <kylem> rookery.ubuntu.com/~kyle/vmlinuz.git is amd64 defconfig i use for quick testing before doing a full rebuild of patches
[05:05] <kylem> it fails on my sata_nv board, might be worth a try
[05:05] <kylem> in 10 seconds when it finished uplaoidng
[05:07] <kylem> BenC, i just kicked off an i386 build, we'll see if it fails too.
[05:08] <BenC> danielk: Should be about 5 minutes before the package is uploaded
[05:08] <danielk> BenC: ok
[05:08] <pitti> Mithrandir, cjwatson: ok to upload http://pastebin.ca/438284 to fix the last feisty_probs.html?
[05:09] <pitti> (doesn't affect CDs)
[05:10] <kylem> BenC, yeah, it's ata_exec_internal that's failing.
[05:10] <BenC> bummer
[05:10] <BenC> not really fixable
[05:10] <kylem> i have a n idea.
[05:10] <BenC> question is, is it ASUS board, or sata_nv
[05:11] <kylem> libata.hpa_pata_only=1
[05:11] <kylem> only pata disks should have this issue, ideally.
[05:11] <cjwatson> pitti: shouldn't it be python-zopeinterface?
[05:11] <kylem> we can check the cable type pretty easily
[05:11] <wm_eddie> how do I made a .patch file suitable for going inside the debian/patches directory?
[05:12] <wm_eddie> (Of a package)
[05:12] <pitti> cjwatson: I'm not sure; p-zopeinterface is a transitive dependency now, too
[05:12] <kylem> wm_eddie, dpatch
[05:12] <pitti> cjwatson: but I didn't reach doko today
[05:12] <pitti> cjwatson: and other python-foo-dbg depend on python-foo as well
[05:12] <pitti> cjwatson: that's why I think this isn't terribly wrong at least
[05:13] <BenC> boot on my sata_nv board..
[05:14] <pitti> cjwatson: of course the changelog should talk about 'fix zope3-dbg dependencies'; fixing
[05:15] <cjwatson> kylem: I'd recommend the simplest possible fix or workaround if necessary ...
[05:16] <pitti> wm_eddie: https://wiki.ubuntu.com/MOTU/School/PatchingSources
[05:16] <kylem> cjwatson, ok. i think i have something, giving it a test
[05:17] <mjr> hmh, the "desktop effects" configuration applet uses a stay-down button which to me is bad. But YMMV.
[05:18] <danielk> BenC: still hangs
[05:19] <BenC> danielk: I expected the hang still, just wondering if the ata_ignore_hpa=0 works around it
[05:19] <danielk> BenC: ok, trying
[05:19] <BenC> hangs on my sata_nv too
[05:19] <wm_eddie> thanks pitti.
[05:22] <wm_eddie> Yay, I fixed the desktop-effects cube checkbox.
[05:22] <danielk> BenC: still hangs with libata.ata_ignore_hpa=0
[05:23] <kylem> BenC, fails on i386 here tooo.
[05:23] <mjg59_> kylem: Checking the cable type isn't a good plan
[05:23] <kylem> mjg59_, i know.
[05:24] <kylem> unfortunately, i'm out of better ones.
[05:25] <kylem> i wonder if it's caused by drivers/ide code loading first.
[05:25] <mjg59> So *how* is ata_exec_internal causing an MCE?
[05:25] <mjg59> I've never seen driver code trigger those on x86
[05:26] <kylem> not a clue in the world
[05:26] <BenC> maybe it's causing the controller to choke up something
[05:26] <BenC> it does seem sata_nv specific
[05:26] <kylem> a PCI access timing out would softfail 0xffffffff, not hardfail and gutter the bus
[05:26] <BenC> can a PCI device trigger an MCE?
[05:29] <BenC> danielk: damnit, sorry, it's libata.ignore_hpa=0
[05:29] <danielk> ok, trying
[05:29] <mjg59> kylem: Inappropriate DMAing? Though I can't imagine why that would happen
[05:30] <kylem> mjg59, inappropriate how? :)
[05:30] <pitti> Mithrandir: zope patch with improved changelog, confirmed by Matthias: http://pastebin.ca/438310
[05:30] <doko> pitti, cjwatson, Mithrandir: sorry, forgot about that; the fix is correct
[05:30] <mjg59> What's the outcome of DMAing to an address that's not backed by physical memory?
[05:31] <kylem> mjg59, kersplat.
[05:31] <mjg59> What sort of kersplat?
[05:33] <pitti> seb128, mvo: is the gnome network monitor applet removed on upgrades in favour of n-m?
[05:33] <seb128> pitti: no, panel config is an user one, there is no real way to do it
[05:34] <BenC> is it possible that sata_nv doesn't setup the devices well enough before we start probing hpa?
[05:34] <pitti> seb128: alrighty;
[05:34] <seb128> pitti: if you speak about the panel config itself
[05:34] <seb128> uninstalling it would "work"
[05:34] <pitti> seb128: bug 85585
[05:34] <ubotu> Malone bug 85585 in network-manager "i don't think that networkmanager applet is needed" [Undecided,Confirmed]  https://launchpad.net/bugs/85585
[05:34] <pitti> seb128: 'after upgrade I have both network monitor and nm-applet
[05:34] <danielk> BenC: libata.ignore_hpa=0 doesn't help either
[05:34] <pitti> seb128: I'm sure that there are already dups of that
[05:35] <BenC> danielk: weird, it helps me
[05:35] <seb128> pitti: the only way to close that would be to deprecated network monitor
[05:35] <seb128> pitti: like make it a null applet
[05:35] <desrt> [579347.567063]  NetworkManager[12366]  trap int3 rip:421b7c rsp:7fff9b9c7fc0 error:0
[05:35] <danielk> strange
[05:35] <seb128> pitti: but some users might still want to use it
[05:35] <BenC> danielk: can you boot up a working kernel and do "echo options libata ignore_hpa=0" > /etc/modprobe.d/mylibata
[05:35] <pitti> seb128: right, bad as well; do you already have a reference bug for that?
[05:35] <BenC> danielk: then update-initramfs -u, and reboot
[05:35] <danielk> ok
[05:35] <kylem> 08:33:02 < kyle> hmm, will a DMA to a non-existant address MCE on i386/x86-64?
[05:36] <kylem> 08:35:48 < jejb> no ... unfortunately
[05:36] <mjg59> Ok
[05:36] <seb128> pitti: not that I remember, we didn't get many bugs about it afaik (or not on GNOME)
[05:36] <mjg59> So what on earth /can/ MCE an i386?
[05:36] <pitti> seb128: alright, I just keep it then; thank you
[05:36] <seb128> np
[05:36] <seb128> pitti: cleaning network-manager huge stack of bugs?
[05:36] <mjg59> I was under the impression that the answer was "Basically nothing"
[05:37] <pitti> seb128: yep
 bluefoxicy: to reconfigure X you run "sudo dpkg-reconfigure -phigh xserver-xorg" as suggested in xorg.conf
[05:37] <seb128> pitti: I think that's required, lot of bugs there
[05:38] <bluefoxicy> tepsipakki:  that should happen automagically.  I put in LiveCD, it installs (has) ati/nvidia drivers and configures Xorg.   instead of "OHCRAP BAIL BAIL BAIL hey btw X died"
[05:38] <bluefoxicy> and it shouldn't ask me a damned thing besides that
[05:38] <bluefoxicy> which reminds me
[05:39] <kylem> i think i found it, Ben.
[05:39] <bluefoxicy> I should go file a bug on that, now that I've calmed down to the point that I can make a report without 80% of it being abusive language
[05:39] <pitti> bluefoxicy: no fglrx/nvidia-glx on live system
[05:39] <pitti> bluefoxicy: and you can use restricted-manager to configure them
[05:39] <bluefoxicy> pitti:  oh, no?  I thought it pulled those down.
[05:39] <mjg59> No
[05:39] <pitti> bluefoxicy: right, r-m will download them
[05:39] <mjg59> We don't use the non-free X drivers by default
[05:39] <pitti> but ENOSPACE
[05:40] <pitti> on the CDs
[05:40] <bluefoxicy> pitti:  I swapped mobos.  Onboard via -> onboard nvidia.  Result:  2 hours of me trying to get X configured properly to start; half of that was just trying to get it to draw a mouse pointer instead of highlighting things in a ghostly manner as my mouse moved
[05:40] <seb128> bluefoxicy: there is likely already a bug about it
[05:40] <BenC> not doing hpa makes things happy, happy on my sata_nv
[05:40] <seb128> bluefoxicy: there is specs about it
[05:41] <bluefoxicy> I'm not so worried about X not doing nvidia-glx automagically as I am X freaking dying and expecting me to answer 20 questions to fix it when I swap video chipsets
[05:41] <seb128> bluefoxicy: it only requires somebody to do the job, everybody is already overworked
[05:41] <pitti> bluefoxicy: as seb says, it's a known problem and there's a spec
[05:41] <pitti> no need for more bug reports about ti
[05:41] <pitti> s/ti/it/
[05:41] <Hobbsee> bluefoxicy: feel free to volunteer to do it, isntead of waving the magic wand
[05:42] <bluefoxicy> seb128:  Yeah, everyone is always overworked.  Hell I'm overworked, I have a job and it's made me a less productive member of society :/
[05:42] <seb128> bluefoxicy: you can always complain that we don't work 24 hours a day, not really going to change anything though
[05:42] <desrt> bluefoxicy; at the very least, understand that this won't be fixed for feisty and that the most productive thing that you can do right now is to stop talking about it until the next week is over.
[05:42] <seb128> bluefoxicy: it'll be done at some stage, either contribute or wait, not a lot that ranting will change
[05:43] <bluefoxicy> anyway at least there's a bug on it
[05:43] <bluefoxicy> there's not much else I can really do ;/
[05:43] <seb128> and a specification
[05:43] <Hobbsee> bluefoxicy: while you're waiting for it to be done, how bout you get rid of all the dupes of the non-booting kernel bug?
[05:43] <mvo> pitti: release-upgrader is not touch the users config in any way
[05:44] <pitti> mvo: right, already settled with Seb; thank you!
[05:46] <danielk> BenC: ok, that helped, thanks
[05:46] <BenC> danielk: thanks, we'll see if we can get this worked out...appreciate the report
[05:47] <danielk> np
[06:02] <doko> ogra, cjwatson: I couldn't confirm the keyboard selection problem with the current edubuntu amd64 dvd (although it's still reproducible with the old one), so either it's fixed or a bad disk
[06:02] <ogra> bad disk i guess
[06:02] <ogra> nobody else saw it
[06:15] <desrt> so guys... you know this bug where laptops using madwifi randomly lock up.... i think i figured out what causes it
[06:16] <cjwatson> pitti: zope3> ok, that's fine - have you uploaded it?
[06:16] <desrt> it happens when networkmanager tells the driver to associate with a unencrypted network very rapidly after it is first discovered
[06:16] <cjwatson> doko: ok, thanks
[06:16] <pitti> cjwatson: no, no approval yet
[06:16] <pitti> cjwatson: uploaded
[06:17] <cjwatson> (it's usually best to shove it in the queue at times like this - we can always reject)
[06:19] <cjwatson> Mithrandir: I'm going to hold off on accepting debian-installer for a while until we decide what's happening with the kernel
[06:23] <seb128> cjwatson: did you read what I wrote about X-Ubuntu-Desktop-Domain and the ubiquity desktop icon translation the other day?
[06:24] <cjwatson> bugger. yes, and totally forgot about it.
[06:24] <cjwatson> is it critical?
[06:24] <seb128> no, it's just to get the "Install" translated on the desktop CD
[06:24] <cjwatson> I don't quite understand why it used to be needed and isn't any more
[06:25] <seb128> well, it's required to use language pack
[06:25] <cjwatson> but I include the translations directly
[06:25] <seb128> but it's broken for some reason and doesn't get translated at all
[06:25] <seb128> and it's late to track the bug now
[06:25] <seb128> yes
[06:25] <cjwatson> I intentionally disregard language packs there
[06:25] <seb128> dropping the domain will make the .desktop translations being used
[06:25] <seb128> ahhh
[06:25] <cjwatson> it's a gtk-specific problem?
[06:25] <seb128> that explains it then
[06:26] <seb128> dunno about the KDE side
[06:26] <seb128> we patched glib to use gettext before the .desktop translations
[06:26] <cjwatson> Mithrandir: ^-- up to you
[06:26] <seb128> dunno if that has been done for kubuntu
[06:26] <cjwatson> TBH I'm inclined to leave it at this point - sorry for dropping it on the floor earlier
[06:26] <pitti> seb128: ISTR that it was done
[06:27] <seb128> cjwatson: np, most people understand "Install" anyway
[06:27] <Riddell> seb128: yes, it's just the same
[06:27] <seb128> it's only cosmetic
[06:27] <cjwatson> "Install" is also what's written on the pressed CD sleeves
[06:28] <cjwatson> Riddell: does it actually work for Kubuntu? :-)
[06:29] <pitti> seb128: just to understand this fully, you want ubiquity to drop the X-Ubuntu-Gettext-Domain: to circumvent the glib bug about not using the langpacks for translation?
[06:29] <seb128> pitti: no, to workaround the icon label not being translated at the moment
[06:30] <pitti> seb128: right, that's what I meant
[06:30] <seb128> pitti: if we drop the gettext domain it uses the .desktop Name[locale]  correctly
[06:30] <pitti> ok, so we mean the same thing
[06:30] <seb128> still there is a bug somewhere but it's too late to debug it now
[06:30] <seb128> next cycle
[06:30] <seb128> if there is no .mo available the desktop Name[locale]  should be used
[06:31] <pitti> seb128: I even think that this works
[06:31] <Riddell> cjwatson: not sure, I don't think I've booted it up in different languages
[06:31] <seb128> well, something make it not being translated
[06:31] <pitti> seb128: the problem is AFAIR when the .mo *is* available
[06:31] <cjwatson> seb128: I've committed the fix for my gutsy tree anyway
[06:31] <seb128> cjwatson: ok, thank you
[06:31] <cjwatson> (just commenting it out, since it's a workaround)
[06:32] <pitti> cjwatson: TBH I'd rather leave it as it is and fix the actual glib bug
[06:32] <seb128> pitti: well that's a workaround for the time we fix the glib bug
[06:32] <cjwatson> I agree, hence only commenting it out
[06:32] <kylem> danielk, around?
[06:32] <kylem> BenC, around?
[06:32] <kylem> danielk, try adding sata_nv.adma=0 to your command line.
[06:32] <pitti> seb128: weird, I thought that was assigned to me some days ago
[06:33] <cjwatson> pitti: why is ubiquity.mo in language packs at all?
[06:33] <cjwatson> pitti: in fact, I don't see it in the -de ones (random example)
[06:33] <pitti> cjwatson: ubiquity doesn't use it?
[06:33] <seb128> pitti: I closed the bug which was assigned to you as a dup
[06:33] <seb128> pitti: there was a bug much older on ubiquity
[06:33] <pitti> seb128: I see
[06:33] <cjwatson> pitti: ubiquity is designed to ignore language packs because typically we want the installer to have broader language coverage than will fit on the CD in the form of langpacks
[06:33] <pitti> ./language-pack-de-base/data/de/LC_MESSAGES/ubiquity.po
[06:34] <seb128> pitti: bug #45741
[06:34] <ubotu> Malone bug 45741 in ubiquity "Ubiquity desktop icon "Install" is not translated" [High,Confirmed]  https://launchpad.net/bugs/45741
[06:34] <cjwatson> <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/l/language-pack-de-base/language-pack-de-base_7.04+20070329_all.deb | grep ubiquity
[06:34] <pitti> cjwatson: I see
[06:34] <cjwatson> <cjwatson@riva ~>$
[06:34] <cjwatson> seb128: not convinced that's the same bug
[06:34] <cjwatson> I suppose it could be
[06:34] <seb128> "1. Desktop Icon "Install" does not appear translated although is translated and merged in Rosetta;"
[06:34] <seb128> looks like the same
[06:34] <cjwatson> I thought I remembered it working in dapper though
[06:35] <pitti> cjwatson: it's in the daily packages now; it seems my recent fix for software-properties fixed ubiquity as well
[06:35] <cjwatson> yeah, but it could just have been that I hadn't merged it into the package at that point
[06:35] <seb128> we didn't have language packs for .desktop in dapper, did we?
[06:35] <pitti> seb128: I think we did
[06:35] <cjwatson> and that it wasn't in the language pack
[06:36] <seb128> pitti: hum, right, they went during the devel cycle though, so maybe cjwatson remember it was working before that
[06:36] <seb128> s/went/came
[06:36] <cjwatson> could be
[06:36] <cjwatson> I'm sure I tested it when I first did ubiquity's .desktop infrastructure
[06:40] <seb128> pitti: glib bug confirmed BTW with gedit, I dnd the .desktop and moved the .mo somewhere else, the item is not translated then
[06:42] <pitti> seb128: heh, then this might just fix itself after a langpack update :)
[06:42] <pitti> seb128: you might actually try a live CD and install the daily langpack deb
[06:42] <seb128> pitti: I've undupped https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/95883, it's easier to track this way
[06:42] <ubotu> Malone bug 95883 in nautilus ".desktop files on desktop do not use translations" [Low,Confirmed]
[06:44] <desrt> hah.  403 on linux-image-2.6.20-14-generic_2.6.20-14.23_i386.deb.  nice touch!
[06:45] <mjg59> Ok. Looks like we've got a handle on the problem.
[06:49] <desrt> mjg59; party.
[06:59] <BenC> danielk, pitti, dholbach: Be around shortly for another kernel to test?
[06:59] <dholbach> yes
[06:59] <pitti> BenC: yup
[06:59] <pitti> BenC: the one you uploaded a while ago is no good?
[06:59] <BenC> Seems kyle nailed down the exact problem with sata_nv, we just want to make sure there are no other regressions
[06:59] <dholbach> rock
[06:59] <BenC> pitti: it's good for you, but not sata_nv
[06:59] <dholbach> go kernel team go!
[07:00] <BenC> Anyone willing to test this kernel when I get it uploaded I would appreciate too
[07:00] <BenC> be done in about 30 minutes
[07:00] <BenC> i386 and amd64
[07:00] <dholbach> super
[07:00] <zul> just tell me where you stashed it
[07:01] <pitti> BenC: btw, I made the mistake of already releasing the amd64 binaries, so l-r-m amd64 is already building against 15.24; but I guess that won't need a rebuild, unless the ABI changes again?
[07:01] <kylem> elegant solution written, damn that was easy.
[07:01] <pitti> BenC: (I already released them for testing)
[07:01] <BenC> no ABI bump
[07:01] <pitti> BenC: great
[07:02] <pitti> BenC: so I can let l-r-m build away on other arches, too?
[07:02] <BenC> pitti: The current kernel isn't too bad, the scope of the problem is more limited than the other problems
[07:02] <BenC> yeah
[07:02] <pitti> BenC: right, I thought we are pretty safe until we upload a new -meta
[07:02] <BenC> I uploaded meta :)
[07:02] <BenC> not sure if it's NEWd or not
[07:03] <pitti> meta in new?
[07:03] <pitti> BenC: it's in unapproved
[07:10] <mdz> BenC: is the patch up anywhere?
[07:11] <danielk> kylem, BenC: back
[07:13] <BenC> mdz: http://people.ubuntu.com/~bcollins/libata.diff
[07:13] <BenC> mdz: That is what's going into -15.25
[07:13] <BenC>   * sata_nv: Revert patch that enabled ADMA for NODATA transfers.
[07:13] <BenC>     - GIT-SHA 6429d0744ca5ffe007109ef4d70414bebe15966c
[07:13] <BenC>   * libata: Completely avoid HPA code paths when ignore_hpa=0
[07:13] <BenC>     - GIT-SHA 9e3e1aea530dcb2e792f14e365a0d6d95539bfa9
[07:13] <BenC> that's the changelog
[07:18] <mdz> BenC: what triggered this sata_nv problem? or is it an old bug?
[07:19] <BenC> mdz: HPA triggered it
[07:19] <BenC> it does NODATA transfers, and tripped up the ADMA code in sata_nv
[07:19] <cjwatson> the HPA ATA commands time out on that controller in that mode
[07:19] <cjwatson> specifically those commands
[07:19] <doko> heno: the edubuntu dvd images are not listed on the testing pages; anyway, got the same results as with yesterday's images (plus the keyboard problem was fixed / or a bad disk)
[07:20] <BenC> it seems to really be a hw issue, but we worked around it
[07:20] <mdz> BenC: the HPA changes look very reasonable, though sata_nv is opaque to me
[07:20] <cjwatson> dunno, does the ADMA engine have a spec? the patch being reverted now might be violating it
[07:21] <BenC> mdz: the patch is just a -R of the one that introduced ADMA for NODATA calls
[07:21] <BenC>      commit 382a6652e91b34d5480cfc0ed840c196650493d4
[07:21] <BenC>      Author: Robert Hancock<EMAIL_ADDRESS>[07:21] <BenC>      Date:   Mon Feb 5 16:26:02 2007 -0800
[07:21] <BenC>          sata_nv: use ADMA for NODATA commands
[07:21] <BenC> mdz: that was the problematic one
[07:22] <BenC> cjwatson: that's possible...kyle has a patch that avoids ADMA for the calls that HPA checks do
[07:22] <BenC> he sent it upstream for comment
[07:23] <BenC> builds almost done...
[07:24] <cjwatson> yeah, saw kyle's patch by mail
[07:24] <kylem> ack, meant to bcc mdz too, my bad
[07:26] <BenC> kernels are uploading
[07:26] <BenC> 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
[07:26] <BenC> 453c471013d6a378d1b41e26278d2ac2  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
[07:27] <mdz> BenC: hmm?  -15.24 was the previous upload
[07:27] <BenC> http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[07:27] <mdz> the one which is still building
[07:27] <BenC> mdz: no changelog entry, just patch
[07:27] <mdz> eeek
[07:27] <BenC> it's just for this build
[07:27] <BenC> my upload has changelog :)
[07:27] <kylem> cjwatson, http://linux-ata.org/driver-status.html
[07:28] <BenC> amd64 kernel is done
[07:29] <cjwatson> kylem: sorry, what am I looking for there?
[07:29] <pitti> BenC: downloading
[07:29] <kylem> cjwatson, you asked if the doc was open
[07:29] <BenC> cjwatson: #nvidia
[07:29] <BenC> for that URL
[07:29] <cjwatson> ah, under NDA it says
[07:30] <kylem> Robert Hancock has the docs now, i think
[07:31] <BenC> i386 done now too
[07:32] <dholbach> rebooting amd64
[07:32] <dholbach> BenC: amd64 looks good
[07:32] <BenC> boots on my xeon
[07:32] <BenC> dholbach: thanks
[07:35] <BenC> Sorry, i386 image built without the patch
[07:36] <BenC> amd64 is good though
[07:36] <dholbach> ok, then I don't need to restart the i386 :-)
[07:36] <dholbach> danielk: still around?
[07:37] <danielk> yup
[07:37] <pitti> BenC: nothing weird, smooth as silk
[07:37] <dholbach> yay pitti!
[07:37] <danielk> installing right now
[07:37] <dholbach> super
[07:37] <cjwatson> anyone else here with sata_nv?
[07:37] <pitti> oh, I might know someone
[07:38] <pitti> darn, he's offline
[07:38] <BenC> pitti: excellent thanks
[07:38] <fryfrog> sorry, pata_amd here :(
[07:38] <pitti> who can he dare to walk away from the computer on a friday evening? :-)
[07:38] <BenC> kylem: can you try the amd64 image?
[07:38] <kylem> yup.
[07:38] <kylem> suckin' it down now.
[07:39] <BenC> Shit, I'm going to need the ABI's for the -15.24 upload
[07:40] <pitti> BenC: ia64 and i386 are still building, sorry
[07:40] <cjwatson> let's see how fast we can get them to you
[07:40] <desrt> the world plots against me.
[07:40] <cjwatson> i386 is in accepted
[07:40] <BenC> I don't mind doing an abi ignore for ia64
[07:40] <desrt> amd64, powerpc, sparc.  all done!  i386 wait wait wait :p
[07:41] <Treenaks> desrt: i386 is the new m68k
[07:41] <desrt> m68k was pretty hot, i must say.
[07:41] <Keybuk> hello
[07:41] <desrt> hello sir.
[07:41] <Treenaks> hi#
[07:42] <desrt> Keybuk; haven't seen you around in a while.  how is life?
[07:42] <Keybuk> life is bloody busy ;)
[07:42] <desrt> how will life be next week?
[07:42] <Keybuk> cjwatson: so, yes, I have sata_nv
[07:42] <Keybuk> desrt: just as busy
[07:42] <desrt> (well.. one week from now, i mean)
[07:42] <Keybuk> but then the week after is nice and fluffy
[07:42] <desrt> :)
[07:42] <czr> any hints of the format of d-i mirror/http/proxy? I'm trying to build a pxe booted preseed file (using netboot) but it doesn't want to use proxy at all
[07:42] <desrt> seems like a good time to take a vacation in the south of spain
[07:42] <czr> (somewhat OT, sry)
[07:43] <Keybuk> at least one week, I'm on a plane for all of it
[07:43] <dholbach> Keybuk: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[07:43] <desrt> Keybuk; only 1 more to go :)
[07:43] <kylem> BenC, boots here.
[07:43] <Treenaks> desrt: I've been planning that too, what a coincidence :)
[07:43] <BenC> Keybuk: running amd64 kernel or i386?
[07:43] <Keybuk> BenC: amd64
[07:43] <dholbach> 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
[07:43] <BenC> kylem: http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[07:43] <BenC> s/kylem/Keybuk/
[07:43] <Keybuk> desrt: I think I have busy week, quiet week, week on a plane, week in spain
[07:43] <desrt> BenC; i have an amd64 desktop... should i be testing?
[07:43] <Keybuk> (ooh, that rimes)
[07:43] <BenC> Keybuk: Can you test the kernel there please?
[07:43] <danielk> works!
[07:43] <BenC> desrt: yes please
[07:43] <dholbach> danielk: ROCK!
[07:43] <Keybuk> BenC: downloading; what am I looking for?
[07:43] <desrt> Keybuk; how poetic.  you could be the next dr. seuss :)
[07:43] <cjwatson> accelerating the publisher now
[07:44] <BenC> Keybuk: that it boots :)
[07:44] <danielk> dholbach: yay!
[07:44] <Keybuk> BenC: so keep a spare kernel around, eh?
[07:44] <dholbach> danielk: thanks a lot for testing!
[07:44] <kylem> now i just need l-r-m... :P
[07:44] <desrt> Keybuk; just make sure the spare one isn't -14 :)
[07:44] <kylem> :)
[07:44] <BenC> danielk: works for you?
[07:45] <danielk> BenC: yup
[07:45] <dholbach> BenC: <danielk> works!
[07:45] <cjwatson> l-r-m is publishing for amd64 right now
[07:45] <desrt> ubuntu is rather full of huggers.
[07:45] <dholbach> :-D
[07:45] <cjwatson> i386 should be next cycle
[07:45] <BenC> danielk: excellent, thanks
[07:45] <mvo> kylem: you need someone with a sata_nv?
[07:45] <danielk> thanks a lot
[07:45] <BenC> mvo: the more sata_nv testing the better
[07:45] <mjg59> Excellent.
[07:45] <mjg59> We've had the kernel panic almost a week before release
[07:45] <mjg59> That's far better than usual
[07:46] <Keybuk> desrt: hugging rocks
[07:46] <desrt> my laptop still kernel panics on boot about 50% of the time due to that io-apic bug...
[07:46] <mvo>  http://people.ubuntu.com/~bcollins/kernels/feisty-release/ ?
[07:46] <dholbach> mvo: yes
[07:46] <dholbach> mvo: 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
[07:47] <BenC> mvo: Yes, i386 will be there soon if you need it
[07:47] <dholbach> ok, so when are new cds ready? :-)
[07:47] <mvo> BenC: amd64 is what I need
[07:49] <danielk> bye everyone
[07:49] <dholbach> danielk: have a nice evening!
[07:49] <kylem> danielk, thanks for your help
[07:49] <BenC> 630d17875bafda11e8c23edea56bd29f  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
[07:49] <danielk> dholbach: c'ya tomorrow!
[07:49] <BenC> uploading now
[07:49] <dholbach> danielk: yeah, see you
[07:49] <Keybuk> ok, rebooting now
[07:49] <danielk> kylem: you're welcome
[07:49] <Keybuk> if I'm not back within 30s, assume the worst and send jaffa cakes
[07:49] <danielk> later
[07:49] <heno> doko: right, I could post it but it would be marked inactive anyway; waiting for new images
[07:50] <dholbach> jaffa cakes *shudder*
[07:50] <doko> dholbach: what about pizza tonight?
[07:50] <dholbach> doko: I had pizza for lunch already :-)
[07:51] <Treenaks> dholbach: more pizza!
[07:51] <dholbach> hehe
[07:51] <desrt> BenC; life is good on -15
[07:51] <BenC> desrt: thanks
[07:51] <desrt> want a dmesg or anything?
[07:52] <desrt> (this box has 3 serial ata HDs, btw.. and no CD drive)
[07:52] <kylem> desrt, could you toss me a dmesg?
[07:53] <ogra> doko, i'll take a pizza, when do you deliver it ?
[07:53] <desrt> http://desrt.mcmaster.ca/random/linux-image-2.6.20-15-generic_2.6.20-15.24_i386-dmesg
[07:53] <Keybuk> BenC: repeat after me, "next time I give someone a new kernel ABI, I will also give them a restricted modules to go with it" <g>
[07:53] <ogra> doko, btw what about the frmabuffer prob you had with the edubuntu DVD ? is that still there ?
[07:53] <BenC> Keybuk: it's in the archive :P
[07:53] <pitti> Keybuk: lrm for amd64 is built
[07:54] <Treenaks> ogra: doko.. on a scooter.. delivering pizza throughout Germany?
[07:54] <desrt> Keybuk; but a new computer :p
[07:54] <desrt> *buy
[07:54] <Keybuk> desrt: I'm extremely happy with this one ... I can set the prettyness in games to 11
[07:54] <desrt> nvidia, eh?
[07:54] <ogra> Treenaks, only 350km :)
[07:54] <doko> ogra: yes, but it may be my graphics card. Radeon 9600 based
[07:54] <ogra> ok
[07:55] <ogra> you just didnt mention it anymore so i thought i'd ask again :)
[07:55] <cjwatson> lrm for amd64 is built but is still publishing
[07:55] <cjwatson> should be available shortlty
[07:56] <Keybuk> cjwatson, benc: booted ok with sata_nv other than missing X :)
[07:56] <BenC> Keybuk: great, thanks
[07:56] <Keybuk> did you want the dmesg or anything?
[07:57] <BenC> Keybuk: if you could pastebin it, that'd be great
[07:57] <Keybuk> http://people.ubuntu.com/~scott/dmesg
[07:57] <desrt> 64bit kernel + 32bit user
[07:58] <BenC> Keybuk: perfect, thanks again
[07:58] <desrt> we could probably do it practically for free....
[07:58] <BenC> desrt: We've thought about that, but there's not a lot of testing with 32->64-bit thunking on x86-64
[07:58] <BenC> we may be missing some functionality because of it
[07:59] <desrt> ah
[07:59] <BenC> last I checked usb-printing was borked
[07:59] <BenC> but it's been a long time since then
[07:59] <desrt> usbdevfs uses a different interface on 32 and 64?
[07:59] <desrt> eugh
[07:59] <mvo> BenC: kernel boots fine for me. you want a dmesg output or something?
[07:59] <kylem> netfilter is kind of borked for 32->64.
[08:00] <BenC> desrt: No, same interface, but ioctl's have to be translated when userspace and kernel don't match
[08:00] <mvo> usplash looks funny though, but that may as well be my gfx card dying (ancient ati)
[08:00] <kylem> it's also a royal pain in the god damned arse to debug.
[08:00] <desrt> BenC; ah.  this is true.
[08:00] <cjwatson> I know this kernel stuff has been a fun ride, but I can't believe the recent changes would affect usplash
[08:01] <kylem> mvo, 'funny'?
[08:01] <Treenaks> kylem: smiley faces, etc.
[08:01] <mvo> kylem: sort of flickery, in the background, makes my eyes hurt. but once gdm is up, everything is fine again
[08:01] <kylem> weird.
[08:02] <cjwatson> the ATI card in my laptop fails to get set up correctly once every so often, and flickers madly until you change video mode
[08:02] <mvo> I have not seen that before, but I doubt that its releated to the kernel, I rarely watch my system booting
[08:02] <cjwatson> sometimes even that doesn't sort it out and I need a suspend/resume cycle to do it
[08:02] <BenC> happens in my powerbook a lot
[08:02] <Treenaks> kylem: (bug 20283 if you really want to know)
[08:02] <ubotu> Malone bug 20283 in xserver-xorg-video-ati "[X700]  Really bad sync on HP NW8240" [Medium,Confirmed]  https://launchpad.net/bugs/20283
[08:02] <cjwatson> used to be about one time in four, I think not so much recently
[08:03] <kylem> hmm
[08:04] <BenC> cjwatson: any ETA for the 386 build, so I don't have to run this command every 2 minutes? :)
[08:07] <cjwatson> BenC: it's in the final stages - maybe five-ten minutes
[08:07] <cjwatson> ia64 is still missing
[08:08] <cjwatson> happy with you abi-ignoring that if the other arches are clean
[08:08] <cjwatson> though the build looks not a million miles from finishing
[08:09] <dholbach> brb
[08:09] <cjwatson> publisher> running germinate
[08:11] <mdz> er, I just noticed that my root filesystem is not in mtab on my laptop
[08:11] <mdz> I wonder when that happened
[08:12] <mdz> need to reboot to test the new kernel anyway, will find out if it's persistent
[08:12] <mdz> brb
[08:12] <cjwatson> BenC: done, modulo mirroring
[08:13] <BenC> cjwatson: is there a place I can get to it from rookery?
[08:14] <dholbach> -15 is happy on both my i386s (was happy there before too)
[08:14] <cjwatson> BenC: by the time you set anything complicated up, it'll have mirrored to archive.ubuntu.com
[08:14] <BenC> dholbach: great, thanks
[08:14] <BenC> cjwatson: ok, thanks
[08:14] <dholbach> np
[08:14] <cjwatson> the linux-headers package is up, it's obviously in the middle of it
[08:14] <BenC> ah, grabbing it now
[08:15] <cjwatson> there it is
[08:15] <cjwatson> may depend on which mirror you hit, try again in a bit if it fails
[08:16] <mdz> BenC: the i386 kernel whose md5sum you posted looks OK here
[08:16] <mdz> BenC: are you soliciting dmesgs?
[08:16] <BenC> mdz:  If you don't mind, please
[08:17] <jwendell> seb128, Hi
[08:17] <desrt> i386 -15 is up?
[08:17] <rpereira> Does someone have problems too with Atheros AR5002 and network-manager?
[08:17] <jwendell> seb128, any reason to not update libnotify and notification-daemon to latest version? They're available since Feb 27
[08:17] <mdz> BenC: people.ubuntu.com/~mdz/temp/dmesg
[08:18] <cjwatson> desrt: yes, though not the sata_nv fix yet
[08:18] <dholbach> jwendell: we're 6 days away from release
[08:18] <kylem> [    4.152000]  BEN: Called!!
[08:18] <kylem> [    4.152000]  BEN: Left, 1, 0
[08:18] <kylem> ;-)
[08:19] <cjwatson> I was about to comment on that too
[08:19] <desrt> cjwatson; that's fine.  intel chipset here :)
[08:19] <BenC> mdz: Ah, that's an outdated kernel...can you grab the current one?
[08:19] <cjwatson> I assume you're taking those out for upload? :)
[08:19] <BenC> I don't suspect any problems, so it's not necessary
[08:20] <mdz> BenC: that's odd, the changelog looks correct
[08:20] <mdz> linux-source-2.6.20 (2.6.20-15.24) feisty; urgency=low
[08:20] <mdz>   [Ben Collins]
[08:20] <mdz>   * libata: Re-add the tracking of n_sectors_boot
[08:20] <mdz>     - GIT-SHA 1fa3ab07416406841cc1c7064b55fb084bbb1e3f
[08:20] <mdz>   * i2c_ec: Do not set parent device. Current ACPI is not setup for this.
[08:20] <mdz>     - GIT-SHA d80fb3540d170f18639c08f64afd133129bed856
[08:20] <mdz>     - Bug #96480
[08:20] <ubotu> Malone bug 96480 in linux-source-2.6.20 "Kernel 2.6.20-13 acpi bug" [Critical,Fix committed]  https://launchpad.net/bugs/96480
[08:20] <mdz>   [Upstream Kernel Changes]
[08:20] <mdz>   * 2.6.21 fix lba48 bug in libata fill_result_tf()
[08:20] <mdz>  -- Ben Collins<EMAIL_ADDRESS>Thu, 12 Apr 2007 18:58:24 -0400
[08:20] <BenC> mdz: that was a mid testing build
[08:20] <BenC> mdz: the first i386 build I did was bogus, you must have grabbed it first
[08:20] <cjwatson> Keybuk: heh, if you boot into recovery mode, bootchart sits spinning on sleep 0.2 ...
[08:21] <mdz> BenC: where's the new one?
[08:21] <jwendell> dholbach, i know, i asked just because since it was release, we had a lot of time to put it into feisty
[08:21] <dholbach> jwendell: seems it went unnoticed
[08:21] <BenC> mdz: same location
[08:21] <BenC> 630d17875bafda11e8c23edea56bd29f  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
[08:21] <BenC> there's the right md5sum
[08:22] <mdz> BenC: I don't have the URL anymore because I rebooted...
[08:22] <BenC> mdz: people.u.c/~bcollins/kernels/feisty-release/
[08:22] <mdz> BenC: that's the same one I had before
[08:22] <mdz> same md5sum
[08:23] <mdz> 630d17875bafda11e8c23edea56bd29f  linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
[08:23] <BenC> mdz: let me check the bins...
[08:23] <desrt> BenC; -15-generic-i386 works on 1st gen macbook
[08:23] <desrt> dmesg?
[08:24] <BenC> desrt: not with the 386 that you have
[08:24] <BenC> 5d86d7f2b81fbe886225838a12440fe1  linux-image-2.6.20-15-generic_2.6.20-15.24_amd64.deb
[08:24] <BenC> there's the right one, uploading
[08:24] <BenC> sorry about that
[08:24] <BenC> damn...that's amd64
[08:24] <desrt> BenC; i have the i386 md5 630d17875bafda11e8c23edea56bd29f
[08:25] <desrt> from like 30 seconds ago :p
[08:25] <Treenaks>
[08:25] <desrt> arf.  no -headers package -> no madwifi
[08:25] <BenC> Ah, ok, that build is good
[08:26] <BenC> it's all goodness
[08:26] <desrt> awesome.  it works. :)
[08:26] <desrt> don't suppose you have a matching -headers for it? :)
[08:26] <BenC> there's no self printk's in the uploaded source though
[08:26] <BenC> desrt: Not yet :)
[08:26] <BenC> desrt: the headers in the archive should be good for it
[08:26] <desrt> cool.
[08:28] <desrt> today i go down to the coffee shop that always makes my laptop crash
[08:28] <desrt> and find out why
[08:29] <fabbione> desrt: your eyes will bleed.. don't :)
[08:29] <desrt> fabbione; i suspect that it might be the easiest place for a workaround :p
[08:30] <BenC> Mithrandir, mdz, cjwatson: uploaded
[08:30] <mdz> BenC: to the archive?
[08:30] <BenC> mdz: yes
 'AARGH MY EYES' <coffee shop owner> Why? <desrt> Your AP breaks my Ubuntu and now I have to read networkmanager source <owner> I'll buy another ap if you stop bleeding on my stuff
[08:30] <mdz> BenC: do you have a debdiff?
[08:31] <BenC> And if anyone else has a showstopping kernel bug, please give me at least 2 hours :)
[08:31] <BenC> mdz: I already sent it to you
[08:31] <Treenaks> BenC: smart batteries? (or are they fixed too? :)
[08:31] <mdz> hasn't come in yet
[08:31] <BenC> mdz: Other than the ABI files, and debian/changelog, you have the idff
[08:31] <mdz> by email?
[08:31] <mjg59> Treenaks: Fixed
[08:31] <Treenaks> mjg59, BenC: \o/
[08:31] <fabbione> BenC: me wants ocfs2 crack :P
[08:31] <BenC> mdz: http://people.ubuntu.com/~bcollins/libata.diff
[08:31] <mjg59> Treenaks: Should be, anyway
[08:31] <Treenaks> mjg59: (yay for acer laptops... *sigh*)
[08:31] <zul> fabbione: no you just want crack
[08:32] <mjg59> Treenaks: It's hard to tell, none of us have affected hardware
[08:32] <fabbione> zul: point..
[08:32] <Treenaks> mjg59: I do, but it's on edgy atm
[08:32] <Treenaks> I could upgrade..
[08:32] <mdz> never mind, I'll generate one
[08:32] <mdz> it's important to review the exact diff used in the upload, even if we think we know what went into it
[08:33] <BenC> mdz: I just diff'd the tags from my upload, I've no other way to get a diff quickly
[08:33] <mdz> BenC: I'll pull one from the upload and put it up
[08:35] <mdz> http://people.ubuntu.com/~mdz/temp/2.6.20-15.25.diff
[08:36] <fabbione> 403
[08:36] <desrt> mdz; 403
[08:36] <cjwatson> I've read through it independently (mdebdiff from what's in the queue), but it matches what I understood to be in the upload
[08:36] <mdz> fixed
[08:36] <mdz> cjwatson: neat, didn't know about mdebdiff
[08:37] <fabbione> is mdebdiff something running on dresher?
[08:37] <fabbione> there is no such thing in the archive
[08:38] <cjwatson> yes
[08:38] <fabbione> ok
[08:38] <cjwatson> it's a script that combines debdiff with madison-lite (aliased to m on drescher)
[08:38] <mdz> diff is OK with me
[08:39] <cjwatson> palmer's nearly finished with l-r-m/i386
[08:39] <glick> hmmm pymedia isnt included in ubuntu repos :/
[08:39] <mdz> cjwatson: so you'll accept l-m along with the new l-s?
[08:40] <cjwatson> yeah
[08:41] <glick> hmm maybe ill maintain that package
[08:41] <glick> package it up
[08:41] <glick> bring it into ubuntu repos
[08:41] <cjwatson> publisher running
[08:41] <fabbione> cjwatson: thanks
[08:42] <BenC> cjwatson: gracias...lets go grab a beer
[08:43] <desrt> wow.  that bug on launchpad is getting interesting
[08:43] <glick> anyone heard of pymedia?
[08:43] <desrt> people are starting to swear and call each other names
[08:44] <kylem> BenC, everything look ok?
[08:45] <BenC> kylem: looks good to me
[08:45] <BenC> kylem: thanks
[08:45] <mjg59> desrt: Which one?
[08:45] <kylem> ok cool
[08:45] <kylem> pizza time
[08:46] <glick> whats the channel for ubuntu motu?
[08:46] <kylem> #ubuntu-motu
[08:46] <glick> thanks
[08:46] <kylem> welcome.
[08:46] <desrt> \
[08:47] <desrt> mjg59; https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106063
[08:47] <ubotu> Malone bug 106063 in linux-source-2.6.20 "MASTER: Computer will not boot after 2.6.20-14.23 kernel upgrade" [Critical,Fix committed]
[08:47] <desrt> "The" bug
[08:48] <theCore> BenC: was there a problem with today's kernel?
[08:48] <desrt> theCore; heh.
[08:48] <mvo_> lol
[08:48] <kylem> haha.
[08:48] <theCore> uh?
[08:49] <desrt> theCore; yes.  a rather large problem.
[08:49] <theCore> ah
[08:49] <desrt> theCore; fixed now, though.. and building.
[08:49] <theCore> W: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.20/linux-image-2.6.20-14-generic_2.6.20-14.23_i386.deb
[08:49] <theCore>   403 Forbidden [IP: <IP_ADDRESS> 80]
[08:49] <desrt> theCore; that's the broken one
[08:49] <desrt> theCore; it's forbidden for your own protection :)
[08:49] <theCore> so that explains this :)
[08:49] <doko> seb128, dholbach: python-gst (universe) currently FTBFS, no rdeps and build-deps. ok to remove from feisty?
[08:50] <theCore> any link to the bug?
[08:50] <desrt> theCore; i just pasted it up there ^^
[08:50] <theCore> ah
[08:50] <theCore> thanks desrt
[08:50] <desrt> no prob.
[08:54] <theCore> ouch, there is some angry complains on this bug report
[08:54] <doko_> seb128, dholbach: python-gst (universe) currently FTBFS, no rdeps and build-deps. ok to remove from feisty?
[08:57] <seb128> doko_: yep
[08:57] <doko_> seb128: want a bug report?
[08:57] <seb128> yes
[08:57] <seb128> or don't bother
[08:57] <seb128> I'll do it now
[08:58] <seb128> there is python-gst0.10 now anyway
[09:03] <doko_> seb128: bug 106304
[09:03] <ubotu> Malone bug 106304 in gst-python "please remove the gst-python source and binaries from feisty" [Undecided,Unconfirmed]  https://launchpad.net/bugs/106304
[09:03] <seb128> doko_: ok
[10:08] <Kmos> BenC: you sent that ata fix to kernel.org people ?
[10:09] <cjwatson>   * libata: Re-add the tracking of n_sectors_boot
[10:09] <cjwatson> that was syncing up with patches discussed upstream
[10:09] <cjwatson>   * 2.6.21 fix lba48 bug in libata fill_result_tf()
[10:09] <cjwatson> that was an upstream change to start with
[10:09] <Kmos> :-)
[10:09] <Kmos> ha
[10:09] <Kmos> its been uploaded to archive ?
[10:10] <cjwatson> and Kyle sent a better version of the sata_nv patch in -15.25 upstream; the patch as uploaded just reverted an earlier upstream change for the time beeing
[10:10] <cjwatson> being
[10:10] <cjwatson> ok, so the current state is:
[10:10] <kylem> we're all groovy.
[10:10] <kylem> :)
[10:10] <cjwatson> -15.24 is in the archive and built everywhere
[10:11] <cjwatson> except possibly ia64, and if not that's on its way
[10:11] <cjwatson> -15.24 should work for everyone except people using sata_nv
[10:11] <cjwatson> for sata_nv, -15.25 has been uploaded
[10:11] <Kmos> nice
[10:11] <Kmos> thx for the info
[10:11] <cjwatson> but it has not yet built
[10:11] <cjwatson> (in progress, hamsters running as fast as they can)
[10:12] <cjwatson> so sata_nv users should stay on -13 until -15.25 is available, and everyone else should use -15.24
[10:12] <cjwatson> and REPORT REGRESSIONS ASAP
[10:12] <Kmos> :)
[10:13] <theCore> I am sure everyone loves this crazy Friday 13th.
[10:15] <Seveas> cjwatson, maybe they'd run faster if someone would feed them steroids ;)
[10:17] <radevil> hello
[10:18] <radevil> does anybody in here work for canonical???
[10:19] <Kmos> I think a lot :)
[10:19] <radevil> yes? :)
[10:19] <radevil> i found the employment web page in ubuntu site
[10:20] <radevil> i'm interested in a position for server developer
[10:21] <cjwatson> the employment page has an address for applications
[10:21] <cjwatson> we don't really take applications by IRC ;-)
[10:21] <radevil> i already made a CV and i'm making a cover letter, it's hard for me to make such a formal letter in english
[10:22] <radevil> so i wanted to konw if  i can speak with somebody in here directly
[10:22] <radevil> know*
[10:22] <fdoving> isn't there #canonical ?
[10:22] <radevil> i don't know i don't want to mess it up sending a cover letter full of errors :P
[10:23] <cjwatson> fdoving: not on a public server
[10:23] <radevil> mmm i don't know i'll try it
[10:23] <fdoving> cjwatson: ok.
[10:23] <cjwatson> and when it was it was passworded
[10:23] <radevil> [#canonical]  CHANNEL HAS MOVED
[10:24] <radevil> do you guys work from your houses?????
[10:24] <cjwatson> radevil: we understand that some people's English is not 100%, and it's OK to note that
[10:24] <cjwatson> most Canonical-employed Ubuntu developers work from home, though not quite all
[10:24] <cjwatson> generally that's the expectation for new staff
[10:24] <radevil> is it a full time job??
[10:25] <cjwatson> yes
[10:25] <theCore> radevil: I think they look more at your competences and accomplishment than you English mistakes
[10:26] <cjwatson>    Strong English language communication skills, especially in online environments such as mailing lists and IRC
[10:26] <cjwatson> you do need to be able to get by pretty well
[10:26] <cjwatson> though that's not the same thing as being able to compose formal letters
[10:26] <theCore> bah.... I even made two mistakes saying that ...
[10:27] <cjwatson> being able to communiate effectively on a day-to-day basis is the important bit, really
[10:27] <cjwatson> disclaimer: I am a hiring manager at Canonical, but I am not the hiring manager for the server positions
[10:28] <radevil> ohh )
[10:28] <radevil> :)
[10:28] <cjwatson> if you want help with your covering letter or CV, I think it would be better to find help locally than to look for somebody from Canonical to do it
[10:28] <theCore> cjwatson: hire me! :)
[10:28] <cjwatson> in some ways it's a bit pointless to look for help from employees of the company you're applying to with regard to the impression you're making on that company :-)
[10:29] <radevil> lol yes
[10:29] <theCore> (just joking)
[10:29] <radevil> cjwatson: can i make you a few questions??
[10:30] <cjwatson> radevil: it's off-topic for this channel, but you can ask me in private
[10:30] <radevil> ohh ok, i'll pm you
[10:42] <doko> Mithrandir: I'd like to update gcc-snapshot again to fix the i386 build failure, but I'm worried about build times; would it be ok to upload tomorrow when the kernel packages are built?
[10:48] <Solarion> how hard would it be to implement a GUI for user ulimits?
[10:48] <Solarion> [e.g. have gdm, login, ssh, etc. set ulimits when user logs in]
[11:00] <ajmitch> morning
[11:04] <Solarion> that easy, eh?
[11:19] <Mithrandir> seb128: X-Ubuntu-Desktop-Domain> IMO too late.
[11:19] <fryfrog> i hate to bug the devs, but i'm having some trouble with the *new* kernel and I think I saw someone talking about a work around earlier.  It was I *think* a kernel arg to disable "hpa" of some sorts, but I don't recall what it was.  Does anyone know, or is there a log of the channel somewhere?
[11:19] <seb128> Mithrandir: yeah, we decided to not do the change
[11:23] <Seveas> fryfrog, /join #ubuntu+1 and read the topic
[11:23] <mc44> Seveas: he meanwithhhhhhh1
[11:24] <mc44> oops
[11:24] <fryfrog> i'm talking about the new "fix" kernel -15
[11:24] <mc44> Seveas: he means with -15
[11:24] <Seveas> fryfrog, *new* isn't really specific when there's 3 revisions you can refer to as new :)
[11:25] <fryfrog> ah, sorry :)
[11:25] <fryfrog> i should have specified :)
[11:25] <fryfrog> does "n_sectors mismatch" ring a bell?
[11:28] <Seveas> fryfrog, https://launchpad.net/ubuntu/feisty/+source/linux-source-2.6.20/2.6.20-15.24
[11:29] <Seveas> fryfrog, which by the way is not the latest kernel
[11:29] <Seveas> (or is it, me is very confused about kernels today)
[11:29] <mc44> yeah its not -15.24 yet
[11:29] <Seveas> .25 is latest
[11:30] <mc44> the ones in the repos are .14, right
[11:31] <jdong> repos are still -14....
[11:31] <jdong> at least as of 25 minutes ago
[11:31] <fryfrog> so i should just hang in there then?
[11:32] <mc44> jdong: they are -15.14 for me
[11:32] <fryfrog> i'm booting to my gentoo livecd so i can chroot into it
[11:32] <jdong>   Candidate: <IP_ADDRESS>.14
[11:32] <jdong> ah yes
[11:32] <jdong> new apt-get update shows that
[11:32] <jdong> also the fact I'm on the ANL mirror doesn't help with my updatedness :D
[11:36] <fryfrog> humm, i can't find a boot kernel option to disable hpa
[11:36] <kylem> libata.ignore_hpa=1
[11:37] <fryfrog> ahhh!
[11:37] <fryfrog> thankyou :)
[11:37] <fryfrog> that is what i was looking for
[11:37] <jdong> aah the whole internet's slow today :D
[11:38] <kylem> fryfrog, can you please pastebot your dmesg for me?
[11:38] <fryfrog> sure, once i'm into a networkable place i can get it :)
[11:39] <kylem> ok
[11:39] <fryfrog> is it okay that it will be with the ignore_hpa=1 option
[11:39] <fryfrog> ?
[11:39] <fryfrog> crap, that didn't do it, did i typo something?
[11:40] <kylem> no. i need to see the mismatch messages
[11:40] <fryfrog> ah, sure i can just do that from teh typing skills
[11:41] <kylem> you included the libata. part right?
[11:41] <fryfrog> ata1.00: n_sectors mismatch 150994954 != 15630488
[11:41] <ajmitch> though I think I have an identical mb to you, kylem
[11:41] <fryfrog> revalidation failed
[11:41] <fryfrog> disabled
[11:41] <fryfrog> yeah, i'm checking for typos now
[11:41] <pkl_>  libata: Completely avoid HPA code paths when ignore_hpa=0 ?
[11:42] <fryfrog> its okay for it to be "ro libata.ignore_hpa-1 single" right?
[11:42] <fryfrog> i mean, the order of "ro" and "single" and libata.ignore_hpa=1" doesn't matter
[11:43] <fryfrog> er, that was a = not -, dang laptop kb
[11:43] <kylem> fryfrog, there should be a line above that says ata_hpa_resize 1, can you copy that line too?
[11:43] <fryfrog> sure
[11:44] <fryfrog> ata_hpa_resize 1: sectors = 156299375, hpa_sectors = 156301488
[11:44] <fryfrog> want the "current size" and "native size"?
[11:44] <kylem> yeah
[11:44] <fryfrog> current size : 156299375 sectors (80025 MB)
[11:45] <fryfrog> native size : 156301488 sectors (80026 MB)
[11:45] <fryfrog> then it says native size increased to 150994954 sectors
[11:45] <fryfrog> blech, i wish i could copy/paste it :/
[11:45] <fryfrog> wonder if i can mount an nfs share
[11:46] <kylem> what chipset?
[11:46] <fryfrog> pata_amd
[11:46] <fryfrog> er, well that is the driver
[11:46] <kylem> ok
[11:46] <fryfrog> i believe it is an nforce4 on it's PATA port
[11:47] <fryfrog> er, -believe
[11:47] <fryfrog> i know :)
[11:47] <fryfrog> the "libata.ignore_hpa=1" doesn't change anything (nor does =0)
[11:49] <kylem> hrm.
[11:50] <fryfrog> got my myth backend working, now the fe is busted! :)
[11:50] <fryfrog> i could provide a booted with gentoo livecd, but i dont think that'd help :(
[11:50] <fryfrog> i mean, access to it
[11:52] <kylem> got a digital camera?
[11:52] <fryfrog> sure, want a pic of the section?
[11:52] <kylem> yes, very much thank you
[11:52] <fryfrog> just the part around the ata error?
[11:54] <kylem> if possible the whole section where you see disks detected, lines beginning with atax.x: especially
[12:01] <fryfrog> ok
[12:01] <fryfrog> i forgot to check if my webserver had come back after the feisty update :)
[12:03] <kylem> are you running i386-generic?
[12:03] <fryfrog> "-generic" (not amd64)
[12:03] <kylem> i mistakenly thought 15.25 was in the archive already, but i was wrong. the ignore_hpa thing was added there.
[12:03] <kylem> http://people.ubuntu.com/~bcollins/kernels/feisty-release/linux-image-2.6.20-15-generic_2.6.20-15.24_i386.deb
[12:03] <kylem> this should help.
[12:07] <fryfrog> http://fryfrog.com/wordpress/v/MaryAnn-Donnie/Donnie/Test/
[12:07] <fryfrog> ahhh
[12:08] <kylem> thanks, looking
[12:08] <fryfrog> its a pretty crappy monitor :)
[12:08] <fryfrog> ah, but not to bad i can read it :)
[12:08] <Stormx2> Hey. Wouldn't it be possible to have concurrent connections in apt-get update? I'm pretty sure it does the package lists 1-by-1, even if they are on seperate servers
[12:09] <fryfrog> i think "aptitude update" must do them concurrently
[12:09] <fryfrog> maybe?
[12:09] <fryfrog> maybe not