Hi Federico, The updated package looks good to me. I installed it locally and it passes my (limited) smoke tests, and I will upload it soon. I will handle merging and tagging for this upload, but include some comments in-line below.
On Thu, May 21, 2026 at 11:53:57PM -0400, Federico Grau wrote: > Hello debian-hams and debian-go -- > > I've packaged pat v1.0.0 , pushed my work to my personal repo on > salsa.d.o , and created a MR. > > https://salsa.debian.org/debian-hamradio-team/pat/-/merge_requests/3 > https://tracker.debian.org/pkg/pat > > As noted in the MR, the biggest improvement is replacing > howeyc/gopass with golang.org/x/term , removing pat's risk > to Debian #1130525 . > > The update also includes: > Some web ui, config, and panic bug fixes. > Some refactoring of code. > Debian standards updated from 4.7.3 to 4.7.4 , with no changes required. > Updated d/patches. > > > I again express some minor concerns with "blob" updates to > javascript and JSON as part of upstream "pre-release script" > commit c1f8b1533859faadd14482d6372954c9434957ae on 2026-04-19 > 17:57 +0200 > > internal/cmsapi/gateway_status.json.gz > web/dist/js/config.js > web/dist/js/config.js.map > > https://github.com/la5nta/pat > > These blob updates match previous releases. However, given their > "blob" nature I am unable to thoroughly review their changes. I agree that these are unfortunate, but they are not unprecedented. There are some tools available for comparing minified Javascript, but I do not have much experience with them. We may be able to work them into our workflow. > While I've created MR before, this is my first time create a MR > for the package/repo I maintain. Would I accept the MR, or > someone else? Similarly, I'm not clear who or when debian signed > tags should be created in the process. If you are seeking review and/or sponsorship, I think it is typical for the reviewers to accept the MR and perform the merge. But this is admittedly my preference for keeping the primary branch (in this case debian/sid) in sync with what is in the archive - primarily to reduce the chance of any potential confusion of those using the archive without following the list. For signed tags, I believe the uploader should do this. When sponsoring, the sponsor is asserting that they have reviewed the package and take responsibility for the upload. Therefore, they should tag and sign. Again, the tagging should match what is available in the archive. Regarding process, I have always found Salsa MRs a little clunky for new versions. It would be convenient if the MR was one logical entity that encompassed the upstream branch as well. My process is to add your remote to my local, merge your "upstream" branch into my local branch, checkout the MR branch, build, review, make any minor tweaks needed to the packaging, etc. Once testing is done, I merge the MR, rebuild once again, sign and upload, tag, and then push the branches and tags. > After review and feedback, if there are no blocking items I > welcome next steps to upload `pat' to unstable for additional > testing, or alternate constructive guidance. I will upload after the rebuild from the primary branch. Thank you for your contribution to Debian! tony
