[00:13] <infinity> cjwatson: ^
[09:52] <cjwatson> infinity: That's curious; in the one I have on disk, I did use -v.
[09:52] <infinity> cjwatson: Weird.  You can check your .changes in the rejected queue, it only had the top version.
[09:53] <infinity> cjwatson: Anyhow, I sponsored with a new dpkg-genchanges, and accepted.
[09:53] <infinity> Err.
[09:54] <infinity> And now that I look in the rejected queue, I see both entries.
[09:54] <infinity> Was I on crack last night?
[09:54] <infinity> Poooossibly.
[09:54] <cjwatson> Ah well, no harm :)
[09:54]  * infinity shrugs it off.
[09:55] <infinity> This distro needs more bonghits anyway.  We're clearly getting too good at what we do.
[11:23] <ScottK> I managed to use my hint file to force the rest of KDE 4.9.80 into raring.  cjwatson: Thanks for the tutorial a couple of days ago.
[11:26] <cjwatson> you're welcome
[11:38] <infinity> Oh, and I finally got rid of that NBS linux-source-3.5.0
[12:04] <ogra_> ogra@nexus7:~$ apt-cache madison ubuntu-defaults-nexus7
[12:04] <ogra_> ubuntu-defaults-nexus7 |       0.35 | http://ports.ubuntu.com/ubuntu-ports/ raring/universe armhf Packages
[12:04] <ogra_> ubuntu-defaults-nexus7 |       0.36 | http://ports.ubuntu.com/ubuntu-ports/ raring/universe Sources
[12:04] <ogra_> hmpf
[12:05] <ogra_> 0.36 was promoted 20h ago according to launchpad
[12:05] <ogra_> and i see the binary on http://ports.ubuntu.com/pool/universe/u/ubuntu-defaults-nexus7/
[12:05] <ogra_> did the ports.ubuntu.com publisher fail ?
[12:17] <ogra_> ogra@nexus7:~/ubuntu-defaults-nexus7-0.36$ apt-cache madison curl
[12:17] <ogra_>       curl | 7.28.0-2ubuntu2 | http://ports.ubuntu.com/ubuntu-ports/ raring/main armhf Packages
[12:17] <ogra_>       curl | 7.28.0-3ubuntu1 | http://ports.ubuntu.com/ubuntu-ports/ raring/main Sources
[12:17] <ogra_> ogra@nexus7:~/ubuntu-defaults-nexus7-0.36$
[12:17] <ogra_> hmm, seems other packages are messed up too
[12:17] <ogra_> https://launchpad.net/ubuntu/raring/+source/curl/7.28.0-3ubuntu1 thinks that was published 15h ago
[12:18] <ogra_> cjwatson, any idea ? smells like the publisher is stuck or so
[12:18] <ogra_> ot infinity (if still awake) ^^^
[12:19] <ogra_> *or
[12:35] <xnox> ogra_: http://ports.ubuntu.com/pool/universe/u/ubuntu-defaults-nexus7/ubuntu-defaults-nexus7_0.36_all.deb
[12:35] <xnox> ogra_: and rmadison agrees.
[12:35] <ogra_> not here (see above )
[12:37]  * ogra_ reboots, thats freshly after install without reboot, lets see if something changes
[12:38] <ogra_> aha
[12:38] <ogra_> this apt-get update run takes significantly longer now
[12:39] <ogra_> yeah, now it works
[12:39] <ogra_> weird
[12:39] <ogra_> i wonder if it has to do with the change of the hostname
[12:39] <ogra_> like the other services we identified (rsyslog etc)
[12:46] <xnox> ogra_: in other news. ubiquity should be fully published now & next respin should drop metacity. Apart from germinate rdepends are not updated yet =/ so not sure if it's still seeded or not.
[12:46] <ogra_> we'll see
[12:46] <ogra_> no hurry at all
[13:17] <ogra_> hmm, why are kpartx and lvm2 hard deps of ubuntu-minimal/-standard
[13:18] <ogra_> oh, they arent, dmsetup is
[13:24] <ogra_> flash-kernel: installing version 3.1.10-8-nexus7
[13:25] <ogra_> Flashing kernel and initramfs to /dev/mmcblk0p2... /dev/mmcblk0p2: updated is too big for the Boot Image (8472576 vs 8388608 bytes)
[13:25] <ogra_> *sniff*
[13:25] <ogra_> even when droping everything from the initrd, setting MODULES=list and swithcing to xz compression i cant get the initrd small enough
[13:30] <ogra_> ah, shiny, weeding out more stuff manually makes it work (sadly right at the edge of teh size limit)
[15:09] <cjwatson> Could somebody NEW that batch of gettext binaries?  It should make a big difference to cross-buildability.
[15:16] <didrocks> cjwatson: the dep from the -dev on Depends: libgettextpo0 (= 0.18.1.1-10ubuntu1) for instance is only fullfilled if the same corresponding arch binary package is installed, right?
[15:18] <didrocks> (because the corresponding libgettextpo0 is multiarch: Same as well, not foreign I guess, but just checking before acking, it's my only question, otherwise, looks good)
[15:19] <cjwatson> didrocks: That's right, yes - an M-A: same package may not satisfy a dependency of a package of a different architecture
[15:19] <cjwatson> (https://wiki.ubuntu.com/MultiarchSpec)
[15:20] <didrocks> cjwatson: excellent, NEWed then :) (and tab opened)
[15:20] <cjwatson> Great, thanks
[15:20] <cjwatson> I'll be able to kick off my cross-builder in a bit and see how much further it gets ...
[15:21] <cjwatson> Currently engaged in reverting all the gettext:any build-deps we used to have, which wasn't a scalable approach
[15:22] <didrocks> oh right, good goal :)
[15:51] <cjwatson> Hmm
[15:51] <cjwatson> I think I'm going to make raring-proposed → raring propagation require powerpc again - the current arrangement causes problems with powerpc-only packages
[15:52] <Laney> seems relatively caught up anyway
[15:52] <cjwatson> (they get propagated almost immediately, but there are no binaries to copy so the package copier refuses to copy the source, and then the build comes along and is rejected because the publication in -proposed has been deleted and it's a build for a superseded source)
[15:53]  * cjwatson audits
[15:58] <ScottK> BTW, For kalgebra I had removed the armhf binary since it looked like one of it's dependencies (cantor) would be unbuildable on armhf for an extended period.    It turned out cantor got fixed by upstream very quickly and after it was built and kalgebra got retried and built, armhf migrated fine.
[15:58]  * Laney adds self a hint file to hold some gstreamer back for a little while
[16:30] <plars> I don't recall what the latest word was on this - we have a lot of warnings all over the place for oversized images, but does the release team want a bug for that also? Many of the precise images are oversize now in the dailies
[16:30] <Laney> there's a daily email report for that so a bug wouldn't add much
[16:30] <cjwatson> plars: we get mailed daily about it, so ... what Laney said
[16:32] <plars> Laney, cjwatson: so we currently duplicate this check in some iso smoke tests in the lab, causing a daily job failure now.  I think I'm going to take this test out since it just duplicates the existing checks you are getting notified about, but we'll rely on you guys to handle it in that case
[16:32] <cjwatson> Yeah, I don't think we need to be notified in two places
[16:32] <cjwatson> And it probably obscures other things that are less easily detectable elsewhere
[16:34] <plars> exactly, thanks
[17:55] <bdmurray> cjwatson: since I'm not in ubuntu-archive anymore I can't remove packages from the archive - a couple of weeks ago slangasek mentioned opening a launchpad bug about granting the SRU team access to remove packages.  Does that seem best?
[17:56] <bdmurray> In the meantime could somebody remove yaml-mode from lucid-proposed?
[17:56] <cjwatson> The implementation would be more about granting removal permission to people with queue admin permissions on the relevant context
[17:56] <cjwatson> We shouldn't be special-casing ubuntu-sru
[17:56] <cjwatson> give me a removal reason string and I can remove it
[17:56] <bdmurray> "Not verified within a timely fashion."
[17:58] <cjwatson> bdmurray: done
[18:00] <bdmurray> and samba in lucid-proposed for the same reason
[18:04] <cjwatson> bdmurray: done
[18:11] <bdmurray> thanks
[18:55] <micahg> stgraber: is that queuebot's fault on lxc (using the backport version vs proposed) or something else?
[18:57] <stgraber> micahg: yep, infinity spotted that bug before, I need to teach queuebot to look in the right pockets instead of doing a generic lookup in the whole series
[19:13] <micahg> bdmurray: I would think that failed-srus would go back to triaged, not won't fix
[19:14] <TheDrums> Howdy.  I'm wondering if there'd be a chance that the released ISOs would switch to XZ compression?  This would give the teams (Xubuntu for one) more room to breath.
[19:15] <micahg> TheDrums: no, this has been brought up before, unless Xubuntu doesn't want its image to be rsyncable (and then it's only maybe)
[19:17] <bdmurray> micahg: okay, that seems fine
[19:17] <TheDrums> micahg: Ah, sorry then.
[20:04] <slangasek> hmmmm, update-manager is showing me wrong changelogs for SRUs
[20:04] <slangasek> server-side breakage on changelogs.u.c?
[20:21] <slangasek> aha, it's because of NEWS.Debian in the packages
[20:21] <slangasek> (bug #1084715)
[20:21] <ubot2> Launchpad bug 1084715 in update-manager (Ubuntu) "update-manager showing wrong NEWS.Debian entries for SRUs" [Undecided,New] https://launchpad.net/bugs/1084715
[20:27] <seb128> slangasek, that bug description is confusing (or did I overlook something?)
[20:27] <seb128> slangasek, you wrote what it should show but you didn't describe what it's actually showing?
[20:34] <slangasek> seb128: it should only be showing the changelog entry
[20:34] <slangasek> none of the NEWS is actually news
[20:53] <slangasek> so which flavors are in fact doing alphas this cycle?
[20:54] <slangasek> the release schedule says the first of these is due to happen next week
[20:54] <ScottK> Kubuntu is
[20:55] <ScottK> We've actually been doing some installer testing this week and making sure we had all the KDE stuff we want landed.
[20:55] <slangasek> ok, cool
[20:55] <ScottK> Riddell: ^^^
[20:55] <ScottK> I don't think anyone else is, but I'm not certain.
[20:56] <slangasek> I was just talking to stgraber, as we noticed he has a work item about determining who "the release drivers are for each milestone", and we were trying to puzzle out what that actually means
[20:56] <slangasek> seems like we should know that in time for the first milestone :P
[20:56] <ScottK> Until we non-Canonical can respin images, I think who it is needs to be Canonical.
[20:56] <slangasek> right, I was guessing that's what it was
[20:56] <ScottK> I agree about knowing who it is.
[20:58] <ScottK> We should also work on messaging this early too.
[21:00] <stgraber> ok, so the work item is mostly about nagging people to put their name on https://wiki.ubuntu.com/RaringRingtail/ReleaseTaskSignup then?
[21:01] <slangasek> perhaps nagging is not the best modality, but yes :)
[21:02] <stgraber> I'm happy to take alpha-1, that'll let me check that the new manifest + auto-copy of build entries on the tracker works as expected
[21:02] <slangasek> stgraber, cjwatson, infinity: should we draw straws wrt driving nusakan?
[21:03] <slangasek> stgraber: great, I was just about to nominate you for alpha-1
[21:03] <stgraber> see, you didn't even have to ;)
[21:04] <stgraber> hmm, I guess I can take Check list tracking too for a1, if that's just about following the list on the wiki and making sure everything gets done
[21:05] <slangasek> I'm afraid I have no idea what those different columns are for
[21:05] <slangasek> except the nusakan one which is obvious
[21:06] <stgraber> my interpretation is: nusakan => trigger the builds, checklist => follow the matching wikipage and make sure all entries get done, release-notes => poke people to update the wiki pages and send the announcement, qa-contact => who's looking at the bugs on the QA side
[21:07] <stgraber> I'm happy to take the first three unless someone desperately wants to do the paperwork part, for QA, my guess is that it'll be balloons as it's going to be a non-Canonical flavour only run?
[21:07] <slangasek> right; columns 2-4 are things that I would expect to be handled by the flavors that are particpating in the milestone
[21:08] <ScottK> slangasek: 2 - 4 or 3 - 5?
[21:08] <slangasek> ScottK: sorry, was only counting the signup columns
[21:08] <ScottK> OK.
[21:09] <stgraber> well, it was decided at UDS that it'd be the release team doing the announce for the non-Canonical milestones as was done in the past. So there's definitely going to be more involvment from the flavour leads to actually give us the content and do all the testing, but the checklist and announcement should still be done by the release tam
[21:09] <stgraber> *team
[21:09] <ScottK> Also, for the U-D-A Alpha announcement we need to figure out the template that we'll use to explain who is participating in the Alpha and who is not.
[21:10] <ScottK> Right, but we can write the part of the content that explains Ubuntu desktop, Ubuntu server, etc are not participating due to switching to a continuous integration model.
[21:10] <stgraber> yep, that definitely needs to be the first paragraph of the announcement, to avoid confusing everyone
[21:10] <ScottK> I suspect there are people inside Canonical that want a chop on that boilerplate.
[21:13] <slangasek> plausible ;)
[21:13] <ScottK> If only the relevant Canonical manager were on IRC right now ...
[21:14] <stgraber> ok, so for now I updated the wiki to be me for all first 3 columns and balloons for QA relations, I plan to heavily delegate on the participating flavours however :)
[21:14] <ScottK> Excellent.
[21:15] <balloons> stgraber, signed me up eh?
[21:15] <stgraber> I'll send an e-mail shortly to ubuntu-release@lists.u.c to see exactly who's participating so they can be added to the alpha-1 manifest
[21:15] <stgraber> balloons: totally did :) I figured you'd be the best point of contact for flavours testing for their alpha-1 next week :)
[21:17] <balloons> stgraber, so what all is being asked of me?
[21:17] <balloons> I can help any of the flavor leads use the tracker, etc
[21:18] <stgraber> balloons: basically help them if they have some problems with their testcases and keep an eye on the bugs being reported for any critical looking ones.
[21:18] <stgraber> balloons: which I assume you do pretty much everyday anyway
[21:19] <balloons> fair enough.. just wanted to clarify I won't be running any of the milestones.. I want to see the flavors take ownership of them, and it seems like that's going well
[21:31] <bdmurray> There are 2 versions of libgpod in the quantal -proposed queue both of which look the same based off their launchpad generated diffs.  Is that information to reject one or is there something more I should look at?
[21:33] <slangasek> do they both have the same .changes file?
[21:33] <slangasek> (one might be missing changelog entries it should have)
[21:34] <bdmurray> no, the checksums are different
[21:35] <stgraber> highvoltage, Riddell, gilir, knome: I'd appreciate it if you could read and reply to my e-mail to ubuntu-release@lists.u.c
[21:35] <knome> will do. thanks for hilighting
[21:35] <stgraber> and if any of you see Scott Lavender online, please forward this ping :)
[21:35] <slangasek> bdmurray: hmm, which checksums?
[21:36] <slangasek> the ones within the .changes?
[21:36] <bdmurray> slangasek: right
[21:38] <knome> stgraber, xubuntu won't be participating. do you want an email reply with that too?
[21:38] <slangasek> bdmurray: looks like it doesn't matter, then
[21:38] <stgraber> knome: that'd be great so those who aren't on IRC know what to expect
[21:38] <knome> stgraber, ok, i'll do that! :)
[21:39] <knome> stgraber, done
[21:39] <stgraber> thanks
[22:10]  * med_ wonders how to get some attention to a SRU candidate
[22:10] <med_> bdmurray,  maybe...  https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= walinuxagent?
[22:10]  * bdmurray wonders what med_ means by candidate
[22:11]  * med_ should read more on the process to determine what state that really is in
[22:24] <infinity> med_: I haven't looked yet, but does one of the bugs referenced in the changelog explain the rationale for this being backported to precise?
[22:25] <infinity> med_: (I can probably guess that on my own from the package name, mind you, but some sort of "this is how we plan to test it on precise" would be nice)
[22:25] <med_> infinity, we plan to test it heavily on precise.
[22:25] <infinity> med_: A changelog telling me that it fixes a critical bug is somewhat meaningless when it disn't exist in precise before. :)
[22:26] <infinity> By definition, it's more buggy than the version that was there before. :P
[22:26] <med_> infinity, nod, it was included in the image put into the Microsoft Azure cloud (as we were too late to make the precise release)
[22:26] <med_> but it is a required agent for the Azure cloud
[22:27] <med_> (ie, Ubuntu won't work at all without it.)
[22:27] <infinity> Ahh, so we're shipping a non-archive versions of this in our images?  Ick.
[22:27] <med_> ick is correct.
[22:27] <infinity> At least one of those bugs referenced in the SRU might want to mention that fact.
[22:27] <infinity> Makes the SRU far more justifiable. :P
[22:27] <med_> okay.
[22:28] <infinity> Otherwise, yeah, I see no huge problems with the concept of accepting this.  I'll review it in a bit.
[22:29] <bdmurray> infinity: thanks
[22:30] <med_> thanks both.
[22:40] <med_> infinity,  I put a comment #9 into 1079897
[22:40] <cjwatson> slangasek: I'm fine with helping out for future milestones
[22:41] <cjwatson> But sounds like this one is dealt with
[22:41]  * slangasek nods
[22:41] <cjwatson> This one may need some help from me to get britney set up to block things as needed
[22:43] <cjwatson> BTW, I'm off work tomorrow - daughter's birthday
[22:53]  * med_ suspects that daughter was in copehagen
[22:54] <cjwatson> med_: Yeah
[22:54] <stgraber> cjwatson: oh right, I meant to ping you about the per-source migration freezes in britney. I'm hoping we won't have to do any of that for alpha-1 but it's an option we said we'd give the flavours, so ...
[22:55] <cjwatson> Right.  Er, somebody gets to generate a great big list and we'll plug it in, I guess.  I don't think we'll have anything more dynamic available in short order
[22:56] <stgraber> yeah, for now I expect them to give me a list of source package names that they want to hold, so in theory, no auto-generated bits
[22:56] <stgraber> if they all come with huge lists, then we'll probably need to figure out how to automate that stuff, but I doubt that'll be the case for alpha-1
[22:57] <cjwatson> It'd be nice to be able to freeze by package set or by Priority or Task or something.
[23:13] <infinity> I'm personally kinda hoping they decide they don't need this feature, but we'll see how A1 goes.