Feature #12193

Feature #12163: Announce in advance that 3.0 will be 64-bit only

Notify the user when their 32-bit computer won't work with Tails 3.0

Added by intrigeri about 2 months ago. Updated 19 days ago.

Status:ResolvedStart date:01/30/2017
Priority:ElevatedDue date:
Assignee:-% Done:

100%

Category:Hardware support
Target version:Tails_2.11
QA Check:Pass Blueprint:
Feature Branch:feature/12193-notify-if-32-bit Easy:
Type of work:Code Affected tool:

Description

Let's make this notification point to the blog post that will result from #12192.

This branch shall be reverted on feature/stretch, where its only effect would be to eat memory and CPU cycles.


Related issues

Related to Tails - Bug #12281: Cannot open multiple doc pages concurrently from notifications Confirmed 03/03/2017
Blocked by Tails - Feature #12192: Blog post to announce that 3.0 will be 64-bit only Resolved 01/30/2017
Blocked by Tails - Bug #12269: "Tor is not ready" should not pop up when opening local documentation Resolved 02/27/2017

Associated revisions

Revision 11bb9f67
Added by intrigeri about 2 months ago

Notify the user if running on a 32-bit processor, that won't be supported in Tails 3.0 anymore (refs: #12193).

Revision d1e80669
Added by intrigeri 26 days ago

