Re: Proposed MBF: packages that FTBFS with make --shuffle
Santiago Vila writes: > Single-CPU systems are ubiquitous in the cloud. I was a system admin in > a small startup some time ago. Everything was in the cloud, and one of my > duties was naturally to reduce the IT bill if possible, so I used single-cpu > systems extensively, as they are almost always cheaper. What about virtual machine instances with an odd number of CPU cores (larger than one)? I recall encountering some peculiar bugs with three vCPU machines years ago.
Bug#1105841: ITP: golang-github-gohxs-readline -- Go implementation of GNU Readline (library)
Package: wnpp Severity: wishlist Owner: Otto Kekalainen * Package name: golang-github-gohxs-readline Version : 1.4 Upstream Author : Luis Figueiredo * URL : https://github.com/gohxs/readline * License : Expat Programming Lang: Go Description : Go implementation of GNU Readline (library) This package provides a Go library for implementing readline functionality, enabling interactive command-line interfaces with line editing and history management. It offers a lightweight and flexible API for developers building terminal-based applications, allowing efficient handling of user input. It includes the source code and development files for integrating the library into Go projects. The library is particularly useful for creating custom CLI tools or interactive shells, supporting features like tab completion and history navigation. Primary motivation: This is one of the build dependencies for 'usql'.
Bug#1105842: ITP: golang-github-google-goexpect -- Go implementation of Expect (library)
Package: wnpp Severity: wishlist Owner: Otto Kekalainen * Package name: golang-github-google-goexpect Version : 0.0~git20210430.ab937bf Upstream Author : Google * URL : https://github.com/google/goexpect * License : BSD-3-clause Programming Lang: Go Description : Go implementation of Expect (library) This package provides a Go library for automating and testing interactive programs by simulating user input and matching expected output. It enables developers to script interactions with command-line applications, making it ideal for testing, automation, and building robust CLI tools in Go. It includes the source code and development files for integrating the library into Go projects. With support for regular expression-based matching and timeout handling, it offers a powerful and flexible way to manage terminal-based interactions programmatically Primary motivation: This is one of the build dependencies for 'usql'.
Bug#1105843: ITP: golang-github-mattn-go-sixel -- Go library for DRCS Sixel graphics encoding and decoding
Package: wnpp Severity: wishlist Owner: Otto Kekalainen * Package name: golang-github-mattn-go-sixel Version : 0.0.5 Upstream Author : Yasuhiro Matsumoto * URL : https://github.com/mattn/go-sixel * License : Expat Programming Lang: Go Description : Go library for DRCS Sixel graphics encoding and decoding This package provides a Go library for encoding and decoding SIXEL graphics, enabling developers to render images in terminals that support the SIXEL protocol. It includes tools for creating and processing SIXEL images with features like dithering, color quantization, and customizable dimensions, making it suitable for terminal-based applications. It contains the source code and development files for integrating the library into Go projects. Ideal for building terminal image viewers or graphics tools, it supports efficient handling of paletted images and is compatible with terminals like iTerm2 and those supporting DRCS SIXEL graphics. Primary motivation: This is one of the build dependencies for 'usql'.
Bug#1105845: ITP: golang-github-ziutek-telnet -- Go library for handling Telnet connections
Package: wnpp Severity: wishlist Owner: Otto Kekalainen * Package name: golang-github-ziutek-telnet Version : 0.1.0 Upstream Author : Michał Derkacz * URL : https://github.com/ziutek/telnet * License : Expat Programming Lang: Go Description : Go library for handling Telnet connections This package provides a Go library for managing Telnet connections, enabling developers to create robust Telnet clients for interacting with remote servers. It offers a simple interface for handling Telnet protocol specifics, such as option negotiation, echo control, and data transfer, making it suitable for automating interactions with Telnet-based systems. It includes the source code and development files for integrating the library into Go projects. With features like reading until delimiters and support for Unix-style line endings, it is ideal for building command-line tools, network automation scripts, or custom Telnet clients. Primary motivation: This is one of the build dependencies for 'usql'.
Bug#1105844: ITP: golang-github-xo-tblfmt -- treaming, buffered table encoder for result sets (ie from a database)
Package: wnpp Severity: wishlist Owner: Otto Kekalainen * Package name: golang-github-xo-tblfmt Version : 0.15.1 Upstream Author : XO and Kenneth Shaw * URL : https://github.com/xo/tblfmt * License : Expat Programming Lang: Go Description : Streaming, buffered table encoder for result sets (ie from a database) This package provides a Go library for formatting and rendering tabular data into various output formats, such as plain text, CSV, or Markdown. It offers a flexible and customizable API for developers to create well-structured tables in command-line applications or other Go programs. It includes the source code and development files for integrating the library into Go projects. With support for customizable column alignment, padding, and styling, it is ideal for generating readable and professional-looking table outputs in terminal-based tools or data processing applications. Primary motivation: This is one of the build dependencies for 'usql'.
Re: Question about splitting a source package with an epoch
Soren Stoutner writes: > Manuel and I would like to split this into two source packages, based on > these > two upstream source repositories: > > https://github.com/OpenTaal/opentaal-hunspell > > https://github.com/OpenTaal/opentaal-wordlist > > The current dutch package has an epoch for reasons that happened before we > were involved with the package: 1:2.20.19+1-1. This doesn't look right, because $ rmadison hunspell-nl -s unstable hunspell-nl | 2:2.20.19+1-1 | unstable | all Ie: Wrong epoch, which I hope is just a typo. I also don't think ftpmasters will agree that a NEW package should have an epoch... I'm CCing -devel, because introducing epochs must be discussed there, and I count a NEW package as introducing an epoch. > If we create a new source package named hunspell-nl, it would also > need to have the same epoch. Why not take the opportunity to remove the epoch? The upstream names are opentaal-hunspell and opentaal-wordlist, so why not: 1. Create src:opentaal-hunspell and src:opentaal-wordlist 2. Use bin:opentaal-hunspell[-nl] and bin:opentaal-wordlist[-nl] 3. Create a dutch metapackage in one of these two NEW src:opentaal.* packages 4. Use versioned Provides, with epoch, in the dutch metapackage. > As I have never moved a binary package to a new source package, my question > is > two-fold. > > 1. Should I create an ITP for the new source package, even though the binary > package it produces is not new? Something about creating an ITP that > includes > an epoch feels off to me. I think that feeling is this: NEW packages shouldn't have epochs. > 2. When moving the binary package to a new source package, should the old > changelog be preserved? It seems even weirder to me to have a one-line > changelog that says “Initial release” that already contains an epoch. Rather than "moving", why not think about it as new upstream source (via two packages) and a takeover of the previous namespace? Please retain me in CC. Regards, Nicholas signature.asc Description: PGP signature
Re: Question about splitting a source package with an epoch
On Thursday, May 15, 2025 3:56:50 PM Mountain Standard Time Nicholas D Steeves wrote: > "adjusting" the epoch also requires discussion, and consensus, on -devel As far as I know, nobody is proposing adding or adjusting any epochs. All of these binary packages are going to end up with the same epochs they already have. > We have > an obligation to avoid epochs whenever possible, and the way that we do > this is by deductively eliminating alternatives such as Breaks, > Replaces, and Provides. Maybe I missed part of this thread? If so, > where can I read that this was demonstrated? I completely agree. I detest epochs and do everything I can to avoid using them. The background (partially explained in the first email) is that this is a package I recently salvaged. It has never had a working debian/watch file and cannot have one in its current state because the original maintainer combined sources from multiple upstream sources with potentially distinct release schedules. As part of bringing the package up to Debian standards, I need to split it into two source packages that match the upstream repositories. At some point in the past, an epoch was added to this package. I am unaware of the history of why this was done. I also don’t know why one of the binary packages has an epoch of 2 (something I learned in this email chain), while the other three have an epoch of 1. As much as I would like to get rid of the epochs, I don’t see any way to do so. My original question (posted on debian-mentors) was not really about how to handle the epochs of the binary files, but how to handle the changelog files. I have never split a source package before, and certainly not one with an epoch. I assumed that the new source package needed to start out with a new debian/changelog, and creating one with a single entry with an epoch seemed wrong to me. However, it was pointed out that when splitting a source package, it is appropriate to maintain the debian/changelog history, in which case I can simply explain in the changelog that the binary package was moved to a new source package and the previous debian/changelog history will make it obvious why the epoch was maintained. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Question about splitting a source package with an epoch
On Thursday, May 15, 2025 1:07:32 PM Mountain Standard Time Nicholas D Steeves wrote: > Soren Stoutner writes: > > Manuel and I would like to split this into two source packages, based on > > these two upstream source repositories: > > > > https://github.com/OpenTaal/opentaal-hunspell > > > > https://github.com/OpenTaal/opentaal-wordlist > > > > The current dutch package has an epoch for reasons that happened before we > > were involved with the package: 1:2.20.19+1-1. > > This doesn't look right, because > > $ rmadison hunspell-nl -s unstable > hunspell-nl | 2:2.20.19+1-1 | unstable | all > > Ie: Wrong epoch, which I hope is just a typo. I also don't think > ftpmasters will agree that a NEW package should have an epoch... I'm > CCing -devel, because introducing epochs must be discussed there, and I > count a NEW package as introducing an epoch. The changelog indeed says the current epoch is 1: https://salsa.debian.org/debian/dutch/-/blob/master/debian/changelog? ref_type=heads#L1 Also, tracker.debian.org says the same thing: https://tracker.debian.org/pkg/dutch It is interesting that rmadison says differently. Is this some automatic adjustment in dak? If so, I would imagine that it would make sense to adjust the epoch to 2 in package changelog. > > If we create a new source package named hunspell-nl, it would also > > need to have the same epoch. > > Why not take the opportunity to remove the epoch? The upstream names > are opentaal-hunspell and opentaal-wordlist, so why not: > > 1. Create src:opentaal-hunspell and src:opentaal-wordlist > 2. Use bin:opentaal-hunspell[-nl] and bin:opentaal-wordlist[-nl] > 3. Create a dutch metapackage in one of these two NEW src:opentaal.* > packages 4. Use versioned Provides, with epoch, in the dutch metapackage. I would love to, but the binary package names are not negotiable because they are set by Debian’s dictionary policy. For example, the hunspell-nl binary package needs to retain this name to match the other hunspell dictionaries. Similarly for aspell-nl, wdutch, and idutch. You can read over the policy with the following URL when the dictionaries- common-dev package is installed. file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#AEN174 On Thursday, May 15, 2025 1:41:16 AM Mountain Standard Time Santiago Vila wrote: > El 15/5/25 a las 0:39, Soren Stoutner escribió: > > 2. When moving the binary package to a new source package, should the old > > changelog be preserved? It seems even weirder to me to have a one-line > > changelog that says “Initial release” that already contains an epoch. > > I think it depends on whether or not you consider the new source to be > a successor of the old one. > > For example, the hello package which did not use debhelper at first was > "forked" to hello-debhelper. Because it was a "fork", it retained the old > changelog. This is indeed a continuation of the existing upstream source, meaning that the source in the current package came from two different repositories (combined in a way different than what MUT would do). Creating a new source package and including the current changelog makes the most sense to me. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Question about splitting a source package with an epoch
On Thu, 15 May 2025 at 13:39:32 -0700, Soren Stoutner wrote: The changelog indeed says the current epoch is 1: https://salsa.debian.org/debian/dutch/-/blob/master/debian/changelog? ref_type=heads#L1 Also, tracker.debian.org says the same thing: https://tracker.debian.org/pkg/dutch That's the version of the source package. The version of a binary package defaults to the same as its source, but it can be different, and in this case, it is: dh_gencontrol -p hunspell-nl -- -v2:$(DEB_VERSION_UPSTREAM_REVISION) — https://tracker.debian.org/media/packages/d/dutch/rules-12.20.191-1 smcv
Re: Question about splitting a source package with an epoch
Soren Stoutner writes: > On Thursday, May 15, 2025 1:07:32 PM Mountain Standard Time Nicholas D > Steeves > wrote: >> Soren Stoutner writes: >> > Manuel and I would like to split this into two source packages, based on >> > these two upstream source repositories: >> > >> > https://github.com/OpenTaal/opentaal-hunspell >> > >> > https://github.com/OpenTaal/opentaal-wordlist >> > >> > The current dutch package has an epoch for reasons that happened before we >> > were involved with the package: 1:2.20.19+1-1. >> >> This doesn't look right, because >> >> $ rmadison hunspell-nl -s unstable >> hunspell-nl | 2:2.20.19+1-1 | unstable | all >> >> Ie: Wrong epoch, which I hope is just a typo. I also don't think >> ftpmasters will agree that a NEW package should have an epoch... I'm >> CCing -devel, because introducing epochs must be discussed there, and I >> count a NEW package as introducing an epoch. > > The changelog indeed says the current epoch is 1: > > https://salsa.debian.org/debian/dutch/-/blob/master/debian/changelog? > ref_type=heads#L1 > > Also, tracker.debian.org says the same thing: > > https://tracker.debian.org/pkg/dutch > > It is interesting that rmadison says differently. Is this some automatic > adjustment in dak? If so, I would imagine that it would make sense to adjust > the epoch to 2 in package changelog. "adjusting" the epoch also requires discussion, and consensus, on -devel >> > If we create a new source package named hunspell-nl, it would also >> > need to have the same epoch. >> >> Why not take the opportunity to remove the epoch? The upstream names >> are opentaal-hunspell and opentaal-wordlist, so why not: >> >> 1. Create src:opentaal-hunspell and src:opentaal-wordlist >> 2. Use bin:opentaal-hunspell[-nl] and bin:opentaal-wordlist[-nl] >> 3. Create a dutch metapackage in one of these two NEW src:opentaal.* >> packages 4. Use versioned Provides, with epoch, in the dutch metapackage. > > I would love to, but the binary package names are not negotiable because they > are set by Debian’s dictionary policy. For example, the hunspell-nl binary > package needs to retain this name to match the other hunspell dictionaries. > Similarly for aspell-nl, wdutch, and idutch. Understood, and my binary package names are just a suggestion. We have an obligation to avoid epochs whenever possible, and the way that we do this is by deductively eliminating alternatives such as Breaks, Replaces, and Provides. Maybe I missed part of this thread? If so, where can I read that this was demonstrated? Thanks Nicholas signature.asc Description: PGP signature
Bug#1105839: ITP: ovpn-dkms -- OpenVPN data channel offload (ovpn)
Package: wnpp Severity: wishlist Owner: Bernhard Schmidt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ovpn-dkms Version : Git snapshot Upstream Contact: Antonio Quartulli * URL : https://github.com/OpenVPN/ovpn-backports/ * License : GPL-2.0 Programming Lang: C Description : OpenVPN data channel offload (ovpn) This DKMS module will provide a backport of the OpenVPN 2.7+ data channel offloading module that has been merged in Linux mainline 6.14+. I intend to upload this to experimental and later to Forky as soon as it opens up for development, together with OpenVPN 2.7 releases. The main use would be to backport both to Trixie and Bookworm to get them proper in-the-field test coverage. This package is basically the successor of openvpn-dco-dkms, the old out-of-tree DCO module only supported with OpenVPN 2.6. They can both be coinstalled, OpenVPN will use the correct module. I expect to be able to drop both for the Forky release.
Re: Question about splitting a source package with an epoch
On Thursday, May 15, 2025 1:54:36 PM Mountain Standard Time Simon McVittie wrote: > On Thu, 15 May 2025 at 13:39:32 -0700, Soren Stoutner wrote: > >The changelog indeed says the current epoch is 1: > > > >https://salsa.debian.org/debian/dutch/-/blob/master/debian/changelog? > >ref_type=heads#L1 > > > >Also, tracker.debian.org says the same thing: > >https://tracker.debian.org/pkg/dutch > > That's the version of the source package. The version of a binary > package defaults to the same as its source, but it can be different, and > in this case, it is: > > dh_gencontrol -p hunspell-nl -- -v2:$(DEB_VERSION_UPSTREAM_REVISION) > — https://tracker.debian.org/media/packages/d/dutch/rules-12.20.191-1 > > smcv Thanks for the pointer. Cleaning up the debian/watch file was one of the checkboxes in splitting it into two source packages, and I had not yet read over it closely enough to realize it was making this change there. Interestingly, it only does this for the hunspell-nl binary package, not for the other binary packages. This ends up working out well for the package splitting plans because the hunspell-nl binary package will end up with its own source package which can be epoch 2, while aspell-nl, wdutch, and idutch will all be build from the other source package, which can remain epoch 1. Based on the comments so far, I am inclined to create a new hunspell-nl source package that produces a single hunspell-nl binary package with an epoch of 2 to match what is currently used. I will retain the old changelog history for this new package. I will also modify the existing dutch source package to only include one upstream source that can be appropriately followed by debian/watch. It will continue to produce the aspell-nl, wdutch, and idutch binary packages, which will remain at epoch 1. Are there any objections to handling it this way? -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
