Re: Abandonware in testing (Re: lpr/lpd)

[Gioele Barabucci]

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". (Or a rethinking of the 
concept of "orphan packages".)


Right now in Debian there is a distinction between:

1) maintained packages (Maintainer: "foo")

and

2) orphaned packages (Maintainer: "Debian QA Group").

State 1 is the desired state of a package: somebody (a single person or 
a team) looks after this package, packages and tests new releases, and 
is expected to respond to inquiries (bug reports, MRs, NMUs) within a 
reasonable time.


State 2 is an undesired state that should be addressed. Somebody from 
the QA team (= theoretically the whole of Debian) may have a look at it 
in case of transitions or RC bugs. But what Debian really desires is 
that somebody will adopt this package and put their name in the 
Maintainer: field.


What I think is needed is a state 3 (or 1.5) that formalizes what Wookey 
described: there is an informal group of people that may take care of a 
package, but they don't feel like having their names attached to it nor 
want the responsibility of being the ones in charge for timely fixes or 
quick replies.


The way I picture it, "state 3" packages would have something like 
"Debian Caretaking Team" in the Maintainer: field (not the usual "QA 
Group", and have autotests in lieu of a specific person/team that takes 
care of manually testing the package.


Has such a third category already been discussed or explored?

--
Gioele Barabucci

Re: Abandonware in testing (Re: lpr/lpd)

[Wookey]

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 ago".
> 
> Maybe something more nuanced may work.
> 
> For example: packages are removed from testing if:
> 
> - have been orphaned/last maintainer-uploaded more than 2 releases ago,
> - have no autopkgtests OR autopkgtests fail OR are not
> lintian/piuparts-clean.

I don't think that 'maintainer-uploaded' rules is a good one for capturing 'is 
looked after' whichis what I think you intended. 

For example, the very useful package ncdu (which I just sponsored an
NMU upload of - 1.19 is currently in DELAYED) would fail this test.
https://tracker.debian.org/pkg/ncdu

It's actually quite well-maintained, just not by the maintainer:
someone else has uploaded the last 3 upstream versions via
debian-mentors. Upstream even took debian patches in the last release
so there are now no patches, which is about as good as things get for
mature software.

Only-NMU uploads for some years is quite a common pattern and whilst
sometimes it indicates the package is only getting emergency
drive-by maintainance, sometimes (like here) the thing is actually being
maintained just as it should be (just by someone who is not officially
the maintainer).

In this case looking for NMUs of new upstream versions would give the
clue that this is not just life-support. I don't know if that is a
sufficient rule?  Repeated NMUs by one person is also a clue. As you
say something 'more nuanced' still is needed and a useful test may
actually be quite complicated.

To get back to the wider issue: In general I like the fact that Debian
doesn't remove packages so long as they still work (so fas as we
know). It's one thing that gives users stability. (I'm still grumpy
about ipmasq being removed circa 2011, and I still use a local build
of 'bins' which was removed in 2015).

But we do end up carrying a lot of old stuff, possibly some of
which is genuinely superceded/no longer used.

And as a user I _would_ like better mechanisms to explain when
$something has been replaced by $something-else and users are expected
to move over at some point. Sometimes on upqrade a package has just
gone and it's not something you know anything about so you have no
idea if there is a replacement of some sort or what it might be
called. apt-listchanges can fill this gap, but only if you install it
(and it's kind of annoying because it interrupts the install/upgrade
process). And this only works for well-maintained packages that
actually update Debian.NEWS, not barely-maintained/unmaintained
packages. I guess you might get the info from the replacing, as
opposed to replaced package, but as with printing it's often a whole
set of stuff and it's not clear where any 'moving on' info should live. 

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

how-can-i-help by default [Re: lpr/lpd]

[Simon Richter]

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 have an apt update hook
that would download the data from UDD so that how-can-i-help can work
offline when the network is available.


Yes, that's why I thought of using indices/ -- there are already 
Maintainers and Uploaders files in there that I'd expect are also meant 
to change independently from Packages. The indices/ directory seems to 
be available on most if not all mirrors as well, so putting it there 
would not put unnecessary strain on UDD.


My proposal is to display the list of RFA/O packages installed on the 
system by default as part of the after-installation summary, because we 
currently have no way of reaching users of at-risk packages before the 
package is removed, and I would like to change that.


   Simon

Re: lpr/lpd

[Paul Wise]

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 system, nor
when there are no packages installed that are known to need helpers.

