Re: Bug#1101076: ITP: rsync -- rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported)
[not sending to the ITP bug, since it is off-topic for that] On 2025-03-22 15:50, Samuel Henrique wrote: Given the current status of the maintenance on rsync upstream, it's going to be handy to have an alternative packaged in the repository just in case. Could you elaborate on the state of rsync upstream? I have never had any problem with rsync personally, and they appear to have made three releases in the last 12 months. Superficially, it looks like software that is approaching its platonic ideal: unchanging and bug-free. Granted, I know nothing about this except it's a silent piece of my infrastructure that has always "just worked." Is there an article about this, what is going wrong, and/or what needs to be done? Thanks, Antonio Russo
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
Hi! > >But the core of my question here was about the apparent conflict of > >signing up for LowThresholdNmu as an indication that you are open for > >collaboration, yet not having the package in VCS, which would make the > >collaboration easier. I am trying to understand why certain people > >object to using VCS while to most people I work with would not > >consider doing software development without a VCS at all. > > I have been on LowThresholdNmu for many years. I am very happy for people to > fix my packages. > > But I don't use Salsa, or a VCS, in my packaging workflow, so people ... > If someone does an NMU, I expect them to tell me (by email/bug report > containing the patch and any relevant discussion). I will then (try to > remember to) update my package from the archive before doing my next > release so I don't lose their changes in a future upload. That's > it. > > I'd prefer if they didn't stick it on Salsa because it's going to just > moulder and become out of date there (unless there are more NMUs than > maintainer updates). But I don't _really_ care - I probably won't even > notice (until the next person comes along and NMUs from an out-of-date > salsa repo - then I will get grumpy). Thanks for the explanation Wookey on why you prefer to not use VCS for Debian packaging, and why others using VCS, and thus in Debian Salsa, creates extra work for you. It seems it is easier for you to check if a package has patches by searching your email and BTS than by going to a VCS and checking what the main branch or other branches (or MRs) have pending. I assume it is also easier for you to review and discuss those patches, and submit new versions of patches and download and test patches from email than it is by pulling and pushing git commits. Just out of curiosity, what email client and plugins do you use to achieve your optimal email-based workflow?
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
At 2025-03-22T16:15:23-0700, Otto Kekäläinen wrote: > Just out of curiosity, what email client and plugins do you use to > achieve your optimal email-based workflow? I don't see where Wookey made a claim that his workflow was "optimal", merely that it was effective for him personally. Debian Developers are a diverse bunch and approach packaging with a variety of techniques. Not everyone will work exactly as another does; we shouldn't expect that. In high-dimensional spaces, a global optimum often doesn't exist. Regards, Branden signature.asc Description: PGP signature
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
Quoting Otto Kekäläinen (2025-03-21 23:14:14) > Even when doing a NMU you should communicate your intent ahead. For > example https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu > recommends specifically submitting your nmudiff to the bug report and > waiting before proceeding to upload it. For those who prefer Salsa the > equivalent would be to start by submitting a Merge Request and waiting > for some time before proceeding to merge it yourself and do NMU. I assume you mean "For those who prefer using merge requests on Salsa". Some of us (me included) prefer Salsa over Github or Sourcehut or other forges, but what we use is its git hosting service without its optional web-centric services (regardless if accessed via a web browser or a web CLI tool). > But the core of my question here was about the apparent conflict of > signing up for LowThresholdNmu as an indication that you are open for > collaboration, yet not having the package in VCS, which would make the > collaboration easier. I am trying to understand why certain people > object to using VCS while to most people I work with would not > consider doing software development without a VCS at all. Can we > improve VCS in some way to using it becomes generally accepted as a > good thing? I don't see a conflict there. I was interested in collaboration before I learned to master git, and today I am interested in collaboration even if not the same kind of collaboration that some might take for granted as being the norm. The way you phrase it here - collaboration in 2025 without using *any* system for version control - I agree that it is difficult to not read some degree of conflict into that. But if instead saying collaboration in 2025 without playing into the norm of reducing the collaboration style to simple statements in the package control file, then I can easily imagine reasons for doing so that are not contradictory. Personally I have strongly considered *removing* the hinting that the packages that I maintain are version-controlled at Salsa, to avoid anyone making too much assumptions on *how* I make use of Salsa and therefore *which* kinds of collaboration I "obviously" am doing - and I then risk having an NMU done that was notified ahead but only via Salsa chatter which I don't follow. Yes, you do not need to tell me that I can just disable merge requests. I try to remember to do that - it is tedious, because they are enabled by default and it is a lot of webby clicks to disable. I have however experienced several times that others have then turn it on again, no doubt by the assumption that it was disabled in error - i.e. again assuming that collaboration on Salsa means collaboration the common Salsa way. I can see an efficiency benefit of streamlining towards one single way to do collaboration in Debian. I am not convinced that the efficiency is the only relevant quality in collaboration, however. And to me it feels like there is a movement towards reducing variety of methods which is driven by efficiency and does not care about other reasoning. As the dgit project has meticulously mapped, there are many ways to use git for Debian packaging, and on top of that there are several ways - not only in Debian but also in the wider hacker community - of how to collaborate around git. Some of us in Debian want to explore and experiment and learn, not just get things done. That was not an answer to "why not use VCS at all" but instead to what I believe is the more appropriate question of "why not use VCS the common way" - hope that was helpful. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
Re: OpenPGP certificates with SHA-1 issues in Debian keyrings
Guillem Jover wrote... > I'm happy to try to address anything that seems unclear, or get > someone else who might be able to answer! And as Holger suggested > elsewhere, we can probably also create a FAQ on the wiki with some of > this to point to people. Thanks for your explanations, things are a lot clearer now. Christoph signature.asc Description: PGP signature
Re: Documentation for Package Maintainers regarding Translations (was: General Questions about Translations and what a package maintainer has to do)
Hello Marc, Am Wed, Mar 19, 2025 at 09:44:47AM +0100 schrieb Marc Haber: > tl;dr: New Wiki Page https://wiki.debian.org/I18n/ForPackageMaintainers, > please review I just did it. I usually updated it right away, but at one or two points it is more like a discussion. And due to my changes some redundancy is included, but I think this is more helpful during development, you can streamline it of course in the next step(s). If you have any questions on my changes it is probably best to discuss this on list. Please keep me (or -i18n) in CC, as I'm not subscribed to -devel. Thanks. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
On 2025-03-21 15:14 -0700, Otto Kekäläinen wrote: But the core of my question here was about the apparent conflict of signing up for LowThresholdNmu as an indication that you are open for collaboration, yet not having the package in VCS, which would make the collaboration easier. I am trying to understand why certain people object to using VCS while to most people I work with would not consider doing software development without a VCS at all. I have been on LowThresholdNmu for many years. I am very happy for people to fix my packages. But I don't use Salsa, or a VCS, in my packaging workflow, so people sticking it in one on Salsa is essentially irrelevant, and a little bit presumptive/annoying. I know you can't understand why anyone would do this in 2025, but as I've explained before (but you appear to have forgotten given the above message), I am happy with the quilt-based workflow I've been using for a very long time. I did try all that newflangled (git/salsa/dgit) stuff a couple of years ago, but it was mostly annoying so I went back to doing it the way I already know the runes for. If someone does an NMU, I expect them to tell me (by email/bug report containing the patch and any relevant discussion). I will then (try to remember to) update my package from the archive before doing my next release so I don't lose their changes in a future upload. That's it. I'd prefer if they didn't stick it on Salsa because it's going to just moulder and become out of date there (unless there are more NMUs than maintainer updates). But I don't _really_ care - I probably won't even notice (until the next person comes along and NMUs from an out-of-date salsa repo - then I will get grumpy). I do use VCSes for some things, just not (on the whole) debian packaging. Can we improve VCS in some way to using it becomes generally accepted as a good thing? I think it already is largely accepted as a good thing, but you cannot force it everyone, as there seems to be an increasing tendency to want to do in this project. Well you can, but if you are too annoying about it, I'll just go an spend my time on something else - I have a very long list... I'll get there eventually (probably). But the pesistent drumbeat telling me I am doing it wrong (TM) is getting a bit tiresome. I have a working system and a corresponding body of knowledge. My packages are generally sufficiently obscure that it's only me working on them. It's not broken, so at least for the time being, I prefer to spend my time on things that _do_ need fixing (I have lots of those). I remain very happy for people to do NMUs. I appreciate their effort. That does _not_ mean I must intrinsically want said packages converted to an entirely different workflow. Sorry Otto :-) Wookey -- Principal hats: Debian, Wookware http://wookware.org/ signature.asc Description: PGP signature
Re: fluster add epoch
On Saturday, March 22, 2025 1:09:29 PM Mountain Standard Time Christopher Obbard wrote: > Hi! > > For the package fluster, upstream at > http://github.com/fluendo/fluster/, we have a slight mistake with > the upstream versioning and I would like to add an epoch > > The current version in debian is 1.0.1+git20231211.d9106f5-1 (since > upstream had released 1.0.1 but later deleted the tag) and now > upstream latest version is 0.2.0+git20250319.30ac3a8 > > I am proposing to add an epoch; e.g 1:0.2.0+git20250319.30ac3a8 to > make the mistakes from the past go away. > > Does it sound OK to others ? Does upstream plan to release a 1.0.1 sometime in the future? If so, I would probably go with a 1.0.1+really0.2.0 release until upstream catches up. Typically, I don’t like to go with an epoch unless upstream does something that will never be compatible, like switching from a date release of 2025-01-27 to 1.0.1. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1101029: ITP: golang-agwa-go-listener -- library for creating net.Listeners
Package: wnpp Severity: wishlist Owner: Daniel Gröber X-Debbugs-Cc: debian-devel@lists.debian.org, d...@darkboxed.org * Package name: golang-agwa-go-listener Version : 0.6.1 Upstream Contact: Andrew Ayer * URL : https://github.com/AGWA/go-listener * License : X11-distribute-modifications-variant Programming Lang: Go Description : library for creating net.Listeners go-listener makes it easy to also listen on TCP ports, UNIX domain sockets and pre-opened file descriptors. Additionally it supports PROXY protocol and TLS wrapping with automated certificate provisioning using ACME. - This is a dependency of snid (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101006). - I'll maintain it in go-team. --Daniel signature.asc Description: PGP signature
mostly just +1 (Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?)
On Sat, Mar 22, 2025 at 08:24:34AM +0100, Jonas Smedegaard wrote: > Some of us (me included) prefer Salsa over Github or Sourcehut or other > forges, but what we use is its git hosting service without its optional > web-centric services (regardless if accessed via a web browser or a web > CLI tool). This applies to me as well. I absolutly prefer CLI, not web. That said, I often checkout salsa's MR via "git mr origin 123" with these two lines in my .gitconfig: [alias] mr = !sh -c \"git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2\" - I also do comment on MRs and salsa issues via the webbrowser *and* via mail. I also really dislike the salsa web ui. I really like salsa however. > I don't see a conflict there. I was interested in collaboration before > I learned to master git, and today I am interested in collaboration even > if not the same kind of collaboration that some might take for granted > as being the norm. > > The way you phrase it here - collaboration in 2025 without using *any* > system for version control - I agree that it is difficult to not read > some degree of conflict into that. But if instead saying collaboration > in 2025 without playing into the norm of reducing the collaboration > style to simple statements in the package control file, then I can > easily imagine reasons for doing so that are not contradictory. > Personally I have strongly considered *removing* the hinting that the > packages that I maintain are version-controlled at Salsa, to avoid > anyone making too much assumptions on *how* I make use of Salsa and > therefore *which* kinds of collaboration I "obviously" am doing - and > I then risk having an NMU done that was notified ahead but only via > Salsa chatter which I don't follow. > > Yes, you do not need to tell me that I can just disable merge requests. > I try to remember to do that - it is tedious, because they are enabled > by default and it is a lot of webby clicks to disable. I have however > experienced several times that others have then turn it on again, no > doubt by the assumption that it was disabled in error - i.e. again > assuming that collaboration on Salsa means collaboration the common > Salsa way. > > I can see an efficiency benefit of streamlining towards one single way > to do collaboration in Debian. I am not convinced that the efficiency > is the only relevant quality in collaboration, however. And to me it > feels like there is a movement towards reducing variety of methods which > is driven by efficiency and does not care about other reasoning. As the > dgit project has meticulously mapped, there are many ways to use git > for Debian packaging, and on top of that there are several ways - not > only in Debian but also in the wider hacker community - of how to > collaborate around git. Some of us in Debian want to explore and > experiment and learn, not just get things done. I very much agree with these four paragraphs. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." (Bruce Schneier) signature.asc Description: PGP signature
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
> > Just out of curiosity, what email client and plugins do you use to > > achieve your optimal email-based workflow? > > I don't see where Wookey made a claim that his workflow was "optimal", > merely that it was effective for him personally. Debian Developers are > a diverse bunch and approach packaging with a variety of techniques. > > Not everyone will work exactly as another does; we shouldn't expect > that. In high-dimensional spaces, a global optimum often doesn't exist. That is why I wrote "your optimal". It was an honest question about what setup somebody has. There is no need to start stating the obvious about people being different. Stating that one global optimum probably does not exist is also rather obvious. At the same time it can still be true that for many isolated repetitive Debian packaging tasks a global optimum can most likely be found with some effort. Regardless if a global optimum can be achieved or not, we need to tell new aspiring Debian Developers something when they ask how to do things, and that advice needs to be something that is compatible enough with everyone else to make contributions valuable. Hence asking what workflows others have is a perfectly valid question and a good topic for discussion.
Re: Bug#1101076: ITP: rsync -- rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported)
On Sat, 22 Mar 2025 at 21:50:00 +, Samuel Henrique wrote: * Package name: rsync This is going to need a different name, unless you are aiming for it to completely replace and supersede the original (samba.org) rsync. Upstream seems to call their main executable gokr-rsync, which seems as good a name for the package as any other? smcv
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
On 2025-03-22 16:15 -0700, Otto Kekäläinen wrote: Thanks for the explanation Wookey on why you prefer to not use VCS for Debian packaging, and why others using VCS, and thus in Debian Salsa, creates extra work for you. Just out of curiosity, what email client and plugins do you use to achieve your optimal email-based workflow? Nothing fancy: (remote) mutt, dget, mc, meld, zile/jed/emacs, uscan, tracker.debian.org, bts, the firefox 'debian' plugin, wget, sshfs/scp, quilt, dch (and sbuild/schroot, debsign, dupload to build and upload) Wookey -- Principal hats: Debian, Wookware http://wookware.org/ signature.asc Description: PGP signature
Bug#1101076: ITP: rsync -- rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported)
Package: wnpp Severity: wishlist Owner: Samuel Henrique X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: rsync Version : 0.2.6-1 Upstream Author : Michael Stapelberg * URL : https://github.com/gokrazy/rsync * License : BSD-3-clause Programming Lang: Go Description : rsync in Go! implements client and server, which can send or receive files (upload, download, all directions supported) Given the current status of the maintenance on rsync upstream, it's going to be handy to have an alternative packaged in the repository just in case. I haven't played much with this software yet, but I plan to package it for forky. Thank you, -- Samuel Henrique
