Re: dgit view of packages' history
On Wed, 22 May 2024 at 21:55:15 +0200, Paul Gevers wrote: > 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. I believe the 3-commit orig + packaging + merge (vaguely similar to what you would get from `gbp import-dsc` into an empty repository) is what you get if the most recent upload was not made with dgit, and therefore does not have the Dgit field in its `apt-cache showsrc` record. This means that dgit might know what repository the maintainer uses to store their idea of the packaging (it can get this from Vcs-Git), but it does not know which specific commit in that repository is the equivalent of what's in the archive, or which of the various possible workflows the maintainer uses to get from that commit to an uploadable .dsc - and therefore it doesn't have a particularly good way to glue the maintainer's git history into the ancestry of the commit that it generates. If you look at GNOME team packages, packages that were most recently uploaded by me generally do have a Dgit field[1], and packages that were most recently uploaded by another team member often do not. At the time of writing, gtk4/unstable was uploaded with dgit, but gtk4/experimental was not - that might make a useful comparison? I use the dgit-maint-gbp workflow myself, so the dgit history contains a transformation from the format used in our team VCS, which dgit calls the "maintainer view" (in the GNOME team this is gbp-style patches-unapplied) to dgit's canonicalized view (which is patches-applied, because that's what the designers of dgit have chosen to canonicalize into). A nice thing about dgit-maint-gbp is that my co-maintainers don't need to agree with me, and can continue to use gbp + debsign + dput, or quilt + debsign + dput, or construct patches in any other compatible way: as long as we agree on the desired source tree, we can interoperate. smcv [1] except for -security uploads
Re: finally end single-person maintainership
On Thu, 23 May 2024 at 03:01, Simon Richter wrote: > > 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? The main problem is not turnaround (it's terrible ofc), it's that a broken upload to unstable affects _everybody_, while a CI run on Salsa is private and doesn't get in the way of other developers.
Bug#1071670: ITP: libperl-critic-plicease-perl -- Perl module that includes Perl::Critic policies used by Plicease
Package: wnpp Owner: Fernando Yang Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libperl-critic-plicease-perl Version : 0.06 Upstream Author : Graham Ollis * URL : https://metacpan.org/release/Perl-Critic-Plicease * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module that includes Perl::Critic policies used by Plicease The Perl::Critic::Policy::Plicease policies are an eclectic collection of Perl::Critic policies. Some policies are application specific, you should review and include them only on a case by case basis. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
t64 suffix
Dear all, I am trying to find the status of t64 suffix, but I cannot find it neither in my mailbox nor on the page: https://wiki.debian.org/ReleaseGoals/64bit-time#Transition_in_place What is expected from Debian packager now ? 1. Remove the t64 suffix upon next version upload ? 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ? Thanks all -M
Re: finally end single-person maintainership
On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote: > 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. You are wasting a lot of hardware resources we don't have by abusing experimental as a CI. Don't do that. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: t64 suffix
Hi Mathieu (2024.05.23_18:14:20_+) > What is expected from Debian packager now ? > > 1. Remove the t64 suffix upon next version upload ? You can remove it at the next SONAME transition (ABI bump) > 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ? That should only occur on architectures that weren't impacted by the t64 migration. I imagine t64 could be explicitly ignored in lintian (and someone has probably filed a bug about that). Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: finally end single-person maintainership
Am 23.05.2024 20:16 schrieb Bernd Zeimetz :On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote: > 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. You are wasting a lot of hardware resources we don't have by abusing experimental as a CI. Don't do that.I have a string feeling that it is easier for Debian to set up more hardware (I'm thinking of the "how should we spend the money we have" mails) than it is to find more maintainers. Using the resources we have if that saves time on the developer side seems reasonable to me. But IMHO, it would be better to use Salsa CI für that, not experimental.
Re: finally end single-person maintainership
On Thu, 2024-05-23 at 22:00 +0200, Sven Mueller wrote: > > > Am 23.05.2024 20:16 schrieb Bernd Zeimetz : > > On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote: > > > 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. > > > > You are wasting a lot of hardware resources we don't have by > > abusing > > experimental as a CI. Don't do that. > > I have a string feeling that it is easier for Debian to set up more > hardware (I'm thinking of the "how should we spend the money we have" > mails) than it is to find more maintainers. Yes, but I think its a very valid request not to waste buildd time for CIing your packages. And maintaining hardware also needs human resources, its not just done by buying new hardware. -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.de http://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: t64 suffix
On 2024-05-23 18:22 +, Stefano Rivera wrote: > Hi Mathieu (2024.05.23_18:14:20_+) >> What is expected from Debian packager now ? >> >> 1. Remove the t64 suffix upon next version upload ? > > You can remove it at the next SONAME transition (ABI bump) > >> 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ? > > That should only occur on architectures that weren't impacted by the t64 > migration. No, it occurs on all architectures because we changed the package names but not the sonames. > I imagine t64 could be explicitly ignored in lintian (and > someone has probably filed a bug about that). Yes, #1067040[1]. IIUC, the issue should be fixed in lintian git already[2]. Cheers, Sven 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067040 2. https://salsa.debian.org/lintian/lintian/-/commit/07167eebb697d74d84627b275d8aeff4ebf32f7e
Bug#1071708: ITP: emacs-dart-mode -- An Emacs major mode for editing Dart files
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dart-mode Version : 1.0.7+git20240507.ef6cc89 Upstream Author : Google Inc., Brady Trainor * URL or Web page : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ Programming lang: Emacs Lisp Description : An Emacs major mode for editing Dart files This package implements a major-mode for the Dart language, providing basic syntax highlighting and indentation support. I plan to maintain this package within the Debian Emacsen Team .
Bug#1071715: ITP: pytest-httpx -- Intercept and mock HTTPX requests in pytest
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pytest-httpx Version : 0.30.0 Upstream Author : Colin Bounouar * URL : https://github.com/Colin-b/pytest_httpx * License : MIT Programming Lang: Python Description : Intercept and mock HTTPX requests in pytest Provides an `httpx_mock` fixture for the pytest framework. This fixture allows you to intercept and mock HTTP requests made using the HTTPX library. It supports both synchronous and asynchronous HTTPX requests, enabling you to define custom responses, including JSON bodies, headers, status codes, and more. . This library is useful for testing scenarios where making actual network calls is not feasible or desired. You can simulate various HTTP responses and conditions, ensuring your code handles them correctly. Additionally, pytest-httpx supports dynamic responses via callbacks, request verification, and partial mocking, allowing specific requests to go through unmocked. I plan to maintain this package as part of the Python team.
