Project

General

Profile

Bug #17353

.build-manifest discrepancies

Added by CyrilBrulebois 4 months ago. Updated 3 months ago.

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

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:
Starter:
Affected tool:

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?


Related issues

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

Associated revisions

Revision b980b5e4 (diff)
Added by intrigeri 3 months ago

Release process: clarify what artifacts have to match (refs: #17353)

Above we already say "make sure the ISO and USB images built by Jenkins have the
same hash" but in the heat of the release process, as #17353 shows, it's easy to
be perplexed by a differing .build-manifest, so this bullet point is a good
place to clarify the expectations and avoid the RM wondering if it's OK or not.

History

#1 Updated by intrigeri 4 months ago

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 3 months ago

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 3 months ago

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

#4 Updated by intrigeri 3 months ago

  • Status changed from Confirmed to In Progress

#5 Updated by intrigeri 3 months ago

  • 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 b980b5e48202ec45ae8e21010c200d38208a9838. Would this have avoided the doubts and the "hold my breath for a little while" problem?

#6 Updated by CyrilBrulebois 3 months ago

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 3 months ago

  • 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! :)

Also available in: Atom PDF