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
Description: PGP signature
