Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-io-idl-perl
Version : 2.098
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-IO-IDL
* License
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-transform-color-perl
Version : 1.007
Upstream Author : Craig DeForest
* URL : https://metacpan.org/release/PDL-Transform-Color
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-transform-proj4-perl
Version : 2.098
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-Transform-Pr
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-io-gd-perl
Version : 2.103
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-IO-GD
* License
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-perldl2-perl
Version : 2.002
Upstream Author : Chris Marshall
* URL : https://metacpan.org/release/PDL-Perldl2
* License
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-gsl-perl
Version : 2.101
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-GSL
* License :
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-io-envi-perl
Version : 2.098
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-IO-ENVI
* License
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-io-dicom-perl
Version : 2.098
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-IO-Dicom
* License
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-graphics-simple-perl
Version : 1.015
Upstream Author : Craig DeForest
* URL : https://metacpan.org/release/PDL-Graphics-Simple
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-graphics-colorspace-perl
Version : 0.204
Upstream Author : Maggie J. Xiong
* URL : https://metacpan.org/release/PDL-Graphics-
Hi,
On 1/16/25 13:22, Russ Allbery wrote:
There are various things one can do to try to make the output of a man
page generator like that more consistent, but they don't fix the problem,
just reduce its frequency, unless Debian sets up to do a fully
reproducible build with pinned versions of ev
Package: wnpp
Owner: Ed J
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org
* Package name: libpdl-fit-perl
Version : 2.099
Upstream Author : PerlDL Developers
* URL : https://metacpan.org/release/PDL-Fit
* License :
Simon Richter writes:
> On 1/16/25 01:43, Sam Hartman wrote:
>> For a while we just built the man pages but if any of the docbook tools
>> changed between one arch build and another, we'd end up with m-a
>> uninstallable packages.
> Can this be fixed by removing the "Generator:" comment in the g
Hi,
On 1/16/25 01:43, Sam Hartman wrote:
For a while we just built the man pages but if any of the docbook tools
changed between one arch build and another, we'd end up with m-a
uninstallable packages.
Can this be fixed by removing the "Generator:" comment in the generated
manpage, and possi
"G. Branden Robinson" writes:
> 1. podlators/Pod::Man -- a proud exception to some of the
> generalizations above. First, it's been around probably longer than
> any of these others, maybe by a margin of decades. Second, it was
> initially developed by people who seemed to have a g
Hi Jonathan,
At 2025-01-15T22:01:28+, Jonathan Dowland wrote:
> On Wed Jan 15, 2025 at 9:42 PM GMT, G. Branden Robinson wrote:
> > As someone who has a bit of a preoccupation with man pages
>
> You've reminded me that you presented 'Write the Fine Manual' in 2005,
> (possibly at DebConf?).
I
On Wed Jan 15, 2025 at 9:42 PM GMT, G. Branden Robinson wrote:
As someone who has a bit of a preoccupation with man pages
You've reminded me that you presented 'Write the Fine Manual' in 2005,
(possibly at DebConf?). I thought it was a really good slide-deck, but
it's either unavailable or at
At 2025-01-15T14:09:03-0700, Sam Hartman wrote:
> > "G" == G Branden Robinson writes:
> G> Don't we have dpkg filters for this sort of use case?
>
> I honestly can't tell from your message which position you are
> supporting, which I do find somewhat frustrating when I'm trying to
> get f
Sam Hartman writes:
> My proposal is to move the man pages into libpam-doc. I'm not actually
> convinced that normal Debian users need man pages for all the pam
> modules on all Debian systems, and a suggests relationship should be
> sufficient. If people really want to maintain the current level
> "G" == G Branden Robinson writes:
G> At 2025-01-15T12:45:22-0700, Sam Hartman wrote:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather have the man pages installed without the addi
On Wed, 15 Jan 2025, Johannes Schauer Marin Rodrigues wrote:
>Quoting Thorsten Glaser (2025-01-15 00:50:55)
>> There should be something in this that says that they need to do so
>> in a way that matches ftpmaster policies.
>
>Do we really need to explicitly codify "please work well together with
At 2025-01-15T12:45:22-0700, Sam Hartman wrote:
> Marvin> I have on a number of occasions used these man pages, and
> Marvin> having them installed locally is very helpful. I would
> Marvin> rather have the man pages installed without the additional
> Marvin> documentation in libpa
At 2025-01-15T20:25:04+0100, Thorsten Glaser wrote:
> On Wed, 15 Jan 2025, Johannes Schauer Marin Rodrigues wrote:
> >Quoting Thorsten Glaser (2025-01-15 00:50:55)
> >> There should be something in this that says that they need to do so
> >> in a way that matches ftpmaster policies.
> >
> >Do we re
> "Marvin" == Marvin Renich writes:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather have the man pages installed without the additional
Marvin> documentation in libpam-doc. Why n
* Sam Hartman [250115 11:44]:
>
> TL;DR: I propose move man pages out of a multi-arch: same package into a
> arch all package. Asking for any downsides and usrmerge review.
>
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pa
On 15/01/25 15:19, Andreas Tille wrote:
I'm not sure that these packages are on BTS only because the associated
packages have no Git/salsa repo. The BTS is our prefered form of
reporting issues. Adding an MR and linking to it as a patch as you did
in [1] is perfect and as a maintainer (who has
On 15/01/25 17:43, Sam Hartman wrote:
My proposal is to move the man pages into libpam-doc.
I'm not actually convinced that normal Debian users need man pages for
all the pam modules on all Debian systems, and a suggests relationship
should be sufficient.
Unrelated to the question at hand, but
TL;DR: I propose move man pages out of a multi-arch: same package into a
arch all package. Asking for any downsides and usrmerge review.
I'm in the process of packaging pam 1.7.0. Upstream has moved from
autotools to meson and in the process has streamlined their release
tarballs to remove all or
On Wed Jan 15, 2025 at 12:37 AM GMT, Kunal Mehta wrote:
Agreed 100%, the openness for editing is really what makes wikis
shine. It can be hard to accept, with many of us firmly set in Git's
pre-approval style PR/MR workflows, to allow anyone with an account,
to just change anything, but that em
Hi Gioele,
Am Wed, Jan 15, 2025 at 08:55:51AM +0100 schrieb Gioele Barabucci:
> On 14/01/25 23:14, Otto Kekäläinen wrote:
> > Numerous people are posting Merge Requests on Salsa. Please help review
> > them!
>
> Could we do the same for BTS patches?
>
> There are ~5000 patches that have been si
On Wed, Jan 08, 2025 at 03:21:43PM +0100, Helmut Grohne wrote:
codesearching DEP17.*M18 (and a few other patterns) suggest the
> following packages needing an update:
> * bfh-metapackages
Open #1092955. I first got it wrong and then sent another update.
> * clonezilla
Open #1093135. Though th
Hello,
All delegates have to co-ordinate with each other. There’s no special need for
this delegation to make reference to others, as josch says.
--
Sean Whitton
Please excuse top-posting and brevity. I am writing to you from a mobile phone.
> On 15 Jan 2025, at 07:47, Andreas Tille wrote:
>
Hi Mo,
before going into criticizing things, I would like to thank you for your
continued work in the AI space. In particular, your way of classifying
models into different degrees of freedom demonstrates how much you care
about Debian's values. I see that your focus is on enabling users and
that'
On Wed, Jan 08, 2025 at 03:21:42PM +0100, Helmut Grohne wrote:
> Since I was failing to get this right earlier, I figured I could as well
> write some tests. As a result, I'm attaching a shell script. It
> constructs a few demo packages and attempts a hopefully exhaustive
> combination of using the
Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode
X-Debbugs-Cc: debian-devel@lists.debian.org,debian-r...@lists.debian.org
* Package name: rust-cargo-vendor-filterer
Version : 0.5.16
Upstream Contact: GitHub issue tracker lol
* URL : https://github.com/coreos
Quoting Chris Hofstaedtler (2025-01-15 11:44:19)
> * Jonas Smedegaard [250115 11:40]:
> > Quoting Andrej Shadura (2025-01-15 11:24:31)
> > > Hello,
> > >
> > > On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
> > > >> >> >Then let's move to the tinker team mailinglist:
> > > >> >> >https://
* Jonas Smedegaard [250115 11:40]:
> Quoting Andrej Shadura (2025-01-15 11:24:31)
> > Hello,
> >
> > On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
> > >> >> >Then let's move to the tinker team mailinglist:
> > >> >> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-d
Quoting Andrej Shadura (2025-01-15 11:24:31)
> Hello,
>
> On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
> >> >> >Then let's move to the tinker team mailinglist:
> >> >> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
>
> > No, but that my proposal for discuss
Hello,
On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
>> >> >Then let's move to the tinker team mailinglist:
>> >> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
> No, but that my proposal for discussion place was so out of this earth
> that you felt the need
Quoting Thorsten Glaser (2025-01-15 00:50:55)
> There should be something in this that says that they need to do so in a way
> that matches ftpmaster policies.
Do we really need to explicitly codify "please work well together with your
fellow DDs" in the task description of delegates?
I think tha
Hi,
Am Wed, Jan 15, 2025 at 09:01:33AM +0100 schrieb Gioele Barabucci:
> Indeed, archiving the project [1], as suggested by Chris, seems a more
> sensible course of action. Everything remains available, but users are given
> a clear indication of the status of the repository.
>
> [1]
> https://d
On 14/01/25 23:14, Otto Kekäläinen wrote:
Numerous people are posting Merge Requests on Salsa. Please help review them!
Could we do the same for BTS patches?
There are ~5000 patches that have been sitting in the BTS for years,
some trivial (examples from my own: [1,2]), others less so. Most o
On 15/01/25 08:43, Andreas Tille wrote:
However, I would support the idea of bulk closing MRs and complete
repositories *if* the package has been removed from Debian for the
same reason we bulk close their bug reports.
I tend to keep the repository for several reasons:
* Users might like to
43 matches
Mail list logo
