From: Till Kamppeter <till.kamppeter@gmail.com>
To: Andreas Radke <andyrtr@archlinux.org>
Cc: Aveek Basu <aveek.basu@lexmark.com>,
Open Printing <printing-architecture@lists.linux-foundation.org>
Subject: Re: [Printing-architecture] OpenPrinting News
Date: Fri, 10 Dec 2021 19:54:49 -0300 [thread overview]
Message-ID: <ff2fcb6b-fcec-115d-0f4e-a191a71ff3b3@gmail.com> (raw)
In-Reply-To: <20211210212022.7818a35d@laptop64>
Up to now I have created more or less a working model of the needed
Printer Applications, to find out what is needed in the library's APIs
before making releases of the libraries (libcupsfilters,
libpappl-retrofit). Therefore there are no upstream package releases yet
but Snaps for everything.
With the Snaps I once wanted to find out whether and how CUPS and the
Printer Applications work when snapped (or generally sandboxed) and also
give users a way to quickly download and try out everything without
needing to compile.
I know that with Snaps I cover many distributions (the systemd-based
ones) but not all, as some do not use systemd and others have policies
against Snap, mainly due to the fact that there is currently only one
Snap Store. So Snap is a good platform to quickly get user response for
a new project, without the bureaucracy of getting it into a distro and
without only addressing the users who compile stuff. It also covers many
distributions and so gets a permanent source for many users, especially
also for packages (here printer drivers) which are newer than the distro
release they are using.
What is Arch's situation. Do they not support Snap because they are not
using systemd or is it because of things like the Snap Store "monopoly",
or because of being an easy way to install closed-source software, or
for other reasons?
Now, as I have put practically all free software printer drivers into
Printer Applications I know that my library's APIs are good enough for
the task and so, as you can read in my December news, I am working on
making the libraries releasable, by testing and debugging them. Then I
will release cups-filters 2.0.x and pappl-retrofit 1.0.x, and after that
also spin upstream releases of the 4 Printer Application, making it easy
for distros to create distro packages in their package format (DEB, RPM,
whatever Arch uses, ...).
The build systems of cups-filters and libpappl-retrofit are already
distro-friendly (derived from cups-filters 1.x), so once we have
releases, creating distro packages should be easy.
The daemons in the Printer Applications are created and controlled by
the PAPPL library project. Should you run into problems packaging the
Printer Applications for a distro where PID 1 is not systemd due to the
starting of the daemon, please report an issue at PAPPL:
https://github.com/michaelrsweet/pappl/issues
This is the state of the art as of now and I naturally want that the
Printer Applications will be packaged in different formats to cover as
many distributions as possible and so reach as many users as possible.
Especially when we are at CUPS 3.x in 2 years, PPD support is dropped in
CUPS and so everyone will need Printer Applications for non-driverless
legacy printers, independent of whether there is some sandboxed
packaging used or not.
We especially need to make sure that printing support in Arch is in a
good shape so that it "just works" for users. Especially see this video:
https://www.youtube.com/watch?v=TtsglXhbxno&t=9s
So I would much like that the user experience on Arch is the same as on
Mint, and we from OpenPrinting want to help you on that.
I hope this clarified the situation. Please post if you have any further
questions.
Till
On 10/12/2021 21:20, Andreas Radke wrote:
> Hi Till,
>
> I'm still missing some initial news about how to package printer
> applications in the future as casual distribution packages without the
> snap store. I'm willing to help offering early packages but so far there
> seems to be no way planned without going the snap path. Arch doesn't
> offer any snap support and will never do so.
>
> -Andy
> Arch Linux
>
next prev parent reply other threads:[~2021-12-10 22:54 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 19:25 [Printing-architecture] OpenPrinting News Till Kamppeter
[not found] ` <20211210212022.7818a35d@laptop64>
2021-12-10 22:54 ` Till Kamppeter [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-12-21 4:05 Till Kamppeter
2023-11-28 1:30 Till Kamppeter
2023-11-03 9:00 Till Kamppeter
2023-10-04 23:48 Till Kamppeter
2023-09-05 22:06 Till Kamppeter
2023-07-04 16:51 Till Kamppeter
2023-05-25 9:07 Till Kamppeter
2023-04-16 21:06 Till Kamppeter
2023-03-28 20:56 Till Kamppeter
2023-02-27 23:35 Till Kamppeter
2023-01-20 22:29 Till Kamppeter
2022-12-19 0:26 Till Kamppeter
2022-11-21 13:43 Till Kamppeter
2022-10-21 0:38 Till Kamppeter
2022-09-22 17:43 Till Kamppeter
2022-08-19 22:13 Till Kamppeter
2022-06-14 18:51 Till Kamppeter
2022-05-11 22:12 Till Kamppeter
2022-04-13 20:08 Till Kamppeter
2022-03-18 15:00 Till Kamppeter
2022-02-14 18:38 Till Kamppeter
2022-01-17 18:16 Till Kamppeter
2021-11-13 23:49 Till Kamppeter
2021-10-12 22:09 Till Kamppeter
2021-10-13 10:28 ` Zdenek Dohnal
2021-10-13 11:57 ` Till Kamppeter
2021-10-13 12:32 ` Zdenek Dohnal
2021-09-16 19:18 Till Kamppeter
2021-08-13 22:17 Till Kamppeter
2021-07-17 0:10 Till Kamppeter
2021-07-18 10:50 ` Andreas Radke
2021-06-15 11:21 Till Kamppeter
2021-05-21 16:30 Till Kamppeter
2021-04-11 12:53 Till Kamppeter
2021-03-06 0:14 Till Kamppeter
2021-02-08 23:13 Till Kamppeter
2021-02-10 6:01 ` Zdenek Dohnal
2021-01-15 20:05 Till Kamppeter
2020-12-13 20:10 Till Kamppeter
2020-11-12 22:59 Till Kamppeter
2020-10-26 19:54 Till Kamppeter
2020-09-11 18:53 Till Kamppeter
2020-08-14 6:29 Till Kamppeter
2020-08-14 11:42 ` Till Kamppeter
2020-08-17 6:00 ` Zdenek Dohnal
2020-07-10 18:57 Till Kamppeter
2020-06-05 22:58 Till Kamppeter
2020-05-18 21:27 Till Kamppeter
2020-04-11 8:32 Till Kamppeter
2020-03-20 22:18 Till Kamppeter
2020-03-23 6:03 ` Zdenek Dohnal
2020-02-17 11:19 Till Kamppeter
2020-01-17 21:24 Till Kamppeter
2019-12-14 0:44 Till Kamppeter
2019-11-06 23:06 Till Kamppeter
2019-09-03 21:16 Till Kamppeter
2019-08-07 12:44 Till Kamppeter
2019-06-04 10:41 Till Kamppeter
2019-06-04 11:24 ` Zdenek Dohnal
2019-05-12 16:03 Till Kamppeter
2019-05-12 18:15 ` Matthias Apitz
2019-05-12 18:48 ` Till Kamppeter
2019-04-05 15:10 Till Kamppeter
2019-04-05 19:20 ` Till Kamppeter
2019-04-07 15:21 ` Till Kamppeter
2019-04-07 15:28 ` Ira McDonald
2019-04-07 15:38 ` Till Kamppeter
2019-03-06 14:55 Till Kamppeter
2019-02-13 18:14 Till Kamppeter
2019-02-13 20:34 ` Michael Sweet
2019-02-13 21:26 ` Till Kamppeter
2019-02-13 21:43 ` Michael Sweet
2019-02-13 23:56 ` Solomon Peachy
2019-02-14 8:34 ` Zdenek Dohnal
2019-02-14 17:49 ` Kurt Pfeifle
2019-02-14 20:57 ` Till Kamppeter
2019-02-14 23:43 ` Kurt Pfeifle
2019-02-14 13:21 ` Zdenek Dohnal
2019-02-14 14:39 ` Zdenek Dohnal
2019-02-14 15:31 ` Till Kamppeter
2019-02-14 16:12 ` Zdenek Dohnal
2019-02-14 14:52 ` Till Kamppeter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff2fcb6b-fcec-115d-0f4e-a191a71ff3b3@gmail.com \
--to=till.kamppeter@gmail.com \
--cc=andyrtr@archlinux.org \
--cc=aveek.basu@lexmark.com \
--cc=printing-architecture@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.