Bug#1143447: RFA: microsocks -- multithreaded, small, efficient SOCKS5 server

Peter Pentchev <[email protected]> Fri, 7 Aug 2026 20:21:59 +0300
Newsgroups	gmane.linux.debian.devel.wnpp
Message-ID	<anYUMfSoMeLVt0_b__21602.8532174946$1786123408$gmane$org@straylight.m.ringlet.net>
On Fri, Aug 07, 2026 at 02:29:26PM +0200, Federico Molara wrote:
> Hi Peter,
> 
> I am interested in possibly adopting the Debian microsocks package following
> your RFA #1143447, but I have not filed an ITA yet.
> 
> I have reviewed the current Debian packaging and the small upstream codebase,
> checked the BTS, tracker, Salsa repository/CI, upstream status, reverse
> dependencies, popcon, and the security tracker, and rebuilt the unchanged
> 1.0.5-3 package in an updated unstable sbuild environment. The source and
> binary builds, the nocheck profile, lintian, autopkgtest, uscan, and the
> test-tunnel functional tests all passed; Debian's reproducibility status and
> the current Salsa pipeline are also green.

Yeah, I do try to leave packages in good shape :) But thanks for making sure!

> I also found a few upstream-facing
> robustness points around SOCKS-over-TCP framing, handshake timeouts, and cleanup
> when pthread_create() fails that I would like to discuss rather than change
> without coordination.

That would better be discussed with upstream, yes. Over the years
I have found that different upstream authors have vastly different ideas
about how far a packager should be expected to diverge, and I myself have,
once or twice, done something that other DDs have called
"developing in debian/" (extensive patches that change the way
the software behaves), and sometimes this is really not a good idea once
you realize you have to *maintain* those patches as the upstream source
changes over the years :) But sometimes it is necessary because
the authors simply won't accept a change that really, really makes sense
at least in the Debian context.

> Could you tell me what you would expect from the handover and whether there is
> any pending work or preferred maintenance workflow I should know about?

Pending work - not right now, I can't think of anything. Pretty much wait for
the next upstream release or, if a Debian build tool gets some new shiny
functionality, see if it will simplify the packaging even further.

Maintenance workflow - I personally have used the "quilt with patches
unapplied" way until now. Import a new upstream version with `gbp import-orig`,
then `quilt push -a` and `quilt push -f`, edit, `quilt refresh -p ab` until
I get the patches right for the new release. For the actual upload to
the Debian archive I use `dgit push-source` for a new upstream release
(although that might change now that tag2upload seems to be learning
about pristine-tar) and `git debpush` for the later Debian-only revisions.
But yeah, if you do not have upload rights, you would need sponsoring for
at least the first couple of uploads; in that case, nothing unusual again -
`dch -r`, commit, push, request sponsorship, and only add a signed tag
once the package is actually uploaded (or let the sponsor do that).

And of course, none of the steps I listed above are set in stone -
a new maintainer may do things in a completely different way, and
that's fine :)

> If I decide to proceed, would you be willing to accompany me through
> the handover and, explicitly, to review and sponsor my first upload?

Sure, no problem! And thank you for your interest in this package!

G'luck,
Peter

-- 
Peter Pentchev  [email protected] [email protected] [email protected]
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
signature.asc (application/pgp-signature, 833 B)