/srv/irclogs.ubuntu.com/2013/11/07/#ubuntu-release.txt

=== bjf[afk] is now known as bjf
slangasekbdmurray: the '%s' % [...] seems unnecessary, you should be able to just do [var]03:01
bdmurrayslangasek: okay03:01
slangasekbdmurray: (fixing locally and merging)03:02
LaneyHrm09:28
Laneygdk-pixbuf was blocked on chromium-browser autopkgtest failure, but it just migrated09:28
jamespageplease could someone reject libunwind from saucy10:54
jamespageI really must upgrade and stop doing that10:54
xnoxjamespage: just "upgrade" devscripts & distro-info from trusty ;-)11:07
=== tjaalton_ is now known as tjaalton
xnoxinfinity: cjwatson: "Supported: 9m" in Packages in trusty/main. Shouldn't that change for trusty & a step added to https://wiki.ubuntu.com/NewReleaseCycleProcess ?12:46
cjwatsonxnox: Yes, file an LP bug please13:22
xnoxcjwatson: against "ubuntu" or launchpad or?13:22
xnoxTB?13:23
cjwatsonxnox: Sorry, I meant an LP bug on Launchpad itself :)13:23
cjwatsonCertainly not TB13:23
cjwatsonLP has some code that hardcodes Ubuntu codenames and deals with all this stuff13:23
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:29
xnoxbug #124895513:31
ubot2Launchpad bug 1248955 in Launchpad itself "Please update maintenance-timeframe.py for ubuntu 14.04 (TRUSTY)" [Undecided,Confirmed] https://launchpad.net/bugs/124895513:31
cjwatsonogra_: I think that could be handled fine on the mailing list13:32
ogra_k13:32
cjwatsonogra_: The core facilities are all there13:32
cjwatsonJust needs people to write hooks for things they care about13:32
Laneycan someone aim wayland at better arm64 hardware?16:16
cjwatsonsure16:18
Laneyta16:18
cjwatsonhmph, birch is unwell now16:22
* cjwatson goes to powerstab16:22
slangasekum, who just accepted shim-signed into -updates?16:47
slangasekbdmurray: that wasn't you, was it?16:48
stgraberslangasek: that was me16:48
slangasekstgraber: needs to be undone16:49
stgraberslangasek: hmm, ok, what's the problem?16:49
slangasekthat's part of the SRU bundle for 122957216:49
slangasekwhich is not verification-done16:49
stgraberhmm, why didn't pending-sru tell me as much?16:49
slangasekand that shim-signed depends on a newer version of shim than is present in -updates16:49
slangasekbecause by the nature of the SRU, it's all binary copies from trusty16: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:50
slangasekstgraber: 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:51
slangasekstgraber: can you delete them back out of -updates, please?  since they'll be uninstallable for people16:52
slangasekhmm, it will have clobbered the version in precise-updates though16:52
slangasekstgraber: can you help with the verification today so we can get that all properly published?16:53
stgraberright, was about to say, I can do that for all of them by precise16:53
bdmurraycould you manually set the phased update percentage to 0 in the mean time?16:53
slangasekbdmurray: irrelevant, the package has unsatisfiable deps so won't ever be pulled in16:54
slangasek(at least, I can't think of a case where the PUP will make a difference for this)16:54
bdmurrayah, okay16:55
stgraberslangasek: so I've removed that one from -updates from all releases for now, hopefully nobody will actually have seen it16:55
stgraberslangasek: 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 today16:56
ubot2Launchpad bug 1229572 in shim-signed (Ubuntu Raring) "backport SecureBoot support from 13.10 for 12.04.4" [Undecided,Fix committed] https://launchpad.net/bugs/122957216:56
slangasekstgraber: agreed - thanks :)16:57
=== doko_ is now known as doko
stgraberslangasek: 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 binary17:01
stgraberslangasek: shim-signed FTBFS on precise17:12
stgraberslangasek: well, shim-signed from precise-proposed, FTBFS when built against precise-proposed17:13
stgraberbecause it b-d on sbsigntool >= 0.6-0ubuntu4 but the precise backport of that one in 0.6-0ubuntu4~12.04.117:13
stgraberslangasek: ^ 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:23
slangasekstgraber: no, 2) is about rebuilding shim and making sure that if we ever need to rebuild it in precise, that it is buildable17:28
slangasekstgraber: shim-signed, looking17:28
stgraberslangasek: shim rebuild is part of 1) I believe (and I confirmed it still builds fine against -proposed a few minutes ago)17:29
slangasekstgraber: it's rebuild /and make sure the built binary works/17:29
slangasekbecause we're making changes to gnu-efi itself as part of this SRU batch17:29
stgraberslangasek: 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
slangasekstgraber: self-signing...17:30
stgraberrebuilt shim works fine under UEFI (tested in OVMF)17:37
slangasekhurrah17:37
stgraberso 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-updates17:38
slangasekstgraber: ack17:44
rbasakutlemming: ^^ you're up :)17:56
utlemmingrbasak: thank :)17:56
utlemminger, thanks :)17:57
stgraberslangasek: all released now to precise-updates (after doing one last check on a precise SB system with -proposed enabled)18:20
slangasekstgraber: 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:23
stgraberslangasek: 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 enough18:24
slangasekok18:25
slangasekalso just noticed that -proposed still only had shim-signed 1.4; I'll prep another round of uploads for 1.518:26
bdmurraystgraber: are you still doing SRU queue work?  I didn't want to overlap with you18:56
stgraberbdmurray: I'm just dealing with secureboot validation at this point, so freel free to take anything else.18:59
bdmurraygot it, thanks19:00
slangasekcjwatson: 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 it19:16
ubot2Launchpad 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/124241719:16
stgraberslangasek: 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:38
stgraberslangasek: and all done19:55
infinitystgraber: Hrm, linux-signed was rebuilt?20:13
infinitystgraber: I was going to do a massive round of kernel SRU promotions today, do I need some context here?20:15
stgraberinfinity: just a test-rebuild on my machine to make sure the new signing tools didn't break the build20:15
stgraberso nothing to worry about on your side20:15
infinityAhh, kay.20:15
infinity+        ("9m", UbuntuMaintenance.SUPPORTED_SEEDS),20:57
infinityxnox: ^20:57
infinityxnox: That doesn't seem right.20:57
stgraberinfinity: is that from the LP Supported override code?20:58
infinityYeah.20:59
stgraberI 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 somehow21:00
infinityMaybe I need context, and "SUPPORTED" isn't what I think it is.21:00
xnoxinfinity: adding armel back, as we still publish quantal.21:00
xnoxSUPPORTED_SEEDS = ["all"]21:01
infinityAhh, indeed, SUPPORTED_SEEDS is...21:01
infinityWhat you said.21:01
infinityBadly named variable is badly named.21:01
xnoxinfinity: so only SERVER_SEEDS and DESKTOP_SEEDS get 5y. All other seeds get 9m. the rest is universe, unsupported.21:02
infinityxnox: Yeah, I followed the code and got there.21:02
xnoxinfinity: server + desktop are: server-ship  supported-server ship supported-desktop supported-desktop-extra21:02
infinityxnox: Like I said, just a terribly named variable.21:02
stgraberthat seems vaguely wrong21:03
xnoxah, ok.21:03
infinitystgraber: It's a bit more complex than that.21:03
stgraberfor example I'd expect something in the server supported seed to get 5y and apparently that's not the case21:03
infinity    SERVER_SEEDS = [21:04
infinity        "server-ship",21:04
infinity        "supported-server",21:04
infinity        ]21:04
infinityIt should, according to the code.21:04
infinityFor precise, that is.  This MP is adding trusty, so everything's 9m right now.21:04
xnoxinfinity: 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
stgraberbah, yeah, I checked against trusty, ignore me (was missing context a bit here ;))21:05
stgraberxnox: what's the URL to that MP?21:05
xnoxstgraber: =)))) the merge proposal is exactly to fix this now, instead of on the release day.21:05
infinityhttps://code.launchpad.net/~xnox/launchpad/update-maintenance-check-3/+merge/19441621:05
stgraberok, 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
xnoxstgraber: cause i remember colin was twiddling it for raring release.21:06
stgraberlooks like back in precise we didn't bother at least (I just checked Edubuntu and we don't have Supported: 5y there)21:07
xnoxstgraber: 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
infinitystgraber: 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
stgraberxnox: yeah, that was the whole, oops, we completely forgot to update it from 18m to 9m up until the last minute ;)21:07
stgraberinfinity: yeah, I guess we can stick to whatever we had in precise, nobody complained about this I believe, so that's fine21:08
infinitystgraber: 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
stgraberinfinity: FWIW I have scripts running in cron generating said support lists, we just never bothered to integrate that with the archive somehow ;)21:08
xnoxinfinity: 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
stgraberhttp://people.canonical.com/~stgraber/supported-packages/21:09
infinityxnox: I know.21:09
stgraberxnox: not really true, we unfortunately have packages without Supported: that are supported for LTS and packages that are Supported: which really aren't ;)21:09
xnoxstgraber: software has bugs, otherwise i'd be out of job =)21:10
xnoxstgraber: yeah, there are blurred lines =)21:10
stgraberxnox: 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:11
stgraberthe 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 on21:12
xnoxstgraber: I knew about security lists, but not about per binary splits.21:12
infinitystgraber: 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:12
xnoxinfinity: well, but there is no security seed.21:13
xnoxinfinity: and there arguably should be one.21:13
infinityOh, this arguably needs a better design, and vorlon and I talked about it at length.21:13
infinityAnd then he sacrificed me to another manager.21:14
xnox=)))))))21:14
stgraberxnox: we currently assume any binary package (not source) in main is covered, which isn't ideal but is close enough for now21:14
xnox.... clearly it was a hint your approach was the wrong one ;-)21:14
xnoxstgraber: i'm yet to see a security upload for autoconf =)21:15
stgraberthe 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
xnoxstgraber: 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:16
stgraberxnox: 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:17
xnoxi see.21:18
xnox.... anyway =)21:18
xnoxstgraber: i hope there will be an ack on the branch and to get it merged before we release trusty.21:18
stgraberinfinity: 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:20
infinitystgraber: cjwatson has a branch in flight to make it configurable for cron.germinate, he may have missed maint-check, didn't look yet.21:22
infinityhttps://code.launchpad.net/~cjwatson/launchpad/configurable-germinate-base/+merge/19434021:24
infinityYeah, looks like it just got generate-extra-overrides, not the other.21:24
slangasekstgraber: 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:23
slangasekinfinity: ... and since then I've forgotten what we even talked about, so I'm blissfully ignorant22:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!