[Printing-architecture] OpenPrinting News

Zdenek Dohnal zdohnal at redhat.com
Thu Feb 14 13:21:48 UTC 2019

On 2/13/19 7:14 PM, Till Kamppeter wrote:
> Hi,
> here is the newest development of the last month.
>    Till
> ----------
> Google Summer of Code 2019
> --------------------------
> The org application of the Linux Foundation is submitted and on Feb 26
> we will know whether we got accepted by Google.
> Avahi
> -----
> Also Red Hat is bumping into the fact that Avahi is unmaintained
> upstream, see discussion as answer to our minutes from last month:
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/thread.html
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003653.html
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003654.html
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003655.html
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003656.html
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003657.html
> https://lists.linuxfoundation.org/pipermail/printing-architecture/2019/003659.html
> Michael Sweet writes:
> ----------
> A bug was filed against CUPS last month requesting that we start
> supporting systemd's new mDNS resolver (which apparently is replacing
> the use of Avahi in systemd?!?):
>     https://github.com/apple/cups/issues/5452
> I pushed back since there does not appear to be a way to browse DNS-SD
> SRV records and there is no interface for registering services outside
> of systemd configuration files.  But that might be a future
> alternative to Avahi should they extend the current interfaces to
> support it...
> ----------
> Zdenek Dohnal from Red Hat writes:
> ----------
> I talked about both issues with Michal Sekletar, which is systemd and
> avahi maintainer for RHEL and the situation is following:
> 1) systemd-resolved as successor of nss-mdns module:
>     As far as Michal knows, systemd-resolved is not currently meant as
> successor of nss-mdns module + avahi since it does not support service
> browsing as Mike found out. If it will in the future, he does not know
> right now (probably how avahi situation will turn up...).
> 2) Avahi upstream maintenance
>    Michal and several other people tried to convince Trent to pass
> ownership to someone else (Michal knew about two people, who would like
> to take Avahi project at that time) about two years ago, because Trent
> seemed to do not have time for the project. But Trent did not want to
> give away the upstream project. Currently Michal fixes Avahi issues
> downstream in Fedora/RHEL.
> ----------
> My suggestion:
> ----------
> As Debian does not accept carrying patches distro only with upstream not
> taking them and also as it is very awkward if all distros have to carry
> the same patch due to upstream not caring, and naturally also an
> integral part of the OS needs solid upstream maintainership, this is an
> unbearable situation.
> It would be great if someone could convince Trent to accept a
> co-maintainer who also can directly commit to and also issue releases of
> Avahi. If Trent refuses this, I see as the only solution the forking of
> the project. This is the usual way how one handles these situations.
> The current official Avahi repo is
> https://github.com/lathiat/avahi/
> so it is under the personal domain of Trent and not a project domain as
> for example
> https://github.com/openprinting/
> where cups-filters, ippusbxd and others are.
> So I checked
> https://github.com/avahi/
> and there is something which has nothing to do with Avahi. We should ask
> the owner whether he could move his GitHub activity to another name to
> free avahi for us and then we put our fork of Avahi there.
> If this does not work out I suggest to host the Avahi fork on GitLab.
> Or should we fork Avahi under a new name then?
> ----------
> According to Zdenek, Michal tried this with the co-maintainership
> already.
> Seems that Trent is refusing any cooperation or completely ignoring
> the project.
> My suggestion is to fork the project and use one of the locations
> suggested by me, but who should be the upstream maintainer then.
Michal Sekletar contacted me last week about Avahi situation. IMHO he
talked with Lennart (since he is his co-worker from the same team) about
the situation and came up with solution they will try to implement Avahi
features (because Avahi has currently uncooperative upstream and Avahi
API is not so good for use in their opinion) into systemd itself,
probably in systemd-resolved.

But the initiative does not have any specific dates when it will be
done, only 'in the future', so I cannot declare any specific deadlines
when it will be done. Because of it I'm for Till's suggestion, if
immediate solution is needed.

About future work on systemd, I only told Michal what CUPS would need
from systemd, if Avahi will be gone (I used what Mike said in

- register service instance and TEXT/LOC records

- browse for service

- resolving .local hostnames

If I missed something, please tell me and send me an email.

Just sharing the latest gossip from systemd group.

> ----
> No new releases.
> When working on this cups-filters bug report
> https://github.com/OpenPrinting/cups-filters/issues/22
> I discovered that CUPS uses 4 different variants of the
> get-printer-attributes IPP request at 4 places, so for one and the
> same printer 4 different PPD files can get generated, depending on the
> method how one creates a print queue for the driverless IPP printer. I
> have reported this to CUPS as a bug and Mike has fixed it on both
> 2.2.x and 2.3.x.
> See
> https://github.com/apple/cups/issues/5484
> cups-filters
> ------------
> Currently released is 1.22.0.
> From this release on the pdftopdf filter flattens interactive PDF
> forms and annotations internally, using QPDF, instead of calling
> external utilities. This especially eliminates slowing factors as
> additional piping of the data and unneeded use of PDF interpreters.
> Using external utilities for flattening is still possible in case of
> problems. In addition, a crash bug in cups-browsed got fixed and
> compatibility of the filters with Poppler 0.72 assured.
> The form-flattening with QPDF was already planned 2 years ago as GSoC
> project, but the student did not complete his work. Jay Berkenbilt,
> upstream maintainer of QPDF, completed the work (the code is
> practically completely in QPDF), released a new version of QPDF with
> this included, and told me what to call from pdftopdf during the
> new-year break. Note that Jay is doing all that voluntarily. Also
> Tobias Hoffmann, former GSoC student and mentor, helped on this.
> The next release will (1.22.1) will still happen before Ubuntu's
> Feature Freeze (Feb 21) and mainly switch the get-printer-attributes
> IPP calls to the way how CUPS does it now.
> CHANGES IN V1.22.1
>     - cups-browsed, driverless: When polling the printer's
>           capabilities via get-printer-attributes IPP request for
>           driverless printing, use the attributes "all" and
>           "media-col-database". Without "all" some printers do not
>           report "urf-supported" and without "media-col-database" not
>           all paper size and marging info gets reported (Issue #22,
>           Pull request #86, CUPS issue #5484).
>     - braille: Document how to rework output before
>       embossing. Thanks to Samuel Thibault for this patch (Pull
>       request #90).
> CHANGES IN V1.22.0
>     - pdftopdf: Use QPDF for flattening interactive PDF forms
>       (Issues #2, #23, #36, Pull request #88).
>     - pdftopdf: Fixed bug of closing temporary file prematurely
>       when external PDF form flattening utilities fail (Thanks to
>       Tobias Hoffmann for finding this, see pull request #88).
>     - pdftoopvp: More fixes for building with Poppler 0.72
>       (Pull request #83, Issue #75).
>     - pdftoraster, pdftoijs, pdftoopvp: Removed support for
>       Poppler 0.18 (Pull request #83).
>     - cups-browsed: Fixed crash in applying the BrowseFilter
>       cups-browsed.conf directives (Debian bug #916765).
> ippusbxd
> --------
> No further news.
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20190214/90470c66/attachment.sig>

More information about the Printing-architecture mailing list