Hi Simon, Simon Frei <freisi...@gmail.com> writes:
> -----BEGIN PGP SIGNED MESSAGE----- > 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 <alexan...@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) https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ * 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: https://ftp-master.debian.org/REJECT-FAQ.html https://ftp-master.debian.org/NEW-checklist.html Other resources are debian-ment...@lists.debian.org and #debian-ment...@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. Cheers, Nicholas
signature.asc
Description: PGP signature