tails-32-bit-notify-user: make decisions based on the CPU architecture, not the running kernel one (refs: #12193).

Otherwise, manually picking the 32-bit kernel on 64-bit hardware would result in
the notification being shown.

Revision 2c5567c2
Added by intrigeri 26 days ago

tails-32-bit-notify-user: display the local news, and a localized version if available (refs: #12193).

This will make this work even when offline.

Revision 8bb7900d
Added by intrigeri 25 days ago

tails-32-bit-notify-user: display the local news, and a localized version if available (refs: #12193).

This will make this work even when offline.

Revision a70b53a0
Added by intrigeri 25 days ago

tails-32-bit-notify-user: display the local news, and a localized version if available (refs: #12193).

This will make this work even when offline.

Revision 034e973a
Added by intrigeri 23 days ago

Make notification action ids unique, in case it helps with the weird behaviour we see when multiple notifications with actions are displayed at the same time. (refs: #12193)

Revision c5c2915d
Added by intrigeri 23 days ago

Merge branch 'feature/12193-notify-if-32-bit' into stable (fix-committed: #12193)

History

#1 Updated by intrigeri about 2 months ago

  • Feature Branch set to feature/12193-notify-if-32-bit

#2 Updated by intrigeri about 2 months ago

  • Blocked by Feature #12192: Blog post to announce that 3.0 will be 64-bit only added

#3 Updated by intrigeri about 2 months ago

  • Description updated (diff)

#4 Updated by intrigeri about 2 months ago

  • Description updated (diff)

#5 Updated by intrigeri about 2 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

#6 Updated by intrigeri about 2 months ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 10 to 50
  • QA Check set to Ready for QA

Candidate for 2.11. Note that it depends on a blog post that's not been published yet, so feel free to reassign to me after code review, and I'll merge into stable+devel myself once the blog post is up.

#7 Updated by anonym about 1 month ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 50 to 70
  • QA Check changed from Ready for QA to Dev Needed
  • exit 0 if $architecture eq 'x86_64';
    This is a bit simplistic, since manually picking the 32-bit kernel on 64-bit hardware will result in the notification being shown. Edge case, and presumably such users will realize that it doesn't affect them, so whatever, let's ignore this unless you know a simple way to implement a more reliable architecture check.
  • At the moment the notification's "Lean more" button will try to open the online version of the blog post. This won't work until users go online, and the notification will be shown before that (and it's even worse in offline mode). I think we should open the blog post from the offline wiki shipped with Tails instead.

#8 Updated by intrigeri about 1 month ago

  • exit 0 if $architecture eq 'x86_64';
    This is a bit simplistic, since manually picking the 32-bit kernel on 64-bit hardware will result in the notification being shown. Edge case, and presumably such users will realize that it doesn't affect them, so whatever, let's ignore this unless you know a simple way to implement a more reliable architecture check.

I think my time is better spent on other Tails matters, but well, I'll see if I can get something in 5 minutes.

  • At the moment the notification's "Lean more" button will try to open the online version of the blog post. This won't work until users go online, and the notification will be shown before that (and it's even worse in offline mode). I think we should open the blog post from the offline wiki shipped with Tails instead.

Right, I can do that (as we do in tails-virt-notify-user already). The downside is that the English version will be displayed to everyone (unless I write more code), while the online version would be localized (in French only, currently). But IMO a reliable local English version, with an option to manually switch to the localized version (if already translated when we build the ISO), is better than an unreliable online version.

#9 Updated by anonym about 1 month ago

intrigeri wrote:

  • [...] This is a bit simplistic, since manually picking the 32-bit kernel on 64-bit hardware will result in the notification being shown. Edge case, and presumably such users will realize that it doesn't affect them, so whatever, let's ignore this unless you know a simple way to implement a more reliable architecture check.

I think my time is better spent on other Tails matters, but well, I'll see if I can get something in 5 minutes.

Five minutes at most! :)

  • At the moment the notification's "Lean more" button will try to open the online version of the blog post. This won't work until users go online, and the notification will be shown before that (and it's even worse in offline mode). I think we should open the blog post from the offline wiki shipped with Tails instead.

Right, I can do that (as we do in tails-virt-notify-user already). The downside is that the English version will be displayed to everyone (unless I write more code), while the online version would be localized (in French only, currently). But IMO a reliable local English version, with an option to manually switch to the localized version (if already translated when we build the ISO), is better than an unreliable online version.

We can get the preferred translation too! Have a look at /usr/local/bin/tails-documentation. :)

#10 Updated by intrigeri 26 days ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 70 to 80
  • QA Check changed from Dev Needed to Ready for QA

(Only tested by copying the script in 2.10. Tried 32-bit and 64-bit CPU, English and French locales, works as planned.)

#11 Updated by anonym 26 days ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Ready for QA to Dev Needed

intrigeri wrote:

(Only tested by copying the script in 2.10. Tried 32-bit and 64-bit CPU, English and French locales, works as planned.)

Is there a reason you didn't use /usr/local/bin/tails-documentation as I suggested above, and instead re-implemented parts of it in Perl with doc_page_url()? Also, this will still be affected by #12269, which I have proposed a solution for (but only for tails-documentation -- if you want to fix your function it should export TOR_BROWSER_SKIP_OFFLINE_WARNING).

If there's no good reason for this I'd much rather you revert 2c5567c297987ac0a10a7a004f8b4dc5106d2da0 and s/tor-browser/tails-documentation/ instead.

#12 Updated by intrigeri 26 days ago

Is there a reason you didn't use /usr/local/bin/tails-documentation as I suggested above, and instead re-implemented parts of it in Perl with doc_page_url()?

Oops, I misunderstood. I thought you were pointing me to tails-documentation as an example, not as a tool I should use. Now it's obvious :)
Sorry!

Also, this will still be affected by #12269, which I have proposed a solution for(but only for tails-documentation -- if you want to fix your function it should export TOR_BROWSER_SKIP_OFFLINE_WARNING).

OK, will do.

If there's no good reason for this I'd much rather you revert 2c5567c297987ac0a10a7a004f8b4dc5106d2da0 and s/tor-browser/tails-documentation/ instead.

OK.

#13 Updated by intrigeri 26 days ago

  • Blocked by Bug #12269: "Tor is not ready" should not pop up when opening local documentation added

#14 Updated by anonym 26 days ago

intrigeri wrote:

Also, this will still be affected by #12269, which I have proposed a solution for(but only for tails-documentation -- if you want to fix your function it should export TOR_BROWSER_SKIP_OFFLINE_WARNING).

OK, will do.

Hm, ok. I interpret this as you will fix your doc_page_url() instead of moving to tails-documentation. Considering what I said in my previous comment I suppose you have a good reason for that then (?).

If there's no good reason for this I'd much rather you revert 2c5567c297987ac0a10a7a004f8b4dc5106d2da0 and s/tor-browser/tails-documentation/ instead.

OK.

So what does "OK" mean here? I'm confused!

#15 Updated by intrigeri 25 days ago

I'll use tails-documentation. Sorry for the confusion again :/

#16 Updated by intrigeri 25 days ago

  • Related to Bug #12281: Cannot open multiple doc pages concurrently from notifications added

#17 Updated by intrigeri 25 days ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Dev Needed to Ready for QA

While I was at it, I also fixed tails-virt-notify-user.

#18 Updated by anonym 24 days ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Ready for QA to Dev Needed

Your changes look good!

However, something is broken: the "Learn more" button doesn't do anything (I even changed the action to touch /tmp/bla, and it was not created, so I don't think there's a problem with e.g. Xorg stuff missing from the environment or whatever).

However, it does work if I run either of:

  • /usr/local/lib/tails-32-bit-notify-user
  • systemctl --user restart tails-32-bit-notify-user.service

This also affects tails-virt-notify-user.service and (from #12271, already merged) tails-32-bit-notify-user.service. When I tested the latter it worked for me, but I admit to not rebooting but using the systemctl command above (feeling guilty). So, intrigeri, you being the expert on systemd here, what could be different?

(I was thinking about the environment, but unsetting DISPLAY, XAUTHORITY etc and rerunning it still produces a notification with a working "Learn more" button (my experiment with touch also seem to indicate it's not related to Xorg environment stuff).)


I also noticed that when executing the above commands, clicking on "Learn more" and the browser starts, then the commands are blocked! Looking at action_cb() it makes sense:

sub action_cb {
    my $reactor = shift;
    exec(
        [... open docs ...]
    );
    $reactor->shutdown;
}

so if the browser isn't already running, the blocking is expected due to the use of exec. Also, since we use exec, we won't ever return to the Perl script, so $reactor->shutdown will never be reached. The exec should be run as a subprocess, e.g.:
sub action_cb {
    my $reactor = shift;
    unless (fork) {
        exec(
            [... open docs ...]
        );
    }
    $reactor->shutdown;
}

... although I'm sure you know of a more Modern way to start subprocesses than fork(). :) This also affect "my" tails-i2p-removal-notify-user.

#19 Updated by intrigeri 24 days ago

However, something is broken: the "Learn more" button doesn't do anything

Wow, weird. I'm pretty sure I've tested all three notifications we're talking of. Will look at it first thing tomorrow!

#20 Updated by anonym 24 days ago

Update: the 'the "Learn more" button doesn't do anything' problem seems to happen at random.

#21 Updated by anonym 24 days ago

And now I cannot reproduce the "Learn more" issue. I first got it 5 boots in a row, and now I've done 15 boots in a row without getting it. I say: if you cannot reproduce, ignore it.

#22 Updated by anonym 24 days ago

BTW, I just pushed my fork() fix of action_cb(); feel free to drop it if you have a better solution.

#23 Updated by intrigeri 23 days ago

  • QA Check changed from Dev Needed to Ready for QA

#24 Updated by intrigeri 23 days ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 80 to 100

#25 Updated by intrigeri 23 days ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

It still works quite weirdly when multiple such notifications are displayed at the same time :/

Who's affected? 32-bit + I2P (just for 1 release), 32-bit + virtualization (=> worst case they need to fix their VM config once 3.0 is out, is all), I2P + virtualization (just for 1 release); the I2P ones are very very few people according to the (skewed, limited, but that's what we have) data. 32-bit are very few so 32-bit + I2P, well, not sure they even exist. 32-bit + virtualization are ~2.5%, which is more people but the impact if they miss one notification is not so bad.

So we decided on XMPP it was not worth spending more time on this problem now.

#26 Updated by anonym 19 days ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF