Bug #17353

.build-manifest discrepancies

Added by CyrilBrulebois 2019-12-16 01:53:43 . Updated 2019-12-25 13:09:46 .

Status:
In Progress
Priority:
Normal
Assignee:
CyrilBrulebois
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Seen with 4.1.1.

I’m not sure why building from a tag results in different contents in .build-manifest files.

Due to delays documented elsewhere, the build in Jenkins started after the security snapshot was updated, resulting in this diff between the Jenkins build and my official/local one:

kibi@armor:~/work/clients/tails/release/artifacts$ diff -u jenkins/tails-amd64-4.1.1.build-manifest tails-amd64-4.1.1.build-manifest 
--- jenkins/tails-amd64-4.1.1.build-manifest    2019-12-16 02:07:07.101295056 +0100
+++ tails-amd64-4.1.1.build-manifest    2019-12-16 01:18:03.631713792 +0100
@@ -3,7 +3,7 @@
   debian:
     reference: '2019111801'
   debian-security:
-    reference: '2019121504'
+    reference: '2019121503'
   torproject:
     reference: '2019100904'
 packages:

We’re building from a tag, there’s no reason to have irrelevant references pop up in the build results?

Subtasks

Related issues

Related to Tails - Bug #17361: Streamline our release process Confirmed

History

#1 Updated by intrigeri 2019-12-16 13:05:03

> We’re building from a tag, there’s no reason to have irrelevant references pop up in the build results?

IIRC these differences are indeed irrelevant because when building from a tag, we don’t use time-based snapshots, so these serial numbers won’t be used.

Which step of the release process led you to do this diff?

#2 Updated by CyrilBrulebois 2019-12-17 00:06:59

Several edits (sorry): Checking the reproducibility bit: downloading the shasum file from Jenkins and feeding it to the shasum command to check most local files (of course .buildlog and some other things would be different) match those on Jenkins, the .build-manifest checksum mismatch wasn’t quite expected and made me hold my breath for a little while…

#3 Updated by intrigeri 2019-12-17 11:53:52

  • related to Bug #17361: Streamline our release process added

#4 Updated by intrigeri 2019-12-17 11:57:58

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|b980b5e48202ec45ae8e21010c200d38208a9838.

#5 Updated by intrigeri 2019-12-17 11:59:57

  • Status changed from In Progress to Needs Validation
  • Assignee set to CyrilBrulebois
  • Type of work changed from Code to Contributors documentation

Got it, thanks for the clear explanation! I’ve clarified the doc with commit:b980b5e48202ec45ae8e21010c200d38208a9838. Would this have avoided the doubts and the “hold my breath for a little while” problem?

#6 Updated by CyrilBrulebois 2019-12-22 15:58:33

This doc update looks fine enough, thanks.

I’m not convinced the underlying difference should be happening in the first place though, even if it might not be worth fixing (time/cost-wise).

#7 Updated by intrigeri 2019-12-25 13:09:46

  • Status changed from Needs Validation to In Progress

Hi,

> This doc update looks fine enough, thanks.

Thanks for the quick review!

> I’m not convinced the underlying difference should be happening in the first place though, even if it might not be worth fixing (time/cost-wise).

Indeed, the origin_references data is misleading when building from a tag. We could for example teach generate-build-manifest not to include this data when building from a tag. The end result would be cleaner and less confusing. At the moment I can think of no serious new problem this solution would cause: I’m aware of no consumer of our build-manifests generated while building from a tag, that care about origin_references. Having the format of build manifests vary depending on $reason could cause other kinds of confusion, and make implementation of new consumers a tiny bit more complicated, but I’m not worried about this: apart of tails-prepare-tagged-apt-snapshot-import (which takes as input a build manifest generated before tagging), all the consumers of our build manifests that I’m aware of only look into the packages section and could not care less about the origin_references section.

Now that we’ve already solved the only practical problem (that I’m aware of) caused by this discrepancy, I personally find it hard to justify putting more time into it.
But if you feel it’s worth it, please go ahead: I really don’t want us to spend more time debating whether it’s worth it, than the time it would take to actually do it! :)