Bug #11851

post-2.6 stable uses now expired 2016091902 APT snapshot

Added by anonym 2016-09-29 02:35:37 . Updated 2016-11-15 18:23:34 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Build system
Target version:
Tails_2.7
Start date:
2016-09-29
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

From a build of a branch based on stable:

09:14:44 Get:1 http://time-based.snapshots.deb.tails.boum.org jessie InRelease [7650 B]
09:14:44 Get:2 http://deb.tails.boum.org stable InRelease [9675 B]
09:14:44 Get:3 http://time-based.snapshots.deb.tails.boum.org jessie/updates InRelease [7597 B]
09:14:44 Get:4 http://time-based.snapshots.deb.tails.boum.org jessie-backports InRelease [7625 B]
09:14:44 Get:5 http://time-based.snapshots.deb.tails.boum.org sid InRelease [7653 B]
09:14:44 Get:6 http://time-based.snapshots.deb.tails.boum.org stretch InRelease [7655 B]
09:14:44 Get:7 http://time-based.snapshots.deb.tails.boum.org obfs4proxy InRelease [2522 B]
09:14:44 Get:8 http://time-based.snapshots.deb.tails.boum.org jessie InRelease [2520 B]
09:14:44 Get:9 http://time-based.snapshots.deb.tails.boum.org sid InRelease [2520 B]
09:14:45 E: Release file for http://time-based.snapshots.deb.tails.boum.org/debian/2016091902/dists/jessie/InRelease is expired (invalid since 2h 29min 19s). Updates for this repository will not be applied.
09:14:45 P: Begin unmounting filesystems...
09:14:45


Indeed, when I made the new snapshot late in the Tails 2.6 release process, I am sure I forgot to extend its expiry. Since this was a “creative” solution not part of the normal release process, I don’t think more documentation can help prevent this in the future.

What to do? Can we recreate it? Should I pick today’s snapshot? The first one after 2016091902 that still hasn’t expired?

Subtasks

History

#1 Updated by anonym 2016-09-29 02:36:39

  • Assignee set to CyrilBrulebois
  • QA Check set to Info Needed

anonym wrote:
> What to do? Can we recreate it?

I think the best one to answer this question is either you…

#2 Updated by anonym 2016-09-29 02:37:02

  • Assignee changed from CyrilBrulebois to intrigeri

anonym wrote:
> anonym wrote:
> > What to do? Can we recreate it?
>
> I think the best one to answer this question is either you…

… or you.

#3 Updated by CyrilBrulebois 2016-09-29 02:54:56

As far as I can tell, you only need to bump its validity date, see files/reprepro/snapshots/time_based/tails-bump-apt-snapshot-valid-until in puppet-tails.git

It’s not about recreating the snapshot, it’s just about updating its Valid-Until field (Release file).

#4 Updated by anonym 2016-09-29 07:41:18

CyrilBrulebois wrote:
> As far as I can tell, you only need to bump its validity date, see files/reprepro/snapshots/time_based/tails-bump-apt-snapshot-valid-until in puppet-tails.git
>
> It’s not about recreating the snapshot, it’s just about updating its Valid-Until field (Release file).
It seems to be deleted (cleanup?) because when I try to bump the expiry of it this happens:

# ssh reprepro-time-based-snapshots@incoming.deb.tails.boum.org tails-bump-apt-snapshot-valid-until debian 2016091902 75
E: no Release files under snapshots/2016091902, buggy serial?


So I guess it would need to be (re)created, after all.

#5 Updated by CyrilBrulebois 2016-09-29 09:53:53

Ah, indeed. I seem to remember having suggested keeping a list of snapshots currently used (present somewhere in a git branch) to make sure they’re not automatically cleaned up, even when expiry happens. Either I did and intrigeri decided we wouldn’t need that, or I didn’t and that’s entirely my fault…

If that snapshot was pruned, I don’t think we can recreate it as it was (except maybe by fiddling with snapshot.debian.org for the Debian parts). I’ll let intrigeri comment further on this.

#6 Updated by intrigeri 2016-09-30 01:07:55

  • Assignee changed from intrigeri to anonym

> If that snapshot was pruned, I don’t think we can recreate it as it was (except maybe by fiddling with snapshot.debian.org for the Debian parts). I’ll let intrigeri comment further on this.

It was apparently pruned, which means that something went wrong during the 2.6 release process and the used snapshots’ expiration date were not bumped… possibly because the snapshots serials were bumped after freezing them and bumping their expiration date (commit:d4969a5e928b389f54bb3deae20e2e9b91c30283 perhaps?).

So, I think that what needs to be done now is:

  • bump serials to something as close as possible as the ones used in 2.6, make sure it works fine and merge;
  • make sure that this mistake does not happen again: if my guess is correct, then it should be enough to add a sanity check somewhere in the release process (possibly around the time when we create the tagged snapshots?).

anonym, can you please take care of those?

#7 Updated by bertagaz 2016-09-30 05:13:03

CyrilBrulebois wrote:
> If that snapshot was pruned, I don’t think we can recreate it as it was (except maybe by fiddling with snapshot.debian.org for the Debian parts). I’ll let intrigeri comment further on this.

If it can be of any help to rebuild this snapshot, I’ve build a branch based on stable (but with other merged in) on the 2016 Sep. 27, and my apt-cacher-ng instance seems to have time-based snapshosts from current stable APT_snapshots serial (2016091902). I’m unsure how it can resurrect this snapshot though.

#8 Updated by anonym 2016-09-30 05:18:02

bertagaz wrote:
> CyrilBrulebois wrote:
> > If that snapshot was pruned, I don’t think we can recreate it as it was (except maybe by fiddling with snapshot.debian.org for the Debian parts). I’ll let intrigeri comment further on this.
>
> If it can be of any help to rebuild this snapshot, I’ve build a branch based on stable (but with other merged in) on the 2016 Sep. 27, and my apt-cacher-ng instance seems to have time-based snapshosts from current stable APT_snapshots serial (2016091902). I’m unsure how it can resurrect this snapshot though.

Let’s KISS a bit. I’ve bumped 2016092002 so it will live until 2016-12-14 and I am currently building stable using that snapshot for both debian and torproject. If the packages diff is empty or small enough, I’ll make that the new snapshot. Stay tuned…

#9 Updated by intrigeri 2016-09-30 05:46:31

> Let’s KISS a bit.

ACK

#10 Updated by anonym 2016-09-30 06:49:49

  • Status changed from Confirmed to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 0 to 100
  • QA Check changed from Info Needed to Pass

That worked, and the package diff only contained security fixes, which is still expected.

#11 Updated by anonym 2016-09-30 11:50:55

  • Status changed from Fix committed to In Progress

Applied in changeset commit:fc1b02392a0b1d7b8d978c0254da6e65b62981af.

#12 Updated by anonym 2016-09-30 11:50:56

  • Status changed from In Progress to Fix committed

Applied in changeset commit:fc1b02392a0b1d7b8d978c0254da6e65b62981af.

#13 Updated by bertagaz 2016-11-15 18:23:34

  • Status changed from Fix committed to Resolved