Feature #17543

Make it easier to identify which nightly build is running

Added by sajolida 2020-03-21 19:11:15 . Updated 2020-03-28 07:35:56 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

When I start tails-amd64-feature_17136-persist-greeter-settings-4.5-20200321T0705Z-283adb96ff+devel@3cf81af290.img I get the following “About” inside Tails:

  • How can I relate it to the image that I burnt?
  • Could we display the commit number of the image (283adb96ff) instead of this mysterious a612277…

Files

about.png (55764 B) sajolida, 2020-03-21 19:08:30

Subtasks

Related issues

Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2020-03-21 19:45:58

  • Status changed from New to Confirmed

> When I start tails-amd64-feature_17136-persist-greeter-settings-4.5-20200321T0705Z-283adb96ff+devel@3cf81af290.img I get the following “About” inside Tails:
> […]
> * How can I relate it to the image that I burnt?
> * Could we display the commit number of the image (283adb96ff) instead of this mysterious a612277…

I understand we display useless information there.

So the question is: what would be useful information?

For example, to display all the info needed to identify the source code this image was built from, we need to include both commit IDs: 283adb96ff and 3cf81af290.
That’s because this image was built from the feature/17136-persist-greeter-settings branch at 283adb96ff, after merging devel (at 3cf81af290) into it, so “the commit number of the image (283adb96ff)” alone is not sufficient.

Would this solve the problem you’re raising here?

Do you think this should be FT work? (I mean, I do see and understand the problem, but I don’t really know what’s the practical impact.)

#2 Updated by sajolida 2020-03-23 22:04:30

The practical impact is that it made me lost 15 minutes while testing

Bug #17183: I couldn’t test the Persistent Storage in a VM so I copied the
image to a USB stick, started Tails, experienced a failure in my tests,
went to About to verify whether I had burnt the correct image, tried
very hard to make sense of the information displayed there (I really
thought I already made sense out of it), finally gave up, burnt the
image again, and started Tails again to confirm.

I understand that this doesn’t affect in the same way tests done from a
VM but it affects the performance of testers running on bare metal:
myself sometimes or people on tails-testers@. Doing such tests is most
of the time volunteer work, very rarely gratifying, and often
frustrating. So making them less painful sounds important to encourage
testing contributions.

It’s not my duty to define the priorities of the FT but I think that
this ticket fails into your realm of responsibility as people who
“maintaining the ISO build system” and ask others to test their stuff
while in development.

At least not display misleading information there, currently the 2nd
line of “Build information” that could look like a Git commit reference
but is not. The whole “Build information” section can probably disappear
actually: I don’t see it being useful to anybody else than devs and devs
can already deduce this information from the version number.

Now, random people on tails-testers@ might also be confused by
displaying an official version number (eg. 4.4) on something that’s not
an official release.

The useful information there would be something that could be related to
the full name of the image “283adb96ff+devel@3cf81af290” sounds good.
So ideally, “283adb96ff+devel@3cf81af290” in the second line, instead of
the misleading official version number.

As far as I’m concerned, I guess that I’ll now remember that this
information is irrelevant and I probably won’t burn an ISO twice when
getting surprising tests results in the future.

#3 Updated by intrigeri 2020-03-27 10:21:49

#4 Updated by intrigeri 2020-03-27 10:23:08

Hi,

thanks!

How about this:

0. In any case, remove:

  • the link to our website
  • “Tails developers”
  • “The Amnesic Incognito Live System”
  • the entire “Build information” section

1. Official release (including alpha, beta, RC)

Tails 4.5
Built from 520acfb262

2. Nightly build from a topic branch

Tails 4.5 UNRELEASED
Built from 283adb96ff+devel@3cf81af290 on 20200327T1012Z

3. Nightly build from stable, testing, or devel

Tails 4.5 UNRELEASED
Built from 520acfb262 on 20200327T1012Z

?

Implementation wise, I would like to see us use this as an opportunity to clean up a 10 years old historical mess:

  • Get rid of /etc/amnesia/version in favor of /etc/os-release which has a structured format
  • auto/config saves the needed info to /etc/os-release; this includes:
    • GIT_SHORT_ID
    • whether we’re building a release or not
    • if we’re not building a release and we’ve merged the base branch: CLEAN_GIT_BASE_BRANCH and GIT_BASE_BRANCH_SHORT_ID
    • AMNESIA_NOW (could be renamed, in passing)
  • Delete config/chroot_local-hooks/97-versions
  • Adjust config/chroot_local-includes/lib/live/config/0001-sane-clock to retrieve info from os-release
  • Adjust config/chroot_local-includes/usr/local/bin/tails-about to stop using tails-version and instead, retrieve info from os-release and display it as per design above
  • config/chroot_local-includes/etc/whisperback/config.py: stop using tails-version and instead, retrieve info from os-release; possibly sharing code with tails-about but it might not be worth it
  • config/chroot_local-includes/usr/local/bin/tails-version (now unused, but some folks might be used to it): cat /etc/os-release
  • Adjust features/step_definitions/common_steps.rb

Now, if someone prefers to apply the minimum changes needed to fix this issue, that’s fine by me too! The best, the good, enemy of, etc. :)

#5 Updated by sajolida 2020-03-27 19:39:02

> How about this:

That would be awesome :)

> * the link to our website

If super easy, point to the release notes instead?

#6 Updated by intrigeri 2020-03-28 07:35:56

> If super easy, point to the release notes instead?

The algorithm seems very simple:

if released:
    tag = replace "~" with "-" in version number
    if version number includes "~"
        link to https://tails.boum.org/news/test_$tag/
    else
        link to https://tails.boum.org/news/version_$tag/
else:
   do nothing

In the implementation I’ve proposed, tails-about would have access to all the info it needs to implement it in a few lines of Python.