Re: speech question.
Mike Coulombe, le sam. 16 nov. 2024 17:34:36 -0800, a ecrit: > It's an intel pch card if that can help you guys. We need more details, such as lspci, kernel logs about possibly loading a kernel, etc. Samuel
Bug#1087685: ITP: golang-github-smallstep-crypto -- Crypto is a collection of packages used by Smallstep products
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-smallstep-crypto Version : 0.54.2-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/crypto * License : Apache-2.0 Programming Lang: Go Description : Crypto is a collection of packages used by Smallstep products Crypto is a collection of packages used in smallstep (https://smallstep.com) products. See: . * step (https://github.com/smallstep/cli): A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, etc. * step-ca (https://github.com/smallstep/certificates): A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-smallstep-crypto /Simon signature.asc Description: PGP signature
Re: Is there a point to retaining src:pth?
On Sun, Nov 17, 2024 at 11:21:00AM +0100, Ben Hutchings wrote:
> On Sun, 2024-11-17 at 03:22 +0100, наб wrote:
> > src:pth has been gone from testing since August.
> > There are no rdeps and no rbuilddeps,
> > and only FTBFS bugs since like 2012.
> > I can hardly imagine a point to Pth at all in 2024
> > (or any time after ubiquitous pthread support),
> > so it reads to me like an easy QA removal.
> >
> > But, this seems incongruent with the
> > inst~15000 + vote~15 popcon
> > (admittedly, with a peak of 50k, that may just be latent).
> I'm not seeing those numbers. Maybe because pth had an ABI bump for
> time64 and libpth20 is no longer on the graph.
Had to dig these out of the graph manually:
https://qa.debian.org/popcon-graph.php?packages=libpth20t64+libpth20+libpth-dev&show_vote=on&show_old=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
https://qa.debian.org/popcon-graph.php?packages=libpth20t64+libpth20+libpth-dev&show_vote=on&show_old=on&want_legend=on&want_ticks=on&from_date=2020-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> > What am I missing here? Is there any reason for any one
> > to install libpth{20,-dev} at any time any more?
> GnuPG once used pth, but switched to npth over a decade ago.
That historical context was what I was missing,
and certainly matches the peak and cliff.
> As recently as bullseye, pth still had some significant
> reverse-(build-)dependencies:
This looked like a scary prospect,
> $ grep-dctrl -FBuild-Depends -sPackage libpth-dev
> /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_source_Sources
> Package: gcc-9
> Package: libdap
> Package: pianobar
> Package: unicon
> Package: zhcon
> $ grep-dctrl -FDepends -sPackage libpth20
> /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
>
> Package: libgm2-0
> Package: genometools-common
> Package: libpth-dev
> Package: zhcon
but from the changelogs and relevant bugs,
it looks like all of these specced that by accident as a left-over.
So it was deeply vestigial even in bullseye,
and the maintainer trimmed it off most of the way.
> but it does seem like it can be dropped now.
https://bugs.debian.org/1087708
Thanks,
signature.asc
Description: PGP signature
DEP-18 v2: request for comments
Hi all, I published a complete rewrite of the earlier draft as: https://salsa.debian.org/dep-team/deps/-/merge_requests/12 DEP-18: Encourage Continuous Integration and Merge Request based Collaboration for Debian packages If you are in favor of having this as a DRAFT in the DEP directory, please give it a thumbs up. Summary of previous discussion below, but an even better summary was written by LWN in https://lwn.net/Articles/986480/ Related to Salsa in general, I heard we have now new and faster hardware (thanks Salsa Admins!), and related to Salsa CI there is also an overhauled README (https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md) and lots of fixes by 7 different authors. I think a lot of people have also practiced more code reviews and tested the Merge Request feature on Salsa than before. Overall, I think we are on a good path to evolving this way of working, and hopefully doing it in a way that it does not stifle work for maintainers who prefer to continue their single-maintainer habits, so nobody feels at loss. On Tue, 27 Aug 2024 at 19:13, Otto Kekäläinen wrote: > > Hi! > > While I intend to continue on iterating DEP-18, here is a summary to > those who did not wade through the 140+ messages on the topic. > Unfortunately, the summary itself is also a bit long :) > > > > Summary of mailing list discussion in > https://lists.debian.org/debian-devel/2024/07/msg00429.html > > ## Overall Sentiment > > There was a broad consensus that Debian workflows are too fractured > and would benefit from more standardization and unification. However, > there were differing opinions on the right approach to achieve this. > > Soren Stoutner expressed this sentiment clearly: > > > 1. Debian workflows are too fractured. The project would be better if we > > asked people to standardize around a single (or a small number) of > > workflows. To do so, the workflow would need to be flexible enough to > > handle the wide range of technical needs of all the packages and upstream > > configurations. > > 2. Standardizing around a single (or small number of) workflows wil make > > some people unhappy. But that is an acceptable price to pay because of the > > general benefit to the project as long as the correct solution is adopted. > > Unity is more important than minority opinions on this particular issue. > > Similarly, Andrey Rakhmatullin argued that while some may resign, "the > '1000 DDs status quo' problem also means that more people leave than > join _anyway_. Not the unity per se, but having significantly lower > barriers to start contributing" is important. > > ## Git and Gitlab Usage > > Multiple participants noted that most other Linux distributions use > Git as the primary version control system, often with GitLab or GitHub > for collaboration. Debian's multi-branch approach with pristine-tar > was seen as somewhat unique. > > There were differing views on whether Debian should move closer to the > more common Git-based workflows used elsewhere, or maintain its own > custom approach, which of git-buildpackage and dgit are the most > common ones (both with multiple ways to use them). > > ## Mandatory vs Optional Policies > > Some participants, like Salvo Tomaselli, felt DEP-18 was too > prescriptive in mandating specific tools and workflows, and that a > more flexible, optional approach would be better: > > > Keep in mind that unhappy people quit. I don't think that unity is so > > important that we're willing to sacrifice project members. > > Others, including Soren Stoutner, argued that standardization was > important, even if it made some people initially unhappy, as long as > the right solution was adopted: "Unity is more important than minority > opinions on this particular issue." > > ## Maintainer Workflows > > There were concerns that requiring specific Git and Gitlab practices > could create burdens for existing maintainers, especially > single-person maintainers. Sean Whitton described his own preferences > as a maintainer: > > > I am happy to use salsa for git hosting and access management. I love that > > I can easily grant push access to my non-DD team members. But, I turn off > > salsa MRs for the repos of all packages I regularly upload. I would hope > > that this DEP can be written such as to account for these sorts of choices. > > Fabio Fantoni suggested allowing maintainers to specify their preferred > > collaboration methods in a machine-readable way, for example through a > > "Collaboration-Policy" field in debian/control. > > ## Performance and Reliability > > Multiple participants, including Salvo Tomaselli, Johannes Schauer > Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained > about Salsa/GitLab being slow or unreliable at times, which deterred > contribution. Improvements to performance and uptime were seen as > important. In response, Ott
Re: DEP-0, DEP0 or DEP 0?
Thanks for the comments! Let's implement this. Please vote on which variant you prefer by giving a thumbs up at https://salsa.debian.org/dep-team/deps/-/merge_requests/13 Unify DEP spelling with a dash instead of a space (e.g. "DEP-0") OR https://salsa.debian.org/dep-team/deps/-/merge_requests/14 Unify DEP spelling with a space instead of dash (e.g. "DEP 0") I apologize that this requires JavaScript to those who are concerned. I don't know how to +1 in the GitLab API from the command line, so I can't offer that as an option now, but I can provide direct links to raw diff so you can at least read these without having to run JavaScript: https://salsa.debian.org/dep-team/deps/-/merge_requests/13.patch https://salsa.debian.org/dep-team/deps/-/merge_requests/14.patch
Bug#1087753: ITP: golang-github-notaryproject-tspclient-go -- Golang implementation of the Time-Stamp Protocol (TSP) client as specified in RFC3161
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-notaryproject-tspclient-go Version : 0.2.0-1 Upstream Author : Notary Project * URL : https://github.com/notaryproject/tspclient-go * License : Apache-2.0 Programming Lang: Go Description : Golang implementation of the Time-Stamp Protocol (TSP) client as specified in RFC3161 This package provides implementation of the Time-Stamp Protocol (TSP) client as specified in RFC 3161.
Re: DEP-0, DEP0 or DEP 0?
* Otto Kekäläinen: " Re: DEP-0, DEP0 or DEP 0?" (Sun, 17 Nov 2024 15:23:50 -0800): Hi Otto, > Let's implement this. Please vote on which variant you prefer by > giving a thumbs up at > > https://salsa.debian.org/dep-team/deps/-/merge_requests/13 > Unify DEP spelling with a dash instead of a space (e.g. "DEP-0") > > OR > > https://salsa.debian.org/dep-team/deps/-/merge_requests/14 > Unify DEP spelling with a space instead of dash (e.g. "DEP 0") > > > I apologize that this requires JavaScript to those who are concerned. > I don't know how to +1 in the GitLab API from the command line, so I > can't offer that as an option now, but I can provide direct links to > raw diff so you can at least read these without having to run > JavaScript: > https://salsa.debian.org/dep-team/deps/-/merge_requests/13.patch > https://salsa.debian.org/dep-team/deps/-/merge_requests/14.patch I know that you are working a lot on Salsa CI and that you like and promote the platform. Not all in the project are at ease with gitlab. So please avoid to change communication channels and put pressure on people to use that platform for voting purposes that have a meaning to the project. Thanks! I vote for DEP-0. Cheers, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Is there a point to retaining src:pth?
On Sun, 2024-11-17 at 03:22 +0100, наб wrote:
> Hi!
>
> src:pth has been gone from testing since August.
> There are no rdeps and no rbuilddeps,
> and only FTBFS bugs since like 2012.
> I can hardly imagine a point to Pth at all in 2024
> (or any time after ubiquitous pthread support),
> so it reads to me like an easy QA removal.
>
> But, this seems incongruent with the
> inst~15000 + vote~15 popcon
> (admittedly, with a peak of 50k, that may just be latent).
I'm not seeing those numbers. Maybe because pth had an ABI bump for
time64 and libpth20 is no longer on the graph.
> What am I missing here? Is there any reason for any one
> to install libpth{20,-dev} at any time any more?
GnuPG once used pth, but switched to npth over a decade ago. As
recently as bullseye, pth still had some significant reverse-
(build-)dependencies:
$ grep-dctrl -FBuild-Depends -sPackage libpth-dev
/var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_source_Sources
Package: gcc-9
Package: libdap
Package: pianobar
Package: unicon
Package: zhcon
$ grep-dctrl -FDepends -sPackage libpth20
/var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
Package: libgm2-0
Package: genometools-common
Package: libpth-dev
Package: zhcon
but it does seem like it can be dropped now.
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
signature.asc
Description: This is a digitally signed message part
