Hi!  This is a Go package, and as such you are welcome to team-maintain
it in the Debian Go Team if you are okay with that?  That would allow
the rest of the team to do QA fixes on it more easily.

/Simon

Control: reassign -1 syncthingtray
Control: retitle -1 syncthingtray: consider go-team maintain this?

I think this was a typo for "syncthingtray" and have corrected the bug's
metadata accordingly, but let me know if I guessed wrongly.

Thanks,

Colin Watson <cjwatson@debian.org> writes:

Oops, you are right, thank you!

/Simon

Hi Simon,

Simon Josefsson <simon@josefsson.org> writes:

Might you be confusing Syncthing Tray with Syncthing itself?  Syncthing
itself is implemented in Go, and it's already part of the Go Team:

https://packages.debian.org/stable/syncthing

Syncthing Tray, and its martchus-* dependencies are implemented in C++
and come from a completely different upstream.

https://packages.debian.org/stable/syncthingtray

It sounds like you're passionate about Go, so I'd like to invite you to
help maintain Syncthing itself on the Debian Go Team.  We have 1.29.5,
but upstream has moved on to 2.1.3, so there's a significant need for
help there.

Regards,
Nicholas

Nicholas D Steeves <sten@debian.org> writes:

Indeed you are right.  I found the syncthingtray package came up during
one of my golang dependency cleanups, and right now I can't reconstruct
the path that led me to believe that syncthingtray was a Go package
(possibly it could have been 'Build-Depends: syncthing').

Sorry for the noise!  Closing the bug.

I just did a dependency cleanup upload of 'syncthing', but I don't use
syncthing (although long-time user of nextcloud and have considered
setting up syncthing separately too), so I don't have confidence in
making any changes to the packaging.  Are you in a position to test
package updates, if I would make them?  If so, I could look attempting
to package a newer upstream and pushing it into experimental.  However
sometimes newer upstream releases comes with a LOT of new unpackaged
library dependencies, and I don't have cycles for any significant
undertaking here.

/Simon

Hi Simon,

Simon Josefsson <simon@josefsson.org> writes:

No worries, and thank you for your work doing dependency cleanups!

Thanks!

I heavily depend on the package and use it every day, so yes, maybe?

The primary blocker I ran into was that I couldn't figure out how to
disable the unneeded azure-related stuff and/or patch upstream
assumptions to use potentially Debian-flavoured BDs.  I confess that I
have inadequate golang knowledge and experience and I may have
misidentified the concrete material cause.

There's an unusual amount of silence about this package, and I wonder if
others have also tried to update it to 1.29.6 (IIRC this was when the
cursed azure deps were introduced), and have also failed.  I locally
imported every patch-level release before the 2.x series, compared the
delta, and IIRC decided that the Debian-contributor cost to deal with
dependency churn vs the state of upstream stability justified targeting
2.0.5.  In every case, I seemed to get everything working, except the
azure stuff.

IIRC sid has all the required deps for 2.0.5 function correctly.  Maybe
you still see where I made [a] mistake[s]? :) Any help whatsoever would
be appreciated!  Your (and arguably Marcos Talau's) changes to
debian/sid should be merged to debian/experimental, but at this point I
don't know if 1.29.5_ds1-3 and 1.29.5_ds1-4 should be
changelog-only...I feel like they may not longer be necessary for 2.0.5.

By the way, this is what I use to make d/changelog merge conflicts less
painful:

https://manpages.debian.org/unstable/dpkg-dev/dpkg-mergechangelogs.1.en.html

Cheers,
Nicholas