[04:07] <infinity> bdmurray: Do I need to note the irony that an SRU prepared by you for a bug filed by you has tripped your lack-of-validation check? :)
[04:07] <infinity> bdmurray: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1429967
[04:07] <ubot93> Launchpad bug 1429967 in dkms (Ubuntu Utopic) "dkms apport package hook doesn't write package version to apport Package key" [High,Fix committed]
[05:22] <bdmurray> Is that irony or some bad karma?
[05:42] <Mirv> hmm. ubuntu-ui-toolkit stuck in proposed, I only find an arm64 reference in update_output regarding ubuntu-ui-toolkit-autopilot but I'm not sure how to parse it
[05:43] <Mirv> I first thought it might be related to https://launchpad.net/ubuntu/+source/unity-scopes-api/0.6.19+15.10.20150706.1-0ubuntu1 which had arm64 failure yesterday but it got already fixed in https://launchpad.net/ubuntu/+source/unity-scopes-api/0.6.19+15.10.20150708-0ubuntu1
[09:31] <tjaalton> infinity: daily trusty image works now, backport stack is installed
[09:32] <infinity> tjaalton: \o/
[09:39] <Laney> Mirv: It added a dep on ubuntu-keyboard-autoiplot which isn't there on arm64
[09:39] <cjwatson> Heh, I'd *just* got there too
[09:40] <Laney> :)
[09:41] <Laney> Does britney stop at the first arch which breaks?
[09:45] <Mirv> bzoltan_: ^
[09:47] <Laney> Mirv: Suggest setting up chdist to reproduce this kind of thing
[09:48] <cjwatson> Laney: No
[09:49] <Laney> cjwatson: Don't understand why it doesn't list powerpc ppc64el as uninstallable then
[09:49] <Mirv> thanks Laney, I had forgotten about chdist for this
[09:50] <cjwatson> Laney: Maybe they were uninstallable before?
[09:50] <cjwatson> No, apparently not ...
[09:50] <cjwatson> OK, maybe it does sometimes stop at the first
[09:51] <cjwatson> I don't quite remember
[09:52] <Laney> Seems plausible as every other non-hinted uninstallable only lists one arch
[09:54] <cjwatson> Oh, right, didn't notice that this wasn't an autohinted thing.
[11:29] <Mirv> I wonder if qtdeclarative-opensource-src could be allowed to migrate to release pocket? there's only kscreen autopkgtest regression blocking it, and it was regressing already before the qtdeclarative upload.
[12:11] <Laney> Mirv: did you check with Riddell about fixing it?
[12:12] <Mirv> Laney: excellent idea! Riddell, would you have time to look at the kscreen 5.3.2 autopkgtest failure, or consider whether you could override qtdeclarative update to ignore it if kscreen fixing would take time?
[13:43] <rbasak> Someone just independently pointed me to http://people.canonical.com/~ubuntu-archive/phased-updates.html
[13:43] <rbasak> grub2-signed 50%, grub2 70%.
[13:44] <rbasak> That's not good I think. They doesn't necessarily overlap either.
[13:44] <rbasak> Can we somehow bind the phasing of those together?
[13:44] <ScottK> Actually, if they have to be installed together, I think they both need to be 100% as there's no guarantee the same 50% get both packages.
[13:45] <rbasak> The trouble is that if a user sees grub2 but not grub2-signed then it seems that grub2-signed ends up being removed in order to update grub2, and that breaks things.
[13:46] <rbasak> I presume that's because there's nothing that depends on grub2-signed because the installer it it there?
[13:46] <rbasak> (I mean the binary grub-efi-amd64-signed of course)
[13:46] <cjwatson> ScottK: It's probably not terrible since one is uninstallable without the other.
[13:47] <cjwatson> Removal is weird, I'm surprised that would happen.
[13:47] <cjwatson> I would have expected the rest of grub2 to be held back.
[13:47] <cjwatson> Let me at least bump the grub2-signed phased update percentages, though.
[13:47] <rbasak> cjwatson: http://irclogs.ubuntu.com/2015/07/08/%23ubuntu-kernel.html#t16:15 happened yesterday. I wonder if you can make any sense of that?
[13:47] <ScottK> Having a post-release update be uninstallable is a significant issue I think.
[13:48] <cjwatson> rbasak: I don't know, I'm afraid
[13:48] <rbasak> He said he used update-manager
[13:48] <cjwatson> ScottK: Perhaps update-manager should consider them bound together in some way, as it already does with source packages
[13:48] <rbasak> Which suggests to me that update-manager did remove grub2-signed, but that isn't clear.
[13:48] <ScottK> Perhaps, but not everyone uses that.
[13:48] <rbasak> I'll ask him for his history.log I think.
[13:49] <cjwatson> ScottK: For people who don't, the phased update percentages aren't considered.
[13:49] <ScottK> True.
[13:49] <cjwatson> ScottK: u-m is what processes them, unless there's a similar Kubuntu thing
[13:49] <ScottK> There is, but it doesn't consider them.
[13:49] <cjwatson> rbasak: Also, for utopic, note that they have the same PUP
[13:50] <cjwatson> And that was the case at hand here
[13:50] <ScottK> rbasak and I were also discussing the idea of modifying sru-release to warn if you try to release grub2, but not grub2 signed.
[13:50] <ScottK> That would have at least avoided me releasing one without the other.
[13:50] <cjwatson> Seems like a good idea.  It might not be terrible to hardcode this case in u-m either; it's pretty specialised
[13:50] <cjwatson> Most combinations of multiple sources in SRUs aren't lockstep at the client end like this
[13:51] <rbasak> I suggested having a list of hardcoded "special" packages which it'll refuse to touch if you mention without a force flag
[13:51] <rbasak> Maybe a dictionary keyed on package with a text explanation in the value so you know what to do.
[13:51] <rbasak> Simple so it doesn't try to be smart and do it wrong, but hopefully effective enough to prevent accidents.
[13:52] <ScottK> I think it needs to be both sru-release and u-m since even if you release the SRUs together there's no guarantee a user gets them both.
[13:53] <cjwatson> Yeah
[13:54] <rbasak> What's u-m?
[13:54] <ScottK> update-manager
[13:54] <rbasak> Ah, thanks.
[13:57] <infinity> cjwatson: It would seem like a bug if u-m is removing grub2-signed to do the upgrade anyway, though.  It's meant to only remove in the Conflict/Replace special case, and otherwise tell you where to go and, possibly, how to get there.
[13:57] <cjwatson> Indeed!
[13:58] <cjwatson> Of course we aren't told if the user in this case overrode stuff ...
[13:58] <infinity> (apt-get, on the other hand, will remove grub2-signed with glee)
[13:59] <infinity> Similar (but slightly different) problem for linux-signed, and we only avoid seeing that because almost every kernel SRU is a security release, thus phased 100%
[13:59] <rbasak> I've asked for his history.log to hopefully understand better what happened, but he'll be a while getting back to me.
[14:27] <infinity> cjwatson: Good news, we got apt logs and they confirm that update-manager didn't do a stupid.
[15:10] <teward> who's on vanguard, if anoyne?  (I"m not sure the schedule...)
[15:18] <teward> main reason for asking is I'd like an SRU looked at / approved which adds apport hooks into the Vivid nginx package - if only because we have a number of NotUseful reports which don't have enough debugging data to debug the cause of a postinstall script failure (which ties back to "Job failed to start" errors)
[15:19] <teward> i'm working on testbuilds now, and if all works i'm uploading to wily to make sure it has the change to
[15:19] <teward> but i'd like it all done today or soon :P
[15:20] <rbasak> teward: for SRUs https://wiki.ubuntu.com/StableReleaseUpdates#Publishing has the rota. You want bdmurray I guess. Not sure if he's around today though.
[15:21] <teward> rbasak: i don't think he is (see -meeting)
[15:21] <teward> hence the question of who's on vanguard
[15:21] <teward> s/vanguard/duty for today/
[15:21] <rbasak> I don't think the SRU team maintain a vanguard person
[15:21] <teward> ok
[15:22] <rbasak> But you can ask here and they do respond to urgent stuff
[15:22] <teward> https://wiki.ubuntu.com/StableReleaseUpdates#Publishing says to poke the vanguards who're on the schedule.
[15:22] <rbasak> I mean that they don't cover absences :)
[15:22] <teward> rbasak: less urgent more "Need this before we get more crap bugs" (that whole nginx postinstall script failure nonuseful debug data issue i have complained about for at least a month)
[15:22] <teward> rbasak: ack
[15:49] <cjwatson> infinity: Oh good.
[17:08] <slangasek> cjwatson: another bug report has landed on our doorstep about UbuntuHashes (bug #1288593).  Can you refresh my memory why this hasn't been killed off in favor of directing users to the gpg-signed SUMS files we publish?
[17:08] <ubot93> bug 1288593 in ubuntu-docs (Ubuntu) "Please include SHA256 or SHA512 hashes on Ubuntu Hashes page" [Undecided,Confirmed] https://launchpad.net/bugs/1288593
[17:08] <cjwatson> slangasek: I thought we had an agreement to kill it off at this point
[17:09] <slangasek> oh, ok
[17:09] <slangasek> so should we just remove that from help.u.c?
[17:09] <cjwatson> somewhere ...
[17:09] <cjwatson> somebody would have to chase down links etc. and replace with good user-facing instructions on verifying hashes
[17:11] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1219589 and https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1349715 come up in my searches
[17:11] <ubot93> Launchpad bug 1219589 in ubuntu-docs (Ubuntu) "ubuntu-12.04.3-desktop-amd64.iso md5sum missing from https://help.ubuntu.com/community/UbuntuHashes" [Undecided,Fix released]
[17:11] <ubot93> Launchpad bug 1349715 in ubuntu-docs (Ubuntu) "Ubuntu hashes for 14.04.1 missing on https://help.ubuntu.com/community/UbuntuHashes" [Medium,Fix released]
[17:11] <cjwatson> (I had a mail thread with ubuntu-docs folks as well)
[17:12] <cjwatson> must run though
[17:12] <slangasek> askubuntu.com seems to point to the right place, but does not talk about gpg verification
[17:12] <slangasek> cjwatson: ok, cheers
=== kickinz1 is now known as kickinz1|eod
=== kickinz1|eod is now known as kickinz1
[18:18] <Riddell> Mirv: Laney: I'm away this week, feel free to override if it's blocking