> And ideally, that check would be quick and use information already on
> the system at this point, maybe a supplemental file under indices/ that 
> can be downloaded during an update.

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 have an apt update hook
that would download the data from UDD so that how-can-i-help can work
offline when the network is available.

The main problem with how-can-i-help currently is that the maintainer
is not currently active in Debian and no-one else is working on it.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lpr/lpd

[Paul Wise]

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 system, nor
when there are no packages installed that are known to need work.

> And ideally, that check would be quick and use information already on
> the system at this point, maybe a supplemental file under indices/ that 
> can be downloaded during an update.

Currently how-can-i-help does online checks, but it should be possible
to have it add an apt hook to download the necessary files from UDD.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lpr/lpd

[Simon Richter]

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... 

Scanning processor microcode... 

Scanning linux images... 



Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on 
this host.


No installed packages are looking for a new maintainer.

And ideally, that check would be quick and use information already on 
the system at this point, maybe a supplemental file under indices/ that 
can be downloaded during an update.


   Simon

Re: lpr/lpd

[Thorsten Alteholz]

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

Abandonware in testing (Re: lpr/lpd)

[Gioele Barabucci]

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: packages are removed from testing if:

- have been orphaned/last maintainer-uploaded more than 2 releases ago,
- have no autopkgtests OR autopkgtests fail OR are not 
lintian/piuparts-clean.


Regards,

--
Gioele Barabucci

Re: lpr/lpd

[Paul Wise]

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 state.
> 
> I believe we used to have a tool for that in Debian, but almost no one 
> had it installed because it had additional overhead, making it pointless.

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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: lpr/lpd

