[00:28]  * skaet back now... dog fed, images emerging. :)
[00:29] <infinity> I hope those two statements are disconnected.
[00:29] <infinity> Or it speaks volumes about beta quality...
[00:29] <skaet> infinity, there was a comma there for a reason.  :)
[00:30] <infinity> Not sure that helps. :P
[00:30] <skaet> lol,  will split them up to separte topics next time.  ;)
[00:31]  * GrueMaster grabs a scoop, starts validating.
[00:31] <skaet> infinity,  in #ubuntu-testing wxl was griping about powerpc alternate for ubuntu still being oversized - possible tester?
[00:31]  * infinity wanders off for a smoke before someone mentions the Poopy Pangolin.
[00:32] <infinity> skaet: A tester would be nice!
[00:33] <infinity> And yeah, it's pretty horribly oversized.
[00:33] <infinity> Probably due to being the only image that still ships with multiple kernels.
[00:33] <infinity> I might have to put a weekend worth of community love into PPC images.
[00:33] <skaet> why multiple kernels?
[00:33] <GrueMaster> I may have missed something earlier, was openjdk-6-jre rebuilt earlier?
[00:33] <infinity> 32/64.
[00:33] <skaet> sigh,  yeah.
[00:35] <infinity> Maybe I could just make the install media 64-bit only, and let 32-bit users use netinst and other methods.
[00:35] <infinity> I mean, honestly, half the ppc32 machines out there can't reliably (or at all) boot CD media anyway.
[00:35] <infinity> I know mine can't. :P
[00:36] <infinity> I think the only intersection of ppc32 and "can actually boot an installer without manual intervention" would be the G4 desktops and laptops.
[00:36] <infinity> Which is, what, a 2 year window in the middle of a long line?
[00:37] <infinity> Oh, and candy-coloured iMacs.  There were a ton of those sold, too.
[00:37] <infinity> Nevermind.  I'll find another way to make space.
[00:38] <GrueMaster> It would be interesting to know how many users of those are still around.  I think they were phased out in 2004 time frame.
[00:38] <infinity> GrueMaster: The candy iMacs and clamshell iBooks?
[00:39] <infinity> GrueMaster: Yeah, they're old, but Apple sold a stupid number of them.
[00:39] <skaet> infinity,  wxl has 32 bit hardware - so maybe bias there?
[00:39] <infinity> skaet: Oh, shiny.
[00:40] <infinity> skaet: Between he an I (I have a POWER5 workstation and an ancient G3 desktop), we probably cover a fair number of potential hardware, then.
[00:41] <skaet> infinity,  coolio,  ping him directly from ubuntu-testing when there's something in size.
[00:41] <GrueMaster> (and users).   :P
[00:41] <infinity> GrueMaster: There are definitely PPC users.
[00:42] <infinity> GrueMaster: But it's a question of scale, right.  We have millions of x86 users, and finding more than a couple of testers who are willing to actually report QA results (not counting ones that we pay for) is still hard.
[00:42] <infinity> GrueMaster: So, finding people willing to test a port for free among a smaller user base.  Fun.
[00:43] <GrueMaster> Oh, I am well aware of that issue.  I've been trying to recruit testers for omap/omap4 for a year now.
[00:44] <GrueMaster> I have a hard enough time getting someone to test a fix for a bug they reported when I don't have the same hw (which is why I ended up on a buying spree last year).
[00:45] <GrueMaster> Well, one of the reasons.  I still like the toys.
[00:49] <skaet> :)
[00:55] <infinity> Yeah, I'm often tempted to go eBaying for more PPC hardware.
[00:56] <infinity> But, honestly, I want other testers so I can, like, do other things and not have it rest on me.
[00:56] <infinity> You're okay, since you're paid to QA ARM stuff.
[00:56] <infinity> Sadly, PPC has to be in my "spare time".
[00:56] <infinity> (Also, I'm not lugging my POWER5 workstation to London for the release sprint)
[00:59] <stgraber> why not? ;)
[01:00] <infinity> stgraber: I could discuss how heavy it is, but probably not without making a few "your mom" jokes.
[01:04] <ScottK> infinity: Maybe barry fixed his.
[01:06] <infinity> ScottK: His mom?
[01:06] <ScottK> Heh.
[01:07] <ScottK> No, his powerpc box.
[01:09] <GrueMaster> infinity: You can always set it up for remote testing.
[01:14] <stgraber> skaet: I pushed a (rather ugly) fix/workaround for bug 645449 to ubiquity's trunk. It seems to do the trick here. Should I upload a new ubiquity now?
[01:14] <ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Confirmed] https://launchpad.net/bugs/645449
[01:16] <skaet> stgraber,  would like the current set of images to finish off building before it goes into the archive,  but go ahead and push it up to unapproved queue.   Will ask pitti, Riddell to look at it when they come on shift - other image builds should be finished by then.
[01:17] <stgraber> skaet: ok, I'm not planning any more ubiquity work tonight, so will upload what I have.
[01:17] <stgraber> skaet: the remaining big issue is the accessibility one but this will most likely involve a gtk upload rather than ubiquity
[01:18] <skaet> stgraber, gotcha.  thanks!
[01:24] <stgraber> ok, uploaded. Time for some food now ;)
[01:24] <skaet> stgraber,  thanks!  enjoy dinner.
[01:30] <skaet> infinity,  could you check the core logs and see if something's gone south on it?   it seems to be taking quite a long time after all the builders have reported success...
[01:30] <skaet> kapok.buildd finished at Mon Feb 27 23:08:10 UTC 2012 (success)
[01:30] <skaet> cardamom.buildd finished at Mon Feb 27 23:09:25 UTC 2012 (success)
[01:30] <skaet> celbalrai.buildd finished at Mon Feb 27 23:11:25 UTC 2012 (success)
[01:31] <skaet> given its now: Tue Feb 28 01:31:05 UTC 2012 and it hasn't finished
[01:36] <skaet> hmm... its waiting on annonaceae - but I'm not seeing annonaceae in the set of builders...   hrmmm
[01:37] <skaet> slangasek, ^ you know what's going on with annonaceae?  which arch was it mapped to?
[01:40] <GrueMaster> skaet: That was a beaglexm buildd.  Should have been replaced with a panda.
[01:41] <skaet> Thanks GrueMaster.  I'll kill it now then, and see what else happens.
[01:41] <GrueMaster> (all the *ceae machines were beaglexm omap boards).
[01:43] <skaet> NCommander, infinity - could you look at the scripts and see if there are any other spots that might need fixing as well....
[01:44] <skaet> (reference was in ubuntu-core set)
[01:44] <NCommander> skaet: I'll poke it in the morning if infinity doesn't get to it; he wrote that code so he should know it better
[01:46] <skaet> thanks NCommander.  :)
[01:47] <infinity> GrueMaster: No it wasn't.
[01:47] <infinity> GrueMaster: We didn't decommission the beagles.
[01:48] <GrueMaster> Ok.  Thought we were working on them too.  It is a beaglexm, though.
[01:48] <infinity> Yes, I know.
[02:01] <infinity> skaet: annonaceae should be recovering from whatever insanity took it over.  I can respin core later when the world's settled down a bit, or something.
[02:01] <infinity> (Not that it's wildly important to have it in sync for beta1, it's not like it has an installer or anything)
[02:01] <skaet> infinity, coolio.  thanks.
[02:05] <stgraber> skaet: 02:03 <TheMuso> So maybe just disable the at-spi/atk-bridge code in ubiquity-dm for now, and I'll bang on it and see what I can find out, and I'll need to talk to upstrea in any cased.
[02:06] <stgraber> skaet: actually, a bit of context might help: 02:02 <TheMuso> The only update so far is that the latest code from upstrea for the accessibility stack, with the exception of GTK, doesn't help fix the problem.
[02:06] <skaet> stgraber, release note time sounds like.... :-/
[02:07] <stgraber> skaet: what do you prefer as a release note, manual partitioning not working unless you use the live session or accessibility disabled in the installer?
[02:07] <skaet> stgraber,  edubuntu dvd's finished building - should be posting any minute now.
[02:07] <stgraber> skaet: looks like it did, just got the e-mail notification. thanks
[02:10] <skaet> stgraber,  think I'll wait for pitti to comment on this...  not sure about the size of the user pool for each of those features.
[02:11] <skaet> suspect it will bias towards accessibility disable in the installer, but want his input.
[03:26]  * skaet calling it an evening...
[03:36] <skaet> Riddell,  pitti - pad is up to date - some weirdnesses/concerns from today's builds and redos looking likely.
[03:37] <skaet> (specifically arm images)
[03:39] <infinity> skaet: What else when goofy with ARM images?
[03:40] <infinity> skaet: I thought it was just core.
[03:40] <infinity> s/when/went/
[04:19]  * slangasek scratches his head.  I think that packageset listing is wrong for nis maybe :)
[04:19] <micahg> yeah, those look wrong
[04:42] <stgraber> ^ that should fix the package set related mistakes
[04:44] <pitti> Good morning
[04:47] <pitti> "respin triggering bug"? (from the pad)
[04:49] <pitti> stgraber: there is your ubiquity upload in the queue
[04:49] <pitti> stgraber: that'll need respins for everything, right?
[04:49] <pitti> well, no alternates/servers of course
[04:53] <pitti> but I guess we need to rebuild servers as well when sorting out the python-babel stuff
[05:00] <pitti> stgraber: do you know if bug 905754 needs to be included into ubiquity? the current upload doesn't seem to
[05:00] <ubot2`> Launchpad bug 905754 in libtimezonemap "Israel is not on the installer map" [High,Fix released] https://launchpad.net/bugs/905754
[05:06] <stgraber> pitti: 20:14 -queuebot:#ubuntu-release- Removed package: libtimezonemap
[05:06] <stgraber> I believe that one was for the map
[05:07]  * stgraber reads the question again :)
[05:09] <stgraber> pitti: ubiquity seems to just depend on the gir package so I don't think any change in ubiquity is required
[05:13] <stgraber> not sure why we still have an ubiquity task on that one ... I guess the easiest will be to test with a recent build and see if it works as expected...
[05:18] <pitti> stgraber: ah, thanks
[05:19]  * pitti removes ubiquity task then
[05:27] <ScottK> kde-workspace should get in if we care about Lucid -> Precise for this milestone.
[05:28] <pitti> was just looking at it
[05:28] <pitti> ScottK: I'm inclined to accept it now; it doesn't make much difference on the images, but we'll respin anyway, and this looks rather safe
[05:28] <pitti> we don't currently plan to respin alternates, but we could for this if you want
[05:32] <ScottK> There's currently no tests done on the Kubuntu alternates so there's no retesting needed after a respin.
[05:32] <ScottK> I'd be inclined to respin the alternates too.
[05:35] <ScottK> Good night and thanks.
[05:36] <pitti> ack
[05:36] <pitti> ScottK: good night
[05:37] <pitti> noted so in the pad
[05:43] <slangasek> stgraber: libtimezonemap> do you have time to test that?
[05:43] <slangasek> would like to make sure we get that tested asap so we know if another ubiquity change is needed
[05:43] <slangasek> evan certainly seemed to think one would be
[06:17] <micahg> it seems like I might need to upload a fix for icedtea-web (it doesn't affect the images, but no change packages would be picked up on ubuntu and kubuntu dvd respins)
[06:17] <pitti> micahg: that sounds fine
[06:18] <pitti> in fact, I could need a main package to get the publisher running for main and recompute Task: headers
[06:18] <pitti> (for downsizing ubuntu desktops)
[06:18] <micahg> ooh, sounds like fun :)
[06:19] <pitti> I can also take that live-build upload, it's harmless enough (just fixing an example)
[06:20] <micahg> there's no magical postinst syntax checker is there?
[06:20] <pitti> sh -n ?
[06:20] <pitti> I've seen that in some package's ruls file
[06:20]  * micahg will have to build the package first, will try
[06:20] <pitti> running all the scripts through sh -n and fail the build if that fails
[06:23] <micahg> the issue is icedtea-7-plugin BTW
[06:23]  * micahg wonders if doko_ is up yet
[06:26] <pitti> not a very hacker-friendly time yet in Germany
[06:27] <micahg> ok, I'll just test and upload a fix
[06:28] <micahg> do I need an FFe to change which packages are seeded for Xubuntu?
[06:29] <pitti> by the letter, I guess so; what do you want to change?
[06:30] <micahg> well,we want to drop quadrapassel so we can get clutter off the images for the LTS, we were thinking of adding alacarte since it no longer depends on half of GNOME
[06:31] <pitti> that seems fine
[06:32] <micahg> I was goign to wait until after beta 1 to make these changes
[06:42] <micahg> pitti: I think you need firefox-locale-en for it to function properly in the live enc
[06:42] <micahg> *env
[06:43] <pitti> micahg: oh, how so?
[06:43] <micahg> well, you need one of the locales available I think
[06:43] <pitti> it just ships en-GB and en-ZA stuff, the en-US is built int
[06:43] <micahg> oh, really, nevermind them :)
[06:44] <micahg> so it is, I remembered something breaking in my VMs without it, but maybe that was fixed
[06:44] <micahg> looks fine though, so ignore me :)
[06:44] <pitti> micahg: thanks for checking
[06:49] <micahg> pitti: do we need to save that icedtea upload for something, I got 3 upgrade failure reports in the past 4 hours
[06:50] <pitti> nope, accepting; thanks for fixing!
[06:50] <micahg> I installed the bad package and then installed the fixed one, it finished upgrading, so I considered it a success :)
[06:51] <micahg> pitti: thanks
[07:02] <micahg> this is hilarious, we have arch skew where powerpc/armhf/armel is ahead of i386/amd64
[07:05] <pitti> starting desktop builds for new ubiquity / kdebase-workspace on kubuntu
[07:07] <micahg> pitti: should I replace hpijs with its equivalent in the seed?
[07:07] <pitti> micahg: ah, please
[07:12] <micahg> I'm doing a test rebuild on openjdk-6 on i386, if it's successful, I'll need some help getting it on a faster builder
[07:14] <pitti> oh, didn't we just get a new build yesterday?
[07:19] <micahg> yes, but it failed on i386
[07:19] <micahg> I just wanted to make sure it's the builder and not the build
[07:20] <micahg> but armhf/armel/powerpc finished just fine
[07:21] <pitti> ah, presumably we don't run the tests there
[07:21] <micahg> maybe we should just get it going on a faster build in any event since the build farm is free
[07:21] <micahg> *builder
[07:22] <pitti> java.util.NoSuchElementException doesn't sounds like it's related to out of memory or space?
[07:23] <micahg> I have no idea
[07:23] <jibel> good morning
[07:23] <pitti> bonjour jibel
[07:23] <pitti> micahg: so, I can hand it over to zirconium
[07:23] <jibel> why upgrades are marked 'rebuilding' on the tracker ?
[07:23] <micahg> maybe jamespage can help if he's around
[07:23] <pitti> micahg: it's not like our i386 builders have terribly much to do ATM
[07:24] <pitti> micahg: if you think it could work on i386; but amd64 is still building as well
[07:24] <pitti> jibel: I don't know
[07:24] <pitti> micahg: oh, https://launchpad.net/ubuntu/+source/openjdk-6/6b24-1.11.1-3ubuntu1/+build/3243935 just shows the exception as well
[07:24] <pitti> (amd64 build)
[07:25] <pitti> semop(2): encountered an error: Invalid argument
[07:25] <pitti> it might actually be this, which might or might not be unrelated
[07:26] <micahg> well, both of those buildds were slow (yellow and vernadsky), idk, maybe jamespage can take a look or we should wait for doko
[07:26] <micahg> ah, still early for the UK as well
[07:39] <pitti> micahg: congrats to your ubuntu seed commit, it was rev number 2000 :)
[07:41]  * micahg wonders what type of prize comes with that
[07:42] <nigelb> micahg: slavery ;)
[07:44] <jibel> pitti, do you think I can re-enable them ? there's nothing mentioned on the pad
[07:44] <pitti> jibel: fine for me
[07:44] <jibel> pitti, k, thank
[07:44] <pitti> jibel: I guess the Kubuntu one should be re-attempted as we got a kde-workspace bug fix this morning
[07:44] <pitti> (one of the linked bugs)
[07:44] <pitti> jibel: did you run into the "dpkg: already configured" issue in manual tests?
[07:45] <pitti> that bug is still open and apparently breaking quite a lot
[07:45] <jibel> pitti, I did once and bdmurray too
[07:53] <jibel> I confirm bug 940196 with alternate 20120227.2. cannot upgrade from cd without network
[07:53] <ubot2`> Launchpad bug 940196 in update-manager "cdromupgrade from Oneiric to Precise no network failed: The package 'unity-2d-places' is marked for removal but it's in the removal blacklist" [High,Triaged] https://launchpad.net/bugs/940196
[07:55] <pitti> micahg: seems the amd64 jdk build hangs at the same position
[07:55] <slangasek> jibel: yeah, I've diagnosed that one
[07:55] <micahg> pitti: I'm 9GB into the test build
[07:56] <slangasek> jibel: bug #940240> so there are no other term.logs lying around, that might have the output from installing?
[07:56] <ubot2`> Launchpad bug 940240 in update-manager "lucid -> precise upgrade: dist-upgrade/apt-term.log only shows packages being removed" [High,New] https://launchpad.net/bugs/940240
[07:59] <jibel> slangasek, no other term.logs. the only trace of packages installation is in dpkg.log
[07:59] <slangasek> hmm :/
[07:59] <slangasek> ok
[08:00] <mvo> jibel: is /var/log/apt/history.log showing sensible data?
[08:01] <mvo> its a bit mysterious as the log is opened with fopen(.., "a")
[08:01] <mvo> in libapt
[08:02] <mvo> jibel: this is only for the main-all build? or for all of them?
[08:02] <jibel> mvo, looking
[08:03] <mvo> jibel: the time stamps are pretty clearn, apt-term.log has 17:54 in the header but main.log starts at 16:19 :/
[08:04] <jibel> mvo, only with main-all when debconf prompts are redirected to a file
[08:04] <mvo> jibel: oh…
[08:04] <slangasek> mvo: hey, what's the package name for the backported apt used by the upgrader for lucid?
[08:04] <jibel> mvo, i.e DEBIAN_FRONTEND is set to something else than noninteractive
[08:04] <mvo> jibel: woah, that is interessting
[08:05] <mvo> slangasek: its "Packages=libapt-pkg4.12,libapt-inst1.4,release-upgrader-python-apt
[08:05] <mvo> "
[08:05] <mvo> slangasek: it comes from the users ${mirror} with a fallback to archive.u.c
[08:06] <slangasek> ah, the source is in universe instead of main, that's why I couldn't find it :)
[08:06] <slangasek> mvo: thanks
[08:06] <jibel> mvo, I think main-all is just a red-herring and the cause of the upgrade failure is due to puppetmaster failing to restart, which generate a failure in etckeeper
[08:06] <mvo> yw
[08:07] <mvo> jibel: right, I'm not concerned with the failure at this point, I'm just puzzled why the logs are not there :/
[08:07] <jibel> agree
[08:07]  * mvo scratches head
[08:09] <jibel> mvo, history.log contains 3 lines
[08:09] <jibel> mvo, start date, end date and a big remove in between
[08:10] <mvo> jibel: so no trace of the  upgrade there as well? and no history.log.1.gz or anything like this?
[08:14] <jibel> mvo, no, the dist-upgrade backup directory contains the installation of the upgrader itself
[08:32] <Daviey> jibel: i thought the puppetmaster + etckeeper/bzr issue was resolved?
[08:33] <pitti> hello Daviey
[08:36] <Daviey> morning pitti
[08:37] <pitti> nova is built now, so time to spin server images
[08:37] <jibel> Daviey, which version resolved this issue ? I got it last Friday when I was looking why main failed.
[08:37] <jibel> morning Daviey
[08:38] <Daviey> pitti: yep, i was just looking over it right now :)
[08:38] <Daviey> jibel: Hmm, perhaps it's a related issue.. I thought the LANG issue was to blame.
[08:40] <Daviey> pitti: triggering now.
[08:41] <Daviey> pitti: have you already triggered?
[08:41] <pitti> server x86/armels building for nova
[08:41] <pitti> Daviey: yes, something else missing?
[08:41] <Daviey> Oh, no - it just explains why it crapped out on lockfile for me :)
[08:49] <mvo> jibel: ok, here is my theory (and I think its correct) - there is no main log because the main upgrade was not run because dpkg-preconfigure failed with various "cups template parse error: Template parse error near `Description-sr@latin.UTF-8: elite li da CUPS Å¡tampa nepoznate radnje kao raw radnje?', in stanza #1 of /tmp/cups.template.192914" errors
[08:50] <mvo> jibel: now of course that is a bug in the upgrader as it needs to record this as a failure :(
[08:55] <mvo> jibel: hm, hm, maybe not, but its definitely something along these lines
[08:56] <jibel> mvo, this error is still in the latest run but everything is logged correctly
[08:56] <jibel> https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-main/37/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all-amd64/bootstrap.log
[08:57] <pitti> ubuntu desktop i386 is still a tad oversized; I made some seed changes to fix this, but I'll need a respin for this
[08:57] <pitti> jibel, Riddell ^ would that sound ok?
[08:57] <pitti> the previous respin is just from an hour ago or so, so not much lost there
[08:57] <jibel> pitti, ok
[08:58] <Riddell> pitti: good with me
[08:58] <pitti> I think I freed a little less than a MB, which should suffice
[08:59] <Riddell> ooh Kubuntu undersized :)
[08:59] <pitti> also, ubuntu-meta was out of date relative to the images
[08:59] <pitti> so that needs a rebuild
[09:00] <jamespage> micahg, looking now
[09:01] <pitti> Riddell: good morning
[09:03]  * pitti updates pad again for up-to-the-minute status
[09:09] <Riddell> "get israel on installer map" uh oh , that could get political
[09:19] <ogra_> infinity, skaet, ac100 should be a "community supported" image ... not sure if it needs to be advertised in any official doc or not, it will be announced on the ac100 mailing list anyway ...
[09:24] <didrocks> pitti: some news on the keybinding for switching ws, we will revert them for this cycle
[09:24] <didrocks> pitti: I guess it will be a post beta1 thing?
[09:24] <pitti> didrocks: unless you can upload it in the next hour or so
[09:24] <pitti> didrocks: ubuntu desktop is scheduled for a rebuild, but need to wait for the DVD builds to finish
[09:25] <didrocks> pitti: oh? that, I can :)
[09:25] <pitti> didrocks: is that "unity"? because that takes a while to buid
[09:25] <didrocks> pitti: it's compiz
[09:25] <pitti> didrocks: and it would also invalidate the ARM images
[09:25] <didrocks> takes a while as well, but a little bit quicker
[09:26] <seb128> pitti, what images are planned for rebuild? I guess we want to avoid trivial changes like rhythmbox (fixing sound indicator integration) or nautilus (segfault fix)?
[09:27] <pitti> seb128: so far I only plan to respin ubuntu desktop for the slight i386 oversizedness
[09:27] <pitti> didn't plan alternates, ARMs, DVD, etc.
[09:27] <pitti> didrocks: it's fine for you to upload, so that we can grab it in case we do want to rebuild the otherrs
[09:28] <pitti> seb128: yes, I looked at those, and they didn't seem to be issues that couldn't be fixed with upgrades
[09:28] <seb128> pitti, ok, I was pointing it in case, I'm always unsure what are the criteria for accepting updates or not when respins are done
[09:28] <pitti> didrocks: I guess the hotkey is good enough for b1, given how this was firmly decided pre-b1? :-)
[09:28] <seb128> pitti, but yeah, no deal breaker
[09:29] <pitti> strictly speaking we'd need to rebuild alternates and DVDs as well for the new ubuntu-meta
[09:30] <pitti> jibel: when do you think is the cutoff point for rebuilds when we still want to get good testing coverage?
[09:30] <pitti> jibel: i. e. do we have room for another set of ubuntu alternates/DVDs?
[09:30] <jamespage> micahg, getting nowhere fast ATM - I have to duck out for 1.5 hours - I can look again when I get back if its still not fixed...
[09:30] <didrocks> pitti: hm, I staged the libjpeg-dev in c-p-m as well though :/
[09:30] <micahg> jamespage: ok, do you think it's transient or a real failure though
[09:31] <didrocks> pitti: as it's what I'm running now, I need to revert it if we want to sneak c-p-m in (for the keybinding revert)
[09:31] <jamespage> micahg, probably real as it happened on i386 and amd64
[09:31] <micahg> jamespage: I have a test build going right now that should hopefully be fnished in an hour
[09:31] <pitti> didrocks: if you tested it, and it works with libjpeg8 (well, no reason to believe it doesn't), its' fine
[09:31] <pitti> didrocks: compiz is 46 minutes on armhf, not too bad
[09:31] <didrocks> pitti: sorry, it's compiz-plugins-main, not compiz
[09:32] <pitti> didrocks: ah, that's 35 mins on armhf
[09:32] <didrocks> pitti: also, that will trigger a "bug" (the shortcuts display is hardcoded in unity, but I guess its not such a big issue compared to the other issue ;))
[09:32] <pitti> didrocks: please get it uploaded, and I'll see to it
[09:32] <pitti> didrocks: yes, I noticed; it doesn't adapt to the actual keys
[09:32] <pitti> didrocks: but no biggie for b1 indeed
[09:33]  * didrocks rebuilds in a pbuilder to ensure everything is fine
[09:34] <didrocks> pitti: will ping you once done and then upload
[09:34] <pitti> didrocks: thanks; the queue-bot will pick it up, too
[09:34] <didrocks> oh right :)
[09:34] <pitti> queuebot: ping pitti on compiz-plugins-main
[09:34] <pitti> (I wish this would work :) )
[09:35] <pitti> queuebot: oh, and make me a cup of tea, please
[09:35] <didrocks> :-)
[09:35] <didrocks> pitti: almost ^ :p
[09:37] <pitti> Riddell: any reservations against rebuilding the Ubuntu images for the compiz and ubuntu-meta updates later on? (I can handle this)
[09:39] <pitti> seb128: nautilus looks easy, but is also on edubuntu and ubuntustudio, don't want to rebuild these
[09:40] <seb128> pitti, ok, no worry, we don't really need it, I'm just trying to not get too much sitting in the queue because that leads to issues like uploads being rejected (cf my mail on the list)
[09:40] <pitti> yeah
[09:42] <Riddell> pitti: none from me
[09:46] <jibel> pitti, yes I do have room. today all day is fine for rebuilds
[09:46] <pitti> jibel: ok, great
[09:46] <jibel> (european time I mean)
[09:47] <pitti> ah, server daily-preinstalled done (x86, too)
[09:47] <pitti> Daviey: ^ FYI
[09:47] <pitti> should now have the new nova
[09:53] <micahg> jamespage: pitti: I'm going to sleep soon, I'm sure doko will be around before I get up for openjdk-6, I can let everyone know how the test rebuild goes in ~7 or so hours, but I figure you'll have a solution for it by then
[09:54] <doko> micahg, context?
[09:54] <doko> ahh, I see
[09:54] <micahg> doko: oh, hi :), the openjdk-6 builds failed on i386/amd64, but built on the rest
[09:55] <micahg> this prevented icedtea-web (which I fixed) from building on the opposite archs of openjdk-6 due to arch skew
[09:56] <doko> micahg, pitti: yes, seen. I re-enabled the testsuite. so the best "fix" for the beta is to disable it again (and magically bringing down build times)
[09:59] <micahg> doko: so I can kill my local test rebuild then or is there some benefit to know if it succeeds?
[09:59] <doko> micahg, won't succeed, I see the same here locally
[10:00] <micahg> doko: ok, killing, thanks
[10:01] <didrocks> pitti: uploaded, should be here soon
[10:06] <pitti> didrocks: yay, thanks
[10:06] <micahg> Riddell: is nm-applet hidden in xubuntu worth respinning for?
[10:07] <pitti> micahg: your call, but it seems rather ugly to me
[10:07] <micahg> pitti: ugly to not have it, I would agree with that :)
[10:08] <pitti> micahg: if it was ubuntu, I'd respin, if I had a fix
[10:08] <micahg> pitti: ok, I'll upload a fix in a few minutes (just a gconf setting)
[10:08] <micahg> pitti: should I make my other changes as well (drop clutter/quadrapassel, add alacarte)?
[10:09] <pitti> micahg: fine for me; better to have changes in beta than afterwards IMHO
[10:09] <pitti> and today's still enough time
[10:09] <Riddell> micahg: yeah just depends if xubuntu dudes can get it tested in time
[10:15] <micahg> please refresh  my memory, do I have to wait a publisher cycle before regenerating a -meta package?
[10:16] <micahg> Riddell: I see no tests done yet, so doesn't seem to matter
[10:17] <pitti> micahg: not for -meta
[10:17] <pitti> micahg: but you need to wait for two publishers to have seed changes propagated to Task: headers
[10:17] <pitti> (and publish a package in the affected component, too)
[10:17] <pitti> so that xubuntu-meta upload will provide that
[10:18] <Riddell> -meta uses the bzr branch usually
[10:18] <micahg> pitti: ok, thanks, should I add a note about the xubuntu rebuild to the pad?
[10:18] <pitti> micahg: please do
[10:18] <pitti> the only exception is if you seed a package that just got promoted
[10:18] <pitti> that needs a publisher for the actual promotion to happen, as ./update verifies the component
[10:18] <pitti> but that doesn't apply to xubuntu
[10:21] <micahg> pitti: is the nm-applet issue important for the alternate also, I only marked it for the Desktop imge
[10:21]  * micahg would think not
[10:21] <pitti> micahg: yes, an alternate install would certainly have the same problem?
[10:21] <micahg> oh, I would think that updates would run and pick up the new package
[10:22] <micahg> ok, marked both
[10:28] <micahg> pitti: nm-applet fix confirmed, can you release the xubuntu-default-settings package
[10:29] <pitti> micahg: done
[10:29] <pitti> updated pad with the build link
[10:29] <micahg> pitti: thanks, I just uploaded the meta as well
[10:37] <micahg> pitti: thanks for all your help tonight
[10:37] <pitti> my pleasure :) thanks for having an eye on xubuntu
[10:45] <pitti> Riddell: the pad says kubuntu arm was rebuilt for amarok, but http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/ only has an image for Feb 25?
[10:46] <Riddell> pitti: I've not rebuilt kubuntu arm
[10:46] <Riddell> so whoever wrote that is probably wrong
[10:46] <pitti> Riddell: ah, I guess I was confused then
[10:46] <Riddell> please do start off a rebuild if it's easy for you to do (I'm in the middle of testing)
[10:46] <pitti> it said "package built" then
[10:46] <pitti> Riddell: yep, doing
[10:47] <pitti> running, pad updated
[10:47] <pitti> ah, compiz-p-m built everywhere, excellent
[10:47] <pitti> didrocks: ^
[10:48] <pitti> waiting for publisher/mirror, then will rebuild
[10:48] <didrocks> pitti: nice!
[11:09]  * pitti makes use of the empty buildds and uploads some no-change rebuilds against fixed binarymangler
[11:09] <pitti> (only packages which are not on any CD)
[11:09] <pitti> for bug 875466, FTR
[11:09] <ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
[11:11] <pitti> hm, queuebot is blatantly lying about the seeds
[11:14] <pitti> starting desktop/DVD ubuntu rebuilds for oversizedness and compiz
[11:16] <pitti> starting ubuntun alternate for the same
[11:20] <pitti> lunch, bbl
[11:52] <barry> ScottK: my momma has a g5 power supply
[11:58] <ScottK> ;-)
[12:13] <pitti> http://cdimage.ubuntu.com/daily-live/20120228.1/
[12:13] <pitti> yippie! non-oversized
[12:14]  * ogra_ does an ac100 testinstall
[12:19] <pitti> starting ubuntu arm image biulds
[12:19] <ogra_> uh, why do you rebuild arm ?
[12:19] <ogra_> just for consistency ?
[12:20] <pitti> ubuntu-meta, the compiz bug fix, and seed changes
[12:20] <ogra_> ah, well, compiz :P
[12:27]  * ogra_ sighs ... still no keyboard selection offered in oem-config
[12:39]  * ogra_ is searching his butt off to find the font size selection in the settings .... where did we hide it again ? the huge and clunky fonts are really to big for a netbook screen
[12:39] <seb128> ogra_, in the a11y capplet you have a text size combo
[12:39] <seb128> i.e small, normal, big etc
[12:40] <ogra_> ah, thanks, you told me before ... sorry i forgot !
[12:40] <seb128> no numerical value selector
[12:40] <ogra_> its really really non intuitive
[12:40] <seb128> but you can use ubuntu-tweaks or gnome-tweak-tools or gsettings or whatever
[12:40] <seb128> indeed...
[12:40] <ogra_> i can live with /small/normal/big ....
[12:40] <ogra_> just finding them is really hard
[12:44] <pitti> starting xubuntu alternate build
[12:45] <seb128> ogra_, it's a known issue, upstream and our design team have been discussion way to improve that but that didn't get resolved yet
[12:45] <ogra_> ah, cool, at least someone cares then
[12:56] <NCommander> pitti: did someone lok at ubuntu-core last night?
[12:57] <pitti> NCommander: I didn't do anything with core; what do you mean with "look"?
[12:57] <pitti> does it need a rebuild?
[12:58] <NCommander> 20:43:53 < skaet> NCommander, infinity - could you look at  the scripts and see if there are any other  spots that might need fixing as well....
[12:58] <NCommander> 20:44:22 < skaet> (reference was in ubuntu-core set)
[13:10] <jibel> pitti, another report "dpkg already installed" bug 942578
[13:10] <ubot2`> Launchpad bug 942578 in update-manager "lucid -> precise server upgrade fail: dpkg: error processing dpkg (--configure): package dpkg is already installed and configured" [Undecided,New] https://launchpad.net/bugs/942578
[13:56] <ogra_> hmm, what is akonadi and why is it installed on all my test installs ?
[13:57] <ogra_> hmpf, looks like a kde app
[14:03] <ScottK> It's only used by KDE, but it's not formally a KDE app.
[14:03] <ScottK> No idea why it's in your test installs.
[14:04] <ogra_> its also in the ac100 manifest, weird
[14:04] <ogra_> not in any other arm manifest though ...
[14:05] <ogra_> even though all images use the same seed
[14:07] <ScottK> I don't see any non-KDE reverse depends/build-depends, so no idea.
[14:08] <ogra_> ugh ... it also has kdepim installed
[14:08] <ogra_> and kate
[14:08] <ogra_> how the heck does that end up on the ac100 images
[14:08] <ScottK> Well that would explain Akonadi anyway.
[14:08] <ogra_> yeah, indeed
[14:09] <ogra_> hmpf
[14:12] <ogra_> bah, i assume it gets pulled in by ubiquity-frontend-kde somehow
[14:12] <ogra_> not sure how that ended up on the ubuntu image though
[14:19] <jdstrand> pitti: hi! fyi, I saw that libapache2-modsecurity briefly showed up on the server-ship seed. my team reviewed its inclusion for main in either oneiric or precise UDS and decided it was not suitable. is there a MIR for it?
[14:21] <jdstrand> I don't see one...
[14:22] <seb128> ^ dunno why the bot thinks pitivi is still in those seeds it's not
[14:24] <jdstrand> fyi, I just upload a libxml2 security update. it is not required for beta1
[14:24] <jdstrand> Riddell, skaet: ^
[14:24] <jdstrand> (and hello)
[14:32] <pitti> jdstrand: no, it was kind of an error
[14:32] <pitti> jdstrand: I reviewed the seeds for packages which did not exist any more
[14:32] <pitti> jdstrand: I removed most of them, but for some it looked rather straightforward to fix them
[14:33] <pitti> jdstrand: like gcc-4.5-docs -> 4.6, etc.
[14:33] <pitti> jdstrand: and libapache2-mod-security looked darn close to libapache2-modsecurity
[14:33] <pitti> jdstrand: but I unseeded it again after I realized the universe deps
[14:34] <jdstrand> pitti: I see, cool. thanks :)
[14:40] <ScottK> pitti: Since the libxml2 upload is a security upload, what would you think about the idea of accepting it so it can be picked up opportunistically if there are respins and people will get it as an upgrade right away if not.
[14:40] <ScottK> I hate the idea of leaving security fixes just sitting there.
[14:41] <pitti> ScottK: no objection from me
[14:41]  * ScottK looks around.
[14:42] <pitti> Riddell: ^ ?
[14:43] <ScottK> jdstrand: How does the copyright attribution in the upstream code change for a security update?
[14:43] <ScottK> (was that part of an upstream patch)
[14:52] <stgraber> slangasek: sorry, closed IRC before I could see your message... testing the timezone map now
[14:58] <Riddell> what what?
[14:58] <pitti> Riddell: asking about accepting the libxml2 security fix now, so that it's there for opportunistic pickup of new image builds (but we wouldn't respin just for that)
[14:58] <Riddell> ScottK: weren't you muttering yesterday about keeping versions in sync :)
[14:58] <pitti> Riddell: and I think it's a good idea
[14:58] <Riddell> yeah go ahead
[14:59] <stgraber> pitti: btw, did you see the discussion on bug 939450?
[14:59] <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
[14:59] <NCommander> skaet: ping?
[14:59] <pitti> stgraber: I saw the bug, yes; seems Luke will look into it?
[15:00] <ScottK> Riddell: Generally, but I think leaving security stuff unfixed is an exception.
[15:00] <stgraber> pitti: skaet and I were mostly wondering what'd be best to release note between "installer will explode if you choose manual partitioning outside of the live session" and "no accessibility in Ubiquity for beta 1"
[15:00] <stgraber> pitti: he's working on it but isn't planning on having a fix for beta-1
[15:00] <skaet> good morning
[15:00] <pitti> no, certainly this is release note matter
[15:00] <ScottK> OK, I see someone beat me too it.
[15:00] <pitti> hey skaet
[15:02] <skaet> good afternoon pitti,  any preference between which group of testers we warn away?
[15:02] <pitti> stgraber: I think more like the former
[15:02] <pitti> i. e. know that it crashes after which step
[15:03] <pitti> skaet: the people who will run beta are still expected to be technical enough to know what manual partitioning is, I think
[15:03] <skaet> thanks pitti.
[15:06] <jdstrand> ScottK: the change to dict.c was part of the upstream patch
[15:06] <ScottK> jdstrand: Thanks.
[15:06] <skaet> Riddell,   looking back on last night's arm builds,  looks like kubuntu preinstalled failed.   Is root cause known?
[15:06] <stgraber> skaet: are you adding that to the release note or want me to write it?
[15:06] <skaet> stgraber,  please go ahead and add it.  :)
[15:07] <Riddell> skaet: no sorry not got to arm at all yet
[15:08] <Riddell> I'm planning on checking dvds then seeing if arm needs my attention
[15:09] <ScottK> Although apparently we can test KDE on ogra_'s ac100 images just fine if we want.
[15:10] <skaet> ScottK,  can you see if you can figure out why the Kubuntu preinstalled failed?  It was the only one of the preinstalleds from last nights run that has seemed to.
[15:10] <ScottK> skaet: Can you point me to the log?
[15:11] <ScottK> If I had to hazard a guess, I'd guess archive skew due to the kde-workspace upload last night.
[15:12] <Riddell> ScottK: what do you mean by "ogra_'s ac100 images"?
[15:12] <ScottK> Some KDE stuff crept onto them.
[15:14]  * skaet trying to figure out path to kubuntu preinstalled log file...
[15:20] <ogra_> Riddell, there seems to be some dependency weirdness on ac100, so akonadi, kdepim and kde-window-manager end up on the image ... pulled in by ubiquity-frontend-kde apparently
[15:22] <Riddell> ogra_: on the ubuntu desktop image?
[15:22] <ogra_> yep
[15:22] <ogra_> only on ac100 though
[15:22] <Riddell> no conspiracy theories please, not deliberate :)
[15:23] <ogra_> hehe, no, likely my error ... but i havent found the root cause yet
[15:23] <Riddell> something depending on ubiquity which needs a frontend so randomly brings in ubiquity-frontend-kde?
[15:24] <ogra_> well, yes, but thats also the case on the other armel images
[15:24]  * pitti waves good bye, need to run out a bit earlier today
[15:24] <Riddell> good night pitti
[15:24] <skaet> pitti, is there an external path to the log files or do I need to paste them into an email?
[15:24] <ogra_> we have jasper depending on oem-config which in turn depends on ubiquity on the other armel images ...
[15:24] <Riddell> ogra_: years ago I had to remove ubiquity from the seed and just add ubiquity-frontend-kde because ubiquity was brining in -gtk, so maybe it's that in reverse?
[15:25] <ogra_> on ac100 jasper is replaced by ac100-tarball-installer ... which has exactly the same set of deps
[15:25] <Riddell> mm, so depend on ubiquity-frontend-gtk before jasper?
[15:25] <ogra_> other way round, but yes
[15:25] <ogra_> (before ac100-tarball-installer)
[15:26] <ogra_> the prob is that ac100-tarball-installer is a universe package and isnt seeded at all (due to the image being built from universe)
[15:27] <ScottK> skaet: I found the copy from my email.
[15:27] <ogra_> so i cant really play with seeds here ...
[15:27] <scott-work_> i noticed that the ubuntu studio beta image is not available any longer in the tracker
[15:27] <ogra_> but i guess i can cheat through a fixed dependency in the package or so
[15:27] <scott-work_> anyone know the reason and when another image will be available?
[15:27] <skaet> ScottK - goodness.   Was just about to email you the log I'd found in the system.  :)
[15:27] <ScottK>  oem-config-kde : Depends: oem-config (= 2.9.22) but it is not going to be installed
[15:27] <ScottK>  ubiquity-frontend-kde : Depends: ubiquity (= 2.9.22) but it is not going to be installed
[15:29] <ScottK> skaet: At a quess, some kind of archive skew issue.  Can you try it again?
[15:29] <skaet> ScottK,  as long as I'm not colliding with someing in progress - sure.   Let me check.
[15:30] <skaet> Riddell,  are you driving the ubuntu ARM preinstalled rebuilds?  how close to done?
[15:30] <ogra_> skaet, i think pitti triggered them
[15:30] <Riddell> skaet: not today I haven't been
[15:31] <ogra_> 3h ago
[15:31] <skaet> Riddell, ogra_ - hmm... not seeing them run on nusakan,  maybe the pad is stale?
[15:31] <Riddell> mm not sure, how do we find that out if he's away?
[15:31] <Riddell> ogra_: do you have shiney new images?
[15:31] <ogra_> well, he said he would do them for: "<pitti> ubuntu-meta, the compiz bug fix, and seed changes"
[15:32] <ogra_> Riddell, i dont think so
[15:32]  * ogra_ checks nusakans processlist
[15:32] <Riddell> I can text pitti
[15:33] <ogra_> nah, gimme a sec
[15:33] <skaet> ScottK - bit of a mystery - there are some arm images on the tracker - anyone know if they work?   or just go ahead and retrigger?
[15:33] <ogra_> yep, seems they are all done
[15:34] <skaet> thanks ogra_
[15:34] <ogra_> http://cdimage.ubuntu.com/daily-preinstalled/20120228.3/
[15:34] <ScottK> No idea.
[15:35] <skaet> ScottK,  ok,  I'll just go retrigger since the builders aren't in use right now.
[15:37] <Riddell> skaet: if ogra_ says they're all done what's to trigger?
[15:37] <skaet> Riddell,  rebuilding kubuntu arm preinstalled images
[15:38] <Riddell> oh cool, can't forget kubuntu :)
[15:38]  * skaet didn't want to run into existing arm rebuild in progress...
[15:40] <Riddell> ogra_: can't I really use a mobile phone charger to power this pandaboard?
[15:41] <ogra_> you need a 5V 3A supply (better 4A)
[15:41] <ogra_> any universal one will do (as long as the plug fits)
[15:41] <Riddell> ogra_: so I can't just plug in a mobile phone USB connection?
[15:41] <Riddell> my local shop doesn't have universal ones that fit
[15:41] <ogra_> not if you want to use any graphical output, or any USB device
[15:42] <Riddell> right
[15:42] <Riddell> that would be handy for test installs, meh
[15:43] <Daviey> ogra_: with a powered hub, you can still use serial console?
[15:44] <ogra_> probably, i really wouldnt though
[15:44] <ogra_> you *can* power the panda through the mini USB ... but thats not recommended and it isnt clear which parts of the board will work and which will fail
[15:45] <ogra_> its good enough to test a u-boot serial console, but as soon as the kernel fires up devices things will fall apart
[15:46] <Riddell> ogra_: which team did you end up on and which did Grue end up on?
[15:46] <debfx> pitti: what do you think about rebuilding all the packages with the md5sums error (not just the ones in main)? I count 174 source packages
[15:46] <skaet> scott-work,  I'm seeing the ubuntu studio image up there.   There was a full rebuild last night and the image refreshed - could that be the source of the ?
[15:47] <Riddell> debfx: pitti is away, me and skaet are driving
[15:47] <Riddell> debfx: what's the issue?
[15:47] <debfx> Riddell: bug #875466
[15:47] <ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
[15:48] <skaet> 20120228.1 is the date tag
[15:48] <debfx> it's not really relevant to the beta, we could just use the builders while they are idling
[15:48] <ogra_> Riddell, GrueMaster is in QA, i'm in foundations
[15:49] <ScottK> debfx: As long as they aren't on any images, it seems reasonable.
[15:49] <skaet> debfx, would rather wait until we know we have good images.    There will be rebuilds likely today.
[15:49] <ScottK> skaet: We can dribble them in so we don't flood the builders.
[15:50] <skaet> ScottK,  its the picking them up and archive issues I'm concerned about.
[15:50] <ScottK> ?
[15:50] <ScottK> As long as he avoids seeded packages, I'm not sure what you mean.
[15:50] <Riddell> debfx: looks like pitti already started, you can throw up the rest if you want to but maybe tomorrow when we are more certain not to need builders
[15:52] <skaet> ScottK,  libxt is in main
[15:53] <debfx> Riddell: ok
[15:55] <ogra_> infinity, skaet, what about armhf+mx5 images ? arent they also "tech-preview" ?
[15:56] <ogra_> (they should either go on the manifest as well, or ac100 should be removed)
[16:03] <skaet> ogra_ if there is testers lined up for them. and we're spinning them as part of the release,  they should be on the manifest.   Please edit to get it correct.
[16:03]  * skaet will stop trying to figure out what's in the manifest based on IRC traffic yesterday :P
[16:03] <ogra_> skaet, k, i need to ask GrueMaster if he planned to assign testing time for them,
[16:04] <ogra_> (he usually did, but i'm not sure he still does after all the changes)
[16:11] <skaet> ScottL, scott-work  - could you also review and sign off (by putting the date) for Ubuntu Studio in https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
[16:12] <skaet> stgraber, highvoltage,  please review https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest for Edubuntu to make sure its accurate
[16:13] <skaet> Daviey - could you review https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest for server and netboot
[16:13] <skaet> Riddell,  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest for Kubuntu
[16:13] <stgraber> skaet: looks good
[16:14] <Daviey> skaet: right
[16:14] <skaet> superm1, https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest,  please review and sign off for mythbuntu
[16:14] <Riddell> skaet: there's no powerpc on the manifest, does that mean we can stop making powerpc images?
[16:14] <Riddell> because they do take ages to build
[16:15] <ogra_> they arent supported in any way ... i guess thats why they arent on the list
[16:15] <ogra_> i doubt we'll stop building
[16:15] <Riddell> ogra_: neither is stuff like kubuntu-active but that's on the manifest page
[16:16] <skaet> Riddell,  want to wait for cjwatson to come back before having that discussion - but it is being contemplated.
[16:16] <Riddell> if they're just plain not being used we should stop making them, they take up our time
[16:17] <ogra_> ++
[16:17] <skaet> Riddell,  it comes down to testers being willing to test.   If there are no testers, then they won't go on the manifest.
[16:17] <ogra_> but i was under the impression there was a userbase
[16:18] <Riddell> a userbase is no good if there are no testers, and they're taking up our precious resources currently so I'm all for screapping them
[16:19] <ogra_> tunr them off and see who shouts at you ? :)
[16:19] <ogra_> *turn
[16:19] <Riddell> ogra_: yes excactly :)
[16:19] <skaet> Riddell,  agree that the builds would go much faster without them in.
[16:19]  * Riddell notes that testing dvd images is so much faster with a usb stick than with dvds
[16:20] <scott-work_> skaet: http://iso.qa.ubuntu.com/qatracker/milestones/208/builds/12720/testcases shows an image but clicking on the link tells me an image isn't available
[16:20]  * ogra_ wishes he had even DVDs on arm ...
[16:20] <skaet> scott-work,  looking...
[16:21] <scott-work_> skaet: i navigated there from the web-sties's front page, not a direct link
[16:21] <skaet> scott-work,  yeah,  I'm seeing it too.
[16:21] <jibel> scott-work_, download link is not setup for studio dvd. I'll fix it
[16:22] <scott-work_> jibel: thank you :)  (and you too skaet )
[16:22] <skaet> http://cdimage.ubuntu.com/ubuntustudio/dvd/20120228.1/
[16:22]  * ogra_ is out for 1-2h
[16:22] <skaet> yes,  images is there.  just a link issue.
[16:22] <skaet> thanks jibel
[16:23] <GrueMaster> Morning.  There was a question directed at me?
[16:23] <ogra_> GrueMaster, do you test mx5 ?
[16:23] <GrueMaster> I test all arm images during milestone release.
[16:23] <GrueMaster> If it is there, I will test it.
[16:24] <ogra_> ok, then i'll add them to the manifest once i return, thanks !
[16:24]  * ogra_ is out
[16:24] <GrueMaster> After this cycle, we will reevaluate what I test and what I don't test.
[16:24]  * skaet nods
[16:25] <GrueMaster> Riddell: Ping me in #ubuntu-arm and I can help you bring up your panda.
[16:31] <ScottK> skaet: I meant doing the ones that aren't in Main.
[16:33] <skaet> ScottK,  it wasn't clear from the bug or post which was being refered to - so rather err on side of not letting things through that could cause problems - that's all.
[16:34]  * skaet is fine with unseeded universe going through,  no probs.
[16:34] <skaet> Riddell,  can you confirm that pad.ubuntu.com/ubuntu-release now matches your understanding of the state of things too?
[16:36] <Riddell> skaet: yes I'd say so
[16:36] <Riddell> skaet: are you doing the kubuntu arm rebuilds?
[16:39] <skaet> Riddell,  yup there running,  should be done soon.
[16:39] <skaet> Riddell,  can you confirm debian-cd/CONF.sh set to OFFICIAL  (I think it was done, but just double checking)
[16:40] <Riddell> skaet: I did that yes
[16:41] <skaet> Riddell,  :)   goodness,  was hoping to hear that.
[16:41] <skaet> Riddell,  were all the team notifications on the checklist done as well?  or are some of them still pending?
[16:41] <jibel> scott-work_, dl links added.
[16:42] <scott-work_> jibel: thank you
[16:42] <jibel> yw
[16:42] <Riddell> skaet: mostly, which ones are you looking at?
[16:42] <skaet> Riddell,  OEM and commercial engineering
[16:44] <Riddell> skaet: no I don't think I did those
[16:44] <skaet> Riddell,  ok,  will take care of
[16:45]  * skaet didn't want to pester folks twice if you had
[16:48] <Daviey> skaet: object to another server retwirl + automated testing?
[16:49] <skaet> Daviey,  nope
[16:49] <skaet> Daviey,  want me to kick it off?
[16:50] <Daviey> skaet: no, i'm primed. :)
[16:51] <Riddell> how come Ubuntu DVDs only have ubiquity tests?  do we not care about testing d-i on those images?
[16:51] <skaet> Daviey,  please update the pad as you do it and when they're done, so we can avoid conflicts then.  :)
[16:52] <skaet> Riddell, not sure.  slangasek ^  any thoughts?
[16:53] <skaet> Daviey,  adding the reason for the server retwirl would be appreciated too.
[16:53] <Daviey> skaet: i removed the reasoning.. which was an 'Oppertunity'
[16:54] <jibel> Riddell, there's no d-i on Ubuntu DVDs, it's like a desktop image on steroids
[16:55] <SpamapS> is 20120227 still valid? About to start some iso testing
[16:55] <Riddell> jibel: hmm, interesting, that change didn't happen in kubuntu then
[16:55] <Riddell> jibel: but that explains the smaller dvd size then
[16:56] <Riddell> SpamapS: see http://iso.qa.ubuntu.com/
[16:56] <Riddell> SpamapS: #ubuntu-testing is the best place for testing chatter
[16:57] <Daviey> SpamapS: It's valid 'enough'.. I'm doing a respin to add acpid to the install, but i think the delta is small enough not to invalidate your testing.
[16:57] <Daviey> err, but we are on *28
[16:57] <jibel> Riddell, https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate
[16:59] <jibel> SpamapS, 20120228 is valid until Daviey rebuilds
[17:01] <Riddell> jibel: do you know what this means? "Switch DVD images over to USB seeds: DONE"
[17:02] <ScottK> Riddell: Now you can feel apachelogger's pain about work items. ;-)
[17:02]  * ScottK revels in the irony.
[17:03] <Riddell> hey I never wanted to do the WI system, we kept a full todo list in kubuntu until recently.  it's all rickspencer3's fault :)
[17:08] <skaet> Daviey,  arm server or ubuntu server?
[17:08] <Riddell> skaet: surely that teminology is obsolete, we're all arm now?
[17:09] <skaet> Riddell,  yeah, you're right.  :)  Daivey are you doing the rebuild on arm or on i386/amd64
[17:10] <skaet> if on arm - please hold off, so you don't stomp on the kubuntu preinstalled arm build inprogress
[17:10]  * Riddell doesn't like being stomped on
[17:12] <skaet> Daviey,  looks like it just finished,  if its arm you are ok,  but PLEASE indicate which builds are in progress once you launch them on the pad.
[17:15] <slangasek> Riddell, skaet: we don't have d-i on the Ubuntu DVDs anymore, that was part of the downsizing
[17:15] <skaet> thanks slangasek.
[17:17] <slangasek> mvo: 940240> how do you reach the conclusion that the main upgrade was prevented from running?  the dpkg log shows all the packages being upgraded
[17:18] <ScottK> skaet: So it succeeded?
[17:19]  * ScottK sees no bad news in the inbox.
[17:21] <mvo> slangasek: I logged into the test  vm  and a whole bunch of stuff was not upgraded, but you are right, the dpkg.log shows clearly that another bunch was upgraded successfully
[17:21] <infinity> Riddell: PowerPC images are used, but certainly not in all flavours.  We can/should discuss cutting the set down.
[17:21] <infinity> (That said, we were supposed to have another PPC buildd months ago...)
[17:21] <slangasek> mvo: ok - and those upgraded packages don't show up in the term.log at all :/
[17:21] <Riddell> ScottK: know of any kubuntu ppc users or can that be a quick one to kill?
[17:22] <ScottK> Riddell: Tm_T was the only one I knew of and AFAIK his hardware is dead.
[17:22] <Riddell> my mac died just after canonical stopped supporting it, so that was good timing :)
[17:22] <Riddell> ok I'll look at killing the powerpc kubuntu builds
[17:22] <mvo> slangasek: yeah, its really confusing, I poked around in the system and in the source and have no clue currently why this happens. oddly enough jibel told me that the next run has valid logs
[17:23] <ScottK> Riddell: As long as there's a basic image people can use to install with, the can always apt-get install kubuntu-desktop anyway.
[17:23] <slangasek> heh
[17:23] <ScottK> I don't think we need to worry about extremely non-technical users on powerpc.
[17:23] <slangasek> mvo: but isn't the next run done without the debconf redirection?
[17:24] <skaet> ScottK,  yup 20120228.1 posted now.
[17:26] <Daviey> SpamapS: 28.1 posted
[17:29] <mvo> slangasek: I don't think so, its just a environment that should be valid for the entire life of the test-upgrade and I also don't get how it prevents apt from logging the output unless something in the dpkg-preconfigure for debconf does something crazy
[17:30] <skaet> Daviey,  did you do the arcm builds or not?? - I see 28.1 listed for them but clicking on them doesn't give me an image.   (and arm server images usually take about 50 minutes :P )
[17:31] <Riddell> skaet: in our upgrade tests on the iso tracker should we not have two for each flavour?  upgrade from oneiric and upgrade from lucid?
[17:31] <slangasek> hmm.  where is the hook that's doing the debconf redirect?
[17:31] <skaet> Riddell,  yup good point.   Can you add?
[17:32] <mvo> slangasek: AutoUpgradeTester/UpgradeTestBackendQemu.py - but its just:
[17:32] <mvo> cmd_prefix=['export DEBIAN_FRONTEND=editor EDITOR="cat>>%s";' % debconf_log]
[17:32] <jibel> mvo, slangasek is right. with the redirection is fails and nothing logged excepted packages being removed and without is passes
[17:32] <skaet> stgraber, jibel, ^ see Riddell's point about upgrade testing.
[17:33] <Daviey> skaet: as yet, i've only built i386,amd64
[17:33] <Riddell> I'll fiddle with the tracker :)
[17:33] <jibel> mvo, the current main test passes and I only disabled the capture of debconf prompts. its the same base image
[17:33] <mvo> jibel: right but the same thing works for e.g. server, correct?
[17:33] <stgraber> Riddell: it's taking 8 hours to run all of these tests with only upgrades from Oneiric, upgrading from Lucid too would likely require me to find another machine to run the tests
[17:34] <jibel> mvo, right, other images pass with the redirection enabled
[17:34] <stgraber> Riddell: though I can add the tests cases on the tracker, they just won't get automated results
[17:34] <skaet> Daviey, ack.  marking the arm ones as rebuilding then.   its misleading right now.
[17:35] <slangasek> ScottK, Riddell: were there any changes to kubuntu dependencies around the 24th that could account for the changed LTS upgrade behavior in bug #940396?
[17:35] <ubot2`> Launchpad bug 940396 in update-manager "lucid -> precise main all failed to upgrade: dpkg: dependency problems prevent configuration of kde-runtime" [High,New] https://launchpad.net/bugs/940396
[17:35]  * mvo needs to get dinner now
[17:36] <ScottK> slangasek: Not that I can immediately recall.
[17:36] <slangasek> ok
[17:36]  * ScottK looks
[17:37] <slangasek> jibel: why is this job marked as "failed" when the upgrade seems to have completed? https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/
[17:37] <ScottK> Actually the seeds got a serious rework on the 23rd.
[17:37] <slangasek> ScottK: ah, I'll bet that's it; let me have a peek at those
[17:38] <jibel> slangasek,  "package dpkg is already installed and configured" in apt-term.log
[17:39] <jibel> slangasek, jenkins' UI is confusing, the artefacts  displayed on the summary page are from the last successful run
[17:39] <stgraber> anyone knows what to change to have ".disk/info" in Edubuntu DVD say "12.04 LTS" instead of just "12.04". I believe that's the cause for both the desktop icon and ubiquity not showing the LTS for Edubuntu
[17:39] <slangasek> jibel: oh sorry, I was looking at the latest successful one yes
[17:42] <infinity> stgraber: debian-cd/CONF.sh, perhaps.
[17:42] <infinity>     case $PROJECT in
[17:42] <infinity>       ubuntu|ubuntu-server|kubuntu)
[17:42] <infinity>         DEBVERSION="$DEBVERSION LTS"
[17:42] <infinity>         ;;
[17:42] <infinity>     esac
[17:42] <infinity> stgraber: ^^
[17:44] <slangasek> infinity: security builds are done in a chroot that doesn't use -proposed, right?
[17:44] <infinity> slangasek: Right.
[17:44] <stgraber> infinity: looks like it
[17:44] <slangasek> infinity: heh; then bug #871083 in libpam-modules went away on its own
[17:44] <ubot2`> Launchpad bug 871083 in gzip "gzip -9n sometimes generates a different output file on different architectures" [Medium,Fix committed] https://launchpad.net/bugs/871083
[17:44] <stgraber> infinity: can you add edubuntu to that list?
[17:44] <jdstrand> we don't use -updates either
[17:44] <infinity> jdstrand: I assumed that was what he meant. ;)
[17:44] <slangasek> (we have a fixed gzip, but it wouldn't have been used and it's hard to SRU verify :P)
[17:44] <stgraber> infinity: I'm guessing xubuntu will want to be added too (as they have been approved for a 3 years LTS)
[17:45] <infinity> Oh, that SRU hasn't actually been moved yet?
[17:45] <slangasek> no
[17:45] <infinity> slangasek: Maybe you just fixed it from a distance with a healthy combination of grumbling and angry eyebrows?
[17:45] <slangasek> would it matter to move it, really?
[17:45] <slangasek> infinity: no, the security build was picked up by yellow
[17:45] <slangasek> which didn't give us this problem :)
[17:46] <infinity> stgraber: Can do both, sure.  Are they the only two new LTSen?
[17:47] <stgraber> infinity: yeah, so far, only Edubuntu, Kubuntu and Xubuntu have been approved for community LTS. Ubuntu Studio asked for it last week and it'll be discussed at the next TB meeting
[17:47] <infinity> slangasek: And no, copying the SRU will do us no good in light of the fact that security builds still wouldn't use it.  But perhaps you could talk to the security team about making an exception for a silent security release of gzip too.
[17:48] <slangasek> jdstrand: ^^ do you want gzip in oneiric-security, so security updates to pam don't risk regressing multiarch installability?
[17:48] <ScottK> There has been stuff copied into -security before when it was needed.
[17:48] <infinity> (It's certainly been done in the past when something non-security was needed for security sanity)
[17:48] <infinity> ScottK: Jinx.
[17:48] <jdstrand> yes, we pull back things from -updates as necessary
[17:48] <skaet> stgraber, when did xubuntu get approved for the 3 year LTS?
[17:49]  * skaet is a bit surprised, and notes that it isn't in the manifest. :P
[17:49] <stgraber> skaet: at the TB meeting during the budapest sprint
[17:49] <stgraber> skaet: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000922.html
[17:49] <skaet> thanks stgraber
[17:50] <infinity> stgraber: There isn't an "edubuntu" PROJECT anymore, right?  It's edubuntu-dvd, or something?
[17:50]  * infinity just uses a * instead of hunting.
[17:50] <Riddell> skaet: lucid upgrades added, I missed out wubi, I assume that doesn't do it?
[17:50] <jdstrand> slangasek: yes I would, but I'm not sure when would be the right time-- normally we would just push it out with the update that needed it, but in this case it seems less clear
[17:51] <skaet> Riddell,  not sure,  time to confirm with ev
[17:51] <slangasek> jdstrand: well, next time you're building anything that has a multiarch library in oneiric I guess? :)
[17:51] <jdstrand> slangasek: however, if you give us a package, I'd be happy to build it in our -security only PPAs and copy it to -proposed for you
[17:52] <skaet> ev,  ^  does it make sense to test wubi upgrades from lucid to precise?
[17:52] <slangasek> Riddell, skaet: ev is at a conference today
[17:52] <infinity> jdstrand: It's already in -proposed.
[17:52] <jdstrand> slangasek: when the SRU is approved, we can copy to -updates and -security
[17:52] <skaet> slangasek,  ack.
[17:52] <infinity> jdstrand: And has been for a while. ;)
[17:53] <jdstrand> infinity: meh-- does it pull in anything from -updates? (I missed backscroll)
[17:53] <infinity> jdstrand: Seems pretty unlikely, it's gzip.
[17:53] <jdstrand> I'm thinking about a pocket copy to security
[17:53] <infinity> jdstrand: But we can double-check that it doesn't contaminate.
[17:53] <stgraber> infinity: edubuntu* sounds good, I'm never sure what it's called in the different places ...
[17:53] <jdstrand> I think that would be good (and also unlikely, though a libc update could do it)
[17:55] <slangasek> skaet, Riddell: I didn't think that wubi itself had an upgrade mode, this is just about testing that upgrades work within a wubi install; so if this worked from lucid->maverick, and works from oneiric->precise, I'm not sure an additional wubi lucid->precise upgrade test gets us anything
[17:55] <infinity> jdstrand: Haven't had any libc6 updates in oneiric.
[17:55] <slangasek> Package: gzip
[17:55] <slangasek> Depends: dpkg (>= 1.15.4) | install-info
[17:55] <slangasek> Pre-Depends: libc6 (>= 2.14)
[17:56] <slangasek> that's on precise
[17:56] <slangasek> on oneiric, the deps are similarly small, but with the right libc6 version ;)
[17:57]  * infinity wonders who committed directly to /srv/cdimage.ubuntu.com/debian-cd/
[17:57] <slangasek>  Pre-Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.4.0)
[17:57] <slangasek> 2.4 looks safe
[17:58] <ogra_> re
[18:01] <infinity> stgraber: Alright, CONF.sh updated, as well as make-web-indices.
[18:02] <jdstrand> slangasek, infinity: gzip seems ok to go to -security to me
[18:02] <jdstrand> when is this happening?
[18:02] <slangasek> when do you want it?  at the same time as -updates?
[18:03] <jdstrand> I think that is best. We'll issue a USN for it, but be clear it is not for a vulnerability
[18:03] <jdstrand> slangasek: so I guess can just use '-s' with sru-release and ping me
[18:05] <stgraber> slangasek: I commented in bug 905754 after a quick test of the current image, current behaviour seems reasonable to me considering the number of cities in that area
[18:05] <ubot2`> Launchpad bug 905754 in libtimezonemap "Israel is not on the installer map" [High,Fix released] https://launchpad.net/bugs/905754
[18:11] <slangasek> stgraber: great, thanks for confirming
[18:11] <Riddell> hmm this is getting political "I can confirm one can now select Jerusalem"  Jerusalem is not the capital of Israel
[18:12] <ScottK> According to them it is.  Hard one to avoid.
[18:13] <slangasek> the list of timezones has nothing to do with capitals
[18:13] <Riddell> yes, it's only the rest of he world that doesn't recognise it
[18:14] <ScottK> At a glance it's the only city listed for IST – Israel Standard Time
[18:14] <ScottK> So that's how you'd have to select it.
[18:16]  * Riddell out for the evening
[18:29] <infinity> Seems politically dangerous for the IST key city to be anything but Tel Aviv, but what do I know?
[18:30] <ScottK> It is what it is.  Not up to us.  For us it'd be dangerous to change it from whatever's normal.
[18:35] <jbicha> the EST city is New York, not DC; Jerusalem is a larger city in Israel than Tel Aviv
[18:36] <infinity> Fair enough.
[18:36] <infinity> I get grumpy every time I have to select my timezone as Edmonton. :P
[18:38] <stgraber> hehe, since I switched ISP, geoip thinks I'm in Rainy River, ON so not even the right timezone ;) (it's on CST and I'm on EST)
[18:42] <ogra_> infinity, do you want to be the signoff contact for mx5 or should i ?
[18:42] <ogra_> (you were it in the past)
[18:42] <infinity> I'm fine with it.
[18:43] <infinity> Although, I won't be taking my QuickStart with me to the release sprint.
[18:43] <infinity> So, if the signoff should also be able to test, maybe you. :P
[18:43] <ogra_> heh, i dont even have the HW
[18:43] <infinity> Oh.
[18:43] <infinity> Then me, or Jani.
[18:43] <ogra_> GrueMaster said he would do the tests anyway
[18:43]  * infinity nods.
[18:43] <ogra_> k, adding you as signoff then
[18:43] <infinity> Nothing more than a quick smoketest is needed anyway, it's unsupported.
[18:44] <ogra_> right, like ac100
[18:44] <infinity> I'll happily signoff on both mx5 and ac100, no need to make Kate run around and chase too many people.
[18:44] <ogra_> even though i find the more intresting oem-config bugs in ac100
[18:44] <GrueMaster> I'm the QA guy and I have both rev's of the HW.
[18:44] <infinity> That was very AA.
[18:45] <ogra_> GrueMaster, want to be the signoff contact for both ?
[18:45] <infinity> "My name is Tobin, and I'm a toyaholic."
[18:45] <ogra_> LOL
[18:45] <GrueMaster> I actually figured I would be on the hook for most of Arm testing anyways.
[18:45] <GrueMaster> Sure.
[18:45] <ogra_> k
[18:45] <GrueMaster> Both?
[18:46] <infinity> ogra_: Just make me the signoff.  I'll be in Kate's TZ. :P
[18:46] <infinity> I can bug Tobin for test results if I don't see any, but he's a very responsible isotracker user.
[18:46] <ogra_> ok
[18:46]  * infinity had some other changes to make to the manifest page anyway today.
[18:47]  * GrueMaster considers enrolling in a 12 step program for PC Hoarders.
[18:48] <ogra_> like NCommander ?
[18:48] <ogra_> (well, apparently he at least tries to get rid of some 30yo HW)
[18:48] <skaet> slangasek, thanks.
[18:49] <GrueMaster> I still have my AT&T 3B1 (but Ubuntu doesn't run on it sadly).
[18:50] <ScottK> ogra_: I think NCommander gets rid of it by giving it to GrueMaster.
[18:50] <ogra_> heh
[18:50] <ogra_> i think GrueMaster has enough already
[18:50] <GrueMaster> Well, he is threatening to bring me his IA64 system.
[18:51] <ogra_> be happy he has no s390 in a cabinet
[18:52] <GrueMaster> heh.
[19:32] <SpamapS> If I upload to precise right now, it will just be queued right? Don't want to break beta..
[19:32] <skaet> SpamapS - yes it goes into queue.
[19:32] <skaet> let us know what not to approve.  ;)
[19:33] <skaet> unless its fixing a release critical bug... of course.
[19:33] <Daviey> SpamapS: Why not just hold it until thaw?
[19:33] <SpamapS> Daviey: yeah I think I will.
[19:34] <Daviey> SpamapS: Yeah, it's been the case before that people have uploaded to stage, and some keen reviewer accepted it :/
[19:34] <Daviey> LP doesn't offer a comment facility on the queue. :(
[19:34] <SpamapS> yeah, I'll hold it.
[19:35] <slangasek> from my perspective, it's better for folks to just upload to the queue
[19:35] <slangasek> instead of holding things locally
[19:35] <infinity> Ditto.
[19:35] <infinity> If we choose to accept it, it's because we're respinning anyway.
[19:35] <slangasek> "some keen reviewer accepted it" - then we should teach them not to do that if the packages aren't milestone-critical or safe :)
[19:36] <Daviey> slangasek: you think that will change?
[19:36] <slangasek> what will?
[19:36] <Daviey> slangasek: People will know not to accept something that looks safe?
[19:36] <infinity> The set of people with access to accept from unapproved isn't huge.  You'd think we could socialise this issue a bit better. :P
[19:36] <Daviey> If it's not wanted in beta, why the heck upload during the freeze?
[19:36] <Daviey> O_o
[19:36] <slangasek> it's kinda definitional to the role of release team that you know what the hell you're doing wrt queue accepts
[19:37] <infinity> Daviey: Why have a queue freeze, if we expect people to stop uploading? :)
[19:37] <Daviey> slangasek: So i didn't get bitten twice last cycle?
[19:37] <slangasek> Daviey: don't remember what you're referring to
[19:38] <slangasek> I'm saying that release team members not knowing what they're doing wrt the queue is not a bug to be worked around by not using the queue
[19:39] <Daviey> slangasek: Are you saying that uploads haven't been rejected when they were uploaded during a freeze, but really wanted to be accepted once the thaw happens?
[19:40] <slangasek> no?
[19:40] <slangasek> I'm saying that's not how it's supposed to work
[19:40] <slangasek> and if that has happened, then we need to get people on the same page
[19:41] <Daviey> slangasek: right.. there are two things happening here..
[19:41] <Daviey> 1) People uploading things that *should* wait for post-milestone
[19:41] <Daviey>  - these are either rejected, or just left ignored in the queue.
[19:41] <slangasek> what is this "either"?
[19:41] <slangasek> NOBODY should be rejecting such uploads
[19:42] <slangasek> and if you're seeing them rejected, I want to know why
[19:42] <slangasek> that's inconsistent with how the queue has always been defined
[19:43] <slangasek> the only time a package should ever be rejected from unapproved during development is if it's been reviewed and found to be fundamentally broken and not appropriate to be accepted even after the freeze expires
[19:43] <infinity> I don't start rejecting until final freeze (when I'm rejecting and saying "please upload to proposed")
[19:43] <infinity> Well, yes, and the "broken" case.
[19:44] <infinity> Daviey: During non-final freezes, the unapproved queue should look more like a delay than anything else.
[19:44] <infinity> With the possibility of inclusion in the current milestone, if deemed appropriate.
[19:45] <Daviey> slangasek: I know last cycle there were rejections happening incase a fellow release team member accepted them, as they looked sane.
[19:48] <slangasek> Daviey: that seems unnecessary to me given that only milestone-critical fixes should be accepted during the freeze window
[19:48] <slangasek> and it imposes a greater burden on the developers during the freeze, which is not what we want
[19:49] <slangasek> so I'd really like us to fix that
[19:49] <slangasek> do you recall specifics of who rejected what?
[19:49] <Daviey> slangasek: Okay, well there seems to be inconsistencies, regardless.
[19:49] <Daviey> slangasek: give me a minute
[19:53] <ScottK> The bigger problem I've seen with the queue is developers uploading to the queue pending FFe approval and then when the queue thawed it got auto accepted because no one rejected it.
[19:53] <slangasek> yes, that's certainly a problem
[19:53] <slangasek> and falls under "not appropriate to be accepted even after the freeze expires"
[19:53] <ScottK> Yes
[19:53] <slangasek> so we could do with some clarification there as well for developers, I think
[19:53] <ScottK> I also think there's room for "Low risk and we're respinning anyway" accepts.
[19:54] <slangasek> well, I wouldn't expect any member of the release team to accept such a thing without having talked to the uploader to confirm it's considered safe for inclusion
[19:55] <slangasek> precisely so that we *don't* get caught out by an uploader thinking they've staged something for after the milestone only to have it included
[19:56] <ScottK> In that case I may be slightly guilty (last cycle, not this one)
[19:57] <skaet> Daviey, infinity - armel+omap armel+omap4 armhf+omap - don't think these should be considered supported for 5 years.   separate line?
[19:58] <Daviey> skaet: I raised that.. honestly, i don't know.
[20:02] <infinity> skaet: Oh, in netinst?  The armel ones shouldn't be.  I'll move them.
[20:02] <skaet> thanks infinity.
[20:03] <infinity> (they will be anyway, mind you, so the point is more academic than anything)
[20:04] <skaet> infinity,  its what we're doing 2 years from now with them I'm concerned about.  (point releases,etc.)
[20:04] <infinity> skaet: Yes, and they'll be just as supported as armhf+same.
[20:04] <infinity> skaet: Because the kernels are identical, as are the d-i bits.
[20:04] <infinity> skaet: So, anything we fix on one fixes the other by accident. :P
[20:04] <infinity> skaet: Hence my point that the distinction is academic.
[20:05] <infinity> (But worth noting anyway)
[20:05] <skaet> slangasek, ScottK - and put it on the pad that that's being done,  so surprises being minimized please.
[20:05] <ScottK> OK.
[20:05]  * ScottK didn't do anything recently.
[20:05] <skaet> :)
[20:07] <Daviey> infinity: I think it's more about setting expectations for SRU's IMO..
[20:08] <infinity> Daviey: Yes, I know.  But in this very specific case, it's purely academic.
[20:08] <infinity> Daviey: We're not going to magically release an SRU that breaks armel+omap4 (for instance) while preserving armhf+omap4, because the code is literally identical (at the kernel and d-i/netboot level).
[20:09] <Daviey> ahh, right
[20:09] <infinity> Daviey: At the userspace level, armel support may well flag over time, if something fails to build and no one cares why (though that still seems unlikely)
[20:09] <infinity> Daviey: But at the netboot level, they're symlinks into each other.  They are precisely identical. :)
[20:10] <Daviey> hah
[20:10] <infinity> Anyhow, I still think there's plenty of value in communicating the "armel isn't supported" bit, so I've updated the manifest to communicate that.
[20:11] <Daviey> rocking
[20:12] <infinity> I wonder if maybe I should change "unsupported" to "best-effort" or something less harsh (thinking of the ac100 and mx5 "community kernels" here).
[20:12] <infinity> But, meh.
[20:12] <infinity> unsupported is accurate for a technical/release document.
[20:12] <infinity> For the release notes, we might want to soften it (if we mention those subarches at all).
[20:12] <infinity> s/notes/announcement/
[20:13] <Daviey> infinity: lets create a working group to define the difference between 'unsupported', 'best-effort', 'community supported' and 'technical preview'
[20:13] <skaet> infinity,  same wording as we use for unseeded packages in universe is probably appropriate.
[20:13] <skaet> for the announce
[20:14] <skaet> for the manifest - lets standardize on community supported and technical preview as appropriate.
[20:15] <infinity> skaet: If you want to change my "unsupported" to "community supported", be my guest.  Though I think the former is slightly more accurate for the ones I marked. :P
[20:15] <infinity> (Again, academically accurate anyway, in practice, nearly everything gets "supported" on some level or other... Until it doesn't)
[20:17] <skaet> infinity - hadn't seen your latest...  not fussed by it at this point.
[20:17] <infinity> skaet: :)
[20:19] <skaet> Daviey - arm server rebuild done?
[20:19] <skaet> (or even started yet?)
[20:19]  * skaet not seeing anything in the processes
[20:20] <skaet> stgraber,  jibel - any must fix bugs we're looking like we need to respin for,  from your perspective, or are we opportunity only now?
[20:21] <skaet> slangasek, ^ ?
[20:28] <Daviey> skaet: no, i didn't do that.. should i?
[20:30] <infinity> If it's just for acpid, don't bother.
[20:30] <Daviey> infinity: Does arm even have acpi?
[20:31] <infinity> Daviey: The userspace tools?  Sure.  Actual ACPI implementations on any SoCs?  Not yet. :P
[20:31] <skaet> Daviey,  you'd marked it on the pad - if mistake.  that's fine,  just want to get clean viewpoint.
[20:31] <Daviey> skaet: did i?
[20:31] <infinity> That [19] is someone's.
[20:31] <Daviey> skaet: On the pad, i marked Ubuntu Server and Ubuntu Cloud Images. :/
[20:31] <infinity> I've lost colour history. :/
[20:31] <infinity> Anyhow, let me end the debate with 4 ctrl-Hs.
[20:31] <skaet> he had it as [1] initially - I just changed it to [19]
[20:32]  * skaet trying to keep numerical track of issues - reusing numbers in a release foils my attempts
[20:32] <infinity> There.  No need to respin. ;)
[20:32] <infinity> Problem solved!
[20:32] <skaet> infinity,  :)
[20:33] <Daviey> skaet: Ah, ok - i thought it was safe to recycle numbers.  But i didn't add the number to Ubuntu ARM*.. not looked at the history to see who did
[20:35] <ScottK> infinity: What archs is kubuntu-active built for according to cdimage?
[20:36]  * infinity checks.
[20:36] <stgraber> skaet: there are a few ubiquity bugs I'm looking at but none should be critical
[20:37] <infinity> ScottK: Just i386, according to default-arches.
[20:37] <ScottK> Hmmm.
[20:37] <infinity> ScottK: Not sure why Riddell set it up that way.  Maybe just for testing purposes (since he still doesn't have it working)
[20:38] <ScottK> OK then.  Any idea about http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-active/precise/daily-live-20120228.log then?
[20:38] <ScottK> You just shot my theory down.
[20:39] <infinity> ScottK: Yeah, I imagine somewhere the image type is listed as "active" when it should have been "live" or "desktop" or some such.
[20:39] <ScottK> Sigh.
[20:39] <ScottK> where's the public cdimage branch again?
[20:39]  * ScottK pulls out grep.
[20:40] <infinity> bin/publish-daily:			kubuntu-active)
[20:40] <infinity> bin/publish-daily:				TYPE=preinstalled-active
[20:40] <infinity> bin/publish-daily:			kubuntu-active)
[20:40] <infinity> bin/publish-daily:				TYPE=active
[20:40] <infinity> I'm betting it's there.
[20:41] <ScottK> Should be type preinstalled?
[20:41] <ScottK> Well, not for i386
[20:41] <ScottK> That should be live I guess
[20:41] <infinity> The second one should be "desktop"
[20:42] <ScottK> Ah.
[20:42] <infinity> The first should be preinstalled-desktop, probably.
[20:42] <ScottK> Wanna give it a shot?
[20:42] <infinity> Actually, just removing the kubuntu-active stuff entirely and letting the cases fall through to *) should fix it.
[20:43]  * infinity does.
[20:43] <ScottK> Thanks.
[20:43] <skaet> ScottK,  infinity - Riddell set it up that way out of respect for the arm server resources at my request...
[20:44] <infinity> skaet: That doesn't explain why it doesn't build on amd64. ;)
[20:44] <ScottK> skaet: Not building any images does conserve resources.
[20:44] <infinity> But either way, one arch is fine for testing.
[20:44] <skaet> infinity,  true.  :)
[20:44]  * skaet fixated on the long time it takes to rebuild all our arm images.   :P
[20:45] <infinity> ScottK: Retrying cron.daily-live for kubuntu-active.  Let's see if it works any gooder.
[20:45] <ScottK> Thanks.
[20:46] <skaet> ScottK,  image hasn't built yet - wanted it cleaned up and working well on fast rebuild architecture before we considered any other spins. :P   It was added after feature freeze....
[20:46] <infinity> (Maybe I'll check back after I have some lunch, I just realised how late it is)
[20:46] <ScottK> skaet: Right, I'm just trying to get it working on i386 (per the note on the pad)
[20:48] <slangasek> curious, who needs acpid for what?
[20:48] <skaet> ScottK,  :)
[20:48] <skaet> slangasek,  Daviey, server respin.   cleaning up cruft now
[20:48] <slangasek> I thought acpid was on its last leg, I'm surprised to see server pulling it in
[20:49] <skaet> slangasek,  anything that should be added from your perspective?
[20:49] <skaet> ie.  any blockers we're expecting fixes for shortly.
[20:49] <slangasek> skaet: no - are you and jibel happy with the set of outstanding ubiquity bugs?
[20:50] <skaet> slangasek, bit concerned about autotesting of updates from lucid failing.
[20:50]  * skaet not thrilled at some of the bugs - but doesn't think fixes will emerge out of thin air either
[20:51] <slangasek> well, upgrade bugs generally don't/shouldn't require a CD respin
[20:56] <Daviey> slangasek: kvm cannot be rebooted without acpid.
[20:56]  * slangasek blinks
[20:57] <Daviey> slangasek: suprised?  This has been known since at least Hardy :/
[20:57] <Daviey> slangasek: I mean via libvirt.
[20:57] <slangasek> oh, because libvirt is generating an acpi powerbutton event?
[20:59] <Daviey> right!
[20:59] <slangasek> yeah, that makes sense
[20:59] <slangasek> so acpid had fallen out of the seed?
[21:22] <infinity> ScottK: So, that produced some sort of ISO.  No idea if it works, but there it is. ;)
[21:22] <infinity> ScottK: http://cdimage.ubuntu.com/kubuntu-active/daily-live/20120228.1/
[21:26] <infinity> ScottK: Obviously the pretty headers need some work to make them more informative (and prettier), but whatever.  That's cosmetic.
[21:27] <ScottK> \o/
[21:27] <ScottK> Riddell: ^^^
[21:28] <ScottK> infinity: Thanks again.
[21:31] <infinity> ScottK: NP.
[21:59]  * infinity should have actually eaten lunch instead of making tax-related phone calls. :/
[22:34] <skaet> infinity,  https://bugs.launchpad.net/launchpad/+bug/885739 - code branch on hold for merging :D
[22:35] <ubot2`> Launchpad bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,Triaged]
[22:37] <stgraber> skaet: looks like that's just the DB part so far, there isn't any actual code change that I can see in there
[22:38] <skaet> stgraber,  its progress though... but thanks for letting me know I shouldn't get too excited.  :)
[22:41] <stgraber> skaet: it'd be great to have it for final freeze but otherwise we can probably survive till 12.10 :)
[22:43]  * skaet not so sure about that.... ;)
[22:44] <Riddell> ooh infinity, how did you fix it?
[22:44] <infinity> Riddell: Removed the kubuntu-active special-casing from publish-daily.
[22:44] <infinity> Riddell: You were claiming they were type "active" and "preinstalled-active" which was patently untrue, they're *desktop images.
[22:45] <Riddell> that would be because they were type mobile for kubuntu-mobile
[22:45] <infinity> Yeah, probably.  The world has moved on since then. ;)
[22:48] <infinity> Riddell: There may be other places where those assumptions could use a tidying.  I'll re-review your commits later with that in mind.
[22:48] <Riddell> lovely, thanks infinity
[22:48] <infinity> Riddell: But at least x86ish desktop stuff should build and publish well enough to test.
[23:15] <GrueMaster> Any ETA on the arm server images?
[23:26] <skaet> stgraber, https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/942836 - you aware of this one?
[23:26] <ubot2`> Launchpad bug 942836 in xorg "unity does not appear" [Undecided,Confirmed]
[23:27] <skaet> GrueMaster, all arm server images should be up on the tester.
[23:27] <GrueMaster> "Download	Ubuntu Server armhf+omap4 (rebuilding)" is what I see.
[23:27] <skaet> hmm... except for server - it appears.   looks like something needs to be cleanded up there.
[23:28] <skaet> in the backscroll,  I think I saw that Daviey and infinity agreed it didn't need respin for acpid - so the prior version should be good.   I'll reset the iso tracker to that now.
[23:29] <GrueMaster> ok, thanks.
[23:31] <skaet> GrueMaster - looks like we have link problems there to that entry too... :P
[23:32]  * skaet checking on details...
[23:33] <slangasek> acpid's not relevant on armhf images, no
[23:33] <skaet> hmmph...  there are 20120228.1 images.
[23:33] <skaet> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20120228.1/
[23:35]  * infinity notices that he forgot to clean up armel+ac100 from cdimage.
[23:35] <infinity> La la la.
[23:40] <GrueMaster> infinity: ogra wanted to keep that image as we don't have armhf video drivers.
[23:40] <infinity> GrueMaster: Oli and I discussed it.
[23:41] <infinity> (As did others)
[23:41] <infinity> GrueMaster: I already disabled it, just didn't remove the cruft.
[23:41] <GrueMaster> Ok.  I wasn't in that conversation I guess.
[23:43] <GrueMaster> slangasek: acpid is not used on arm, but it shouldn't warrant a respin either.
[23:43] <slangasek> yes, the respins were about getting acpid *into* images
[23:44] <skaet> GrueMaster,  links should work now
[23:45] <skaet> jibel, stgraber - don't quite think I set the links up correctly (used current, am thinking there should be a substitution variable), can you review/fix for ubuntu server armhf images when you get a chance.
[23:46] <GrueMaster> Can someone release openjdk-6-jre-libs?  My netboot images require it for testing (jenkins).
[23:47] <infinity> GrueMaster: Release it from where?
[23:48] <skaet> yeah,  not seeing it in unapproved.... ?
[23:48] <infinity> Nor new.
[23:48] <GrueMaster> I'm seeing package skew.  Just a sec.
[23:48] <infinity> Is it arch:all?
[23:49] <infinity> openjdk-6 was FTBFS on i386.
[23:49] <GrueMaster> (might be my local mirror, but doubtful).
[23:49] <slangasek> it is :all
[23:49] <infinity> Then that's the issue.
[23:49] <slangasek> and it's *not* FTBFS on i386, but it is on arm*
[23:49] <infinity> slangasek: Err, LP tells me a different story.
[23:49] <infinity> https://launchpad.net/ubuntu/+source/openjdk-6/6b24-1.11.1-3ubuntu1
[23:50] <GrueMaster> Same here when I checked yesterday.
[23:50] <slangasek> oh heh
[23:50] <slangasek> no, it's only FTBFS on x86 and builds on arm* and powerpc
[23:50] <infinity> Right.
[23:50] <skaet> infinity, slangasek, NCommander - will be afk for a good part of my evening.  Will check on things tonight.   Pad is up to date - please log any changes to the pad.
[23:50] <slangasek> sorry, this was such an unlikely outcome that I didn't compare the version numbers
[23:50] <infinity> Which means no new arch:all bits. ;)
[23:50] <slangasek> skaet: ok
[23:50] <skaet> thanks!  :)
[23:50]  * skaet --> afk
[23:51] <infinity> slangasek: On behalf of every ports maintainer and user everywhere: THPT!!
[23:51] <infinity> Or something.
[23:51] <GrueMaster> +1
[23:52]  * infinity so rarely gets these opportunities.
[23:52] <GrueMaster> heh
[23:53] <GrueMaster> Although to be fair, I think it builds on arm (and other ports) is we disable something like 90% of the post-build tests.
[23:54] <infinity> Shh.
[23:54] <GrueMaster> :-|
[23:59] <GrueMaster> Links (or at least versions) for ubuntu-core need to be updated on the iso tracker.  Most are 20120228, one is 20120228.1.