[00:14] <micahg> is there a way to override specific binaries in the queue or do I have to accept all the binaries and then override specific ones?
[00:19] <cjwatson> wxl: I turned dailies on earlier today, so it'll just be waiting for cron to roll round.
[00:19] <cjwatson> (And I mentioned doing so here)
[00:20] <wxl> okie dokie, cjwatson. thanks. didn't notice. hey, what are you doing on the release team anyways? :)
[00:20] <cjwatson> I'm not, but it was easy for me to do this bit when somebody asked
[00:20]  * wxl nods
[00:20] <wxl> well good to see you, anyways. thanks for all the lp improvements XD
[00:20] <cjwatson> stgraber: Would you mind setting up xenial targets on iso.qa?
[00:21] <cjwatson> np, it's fun
[00:21] <cjwatson> And it hasn't taken several weeks to get dailies back after release for ages.
[00:22] <wxl> cjwatson: https://wiki.ubuntu.com/NewReleaseCycleProcess seems to suggest there may be some reason to wait before the dailies can be turned on. are there any blockers (except for time, energy, etc) to turning them back on right after release?
[00:23] <cjwatson> wxl: Turning them on is less urgent than doing all the other things before that that blocks more developers
[00:23] <cjwatson> wxl: And seriously dude, we turned them on less than two working days after release
[00:24] <wxl> cjwatson: right, so it's a question of time/manpower to get more urgent items done. sounds good :)
[00:24] <cjwatson> What do you want, blood?
[00:24] <wxl> cjwatson: i honestly don't care, but just want to establish realistic expectations amongst the testers and such that are constantly mewling at me when their dailies aren't available XD
[00:24] <cjwatson> That also usually includes various release team folks flying places, etc.
[00:25] <cjwatson> Just ignore that sort of thing when it's only a couple of working days after the last release, please
[00:25] <cjwatson> Don't pass it on
[00:26] <cjwatson> Sure, some people no doubt have wildly unrealistic expectations of human abilities, but I don't think it's necessary to pander to them
[00:26] <wxl> well i think pointing at the "couple weeks" thing will get them to shoosh it and release team can pleasantly surprise them when it's in a couple days XD
[00:26] <wxl> well time to go home. thanks again
[00:42] <stgraber> cjwatson: looks like somebody (you?) did most of the work already. Only thing that seems to be missing is the manifest which I usually copy through the DB interface on limequat. Doing that now.
[00:43] <stgraber> done
[00:44] <cjwatson> stgraber: I didn't touch iso.qa.  Cool, thanks.
[00:44] <cjwatson> Fixed up .isotracker.conf on cdimage
[13:52] <rtg> when will xenial show up in http://packages.ubuntu.com/ ?
[13:53] <ogra_> do we even maintain packages.u.c ?
[13:53]  * ogra_ always thought thats an external thing
[13:53] <rtg> dunno, but I sure find it handy
[13:54] <ogra_> i know it was handled/maintained  by a debian guy in the past (might be that IS took it over and i'm not up to date though)
[13:55] <ogra_> i.e. in the past the answer to your question was "contact the maintainer" :)
[13:56] <rtg> I find it to be a real handy way of mapping binary packages back to their source package. I imagine there are other ways to do that.
[14:00] <mdeslaur> rtg: I asked Rhonda in #ubuntu-motu
[14:01] <rtg> mdeslaur, thanks
[14:04] <cyphermox> rtg: apt-cache show $binary | grep Source
[14:05] <apw> (nd if that is empty the source package is the same as the binary)
[14:10] <rtg> once the source package is known, is there a way to teach pull-lp-source to get something from universe/multiverse ? For example, zfs-dkms. I can find it by rooting around in http://archive.ubuntu.com/ubuntu/pool/universe/z/zfs-linux/, but that isn't too handy.
[14:12] <apw> rtg, works for me .... (pull-lp-source zfs-linux)
[14:12] <rtg> hmm, I wonder why I'm special
[14:16] <cyphermox> do you have universe in your sources.list? in case that matters at all
[14:17] <cjwatson> pull-lp-source doesn't care about the component
[14:18] <cjwatson> (well, not very much.  it cares about it for the actual download, but if at all possible it finds out the component by asking LP)
[14:18] <cyphermox> right
[14:18] <cyphermox> well, sounds like rtg is the only one with issues getting packages from universe? ;)
[14:39] <cjwatson> cyphermox: cdrom-detect merge to wily, really?
[14:39] <cyphermox> argh, did I screw this up again?
[14:40] <cyphermox> it's a mistake, should have been xenial, of course :)
[14:40] <cjwatson> cyphermox: ok, rejected
[14:40] <cyphermox> thanks.
[15:16] <doko> does somebody want to comment on the "open xenial" announcement? http://paste.ubuntu.com/12980220/
[15:18] <doko> Laney, slangasek, infinity: ^^^
[15:39] <jdstrand> doko: fyi, I did a no-code-change upload of ubuntu-core-launcher to xenial, and ppc64el ftbfs, but there is no build log
[15:40] <doko> jdstrand, given back.
[15:41] <jdstrand> doko: ok, but I already tried the rebuild once, it had the same result
[15:41] <jdstrand> ftbfs, no log
[15:44] <doko> cjwatson, ^^^ this one seems to persist
[15:52] <cjwatson> doko: right, that's being investigated at the moment
[15:52] <cjwatson> there's a problem with resolving ntp.buildd in the bos01 region
[16:58] <tumbleweed> hrm, any idea why this autohint is failing?
[16:58] <tumbleweed> Trying easy from autohinter: python-cffi/1.3.0-3ubuntu1 python-cryptography/1.0.2-1 python-netlib/0.12.1-1 python-pygit2/0.23.0-1 snimpy/0.8.6-2 tahoe-lafs/1.10.2-2 xcffib/0.3.6-1
[16:58] <tumbleweed> it says:
[16:58] <tumbleweed>     * amd64: python-pygit2, python3-pygit2
[16:59] <tumbleweed> etc
[16:59] <tumbleweed> but they're installable
[17:00] <tumbleweed> ah, snimpy isn't
[17:01] <tumbleweed> britney lies :P
[17:01] <tumbleweed> no, the new one is
[17:03] <tumbleweed> I'm still confused :(
[17:14] <wxl> can anyone help me with our failed i386 daily? https://launchpadlibrarian.net/223219521/buildlog_ubuntu_xenial_i386_lubuntu_BUILDING.txt.gz
[17:15] <wxl> seems the error exists in accessing /run/uuidd?
[17:16] <cjwatson> no, the error that causes the failure is   W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/main/i18n/Translation-en  Hash Sum mismatch
[17:16] <cjwatson> which is transient, should go away next build
[17:16] <wxl> okie dokie. thanks as always cjwatson
[17:16] <wxl> would it be worthwhile then to just do a rebuild?
[17:17] <cjwatson> yeah, will do
[17:17] <wxl> i can
[17:17] <cjwatson> ok
[17:17] <wxl> you've got better things to do :)
[17:17] <cjwatson> heh, either way
[17:17] <cjwatson> let me just double-check that the hashes are fine on the master
[17:18] <cjwatson> cjwatson@pepo:~/ubuntu/dists/xenial$ grep 'main/i18n/Translation-en$' InRelease
[17:18] <cjwatson>  5a36a0899f665b142868ed0944440a56          4441015 main/i18n/Translation-en
[17:18] <cjwatson>  dfa293adcfd3a08334b9ec517f3931d28c840eab          4441015 main/i18n/Translation-en
[17:18] <cjwatson>  556a2743e0a3028cf683894bd6030987eef7a8d2d3f47f14eab197ded5dd1b2f          4441015 main/i18n/Translation-en
[17:18] <cjwatson> cjwatson@pepo:~/ubuntu/dists/xenial$ echo '556a2743e0a3028cf683894bd6030987eef7a8d2d3f47f14eab197ded5dd1b2f  main/i18n/Translation-en' | sha256sum -c
[17:18] <cjwatson> main/i18n/Translation-en: OK
[17:18] <cjwatson> should be fine
[17:19] <cjwatson> I might see whether there's some problem with the mirroring, but that might just be a currently-unavoidable race
[17:19] <wxl> well meanwhile i'm waiting on the sso to wake up from its untimely slumber, so…
[17:22] <wxl> oh derp i guess if there's no initial version it's hard for me to schedule a rebuild
[17:23] <cjwatson> ah, that's an interesting quirk
[17:23] <cjwatson> I'll just do it for you from a shell
[17:23] <cjwatson> (running)
[23:35] <bdmurray> Any SRU team people about to look at my uploads?
[23:35] <RAOF> bdmurray: Sure! What in particular would you like processed?
[23:35] <bdmurray> RAOF: software-properties and u-r-u for wily
[23:37] <tumbleweed> on that topic, I have a pile of distro-info-data uploads from before release, that nobody has processed yet