=== bjf[afk] is now known as bjf
[03:01] <slangasek> bdmurray: the '%s' % [...] seems unnecessary, you should be able to just do [var]
[03:01] <bdmurray> slangasek: okay
[03:02] <slangasek> bdmurray: (fixing locally and merging)
[09:28] <Laney> Hrm
[09:28] <Laney> gdk-pixbuf was blocked on chromium-browser autopkgtest failure, but it just migrated
[10:54] <jamespage> please could someone reject libunwind from saucy
[10:54] <jamespage> I really must upgrade and stop doing that
[11:07] <xnox> jamespage: just "upgrade" devscripts & distro-info from trusty ;-)
=== tjaalton_ is now known as tjaalton
[12:46] <xnox> infinity: cjwatson: "Supported: 9m" in Packages in trusty/main. Shouldn't that change for trusty & a step added to https://wiki.ubuntu.com/NewReleaseCycleProcess ?
[13:22] <cjwatson> xnox: Yes, file an LP bug please
[13:22] <xnox> cjwatson: against "ubuntu" or launchpad or?
[13:23] <xnox> TB?
[13:23] <cjwatson> xnox: Sorry, I meant an LP bug on Launchpad itself :)
[13:23] <cjwatson> Certainly not TB
[13:23] <cjwatson> LP has some code that hardcodes Ubuntu codenames and deals with all this stuff
[13:29] <ogra_> cjwatson, while you say fonts ... wouldnt it make sense to have a vUDS session about content packaging ? (books, wallpapers, fonts, whatever other content)
[13:29] <ogra_> (for click that is)
[13:31] <xnox> bug #1248955
[13:31] <ubot2> Launchpad bug 1248955 in Launchpad itself "Please update maintenance-timeframe.py for ubuntu 14.04 (TRUSTY)" [Undecided,Confirmed] https://launchpad.net/bugs/1248955
[13:32] <cjwatson> ogra_: I think that could be handled fine on the mailing list
[13:32] <ogra_> k
[13:32] <cjwatson> ogra_: The core facilities are all there
[13:32] <cjwatson> Just needs people to write hooks for things they care about
[16:16] <Laney> can someone aim wayland at better arm64 hardware?
[16:18] <cjwatson> sure
[16:18] <Laney> ta
[16:22] <cjwatson> hmph, birch is unwell now
[16:22]  * cjwatson goes to powerstab
[16:47] <slangasek> um, who just accepted shim-signed into -updates?
[16:48] <slangasek> bdmurray: that wasn't you, was it?
[16:48] <stgraber> slangasek: that was me
[16:49] <slangasek> stgraber: needs to be undone
[16:49] <stgraber> slangasek: hmm, ok, what's the problem?
[16:49] <slangasek> that's part of the SRU bundle for 1229572
[16:49] <slangasek> which is not verification-done
[16:49] <stgraber> hmm, why didn't pending-sru tell me as much?
[16:49] <slangasek> and that shim-signed depends on a newer version of shim than is present in -updates
[16:50] <slangasek> because by the nature of the SRU, it's all binary copies from trusty
[16:50] <slangasek> (technically shim-signed didn't need to be a binary copy; in the future I'll avoid doing it for that one)
[16:51] <slangasek> stgraber: in general, you should be suspicious of any SRU that *doesn't* have bug numbers referenced on http://people.canonical.com/~ubuntu-archive/pending-sru.html and make sure you really know what's going on with it before copying :-)
[16:52] <slangasek> stgraber: can you delete them back out of -updates, please?  since they'll be uninstallable for people
[16:52] <slangasek> hmm, it will have clobbered the version in precise-updates though
[16:53] <slangasek> stgraber: can you help with the verification today so we can get that all properly published?
[16:53] <stgraber> right, was about to say, I can do that for all of them by precise
[16:53] <bdmurray> could you manually set the phased update percentage to 0 in the mean time?
[16:54] <slangasek> bdmurray: irrelevant, the package has unsatisfiable deps so won't ever be pulled in
[16:54] <slangasek> (at least, I can't think of a case where the PUP will make a difference for this)
[16:55] <bdmurray> ah, okay
[16:55] <stgraber> slangasek: so I've removed that one from -updates from all releases for now, hopefully nobody will actually have seen it
[16:56] <stgraber> slangasek: so I suspect the easiest way of dealing with that for precise is for me to do the whole validation for bug 1229572 and if it all works, then release the whole set later today
[16:56] <ubot2> Launchpad bug 1229572 in shim-signed (Ubuntu Raring) "backport SecureBoot support from 13.10 for 12.04.4" [Undecided,Fix committed] https://launchpad.net/bugs/1229572
[16:57] <slangasek> stgraber: agreed - thanks :)
=== doko_ is now known as doko
[17:01] <stgraber> slangasek: for 2) that's shim-signed, right? so since it's a binary copy from trusty we can consider it as good as my laptop currently boots fine with and without SB using the same signed binary
[17:12] <stgraber> slangasek: shim-signed FTBFS on precise
[17:13] <stgraber> slangasek: well, shim-signed from precise-proposed, FTBFS when built against precise-proposed
[17:13] <stgraber> because it b-d on sbsigntool >= 0.6-0ubuntu4 but the precise backport of that one in 0.6-0ubuntu4~12.04.1
[17:23] <stgraber> slangasek: ^ for your review, this one builds fine against precise-proposed. (I had to bump the version a bit to be higher than the previous binary copy)
[17:28] <slangasek> stgraber: no, 2) is about rebuilding shim and making sure that if we ever need to rebuild it in precise, that it is buildable
[17:28] <slangasek> stgraber: shim-signed, looking
[17:29] <stgraber> slangasek: shim rebuild is part of 1) I believe (and I confirmed it still builds fine against -proposed a few minutes ago)
[17:29] <slangasek> stgraber: it's rebuild /and make sure the built binary works/
[17:29] <slangasek> because we're making changes to gnu-efi itself as part of this SRU batch
[17:30] <stgraber> slangasek: ok, I'll run the binary under OVMF quickly, can't test under SB though since it's unsigned (which is the confusing bit in 2) since it asks to test with SB, which is impossible)
[17:30] <slangasek> stgraber: self-signing...
[17:37] <stgraber> rebuilt shim works fine under UEFI (tested in OVMF)
[17:37] <slangasek> hurrah
[17:38] <stgraber> so once the new shim-signed is built, that'll be all the validation for precise done, since we don't have a shim-signed in -updates anymore, I'll just ingore the validation delay and move the whole stack to precise-updates
[17:44] <slangasek> stgraber: ack
[17:56] <rbasak> utlemming: ^^ you're up :)
[17:56] <utlemming> rbasak: thank :)
[17:57] <utlemming> er, thanks :)
[18:20] <stgraber> slangasek: all released now to precise-updates (after doing one last check on a precise SB system with -proposed enabled)
[18:23] <slangasek> stgraber: perfect, thanks.  Do you want to verify q/r while you're at it?  (saucy shouldn't require any further validation, the only update there is shim-signed)
[18:24] <stgraber> slangasek: yeah, I won't do an actual hardware boot though as that'd be too time consuming but I'll do the rebuilds and test shim under OVMF, that should be good enough
[18:25] <slangasek> ok
[18:26] <slangasek> also just noticed that -proposed still only had shim-signed 1.4; I'll prep another round of uploads for 1.5
[18:56] <bdmurray> stgraber: are you still doing SRU queue work?  I didn't want to overlap with you
[18:59] <stgraber> bdmurray: I'm just dealing with secureboot validation at this point, so freel free to take anything else.
[19:00] <bdmurray> got it, thanks
[19:16] <slangasek> cjwatson: did bug #1242417 not affect releases < saucy?  I was going to push shim-signed back as an SRU, wondering if I should include/exclude that change and/or worry about validating it
[19:16] <ubot2> Launchpad bug 1242417 in ubuntustudio-default-settings (Ubuntu Trusty) "UEFI install broken when GRUB_DISTRIBUTOR!=Ubuntu (e.g. Kubuntu/UbuntuStudio)" [Critical,In progress] https://launchpad.net/bugs/1242417
[19:38] <stgraber> slangasek: while not strictly needed (since -updates isn't broken) I think I'll also do the mass release to quantal and raring once I'm done with the linux-signed rebuild for both, that way we have the same stuff everywhere (so basically also ignore the validation delay for shim-signed in quantal and raring)
[19:55] <stgraber> slangasek: and all done
[20:13] <infinity> stgraber: Hrm, linux-signed was rebuilt?
[20:15] <infinity> stgraber: I was going to do a massive round of kernel SRU promotions today, do I need some context here?
[20:15] <stgraber> infinity: just a test-rebuild on my machine to make sure the new signing tools didn't break the build
[20:15] <stgraber> so nothing to worry about on your side
[20:15] <infinity> Ahh, kay.
[20:57] <infinity> +        ("9m", UbuntuMaintenance.SUPPORTED_SEEDS),
[20:57] <infinity> xnox: ^
[20:57] <infinity> xnox: That doesn't seem right.
[20:58] <stgraber> infinity: is that from the LP Supported override code?
[20:59] <infinity> Yeah.
[21:00] <stgraber> I know this was updated in a bit of a rush when we forgot to change it to 9 months last release, though it's weird that this would have broken LTS handling somehow
[21:00] <infinity> Maybe I need context, and "SUPPORTED" isn't what I think it is.
[21:00] <xnox> infinity: adding armel back, as we still publish quantal.
[21:01] <xnox> SUPPORTED_SEEDS = ["all"]
[21:01] <infinity> Ahh, indeed, SUPPORTED_SEEDS is...
[21:01] <infinity> What you said.
[21:01] <infinity> Badly named variable is badly named.
[21:02] <xnox> infinity: so only SERVER_SEEDS and DESKTOP_SEEDS get 5y. All other seeds get 9m. the rest is universe, unsupported.
[21:02] <infinity> xnox: Yeah, I followed the code and got there.
[21:02] <xnox> infinity: server + desktop are: server-ship  supported-server ship supported-desktop supported-desktop-extra
[21:02] <infinity> xnox: Like I said, just a terribly named variable.
[21:03] <stgraber> that seems vaguely wrong
[21:03] <xnox> ah, ok.
[21:03] <infinity> stgraber: It's a bit more complex than that.
[21:03] <stgraber> for example I'd expect something in the server supported seed to get 5y and apparently that's not the case
[21:04] <infinity>     SERVER_SEEDS = [
[21:04] <infinity>         "server-ship",
[21:04] <infinity>         "supported-server",
[21:04] <infinity>         ]
[21:04] <infinity> It should, according to the code.
[21:04] <infinity> For precise, that is.  This MP is adding trusty, so everything's 9m right now.
[21:05] <xnox> infinity: stgraber: I followed Precise example and then: (a) change 18m -> 9m for SUPPORTED; (b) dropped kubuntu from DISTRO_NAMES for LTS; (c) added armhf + arm64 to pseudo supported arches.
[21:05] <stgraber> bah, yeah, I checked against trusty, ignore me (was missing context a bit here ;))
[21:05] <stgraber> xnox: what's the URL to that MP?
[21:05] <xnox> stgraber: =)))) the merge proposal is exactly to fix this now, instead of on the release day.
[21:05] <infinity> https://code.launchpad.net/~xnox/launchpad/update-maintenance-check-3/+merge/194416
[21:06] <stgraber> ok, so are we planning on adding all the LTS flavours to DISTRO_NAMES or do we just not care about Supported reflecting reality for those?
[21:06] <xnox> stgraber: cause i remember colin was twiddling it for raring release.
[21:07] <stgraber> looks like back in precise we didn't bother at least (I just checked Edubuntu and we don't have Supported: 5y there)
[21:07] <xnox> stgraber: i don't know. I know that Kubuntu is LTS for Precise and one can get comercial support for it from the primary ubuntu sponsor.
[21:07] <infinity> stgraber: I think we need to discuss that.  The plan was to extend the Supported field to something machine-parsable and more informative for flavours supported by !Canonical, but that never happened.
[21:07] <stgraber> xnox: yeah, that was the whole, oops, we completely forgot to update it from 18m to 9m up until the last minute ;)
[21:08] <stgraber> infinity: yeah, I guess we can stick to whatever we had in precise, nobody complained about this I believe, so that's fine
[21:08] <infinity> stgraber: So, we could still make time to do that work, *or* we could just use the field as-is and announce support for everyone who says they have it, *or* do what we apparently did in precise and let people advertise their own support.
[21:08] <stgraber> infinity: FWIW I have scripts running in cron generating said support lists, we just never bothered to integrate that with the archive somehow ;)
[21:09] <xnox> infinity: at the moment supported fields exactly list Canonical commitments. Who knows what happens to !Canonical, we ain't going to republish release pocket.
[21:09] <stgraber> http://people.canonical.com/~stgraber/supported-packages/
[21:09] <infinity> xnox: I know.
[21:09] <stgraber> xnox: not really true, we unfortunately have packages without Supported: that are supported for LTS and packages that are Supported: which really aren't ;)
[21:10] <xnox> stgraber: software has bugs, otherwise i'd be out of job =)
[21:10] <xnox> stgraber: yeah, there are blurred lines =)
[21:11] <stgraber> xnox: because the set of packages covered by the security team isn't the same set as the one supported under Ubuntu Advantage. There are also a few cases where we have source packages that are marked as supported but where the security team only commited to a subset of the binaries, ...
[21:12] <stgraber> the plan was to move those support declarations to live outside the archive so they can evolve on their own and we could split Ubuntu Advantage from Canonical Security and add flavour support there too, but we've so far had more pressing stuff to work on
[21:12] <xnox> stgraber: I knew about security lists, but not about per binary splits.
[21:12] <infinity> stgraber: That last case works fine.  There's no Supported field for, say, nscd.
[21:12] <infinity> (Not, it all falls apart if someone SEEDs an unsupported binary, but that's a fault in the seeds, not the method)
[21:13] <xnox> infinity: well, but there is no security seed.
[21:13] <xnox> infinity: and there arguably should be one.
[21:13] <infinity> Oh, this arguably needs a better design, and vorlon and I talked about it at length.
[21:14] <infinity> And then he sacrificed me to another manager.
[21:14] <xnox> =)))))))
[21:14] <stgraber> xnox: we currently assume any binary package (not source) in main is covered, which isn't ideal but is close enough for now
[21:14] <xnox> .... clearly it was a hint your approach was the wrong one ;-)
[21:15] <xnox> stgraber: i'm yet to see a security upload for autoconf =)
[21:16] <stgraber> the new support declaration stuff is a clear requirement for the archive reorg since without the main/universe split, we'd loose our current way of managing support length, but since we haven't been making much progress on the archive reorg side lately, nothing has been moving much (that whole phone/tablet stuff took away the already limited resources)
[21:16] <xnox> stgraber: i don't think the build-dependencies are actually covered by security team as they typically pose no risk, we are a binary distribution not a source one =)
[21:17] <stgraber> xnox: the security team typically have scripts looking for CVEs for any package in main, whatever the reason for the package to be in main, then triage those based on the actual effect for the distro. So something that's strictly build-dep likely won't have a very high priority, but I'd still expect it to show up on their reports.
[21:18] <xnox> i see.
[21:18] <xnox> .... anyway =)
[21:18] <xnox> stgraber: i hope there will be an ack on the branch and to get it merged before we release trusty.
[21:20] <stgraber> infinity: did you already send a branch to kill people.u.c from maintenance-check.py? (just noticed it again while reading through it for the Supported field changes)
[21:22] <infinity> stgraber: cjwatson has a branch in flight to make it configurable for cron.germinate, he may have missed maint-check, didn't look yet.
[21:24] <infinity> https://code.launchpad.net/~cjwatson/launchpad/configurable-germinate-base/+merge/194340
[21:24] <infinity> Yeah, looks like it just got generate-extra-overrides, not the other.
[22:23] <slangasek> stgraber: yes, given that the shim-signed change was just dropping the build-dep version, that seems fine to me - thanks for taking care of it!
[22:24] <slangasek> infinity: ... and since then I've forgotten what we even talked about, so I'm blissfully ignorant