[00:22] <micahg> is an AA is around, libav-extra could use a binary NEW review in quantal (breaking upgrades)
[00:47] <stgraber> ScottK or any other SRU team member who's around: I just marked bug 1032256 verification-failed and the above upload should fix the problem, would appreciate if someone could quickly review and let it in
[00:47] <ubot2> Launchpad bug 1032256 in edubuntu-artwork "Incorrect menu items appear in Edubuntu due to incorrect path in debian/edubuntu-artwork.install" [Medium,In progress] https://launchpad.net/bugs/1032256
[00:47] <stgraber> diff should be an obvious one liner (/me checks the diff in the queue)
[00:50] <stgraber> yep, diff is indeed a one liner ;)
[01:15] <stgraber> slangasek: hmm, do you know what's supposed to happen with the firefox-locale-XYZ packages in -proposed? they are built from the same sources as the langpacks, but they haven't been copied to -updates and weren't mentioned on that wiki page dpm mentioned
[01:18] <stgraber> it also looks like firefox-locale-km is in universe instead of main
[01:20] <infinity> I can fix the latter issue.
[01:23] <infinity> stgraber: Override for firefox-locale-km fixed, and edubuntu-artwork accepted.
[01:23] <stgraber> infinity: thanks
[01:26] <infinity> micahg: Accepted.
[01:28] <infinity> Hrm, I should refresh the quantal chroots tonight, they're getting a bit old.
[03:30] <stgraber> cjwatson: yay! that new getAllPermissions API just landed and it just took a couple of minutes to get the data I wanted. thanks!
[03:32] <stgraber> cjwatson: http://people.canonical.com/~stgraber/ppu/ppu-report is the result for the data I wanted (people with PPU)
=== iulian is now known as Guest97017
[03:57] <micahg> stgraber: infinity: the firefox-locale-* were from the Firefox SRU, not the langpack update
[03:57] <micahg> infinity: thanks for the accept
[04:58] <slangasek> stgraber: no, don't know anything about firefox-locale-* :/
[05:09] <micahg> slangasek: see my statement above :)
[07:02] <didrocks> the unity stack should be good to copy to the release pocket (I can do it myself if needed): bamf, dee, libunity, unity, nux, unity-lens-applications, unity-lens-files, unity-lens-music
=== tjaalton_ is now known as tjaalton
[07:35] <TheDrums> Much chance for a mosh backport?
[07:35] <micahg> TheDrums: see requestbackport script in ubuntu-dev-tools (followup in #ubuntu-motu if need be)
[07:37] <TheDrums> Suppose I was more wondering if it was already on the "agenda", though thanks.
=== Guest97017 is now known as iulian
[07:52] <micahg> TheDrums: happy to discuss in -motu
[09:04] <cjwatson> stgraber: great, you're welcome
[09:10] <xnox> I'd like to nominate bug 699802 for precise & quantal.
[09:10] <ubot2> Launchpad bug 699802 in grub2 "error:: no video mode activated" [Medium,Confirmed] https://launchpad.net/bugs/699802
[09:10] <xnox> or is it too late for precise, especially 12.04.1?
[09:10] <seb128> xnox, hard freeze is thursday for 12.04.1
[09:11] <xnox> seb128: thanks.
[09:11] <seb128> so you still have a slot if you convince people the fix should really make it
[09:11] <xnox> cjwatson: what do you think about this comment https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/699802/comments/24
[09:11] <ubot2> Ubuntu bug 699802 in grub2 "error:: no video mode activated" [Medium,Confirmed]
[09:12] <xnox> i hit this bug myself with crypt+lvm in VM with ubiquity testing
[09:17] <cjwatson> The problem about copying those is that they're fairly large
[09:18] <xnox> =(
[09:18] <cjwatson> But I suppose it's acceptable in the absence of a new enough GRUB to have LUKS support
[09:18] <cjwatson> So go ahead if you want to get that sorted out and tested
[09:19] <xnox> ok
[09:19] <cjwatson> I agree it's a fairly unfortunate bug in that it confuses people
[09:21] <didrocks> cjwatson: hey, did you see above my reminder about the unity stack copy? (I can do it if needed)
[09:21] <cjwatson> I'll do it now, thanks
[09:22] <didrocks> thanks :)
[09:23] <cjwatson> done
[09:28] <didrocks> thanks colin!
=== doko_ is now known as doko
=== yofel_ is now known as yofel
[11:58]  * cjwatson fixes the bogus uninstallables on server images, hopefully for good this time
=== ralsina_ is now known as ralsina
[14:11] <mvo_> could someone from the sru team review the glib-networking sru in precise-proposed? it will unblock all users who need "3dsecure" when purchasing applications via software-center
[14:14] <stgraber> mvo_: is that critical for 12.04.1? if not, it's going to wait there until we enter final freeze on thursday
[14:15] <mvo_> ok stgraber, thanks for the update
[14:55] <stgraber> micahg: oops, my bad (wrt firefox-locale-), not sure where I saw langpack as the source... checking again it's quite clearly coming from firefox :)
[15:16] <stgraber>  I changed that early PPU-specific script into a more generic one reporting all team and individual upload rights at: http://people.canonical.com/~stgraber/permissions
[15:16] <stgraber> I guess that output may be interesting for people outside of the DMB
[15:24] <stgraber> slangasek: so, jibel confirmed that the SRUs I pushed last week to fix the upgrade path are fine and don't show any regression on the automated testing. Should we have them moved to -updates now?
[15:26] <jibel> stgraber, this time auto upgrade *really* upgrades with proposed enabled. I retested the cdrom/no-network upgrade this morning manually
[15:59] <warp10> join #d-a-t
[15:59] <warp10> ops... missed '/', sorry
[16:37] <infinity> cjwatson: Looking at stgraber's PPU permissions dump, why does -core-dev have explicit permissions on a bunch of packagesets, when it already has implicit permissions via components?
[16:38] <Laney> the DMB is going to get that fixed
[16:38] <infinity> Laney: Ahh, I assumed it was perhaps something technical, rather than DMBish.
[16:39] <infinity> (Like, perhaps implicit permissions showing in the dump due to group memberships?)
[16:39] <cjwatson> err, isn't it just because ... what infinity said
[16:39] <Laney> stgraber told me that it's only showing direct permissions
[16:39] <cjwatson> oh, maybe that was part of my initial ->packageset conversion
[16:40] <cjwatson> ubuntu-core-dev might be the owner of those sets
[16:40] <Laney> and it's only the first-ish packagesets
[16:40] <Laney> so I suppose it's just something wot woz dun back at the start
[16:40] <cjwatson> that does look a bit odd
[16:40] <infinity> Not that there's anything "wrong" with it, per se, it just makes it a bit harder to parse.
[16:41] <cjwatson> core, desktop-core, and ubuntu-server don't have any other permissions
[16:41] <cjwatson> (IIRC)
[16:41] <cjwatson> but the others have no excuse, and even in those cases, there's no reason packagesets have to have permissions attached as such
[16:41] <Laney> server is ubuntu-server-dev
[16:41] <infinity> cjwatson: Server has ~ubuntu-server-dev
[16:41] <infinity> Laney: Jinx.
[16:41] <cjwatson> ah yes
[16:41]  * cjwatson amends coe
[16:41] <cjwatson> *code
=== skaet_ is now known as skaet
[16:42]  * Laney nominates infinity to the DMB due to clearly demonstrated interest and knowledge
[16:42] <infinity> Laney: Half of that assertion is true.
[16:43] <Laney> Do mobile/unr/netbook have any continuing relevance?
[16:44] <cjwatson> Doubt it.
[16:44] <infinity> cjwatson: It also misses the partner relationship.  Is that handed at a sketchy spot earlier in the soyuz upload pipeline, rather than via PPUish/ArchiveReorg machinery?
[16:44] <infinity> handled*
[16:44] <micahg> isn't partner just another pocket?
[16:45] <infinity> micahg: Sort of.
[16:45] <infinity> micahg: And pocket rights are represented in this dump (see backports and security).
[16:45] <micahg> infinity: less visible pocket :)
[16:46] <infinity> Partner is a bit weirder, in that it's published to a parallel archive, but I'm not sure how much of that is a publisher construct, and how much of that is (perhaps mistakenly) represented in structure elsewhere.
[16:46] <cjwatson> Partner is more like a component than a pocket.
[16:46] <cjwatson> Which ends up in a different archive, yes.
[16:47] <cjwatson> Partner upload permissions are just component upload permissions.
[16:47] <cjwatson> edit-acl -c partner query
[16:47] <infinity> Right, but not represented in this dump, for some reason.
[16:47] <cjwatson> I don't think stgraber included component permissions.
[16:47] <infinity> === motu ===
[16:47] <infinity>  - Archive Upload Rights: component 'multiverse'
[16:47] <infinity>  - Archive Upload Rights: component 'universe'
[16:48] <cjwatson> Oh, he did.  Odd then.
[16:48] <cjwatson> Ah, I know
[16:48] <infinity> Maybe he just only queried the 4 components.
[16:48] <cjwatson> I bet those permissions are on a different Archive
[16:48] <cjwatson> They would kind of have to be
[16:48] <infinity> Or that, yeah.
[16:48] <cjwatson> And stgraber's query was Archive.getAllPermissions()
[16:48] <infinity> Anyhow, not a big deal.
[16:49] <cjwatson> So he just needs to run it on all of lp.distributions["ubuntu"].archives, rather than just [0]
[16:49] <micahg> well, partner is irrelevant for the DMB as well
[16:49] <cjwatson> stgraber: BTW your login_with in that script is wrong :)
[16:49] <infinity> micahg: Indeed, entirely irrlevant, was just a curiosity. ;)
[17:00] <slangasek> stgraber: https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/ shows an awful lot of yellow; have these been checked over and confirmed to not be regressions?
[17:00] <slangasek> stgraber: as long as that's done, I'm happy to consider those packages v-done and copy them over, yes
[17:06] <stgraber> infinity, cjwatson: I was only looking at .archives[0] not .archives[1], I'll change that so partner shows up too
[17:07] <stgraber> cjwatson: oh, indeed, bad copy/paste, will fix the login_with ;)
[17:07] <infinity> stgraber: I'm not sure it's important that partner shows up (as pointed out, it's irrlevant to most people), I was curious why it wasn't there, though.
[17:07] <stgraber> slangasek: the yellow is because of conffiles left around and other unrelated failures, jibel says that the upgrade at least works
[17:08] <stgraber> infinity: well, checking partner will probably make the cron 5s slower and it's quite easy to change, so might as well ;) the initial script was specifically written to spot inconsistency with PPU in the primary archive, but it evolved into a generic dump-everything script without that bit of the code being changed
[17:18] <xnox> Anyone has a spare intel matrix raid controller?
[17:21] <stgraber> no spare ones, sorry
[17:22] <xnox> stgraber: can you test that at least an existing array can be assembled / activated using precise-proposed mdadm package without dmraid package present
[17:24] <slangasek> xnox: is that the correct test?
[17:24] <slangasek> I thought the point was we were *not* using mdadm for imsm
[17:24] <slangasek> because dmraid has already claimed it and if we're going to change that we need a migration plan
[17:24] <xnox> slangasek: true, but I still want to find out whether or not we can use mdadm for imsm.
[17:24] <stgraber> xnox: I'd have to check if I have another machine with one, the one I know has one is my server here and has all 4 ports used with standalone non-RAID drives. (I have an HP smartarray P212 for the various RAID arrays)
[17:25] <slangasek> xnox: you mean whether it can be used by hand?  (since the udev rules won't do it)
[17:25] <xnox> slangasek: and then see how to migrate from dmraid to mdadm. Yes, by hand.
[17:25] <slangasek> ok
[17:27] <xnox> slangasek: from https://bugs.launchpad.net/ubuntu/precise/+source/mdadm , the bug 1002357 is the last one not marked as verification-done. Do you think it's enough to be marked as done?
[17:27] <ubot2> Launchpad bug 1002357 in mdadm "sort out udev rules madness (3 editions installed into 4 files)" [Medium,Fix committed] https://launchpad.net/bugs/1002357
[17:41] <slangasek> xnox: yep, I'm happy with that
[17:42] <xnox> slangasek: in that case it's all green \0/
[17:43] <slangasek> huzzah
=== tyhicks` is now known as tyhicks
[18:11] <slangasek> jibel, stgraber: the lucid main amd64 upgrade test has been consistently failing for the past several days, which means we aren't actually getting any confirmation of a successful upgrade to -proposed for this test case: https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/
[18:11] <slangasek> jibel: is this on your radar?  fixable soon-ish?
[18:14] <stgraber> jibel: oh yeah, I think jibel mentioned the lack of the -d parameter to do-release-upgrade
[18:15] <stgraber> slangasek: ^
[18:15] <stgraber> slangasek: jibel's comment regarding the testing of these fixes is https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1029531/comments/19 (not sure whether you saw it already)
[18:15] <ubot2> Ubuntu bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,Fix committed]
[18:29] <skaet> slangasek, stgraber - are we still good to switch from -proposed to -updates for the precise dailies today?
[18:30] <stgraber> skaet: we should be once we do a bunch of copies for the upgrade changes. I'm also working on doing verification testing for a bunch more stuff in the queue
[18:30] <stgraber> skaet: I'll probably come up with a list of known-safe things in the queue that we may want to copy before the 7 days limit
[18:32] <slangasek> stgraber, skaet: yes, once the CD upgrade fixes are published to -updates I think it's fine to switch
[18:32] <slangasek> there's also bug #1034668, but that seems to have not involved a CD upgrade
[18:32] <ubot2> Launchpad bug 1034668 in indicator-appmenu "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [High,Triaged] https://launchpad.net/bugs/1034668
[18:35] <skaet> stgraber, slangasek,  ok,  thanks.
[18:37] <skaet> re:  103466 - ack.
[18:41] <jibel> slangasek, re precise-upgrade-lucid-main/ARCH=amd64. It was a problem with our proxy in the lab. I fixed it this morning and restarted the job 9h 6 minutes ago, and still running (it usually runs in 8h or so)
[18:42] <jibel> it seems to be stuck on "Processing triggers for postgresql-common"
[18:42] <slangasek> jibel: ah, ok.  is it actually stuck?
[18:43] <jibel> slangasek, it must have heard your incantation, it just finished :)
[18:43] <jibel> dist-upgrade.py returned: 0
[18:43] <jibel> slangasek, https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/203/
[18:44] <slangasek> jibel: huzzah, thanks
[18:46] <stgraber> please reject network-manager from the unapproved queue
[18:46] <stgraber> I just found and tracked down a pretty nasty bug that cyphermox is going to fix before we attempt to SRU again
[18:46] <stgraber> (dnsmasq not being allowed to reply to NM, leading to NM reaching the maximum number of established dbus connection after a day or so, freezing the system bus)
[18:47] <infinity> stgraber: Done.
[18:47] <infinity> stgraber: dnsmasq is fine to leave there?
[18:47] <stgraber> yep
[18:47] <cyphermox> infinity : as far as I'm concerned you might as well reject that one too
[18:48] <cyphermox> we'll put in another patch to allow NM to use it's own custom bus name
[18:48] <infinity> I feel like I'm getting mixed messages. ;)
[18:48] <stgraber> cyphermox: oh right, because you want to get the new dbus parameter stuff in there, right
[18:48] <stgraber> yeah, reject both then :)
[18:48] <cyphermox> upstream is finishing up on testing that patch, and it will be in quantal prior to FF... or at least, that's the plan
[19:01] <stgraber> slangasek: hmm, looks like the fix for bug 1017822 doesn't work here... trying to figure out exactly why though. Would still be tempted to have it copied regardless, assuming it's no worse than it used to (as the other bugfix is the one we want for 12.04.1)
[19:01] <ubot2> Launchpad bug 1017822 in fglrx-installer-updates "[quantal] fglrx fails to build on i386" [High,Fix committed] https://launchpad.net/bugs/1017822
[19:03] <stgraber> hmm ... or my setup was just bad ... just cleaned up the system and retried and it now works...
[19:09] <stgraber> right, re-tested both packages, seems to be building fine. Marked verification-done, so fglrx and fglrx-updates should be good to go.
[19:09] <slangasek> ok then :)
[19:18] <stgraber> with my Edubuntu hat on, I'd be happy to see edubuntu-artwork copied to -updates without waiting an extra 7 days. The original SRU was a bit broken and I fixed it and tested yesterday. The fix was a one word fix in a .install file.
[19:39] <infinity> stgraber: Yeah, I'm okay with fast-tracking that one.
[19:43] <slangasek> stgraber: did we conclude that the OOo SRU was or wasn't needed?
[19:44] <stgraber> slangasek: I didn't have to seed it in the end, so it might be helping in some cases but none of those we identified. In short, I'd go with not needed.
[19:44] <slangasek> ok, I'll drop it from -proposed again
[19:47] <slangasek> stgraber: bug #1029021 got a regression-test with the lucid->precise upgrade case?
[19:47] <ubot2> Launchpad bug 1029021 in apt-clone "python implementation of apt-clone should remove usernames and passwords" [High,Fix committed] https://launchpad.net/bugs/1029021
[19:47] <slangasek> (which was what triggered a re-upload last week)
[19:47] <infinity> stgraber: edubuntu-artwork released.
[19:47] <stgraber> infinity: thanks
[19:48] <stgraber> slangasek: right, we know that at least the export function works as expected (didn't crash)
[19:48] <slangasek> ok
[19:48] <slangasek> releasing the SRUs for update-manager, apt-clone, launchpad-integration, nspr, update-notifier
[19:49]  * stgraber pokes queuebot 
[19:49]  * skaet notes that...
[19:50] <infinity> stgraber: queubot won't tell you about sru-releasing.
[19:50] <stgraber> infinity: oh right, because you can do it in one go now
[19:51] <infinity> stgraber: Yeah, it bypasses the queue and just DTRT now.
[19:51] <stgraber> I got used to seeing the package land in -updates Unapproved
[19:51] <slangasek> oh neat, I got an oops-by-mail for one of the package copies
[19:51] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=by
[19:51] <infinity> ubot2: That was some VERY clever parsing, bravo.
[19:51] <ubot2> infinity: Error: I am only a bot, please don't think I'm intelligent :)
[19:51] <slangasek> heh
[19:54] <stgraber> skaet: will switch to -updates + kick respins at 21:00 UTC. Will see if I can do some more verification testing before that
[19:55] <skaet> stgraber,  sounds good.   :)   Thanks.
[19:58] <stgraber> tjaalton: ping
[20:15] <tjaalton> stgraber: pong
[20:16] <stgraber> tjaalton: hey, do you have someone you can poke to get bug 1031784 tested?
[20:16] <ubot2> Launchpad bug 1031784 in mesa "Artifacts on screen with ivy bridge" [Critical,In progress] https://launchpad.net/bugs/1031784
[20:16] <stgraber> at least the xserver-xorg-video-intel part of it?
[20:16] <tjaalton> it needs both mesa and -intel
[20:17] <stgraber> it sounds like something that we really should have on the 12.04.1 release media as ivy bridge is getting quite common these days
[20:17] <tjaalton> don't think just -intel would help much
[20:17] <stgraber> hmm, ok...
[20:17] <tjaalton> it's only GT1 chips, so the slower ones
[20:17] <tjaalton> but still..
[20:17] <stgraber> do you have any way of getting the current mesa in -proposed tested?
[20:18] <stgraber> according to the pending-sru report, the one currently in -proposed didn't get much testing
[20:18] <stgraber> once that one is out, the ivy bridge fix seems trivial and should be easy to test and get to -updates
[20:18] <tjaalton> bryce ran some piglit tests but they showed some regressions, which looked surprising. I promised to have another look at testing with my hw, but didn't get to it today
[20:19] <tjaalton> there's also 8.0.4 available, I'd also test that to see if it helps with the regressions
[20:19] <tjaalton> and 8.0.5 scheduled later this month
[20:20] <tjaalton> one option would be to push 8.0.3.really.8.0.2-0ubuntu0.1 with the ivb patch
[20:20] <stgraber> as ugly as that version number is, I think I'd prefer that for 12.04.1
[20:20] <tjaalton> and postpone the point release(s) until after .1
[20:21] <stgraber> the ivy bridge fix is really simple, clean and easy to test and a whole lot less scary than getting a new upstream mesa
[20:21] <tjaalton> yeah we could hopefully get 8.0.5 soon enough that it wouldn't matter :)
[20:21] <tjaalton> and at least test it properly with some more time
[20:22] <infinity> tjaalton: If we drop the current proposed one, you shouldn't need the icky version number... I think.
[20:22] <tjaalton> no?
[20:23] <tjaalton> I think it's needed, since it's in -proposed and not the queue
[20:23] <infinity> You can't *reuse* the current version, but I suspect the machinery won't prevent us from going backward if there's no published version with the higher number.
[20:23] <infinity> (I'd have to delete it from proposed first, obviously)
[20:23] <tjaalton> ok
[20:24] <tjaalton> well, people who have used -proposed would not get the "new" version then
[20:24] <infinity> Is that preferable to just testing more with the current one?
[20:24] <infinity> Yes, there's that.  proposed users would be stuck with the deleted one.
[20:24] <infinity> Though, that's true any time we drop an SRU from proposed.
[20:24] <tjaalton> what is the deadline for .1? probably too soon to get enough testing..
[20:24] <tjaalton> indeed
[20:25] <stgraber> tjaalton: well, the deadline was a week and a half ago ;) so we're talking about last minute exception in any case ;)
[20:25] <tjaalton> ah :)
[20:25] <stgraber> tjaalton: having just the ivy bridge stuff tested should be fine, the diff is readable and backed by a spec, so it's really just about having someone confirm that it works
[20:25] <infinity> mesa's been in proposed for weeks, how has it not had testing?
[20:26] <tjaalton> then I think the most sensible option is to only add the ivb fix. It'll get tested asap by the hwe guys in taipei
[20:26] <tjaalton> infinity: i've been running it for weeks
[20:26] <stgraber> infinity: well, apparently it had some testings and some regressions found... (without the bugs being updated it'd seem)
[20:26] <tjaalton> but those that had the single bug mentioned in the changelog haven't bothered adding any info on the bug..
[20:27] <stgraber> tjaalton: ok, can you take care of uploading a new mesa based on 8.0.2-0ubuntu3.1 with just the ivy bridge change then?
[20:27] <tjaalton> also, the piglit regressions were on nouveau/radeon, I've only used it on intel
[20:27] <tjaalton> stgraber: sure. ok if I do it in the morning?
[20:27] <tjaalton> EEST morning :)
[20:28] <infinity> I'll drop the current one from proposed, then.
[20:28] <tjaalton> ie. 10h from now
[20:28] <stgraber> tjaalton: once that's in the queue, we'll get the current one removed from -proposed, accept that one, test it, get it in -updates and then post-12.04.1 you can get the new mesa upstream
[20:28] <tjaalton> excellent
[20:28] <stgraber> tjaalton: yeah, it's unlikely to make it to the next CD build anyway (30min from now), so if that's done in the european morning, that's fine
[20:28] <infinity> (I'll just remove it now.  If it's never going to be the binaries we ship, there's no point having it there)
[20:29] <stgraber> infinity: yep, sounds good
[20:29] <tjaalton> thanks, I'll let #ubuntu-x know about this
[20:30] <infinity> tjaalton: I could be wrong about being able to go backward with versions, but if -0ubuntu3.2 gets rejected, renumbering and reuploading isn't rocket science. :P
[20:30] <infinity> tjaalton: And I'm kinda curious to find out.
[20:32] <tjaalton> infinity: heh, we'll find out soon enough
[20:32] <micahg> ISTR one can go backwards with sources, but not binaries...(and even that cjwatson warns not to do it)
[20:33] <tjaalton> well, let me know what the version should look like and I'll upload whatever works
[20:33] <infinity> micahg: Even binaries that are no longer published?  It's possible that the complete history is checked, yeah.
[20:34] <micahg> infinity: that's what I seem to remember, but if you find out otherwise, I'd be kinda happy personally :)
[20:34] <infinity> micahg: Well, there's a fair argument for walking the entire binary publishing history for sane upgrade paths.
[20:35] <infinity> micahg: I would argue that -proposed should, perhaps, not be subject to this, but I really doubt it has special-casing.
[20:35] <infinity> tjaalton: The more I think about it, the more I suspect you'll need some sort of 8.0.3+8.0.2-0ubuntu3.2 ickiness.
[20:36] <tjaalton> infinity: yeah
[20:37] <infinity> Thankfully shortlived, if you plan on an 8.0.4-0ubuntu1 shortly after. :P
[20:42] <tjaalton> yeah, and possibly even pulling the current 8.0 branch.. ivb gpu hang fixes/workarounds there
[20:42] <tjaalton> ivb & snb
[20:51] <stgraber> skaet: updated debian-cd and cdimage-deployment to turn off proposed, disabled the cron jobs for now. Will wait an extra 10min and start kicking the rebuilds.
[20:58] <stgraber> slangasek, infinity: can you also move d-i to -updates? we'll need it if we want a working alternate/server image.
[20:59] <stgraber> slangasek: it looks like you missed fglrx-installer-updates when you copied fglrx-installer earlier
[21:00] <stgraber> infinity: light-themes contains a UI fix for Edubuntu (gnome-panel font and distributor logo), it's currently at 6 days and all fixes have been tested apparently, can you move it?
[21:02] <infinity> stgraber: Done, done, and done (the fglrx one too).
[21:03] <stgraber> yay! will wait for the publisher before starting with the respins
[21:03] <slangasek> stgraber: no, I didn't miss it, that was the oops ;)
[21:03] <slangasek> thanks, I hadn't quite tracked down yet which package had caused it
[21:03] <stgraber> slangasek: ah ;)
[21:03]  * slangasek tries again
[21:05] <stgraber> slangasek: heh, now I see it being copied twice to -updates ;)
=== kate_ is now known as skaet_
[21:05] <stgraber> slangasek: once by infinity and now once by you, though your copy is lacking any kind of content in the confirmation e-mail (to precise-changes@lists.u.c) :)
[21:10] <stgraber> seb128: FYI marked bug 1024480 as verification-failed. It's not a 12.04.1 targeted bug, so no hurry fixing it.
[21:10] <ubot2> Launchpad bug 1024480 in remmina "should use keywords in its .desktop entry" [Low,Fix committed] https://launchpad.net/bugs/1024480
[21:12] <slangasek> stgraber: well, fun
[21:14] <seb128> stgraber, crap, yeah, autoreconf is not run during build, that's ok it was a low hanging fruit one
[21:36] <phillw> hi guys & gals, are you confident in the cadence testing for http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/20963/testcases to be popped onto a VM and tested in the 'real world'? The tester is aware that it may break.
[21:40] <stgraber> phillw: if you're hoping for one of us to say "yeah sure a dev release is fine to be used in production" you'll never get that, so no
[21:40] <stgraber> it's a dev release, use it at your own risk and expect it to break at the worst possible time
[21:42] <phillw> stgraber: I hold the isos for that team on a stable server :) The question was, will I be able to install it? :P
[21:43] <phillw> stgraber: can it now install LAMP, that was the last bug I saw on it.
[21:46] <phillw> well, I will find out in the next hour or two :)
=== rsalveti` is now known as rsalveti
=== Ursinha` is now known as Ursinha
[22:43] <stgraber> skaet: half way through in the rebuilds, should all be done in an hour or so
[23:24] <stgraber> skaet: leaving for a few hours now, I started the rest of the images in the background, so they should build in a fairly random order but should all be published in a little while
[23:24] <skaet> stgraber,  ok
[23:24] <stgraber> (only live images are left, all the alternate and server images are already built)
[23:24] <skaet> thanks stgraber
[23:25] <stgraber> skaet: no amd64+mac for kubuntu in the point release?
[23:25] <stgraber> skaet: I just noticed it's not getting updated on the tracker and default-arches has been changed to prevent it from building
[23:26]  * skaet checking
[23:27] <skaet> stgraber,  its not in Kubuntu's manifest,  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
[23:27] <skaet> ScottK,  Riddell ^ can you confirm no amd64+mac
[23:28] <skaet> if you do want it,  please update ReleaseManifest/12.04.1
[23:28] <stgraber> skaet: ok, removing it from the tracker for now then, no point in having an outdated build on there
[23:28]  * skaet nods
[23:40]  * skaet --> dinner,  back in a bit