On 25/09/23 14:29, Wookey wrote:
It's actually quite well-maintained, just not by the maintainer:
someone else has uploaded the last 3 upstream versions via
debian-mentors.
I think this example shows the need for a level of maintainership that
sits between "fully maintained" and "orphaned".
On 2023-09-23 08:35 +0200, Gioele Barabucci wrote:
> On 22/09/23 09:41, Christoph Biedl wrote:
> > I doubt simple rules will really work out, rules like that
> > one I had in mind "Packages are removed from testing once they have been
> > orphaned/last maintainer-uploaded more than five years
Hi,
On 9/25/23 14:08, Paul Wise wrote:
The problem with that approach is that the help needed information
changes independently to packages, so the information will get very out
of date in between point releases, which is why how-can-i-help does
online checks. If desired, it would be easy to
On Mon, 2023-09-25 at 12:08 +0900, Simon Richter wrote:
> What I'd like to see is something like
...
> No installed packages are looking for a new maintainer.
That is what how-can-i-help does, except it doesn't print anything when
there have been no changes to the status of packages on the
On Mon, 2023-09-25 at 12:08 +0900, Simon Richter wrote:
> What I'd like to see is something like
>
> No installed packages are looking for a new maintainer.
That is what how-can-i-help does, except it doesn't print anything when
there have been no changes to the status of packages on the
Hi,
On 9/23/23 12:10, Paul Wise wrote:
You may be thinking of how-can-i-help, which is recommended to every
new person who asks about how to contribute to Debian.
There is also the older wnpp-alert in devscripts.
What I'd like to see is something like
Scanning processes...
Thanks to all of you for your insights and experiences.
So I guess those lpr/lpd packages should stay within Debian and should be
maintained by the debian-printing team.
Thorsten
On 22/09/23 09:41, Christoph Biedl wrote:
I doubt simple rules will really work out, rules like that
one I had in mind "Packages are removed from testing once they have been
orphaned/last maintainer-uploaded more than five years ago".
Maybe something more nuanced may work.
For example:
On Fri, 2023-09-22 at 23:07 +0900, Simon Richter wrote:
> One thing I'd think might help would be a tag in the package database
> that is derived from WNPP status, which would allow the summary output
> at the end of installs also list packages that are installed that are
> currently in RFA or O
On Fri, Sep 22, 2023 at 11:07:39PM +0900, Simon Richter wrote:
> Yes and no. We're providing a better service than pulling the rug under the
> users, but we could do better by communicating that these packages are in
> need of new maintainers instead of waiting for them to bit-rot to a point
>
Hi,
On 9/22/23 16:41, Christoph Biedl wrote:
That's not surprising: lpr is an old technology, it may be simple but it
has quirks. People moved on, and if they cared a little, they let go.
Erm. We're talking about printers here. lpr is the protocol with the
fewest quirks.
I agree that the
Russ Allbery wrote...
> Since I wrote my original message, I noticed that rlpr is orphaned.
If only rlpr were the only one :-|
When looking into the reverse dependencies of lpr/lprng at the beginning
of this thread, I found several orphaned packages, some for already for
more than ten years. To
some old legacy stuff. Is
> there anybody or do you know anybody who is using the old BSD lpr/lpd
> stuff? I don't mean the lp/lpr commands that are provided by cups but
> the old lpd spooler from package lpr.
I was going to say "me by using dosemu", which is not eve
Simon Richter writes:
> And yes, it is quicker for me to copy another printcap entry and swap
> out the host name than it is to find out how to authenticate to CUPS,
> set up the printer, print a test page then remove and recreate it
> because the generated "short" name I need to pipe data into
> "Christoph" == Christoph Biedl writes:
Christoph> "cups-bsd | lpr". For lpr, that might be xpaint. For
Christoph> lprng, I have no idea. And there's little chance to know.
For a long time (possibly still) MIT's printing infrastructure required
lprng and I don't think made it easy
Hi,
On 18.09.23 04:29, Russ Allbery wrote:
It at least used to be that you could print directly to a remote printer
with lpr and a pretty simple /etc/printcap entry that you could write
manually. I used to use that mechanism to print to an office printer
until I discovered rlpr, which is even
Christoph Biedl writes:
> Well, not me. But the thing that puzzles me is the popcon numbers: lpr
> has 755, lprng 233.
> Assuming most of these installation were not done deliberately but are
> rather by-catch, or: Caused by some package that eventually draws them
> in, via a dependency that
Thorsten Alteholz wrote...
> Maybe this is a good opportunity to get rid of some old legacy stuff. Is
> there anybody or do you know anybody who is using the old BSD lpr/lpd
> stuff?
Well, not me. But the thing that puzzles me is the popcon numbers:
lpr has 755, lprng 233.
Assu
Hi everybody,
as you might have heard during the Debconf talk of Till, cups3 and CPDB
(Common Printing Dialog Backends) are waiting at the gates.
Maybe this is a good opportunity to get rid of some old legacy stuff. Is
there anybody or do you know anybody who is using the old BSD lpr/lpd
19 matches
Mail list logo
