[03:09] <ScottK> slangasek: I'm reviewing the queue.  Some of it looks familiar....
[06:06] <slangasek> familiar?
[06:11] <lamont> slangasek: so...  acorn build failed, but acorn DIDN'T!!  this is progress.
[06:12] <slangasek> ah, cool
[06:12] <lamont> re build-queue, I expect we'll have that resolved once london is awake
[06:12] <slangasek> I didn't bother looking at the log... :)
[06:12] <slangasek> s/looking at/looking for/
[06:12] <slangasek> yes, that seems to be the consensus
[06:12] <lamont> right.  me neither.  just passing through before crashing.
[06:13] <lamont> there was a change made this morning that is very co-incident to the cessation of builds
[06:13] <lamont> so I've lobbed that grenade back to the involved, come wakey-wakey in london
[06:15]  * lamont tries one thing before sleeping
[07:16]  * ogra hugs lamont 
=== ogra_ is now known as ogra
[09:09] <ttx> slangasek/cjwatson: jjohansen investigated options for bug 546743
[09:09] <ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed] https://launchpad.net/bugs/546743
[09:10] <ttx> jjohansen: could you detail them again ?
[09:10] <jjohansen> options are kernel quirk, or we could set /etc/modprobe.d/radeon-kms.conf to have options radeon modeset=0
[09:11] <ttx> jjohansen: would kernel quirk be limited to -server kernels ?
[09:11] <jjohansen> no
[09:11] <ttx> would it be limited to ES1000 ?
[09:12] <jjohansen> well I would hope so it would be targeted at a specific match
[09:13] <ttx> jjohansen: but you don't like this last option, as it means breaking the freeze, right
[09:14] <jjohansen> yes it will require breaking kernel freeze it is the proper way to do it, but very late
[09:15] <ttx> jjohansen: will apw update it anyway to fix the i830 kms issue ?
[09:15] <jjohansen> ttx: maybe but this one won't have been tested
[09:17] <ttx> The problem with /etc/modprobe.d/radeon-kms.conf is that it would break all radeon KMS iiuc, also I'm not sure that one is installed on servers
[09:20] <ttx> another option is to play with server kernel boot options but that would affect everyone rather than just ES1000 users, and some people like to have big consoles (don't ask)
[09:21] <jjohansen> ttx: kernel mode line could just set it for radeon
[09:21] <jjohansen> radeon.modeset=0
[09:21] <jjohansen> instead of nomodeset
[09:22] <ttx> jjohansen: ok. That's still a little uglier, especially in update scenarios
[09:22] <ttx> slangasek/cjwatson: deferring to you on this. I obviously prefer the inkernel fix, but I understand John's concerns as well
[09:22] <jjohansen> ttx: yep
[09:23] <slangasek> we certainly don't want to be disabling KMS for all radeon systems
[09:23] <jjohansen> well I am against the in kernel fix at all until it is tested
[09:24] <slangasek> then I think this is release notes material, documenting that users need to add the kernel option when booting
[09:24] <slangasek> and we can try to fix it for the first post-release SRU
[09:25] <ttx> jjohansen: fader can help in testing, he has quite a few affected boxes available in HW enablement
[09:26] <jjohansen> ttx: okay, I will get him a kernel to test and we will get this in for the first SRU
[09:26] <ttx> slangasek: note that it affects "certified" configs, even if that manual test is not part of the automated acceptation tests
[09:29] <ttx> jjohansen: ok, I'll report suggested solution to management and see how well it flies
[09:30] <ttx> slangasek, jjohansen: thanks !
[09:30] <jjohansen> ttx: I'm sure not well
[09:30] <ttx> jjohansen: we'll see :)
[09:33] <apw> slangasek, the option nomodeset looks to be no longer working because of some module options X are installing and i am not sure why they are installing them at the moment
[09:33] <slangasek> /etc/modprobe.d/radeon-kms.conf?
[09:34] <apw> yeah those force kms on (there is an i915 one too)
[09:34] <apw> and so to turn it off you have to use i915.nomodeset to undo it, nomodeset cannot do it
[09:34] <apw> it is also what is stopping the i830 work quirking from working too
[09:35] <apw> which is why it didn't get uploaded yesterday ... i only found that the setting wasn't -1 as it should be at midnight, and only foudn the overrides this morning
[09:35] <slangasek> I think that's a mismerge from Debian
[09:36] <apw> damn ... ok so for the quirks to work we'd need to upload the kernel bits and x...-intel
[09:36] <apw> don't know if we want to do go that far or wait and sru it
[09:36] <slangasek> uploading the X bits is not a problem, and should be done anyway even if the kernel has to be postponed
[09:36] <apw> i can easily do the kernel bits for i830 etc
[09:36] <slangasek> I'm comfortable uploading to drop those blacklist files
[09:37] <mvo> I can test the fixes, I have the require HW
[09:37] <slangasek> though I still need to get mountall off my plate first
[09:37] <apw> the patches there got some testing last night by mvo, and he could retest today removing the file manually
[09:37] <slangasek> since I've been fighting with that for 3h due to a change in bzr that made all my filesystems fail to mount at boot :/
[09:38] <slangasek> mvo: for i830, or ES1000?
[09:38] <apw> oh he is here ... mvo if you could comment out the contents of /etc/modprobe.d/i915-kms.conf
[09:38] <apw> and redo the test you did last night for me
[09:38] <apw> with no kernel command options
[09:38] <mvo> sure
[09:38] <apw> slangasek, what i can't be sure of getting is the dell bits fixed today, that is a tricky
[09:38] <slangasek> mmk
[09:39] <apw> if we don't get dell done do you still want the i915 blacklists uploading?
[09:39] <slangasek> apw: well, I know from the bug log that rickspencer3 does
[09:39] <ttx> slangasek: would you consider adding radeon.modeset=0 to server installs (in the same vein we remove "splash") to be a pre-release option ?
[09:40] <apw> jjohansen, where we at with the radeon thing there
[09:40] <slangasek> ttx: I'm not happy with that across the board, it means using a completely different code path for displays on server than desktop and may cause us unreproducibility grief
[09:40] <apw> jjohansen, i have blacklist framework for radeon available if we know the PCI-id
[09:41] <ttx> slangasek: ack
[09:41] <slangasek> ttx: and it means having the installer guys make touchy changes to the installer the week before RC, for something which is just a workaround for a bug we plan to SRU anyway
[09:41]  * apw pokes jjohansen 
[09:41] <ttx> slangasek: (just checking) :)
[09:41] <mvo> apw: win
[09:41] <mvo> apw: works just fine now
[09:42] <apw> mvo ... now if it had done that at 10 last night we'd have it in ... grrr
[09:42] <mvo> :(
[09:42] <apw> mvo, not your fault, a miss-merge of another package
[09:42] <mvo> yeah, hope it can still make it, the diff is small and even though the machines are old, they are still in use
[09:43] <slangasek> apw: has that also been regression-tested on non-i830 intel?
[09:44] <ttx> apw: we can certainly get you a PCI-id if that's what it takes
[09:44] <apw> slangasek, not as yet, now the positive side of it is working i want to test the negative
[09:44] <slangasek> well, huh - just reproduced bug #533745 locally for the first time
[09:44] <ubottu> Launchpad bug 533745 in sitecmd "link() - move $params to 3rd parameter" [Low,Fix released] https://launchpad.net/bugs/533745
[09:44] <slangasek> great night for boot bugs, here
[09:45] <apw> ttx could you get it for me yes
[09:45] <apw> slangasek, would you prefer i try and blacklist this radeon one as well to save changes to the installer?
[09:45] <ttx> apw: I don't have that HW, fader has it in the labs... I'm parsing existing logs to see if it shows
[09:46] <apw> would mean re-uploading xorg-radeon as well
[09:46] <apw> ttx whats the bug#
[09:46] <ttx> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546743
[09:46] <ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,Confirmed]
[09:46] <slangasek> apw: jj already expressed concern about uploading it untested; the X bits I'll upload for both regardless, I'll let the two of you sort out whether you want to push that change
[09:46] <apw> jj yep, testing it well enough is the only concern from myside, positive and negative testing
[09:46] <apw> slangasek, even
[09:47] <slangasek> apw: well, how soon did you want to upload the kernel?  I don't think you're going to get the one half of that testing until morning in Boston
[09:48] <apw> slangasek, yeah we could get the i915 tested and ready in a couple of hours, but the radeon would delay that till late here
[09:48] <apw> and doing that means i have little or no time to work on the dell bug
[09:48] <apw> sigh
[09:49]  * ttx gets some coffee, sounds like a long day coming up
[09:49] <slangasek> apw: work on the dell bug first, let radeon tend to itself?
[09:50]  * apw is slightly worried that they are reinventing the wheel, making new patches for blacklisting when they already exist <- jjohansen 
[09:50] <slangasek> who is?
[09:50] <apw> john ...
[09:50] <apw> i'll square it with him when i find him
[10:06] <apw> slangasek, fyi there are two linux-meta-xxx updates outstanding pending builds ... linux-mvl-dove and linux-ec2
[10:15] <slangasek> apw: linux-ec2 bins now accepted; processing dove as well
[10:17] <apw> slangasek, oh had ec2 finished
[10:26] <ogra> slangasek, the ubiquity change i talked about yesterday looks like: http://paste.ubuntu.com/414837/ (i'm still looking for the d-i equivalent, i forgot where thats set)
[10:28] <slangasek> ogra: not in a position to review right now, sorry
[10:28] <ogra> slangasek, i didnt expect you to, just wanted to show how trivial it is :)
[10:29] <ogra> sorry that i didnt manage yesterday
[10:30] <directhex> is an upload in order to make a package build on amd64 as well as i386, rather than i386-only, something that i should make for lucid?
[10:32] <slangasek> directhex: generally welcomed, but will be weighed against things like build time and complexity of the change
[10:34] <directhex> slangasek, i'm just running the test suite to make sure i didn't break anything
[10:35] <directhex> yup, passed
[10:35] <directhex> should i just make an upload & ping in here, or is a bug report preferred?
[10:37] <slangasek> upload and ping
[10:37] <slangasek> (what package?)
[10:42] <directhex> slangasek, libflaim
[10:43]  * slangasek nods
[10:44] <directhex> just doing one more test build, then i need an i386 lucid pbuilder to make sure i didn't break things there
[10:48] <directhex> bah, except "pbuilder create" is busted today
[11:02] <directhex> sigh, 6 hours to try building it in a ppa instead
[11:21] <slangasek> cjwatson: can queuebot come out and play?
[11:29] <cjwatson> starting
[11:29] <directhex> laney test-built for me on i386. just doing some lintian cleanup
[11:31] <directhex>   Uploading libflaim_4.9.966-0ubuntu3_source.changes: done.
[11:46] <slangasek> cjwatson: xserver-xorg-video-{intel,ati} in the queue are mine; could you review?
[11:46] <slangasek> (I'm happy to explain why these changes are sane, if you have questions)
[11:53] <apw> mvo, could you test the final patches for i830 here: http://people.canonical.com/~apw/master-lucid/ (with the modprobe.conf files missing)
[12:17] <slangasek> seb128: hi, libdbusmenu is listed as an "upstream merge" - has the merge result been runtime-tested before upload?
[12:18] <mvo> apw: let me do that now
[12:22] <mvo> apw: hrm, filesystemcheck on the machine, so will take some minutes
[12:22] <apw> mvo, i _hate_ that thing
[12:22]  * mvo too
[12:24] <seb128> slangasek, I've built and installed the update on my main work machine if that's what you are asking there, is an upstream merge any different of a patch in the debian dir?
[12:25] <seb128> slangasek, it's working fine for me, I don't know if ted tested it too but I guess he did
[12:25] <slangasek> seb128: if you've tested it, that's all I need to know, thanks
[12:26] <seb128> slangasek, ok, yes I'm running it there and using the indicator and didn't notice any issue ;-)
[12:27] <slangasek> seb128: in theory 'upstream merge' vs. 'cherry pick' doesn't mean anything; my real concern was the size of the patch, and whether the "upstream merge" wording might imply less rigorous testing
[12:28] <seb128> slangasek, understable, thanks for checking ;-)
[12:28] <slangasek> thanks for testing! :)
[12:32] <cjwatson> slangasek: looking
[12:32] <slangasek> thx
[12:32] <slangasek> mvo: no bug # on this libubuntuone upload, why is this needed/wanted?
[12:34] <seb128> slangasek, we discussed it on #ubuntu-desktop, because otherwise the music store loads flash which leads to bugs and crashes
[12:35] <slangasek> heh, cute
[12:35] <seb128> I've tested the update there, stored works fine
[12:35] <seb128> store
[12:36] <seb128> and rodrigo acked the change too
[12:36] <cjwatson> slangasek: I accepted it anyway since it hardly matters that much, but it looks like a buglet that you didn't remove the /etc/modprobe.d/ directory in xserver-xorg-video-ati
[12:36] <cjwatson> s/-ati/-radeon/
[12:37] <slangasek> cjwatson: yeah, noticed that after I tagged/uploaded while I was preparing -intel
[12:38] <cjwatson> both look fine, and I've verified the kernel defaults
[12:39]  * cjwatson does a dist-upgrade with his dpkg upload by way of stress-testing
[12:45] <mvo> apw: works fine the ~~i915 kernel
[12:46] <apw> mvo thanks ... thats the patches as they would be in an upload, so thanks for testing
[12:46] <apw> mvo, if you have any non-affect intel you could boot it on that would be a good data point too
[12:54]  * apw has pushed the two remaining linux-meta-* variants now that the kernles are built and accepted
[12:54]  * apw strokes queuebot -- perfect timing
[12:56] <slangasek> I'm accepting those
[12:56] <slangasek> and I've uploaded d-i for the dove ABI change
[12:56] <slangasek> someone else should review / accept :)
[12:57]  * cjwatson remembers to change kernel-version in the seeds for -21
[12:58] <cjwatson> right, this dpkg looks good
[12:59]  * ogra would like to upload flash-kernel, but it will break the images unless uboot-envtools gets approved (MIR bug 563394)
[12:59] <ubottu> Launchpad bug 563394 in uboot-envtools "MIR uboot-envtools is needed for flash-kernel installer in omap" [Undecided,New] https://launchpad.net/bugs/563394
[13:00] <cjwatson> d-i trivially ok, approved
[13:00] <cjwatson> slangasek: you planning to change the seeds to match or shall I?
[13:00] <slangasek> I can do it
[13:00] <ogra> cjwatson, was that to me ?
[13:01] <cjwatson> no
[13:01] <slangasek> hmm, speaking of seeds
[13:01] <slangasek> stgraber: did the seed reorg ever shake out with edubuntu?
[13:04] <slangasek> task field on ubiquity-slideshow-ubuntu suggests that it did
[13:14] <ttx> apw: fader is up now, if you need any info or test on the affected hw
[13:14] <fader_> ttx, apw: you guys need PCI IDs from an affected system?
[13:15] <apw> fader_, yes please
[13:15] <fader_> apw: you want the output of "lspci -vnvn" or just the ID for the video card?
[13:15] <apw> +                       { PCI_DEVICE(0x1002, 0x515e) },
[13:15] <apw> +                       { PCI_DEVICE(0x1002, 0x515f) },
[13:16] <apw> fader_, i was told it was those two that are affected, does that match
[13:16] <fader_> apw: Let me take a look
[13:18] <fader_> (It'll take me a moment as the systems are powered off and need to boot, etc.)
[13:25] <fader_> apw: 1c:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
[13:26] <fader_> (more to come)
[13:28] <apw> fader_, whats the pci ids
[13:30] <fader_> D'oh, sorry -- not yet caffeinated :(
[13:30] <fader_> 1002:515e
[13:30] <slangasek> pitti: do you need an MIR bug for a TeX macro package (feynmf)?
[13:30] <pitti> slangasek: ah, I can review that quickly; these are usually harmless
=== ogra_ is now known as ogra
[13:40] <fader_> apw: All the Lenovo systems I've checked have had the same PCI ID... I'll have the info on the IBM in a few
[13:40] <apw> ta
[13:59] <pitti> slangasek: feynmf looks harmless, promoted; I wrote bug 563788 as a paper trail
[13:59] <ubottu> Launchpad bug 563788 in feynmf "[MIR] feynmf" [Undecided,Fix released] https://launchpad.net/bugs/563788
[14:13] <apw> fader_, did i miss the IBM results?
[14:14] <fader_> apw: Sorry, having problems with that machine this morning.  I think I need Nafallo to stab its power button but he went out to lunch :(
[14:17] <fader_> I've asked him to ping me ASAP
[14:22] <apw> fader_, did i ask you to test a kerenl on those machines?
[14:22] <apw> http://people.canonical.com/~apw/lp546743-lucid/
[14:23] <fader_> apw: No, but I can
[14:23] <apw> fader_,
[14:23] <apw> you also need to disable config for radeon
[14:23] <apw> /etc/modprobe.d/radeon-kms.conf needs its content commenting out
[14:23] <apw> a dmesg from one booting that kernel would also be appreciated
[14:24] <fader_> apw: Will do... okay if I attach the dmesg to the bug?
[14:24] <apw> sure thing
[14:25] <apw> or pastebin, or paper napkin :)
[14:29] <fader_> apw: There doesn't seem to be an /etc/modprobe.d/radeon-kms.conf, at least on the first one of these I've looked at
[14:29] <apw> fader_, ok then thats fine
[14:29] <fader_> Cool
[14:29] <apw> not sure _why_ there isn't one ... but hey
[14:35] <fader_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546743/comments/15
[14:35] <ubottu> Launchpad bug 546743 in linux "Blank screen at first boot with ATI ES1000 and 10.04 server" [High,In progress]
[14:39] <apw> fader_, [    3.995143] [drm] radeon disabling kernel modesetting for known bad device.
[14:39] <apw> thanks for the testing ... that looks good
[14:39] <apw> just need to confirm that that those two id's are right
[14:39] <fader_> apw: No problem.
[14:39] <fader_> apw: The Lenovos all look to have the same one; I'll get data on the IBM as soon as I can
[14:45] <jdstrand> from #ubuntu-devel:
[14:45] <jdstrand> 08:43 < jdstrand> slangasek: I have a profile change to fix bug #517714 which  I, *ahem*, reintroduced just before freeze. ok to upload?
[14:45] <ubottu> Launchpad bug 517714 in libvirt "[Lucid] Error starting domain: could not remove profile" [Critical,Triaged] https://launchpad.net/bugs/517714
[14:49] <jdstrand> pitti: can you make this call? ^
[14:49] <jdstrand> pitti: hi btw :)
[14:53] <ttx> <apw> not sure _why_ there isn't one : because it's part of the xserver-xorg-video-radeon package, which is not installed on servers ?
[14:58] <cjwatson> also Steve removed radeon-kms.conf in his recent upload
[15:00] <pitti> jdstrand: looking
[15:04] <jdstrand> pitti: basically, my little 'deny /dev/**' maneuver was, ummm, aggressive. 'deny' overrides any allows, so the stuff for /dev in 'base' got overridden
[15:04] <pitti> jdstrand: this seems like a pure bug fix to me, though?
[15:04] <pitti> jdstrand: i. e. I don't see that this would violate FF or something
[15:05] <jdstrand> pitti: it is a totally pure bugfix. I introduced it in my last upload. profile change only-- no code changes
[15:05] <pitti> jdstrand: so, please just upload it
[15:05] <jdstrand> pitti: ah, I thought that everything had to go through you guys these days
[15:05] <pitti> jdstrand: well, we need to review the uploaded packages in the queue
[15:05] <jdstrand> pitti: can you accept it once I upload it? I'll ping you
[15:06] <pitti> jdstrand: we regularly review the queue anyway, but sure
[15:06] <jdstrand> pitti: ok thanks! the binaries are building locally. after testing I'll upload and ping
=== starshiptrooper is now known as apachelogger
[15:21] <jdstrand> pitti: uploaded. please process when convenient. thanks again :)
[15:26] <ttx> ew
[15:31] <pitti> jdstrand: done
[15:31] <pitti> bbiab
[15:36]  * cjwatson rebuilds server to cope with kernel ABI skew
[15:38] <jdstrand> pitti: thanks! :)
[15:52] <ScottK> pitti or cjwatson: Would you please rescore the pending ttf-indic-fonts build.  Until that gets published, people's upgrades are getting broken.
[15:52] <cjwatson> doing
[15:52] <ScottK> Thanks.
[15:53] <cjwatson> yay for ridiculous build queue lengths
[15:53] <cjwatson> done, 5 minutes
[15:59] <fader_> apw: PCI ID on the ES1000 on the IBM system is 1002:515e
[15:59] <fader_> Same as the Lenovos
[15:59] <apw> fader_, i wonder what this 0x515f matches to
[16:00] <fader_> apw: I don't have console access to that system but if it's useful I can ask Nafallo to plug up a KVM and watch the console for us
[16:00] <fader_> apw: No idea, I haven't found any of our systems that have it :/
[16:00] <apw> does that drm string show up?
[16:00] <apw> in dmesg
[16:01] <apw> 515e	ES1000	
[16:01] <apw> 515f	ES1000
[16:01] <apw> according to 'pci-ids'
[16:02] <fader_> apw: not with the default kernel -- the relevant lines seem to be:
[16:02] <fader_> [    4.631987] [drm] radeon defaulting to kernel modesetting.
[16:02] <apw> ok so we are happy it does the right thing on an ES1000 at least
[16:02] <fader_> [    4.631991] [drm] radeon kernel modesetting enabled.
[16:02] <fader_> [    4.632075] radeon 0000:01:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[16:02] <fader_> [    4.634692] [drm] radeon: Initializing kernel modesetting.
[16:02] <fader_> apw: Want me to try it with your new kernel?
[16:02] <apw> yeah
[16:02] <fader_> Roger wilco
[16:02] <apw> i expect it to day disabled
[16:08] <fader_> apw: [    3.646621] [drm] radeon disabling kernel modesetting for known bad device.
[16:09] <ttx> slangasek: if you're still on mountall/lvm strange issues, you might want to include bug 563902 and bug 563916 to the mix
[16:09] <ubottu> Launchpad bug 563902 in mountall "When snapshots exists, mountall will not mount the parent partition" [Undecided,New] https://launchpad.net/bugs/563902
[16:09] <ubottu> Launchpad bug 563916 in mountall "[lucid] No prompt for [S]kip or [M]anual recovery on server boot" [Undecided,New] https://launchpad.net/bugs/563916
[16:11] <ttx> slangasek: I'll prioritize/target for lucid, feel free to switch to a better package
[16:16] <apw> fader_, most excellent
[16:17] <fader_> apw: I'm at your beck and call if there's more I can do on this :)
[16:24]  * ttx highfives apw and fader_ 
[16:34] <bdrung> what do you think about this FFe request: 563940
[16:34] <bdrung> bug #563940
[16:34] <ubottu> Launchpad bug 563940 in ubuntu "ubuntu-wallpapers-extra freeze exception" [Undecided,New] https://launchpad.net/bugs/563940
[16:46] <seb128> could somebody approve the light-themes update? it fixes buttons order which got screwed in yesterday's update
=== apachelogger is now known as starshiptrooper
[17:02] <ogra> pitti, you dont happen to be bored and in MIR approval mood ?
[17:02] <pitti> ogra: no, but if it's urgent, I can do it :)
[17:02]  * ogra has a tiny little package that looks for some MIR team member to care for it
[17:03] <ogra> well, as urgent as the freeze approaching is ... not more than that though
[17:03] <ogra> bug 563394
[17:03] <ubottu> Launchpad bug 563394 in uboot-envtools "MIR uboot-envtools is needed for flash-kernel installer in omap" [Undecided,New] https://launchpad.net/bugs/563394
[17:03] <pitti> ogra: ok, looking
[17:12] <apw> slangasek, about ?
[17:14] <apw> pitti, did steve tell you about the drm blacklists issues ?
[17:15] <pitti> apw: I don't think so
[17:16] <apw> pitti, ok, then it makes sense to talk to him about things
[17:16] <apw> pitti, i assume he has gone to get some zz'
[17:19] <seb128> pitti, did you see my ping about themes?
[17:20] <pitti> seb128: erm, no?
[17:21] <seb128> pitti, can you accept light-themes, the update from yesterday screwed the button orders
[17:21] <pitti> sure, I'll review it
[17:21] <seb128> pitti, before kwwii get killed because he screwed that
[17:21] <seb128> pitti, danke
[17:22]  * pitti also accepts all the kde-l10n stuff
[17:23] <pitti> ogra: is that package actually useful on !arm?
[17:23] <pitti> -ECHANNEL, -> #u-devel
[17:42] <cjwatson> it would be good if somebody could review dpkg at some point
[17:42] <cjwatson> ah, language packs incoming
[17:43]  * cjwatson accepts a batch of them
[17:43]  * apw wonders what time slangasek will be back with us
[17:54] <cjwatson> somebody else should take over accepting language packs, to stop queuebot blowing up
[17:58] <pitti> re
[17:59] <pitti> (sorry, was @phone)
[17:59] <pitti> cjwatson: yep, can do (dpkg/langpacks)
[17:59] <pitti> cjwatson: I take it the fsync patch was tested already?
[18:07] <cjwatson> so, bit of a saga there
[18:08] <cjwatson> it's been upstream for a little while
[18:08] <cjwatson> but it was busted, as I found when I merged and tested it
[18:08] <cjwatson> so Guillem and I fixed it up between us, and Guillem hit it with some new tests
[18:09] <cjwatson> I've done test dist-upgrades using it that exercised quite a bit
[18:09] <elmo> is it a reasonable speed now? :-p
[18:09] <cjwatson> and apw confirmed that its perf on ext4 is reasonable - slightly slower than before, but not the hour to unpack l-h
[18:10] <elmo> and the fsync is to fix all the zero length bugs people were seeing previously?
[18:10] <cjwatson> I've tested on ext3 and before/after speeds there were within noise, but that was expected
[18:10] <cjwatson> right, the last vestiges of those
[18:10] <apw> yep at worse 50% slower on a very slow machine otherwise avbout the
[18:10] <apw> about the speed of a cache cold
[18:11] <cjwatson> apw was testing a slightly older version, but the changes since then were bug fixes
[18:17] <pitti> cjwatson: thanks (sorry, a bit slow to respond here now due to tbird)
[18:17] <pitti> cjwatson: we obviously want to test it rather earlier than later
[18:17]  * pitti bumps its build score
[18:17] <pitti> with > 1600 i386 jobs we need some manual love here
[18:30] <apw> i've uploaded a kernel package to cover the issues we are seeing with the KMS on a number of platforms.  slangasek is aware of the situation and i presume will handle it
[18:49] <cjwatson> pitti: slow> shrug, I'm in the pub having dinner ;-)
[18:49] <pitti> cjwatson: hm, laptop and beer don't mix well
[18:49] <pitti> cjwatson: enjoy :)
[18:57] <cjwatson> phone :)
[19:06] <stgraber> slangasek: yep, it fixed edubuntu. Thanks !
=== starshiptrooper is now known as apachelogger
[20:44] <highvoltage> jdstrand: sorry, I made a mistake with the qimo upload of yesterday, could you perhaps let my new upload through? it's just an important type (s/DGM/GDM) that it fixes in a configuration file
[21:00] <ScottK> highvoltage: Done
[21:02] <mhall119> thanks ScottK
[21:32] <highvoltage> ScottK: thanks!!!
[21:46] <ScottK> pitti: I'd appreciate it if you could look at the apport hook in eclipse in queue (no rush).   I just fixed queuediff so that you can use it to look.
[22:10] <highvoltage> slangasek: I'd appreciate it if you could approve the edubuntu-artwork package I uploaded so that it can get into tomorrow's daily build, functionality wise all our known bugs is fixed now so there shouldn't be any more until we get the final artwork from canonical's design team
[22:11] <ScottK> highvoltage: I can take care of it.
[22:13] <ScottK> highvoltage: Is it gray matter or grey matter?
[22:13] <ScottK> It's one way in debian/changelog and the other in the package content.
[22:16] <ScottK> highvoltage: OK, me research reveals the package content is in en_US, so I guess that's correct.
[22:18] <ScottK> highvoltage: Accepted.
[22:18] <highvoltage> ScottK: thanks!
[22:18] <highvoltage> ScottK: ok we'll take it as a typo in the changelog then :)
[22:19] <ScottK> Having lived in place where both US and UK English were spoken, I can never remember.
[22:19] <highvoltage> 'gray' is real English right?
[22:20] <highvoltage> and 'grey' is American?
[22:20] <ScottK> No.  Other way around.  Apparently.
[22:20] <highvoltage> heh, ok
[22:20] <ScottK> http://www.greyorgray.com/
[22:20] <ScottK> There's a web site for everything.
[22:20]  * ScottK is out for several hours.  Have fun.
[22:20] <ScottK> /away
[22:21] <jdstrand> highvoltage: this should only be a bugfix upload, no? as such, just file a bug, rev the version, upload referencing the bug and someone from ubuntu-release will review
[22:21] <jdstrand> highvoltage: or am I missing something?
[22:21] <ScottK> jdstrand: I got it already
[22:21] <highvoltage> jdstrand: ScottK sorted it out, thanks!
[22:21] <jdstrand> ScottK: ok cool
[22:21]  * jdstrand didn't read backscroll
[22:21] <highvoltage> it's amazing how reactive and quick the release team is
[22:21] <jdstrand> certainly better than I am ;)
[22:22] <ScottK> Usually when I have the term reactive associated with me, it's not a good thing ....
[22:22] <ScottK> See you later.
[22:22] <highvoltage> I'm not sure if it's always this good but of all the teams I interacted with in the Lucid cycle the release team seems to work the most effeciently
[22:22] <highvoltage> ciao ScottK
[22:27] <slangasek> ttx: 563902> is the user trying to mount by UUID, which won't be unique, instead of by LV name, which will be unique?
[22:27] <slangasek> ttx: bug #563916> well, that's a plymouth bug in the ubuntu-text theme; side effect of not using the ubuntu-logo splash theme, I doubt there's time to implement that for final
[22:27] <ubottu> Launchpad bug 563916 in mountall "[lucid] No prompt for [S]kip or [M]anual recovery on server boot" [High,Confirmed] https://launchpad.net/bugs/563916
[22:28] <slangasek> er - not ubuntu-text; rather, the 'details' (no 'splash')
[22:54] <slangasek> apw: so, we didn't get the dell overheat fix?
[22:59] <slangasek> apw: from scrollback, I didn't see anything regarding a positive test for 1002 515f, only for 515e - do you still think disabling KMS on this chip is the right thing to do?