[pkg-go] Bug#940413: syncthing: Please update to version 1.2.2

Nicholas D Steeves nsteeves at gmail.com
Tue Jul 28 22:47:02 BST 2020

Hi Simon,

Simon Frei <freisim93 at gmail.com> writes:

> Hash: SHA512
> Upfront: The below is written from the perspective of a upstream
> maintainer and debian user (and very minor contributor if at all), I do
> not have much packaging experience - please excuse obvious oversights ;)

Of course, gladly! :-)

> On 21/07/2020 20:20, Nicholas D Steeves wrote:
>> Alexandre Viau <alexandre at alexandreviau.net> writes:
>>> On Sun, Jul 19, 2020 at 10:57 PM Nicholas D Steeves
>>>> It seems to me that the most expedient path forward is to jump from
>>>> 1.2.x to 1.4.x.  ACK?
>>> Right, it looks like we will have too.
>>> I was trying to avoid it at first because it is a lot of work. I
>>> suggest that we move slowly and try to find the lowest version that
>>> works for now.
> What's the reason to expect more work when skipping more versions? My
> naive view is that it is more work to do more steps (e.g. because on
> every step you need to make sure all versions in debian are compatible).
> At the least I can strongly recommend to jump to the latest respective
> patch version (e.g. v1.7.1 is a minimal hotfix for an annoying issue in
> v1.7.0).
>> In other news, I can confirm that 1.4.0 ftbfs with the same qtls error
>> as 1.2.x.
> The quic dependency is unfortantely quite a moving target. As the
> version in debian is very recent (0.17) you'll need Syncthing >=1.6.0 or
> probably patches from
> https://github.com/syncthing/syncthing/commit/ac7338f1f2f10f67f16aa98b35fc97b4e043b7e5
> (no guarantees that's all, that's what came time to mind - untested and
> I'd anyway expect updating to be not much more of a pain than patching).

Thank you for confirming this; this saves a lot of time! :-D  I opened
#966466 to start building a picture of how much work it would be to jump
straight to v1.7.1.

For v1.6.1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964363
For v1.7.1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966466

> In general I am happy to help out with packaging - it just seemed that
> delays recently were mostly due to new dependencies, where I do not have
> any proficience thus my involvement would probably slow stuff down
> instead of speeding it up. Feel free to prod me anytime if there is
> useful task I can do or for any questions where I might have expertise :)

Thank you for your openness and willingness to help :-)

By the way, if ever you're interested in packaging here is a list of
relevant resources:

https://www.debian.org/social_contract (essential)
https://www.debian.org/doc/debian-policy (read relevant sections)
  * note that compliance with 100% of Policy is essential
https://go-team.pages.debian.net/ (obviously relevant)
https://www.debian.org/doc/devel-manuals (a nice overview of available docs)
https://mentors.debian.net/intro-maintainers/ (another nice overview)
  * includes solutions to common challenges
https://www.debian.org/doc/manuals/maint-guide/ (optional but recommended)
https://www.debian.org/doc/manuals/debmake-doc/ (optional but recommended)
  * recommended, probably required for Go Team policy

To be accepted into unstable, packages must pass through the NEW queue.
Here, packages require review by an ftpmaster.  Their criteria is thus:


Other resources are debian-mentors at lists.debian.org and
#debian-mentors at irc.oftc.net

I'd be happy to check your work and provide guidance if you can't find
anyone else!

Another way to help out would be manually check the diff in go.mod
between upstream/1.1.4_ds1 and upstream/1.7.1_ds1 for Bug #966466.  For
this you'll need a sid/unstable chroot and may use 'apt search', 'apt
policy', 'rmadison', plus the Debian bug tracker to see if there are any
missing deps that haven't been documented yet.  NEW packages will have
bugs filed against 'wnpp' and version upgrade requests are filed against
their respective packages.

The next step for my work at https://salsa.debian.org/sten/syncthing
will be to do this check, and then to remove any dependencies revealed
as "dropped" by the diff go.mod step from from debian/control.

If you'd like to work on that, please let me know soon.  The initial
investment of time and effort for NEW packages is really high, but
translating upstream deps to Debian deps is much faster and easier--and
also work that tends to need to be done for *every* new upstream golang
package release.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-go-maintainers/attachments/20200728/251c0252/attachment-0001.sig>

More information about the Pkg-go-maintainers mailing list