Bug #16046

Lightning doesn't work in Thunderbird 60+

Added by anonym 2018-10-12 14:13:10 . Updated 2019-11-01 11:26:36 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-10-12
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

Running Tails 3.9.1, installing the lightning package will pull our 1:60.0-3~deb9u1.0tails2 build. Thunderbird then lists Lightning as enabled in the Add-on manager, but none of the calendar functionality works or is visible (e.g. the “Events and Tasks” menu is not present) so it is just as if Lightning is disabled.

Installing Debian stretch’s versions 1:60.0-3~deb9u1 of thunderbird and lightning fixes the problem. Actually, after this it seems like the profile has been fixed for this problem; if installing our versions, then Lightning suddenly works as it should! So the following is a workaround that permanently fixes persistent Thunderbird profiles:

echo "deb tor+http://vwakviie2ienjx6t.onion/debian/ stretch-proposed-updates main contrib" >> /etc/apt/sources.list
apt update
apt install thunderbird=1:60.0-3~deb9u1 lightning=1:60.0-3~deb9u1
# Now start Thunderbird and verify that Lightning works. Don't do anything else!
apt install thunderbird=1:60.0-3~deb9u1.0tails2 lightning=1:60.0-3~deb9u1.0tails2

So, what is wrong with our builds compared to Debian stretch’s? With Bug #16019#note-8 we established that there in practice shouldn’t be any difference, but apparently there is.

Also, intrigeri said this, which might be relevant: “IIRC lightning is treated in a particular way wrt. extension scopes. might be worth playing with extensions.autoDisableScopes and extensions.enabledScopes if it’s not enabled.”


Subtasks


Related issues

Related to Tails - Bug #16019: Maybe rebase Thunderbird on debian/stretch Rejected 2018-10-01

History

#1 Updated by anonym 2018-10-12 14:14:13

  • related to Bug #16019: Maybe rebase Thunderbird on debian/stretch added

#2 Updated by anonym 2018-10-12 14:14:43

#3 Updated by intrigeri 2018-10-12 15:10:20

  • blocked by deleted (Feature #15506: Core work 2018Q4: Foundations Team)

#4 Updated by anonym 2018-10-12 15:29:38

anonym wrote:
> So the following is a workaround that permanently fixes persistent Thunderbird profiles:

Unfortunately the workaround does not persist. :/

#5 Updated by intrigeri 2018-10-22 08:55:14

I’m told that on current 60.x, Lightning needs lightning-l10n-* to work. But there’s WIP on the sid packaging to merge these langpacks into the thunderbird-l10n-* ones so once we pick this up (and stop reverting it, see Bug #16037) this should be fixed.

#6 Updated by mercedes508 2019-05-24 12:35:52

  • Assignee set to intrigeri

I’m told by a user from WB: f5eaee9daae4f84888e0e3cd2790faa8 that it was solved in 3.13.2 but isn’t in 3.14. So it looks like a regression even though lightning isn’t installed at first.

#7 Updated by intrigeri 2019-05-24 13:01:15

  • Assignee deleted (intrigeri)

Relevant error message: “lightning : Depends: thunderbird (>= 1:60.6.1-1~deb9u1) but it is not going to be installed”.

So we have two problems here:

  • We should pin the lightning* packages just like we pin the thunderbird ones. Otherwise, we’re creating an inconsistent APT config that’s bound to create coinstallability issues such as this one.
  • Whether our own current lightning package works or not is unclear. It might still be broken as described by anonym earlier on this ticket. It might be fixed. I say let’s fix the co-installability issue first and then we’ll see.

For now I’m not treating this as core work as we don’t install Lightning by default.

#8 Updated by intrigeri 2019-11-01 11:26:36

  • Status changed from Confirmed to Resolved

We’ve stopped shipping patched Thunderbird packages, which should have resolved this problem. If that’s not the case, please say so :)