Bug #16019

Maybe rebase Thunderbird on debian/stretch

Added by anonym 2018-10-01 21:25:33 . Updated 2018-10-20 20:36:39 .

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

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Email Client
Deliverable for:

Description

Since we moved to Thunderbird 60 we have been basing our builds on debian/sid (e.g. commit 7a5d2f4 merged the debian/1%60.0-1 tag of debian/sid), which was necessary at the time since debian/stretch was still on version 52. Now it is up-to-date tracking version 60+ and has solved the backporting different than us.

We should consider dropping the backporting work we did in favor of debian/stretch. Example, we should drop 8c86207, 5a790c2 and 4f1fcd4 in favor of 29621ed. Or perhaps we’re happy with our solutions and the status quo and wait with this until an actual problem occurs (e.g. if debian/sid diverges)? Or we just cherry-pick what we need from debian/stretch?

Subtasks

Related issues

Related to Tails - Bug #16046: Lightning doesn't work in Thunderbird 60+ Resolved 2018-10-12

History

#1 Updated by anonym 2018-10-01 21:26:17

#2 Updated by anonym 2018-10-01 21:35:34

If we rebase on debian/stretch we should revert commit:23464324a248bea82f292ae9a358489595c3a85f in Tails’ Git.

#3 Updated by anonym 2018-10-04 02:48:05

  • Status changed from Confirmed to In Progress

Applied in changeset commit:23464324a248bea82f292ae9a358489595c3a85f.

#4 Updated by intrigeri 2018-10-04 20:19:32

I propose:

  • either we merge debian/stretch (no rebasing please), start tracking it, and hope that it’ll always be up-to-date enough for our needs;
  • or we don’t bother and we do nothing on the ground that we’ll soon start focussing on Buster and whatever work we do here will be useful only for a limited amount of time.

I think the 2nd option is good enough.

#5 Updated by intrigeri 2018-10-04 20:19:43

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

#6 Updated by intrigeri 2018-10-04 20:20:13

  • Status changed from In Progress to Rejected

Please reopen if you disagree and see a compelling reason to do anything about this now.

#7 Updated by anonym 2018-10-04 20:55:58

intrigeri wrote:
> Please reopen if you disagree and see a compelling reason to do anything about this now.

I fully agree, but was personally not sure of the exact implication of not using “internal libs” like debian/stretch does. By rejecting this ticket I assume you have considered this (it’s probably trivial if you know the details, which I don’t).

#8 Updated by intrigeri 2018-10-04 21:47:14

> I fully agree, but was personally not sure of the exact implication of not using “internal libs” like debian/stretch does. By rejecting this ticket I assume you have considered this (it’s probably trivial if you know the details, which I don’t).

AFAICT we do exactly the same as current debian/stretch wrt. internal libs (git diff debian-upstream/debian/stretch.. -- debian/mozconfig.default).

#9 Updated by anonym 2018-10-12 14:14:14

  • related to Bug #16046: Lightning doesn't work in Thunderbird 60+ added

#10 Updated by CyrilBrulebois 2018-10-20 20:36:39

For the sake of completeness, I’ve just contacted Carsten with a proposal to revert a few commits in the debian/sid branch so that it gets (more easily) backportable to debian/stretch; the idea is to try and share the backporting load (at least review-wise) between Debian and Tails.

Regarding the Build-Depends thing, that doesn’t worry too much. Having diverged is a bit unpleasing, but that shouldn’t hurt much: those are just a few extra, unneeded, and unused packages?

The ongoing l10n dance with lightning-l10n* packages getting merged into thunderbird-l10n* packages is a bit more challenging, but that’s something that will likely have to be taken care of for stretch(-security), so I’m concentrating on this bit at the moment.