[Theodore Ts'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
> where we have an excuse to remove them -- because all we're doing that way
> is justify the rug pull, but the impact for the users isn't minimized.

There are two things that we can call for, and we probably should try
to do both.  The first is making sure that we have an active *Debian*
maintainer.  The other is to see if we can find an *Upstream*
maintainer.  And for that, we can take a look at a wider set of
potential maintainers.  For example, in the case of rlpr, it also is
packaged by FreeBSD and NetBSD.  So perhaps there are some joint
upstream collaboration that could be done with folks from different
distibutions, or even different OS's.

Just a thought,

- Ted

Re: lpr/lpd

[Simon Richter]

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 desktop users have moved on, and they will move on to 
whatever we present them as default next.


But I also think there are quite a few installations that still use 
these packages, and where people don't have much of an issue with the 
packages being effectively NMU-maintained, because their system works, 
and change only brings uncertainty -- especially if it is change towards 
something that is "actively" maintained and constantly updated.


My suspicion is that a lot of these installations will have a heavy 
amount of homebrew scripting added to them, so supporting them from a 
newer printing system would mean creating a bug-compatible emulation, 
which we can all agree is a forever maintenance burden unless you also 
have a plan to migrate these users to a legacy-free environment.



 Do we provide our users a good service if we keep such zombies alive
 for such a long time?


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 where we have an excuse to remove them -- because all we're 
doing that way is justify the rug pull, but the impact for the users 
isn't minimized.



Plus, most of that code is in C, and I take the liberty to state they
all have security issues. They are just unknown, because no one bothered
to take a closer look. But these bugs exist simply because twenty and
more years ago, secure programming wasn't that common.


It is simple, straightforward code with a service record of over twenty 
years, and I remember that we had security researchers back then and 
there were several advisories on bugtraq for lprng.



Without an external limitation (mostly specific hardware) it's hard to
draw a line when it's obviously the time to remove near-dead packages,
at least from the stable releases. I don't have a good idea either what
to do here.


Same. I think that it cannot be solved on a per-package basis, instead 
we might need infrastructure.


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 state.


I believe we used to have a tool for that in Debian, but almost no one 
had it installed because it had additional overhead, making it pointless.


   Simon

Re: lpr/lpd

[Christoph Biedl]

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 name a few:

* lprng
* apsfilter(D)
* e2ps(R)
* ifhp(R)
* magicfilter(R)
* tk-brief(R)
* trueprint(R)
* xhtml2ps(S)

Plus those NMU-only-maintained packages where the maintainer is probably
MIA.

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.

(...)

> If anyone else who still prints
> regularly prefers the simple command-line interface, you may want to
> consider adopting it, although it looks like you're likely to have to
> adopt upstream as well since it seems to have disappeared.

Dead upstream applies as well to most of the packages listed above. And
that brings me to another, bigger question:

Do we provide our users a good service if we keep such zombies alive
for such a long time?

What I'm trying to say: All the maintenance that happens to such
packages is on an emergency base. If some changes (policy, debhelper,
stricter gcc checks, etc.) trigger RC bugs, someone might do the
necessary adjustments, also because it's often a low-hanging fruit. But
regular care does not happen, and after a few years it shows.

Plus, most of that code is in C, and I take the liberty to state they
all have security issues. They are just unknown, because no one bothered
to take a closer look. But these bugs exist simply because twenty and
more years ago, secure programming wasn't that common.


When kicking isdnutils out of Debian (since Linux kernel hat dropped the
support) I coined the phrase that Debian is not a museum. The lpr/lprng
area feels like it.

On the other hand, becoming museal is a natural result of how we do
things in Debian: Packages are kept alive as long as one single person
cares, while their interest might rather be eliminating RC bugs than the
actual functionality. And proposing a cleanup like in this thread
reliably triggers negative reactions of a few people who want to keep
it.

Without an external limitation (mostly specific hardware) it's hard to
draw a line when it's obviously the time to remove near-dead packages,
at least from the stable releases. I don't have a good idea either what
to do here. 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". And please
don't promote that, it's obviously flawed. But I'm left with a bad
feeling how things currently are.

Chri- "Might do an abandonware BoF at next DebConf" stoph


signature.asc
Description: PGP signature

Re: lpr/lpd

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 17 de septiembre de 2023 14:13:32 -03 Thorsten Alteholz escribió:
> 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 
> 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 even on Debian's archive 
anymore [^0]... but turns out I am filtering the output trough a Qt-based 
application, so no :-/


[^0] Interestingly I keep a copy of the last package on the archive and keeps 
working like a charm for my use case...



signature.asc
Description: This is a digitally signed message part.

Re: lpr/lpd

[Russ Allbery]

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 lpr isn't
> short. I will definitely be looking into rlpr.

Since I wrote my original message, I noticed that rlpr is orphaned.  I no
longer work in an office and print things about once a year, so I no
longer use the package, but it was a lifesaver when I was working in an
office regularly and I do recommend it.  If anyone else who still prints
regularly prefers the simple command-line interface, you may want to
consider adopting it, although it looks like you're likely to have to
adopt upstream as well since it seems to have disappeared.

-- 
Russ Allbery (r...@debian.org)  

Re: lpr/lpd

[Sam Hartman]

> "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 to print with cups.
And there were some efforts there to encourage use of
popularity-contest.
So, those might be legitimate dependencies on the lprng side.

Re: lpr/lpd

[Simon Richter]

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 better for that use case.  It's
possible some of those installations are people doing that, rather than
via dependencies or other things (in which case they probably should move
to rlpr).


Yes, that's basically how I use it. Pretty much all existing printers 
with network interfaces support the BSD lpr protocol still, and accept 
PostScript or PDF. People in Germany are likely to have a FritzBox DSL 
router, which conveniently allows you to export USB printers that way too.


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 lpr isn't 
short. I will definitely be looking into rlpr.


I think those packages are probably still useful to someone, I guess 
several universities will be running these because they are small and 
robust, and can just leave a job in the queue if there is a temporary 
problem rather than mark the printer as offline and any jobs queued to 
it as paused.


Oddly specific rant, I know, but it's "small" things like that that can 
break a use case completely, and that's why we usually ship alternative 
implementations for everything, and why a lot of seemingly small changes 
are controversial: they break non-standard use cases.


   Simon


OpenPGP_signature
Description: OpenPGP digital signature

Re: lpr/lpd

[Russ Allbery]

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 has "lpr" (or "lprng") in the first place
> instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
> have no idea. And there's little chance to know.

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 better for that use case.  It's
possible some of those installations are people doing that, rather than
via dependencies or other things (in which case they probably should move
to rlpr).

-- 
Russ Allbery (r...@debian.org)  

Re: lpr/lpd

[Christoph Biedl]

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.

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 has "lpr" (or "lprng") in the first place
instead of "cups-bsd | lpr". For lpr, that might be xpaint. For lprng, I
have no idea. And there's little chance to know.

Christoph


signature.asc
Description: PGP signature

lpr/lpd

[Thorsten Alteholz]

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 
stuff?  I don't mean the lp/lpr commands that are provided by cups but 
the old lpd spooler from package lpr.


  Thorsten