Re: General Questions about Translations and what a package maintainer has to do
Le Tue, Mar 11, 2025 at 12:03:51PM +0100, Marc Haber a écrit : > tl;dr: We need more docs about best practices to handle translations as > a package maintainer I would suggest you find someone on debian-i18n willing to handle translations for adduser for you and give them commit access. That is how popularity-translation translation have been handled for a long time (thanks, Christian Perrier, I learned everything about translations handling this way!) Cheers, Bill.
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
Hi Sam, Am Tue, Mar 25, 2025 at 10:19:59AM -0600 schrieb Sam Hartman: > > Andreas> Another upload, with the removal of the Vcs fields, would > Andreas> effectively undo the move to Salsa from a package > Andreas> maintenance perspective. As far as NMU rules are concerned, > Andreas> I would consider myself responsible for any unintended > Andreas> consequences caused by my NMU and would take the necessary > Andreas> actions to address them. > > I do not find this response compelling. > I think having NMUs like you are talking about create and leave > dangling-but-unused repos in the debian namespace on salsa is > undesirable. > So, I disagree with the idea that simply removing the VCS headers gets > us back to the previous state. > I think that the debian namespace repo also needs to be removed. I confirm I missed that bit. I agree that the repository should be finally removed. I was just talking about the user visible part of the NMU. This leaves the drawback that Salsa admins will have extra work in the very improbable case that the repository needs to be cleaned up later on. > However, I support your work even if undoing the changes is harder than > you claim it is. > I think we should have significant latitude in improving the situation > of the kind of packages you are talking about. > Please count me as someone supporting you going forward full steam > ahead. Thank you Andreas. -- https://fam-tille.de
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
This mail was sent as Message-ID: at Date: Mon, 24 Mar 2025 17:15:10 +0100 but never reached the list. I'm sending from a different address now I hope forwarding from my sent folder will not break the thread. [Some people are in CC. If you wonder why just seek for your first name.] Hi Tobias, please let me say in advance that I highly appreciate your work in the MIA team and on drafting and refining the ITS procedure. That's really great work and its extremely helpful. Since I highly evaluate your insight into these topics I'm happy about any comment of yours like the mail I'm now answering here (while trying not to repeat what Otto wrote in his response). Am Sun, Mar 23, 2025 at 12:03:26PM +0100 schrieb Tobias Frost: > (this should probably go to vote as general questions for the candiates, > but I'm not having enought time right now to pursue this.) I'm fine with answering on vote but I do not think that I should actively move to this list. Anyone is kindly invited to quote me there and ask specific questions. > On Thu, Mar 20, 2025 at 03:36:48PM +0100, Andreas Tille wrote: > > > > I agree that *uncoordinated* NMUs should not simply choose Salsa as VCS. > > How do you define "*uncoordinated*" NMUs? For me uncoordinated means: Not informing the maintainer and giving a sufficient amount of time to respond. > What makes it "not uncoordinated" in your view? Informing the maintainer by 1. Add the Maintainer ID in CC to every conversation 2. Follow the timing established in ITS procedure to enable a sensible response time > > I'd like to stir some constructive discussion about this-hopefully > > leading to a procedure that is acceptable to everyone and can be > > finalized for discussion at DebCamp. > > Andreas, the this is the correct approach. First discuss changes and > then implement them when project consensus has been reached. > > Do you agree on this principle on the how to work together in Debian? I fully agree with this principle. At the same time, I think it's important to acknowledge that, in practice, there have been cases-such as NMUs adjusting source format to 3.0, Standards-Version updates, debhelper compatibility level bumps, or migration from cdbs to dh-where changes were made before a formal consensus was explicitly documented. As we have discussed previously, NMUs have evolved beyond what is currently reflected in the Developer's Reference, and I strongly support updating our documentation to clarify what is considered acceptable. That said, I believe that practical experimentation can sometimes provide valuable insights to initiate a well-informed discussion on complex topics. In December, we had an initial exchange on this topic [2], and I plan to prepare something for a more structured discussion at DebCamp. Mailing list discussions are valuable, but I think an in-person exchange may be more productive for refining our approach. Of course, any such experiments should be well-communicated and remain harmless. In the case of migrating a package to a Salsa Git repository, for example, the change is fully reversible-removing the Vcs fields is all it takes to restore the previous state. The goal is not to impose changes unilaterally but to explore practical steps that can lead to a broader discussion based on existing cases. We simply need to acknowledge that volunteer participation is fluid-some contributors may step away without explicitly announcing it. The MIA team does an important job of identifying and reaching out to inactive maintainers, but this process naturally takes time. In the meantime, if NMUs are difficult to apply, affected packages may remain blocked for extended periods. This is not a shortcoming of the MIA team, but rather an inherent challenge in a volunteer-driven project, where formal transitions don't always happen in a predictable way. > Unfortunatly1 I have to ask this question, as this is not how you and > (your|the) salvaging team is operating at the moment - IMHO. We have addressed the concerns you raised about the use of the ITS procedure in bug #1093192. In another bug report (#1094788), you suggested using the NMU process to fix bugs. I consider the ITS procedure to be well-crafted and highly appropriate in cases where a new person is willing to take responsibility for maintaining a package. The key question remains: What should be done with packages where no one steps forward to take responsibility by adding themselves as Maintainer or Uploader? Please keep in mind that none of the participants in this discussion on debian-devel are directly affected by the problem at hand. There have been valid arguments against using Salsa for certain packages-for example, Wookey has expressed concerns, and his viewpoint is fully respected. However, his packages are actively maintained and do not appear as candidates for the kind of NMU we did in the examples you named below. The real issue is that the people participating in this
Bug#1101312: ITP: golang-filippo-bigmod -- constant-time library for big integers modulo a prime
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-filippo-bigmod Version : 0.0.3-1 Upstream Author : Filippo Valsorda * URL : https://github.com/FiloSottile/bigmod * License : BSD-3-clause Programming Lang: Go Description : constant-time library for big integers modulo a prime (Go library) Package bigmod implements constant-time big integer arithmetic modulo large odd moduli. Unlike math/big, this package is suitable for implementing security-sensitive cryptographic operations. It is a re-exported version the standard library package crypto/internal/bigmod used to implement crypto/rsa amongst others. Needed by github.com/openpubkey/openpubkey needed by github.com/openpubkey/opkssh. https://salsa.debian.org/go-team/packages/golang-filippo-bigmod https://salsa.debian.org/jas/golang-filippo-bigmod/-/pipelines /Simon signature.asc Description: PGP signature
Bug#1101310: ITP: opkssh -- opkssh (OpenPubkey SSH)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: opkssh Version : 0.3.0-1 Upstream Author : * URL : https://github.com/openpubkey/opkssh * License : Apache-2.0 Programming Lang: Go Description : opkssh (OpenPubkey SSH) opkssh (OpenPubkey SSH) is a tool which enables ssh to be used with OpenID Connect allowing SSH access management via identities like al...@example.com instead of long-lived SSH keys. It does not replace ssh, but rather generates ssh public keys that contain PK Tokens and configures sshd to verify the PK Token in the ssh public key. These PK Tokens contain standard OpenID Connect ID Tokens. This protocol builds on the OpenPubkey (https://github.com/openpubkey/openpubkey/blob/main/README.md) which adds user public keys to OpenID Connect without breaking compatibility with existing OpenID Provider. https://salsa.debian.org/go-team/packages/opkssh https://salsa.debian.org/jas/opkssh/-/pipelines /Simon 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)
On Mon, Mar 24, 2025 at 06:33:19PM +, Helge Kreutzmann wrote: Am Mon, Mar 24, 2025 at 05:49:40PM +0100 schrieb Marc Haber: "Using no line numbers" => invoke msgmerge with --no-location? Yes. "Web pages mentioned above" => I don't see web pages being mentioned. That needs a name or a link I meant the references to the Debian status pages, the link I inserted further above: https://www.debian.org/international/l10n/ Please reword this to make it more clear. Done. "Add code in your build system to discard po(t) that only change in the date stamp" => that would mak ethe source package and the tag in the VCS diverge. I don't like that at all. This I don't understand. At some stage you update the POT files. Then you run a (git) commit, to place the updated files in your repository. Yes, this should be a manual process, in my opinion. In manpages-l10n Tobias added code to detect, if only the time stamp changed. If so, the time stamp is reverted to the previous value, and a "git commit" is a noop. Then also the po files are left alone. That should be a feature of xgettext or the other tools that might write the POT files: Don't regenerate the file if the only change is the time stamp. Since xgettext is unlikely to change¹ This "only" saves you a commit in this corner case. It is not meant to diverge version, because in the end the po(t) files in your package should match the po(t) files in the repository. The problem ist when POT and PO files are regenerated (and actually change) in package build when you're doing an out-of-tree build. For example, I have export-dir=../build-area set in my gbp.conf. When building a package, gbp copies the current working copy (or exports the requested branch) to a temporary directory under ../build-area/ and does the actual build from there. The temporary build directory is then discarded, leaving the current working copy unchanged. When the build process regenerates POT and PO files, those changes never find their way back into your working copy, making the source package and the VCS diverge. That's why I believe that any point in the package build is the wrong place to regenerate PO and POT files. Either that, or we need to strongly discourage doing out-of-tree builds. Greetings Marc ¹ I tried to put some of the ideas that this discussion brought into xgettext / msgmerge bugs and they got rejected upstream quite quickly. I will refrain from wasting my time in this regard in the future. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1101318: ITP: golang-github-awnumar-memguard -- Secure software enclave for storage of sensitive information in memory.
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-awnumar-memguard Version : 0.22.5-1 Upstream Author : Awn * URL : https://github.com/awnumar/memguard * License : Apache-2.0 Programming Lang: Go Description : Secure software enclave for storage of sensitive information in memory. This package attempts to reduce the likelihood of sensitive data being exposed when in memory. It aims to support all major operating systems and is written in pure Go. . Features . * Sensitive data is encrypted and authenticated in memory with XSalsa20Poly1305. The scheme (https://spacetime.dev/encrypting-secrets-in- memory) used also defends against cold-boot attacks (https://spacetime.dev/memory-retention-attacks). * Memory allocation bypasses the language runtime by using system calls (https://github.com/awnumar/memcall) to query the kernel for resources directly. This avoids interference from the garbage-collector. * Buffers that store plaintext data are fortified with guard pages and canary values to detect spurious accesses and overflows. * Effort is taken to prevent sensitive data from touching the disk. This includes locking memory to prevent swapping and handling core dumps. * Kernel-level immutability is implemented so that attempted modification of protected regions results in an access violation. * Multiple endpoints provide session purging and safe termination capabilities as well as signal handling to prevent remnant data being left behind. * Side-channel attacks are mitigated against by making sure that the copying and comparison of data is done in constant-time. https://salsa.debian.org/go-team/packages/golang-github-awnumar-memguard https://salsa.debian.org/jas/golang-github-awnumar-memcall/-/pipelines /Simon signature.asc Description: PGP signature
Bug#1101317: ITP: golang-github-awnumar-memcall -- Cross-platform wrapper for memory-related system calls
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-awnumar-memcall Version : 0.4.0-1 Upstream Author : Awn * URL : https://github.com/awnumar/memcall * License : Apache-2.0 Programming Lang: Go Description : Cross-platform wrapper for memory-related system calls. This package provides a cross-platform wrapper over some common memory- related system calls. Needed by github.com/awnumar/memguard needed by github.com/openpubkey/openpubkey https://salsa.debian.org/go-team/packages/golang-github-awnumar-memcall https://salsa.debian.org/jas/golang-github-awnumar-memcall/-/pipelines /Simon signature.asc Description: PGP signature
Re: Should uncoordinated NMUs unilaterally choose Salsa as the VCS for a package?
> "Andreas" == Andreas Tille writes: >> The move to the debian namespace cannot be easily undone, as >> those repos are protected and require an salsa admin to act on >> e.g for (re)moving it. Andreas> Another upload, with the removal of the Vcs fields, would Andreas> effectively undo the move to Salsa from a package Andreas> maintenance perspective. As far as NMU rules are concerned, Andreas> I would consider myself responsible for any unintended Andreas> consequences caused by my NMU and would take the necessary Andreas> actions to address them. I do not find this response compelling. I think having NMUs like you are talking about create and leave dangling-but-unused repos in the debian namespace on salsa is undesirable. So, I disagree with the idea that simply removing the VCS headers gets us back to the previous state. I think that the debian namespace repo also needs to be removed. However, I support your work even if undoing the changes is harder than you claim it is. I think we should have significant latitude in improving the situation of the kind of packages you are talking about. Please count me as someone supporting you going forward full steam ahead.
Re: The apt tool chain doesn't seem to sanitize it's environment
On Mon, 24 Mar 2025 13:59:00 -0700, John Darrah
wrote:
>Insecure $ENV{CDPATH} while running with -T switch at
>/usr/share/perl5/Debian/AdduserLogging.pm line 157.
As this is another instance of probably the same issue in adduser:
Should adduser clear out its environment completely when invoked?
In the mean time, I have added code to adduser to unset $ENV{CDPATH}.
Greetings
Marc
--
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
Re: General Questions about Translations and what a package maintainer has to do
On Wed, 19 Mar 2025 15:05:56 +0100, Dirk Lehmann wrote: >I have a bit played around with `msgmerge` and found a way to display >a `diff` which contains the translations which will be destroyed if >you merge a .po file from a translator > > * test-de_DE-transl.po > >into your maintained one > > * test-de_DE.po > >in conjunction with the current generated .pot file > > * test.pot > >The essential code snippet looks like this > >** >* >* msgmerge -q -C test-de_DE-transl.po test-de_DE.po test.pot \ >* > test-de_DE-maint+transl.po >* msgmerge -vv -q -C test-de_DE.po test-de_DE-transl.po test.pot \ >* > test-de_DE-transl+maint.po >* >* # Print out the new merged .po file >* cat test-de_DE-transl+maint.po >* >* # Show the diff of destroyed translations (including comments) >* diff -u test-de_DE-maint+transl.po test-de_DE-transl+maint.po >* >** I think this is way beyond what we could expact from J Random Package Maintainer, unless it is fully automated and can be documented and packaged. Greetings Marc -- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
