Bug #15484
Upgrade Electrum to 3.1.1+
100%
Description
Electrum is under very rapid development. We want to make sure that our users have the latest version. Only two packages need to be updated: electrum and python3-electrum. Specifically, this update means that we can use the improved configuration in Bug Bug #15483 among many other improvements listed in https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES .
Subtasks
History
#1 Updated by intrigeri 2018-04-02 09:22:08
- Assignee changed from s7r to mjenglish
- QA Check set to Info Needed
> Install Electrum from Unstable
Well, if we do that, sooner or later it won’t be installable on stable anymore because it’ll pick up dependencies that cannot be satisfied there.
> We want to make sure that our users have the latest version.
Rapid development in itself is not a sufficient reason to risk regressions and increase maintenance costs (and this argument works for lots of software we ship). Why, specifically, are slightly older versions (from stretch-backports) not suitable for our users?
#2 Updated by mjenglish 2018-04-02 11:47:34
intrigeri wrote:
> > Install Electrum from Unstable
>
> Well, if we do that, sooner or later it won’t be installable on stable anymore because it’ll pick up dependencies that cannot be satisfied there.
>
> > We want to make sure that our users have the latest version.
>
> Rapid development in itself is not a sufficient reason to risk regressions and increase maintenance costs (and this argument works for lots of software we ship). Why, specifically, are slightly older versions (from stretch-backports) not suitable for our users?
I think that there is more risk of regressions and maintenance costs for keeping an older version of Electrum. At some point Electrum will be unusable because the backported version is too old.
Specifically, this is a subtask of Bug Bug #15483, so please see that bug report for benefits. The new configuration file only works on Electrum 3.1.1.
#3 Updated by intrigeri 2018-04-02 12:16:30
> I think that there is more risk of regressions and maintenance costs for keeping an older version of Electrum. At some point Electrum will be unusable because the backported version is too old.
Interesting, thanks.
The lifetime of a Tails release (~6 weeks) is much greater than how long stretch-backports lags behind testing/sid (ideally: 5 days; in practice, probably a bit longer). So it seems to me that your argument implies the following: any version of Electrum we include in a Tails ISO will be too old and unusable at some point. If I understand this argument correctly, it basically implies that the Electrum software is not suitable for being included in an OS image that’s released every ~6 weeks. Fine, once we have much improved Additional Software Packages in Tails 3.9 (Feature #14568) we should then:
- stop including Electrum by default
- keep shipping sane APT pinning, default configuration, and persistence preset to make Tails+Electrum’s life easier
Then users who want to use Electrum will need to add it to their list of ASP and they’ll have the same UX as currently, except they’ll always be running the latest version (from the Debian dist our APT pinning prefers, which one is best can be discussed from a different perspective once it’s not about a version that’s frozen in an ISO) as you say they should be.
What do you think?
#4 Updated by mjenglish 2018-04-02 14:24:44
intrigeri wrote:
> What do you think?
I think that you might be misinterpreting what this bug is about. I am talking about a one-time upgrade of Electrum to allow us to fix several bugs in our configuration. Your argument is interesting, but I think that it warrants a separate bug report to determine the long-term implications of including Electrum in Tails by default. Please create a separate issue and assign it to me and I will comment there.
#5 Updated by s7r 2018-04-02 21:42:30
You are right with the timings. Installing from unstable might not be the best move. Installing from stable-backports
however ensures it is properly install-able. Also, every Electrum update in unstable will make it to stable-backports
after the required time passes. This is more closer and in concordance to Tails ~6 weeks estimated release life.
We go for the idea that Electrum is to be shipped with Tails and:
- should be fully usuable (send, receive, sync with the network);
- should not have security bugs, or other severe bugs which could affect user’s funds or security;
It is not mandatory to support all cutting edge features of this wallet and support each and every hardware wallet, to its last version. These will obviously be supported as they come to stable-backports
, but until then users that want cutting edge features should take some time to install themselves the preferred version that support them. If we take this approach, we might never catch up.
When there’s a bug or regression that makes the version shipped in Tails useless, the new Electrum version that fixes is will be in stable-backports
so we should never get there. Again, I don’t see “missing cutting edge features” == “bug”.
#6 Updated by mjenglish 2018-04-02 23:27:21
s7r wrote:
> You are right with the timings. Installing from unstable might not be the best move. Installing from stable-backports
however ensures it is properly install-able. Also, every Electrum update in unstable will make it to stable-backports
after the required time passes. This is more closer and in concordance to Tails ~6 weeks estimated release life.
I could be wrong, but I have found backported software to significantly lag behind testing/unstable. I’m talking about months and not days.
> When there’s a bug or regression that makes the version shipped in Tails useless, the new Electrum version that fixes is will be in stable-backports
so we should never get there. Again, I don’t see “missing cutting edge features” == “bug”.
I wasn’t trying to add cutting edge features, but rather I was trying to clean up the config file which requires Electrum 3.1.1. If this is a controversial move, then we can at least delay shipping the updated config until Electrum is updated via stretch-backports.
#7 Updated by intrigeri 2018-04-03 08:39:19
> I could be wrong, but I have found backported software to significantly lag behind testing/unstable. I’m talking about months and not days.
Let’s use actual data that’s relevant here rather than general stats (which I agree with but are not terribly useful here :)
Since s7r started to take care of Electrum in Debian, there’s been 3 package upgrades in testing. The delay between migration to testing and upload to stretch-backports has been:
- 14 days
- 1 day
- more than 2 weeks: 3.1.1-1 was not uploaded to stretch-backports yet
#8 Updated by intrigeri 2018-04-03 08:40:51
> I think that you might be misinterpreting what this bug is about. I am talking about a one-time upgrade of Electrum
OK, indeed I got it wrong. Re-reading the title and the description of this bug I still find it unclear so please retitle this ticket “Upgrade Electrum to 3.1.1+” or similar :)
#9 Updated by mjenglish 2018-04-03 17:48:20
- Subject changed from Install Electrum from Unstable to Upgrade Electrum to 3.1.1+
#10 Updated by mjenglish 2018-04-03 17:51:16
intrigeri wrote:
> Since s7r started to take care of Electrum in Debian, there’s been 3 package upgrades in testing.
Thanks for correcting me. I wasn’t aware that Electrum has been actively maintained in Debian. Should we close this issue then?
#11 Updated by intrigeri 2018-04-10 08:44:38
- Assignee changed from mjenglish to s7r
- Target version changed from Tails_3.7 to Tails_3.9
- Type of work changed from Code to Debian
> Thanks for correcting me. I wasn’t aware that Electrum has been actively maintained in Debian.
:)
> Should we close this issue then?
I think it might be useful to track this upgrade, I’ll let s7r decide. Next step is ensuring 3.1.1+ makes it into stretch-backports ⇒ adjusting metadata accordingly.
Regarding timing:
- Assuming 3.1.1+ makes it into stretch-backports by August ~10, we’ll have it automatically imported in time for Tails 3.9
- If 3.1.1+ makes it into stretch-backports earlier and we bump the APT snapshots we use for the Debian archive in Tails 3.7 or 3.8 (e.g. for
Bug #15435) then it might make it into 3.7 or 3.8 ⇒ it would be nice if we had a branch forBug #15483+Bug #15484with the corresponding config file update ready so Electrum does not block other dev work such asBug #15435.
#12 Updated by intrigeri 2018-08-07 07:33:10
intrigeri wrote:
> Regarding timing:
>
> * Assuming 3.1.1+ makes it into stretch-backports by August ~10, we’ll have it automatically imported in time for Tails 3.9
This will happen if 3.1.1+ is in stretch-backports by August 16. Any update on this side?
#13 Updated by intrigeri 2018-08-16 15:13:49
intrigeri wrote:
> This will happen if 3.1.1+ is in stretch-backports by August 16. Any update on this side?
It just happened yesterday, at the very last minute. I’ll let it go into Tails 3.9~rc1 but if it breaks stuff, either fixes are provided in a timely manner (see the release schedule and follow updates on tails-dev mailing list) or I’ll revert it to the previous, known working version.
#14 Updated by s7r 2018-08-31 13:34:20
I have just tested with 3.9-rc1 Electrum 3.1.3 works perfectly. I have installed from scratch as well as over a persistent configuration used by previous Electrum 3.1.1. All tests passed ok.
#15 Updated by s7r 2018-08-31 14:55:29
- % Done changed from 0 to 100
- QA Check changed from Info Needed to Pass
- Type of work changed from Debian to Code
#16 Updated by intrigeri 2018-09-03 09:02:14
- Status changed from New to Fix committed
- Assignee deleted (
s7r)
Thanks!
#17 Updated by intrigeri 2018-09-03 09:02:39
- Parent task deleted (
)Bug #15483
#18 Updated by intrigeri 2018-09-03 09:02:56
- blocks
Bug #15483: Update Electrum configuration file added
#19 Updated by intrigeri 2018-09-05 16:21:30
- Status changed from Fix committed to Resolved