Re: finally end single-person maintainership
On Wed, May 22, 2024 at 07:18:04AM +0200, Andreas Tille wrote: > IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on > Salsa we could require the NMUer to add at least a MR. those are two things: - mandating salsa (for git) - mandating to have MRs enabled on salsa for that project. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Very hard to relate to those who think the first three years of the pandemic were bad because they couldn’t go to bars for a while, as opposed to because 25 million people died, 400 million were disabled, and many more continue to be unable to access public space. signature.asc Description: PGP signature
broad goals (Re: finally end single-person maintainership)
On Wed, May 22, 2024 at 12:25:49AM +0200, Salvo Tomaselli wrote: > > I would rather see a small but very stable base distribution, with the > > option to add features on top. > Doesn't this conflict with debian being universal? for some it surely does, while for others it's needed to make Debian the universal OS. fun! ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Only change is constant. signature.asc Description: PGP signature
Re: finally end single-person maintainership
On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote: > On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote: > > > > When a change leads to a RC bug a month or three after having be > > part of a package, fixing the problem falls on the maintainer and not > > on the change author. Even correct changes can trigger latent bugs > > in software. > > Yet another reason why using Salsa and its CI *and having autopkg- > tests* is so important - contributors can test their changes before > even asking to merge them. You can run autopkgtests locally, you do not need Salsa for that. > And yes, its up to the 'expert' maintainer > of the package to ensure there are proper tests in place. Because even > that expert is a human only and we all make mistakes. Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in electricity and in carbon emission, that we cannot completely ignore. In any case, it is not realistic to expect tests to detect all kind of bugs, alas. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1071612: ITP: libterm-ansicolor-concise-perl -- Term::ANSIColor - Color screen output using ANSI escape sequences
Package: wnpp Severity: wishlist Owner: Bruno Gabriel da Fonseca X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libterm-ansicolor-concise-perl Version : 2.06 Upstream Contact: Kazumasa Utashiro * URL : https://metacpan.org/pod/Term::ANSIColor::Concise * License : Artistic or GPL-1+ Programming Lang: Perl Description : Term::ANSIColor - Color screen output using ANSI escape sequences This module provides a simple concise format to describe complicated colors and effects for ANSI terminals. These notations are supposed to be used in command line option parameters. This module used to be a part of Getopt::EX::Colormap module, which provide easy handling interface for command line options. The package will be maintained under the umbrella of the Debian Perl Group.
Re: Bug#1071236: general: keyboard, mouse, and trackpad behave inconsistently; seemingly phantom input device events occur unpredictably
On Wed, 2024-05-22 at 00:41 +0200, Salvo Tomaselli wrote: > Hello, > > you can run "reportbug packagename" to report against a specific package. > > You can find out how your kernel package is called with > > dpkg -l "linux-image-*" That step isn't necessary because "reportbug kernel" automagically does the right thing. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: finally end single-person maintainership
On Wed, 22 May 2024 at 12:35, Bill Allombert wrote: > > On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote: > > On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote: > > > > > > When a change leads to a RC bug a month or three after having be > > > part of a package, fixing the problem falls on the maintainer and not > > > on the change author. Even correct changes can trigger latent bugs > > > in software. > > > > Yet another reason why using Salsa and its CI *and having autopkg- > > tests* is so important - contributors can test their changes before > > even asking to merge them. > > You can run autopkgtests locally, you do not need Salsa for that. It can, but it's really a massive pain. git push and go make a cup of tea is so much nicer. Nowadays I run locally only when debugging complex issues, otherwise it's all delegated to Salsa. > > And yes, its up to the 'expert' maintainer > > of the package to ensure there are proper tests in place. Because even > > that expert is a human only and we all make mistakes. > > Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in > electricity > and in carbon emission, that we cannot completely ignore. > > In any case, it is not realistic to expect tests to detect all kind of bugs, > alas. The cost of running those same builds and tests locally is pushed onto the developer though, and their electricity bill. By using Salsa, the cost is pushed to the project and our sponsors - which seems the right thing to me.
Re: finally end single-person maintainership
Hi, On 5/22/24 20:34, Bill Allombert wrote: You can run autopkgtests locally, you do not need Salsa for that. Also, Debian runs autopkgtests on all packages that provide them, and makes passing them on all supported architectures a requirement for testing migration. It could be argued that testing migration is a CI process. Simon
Requesting for setting up loong64 buildds (Server machines) for Official port
Hi, I am continuously porting loong64 to the Debian community. It's my pleasure to communicate and solve problems with DSA team. When I requested that the loong64 port could be included amongst the Official ports, I got from debian IRC that maybe I need to set up servers machines(buildds) for Official. I learned that the Debian System Administration (DSA) team is responsible for Debian's infrastructure. I would like to send Server machines to Debian Official. Could you tell me how to do? - About Server machines The LoongArch machines are used in Personal Computer, Servers and so on. We can provide stable Server machines, please see https://www.loongson.cn/application/list?id=3. - About loong64 buildds in Unofficial port We have deployed 6 machines and currently have 6 loong64 buildds. Please see https://buildd.debian.org/status/architecture.php?a=loong64&suite=sid. - About Debian debci I am preparing debci machines for debci team. Please see https://lists.debian.org/debian-ci/2024/05/msg00012.html. - About ArchiveQualification page I have created a ArchiveQualification page for loong64. I will update continuously. Please see https://wiki.debian.org/ArchiveQualification/loong64. - About architecture requalification status for trixie I have adding the loong64 port to arch_qualify page. Please see https://release.debian.org/testing/arch_qualify.html. For loong64, the status of porterbox, buildd-dsa and autopkgtest in the arch_qualify page is "NO". About porterbox and buildd-dsa, I hope that I could get guidance or suggestions from Debian DSA team. I am doing this in good faith. Any resources and machines, I am willing to do. If you have any questions about the loong64 port you can contact me at any time? If I've handled any of the processes wrong, please don't feel troubled and please correct me. Thanks, Dandan Zhang
Re: Documenting packaging workflows (was: finally end single-person maintainership)
Salvo Tomaselli writes: > I'm also annoyed at the default ci configuration for salsa, because importing > a > project makes a CI start to run, then fail. Then I have to one by one point > the CI file to something else, but the project will forever be "CI failing" > and > will be reported forever as such in my status page. If you go to the individual pipeline that you never wanted to run (e.g. click on the red 'X' in the overview, or the pipelines view), then you'll see a 'Delete' button in the top-right corner. If you delete all the pipelines in a repo, it reverts to thinking CI is not setup, and you'll no longer be told that the repo is 'CI failing'. BTW I just confirmed that by setting up a new repo for the purpose, and was surprised to find that I also needed to configure CI in order to get it to fail, so I think you may be right that it was once doing the annoying thing you describe, but it didn't do it to me just now. HTH Cheers, Phil. -- Philip Hands -- https://hands.com/~phil signature.asc Description: PGP signature
Bug#1071617: ITP: cached-ipaddress -- Cache construction of IP address objects
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: cached-ipaddress Version : 0.3.0 Upstream Author : J. Nick Koston * URL : https://github.com/bdraco/cached-ipaddress * License : MIT Programming Lang: Python Description : Cache construction of IP address objects Provides a caching mechanism for Python IP address objects. This module caches the construction of IP address objects and their properties, making it efficient when dealing with frequently encountered IP addresses. . The cache is useful for reducing the overhead associated with creating and accessing properties of IP address objects repeatedly. I plan to maintain this package as part of the Python team.
Bug#1071635: ITP: aioruuvigateway -- asyncio-native library for Ruuvi Gateway data requests
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: aioruuvigateway Version : 0.1.0 Upstream Author : Aarni Koskela * URL : https://github.com/akx/aioruuvigateway#readme * License : MIT Programming Lang: Python Description : asyncio-native library for Ruuvi Gateway data requests An asyncio-native library designed to request data from a Ruuvi Gateway. It supports bearer token authentication and allows for efficient data retrieval and parsing. . The Ruuvi Gateway is a device that allows you to remotely access your Ruuvi sensors from anywhere in the world. . This library offers both an API and a command-line interface for accessing and displaying data from the Ruuvi Gateway. . Example usage: . from aioruuvigateway.api import get_gateway_history_data async with httpx.AsyncClient() as client: history = await get_gateway_history_data( client=client, host="192.168.1.249", bearer_token="your_token_here", ) print(history) Command-line interface example: . python -m aioruuvigateway --host 192.168.1.249 --token bearbear --parse --json . This will output data from the gateway in JSON format, printing changed information every 10 seconds. I plan to maintain this package as part of the Python team.
Re: finally end single-person maintainership
On Wed, 2024-05-22 at 21:26 +0900, Simon Richter wrote: > Hi, > > On 5/22/24 20:34, Bill Allombert wrote: > > > You can run autopkgtests locally, you do not need Salsa for that. > > Also, Debian runs autopkgtests on all packages that provide them, and > makes passing them on all supported architectures a requirement for > testing migration. Uploading to check autopkgtests is an absolute waste of ressources. I really hope nobody uploads a package without running the tests somewhere else. > > It could be argued that testing migration is a CI process. > Its a CI process at a way too late stage. Also, uploading to test a merge request is not the right thing to do. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: finally end single-person maintainership
On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote: > > > You can run autopkgtests locally, you do not need Salsa for that. > > > > Also, Debian runs autopkgtests on all packages that provide them, and > > makes passing them on all supported architectures a requirement for > > testing migration. > > Uploading to check autopkgtests is an absolute waste of ressources. I > really hope nobody uploads a package without running the tests > somewhere else. > > > > > It could be argued that testing migration is a CI process. > > > > Its a CI process at a way too late stage. > Also, uploading to test a merge request is not the right thing to do. If the archive is a VCS then uploading an untested package to experimental to run tools is pushing a commit to run CI. *shrug* -- WBR, wRAR signature.asc Description: PGP signature
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)
Hi On 21-05-2024 1:08 p.m., Sean Whitton wrote: PS: I've always wondered if the dgit server shouldn't track history, even if uploads don't happen via it. A dgit clone could (should?) already provide available history, even if no upload happened via it yet. Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's history. So it sort of does this. We could make it do more. Huh. Than my workflow hides this. All I'm often seeing is just the tar content represented in a commit, the latest Debian packing in another and the merge of these two (if I recall and describe what I recall correctly). I always thought that dgit clone generated that on my computer if there was no git content on the dgit server. I'll try to remember this next time I run my no-changes-source-only upload script. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: finally end single-person maintainership
Hi, On 5/23/24 04:32, Andrey Rakhmatullin wrote: It could be argued that testing migration is a CI process. >> Its a CI process at a way too late stage. Also, uploading to test a merge request is not the right thing to do. If the archive is a VCS then uploading an untested package to experimental to run tools is pushing a commit to run CI. *shrug* Yes, but unironically: experimental is a side branch, unstable is a MR, and testing is the main branch. It is entirely valid to be dissatisfied with the turnaround time of the existing CI, but what we're seeing here is the creation of a parallel structure with as-of-yet unclear scope. Can we define the scope as "quick-turnaround unofficial validation", because that's the niche that is currently underserved? Simon
