It would be nice to have a backport of syncthing. In particular, recent versions contain several db optimisations.
Hello, Version 1.18.0 has been uploaded on testing, I will take a look at the amount of work needed for a bullseye-backport, but I'm pretty sure the magnitude of work will be consequent. Cheers,
Hi Félix and Aloïs, Aloïs Micard <creekorful@debian.org> writes: I didn't know about these db optimisations, but this seems like something that would be especially welcome on laptops :-) It's something I'm now looking forward to! As you know, I've also been working on this :-) My three questions are: Would you like to help maintain the backport? Would you like to start now, or wait for 1.18.6? How would you like to divide up the work? For the last of these, a simple approach might be to build, see what's missing, and each claim half of the list, but of course that doesn't take care of interrelated dependency chains...but on the upside, if one of us ends up having to block while waiting for the other then it would feel more like a team effort haha Best, Nicholas
Hi, Having a backport of syncthing would be great, but unfortunately I won't have a lot time to invest in it: a baby, a farm and involvement in other non-profit organisations do not let me as much time as I would like for Debian, sorry! Have a nice day,
I am not the adressee here, but taking the liberty to respond anyway as it fits: I am an upstream maintainer and Debian user. I'd be very interested in helping out with this packaging. As a full disclosure: I will keep directing users reaching us (upstream) to use our own apt repo, because the highly outdated (by design) packages debian stable, which also aren't actively maintained (as in bugfixes backported), provide a poorer experience to users. However the package exists, so I'd love to help make it better. I have dabbled in some packaging, but with emphasis on dabbled (mostly bugs, few small patches). I did provide a few patches for important problems on syncthing before bullseye, and have a branch with a lot more. However response times were pretty slow and when I once did a PR directly, I somehow didn't follow the right packaging flow (I looked at some team documentation). Basically at this point I am willing to invest time in the syncthing package, but as a non-DD/DM I need a DD/DM that wants me to do that and is willing to tell me how they want my contributions. As in how should the source/git be organised. My personal preference would be git only (what tree/source/patch format?), but I am willing to send patches or do other stuff if that's preferred. And I am missing Alexandre Viau in this email discourse so far - he is the one doing most of the work on Syncthing so far. And thus it's probably mainly him who needs to express in what form I or any other contributor could/should chip in. Thus sending this to him too. Please let me know your thoughts and whether what I wrote made any sense :) Best, Simon
Hi Félix, Félix Sipma <felix+debian@gueux.org> writes: No worries! :-) Sorry my email wasn't clear; that section was intended for Aloïs. Progress update is in the next email. Cheers, Nicholas
Hello Simon, and anyone else reading: Quick progress update for anyone reading this thread: I've updated my fork to 1.8.6, it builds, and CI passes. That said, I'm not 100% positive that I didn't miss something when repacking the source. Git diff --stat didn't reveal anything obvious. I didn't push to the team namespace for this reason, and because Alexandre usually handles importation of new upstream versions. I was also happy to find that 1.8.0-to-1.8.6 wasn't as painful as past releases, and that no new dependencies have to pass through the NEW queue; to those unfamiliar with Debian processes, in addition to the time it takes to carefully package and review new software, the ftpmaster QA and legal review represents a significant delay. The latter process is one of the reasons why Debian is a very high quality and reliable distribution. Repo available for review here: https://salsa.debian.org/sten/syncthing.git Reply follows inline. Simon Frei <freisim93@gmail.com> writes: Wow, I didn't expect my email to each Syncthing upstream :-) Welcome! That's wonderful news; although, I must warn you that the learning curve is a bit steep ;-) Debian stable is actively maintained. Security fixes are backported. Were a bug serious and grave enough to cause data loss (or a similarly bad situation) then the release team would authorise a bugfix release. An interesting question is if the release team would authorise importing the version in testing into stable-updates were the version in stable to no longer interoperate with Syncthing for Android (or Syncthing-fork). For feature enhancements and minor bug fixes we have stable-backports. New versions are upload to sid/unstable. Now that's that's cleared up, are you interested in helping with packaging new Syncthing versions in sid/unstable (along with new dependencies), or in doing formal backports? https://wiki.debian.org/BuildingFormalBackports Please share a URL for review so I can direct you to the pertinent documentation. Agreed, and thank you! Alexandre's written on the record that he appreciates help with the dependencies, by the way, so it may be worthwhile to practise using Debian Go Packaging Team tooling. This work targets sid/unstable, which migrates to testing, where it becomes eligible for stable-backports. If you're interested in this, you'll want to read the following doc, and will eventually need to read all the docs it links to: https://www.debian.org/devel/join/newmaint Yes, it makes sense :-) I won't be able to comment on questions about your patches without looking at them. Best, Nicholas
Bug was not closed from changelog, so I'm closing it manually.
syncthing (1.18.6~ds1-1~bpo11+1) bullseye-backports; urgency=medium
* Rebuild for bullseye-backports (Closes: #975042).
* Syncthing >= 1.18.6 (possibly older) require
golang-github-greatroar-blobloom-dev (>=0.7.0), and
golang-github-thejerf-suture-dev (>=4.0.1), so make these changes in
control (also fixed in yet-to-be released 1.19.2~ds1-1).