Tails

#1 Updated by intrigeri 2017-01-30 16:37:37

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

#2 Updated by intrigeri 2017-01-30 16:38:25

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

#3 Updated by intrigeri 2017-01-30 16:39:18

• Description updated

#4 Updated by intrigeri 2017-01-30 16:43:48

• Description updated

#5 Updated by intrigeri 2017-01-30 16:50:17

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

#6 Updated by intrigeri 2017-01-30 19:22:06

• 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 2017-02-17 17:04:02

• 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.

#10 Updated by intrigeri 2017-03-02 10:09:25

• 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 2017-03-02 10:28:29

• 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 Bug #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 commit:2c5567c297987ac0a10a7a004f8b4dc5106d2da0 and s/tor-browser/tails-documentation/ instead.

#13 Updated by intrigeri 2017-03-02 11:41:53

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

#16 Updated by intrigeri 2017-03-03 10:05:35

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

#17 Updated by intrigeri 2017-03-03 10:06:32

• 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 2017-03-04 14:59:43

• 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 Feature #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.

#23 Updated by intrigeri 2017-03-05 14:13:18

• QA Check changed from Dev Needed to Ready for QA

#24 Updated by intrigeri 2017-03-05 15:59:03

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

Applied in changeset commit:c5c2915db63bb62f450b82dcc383b1e94bcf0a0e.

#25 Updated by intrigeri 2017-03-05 16:03:11

• 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 2017-03-09 13:59:47

• Status changed from Fix committed to Resolved