Hi s7r & list, s7r: > intrigeri wrote: > That was a great idea, got countless appreciations for that and also, > based on the feedback I receive and discussions the feature is *very* > popular in Tails. We should definitely not drop it.
To be clear, the email that started this thread was neither a proposal (nor a threat!) to drop it: as long as Electrum keeps working for basic Bitcoin usage without needing extra work, I'm happy to keep it around. Now, once we've released WIP improvements to our Additional Software Packages feature, Electrum is definitely on the list of packages that we should consider making opt-in; but I expect we'll keep the integration bits (e.g. pre-configuration & persistence feature) anyway. > However, I don't think we should upgrade the package after exactly each > and every Electrum release, unless it's something critical or stuff like > this. Fully agreed, I don't think we should set the bar this high (even if the Electrum project had a very trustworthy QA process and brand new releases introduced regressions extremely rarely). > At this moment for example we MUST upgrade to Electrum 3.x because it > includes a major change, that is not compatible with older versions > (SegWit transactions -- this change was quite controversial and took a > lot of time, but fortunately it's locked in permanently at this moment). > One user running something prior 3.x will not be able to have new native > SegWit addresses and benefit of the reduced fees, plus some payers or > payees might require payment to a native SegWit address, without > offering a legacy address. Good to know, I was not aware of it so I'm glad I've raised this topic here and you could answer it! :) > I am quite aware of this ever since first 3.x release, it's being worked > on (Tristan Seligmann from Debian is a mega help) but it takes slightly > longer than usual because among with SegWit, in 3.x Electrum was also > re-written in Python3 which is not in stable. Something will be soon > uploaded to unstable, and then I was planning to open a ticket when it's > in testing to include it in the next Tails release. It's excellent that you're on top of this. Please consider creating this ticket now (and explain there what the next steps are & what we are waiting for), so that our Help Desk can redirect users who request this somewhere. Shall we add you as a watcher for all tickets related to Electrum? >> If someone here particularly cares about Electrum support in Tails, >> here's what you can do: >> >> - wrt. bringing new features to Tails: get involved in the Debian >> package maintenance and maintain Electrum in stable backports >> (currently: stretch-backports) > I will check the policy for stable backports to see, but I think it > might be easier to use *testing* for this package particularly because > this is just how the cryptocurrency world is, it might provide updates > faster than we can have them in the stable repo and also sync these > timings with Tails releases. In testing we can have them in 7 days, > which would be good for us. A backport can be uploaded (and all such uploads will be automatically accepted once a first one has been manually accepted to a given suite) as soon as the package reaches Debian testing, so installing from backports does not add any relevant delay, except in the rare case when the timing of the migration to testing conflicts in the worst possible way with the Tails freeze schedule. Installing from Debian testing can definitely be a sane short-term option *but* this is brittle and can't be relied upon on the long term: at some point it's likely that the package from testing becomes uninstallable on stable due to new/updated versioned dependencies. So we install packages from testing only when we can be fully certain that whenever this happens, someone starts maintaining a backport immediately. I would recommend they start doing it now. >> - wrt. fixing bugs (if no good backport is actively maintained): get >> involved in the Debian package maintenance and fix in Debian >> *stable* any important bugs and issues that make the version >> included in there irrelevant/obsolete >> > If we could use the testing repo for this, things could be solved easier > (I hope). Yes, if we install from backports or from testing, technically *we* don't have to care about the version that's in Debian stable (it's the Debian maintainer's responsibility to do so). >> - in any case: >> * track upstream development closely, in order to pick the best >> versions for Debian unstable/testing and stable backports, >> or to identify bugs that shall be fixed in Debian stable; >> * act as a liaison with Tails developers to let us know when we >> should upgrade to which version (e.g. "there's now >> a well-maintained backport, please ship it"). > I can take this. I am tracking, testing, providing feedback and > suggestions upstream, and also track and use Tails so I can easily do it. Perfect! > Since then, there were few other releases but I did not open tickets > because the version we shipped was/is working. It may not have all the > features of the last release, but it is not useless, it is working and > nothing serious or security related needed to be addressed. From my > point of view, in a system like Tails which takes care of other things, > upgrading for minor features is both impractical and not necessary. Fully agreed. > We can just sync on every Tails release with the Electrum version in > testing, but this requires testing and review (on last upgrade the > config file format changed slightly which was affecting users with > persistence enabled and were still having the old config file on disk). Ideally Electrum upstream would sensibly handle such config updates itself. But sometimes it's not possible, or nobody cares enough to implement it, so: - We occasionally add automatic migration code for pre-existing persistent config e.g. https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/sbin/live-persist#n131 - Failing that, we document in the Tails release notes what users need to do in order to migrate their config. > Either way, let's keep it. Let me know what you think. I feel relieved to see you commit to all the above! Are you also interested in maintaining the Electrum integration into Tails (e.g. taking care of whatever needs to be done on incompatible config updates and similar Tails-specific glue)? If you want to commit to this, at some point we should probably add you as the point of contact for Electrum matters on https://tails.boum.org/contribute/#mentors :) Cheers, -- intrigeri _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
