On 16.09.23 14:29, Christoph Biedl wrote:
One of the questions that I couldn't ask since we were already behind
schedule: Assuming the next Debian release (~2025) will no longer ship
cups2 at all, how does does affect the existing ecosystem around PPD? I
might be wrong but I got the impression se
Till Kamppeter wrote...
> The presentation on DebConf will be even the transition from the original
> CUPS realm to a second, new CUPS realm, ...
... and thanks a lot for that, it gave the clarification needed to
understand what you're heading for.
> > So, it's a good time to resume that topic.
On 31/08/2023 12:30, Christoph Biedl wrote:
Greetings,
we had this discussion on printing several months ago ...
Till Kamppeter wrote...
On 25/12/2022 10:20, Christoph Biedl wrote:
This however should be discussed with all the related package
maintainers and on debian-devel as well. Nothin
Greetings,
we had this discussion on printing several months ago ...
Till Kamppeter wrote...
> On 25/12/2022 10:20, Christoph Biedl wrote:
> > This however should be discussed with all the related package
> > maintainers and on debian-devel as well. Nothing I can afford to spend
> > time on rig
For smooth updating and easy fade-out of PPD file support on the actual
switchover to the New Architecture, I will create the following
relationships between Debian packages (note that on the old system we
had cups-filters 1.x and CUPS 2.x and after the update we want
cups-filters 2.x component
On 30.12.22 16:24, Till Kamppeter wrote:
I will prepare the package right now ... The actual upload needs to
get sponsored, as I am not a Debian Developer. Thorsten could most
probably do this. Once in Debian, we will sync into Ubuntu.
Sure, I will do this (after Bookworm :-)).
Neverthele
On 30/12/2022 06:19, Christoph Biedl wrote:
Christoph Biedl wrote...
2. Allow co-existence by renaming legacy libppd
The conflicting binary package from (legacy) libppd is renamed to
avoid a conflict with your version. So "libppd-dev" could become
"libppd-legacy-dev", and keep poli
Christoph Biedl wrote...
> 2. Allow co-existence by renaming legacy libppd
>
>The conflicting binary package from (legacy) libppd is renamed to
>avoid a conflict with your version. So "libppd-dev" could become
>"libppd-legacy-dev", and keep policy 10.1 in mind². Also, gpr needs
>an
On 28/12/2022 16:40, Christoph Biedl wrote:
Thanks for that, I guess all my concerns are resolved.
Great!
(...)
This gives for libppd2:
/usr/lib/libppd.so.2.0.0
/usr/lib/libppd.so.2
None of my business, but I'd expect some ${DEB_TARGET_MULTIARCH} here.
Yes, the Deabian packages have
Till Kamppeter wrote...
> > > Probably your (2) could perhaps be the way to go?
> >
> > Yes. Current mood, besides kicking lpr* completely (see my other mail):
>
> Long-term goal is actually kicking lpr*, going (2) is only interim ...
Indeed
> > Go indeed (2). It's a step not too big. There is
On 27/12/2022 09:33, Christoph Biedl wrote:
Till Kamppeter wrote...
[ migrating legacy-libppd applications to libppd2 ]
Unfortunately, it is not that simple but also not over-complicated. The
developers had ripped the code for PPD handling from libcups, but they did
not like Michael Sweet's
On 27/12/2022 09:33, Christoph Biedl wrote:
No, this was rather to Thorsten, and suggesting we could ship cups-filters
in both versions in bookworm. That was a service for our users as they can
freely choose when to migrate, and maintainers have less pressure to fix
any bugs immediately.
But I
Till Kamppeter wrote...
[ migrating legacy-libppd applications to libppd2 ]
> Unfortunately, it is not that simple but also not over-complicated. The
> developers had ripped the code for PPD handling from libcups, but they did
> not like Michael Sweet's original API. They replaced the API by a gli
Till Kamppeter wrote...
> On 25/12/2022 10:20, Christoph Biedl wrote:
> > Um, is there a reason why we cannot have both in the upcoming Debian 12
> > ("bookworm")? Since Till shows an exuberant amount of enthusiasm in that
> > matter, I'd prefer it the project could benefit from that soon.
> >
>
>
On 25/12/2022 10:20, Christoph Biedl wrote:
Thorsten Alteholz wrote...
On Fri, 23 Dec 2022, Till Kamppeter wrote:
Now one question: Could we implement (2) already in the current Debian
release (the one which freezes in a few weeks) or do we have to stay
with cups-filters 1.x there and do all t
On 25/12/2022 10:20, Christoph Biedl wrote:
Till Kamppeter wrote...
As both libppd are rip-outs from CUPS, their APIs are very similar, so one
could add some *.h file (and perhaps one *.c file with simple wrapper
functions) to make my modern libppd replacing the legacy one so that we can
ditch
Thorsten Alteholz wrote...
> On Fri, 23 Dec 2022, Till Kamppeter wrote:
> > Now one question: Could we implement (2) already in the current Debian
> > release (the one which freezes in a few weeks) or do we have to stay
> > with cups-filters 1.x there and do all the changes only after that
> > rel
Till Kamppeter wrote...
> I have downloaded the upstream source of the legacy libppd now and
> investigated ...
Thanks a lot for doing all this. I certrainly lack the expertise for that.
> As both libppd are rip-outs from CUPS, their APIs are very similar, so one
> could add some *.h file (and p
Hi Till,
On Fri, 23 Dec 2022, Till Kamppeter wrote:
Now one question: Could we implement (2) already in the current Debian
release (the one which freezes in a few weeks) or do we have to stay with
cups-filters 1.x there and do all the changes only after that release so that
they are in place o
Hi Christoph,
On Fri, 23 Dec 2022, Christoph Biedl wrote:
2. Allow co-existence by renaming legacy libppd
(...)
Biggest concert for me: An updated legacy src:libppd would have to go
through NEW, nodoby knows how long that will take.
oh, this should be easy: if I know of the new upload, the
On 23/12/2022 22:01, Thorsten Alteholz wrote:
the next Debian release will still have cups-filters 1.x
As long as libppd is independent of cups-filters 2.x (at least I
understood your first email this way), the new libppd could be already
added.
The new libppd needs libcupsfilters 2.x, so it
On 23/12/2022 19:30, Till Kamppeter wrote:
Is the API of the legacy libppd complex? Or could one find someone who
could add this API to my modern libppd to keep these users happy and
give them even a maintained library.
I have downloaded the upstream source of the legacy libppd now and
invest
Hi,
thanks for the explanations.
First, I am really wondering that there are still users using some
lpr/LPD/LPRng-type printing system, to my knowledge they are all
unmaintained for decades and many years ago I have dropped their support
from Foomatic. Nobody complained.
I am also wondering
Hi there,
Till Kamppeter wrote...
> Christoph, as you are the Debian maintainer of it, I want to ask you whether
> this package has still any use or whether you could invoke the process of
> requesting removal of it.
First, to avoid any misunderstanding: My motivation to take
maintainership of l
24 matches
Mail list logo
