[00:10] <infinity> GrueMaster: That's cause only one was rebuilt.
[00:10] <infinity> GrueMaster: So, the others are identical in 28 and 28.1
[00:11] <GrueMaster> Ok, well it screws up automated testing, but I can live with it.
[00:15] <GrueMaster> Any guestimated eta on the openjdk issue?  Or should I temporarily remove it from my netboot image automation?
[00:41] <doko> slangasek, infinity: I can upload openjdk without running the tests if required
[00:43] <slangasek> I don't think that's worthwhile; I think GrueMaster should just drop it from the automation for now
[00:45] <GrueMaster> slangasek: The problem with dropping it is I can't run any tests w/o it, so I have to manually install it from LP (there is an arm package there).
[00:45] <slangasek> can't run any tests without it?
[00:46] <GrueMaster> we don't have libvirt to work with like the QA team does.
[00:46] <slangasek> sorry, I thought you were saying it could be easily removed from the pipeline
[00:46] <GrueMaster> I can install without it, but not run tests.
[00:47] <slangasek> well, even if it gets uploaded, it'll take several hours to build on arm again
[00:47] <slangasek> doko: what's the eta for a proper fix?
[00:47] <GrueMaster> It's already built on arm.
[00:49] <GrueMaster> Just the arch-all bits are coming from x86 to the mirror.
[00:50] <slangasek> yes; I was assuming the packages had to be in sync to be installable
[00:50] <slangasek> but it looks like they don't
[00:51] <slangasek> the i386 build took 12 hours to fail last time; I wonder how long it takes to succeed
[00:51] <GrueMaster> They do.  openjdk-6-jre-headless : Depends: openjdk-6-jre-lib (>= 6b24-1.11.1-3ubuntu1) but it is not going to be installed
[00:52] <slangasek> no, it requires openjdk-6-jre-headless to be *newer* than the arm build
[00:52] <slangasek> not in sync
[00:52] <slangasek> so a build on i386 would be sufficient to make it installable
[00:53] <slangasek> GrueMaster: why does openjdk get installed in-line as part of the tests?  The tests themselves are written in java?
[00:53] <GrueMaster> Jenkins is written in java.  The tests are automated through jenkins.
[00:54] <slangasek> I don't see why that involves running java on the host system
[00:54] <GrueMaster> And as more tests come online, the longer they take to run.  Doing it manually is very time consuming as I have to babysit each test otherwise.
[00:55] <GrueMaster> Host system?  Each platform is independent.  I don't have the luxury of tapping into a kvm session to launch jobs.
[00:55] <GrueMaster> (which is how QA is currently running most of their tests).
[00:57] <GrueMaster> Java is pulled in during netboot imaging along with jenkins-slave to start running on reboot.  Tests are queued up waiting for the system to finish reimaging.
[00:58] <GrueMaster> If I had an entire team working on arm QA, I might have come up with a better solution.  Unfortunately, I only have a team of me.  And this is how it is currently set up.
[00:59] <slangasek> ah, so the slave has to run on the host system to receive the jobs. ok.
[01:00] <slangasek> well, I'm not sure getting openjdk-6 rebuilt on i386 is going to be any faster than hand-installing the packages from launchpad
[01:01] <slangasek> all the same
[01:01] <slangasek> doko: could you go ahead and upload openjdk-6 with the tests disabled?
[01:01] <GrueMaster> the easiest solution would be to backrev the pool to the previous version.
[01:01] <infinity> That's an odd definition of "easy".
[01:01] <infinity> (As in, it's really, really not easy at all)
[01:08] <GrueMaster> Neither is re-engineering automation around package skew, but it looks like I'm stuck with it.
[01:14] <doko> slangasek, spend most of the time on it today on that. it's something which comes and goes, until now only seen with cacao and zero, now for the first time with hotspot :/
[01:15] <slangasek> doko: ok
[01:25] <ScottK> infinity: It's a question of easy for who.
[01:26] <smoser> hi. i have 2 uploads in waiting-for-approval that i'd like someone to consider.
[01:26] <smoser> cloud-init, and cloud-utils.
[01:26] <smoser> cloud-utils is more straight forward, the issue and fix were diagnosed fairly thoroughly.
[01:26] <doko> slangasek, in the queue
[01:27] <smoser> cloud-init, i'd like to have these changes in for beta, but i will not be too upset if someone says "you're too late".
[01:27]  * GrueMaster reverts to un-automated "smoke" testing.
[01:28] <smoser> so, there is my plea. i have to run. if there is a question, i'm fine with either being held off, but personally think both are small in scope.
[01:30] <slangasek> smoser: which images are impacted by these changes?
[01:31] <slangasek> is it only the server EC2 images?
[01:31] <slangasek> smoser: AFAICS we don't even have any candidates for server EC2 posted yet, so provided that those are the only images affected, it should be straightforward to accept both of these
[01:33] <slangasek> ah, cloud-utils is on the main server images
[01:35] <slangasek> doko: the upload includes a change to GCC_SUFFIX and GCJ_SUFFIX, what's that about?
[01:37] <infinity> 18:35 < slangasek> doko: the upload includes a change to GCC_SUFFIX and GCJ_SUFFIX, what's that about?
[01:41] <slangasek> smoser: both cloud-utils and cloud-init accepted
[01:42] <slangasek> doko_: see above in case infinity's repost didn't highlight you - I'm unsure of these GC[CJ]_SUFFIX changes included in the openjdk upload
[01:42] <slangasek> marking !arm server for respin on the tracker
[01:43] <GrueMaster> erm, why?
[01:43] <slangasek> !arm
[01:43] <ubot2`> ARM is a specific (RISC) processor architecture used in a variety of applications such as handhelds and networkdevices. For more information see https://wiki.ubuntu.com/ARM . For ARM specific support, stop by the #ubuntu-arm channel.
[01:43] <slangasek> no thanks, bot
[01:44] <slangasek> SpamapS: perhaps you want to delay your RAID test in light of this respin
[01:45] <GrueMaster> Oh, not arm.  ok.
[02:04] <doko_> slangasek, infinity: rejected and re-uploaded
[02:04] <doko_> now off to bed
[02:42] <slangasek> openjdk-6 accepted
[05:19] <SpamapS> slangasek: thanks for teh heads up. I have been debugging a problem in the RAID tests actually :p
[05:23] <slangasek> looks like openjdk-6 is nearly done building on powerpc; I suppose we might as well wait for it to finish before respinning the server CDs
[05:27] <skaet> slangasek, makes sense.   Daveiy should be coming on line soon, and it take <15 minutes to build it,  so suggest letting him trigger it.
[05:27] <SpamapS> Would we be at all interested in adding a PowerMac G5 1.6Ghz to the powerbc buildd farm I wonder? I have one sitting here gathering dust under my desk. :-P
[05:28] <ScottK> infinity: ^^^
[05:29] <ScottK> You could do ISO testing ...
[05:33] <SpamapS> ScottK: I've considered it, but I've always felt that if no other users than me, with my unused G5, step up to do that testing.. then why go through the trouble?
[05:33] <ScottK> There are still a few powerpc users.
[05:34] <ScottK> We just recently lost our last known Kubuntu user to hardware failure, but there are server and Xubuntu users)
[05:34] <micahg> xubuntu stopped building powerpc images due to lack of testers, if we have testers, we can start again
[05:34] <micahg> I think lubuntu was going to try to do powerpc images
[05:38] <slangasek> openjdk-6/powerpc accepted
[05:38] <slangasek> GrueMaster: that does mean openjdk-6 should be fixed again for your purposes
[05:39] <GrueMaster> slangasek: Cool thanks.  I'll probably have to wait anotehr 25 minutes for my mirror to refresh though, but great.
[05:39] <GrueMaster> (netboot installing from ports.ubuntu.com is extremely slow).
[05:42] <GrueMaster> And I seem to be fighting an issue with oem-config-gtk on beaglexm.  It seems to be hanging at the keyboard layout screen.  Passed on mx5, checking panda now.
[05:58] <GrueMaster> This doesn't bode well.  I'm seeing issues with oem-config-gtk hanging at the keyboard layout screen on both omap & omap4 images.
[06:09] <pitti> skaet: external path to log files> which log files? we do have public URLs for live fs and CD build logs indeed
[06:11] <pitti> debfx: yes, I'll do that; but wanted to do in steps
[06:11] <pitti> debfx: let me start the big universe package check, will take a few hours anyway
[06:17] <GrueMaster> sigh.  I think the latest ubiquity patches have hosed arm desktop images.
[06:18] <GrueMaster> And this would explain why mx5 works:
[06:18] <GrueMaster> 20120228.3/precise-preinstalled-desktop-armhf+omap4.manifest:oem-config-gtk     2.9.22
[06:18] <GrueMaster> 20120228.3/precise-preinstalled-desktop-armhf+mx5.manifest:oem-config-gtk       2.9.21
[06:25] <GrueMaster> grrr.  mirror is failing checksums.  refreshing with cdimage.
[06:25]  * GrueMaster needs sleep soonish.  Getting loopy.
[06:46] <GrueMaster> Can someone verify the MD5SUMS for http://cdimage.ubuntu.com/daily-preinstalled/20120228.3/ images?  After refreshing my mirror, I am still failing 4 out of 7 files.  Also, manifests indicate that ac100 and mx5 images were not respun with omap & omap4.
[06:51] <GrueMaster> And Ubuntu Desktop armhf+mx5 is missing from the tracker.  I have a bug filed for an issue specific to it.  Bug 943058.
[06:51] <ubot2`> Launchpad bug 943058 in linux-linaro-lt-mx5 "Kernel doesn't support usb on newer rev quickstart boards." [High,New] https://launchpad.net/bugs/943058
[06:52] <infinity> SpamapS: We have a fair few powerpc users.  The assertion that testers=users is provably false.
[06:52] <infinity> SpamapS: (Of the potentially millions of x86 users we have, how many "step up" to do image testing? :P)
[06:54] <GrueMaster> Someone should add it to the automation testing.  :P
[06:55] <infinity> GrueMaster: Erm, hrm.  None of those images match the md5.  Something may have gone wrong there...
[06:55]  * infinity is tempted to just respin them overnight...
[06:56] <GrueMaster> That kind of makes me feel better.  I thought I was losing it.
[06:56] <infinity> GrueMaster: Our conclusions aren't mutually exclusive. ;)
[06:57] <GrueMaster> Hold that thought for a minute.  I appear to be having issues with oem-config 2.9.22 (which appears to be only on the omap & omap4 images).
[06:58] <infinity> What sort of issues?
[06:58] <GrueMaster> yep.  2.9.22 is not working for me.  I just started 20120228.2 omap4 image and it went right through the keyboard layout with no problems.  It hangs there on 20120228.3 images.
[06:59] <infinity> Keyboard layout, eh?  Drat.  That was definitely code that was mangled in that upload.
[07:00] <GrueMaster> Yes, I know (I read the bzr log).
[07:02] <infinity> stgraber: Your keyboard dialog locking/timeout tricks may be breaking oem-config (or breaking ARM, but arch-specific seems unlikely?)
[07:03] <GrueMaster> I'm not sure x86 really tests oem-config.  QA's current test (that I know of) checks to see that it gets installed, not much else.
[07:03] <GrueMaster> I could try it in a VM here, but it will have to wait til morning.
[07:04]  * GrueMaster is feeling a bit punchy and sleep is higher on the priority list.
[07:04] <infinity> Sleep is probably a saner idea.
[07:06] <GrueMaster> My thought exactly.  Wouldn't want to flood lp with "keyboard repeats when tester's face implants on it after passing out" bugs.
[07:06] <infinity> Seems like a valid bug.
[07:06] <infinity> I still think we need to ship cat detection software by default.
[07:08] <GrueMaster> If only they had keyboards that provided electric shock "education" for those instances.
[07:09]  * GrueMaster EOD.  Back in 8h.
[07:28] <pitti> I'll use the empty builders for some more no-change rebuilds for bug 875466
[07:28] <ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
[07:28] <pitti> (unseeded universe packages)
[07:30] <pitti> debfx: ^ FYI
[07:49] <pitti> I'm done with the first batch; I let the buildds catch up now
[08:17] <jibel> skaet, dl links fixed for arm server
[08:56] <jibel> GrueMaster, what's issue with keyboard and oem-config on arm ? do you have a bug number ?
[08:57] <jibel> GrueMaster, I filed bug 942560 yesterday, is it the same ?
[08:57] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[08:58] <jibel> GrueMaster, and I test everything single desktop install manually if that can make you sleep better.
[09:42] <Riddell> Daviey: server images still to be rebuilt?
[09:42] <Riddell> or am I reading the pad wrongly?
[10:17] <pitti> the builders (except ppc) are empty again; would you mind if I uploaded the next batch of rebuilds for the md5sum fixes?
[10:24] <pitti> Riddell: ^
[10:35] <Riddell> pitti: go for it
[10:35] <pitti> ack, brace for impact, queuebot
[10:36] <pitti> batch of 24, some 50 to go after this
[10:42] <Daviey> Riddell: no, they were all built.. done
[10:43] <Daviey> Riddell: oh, wait.. smoser cloud fixtures?
[10:43] <Daviey> Riddell: We don't need to rebuild for them.
[10:44] <jibel_> Daviey, server are marked for rebuilt on the tracker and last build is 20120228.1
[10:44] <Daviey> jibel_: who marked that?
[10:45] <Daviey> jibel_: ah, seems slangasek did.
[10:46] <Daviey> I spoke to smoser last night, and it seemed we only really cared about these fixes landing in the cloud images.
[10:46] <Riddell> Daviey: shall I mark that you don't want a rebuild and current images are good?
[10:47] <Daviey> Riddell: Well, it's not too expensive to respin tbh.. I plan to human smoke test shortly anyway, and the other test cases are automagic.
[10:47] <Riddell> Daviey: ok so you do want a rebuild?
[10:47] <Daviey> Riddell: on it now... for non-arm
[10:47] <Riddell> Daviey: "on it" meaning you are doing the rebuild?
[10:47] <Daviey> Riddell: yes
[10:47] <Riddell> groovy
[10:48] <jibel_> Daviey, ok, you were faster than me reading scroll back
[10:48]  * micahg wonders why vlc was accepted since it's on the mythbuntu images
[10:51] <pitti> eek, sorry about that, that was my fault ^
[10:51] <Daviey> micahg: Mythbuntu needed that fix for the kfreebsd and powerpc port. :)
[10:51] <pitti> so, if we need to respin and vlc is broken, I can upload a reversion (but hopefully we won't)
[10:52] <micahg> Daviey: vlc was already fixed on powerpc
[10:52] <Daviey> pitti: it 'looks safe', i wouldn't panic!
[10:52] <pitti> Daviey: yes, I'm not :)
[10:52] <micahg> it does reenable a feature that was disabled with the 2.0 upload (v4l2
[12:21] <jdstrand> that ^ does not need to go into beta1
[12:55] <scott-work> skaet: techincal overview for ubuntu studio done
[12:56] <scott-work> skaet: sorry i haven't been as invovled lately, work has gotten incredibly busy lately
[13:14] <utlemming> stgraber: can I have you add http://cloud-images.ubuntu.com/precise/20120229.1/ to the ISO Tracker?
[13:15] <smoser> Daviey, Riddell i dont tihnk that cloud-utils or cloud-init is in the server iso, is it?
[13:15] <smoser> (ie, there would not be need for respin of those due to those changes)
[13:16] <infinity> smoser: Doesn't look like, no.
[13:16] <Daviey> smoser: waaat
[13:17]  * Daviey screams.. 
[13:18] <Daviey> smoser: it's in the pool
[13:18] <Daviey> well, -utils is
[13:19] <infinity> It is?
[13:19] <infinity> cloud-image ends up in ship?
[13:19] <Daviey> no, cloud-utils pkg.
[13:19]  * infinity sees nothing in the tasks that indicates that.
[13:19] <infinity> Unless it's a dependency of something.
[13:19] <Daviey> infinity: http://cdimage.ubuntu.com/ubuntu-server/daily/20120229.1/precise-server-i386.list
[13:20] <infinity> Ah-ha.
[13:20] <infinity> euca2ools pulls it in.
[13:20] <infinity> Which is, in turn, in server-ship.
[13:21] <infinity> Anyhow, respinning for things in the pool but not installed by default isn't necessarily worth the effort for non-final images anyway.
[13:21] <smoser> and the change that is included would not affect install
[13:22] <Daviey> right.. which was why i said we didn't need a rebuild for them..
[13:22] <Riddell> Daviey: but it is respun?
[13:22] <Daviey> but conversation between smoser and slangasek seemed to supersede that
[13:22] <Daviey> Riddell: it was.
[13:23] <smoser> i'm confused. cloud-images need it included.
[13:23] <smoser> and it is in the 20120229.1
[13:23] <infinity> Daviey: Is there a reason, BYW, why nova-compute-xen doesn't get to be in main with the rest of openstack thingees?
[13:24] <Riddell> Daviey: best get your guys testing :)
[13:24] <infinity> Daviey: Or do we just flat our refuse to support xen, despite using it internally? :P
[13:25] <infinity> s/our/out/
[13:25] <Daviey> infinity: I believe that was legacy from when xen was still universe.
[13:26] <Daviey> Riddell: Thankfully, my guys are mostly virtual machines.
[13:40] <greyback> Hi guys, question about freeze exceptions. One feature we've nearly ready now would be easiest merged (and reviewed) in several MRs.
[13:40] <greyback> For a FFe request, is it ok to list these MRs, and build package of code with all the MRs merged in?
[13:41] <Riddell> greyback: yes that's fine
[13:41] <Riddell> greyback: file a bug, list all the useful information, subscrube ubuntu-release and ping here
[14:05] <stgraber> utlemming: looking in a sec if nobody beats me to it
[14:05] <utlemming> straber: :)
[14:07] <stgraber> infinity: is it reliably broken for you? I can reproduce the UI locking up on x86 too but it depends on how quickly you click on stuff and if you select keyboard variants
[14:08] <stgraber> infinity: I started looking into the right way of fixing the bug yesterday, will continue today. If it's always broken for you, I guess I'll just revert my commit and re-introduce the bug where using your keyboard to select layout freezes the dialog
[14:10] <stgraber> utlemming: does that look good?
[14:15] <infinity> stgraber: I haven't tested it, I was relaying GrueMaster's claims.  But I think he was seeing it lock up with reproducibility.
[14:15] <infinity> stgraber: I believe he opted for sleep instead of filing a bug, but he'll be online in an hour or three for you to ask him about it, I'm sure. :)
[14:17] <stgraber> ok
[14:18]  * stgraber really doesn't like the ubi-console-setup debconf/console-setup black amgic...
[14:18] <stgraber> it's clearly racy but there isn't a good way of preventing the race, at least not that I could easily figure out in ubiquity. Last night I started digging into the debconf/console-setup part to try and fix the problem there instead of the UI
[14:24] <utlemming> stgraber: yes, sir, thank you kindly3
[14:26] <jibel> stgraber, there's a problem with ltsp. the client starts compiz even if it detects that 3d is not supported and the desktop is unusable.
[14:27] <stgraber> jibel: sounds like a problem with unity/nux/compiz more than with ltsp...
[14:27] <stgraber> jibel: I'm guessing they thought that as the check is now done by lightdm there's no reason to run it in unity too, and they'd be wrong as not everybody uses lightdm
[14:28] <stgraber> didrocks: ^
[14:28] <didrocks> stgraber: as told to jibel, I don't really have the time to look closely at that, but I need more info from the LTSP side as how it works
[14:28] <stgraber> jibel: we could hardcode to use ubuntu-2d in LTSP but that'd be wrong as there are thin clients perfectly capable of running unity-3d
[14:29] <stgraber> didrocks: LTSP basically opens a session on the server, sets DIPLAY= to point back to the client, then calls /etc/X11/Xsession <session> directly
[14:29] <Riddell> is there actually any advantage in using unity-3d over unity-2d?
[14:30] <didrocks> stgraber: so, you don't use lightdm, right?
[14:30] <stgraber> didrocks: so my guess is that doing so bypasses the nux-whatever check
[14:30] <stgraber> didrocks: correct
[14:30] <didrocks> stgraber: so, you get the second check
[14:30] <didrocks> stgraber: which is done by gnome-session
[14:30] <didrocks> stgraber: I would need you to run gnome-session --debug on a LTSP config
[14:30] <didrocks> while starting the session
[14:31] <stgraber> didrocks: ok, hold on a sec, doing that now
[14:31] <jibel> stgraber, didrocks , I'm filing a bug. I think it can be release noted for B1 as selecting 2d loads the 2d session.
[14:32] <stgraber> jibel: yeah, release note is fine, I just want to make sure we know exactly what the bug is and can have it fixed first thing after beta-1
[14:34] <dobey> does https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/934270/comments/15 make sense to release team?
[14:34] <ubot2`> Launchpad bug 934270 in ubuntuone-control-panel "We need to drop the current GTK+ UI in favor of the Qt UI" [Undecided,New]
[14:44] <stgraber> didrocks: it's an LTSP bug
[14:45] <stgraber> our dmrc parsing is wrong
[14:45] <didrocks> stgraber: ah see!
[14:45] <didrocks> :)
[14:45] <stgraber> it's using TryExec for some reason instead of Exec, so it's calling "/etc/X11/Xsession unity" directly
[14:45] <didrocks> stgraber: ah, that explains then
[14:48] <stgraber> didrocks: apparently we fixed that bug a few days ago in LTSP upstream ;)
[14:48] <stgraber> didrocks: just need to sync the new bugfix version from Debian
[14:48] <didrocks> stgraber: excellent! :)
[14:49] <stgraber> jibel: bug 820417 is the upstream bug
[14:49] <ubot2`> Launchpad bug 820417 in ltsp "LDM doesn't set ~/.dmrc correctly" [Low,Fix released] https://launchpad.net/bugs/820417
[14:51] <stgraber> I'll send a sync request for ldm now but unless we need to rebuild Edubuntu and the alternates anyway, I don't think it's worth fixing for beta1 (release note should be fine)
[14:55] <stgraber> sent the sync request. The only feature change I see in the upstream code is the change of background image, though that doesn't affect Ubuntu as we ship our own theme anyway
[14:55] <jibel> stgraber, thanks
[15:34] <pitti> Riddell: do you need the buildds for anything? if not, I'd like to upload the next 25 packages for md5sums (then 23 left to go)
[15:42]  * pitti assumes not; these are all small builds anyway, and will readily yield for any main package
[15:46] <GrueMaster> stgraber: Morning.  The oem-config issue was very consistent with v2.9.22, but not with v2.9.21.
[15:47] <Riddell> ruby?  I hear that's big in Japan.
[15:48] <ogra_> "big in japan" ... thats alphaville, no ?
[15:48] <pitti> Ruby galore done
[15:49] <Riddell> morning skaet
[15:50] <skaet> Good afternoon Riddell - all looks nice and quiet on the pad
[15:50] <skaet> any worries that haven't made it there yet?
[15:50] <Riddell> yes I think it is, Daviey did a rebuild of -server today but he has his team of virtual machines testing it now
[15:50]  * skaet working through backscrolls still...
[15:51] <stgraber> GrueMaster: ok, I'm currently in a meeting but I have a VM setup to debug that one and try to find the right fix for it...
[15:51] <Riddell> kubuntu is good from my tests
[15:51] <skaet> :)
[15:51] <stgraber> GrueMaster: are you selecting your keyboard layout using the mouse or keyboard? also are you using a specific variant of the layout?
[15:51] <skaet> Riddell,  release notes updated for Kubuntu?
[15:51] <infinity> stgraber: I think he was saying that it locks up when entering the keyboard config dialog (as in, he never even gets a chance to select)
[15:52] <GrueMaster> Actually, I have been letting it go with default, just hitting enter to continue.
[15:52] <ogra_> at least he gets that dialog
[15:52]  * ogra_ has issues on ac100 with that 
[15:52] <pitti> back in 20 mins
[15:52] <GrueMaster> But with 2.9.22, it just sits with the mouse indicating it is busy.  It will not budge from there.
[15:53] <Riddell> mvo: does do-release-upgrade need a sudo or not?
[15:53] <ogra_> it surely did in the past
[15:53] <mvo> Riddell: it will ask you for sudo when it needs it
[15:53] <Riddell> mvo: what does it use to ask?
[15:53] <mvo> Riddell: do-release-upgrade will use plain sudo
[15:54] <mvo> Riddell: the other frontends should use there native tool, gksu/kdesu
[15:54] <Riddell> right, so for beta I do want to advise using kdesudo since that's just a command line
[15:55] <mvo> Riddell: I don't know much about the kde part of this, but for ubuntu we run it without and it will ask when it needs it
[15:56] <Riddell> yeah but nicer not to make people have to do more command line stuff if possible, I'm not that elitest on my users :)
[16:00] <stgraber> GrueMaster: hmm, well, the known issue with my change is that the dialog can be "insensitive" while waiting for debconf/console-setup and sometimes never unlock at all but I don't see anything in my change that'd prevent the dialog from showing up at all
[16:00] <stgraber> GrueMaster: can you check /var/log/syslog and /var/log/installer/debug for traceback?
[16:01] <GrueMaster> I have never been able to get decent debug info from oem-config (and the only thing in /var/log/installer/ is version).
[16:02] <GrueMaster> And the dialog shows up, just never goes away.
[16:02] <ogra_> isnt there another file where ubiquity-dm logs to ?
[16:03] <stgraber> GrueMaster: hmm, ok...
[16:04] <GrueMaster> It has been one of my greatest frustrations for several cycles.
[16:05] <stgraber> skaet: do you think we should revert that workaround then? it's going to re-introduce bug 645449 but should fix GrueMaster's bug and bug 942560
[16:05] <ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Fix released] https://launchpad.net/bugs/645449
[16:05] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[16:05] <stgraber> I'm working on a different and hopefully "proper" fix but I have no clue when I'll have something ready for upload
[16:06]  * skaet reading
[16:07] <GrueMaster> stgraber: Was bug 645499 even reproducible in recent releases?  Seems a bit old, especially for a fix mid-release week.
[16:07] <ubot2`> Launchpad bug 645499 in nautilus "nautilus crashes when unmounting microSD card (dup-of: 630884)" [Medium,Invalid] https://launchpad.net/bugs/645499
[16:07] <ubot2`> Launchpad bug 630884 in nautilus "nautilus crashed with SIGSEGV in g_closure_invoke()" [Critical,Fix released] https://launchpad.net/bugs/630884
[16:07] <stgraber> I could probably keep the delays and drop the "locking the UI" part of the workaround, this should somewhat limit the number of occurences of bug 645449 and hopefully fix the regression
[16:08] <ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Fix released] https://launchpad.net/bugs/645449
[16:08] <stgraber> GrueMaster: yes, it's very easy to reproduce
[16:08] <GrueMaster> oops. wrong bug.
[16:08] <stgraber> GrueMaster: just keep the down arrow key pressed and see the dialog freeze
[16:08] <GrueMaster> ok.
[16:08] <skaet> stgraber,  is this only showing up on arm?
[16:09] <stgraber> skaet: I didn't see GrueMaster's specific issue on anything else but I haven't tested oem-config myself, I can reproduce bug 942560 and its duplicates on x86 though
[16:09] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[16:10] <GrueMaster> stgraber: On a side note, I was able to get through IF I unplugged the network cable before booting.  Just tried that.  Seems odd.
[16:11] <stgraber> GrueMaster: indeed seems really odd and should be unrelated ;) are you sure you're not getting stuck on the timezone dialog (that's just before the keyboard dialog)?
[16:11] <stgraber> GrueMaster: the timezone dialog uses the network so that could explain it
[16:12] <GrueMaster> No, it takes a little longer, then defaults to NYC.  I click on Los Angeles and can move on.
[16:13] <skaet> stgraber,  am worrying a bit about whether jibel has bandwidth for retesting images if we respin at this point.   Is there a workaround for 942560?
[16:14] <stgraber> skaet: the workaround is to use the mouse to first click the keyboard layout and then the keyboard variant, waiting for the UI to refresh between each action
[16:15] <stgraber> trying to do things too quickly or clicking to many different entries in a row can cause the bug
[16:15] <stgraber> *too many
[16:15] <skaet> stgraber,  got cha.  :)  thanks.   if we have a workaround for it am leaning towards leaving things as is.
[16:16] <GrueMaster> I think reverting might be the safer option at this point.  The bug that it fixed has been around for quite a while.
[16:18] <skaet> GrueMaster,  if you feel that way - its good to know.  *sigh*
[16:19] <stgraber> skaet: I'm doing an x86 OEM test install now
[16:19]  * skaet waiting to see if she can get a response from jibel about the testing load,  since this is more than arm
[16:20] <GrueMaster> The other option for me is releasing 20120228.2 images (prior to the fix).  They will be slightly out of sync, but that can be addressed between now and Beta 2.
[16:21] <GrueMaster> And would require less retesting overall.
[16:21] <GrueMaster> Besides, not all of the arm desktop images were respun for this fix.
[16:22] <skaet> GrueMaster - if that works for you,  am fine with that option.
[16:23] <skaet> do you want me to go into the tracker and change them to point to those images now?
[16:23]  * skaet would prefer not to revert if we can avoid it at this point.
[16:23] <GrueMaster> Sure.  I have already partially tested those images to figure out this issue.
[16:24] <skaet> GrueMaster - going and changing now.
[16:25] <GrueMaster> Please delete 20120228.3 from cdimage too if possible.  That directory isn't right anyways (4 out of 7 md5sums failed).
[16:27] <GrueMaster> Oh, and Ubuntu Desktop armhf+mx5 needs to be added to the tracker.
[16:28] <stgraber> skaet: OEM works here, though you have to select your keyboard variant on the first go as the dialog gets locked when you do...
[16:28] <stgraber> now back to figuring out a real fix for that stuff...
[16:29] <skaet> stgraber,  k,  release note time then.   thanks!
[16:30] <stgraber> skaet: writting something now, will also add the LTSP issue jibel found earlier
[16:30] <stgraber> highvoltage: can I let you do the Edubuntu section?
[16:30] <skaet> Thanks stgraber.  :)
[16:32] <stgraber> skaet: just thought of a workaround for the case where the dialog is locked, I added that too
[16:32] <infinity> The livecd-rootfs that queuebot's about to warn about has a fix for ac100 images (and nothing else) that would be kinda nice, but obviously not critical, since it's a community image.
[16:34] <skaet> infinity,  prefer not at this point.   in a couple of hours if no other respin triggers occur,  we can probably let it in and do a rebuild of it for tonight.
[16:34] <ogra_> yeah, its not urgent
[16:34]  * skaet wants to hear from jibel about the images and if there's any other criticals on the horizon.
[16:34] <ogra_> and has an easy workaround
[16:35] <skaet> thanks ogra_ ,  yeah then lets hold off on it until after beta 1.   Please document the workaround in the release notes.
[16:35] <ogra_> will do
[16:35] <ogra_> (not actually a workaround, there are kde bits ending up in the install ... you can just apt-get remove them
[16:36] <ogra_> )
[16:36] <infinity> skaet: Well, livecd-rootfs doesn't ship on any images, so there's no real harm in letting it in, pending a later respin.
[16:36] <infinity> (But if there are no respins, no big deal either way)
[16:39] <skaet> infinity,  thanks.
[16:40]  * pitti uploads the remaining 17 rebuilds for broken md5sums, buildds are still bored
[16:42] <jibel> skaet, it's too short to retest desktop images properly. But i'm trying to reproduce on x86 what GrueMaster's seeing so it can be documented
[16:42] <jibel> skaet, major issues remaining with the live session and the installer are
[16:42] <jibel> bug 940908
[16:42] <ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
[16:42] <jibel> bug 939450
[16:42] <ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
[16:42] <jibel> and bug 942560
[16:42] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[16:46] <skaet> thanks jibel
[16:54] <GrueMaster> skaet: I have tested the armhf+mx5 desktop image, but have no place to put results.  Can it get added to the tracker?
[16:54] <ogra_> yes, please
[16:59] <infinity> (pretty please)
[17:00] <infinity> skaet: I've taken sign-off duties for mx5/ac100, you can yell at me if they don't get test results. :P
[17:01] <pitti> skaet: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview -> the "section missing" is from your new parser? what is it looking out for?
[17:01] <skaet> GrueMaster,  have cleaned up other images to .2 (please verify)
[17:01] <skaet> pitti,  meant that the section wasn't in the weekly report
[17:01] <GrueMaster> Yes, they are on .2 now, thanks.
[17:01] <pitti> skaet: I guess I mis-named it then
[17:01] <skaet> Release Notes section.  :)
[17:02] <GrueMaster> Still need the mx5 image added.
[17:02] <skaet> pitti, https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda/TeamTemplate
[17:03] <skaet> GrueMaster,  yup.  Will add it after I get off my call.   its on the list. sorry to be slow.
[17:03]  * skaet is fine if someone else on the release team adds it before I get to it.  ;)  hint, hint ^ infinity ;)
[17:04] <infinity> Don't make me learn how to use the tracker!
[17:11] <infinity> GrueMaster / skaet: That should do it.
[17:12] <GrueMaster> I can live with it, but the download link is mia.
[17:12] <infinity> It's MIA for omap4 too, which is what I copied. :P
[17:12] <infinity> I can fix, though.
[17:12] <GrueMaster> As I said, I can live with it (I know where the images are).
[17:16] <infinity> GrueMaster: Download link fixed too.
[17:16] <GrueMaster> k, thanks.
[17:20] <pitti> skaet: I added the desktop bits to https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview, but some bits (like the HUD description) will still be improved
[17:21] <SpamapS> no more respins?
[17:37] <Daviey> SpamapS: nein.
[17:37] <Daviey> (correct)
[17:43] <SpamapS> Cool.. just wrapping up RAID1 test again
[17:51] <skaet> pitti,  thanks
[17:51] <skaet> thanks infinity.  :)
[18:17] <skaet> GrueMaster, 20120228.3 removed
[18:20] <GrueMaster> skaet: Thanks.
[18:40] <Riddell> skaet: I'm about done for the day, what's the plan for tomorrow?
[18:42] <skaet> Riddell,  will see what emerges from rest of testing today.
[18:42] <Riddell> skaet: ok but if it's all good when are we hoping to release and who cranks which handles?
[18:43] <skaet> Riddell, will leave you summary of the bits from the checklist - marking the ones good to start.
[18:44] <skaet> while I'm sleeping.  :)
[18:46] <Riddell> skaet: and if all goes well aim for release my late afternoon your morning?
[18:48] <skaet> Riddell,  yup.
[19:34] <GrueMaster> Riddell: Did you ever get your panda running?  Also, have you asked anyone to step up and test kubuntu armhf?
[20:04] <scott-work> i should be testing the remaining ubuntu studio test cases this afternoon (i.e. 64 bit) for beta1
[20:06] <skaet> scott-work, yes please.
[20:07] <skaet> scott-work - no respins planned at this point ( but waiting for all the test results to come in though)
[20:33] <GrueMaster> Well, having seen no response to my question on Kubuntu armhf testing, I guess I can fire them off.  Fortunately, they only take a few minutes to smoke test.
[20:34] <iulian> GHC has just landed in the unapproved queue. Does anyone fancy hitting the 'accept' button?
[20:34]  * iulian giggles.
[20:36] <skaet> looks like we're going to need a respin for lubuntu this evening to get the artwork usable for them.
[20:36] <skaet> https://launchpad.net/bugs/938472
[20:36] <ubot2`> Launchpad bug 938472 in lubuntu-artwork "dialogs are barely readable-- grey on black????" [Undecided,Confirmed]
[20:38] <skaet> NCommander, Riddell, slangasek, ScottK, iulian ^ please let fix through the queue as soon as you see it if I'm not around.
[20:38] <slangasek> ack
[20:43] <GrueMaster> sigh.  Kubuntu Daily-preinstalled 20120228.1 MD5SUMS is wrong.
[20:47] <GrueMaster> As are the daily-preinstalled/201228.2/MD5SUMS for Ubuntu Desktop.
[20:53] <GrueMaster> As far as I can tell, NONE of the arm images match the md5sums from the same directory.
[20:53] <GrueMaster> Kubuntu, Ubuntu Desktop, and Ubuntu server are all wrong.
[20:55] <slangasek> infinity: ^^ can you have a look at what's going on with md5sums?
[21:12]  * skaet curious why suddenly this might have changed.... werid. 
[21:15] <slangasek> I'm not sure it's ever been working, GrueMaster brought it up last milestone as well
[21:15] <slangasek> a fix was applied but perhaps it was incomplete
[21:16] <GrueMaster> I should probably add this to my daily tests.  I don't check daily images normally.
[21:16] <skaet> thanks slangasek.
[21:17] <skaet> GrueMaster, yeah would have been good to know about this much earlier.  Was there a bug number?
[21:18] <GrueMaster> No.  I only file bugs when I know what to file bugs for.  In this case, I wouldn't know what to file against.
[21:18] <GrueMaster> Besides, I just picked it up.
[21:18] <slangasek> the ubuntu-cdimage project
[21:18] <GrueMaster> It's one of the last things I check before release.
[21:18] <GrueMaster> slangasek: ok.
[21:20] <skaet> thanks for checking it GrueMaster.   hopefully we'll sort it now.
[21:21]  * skaet has updated pad with latest status she's aware of
[21:21]  * skaet --> lunch (finally!)
[21:22] <skaet> :)
[21:36] <jibel> skaet, bug 940908 is more serious that it seems finally
[21:36] <ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
[21:37] <jibel> not only keyboard but all boot parameters like oem-config are ignored with persistence enabled
[21:38] <GrueMaster> Please do not respin arm images due to md5sums being broken.  That will pull in oem-config 2.9.22, which is broken.
[22:32] <gilir> skaet, lubuntu-artwork uploded, sorry for the late request
[22:43] <micahg> stgraber: queuebot was flooded out about 7 hours ago
[22:44]  * micahg wonders if it should stay away so no one accepts the new ghc :)
[22:46] <ajmitch> micahg: is ghc a bit of a 'rebuild-the-world' situation? :)
[22:46] <micahg> yes, which I personally think is insane while the archive is frozen
[22:46] <iulian> ajmitch: No, not really. :)
[22:46] <ajmitch> iulian: I thought it was going to be quite a few rebuilds & possibly a few syncs as well
[22:47] <Laney> the rebuilds won't be happening when the archive is frozen
[22:47] <iulian> ajmitch: I wouldn't say "a few". :)
[22:47] <slangasek> not the world, just the universe
[22:47] <Laney> we did think of this.
[22:47] <iulian> slangasek: Heh.
[22:47] <ajmitch> Laney: oh I expected you'd think about it :)
[22:47] <micahg> iulian: you make a whole bunch of things uninstallable with the first upload and the manual processing makes the whole thing tedious
[22:48] <micahg> the archive should be unfrozen in ~24 hours at which point it's a lot easier to do this
[22:48] <stgraber> micahg: apparently irclib doesn't respect the flood restrictions ;) I guess I'll have to implement it myself then (or use a more complete irc library)
[22:48] <slangasek> lubuntu-artwork accepted
[22:49] <micahg> stgraber: well, pitti flooded teh archive with ~25 uploads at once
[22:49] <micahg> it was a very unusual case for a freeze I would think (but I haven't been keeping score)
[22:50] <iulian> micahg: We won't do anything when the archive is frozen, like Laney said above. It'd be a mess!
[22:50] <GrueMaster> There have been other updates that slipped in during image builds.  For example, libxml2.  I have different versions for omap & omap4 images.
[22:51] <micahg> iulian: than why were you asking for ghc to be accepted?
[22:51] <micahg> s/than/then/
[22:51] <iulian> micahg: Having said that, it doesn't really matter whether ghc is accepted now or after.
[22:52] <slangasek> GrueMaster: libxml2 was an opportunistic security upload, discussed on here yesterday
[22:52] <micahg> iulian: sure it does, anything that depends on the virtual provides will be uninstallable
[22:52] <iulian> Yes, we'd end up with loads of uninstallable packages but that's going to be fixed soon anyway.
[22:52] <micahg> unless they got the domination scripts to factor that in as well
[22:52] <micahg> iulian: but why do that when you can minimize the impact
[22:53] <GrueMaster> Ah, well kubuntu omap4 got it, but not omap.  Not that I care, it was the only update for omap and largely doesn't affect many users for beta 1 (seeing as how I'm the only one testing them).  :)
[22:53] <Laney> it takes hours to build on arm
[22:53] <Laney> so should be accepted ~12 hours before the freeze ends
[22:54] <micahg> Laney: with the pandas?
[22:54] <GrueMaster> Which is why I panic at the mention of respins.  :P
[22:54] <Laney> 12 hours is down from 2 days
[22:54] <GrueMaster> Image builds on arm are serial.  None are posted to cdimage until all for that build are done.
[22:55] <Riddell> GrueMaster: no I'm waiting on jason to tell me I can expense the necessary equipment to get the panda running
[22:55] <GrueMaster> arm builds will see greater improvement once we start seeing real arm server hardware.
[22:56] <GrueMaster> Riddell: Images have been tested, results posted.
[22:57] <GrueMaster> And I emailed you on how I think we need to test going forward.
[23:00] <Riddell> GrueMaster: yes, it's up to jason for now
[23:07] <slangasek> GrueMaster: no, image builds on arm are parallel across two builders, and as of alpha-2 we're spitting out the images in sub-batches precisely so the testing isn't held up waiting for them all to finish
[23:07] <GrueMaster> Ah, well that is an improvement then.  Didn't know that had been fixed, thanks.
[23:09] <slangasek> that's why you were getting .1 on the tracker while still testing .0
[23:09] <slangasek> an artifact of how the publishing happens when we split the batch
[23:44]  * skaet catches up on backscroll...   
[23:45] <skaet> jibel, slangasek - is there a known fix likely to land for 940908?
[23:46] <skaet> gilir,  will start off the respins as soon as bits get published.
[23:46] <skaet> GrueMaster - no arm respins... (if we do any)  "noted"  :)
[23:47] <GrueMaster> Ok.  I just saw the note on the pad.
[23:48] <slangasek> skaet: 940908> do you want a respin for that one if you can get it?  it seems it'd be fairly intrusive?
[23:48] <slangasek> stgraber: ^^ 940908 is the one you're working on right now?
[23:49] <skaet> slangasek, yeah don't want to unless it can't be release noted.   I think it can, but figured better check with the experts.  ;)
[23:49] <skaet> s/can/can be release noted/
[23:49] <slangasek> looks release-notable to me
[23:51] <stgraber> bug 940908
[23:52] <skaet> slangasek - ok,  that's what we'll do.
[23:52] <ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
[23:52] <stgraber> slangasek: no, that's the next one on my list
[23:52] <skaet> I'll start off the lubuntu rebuilds as soon as the artwork publishes, and get that up there.
[23:52] <stgraber> slangasek: I'm on bug 942560
[23:52] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[23:52] <slangasek> stgraber: ack
[23:55] <skaet> infinity,  will you be able to patch the ARM images MD5SUMs in the directory?
[23:55] <jibel> skaet, I think it is release notable, the workaround for oem installation is to install from a media without persistence enabled
[23:56] <jibel> for keyboard with persistence, setting the right layout in /etc/default/keyboard should work
[23:56] <skaet> thanks jibel.
[23:57] <jibel> that's the most visible side of this bug probably
[23:58] <skaet> jibel,  given that lucid -> precise updates don't seem to be working in the smoke tests - I think we'd better be making that prominent in the release notes to avoid doing.   Am I being overly pessimistic?