[09:18] <tseliot> can an admin approve fglrx-installer and fglrx-installer-updates in utopic-proposed, please? This will avoid a failure when upgrading
[10:47] <jamespage> apologies - I did not spot "  * [bb3229e] d/: new binary package for nfct" when merging conntrack - that was bad of me
[10:49] <cjwatson> jamespage: that's ok, it looks fine
[10:49] <jamespage> ok
[10:49]  * jamespage feels less bad now!
[10:51] <cjwatson> yikes, ran "rm *" in $HOME after processing that.  thank krusty for backups
[10:51]  * rbasak quietly checks his own last backup succeeded.
[10:52] <cjwatson> my backup system mails me every morning :)
[10:55] <rbasak> Mine did email me on failures, until my mail system broke about a month ago. I haven't got round to fixing it yet :-/
[10:55] <rbasak> (I don't use a local MTA, so I use msmtp, and my SMTP auth provider disappeared. Need to switch to a new one, but that involves changing my SPF records, etc)
[10:55] <ogra_> use the backup to restore your mail system then ;)
[10:57] <cjwatson> there, recovered
[11:05] <tseliot> Riddell: hey, can you approve fglrx-installer and fglrx-installer-updates in utopic-proposed, please?
[11:06] <Riddell> tseliot: what's new?
[11:06] <Riddell> seems the queue is full of language packs today
[11:07] <tseliot> Riddell: there's a problem when upgrading to the packages that these updates solve. (it's alternatives clash)
[11:08] <Riddell> tseliot: accepted
[11:08] <tseliot> Riddell: thanks a lot
[11:09] <Riddell> so.. who's incharge of the RC?
[11:19] <shadeslayer> you! :p
[11:34]  * cjwatson accepts language packs
[11:54] <Riddell> made http://iso.qa.ubuntu.com/qatracker/milestones/325/builds but I don't know how to populate it with images, I thought that would happen magically
[12:00] <cjwatson> Riddell: I think it happens automatically given that it's marked as "automatically publish", but it'll be whenever new builds come out
[12:01] <stgraber> Riddell: hi, infinity is in charge of release but we're currently at Plumbers in Düsseldorf
[12:02] <stgraber> Riddell: the plan is to start publishing real RCs on Friday before we all fly away from here I believe, though I'll have a quick look at that RC milestone
[12:10] <stgraber> Riddell: also, we no longer do RC milestones, instead we just begin Final image testing, so I'll rename that milestone
[12:51] <Riddell> stgraber: mm ok thanks
[13:34] <infinity> doko: Was that a binary sync, or source-only?
[13:34] <infinity> doko: Cause the source PPA isn't clean...
[13:35] <doko> urgh, just used --to-primary. was supposed to land in -proposed
[13:35] <infinity> doko: Ancient version of ubuntu-archive-tools?
[13:36] <doko> no, r859
[13:36] <doko> ok, a bit ancient ...
[13:36] <infinity> doko: Anyhow.  Make sure it doesn't have -b on it when you redo it to proposed, so it rebuilds.
[13:37] <infinity> I can't really tell in the queue if that's how it was done, which is annoying. :/
[13:37] <doko> ok
[13:40] <cjwatson> doko: modern invocation is:  copy-package --from=~owner/distro/name --from-suite=utopic --to=ubuntu --to-suite=utopic-proposed [-b] source
[13:40] <cjwatson> which is much easier to remember and get all the combinations right
[13:40]  * doko makes a note
[13:40] <infinity> cjwatson: Though --to-suite=utopic should still DTRT with a modern checkout, should it not?
[13:40] <cjwatson> but you'll want at least r894 really
[13:40]  * infinity can never remember.
[13:41] <cjwatson> infinity: no, copies don't honour redirections
[13:41] <cjwatson> (deliberately, because promotion uses copies)
[13:41] <cjwatson> as an AA you *can* use --to-suite=utopic but you'll bypass proposed-migration if you do, so please don't
[13:41] <doko> anyway, gcc-4.8 testsuite looks good, no regressions
[13:41] <infinity> cjwatson: I thought they redirected in the client unless one use auto-approve, or something.  But it's been a while since I bothered to look or care.
[13:42] <cjwatson> nope, auto-approve just affects the queue state
[13:42] <infinity> cjwatson: Oh, or is it just that normal people get a hard reject?
[13:42] <cjwatson> right
[13:42] <infinity> I always do the right target regardless, so I guess I thought it was smarter than it is. ;)
[13:43] <cjwatson> r879 introduced the new archive reference forms; r894 added --from-suite.  probably some other bug fixes in there.
[13:45] <infinity> doko: I'll let that in once sagari frees up, so I can aim the ppc build there.
[13:45] <infinity> doko: But looks good otherwise, thanks.
[13:46] <infinity> cjwatson: Do you know of a way to see if a copy was binaryful or not?  It's irksome that I can't seem to sort that out pre-accept.
[13:46] <infinity> wgrant: ^
[13:48] <cjwatson> infinity: "queue show-urls", see if it contains binaries
[13:50] <infinity> cjwatson: Ah-ha!  Missed that in --help.  Thanks!
[13:50] <infinity> doko: Your copy had binaries.  Rejecting again. :/
[13:51] <cjwatson> probably an attribute on the queue somewhere too, but that's the quickest/easier way
[13:51] <cjwatson> *easiest
[13:51] <doko> infinity, I used: ./copy-package -p ubuntu-toolchain-r --ppa-name ppa --to-primary gcc-4.8 --to-suite=utopic-proposed
[13:51] <cjwatson> err
[13:51] <cjwatson> I wonder if I misremember about show-urls
[13:51] <infinity> Hahaha.
[13:51]  * cjwatson checks the copy logs
[13:51] <infinity> Maybe it always shows URLs from the original source? :)
[13:52] <doko> anyway, doing a fresh upload
[13:52] <cjwatson> [2014-10-15 13:38:57,007: INFO/PoolWorker-1] Running <PlainPackageCopyJob to copy package gcc-4.8 from ~ubuntu-toolchain-r/ubuntu/ppa to ubuntu, PROPOSED pocket, in ubuntu utopic> (ID 25199429) in status Waiting
[13:52] <infinity> Luckily, we can re-copy as many times as we want!
[13:52] <cjwatson> ok, that would show "including binaries" if it were with -b
[13:52] <cjwatson> doko: no need to do a fresh upload, just re-copy :)
[13:52] <infinity> doko: Yeah, sorry about that.  Just re-do exactly the same thing.
[13:52] <infinity> And I'll whine at people to fix our tooling so this isn't completely opaque. :/
[13:53] <doko> so the second copy was without binaries?
[13:53] <Laney> In [2]: utopic.getPackageUploads(status='Rejected', name='gcc-4.8')[0].contains_build
[13:53] <cjwatson> Yeah
[13:53] <Laney> Out[2]: False
[13:53] <cjwatson> Laney: I'm not sure that's actually right
[13:53] <stgraber> if there's a reliable API way of doing it, I'll ad the check to queuebot
[13:54] <cjwatson> I think contains_build is probably always false for copies
[13:54]  * Laney tries on a CI train copy
[13:54] <cjwatson> In [2]: utopic.getPackageUploads(status="Unapproved", name="indicator-power")[0].contains_build
[13:55] <cjwatson> Out[2]: False
[13:55] <Laney> Out[9]: False
[13:55] <Laney> Ya
[13:56] <cjwatson> I think it's an attribute on the PCJ and isn't exposed on the API
[13:56] <infinity> Right, I'm going to assume this all gets fixed as wgrant winds through the queue redesign stuff.
[13:57] <infinity> But it's yet another annoyance when a copy is done from an unclean (or not-distro-friendly) PPA, cause I have no idea if it can be accepted.
[13:57] <infinity> So the default for non-silo copies is pretty much just reject in my mind, I guess.
[13:57] <infinity> Well, silo, security, kernel...
[13:58] <cjwatson> infinity: do you have access to carob?
[13:58] <cjwatson> worst case it's possible to dig it out from there
[13:58] <cjwatson> "rsync ackee.canonical.com::launchpad-production-logs/celeryd-production_launchpad_job.log ." and then dig through the log for the copy
[13:59] <infinity> cjwatson: I do, but always forget that I do. :)
[13:59] <infinity> cjwatson: Not exactly the most efficient way to judge acceptability of a queue item, mind you.
[14:00] <cjwatson> no quite
[14:03]  * stgraber just discovered he had access to carob too
[14:04] <cjwatson> obviously not good since Canonical-only, never mind efficiency
[14:05] <infinity> cjwatson: I suspect most non-Canonical AAs/SRUAs/RTMs stay away from reviewing copies anyway, just out of general protest for it being a crap experience. :P
[14:05] <infinity> cjwatson: But that's a reason to make it no crap, of course, not to say "oh, good, then they don't need this hackish workaround".
[14:06] <cjwatson> sure
[14:07] <cjwatson> I did try but got stuck
[14:07] <infinity> Yeah, I'm putting my faith in William here.  He's already made small improvements here and there and knocked out some of my bugs, so I have hope. :)
[14:07] <infinity> And he's, apparently, getting a minion soon.
[14:07] <infinity> So, that might help, if said minion can be brought up to speed quickly.
[14:58] <mvo> could someone please reject my util-linux upload? it needs another tweak
[15:00] <jdstrand> fyi, apparmor upload is bug fix only. it is a new upstream tarball that has bug fixes, policy fixes and testsuite fixes. it also syncs the boot policy load with what is in rtm
[15:01] <jdstrand> oh hrm, it skipped unapproved...
[15:02]  * jdstrand used a security team script and forgot it autoapproved
[15:03] <jdstrand> sorry about that. if a member of the release time would like to review and and tells me to revert it, I can. however, like I said, it is all bug fixes
[15:05] <infinity> mvo: Rejected, see #-devel too.
[15:06] <infinity> mvo: The Debian packages had a bit more fiddling WRT uuid stuff.
[15:07] <mvo> infinity: thanks!
[15:07] <mvo> infinity: the new upload should be better
[15:13] <mvo> infinity: meh, reject again, there is one more instance of this chsh
[15:14]  * mvo makes a note to not upload packaes in anger
[15:15] <infinity> mvo: Too late.
[15:15] <mvo> infinity: ok, I will just do a followup then, it won't hurt :)
[15:15] <mvo> infinity: its just not complete
[15:51] <lool> Someone mind hinting or kicking the autopkgtests to allow touch-meta to transition from proposed into utopic?
[15:52] <lool> unity-scope-click autopkgtests passed, but britney didn't pick it up
[15:52] <lool> that's ubuntu-touch-meta 1.193
[15:54] <infinity> It's possible you're just being impatient.
[15:55] <infinity> (The tests ran after the last britney run)
[15:56] <infinity> We'll work on the time machine patches in the next cycle, though.
[16:20] <cjwatson> sorry
[17:38] <cyphermox> ^ I notice now that I forgot to mention one change in network-manager changelog; the track_ip_settings_post_connection.patch changes go along with the other changes to fix bug 1350332; please don't block this upload for this, I know it's bad :/
[18:59] <slangasek> cyphermox: bug #1350332 is also not a public bug, please use public bugs in the changelogs for Ubuntu packages
[19:00] <cyphermox> let's make it public then
[19:05] <slangasek> cyphermox: a) I'm not sure we're allowed to make it public since it does include logs from a phone, b) I believe launchpad disallows reassigning bugs from private projects to Ubuntu packages
[19:06] <cyphermox> no, you're right
[19:06] <cyphermox> ugh, this day is so bad
[19:06] <slangasek> not a blocker for this upload, for the record
[19:06] <slangasek> but best practices etc.
[19:06] <cyphermox> yes, I know :/
[19:07] <cyphermox> fwiw, it was the first time I heard about private bugs in changelog though
[19:07] <cyphermox> but I agree it's not great for those who will go read it and not have access to the bug
[19:12] <slangasek> cyphermox: yeah.  It's a hard rule for SRUs; for devel uploads it's not a hard rule but it's a nuisance
[19:13] <cyphermox> noted, thanks
[19:13] <cyphermox> I was already using just non-private bugs for SRUs, just never seen it written down
[19:16] <cyphermox> thanks, I owe you a beer I guess
[19:17] <cyphermox> or perhaps whisky so we can forget the pain of this ugliness
[20:01] <elfy> jibel: I see you listed as the qa contact on release task signup - so ... did you know that there appears to be no Upgrade products on http://iso.qa.ubuntu.com/qatracker/milestones/325/builds
[20:16] <cjwatson> slangasek: ^-
[20:17] <slangasek> grabbing
[20:18] <cjwatson> we'll need to be careful to review the result - innocuous diff but it does cause the apparmor hook to go down a different code path
[20:18]  * slangasek nods
[20:18] <cjwatson> albeit one that only contains rm -f, so I think the worst case is some files left in the rootfs that shouldn't be, but nevertheless
[20:27] <jibel> elfy, upgrade test cases are added manually, I'll do it later this week. I'm quite busy with a phone milestone ATM. If I forgot Friday morning, don't hesitate to ping me again.
[20:28] <elfy> I'll try and remember then - pretty tied up on Friday though
[20:28] <elfy> thanks jibel `
[23:57] <rcj> cjwatson, infinity, stgraber: the cloud builder is having problems for 14.10.  I wanted to give you a heads up going into the RC tomorrow.
[23:57] <rcj> cjwatson, infinity, stgraber: to be clearn, the issue is not 14.10 specific