Make it easier to identify which nightly build is running
When I start tails-amd64-feature_17136-persist-greeter-settings-4.5-20200321T0705Zemail@example.com 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…
|Blocks Tails - Feature #16209: Core work: Foundations Team||Confirmed|
#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-20200321T0705Zfirstname.lastname@example.org 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
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
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.
#4 Updated by intrigeri 2020-03-27 10:23:08
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/versionin favor of
/etc/os-releasewhich has a structured format
auto/configsaves the needed info to
/etc/os-release; this includes:
- whether we’re building a release or not
- if we’re not building a release and we’ve merged the base branch:
AMNESIA_NOW(could be renamed, in passing)
config/chroot_local-includes/lib/live/config/0001-sane-clockto retrieve info from
config/chroot_local-includes/usr/local/bin/tails-aboutto stop using
tails-versionand instead, retrieve info from
os-releaseand display it as per design above
config/chroot_local-includes/etc/whisperback/config.py: stop using
tails-versionand instead, retrieve info from
os-release; possibly sharing code with
tails-aboutbut 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):
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. :)
#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.