Splix: 2.0.1 release, stop tarball and versioning nightmare
Hi, The absence of a new SpliX release for 15 years now has caused some bad things with it, especially: https://bugs.launchpad.net/ubuntu/+source/splix/+bug/2060038 splix version 2.0.0+svn315-7fakesync1ubuntu0.22.04.1 in jammy is higher than versions in mantic and noble To stop with this nightmare I came finally around to make a release, catching up all the commits after 2.0.0 and including all non-Debian-specific distro patches. It is 2.0.1, and as I cannot release on the old SourceForge site, I have moved the repo over to GitHub, under OpenPrinting: https://openprinting.github.io/splix/ Please update the Debian package to this release (Does not need to be within Ubuntu deadlines, having it for the 24.10 cycle is good enough). With this we can have an actual sync between Debian and Ubuntu again and we can remove all but the Debian-specific 0004-... patch. Till
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
On 31/03/2024 22:23, Paul Szabo wrote: (Sadly, my other issues were "declined" upstream. Maybe they know what they are doing...) Where did you report them? Till
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
On 30/03/2024 23:19, Paul Szabo wrote: Most issues now reported upstream: https://github.com/OpenPrinting/cups/issues/917 https://github.com/OpenPrinting/cups/issues/918 https://github.com/OpenPrinting/cups/issues/919 The issue with pdftopdf not reported upstream, because I could not find the corresponding "current" source. Cheers, Paul The current source of pdftopdf is libcupsfilters: https://github.com/OpenPrinting/libcupsfilters/issues Till
cups package: Please remove Debian's own cups.pc
Thorsten, in cups 2.4.7-1 you have introduce your own cups.pc file, via debian/cups.pc.in and debian/rules. CUPS upstream has a cups.pc already since 2.4.6 and it is much more sophisticated than yours, especially it contains the system directories of CUPS (like /usr/share/cups/). So in 2.4.7 you rudimentary cups.pc has overwritten the upstream one and this broke several things in Ubuntu noble, especially the autopkgtest of cups-browsed. I have removed your cups.pc in Ubuntu, cups 2.4.7-1.2ubuntu2: ttps://launchpad.net/ubuntu/+source/cups/2.4.7-1.2ubuntu2 http://launchpadlibrarian.net/721297955/cups_2.4.7-1.2ubuntu1_2.4.7-1.2ubuntu2.diff.gz Could you do the same in Debian? Thanks. Till
Re: New HPLIP releases, now 3.23.12, but Debian package still 3.22.10
Due to the Feature Freeze for Ubuntu 24.04 tomorrow I have done an Ubuntu package of HPLIP 3.23.12, it is downloadable on Launchpad now: https://launchpad.net/ubuntu/+source/hplip/3.23.12+dfsg0-0ubuntu1 In the package you especially find all the patches which I had to adjust manually and also 2 new patches, one for compatibility with Python 3.12 and the other to fix a messed up PPD file which broke the autopkgtests. For repackaging the tarball I used the instructions in the file debian/DEBIAN_NEW_UPSTREAM The resolving of the conflicts of the patches during make -f debian/rules get-orig-source did not work for me, but the tarball was already created and so I have taken the tarball and done the rest manually, without using GIT. So the tarball should be the same as it would be used by Debian for this version. Using exactly the same would be great to avoid a tarball mismatch when during the 24.10 cycle Ubuntu auto-syncs with whatever you create for Debian in March. As we are on a good way to get scanning support into PAPPL and SANE backend retr-fitting into pappl-retrofit, at Ubuntu we will probably provide HPLIP as Snap from 24.10 on. After introduction of CUPS 3.x (25.04 at the earliest) we will provide all printer and scanner drivers in Snap format. Till On 27/02/2024 23:34, Thorsten Alteholz wrote: Hi Till, On Tue, 27 Feb 2024, Till Kamppeter wrote: Are there plans for further updates? Or plans for abandoning HPLIP in Debian? the update is on my agenda for March. I definitely do not plan to abandon the package. Thorsten
New HPLIP releases, now 3.23.12, but Debian package still 3.22.10
Hi, according to https://developers.hp.com/hp-linux-imaging-and-printing/release_notes HPLIP's current upstream version is 3.23.12, while the Debian package is still based on version 3.22.10: https://salsa.debian.org/printing-team/hplip.v2/-/commits/debian/main/?ref_type=HEADS Did you try to update and there occured any unexpected problems? Are there plans for further updates? Or plans for abandoning HPLIP in Debian? Till
Re: Debian packages of cpdb-libs and cpdb-backend-cups
I have always used tags without 'v' recently, so for of all "my" OpenPrinting repos (all except cups, libcups, cups-shared, cups-local) you can search for version numbers without 'v' as release tags. Fore the CPDB package please consider also beta (like "2.0b1") and release candidate (like "2.0rc1") versions. 2nd generation of CPDB is essentially important. The first generation is lacking a lot of needed features. Till On 15/02/2024 00:04, Thorsten Alteholz wrote: Hi Till, On Wed, 14 Feb 2024, Till Kamppeter wrote: Thorsten, would you introduce the packages cpdb-libs and cpdb-backend-cups (they are both from OpenPrinting) into Debian? You can use the Ubuntu packages as base for that, as they are already in Ubuntu and tested there. cpdb-libs is already part of Debian in version 1.2.0 and cpdb-backend-cups is available in version 1.1.1. The watch files of both packages don't show a new version. Are they broken or did the versioning change? Hmm, the first versions look like v1.1.1 and the new ones are like 2.0b1. This is rather bad. Would it be possible to name the tags consistent over time? Thorsten
Debian packages of cpdb-libs and cpdb-backend-cups
Thorsten, you have probably followed OpenPrinting and seen that for using CUPS 3.x (or any CUPS as Snap package) the printing functionality needs changes, especially the print dialogs must be able to work all-IPP without using PPD files and also need to cope with temporary CUPS queues. So they all need to get updated. As this will not be the last major change on CUPS and we also want to ease the integration of any new, upcoming cloud printing services, we are separating off the support code for communicating with the print technologies in use (CUPS, clod printing service, ...). The communication will go into backends, one for each print technology, the Common Print Dialog Backends. Each backend will be maintained by the maintainer of the respective print technology (CUPS backend by OpenPrinting). The print dialogs need a common interface to talk with the backends by D-Bus and do not need to directly communicate with the print service. So if we change CUPS, we change the CUPS backend appropriately and print dialogs continue to work without the GUI and app maintainers have to run after each CUPS change. See also https://openprinting.github.io/achievements/#common-print-dialog-backends This would require in Debian to package cpdb-libs and cpdb-backend-cups and then change GUI libraries and apps which already support CPDB to actually use it. Up to now this is at least GTK4, others to come. But the more urgent reason for adding cpdb-libs and cpdb-backend-cups to Debian is not this, but that we can build GTK4 in Debian with printing via CPDB and not directly with CUPS. This way we will get a smaller delta between the Debian and Ubuntu packages of GTK4. This would be awesome and reduce the maintenance burden a lot. The same will happen for other software in the future: Qt, LibreOffice, Chromium Browser, Firefox, Thunderbird ... Thorsten, would you introduce the packages cpdb-libs and cpdb-backend-cups (they are both from OpenPrinting) into Debian? You can use the Ubuntu packages as base for that, as they are already in Ubuntu and tested there. Thanks in advance Till
Re: pstotext - OK to remove completely?
I did not even know that pstotext exists, even not back in the early 2000s when I established CUPS as Linux' standard printing environment. So can be removed, nobody will miss it ... Till On 06/01/2024 13:43, Steven Robbins wrote: Hi, I randomly bumped into a reference to "pstotext" just now -- from ps2ascii manpage. The pstotext package was removed from testing in 2018 due to grave bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895513 The last upstream release was 2004 and there is no trace of upstream on the internet that I can see. There's a wayback capture from mid 2007 but it was removed shortly afterwards. https://web.archive.org/web/20070609094538/http://www.cs.wisc.edu/~ghost/doc/ pstotext.htm To me, it seems that this should just be completely removed from Debian. I'll file a removal bug unless there are objections? -Steve
Re: Picking up orphaned ghostscript
On 23/12/2023 11:25, Thorsten Alteholz wrote: Hi Steven, On 22.12.23 18:47, Steven Robbins wrote: I noticed recently that ghostscript has been orphaned and decided I'll volunteer to be maintainer. great, so I can remove an item from my agenda :-). >From the wiki site, I can see that ghostscript is listed as team maintained. However, the control file doesn't currently list the team in the Maintainer field -- whereas "cups" does. Is this just an individual maintainer preference thing? The repository is still within the Debian namespace, so the connection is not that close as with cups. Would it be OK if I changed the maintainer to the team email (and list myself as uploader)? Yes, that would be fine. I suggest to have Ghostscript under the Debian printing team umbrella to keep all the printing stack at one place. But Steven, mark yourself as uploader then. For the foreseeable future Ghostscript will stay a central part of the printing stack, it is a mature PDF interpreter and also the only free software PostScript interpreter. Applications send the print job data in PDF and if the printer does not understands PDF, Ghostscript rasterizes the data into Apple Raster, PWG Raster, CUPS Raster, PCL 5c/e or turns it into other high-level formats as PostScript or PCL-XL. Of what one finds in distros the only alternative of a PDF interpreter is Poppler, if no PostScript interpreter is needed. But Ghostscript is also more optimized for printing. Till Till
Final 2.0.0 release of the second generation of cups-filters!
Hi, I have done the final 2.0.0 Release of the new cups-filters components now! It contains the fix for security vulnerability CVE-2023-4504 in libppd and several fixes for bugs reported after RC2. Here we go: https://openprinting.github.io/cups-filters-Second-Generation-Final-2.0.0-Release/ There are also GitHub discussions set up for each release. Till
Re: Request for Removal: Unmaintained libppd in Debian
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. Nothing I can afford to spend time on right now given the bookworm freeze timeline. OK, let us aim for complete LPD/LPR/LPRng/legacy-libppd/gpr removal for bookworm+1 ... Well, back then we came up with a decision for libppd but the process that followed did not go quite well (read: It was fairly demotivating for me). Since then, bookworm was released. And I've seen you're going to present something at DebConf[1] - which unfortunately I will not attend in person but I'll try online. The presentation on DebConf will be even the transition from the original CUPS realm to a second, new CUPS realm, ... So, it's a good time to resume that topic. DebConf might be as well the right moment to initiate a "Let's remove lpr-based printing from Debian" discussion. How would you assess the situation and ideas today? ... so in my opinion as CUPS already well established and making its way to the New Architecture after 20+ years in its original architecture, and that not only in Debian, and therefore everything LPR/LPDish not being maintained any more, we should really remove the old LPR/LPD-based remainders from the Debian distro. On the removal it can happen that one or another user complains, but there are millions using CUPS and content with it. Maintaining Debian packages of upstream-unmaintained software only for a handful of people is not worthwhile. Without having looked into the old discussions, so just from memory: Unike last December I'm more inclined today to just kick the old stuff out of Debian, in my area that would be my legacy libppd and gpr which depends on it. The latter would require some interaction with the maintainer, but we could at least give that a try. "maintainer" of gpr? Debian package or upstream? If there is a Debian package maintainer insisting on gpr's continuation, they should tell us why. I would really remove all this from Debian. Till
Bug#1039983: Color Laser-Printer does only print in greyscale after upgrade to Debian 12
Probably you are hitting this bug https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242 The bug is fixed upstream in CUPS 2.4.3 and later and I have created 2 Stable Release Updates (SRUs) for Ubuntu Jammy (CUPS 2.4.1) and Lunar (CUPS 2.4.2). So you could try these fixes and they could perhaps also get applied to Debian.
Second Release Candidate of the second generation of cups-filters released!
Hi, I have done the Second Release Candidate of the new cups-filters components now! It covers the fixes of bugs reported shortly after the release of the first two distros (Ubuntu 23.04, Fedora 38) including cups-filters 2.x (2.0rc1). Also a fix resulting from testing the fully updated CUPS Snap are included, and the fix for our first security vulnerability report. But I did not yet do the final release and did a second release candidate first, as I have synced the libppd code with the PPD file support code of current CUPS. The PPD support code of CUPS got spun out for starting libppd three years ago and after that there happened many changes not being synced during all this time, and therefore there should be a little more time for testing. If nothing severe happens, I will release cups-filters 2.0.0 final in a few weeks, so that perhaps we can celebrate it on the GUADEC … Here we go: https://openprinting.github.io/cups-filters-Second-Generation-Release-Candidate-2/ There are also GitHub discussions set up for each release. Till
Re: Debian Packages for the New Architecture
On 01/06/2023 00:18, Thorsten Alteholz wrote: Hi Till, On Wed, 31 May 2023, Till Kamppeter wrote: I do not know how far the Bookworm release process has progressed and whether the new development cycle has already started. the release is planned on 2023-06-10 and afterwards the fun may begin again. OK, so the week after the next one, Debian can start to get the nice new printing features ... For the New Architecture for printing Debian needs to have the following packages: (...) I am missing KDE/QT in this list. Is everything already available there? Would KDE users still be able to print? In your PPA you only mention gtk4. I have also Qt6 there with a print dialog which correctly works with CPDB. See also my instructions: https://openprinting.github.io/OpenPrinting-News-May-2023/#test-the-gui-changes-for-the-new-architecture As the print dialog did not get actually changed for ~20 years, backporting the CPDB support to older versions of Qt should not be that complicated. I think xfce, lxde, cinnamon and some other desktop environments still depend on gtk3. Are there any efforts to implement CPDB there as well? I did not plan any backports yet, was primarily happy that CPDB support made it into the current GTK. Also in GTK the print dialog stayed unchanged for long time, so that here a backport should also not be too complicated. It looks like the old printing architecture needs to be available in parallel to CPDB. Would that be possible? If I remember correctly there are some hurdles, aren't they? What can we do when cups3 appears? Principally this is no problem at all. Some print dialogs using CPDB and others not does not break any of them. What CPDB adds is full support for the New Architecture, especially 1. No direct handling of the print queue's PPD files, for that printer properties and options are only polled from CUPS through standard APIs of libcups. Now download or local file access of the PPD file, no use of libcups functions to handle PPD files. 2. The dialog lists (and also prints on) not only permanent CUPS queues whic the user or admin creates, but also IPP print destinations for which CUPS does not need a permanent print queue, where, when one tries to print, CIUPS auto-creates a temporary queue and removes this queue again when the job is done. To fulfill this, one has to use the newest, up-to-date (already for several years) CUPS API, the cups...Dest...() functions of libcups, like cupsEnumDests() to list available print destinations, both classic, permanent CUPS queues and IPP print destinations. The CPDB CUPS backend does this. The other advantage of CPDB is that we maintain the CUPS backend at OpenPrinting and when something else changes in CUPS we will update the backend, and so the CPDB-supporting print dialogs stay up-to-date. Generally for print dialogs to work they only need to fulfill (1) and (2), usually by using the correct cups...Dest...() libcups API. If a dialog misses CPDB but fulfills these criteria on its own, we are good enough, for now at least. The workaround for print dialogs which do not comply is cups-browsed. cups-browsed, as it is pre-configured in the Ubuntu (and with this also in the identical Debian) package generates a classic, permanent CUPS queue (with a PPD file) for each discovered IPP print destination on which CUPS would print with a temporary queue. So even print dialogs which fail on both (1) and (2) will work. With CUPS 2.x one can always use cups-browsed, even with the CUPS Snap (as long as it is still CUPS 2.x). With CUPS 3.x the current cups-browsed will not work any more, as we cannot create classic queues with PPD files any more. cups-browsed will then be replaced by a Printer Application (Cluster Printer Application? cluster-printer-app?) which continues its clustering functionality, but this one will not make outdated print dialogs working. I want to get rid of installing and running cups-browsed by default. What we can do for the time being until we actually get CUPS 3.x (Mike has postponed it by a year, to end-2024, see my May News) is to make Debian packages containing not-complying print dialogs depend on cups-browsed (or at least recommend it): libgtk3, Qt4, Qt5, apps with their own print dialogs until those adopt CPDB. The (better) alternatives for old versions of the GUI libraries GTK and Qt is to backport the CPDB support of the current version, perhaps even as distro patch. Apps with their own print dialogs often allow to click a button in the app's print dialog to open the "standard" or "system" print dialog, which is the GTK one. If that GTK dialog is GTK4 (CPDB support) or of a GTK with backported CPDB support, we could distro-patch the app top not show its own dialog at all but the GTK print dialog straight away. For the NEW packages I suggest the following: Jeremy and/or Seb upload/propose
Debian Packages for the New Architecture
Hi, I do not know how far the Bookworm release process has progressed and whether the new development cycle has already started. For the New Architecture for printing Debian needs to have the following packages: - cpdb-libs 2.x - cpdb-backend-cups 2.x - cpdb-backend-file 2.x These packages need to get updated to the newest version - gtk4 with CPDB support CPDB packages (see above) and gtk4 need to be updated gtk4 needs to be built with CPDB support, see example in my Ubuntu PPA: https://launchpad.net/~till-kamppeter/+archive/ubuntu/new-arch-dev - PAPPL Package already in Debian - LPrint Printer Application Package already in Debian - libpappl-retrofit1 - libpappl-retrofit-dev - legacy-printer-app pappl-retrofit needs to be added to Debian as NEW package - ps-printer-app - ghostscript-printer-app - hplip-printer-app - gutenprint-printer-app The retro-fitting Printer Applications need to get added as NEW packages. - hp-printer-app Also this one needs to get added as NEW package. For the NEW packages I suggest the following: Jeremy and/or Seb upload/propose the new packages so that Thorsten, who is then allowed to review the additions, reviews them as a person who knows well about Linux printing. If Thorsten would upload them it would get difficult to find a reviewer. The creation/upload of the Debian package of pappl-retrofit should be easy as I have already created a Ubuntu package. The packaging of the Printer Application packages can be derived from the lprint package. Generally packaging and testing examples for the New Architecture you find in my development PPA: https://launchpad.net/~till-kamppeter/+archive/ubuntu/new-arch-dev WDYT? Till
Release Candidate of the second generation of cups-filters released!
Hi, I have done the Release Candidate of the new cups-filters components now! Finally checking through one bugs, not yet merged pull requests, and GSoC contributor candidate assignments, and also doing a lot of further testing, many bugs got fixed. Especially the orientation-requested and landscape attributes are correctly working now, one can print plain text in landscape layout, suppress auto-rotating of images (via "landscape=false" or "orientation-requested=X", X = 3,4,5, or 6), print images also if the printer uses 16-bit-per-color, and has clean white dot-free backgrounds when printing 1-bit-dithered. cups-browsed now prefers Apple Raster over PDF if the destination printer supports both, as PDF interpreters in printers are often unreliable and slow. And Zdenek Dohnals fixes based on his Coverity scan on cups-browsed are now included in the release. Thanks, Zdenek, for this great work. The 2.0rc1 releases of all the components are also the versions used by Ubuntu 23.04 Lunar Lobster, to be released in a week from now, on Thursday, April, 20! Here we go: https://openprinting.github.io/cups-filters-Second-Generation-Release-Candidate/ There are also GitHub discussions set up for each release now. Till
Forth beta of the cups-browsed in the second generation of cups-filters released!
Hi,
I have done the forth beta release of the new, separated cups-browsed
package, one of the new components of the former cups-filters.
Central part of this release isa new test script, to be used both for
build tests ( "make check") and tests on the packages installed into a
system (like autopkgtests of Debian and Ubuntu).
This is not only for general QA but also a requirement for the package
being accepted in the core part ("Main") of the Ubuntu operating system.
See also
https://openprinting.github.io/OpenPrinting-News-February-2023/#the-new-architecture-is-going-into-ubuntu-and-red-hat
Developing of such a script naturally involves a lot of testing of
cups-browsed itself, making us find several bugs and fix them. These
fixes are also included in the new release.
Here we go:
https://openprinting.github.io/cups-browsed-Second-Generation-Forth-Beta-Release/
There are also GitHub discussions set up for each release now.
Till
Re: Ghostscript orphaned
On 14/02/2023 00:01, Thorsten Alteholz wrote: Oh, I have to admit I have no clue what this means :-). But in case leptonica is related to leptonlib, keeping the convenience copy is a very bad thing as leptonlib is affected by lots of CVEs. The same seems to happen with tesseract ... And please don't shoot the messanger, this sound like something that has to wait until after the release. I do not actually know what leptonlib is and that it existed. I am already using the convenience copy of leptonica in Ghostscript for a longer time as the system's leptonica is not in Main. There were no complaints and especially no CVEs about that, and so I simply relied on Ghostscript's upstream developers in terms of upstream maintenance and security here. According to doc/HowToBuildTheDocs.txt: "This documentation relies on Sphinx to publish HTML & PDF docs from markdown files written with restructured text / RST" At least debian/rules uses sphinx-build ... I only had a look into the debian/ directory and did not see the doc/HowToBuildTheDocs.txt file. Thank you very much. Till
Re: Ghostscript orphaned
On 13/02/2023 23:46, Thorsten Alteholz wrote: This is just some Wiki page. Before Jonas orphanded the package, the Maintainer: was set to the Debian Printing Team but the repository was still in the Debian-namespace. Now, the Maintainer: is set to the QA team and just this Wiki page mentions this relation to the printing team. Thanks for the update o this. Till
First beta of the second generation of the Common Print Dialog Backends released!
Hi, We are now releasing the second beta of the second generation of the Common Print Dialog Backends (CPDB). In the 4.9.4 version of GTK the Merge Request [1] for Gaurav Gulerias GSoC work [2] on adding CPDB support to GTK’s print dialog got finally accepted. To reach this goal, Gaurav also needed to do a lot of enhancements on CPDB itself, and when his merge request got accepted into GTK, CPDB 2.0b1 was already 2 months old and after that a lot of changes have been done, ending up with GTK’s CPDB support not building with any released version of CPDB [3]. Therefore we have now released version 2.0b2 of all the three components of the CPDB to allow easy building of the first CPDB-supporting GTK. [1] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4930 [2] https://github.com/TinyTrebuchet/gsoc22/ [3] https://gitlab.gnome.org/GNOME/gtk/-/issues/5589 The components we are currently maintaining got all updated and released as version 2.0b2. We especially added support for starting print the dialog with a complete list of available printers and keeping the list up-to-date while the dialog is open. We also added support for option groups (like "Media", "Color", "Finishing", ...) and translations for option, choice, and group names, letting in the first place the backends obtain the translations from the printing system and/or the printer, before the frontend uses translations for standard names. And, as usual, there are many bug fixes. Here we go: https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-Second-Beta-Release/ There are also GitHub discussions set up for each release now. Till
Re: Ghostscript orphaned
On 13/02/2023 19:30, Thorsten Alteholz wrote:
Hi Till,
On 13.02.23 11:44, Till Kamppeter wrote:
For me this means that Jonas has dropped maintainership of this
package. Am I right?
yes, you are right.
Thorsten, as Ghostscript is mainly used for printing (rasterizing PDF,
converting PDF to PostScript), it would be great if you could take
maintainership and put it under the Debian Printing Team umbrella.
What do you think?
I have seen this and had hoped that somebody else steps up to maintain
ghostscript. As nobody seems to be interested, yes, the package should
be part of the Printing Team.
Great! Thanks already now.
As I said I am updating the Ubuntu package of Ghostscript currently.
With Jonas it often was not easy to cooperate, when I suggested
something which helped to reduce the delta between the Ubuntu and the
Debian packages he often did not accept my suggestions, he wanted to
have HIS packaging ...
Now I want to ask you whether we could do some better cooperation for
reducing the delta between Debian and Ubuntu.
Especially the big difference between Debian and Ubuntu is that in
Debian all the packages are in one, single repository, but Ubuntu is
devided up in Main and Universe, where Main is the Canonical-supported
core part and Universe are the community-maintained extra applications.
The printing stack is a core part of an operating system, therefore in
Ubuntu the printing stack is in Main. This also means that all
dependencies of the printing stack have to be in Main. This is also
valid for Ghostscript.
To move a package from Universe to Main one has to do a Main Inclusion
Request so that it can be determined whether a package is
well-maintained, fulfills all standards, especially security, for being
covered by commercial support. This is a lot of work, and sometimes it
can take months until Canonical's security team approves a promotion.
Therefore it would be great if we try to maintain together a Ghostscript
package which has a complete functionality but does not take up
dependencies which are in Ubuntu Universe (or not in Ubuntu at all) if
it is not absolutely necessary. As this will hold back updating
Ghostscript in Ubuntu or requiring extra delta as Ubuntu has to apply
different approaches for packaging Ghostscript than Debian. I succeeded
very well with your predecessor Didier Raboud ("OdyX") to eliminate most
of the Debian/Ubuntu delta in all the other printing-related packages.
Improving on Ghostscript would be great now.
Currently, the delta is the following:
- New re-packaging of Ghostscript 10.00.0, keeping the leptonica and
tesseract convenience copies in as they are not in Ubuntu Main.
Added appropriate remark to debian/copyright.
- Just mark all libtesseract symbols optional and be done with it.
They are also arch-specific so causing build failures on non-x86.
- Also keep the lcms2mt convenience copy as it is heavily patched by
Ghostscript's upstream developers, especially for multi-threading
(mt) support.
- Upstream patch (commit 387f094) for the CUPS/PWG/Apple Raster
output device not to match custom page sizes against the sizes
defined in the PPD file, to avoid unwished rotations or size
adjustments. (cups-filters upstream issue #484).
I think with the first 2 we can live very well in general, but the last
2 in the list should actually get into Debian's Ghostscript.
- Debian should use the lcms2mt convenience copy of lcms2, too as it is
heavily adapted to Ghostscript and adds multi-threading.
- The upstream patch is an important fix which I did after the 10.00.0
release of Ghostscript. It is especially important with the new
libcupsfilters 2.x. It is only temporary, in Ghostscript 10.01.0 it
will be included.
I do not actually understand the
Build-Depends-Indep:
python3-sphinx,
python3-sphinx-rtd-theme,
rst2pdf,
in debian/control. Which documentation is generated with this?
Ghostscript is not a Python project.
Till
Ghostscript orphaned
Hi, I have looked into the Debian package of Ghostscript 10.00.0 now and seen the following in its changelog: -- ghostscript (10.0.0~dfsg-4) unstable; urgency=medium * orphan package: set maintainer to Debian QA Group -- Jonas Smedegaard Mon, 24 Oct 2022 13:54:55 +0200 -- For me this means that Jonas has dropped maintainership of this package. Am I right? Thorsten, as Ghostscript is mainly used for printing (rasterizing PDF, converting PDF to PostScript), it would be great if you could take maintainership and put it under the Debian Printing Team umbrella. What do you think? Till
Third beta of the second generation of cups-filters released!
Hi, I have done the third beta releases of the new cups-filters components now! During creation of the Debian, Ubuntu, and Red Hat packages for the components of the 2nd-generation of cups-filters and also during the investigation of reported issues some more bugs got discovered and fixed. Especially in all the component’s source code tarballs the LICENSE file was missing, which is a problem for Linux distributions using the packages. Now all license- and copyright-relevant files, AUTHORS, COPYING, LICENSE, and NOTICE are included in the source tarballs of all the 4 components. Also unnecessary dependencies, remaining from the times when everything was only a single repository, and overlooked during the separation, got removed, especially in libcupsfilters. And minor functional glitches and shortcomings, discovered by users (using cups-filters 1.x but the problem continued in 2.x) and by Debian's and Ubuntu’s automatic testing during package build (autopkgtest), got spotted and fixed. Here we go: https://openprinting.github.io/cups-filters-Second-Generation-Third-Beta-Release/ There are also GitHub discussions set up for each release now. Till
cups-filters 1.28.17 released!
Hi,
I have released cups-filters 1.28.17 now, with the following changes:
- libcupsfilters: In PPD generator create only one *cupsFilter2:
line for raster. Only use the most desirable/reliable format,
usually Apple Raster.
- libcupsfilters: In get_printer_attributes() poll
"media-col-database" separately if needed. On some printers
one gets "media-col-database" only this way. Often it reveals
important functionality, like for example borderless
printing.
- libcupsfilters: Let PPD generator also parse
"media-col-ready" IPP attribute. "media-col-ready" lists the
loaded media, in contrary to "media-ready", as list of
complete descriptions of the media ("media-col" data
structure). This often lists also variants like borderless
(it is the same physical paper). Especially useful when
"media-col-database" is not available.
- libcupsfilters: In generate_sizes() consider all margin
alternatives. When generating the PPD file for a driverless
printer, and in the media-{left,right,top,bottom}-margin-
supported printer IPP attributes there was more than 1 value,
the first value (which often was the 0 for borderless
printing) was not considered, leaving the borderless
functionality of many printers undiscovered (Issues #492).
Bug fix release, to more reliably discover all printer capablities from
driverless printers, especially borderless printing, and to preferably
use Apple Raster instead of PWG Raster or PCLM.
This is primarily for Bookworm as Bookworm will most probably not adopt
cups-filters 2.x.
Thanks in advance.
Till
PAPPL Update to 1.3.1
Hi, could you update PAPPL to 1.3.1 in Ubuntu unstable if the Bookworm freezes still allow it? Thanks. Till
Re: compiler warnings against recent CUPS
Do you mean all these warnings about deprecated PPD-file-related functions? These are harmless for now, as long as the target distro, like Bookworm (and also Ubuntu 23.04 and 23.10) currently, uses a CUPS 2.x version with libcups2. The deprecated functions get actually removed in CUPS 3.x which will get released near the end of this year and so will be the CUPS version used by Ubuntu 24.04 and of the first Debian release after Bookworm. Functionality of printing into a PDF file is nowadays provided by print dialogs, so the situation does not change. cuṕs-pdf is to print to PDF from the command line or to create a print queue not having a printer at hand, for development and debugging. cups-pdf is currently a classic CUPS printer driver and would need to be turned into a Printer Application, an emulation of an IPP printer. This is the format of printer drivers in the world after PPDs being abolished. See https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning and also the video linked there. And https://openprinting.github.io/current/#printer-applications https://openprinting.github.io/current/ I can help you later on with that. Till On 22/01/2023 11:33, Martin-Éric Racine wrote: Greetings, While making a last-minute check on CUPS-PDF before the freeze, I noticed the following compiler warnings (see attachment). These seem to suggest an API migration that, at this stage, merely triggers a warning. Googling up returned no existing patch on other distros that I could use. Nonetheless, I would guess that other CUPS filters have already upgraded their code to match. I was thus wondering if anyone could help me with patching this? Thanks! Martin-Éric
Re: Debian printing packages
On 16/01/2023 15:15, Thorsten Alteholz wrote: oh, I am afraid I won't attend this DebConf ... Had been nice to meet you in India ... But I am also not sure yet whether I will go. There are many conferences throughout the year. You could perhaps do uploads of the New Architecture stuff into Experimental to get some more testing. Yes, this would be possible. Great, this would help me a lot. So I will better wait for you next HPLIP upload before I update the HPLIP Printer Application? It looks like the current version has to wait for a finished python3 transition. So the new upload might take some time, but yes, it might be better to wait for it. Python3 transition? Will this transition already happen in Bookworm or only afterwards? Till
Re: Debian printing packages
On 15/01/2023 09:21, Thorsten Alteholz wrote: Hi Till, The new version sounds like a SONAME change in cpdb-libs? So, yes this is too late for Bookworm. Yes, I has API changs as we had to add several important features, especially human-readable UI strings, translations and options grouping. No problem, it is only essentially needed for the New Architecture. Simply leave Bookworm as it is now and we put in everything new only when development re-opens for the next Debian release and let it mature the full cycle. I will do all the updates Ubuntu-only for now and once Debian re-opens after Bookworm we have already done first rehearsals on Ubuntu. We could even kick off the introduction of the New Architecture on the DebConf in India ... You could perhaps do uploads of the New Architecture stuff into Experimental to get some more testing. By the way, is Debian's HPLIP package up-to-date with upstream? And if not, could you update it? Bookworm should not come with outdated HPLIP. I just uploaded a new version and now have a look at some bugs, so the next upload will follow soon. Thanks for updating HPLIP. So I will better wait for you next HPLIP upload before I update the HPLIP Printer Application? Till
Debian printing packages
Thorsten, thank you very much for your inclusion of the Common Print Dialog Backends packages in Debian. they will make the base for the Ubuntu packages, ideally by syncing, and they will also help me to get the MIRs (Main Inclusion Requests) of these packages in Ubuntu accepted. For all of these there is a new generation (2.0b1) available upstream now and cpdb-libs and cpdb-backend-file would be easy to update already. cpdb-backend-cups depends on libcupsfilters2 which is about to be updated to in Debian. None of the CPDB packages depends on libppd2 (the CUPS backend is ready for the New Architecture, but works with current CUPS as well). The betas should get finally released in ~1 month or so. If this is too late for Bookworm, we should update to the 2.0b1 versions of the cpdb-... packages at least in Experimental. By the way, is Debian's HPLIP package up-to-date with upstream? And if not, could you update it? Bookworm should not come with outdated HPLIP. Till
Second beta of the second generation of cups-filters released!
Hi, I have done the second beta releases of the new cups-filters components now! During creation of the Debian/Ubuntu packages for the components of the 2nd-generation cups-filters and also during the further development of the Common Print Dialog Backends (CPDB) some bugs were discovered which are fixed now. Also the adaptation of the source code documentation files to the individual components was not yet complete. So there were many things to fix and these fixes are now available in the second beta release. Here we go: https://openprinting.github.io/cups-filters-Second-Generation-Second-Beta-Release/ There are also GitHub discussions set up for each release now. Till
Introduction of the Common Print Dialog Backends into Debian
Hi, in 2017 I had created a new concept to maintain the printing technology support in GUI toolkits and applications centralized and separate from the GUI toolkits and applications, the Common Print Dialog Backends (CPDB). The problem is that the print dialogs in GUI toolkits (GTK/Qt) and GUI applications with own print dialogs (Firefox, Chromium, LibreOffice, ...) do not catch up quickly when something changes in CUPS, like introduction of temporary queues for IPP printers for example. Also if a new print technology, like a cloud printing service appears, the GUI developers do not provide support in a timely manner. Especially most of these projects do not have enough (voluntary) people-power to keep up with this. To solve this, we move the responsibility on keeping up with the print technologies away from the GUI/app/desktop developers to the creators of the print technologies, OpenPrinting for CUPS and print-to-file, any provider of a cloud printing technology only needs to make their backend to get their technology into all print dialogs. And the CPDB are also easily snappable so that such a backend could be distributed by the Snap Store. Also for the New Architecture the CPDB are important, as the changes are performed in the CPDB CUPS backend and so the GUI dialog maintainers do not need to adapt their dialogs if the adopt the CPDB. See https://openprinting.github.io/achievements/#common-print-dialog-backends After 2017, I had problems to find volunteers or GSoC contributors to implement the support for the CPDB in the actual GTK and Qt print dialogs, but last year, 2022 I finally succeeded to find a great contributor and he succeeded to implement the CPDB support in the GTK and Qt print dialogs. Along with this he also vastly improved the CPDB framework, especially with support for human-readable and translated option and choice names, option groups/categories (like Media, Quality, Finishing, ...), and a modern CUPS backend using up-to-date CUPS APIs and not handling PPD files at all (so perfectly prepared for the New Architecture). See https://openprinting.github.io/OpenPrinting-News-November-2022/#google-summer-of-code-2022 https://github.com/TinyTrebuchet/gsoc22/ and https://openprinting.github.io/OpenPrinting-News-December-2022/#google-summer-of-code-2022 The principal pull/merge requests in the GUI projects are GTK: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4930/diffs?commit_id=b17001b101e3dc14b262c955e428481c11b8d4c3 https://gitlab.freedesktop.org/cups-pk-helper/cups-pk-helper/-/merge_requests/7 Qt: https://codereview.qt-project.org/c/qt/qtbase/+/437301 And this was leading to the mentioned improvements in the CPDB and therefor a second generation of them: https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-First-Beta-Release/ And therefore I want to ask you to introduce the components of the CPDB into the Debian distributions. It does not need to be in Bookworm, an introduction into Experimental for now and moving it up to unstable after the Bookworm release would be good enough. In addition to getting Debian smoothly into the New Architecture and sharing as much as possible of the printing stack between Debian and Ubuntu it is also helpful for me to get the MIR (Main Inclusion Request) for cpdb-libs approved: https://bugs.launchpad.net/ubuntu/+source/cpdb-libs/+bug/1747759 And for an easy start, Debian packages (at least of 1.x versions) already exist in Ubuntu Universe. They could be the base. The needed packages are cpdb-libs, cpdb-backend-cups, and cpdb-backend-file. The package cpdb-backend-gcp is discontinued as Google Cloud Print got given up by Google. Thanks in advance. Till
Re: Request for Removal: Unmaintained libppd in Debian
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 components replacing cups-filters 1.x and we want to
stay with CUPS 2.x):
Source: libcupsfilters 2.x
--
Needs libcups2
- libcupsfilters2
o Depends:
+ libcupsfilters2-common (>= ${source:Version})
- libcupsfilters2-common
o Recommends:
+ libcupsfilters2 (>= ${source:Version})
o Breaks:
+ cups-filters (<< 2.0~)
o Replaces:
+ cups-filters (<< 2.0~)
- libcupsfilters-dev
o Depends:
+ libcupsfilters2 (= ${binary:Version})
Source: libppd 2.x
--
Needs libcupsfilters2, libcups2
- libppd2
o Depends:
+ libppd2-common (>= ${source:Version})
- libppd2-common
o Recommends:
+ libppd2 (>= ${source:Version})
- libppd-dev
o Depends:
+ libppd2 (= ${binary:Version})
- ppdc
o Depends:
+ libppd2-common (>= ${binary:Version})
o Breaks:
+ cups-ppdc
o Replaces:
+ cups-ppdc
o Provides:
+ cups-ppdc
Source: cups-filters 2.x
Needs libppd2, libcupsfilters2, libcups2
- cups-filters-core-drivers
o Depends:
+ bc
+ cups-ipp-utils
+ poppler-utils
o Breaks:
+ cups-filters (<< 1.13.0)
o Replaces:
+ cups-filters (<< 1.13.0)
- cups-filters
o Depends:
+ bc
+ ghostscript
+ poppler-utils
+ cups-filters-core-drivers (>= ${binary:Version})
o Provides:
+ foomatic-filters
+ foomatic-filters-beh
+ ghostscript-cups
o Recommends:
+ colord
o Suggests (or Recommends?):
+ printer-driver-braille
o Conflicts:
+ foomatic-filters
+ foomatic-filters-beh
+ ghostscript-cups
o Replaces:
+ foomatic-filters
+ foomatic-filters-beh
+ ghostscript-cups
Source: braille-printer-app 1.x
Needs: cups-filters 2.x, libppd2, libcupsfilters2, libcups2, libpappl1
- braille-printer-app
o Recommends:
+ liblouisutdml-bin | liblouis-bin
o Suggests:
+ antiword
+ docx2txt
+ foomatic-db-compressed-ppds | foomatic-db
+ imagemagick
+ lynx
- printer-driver-braille
o Recommends:
+ liblouisutdml-bin | liblouis-bin
o Suggests:
+ antiword
+ docx2txt
+ foomatic-db-compressed-ppds | foomatic-db
+ imagemagick
+ lynx
Source: cups-browsed 2.x
Needs: libppd2, libcupsfilters2, libcups2
- cups-browsed
o Pre-Depends:
+ init-system-helpers (>= 1.54~)
o Depends:
+ cups-daemon
+ lsb-base
o Recommends:
+ avahi-daemon
o Breaks:
+ cups-filters (<< 1.4.0~)
o Replaces:
+ cups-filters (<< 1.4.0~)
o Enhances: cups
There is no libfontembed any more. Its functionality is folded into
libcupsfilters. -> What has to beadded to libcupsfilters's dependencies
for that?
The API of libfontembed got discontinued/removed. There are actually no
packages using it.
There are not really many changes, as there was already a splitting of
the cups-filters source Debian package into binary packages. Some files
got split off cups-filters into the -common binary packages of the 2
libraries. The depencies shown here should handle this, please correct
if I am wrong.
libcupsfilters can be installed alone without the other 4 components, so
PPD file support can be easily discontinued/removed.
The upstream package braille-printer-app is intended to build without
libppd/PPD file support if one builds only the Printer Application and
not the classic driver, which is intended to be done in the future.
The binary Debian package braille-printer-app is also supposed to not
depend on libppd. If needed, I will create a braille-common binary
Debian package to manage this.
In a future version cups-browsed upstream will be a Printer Application
which has no PPD file support, not even internally and then not depend
on libppd any more.
In case of an update of a Debian installation with CUPS 2.x and
cups-filters 1.x, all installed binary packages will get updated and
libppd and printer-driver-braille newly installed if needed. After that
one should be able to uninstall everything which contains PPD support
(simply "apt remove libppd2") and so get a smooth transition to the
future PPD free CUPS 3.x/CUPS Snap environment.
Please also tell me additional dependencies have to be added to the
scheme above for correctly coping with libppd0/libppd-legacy on the system.
Till
Re: Request for Removal: Unmaintained libppd in Debian
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 policy 10.1 in mind². Also, gpr needs an according adjustment. I would take care of that as well. Status update: The renamed src:libppd package was just uploaded as src:libppd-legacy. Great, thank you. [...] @Till: There are some things you could start working on: First, you could upload your libppd as soon as -legacy was ACCEPTED. As I understand things, there's no need to RM the old one, although it could make things more obvious to observers. 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. Also, as I prefer to be open in what I do, and especially here where we're doing something rather unsual: Let's give some clues to those who are disturbed once they ever discover this process. In other words, I'd appreciate if you could add a transition notice in the descriptions of your packages, until trixie, something like "Debian used to ship a different software as libppd0, that one is now provided via libppd-legacy-dev and libppd-legacy1". I will add appropriate info to the package. So I should use the package descriptions (in debian/control) for that? If you want to upload *all* your new stuff to Debian - and I haven't understood yet what is preventing you from doing so: What prevented me from doing so was Thorsten telling me that it is to short before Bookworm. So I suggested this Ubuntu-only roadmap in an earlier e-mail in this thread. We can naturally also: 1. Upload it into Debian right away and let it be the cups-filters of Bookworm. For this note at first that we are not required to switch into the New Architecture by that. Including all the 5 parts we have the same functionality as before, especially classic CUPS filters and PPD file support for CUPS 2.x. Especially for now I have developed using libcups2 and not libcups3. From libcups2 nothing PPD-supporting is used so that a later transition to libcups3 will be easy. All the code stems either from the former cups-filters, libcups, and the ppdc/ subdirectory of the CUPS (2.x) source (PPD compiler). So the risk of a severe design flaw is low. There can be bugs still, but we are not yet releasing Bookworm but still going through a testing and debugging process. I also expect to do final (2.0.0) releases of the components within 1-2 months. So replacing cups-filters 1.x by all the the components of cups-filters 2.x should be smooth. We sync then to Ubuntu. 2. Upload the new packages to experimental and sync to Ubuntu from experimental. This way we skip Bookworm and promote to unstable when unstable opens for the next Debian development cycle. I would also send a message like "News from the CUPS printing in Debian" to debian-devel where you, among all the other things, would mention the libppd situation, and how we resolved it. This would also be of help in my upcoming discussiong with the release team: My change to libppd implies a transition, even if it's about just one package (gpr). No problem to send such a message. So finally about the time frame: Transition freeze will be in less than two weeks, so there is not much time to lose. Unless they are willing to grant an exception for that minimal situation, but I'd prefer to not exercise that. I think I will be able to do the Debian packaging of the 5 components by then. Till
Re: Request for Removal: Unmaintained libppd in Debian
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 these in /usr/lib/x86*/
(...)
Only clashes would be /usr/lib/libppd.so and
/usr/lib/libppd.a (are these files really needed?), so we need to mark a
comflict and rename thelegacy libppd-dev package lippd-legacy-dev or
libppd0-dev.
As I had to learn the hard way, conflicting packages are not enough,
policy 10.1 forbids identical filenames anywere across the archive. So
I've renamed the library as well.
Current packages content is now:
You have to use the binary package name libppd-legacy1 here, as you have
raised the soname to 1: libppd-legacy.so.1.0.1
libppd-legacy0:
/usr/lib/x86_64-linux-gnu/libppd-legacy.so.1
/usr/lib/x86_64-linux-gnu/libppd-legacy.so.1.0.1
/usr/share/doc/libppd-legacy0/changelog.Debian.gz
/usr/share/doc/libppd-legacy0/changelog.gz
u/sr/share/doc/libppd-legacy0/copyright
libppd-legacy-dev:
/usr/include/ppdenums.h
/usr/include/ppd.h
/usr/include/ppdmacros.h
/usr/lib/x86_64-linux-gnu/libppd-legacy.a
/usr/lib/x86_64-linux-gnu/libppd-legacy.so
/usr/share/doc/libppd-legacy-dev/AUTHORS
/usr/share/doc/libppd-legacy-dev/changelog.Debian.gz
/usr/share/doc/libppd-legacy-dev/changelog.gz
/usr/share/doc/libppd-legacy-dev/copyright
/usr/share/man/man3/ppd_check_option_is_marked.3.gz
/usr/share/man/man3/ppd_emit_to_file.3.gz
/usr/share/man/man3/ppd_file_free.3.gz
/usr/share/man/man3/ppd_file_new.3.gz
/usr/share/man/man3/ppd_find_choice.3.gz
/usr/share/man/man3/ppd_get_num_conflicts.3.gz
/usr/share/man/man3/ppd_get_page_length.3.gz
Next step is testing an adjusted gpr, and before developing a test plan.
Otherwise, upload should happen in about three days, once the libppd
2:0.10-9 has migrated to testing.
OK, this way it should all work.
Thank you very much.
Till
Re: Request for Removal: Unmaintained libppd in Debian
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 original API. They replaced the API by a glib-based
one. To keep gpr happy one would need to create wrapper functions with the
new API to the outside and calling the original functions in libppd. One
would use the code of the legacy libppd, remove each API-function's (there
are ~20 API functions) inner workings and replace them by calls of functions
in the current libppd. The resulting code could be put together all into one
pp/ppd-legacy.c file.
I do not actually know how much work this would be and whether it is
worthwhile for the actual number of users of gpr or ppdfilt to do this work.
Errrm. I mean, if you got a lot of time to kill, or are thrilled to do
this, or at least could earn an academic degree from such work ... but
perhaps let's rather forget the idea?
Unfortunately I do not have a lot of time to kill ...
[ ppdfilt ]
and I was wondering where your toolset will provide an replacement as
well. While I could continue to ship legacy libppd with only this binary
package, it might be a good opportunity to drop this one and therefore
complete libppd as well. It seems ppdfilt is used by gpr and
printfilters-ppd ("filters from the GNUlpr printing system"), another
thing from old times. Both are maintained by A Mennucc1, we should take
them into the loop at some time.
As I found out in the meantime (the dusty corners): printfilters-ppd has
dropped out of testing almost six years ago because of mpage removal
and some other issues. And nobody bothered to resolve the situation -
which I admit is not a trivial task to do.
In other words, no need to take care of printfilters-ppd.
Good to know ...
Probably most users had already switched to Foomatic, partially also
guided by their distro, already before it adopted CUPS ...
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 ...
Go indeed (2). It's a step not too big. There is however still a little
obstacle: If you'll introduce your libppd-dev later, none of its file
names may collide with my libppd-legacy-dev. That will be your problem,
not mine - still now is a good time to prevent this from happening.
That's why I asked for your preliminary libppd packaging: Do we share
file names, especially in /usr/include/ and /usr/share/man/?
My current step to do is preparing the libppd package. As a preview we
can simply look at what "make install" actually installs:
--
$ ls -R
.:
usr
./usr:
include lib share
./usr/include:
ppd
./usr/include/ppd:
ppdc.h ppd-filter.h ppd.h
./usr/lib:
libppd.a libppd.la libppd.so libppd.so.2 libppd.so.2.0.0 pkgconfig
./usr/lib/pkgconfig:
libppd.pc
./usr/share:
doc ppdc
./usr/share/doc:
libppd
./usr/share/doc/libppd:
ABOUT-NLS CHANGES-1.x.md CONTRIBUTING.md DEVELOPING.md NOTICE
AUTHORSCHANGES.md COPYING INSTALLREADME.md
./usr/share/ppdc:
epson.h font.defs hp.h label.h media.defs raster.defs
$
--
This gives for libppd2:
/usr/lib/libppd.so.2.0.0
/usr/lib/libppd.so.2
for libppd-dev:
/usr/include/ppd/ppd.h
/usr/include/ppd/ppd-filter.h
/usr/include/ppd/ppdc.h
/usr/lib/libppd.so
/usr/lib/libppd.a
/usr/lib/pkgconfig/libppd.pc
for libppd2-common:
/usr/share/ppdc/*
For the -dev packages the headers (*.h) do not clash as the legacy
libppd puts the files directly into /usr/lib and the current libppd uses
/usr/lib/ppd/. Only clashes would be /usr/lib/libppd.so and
/usr/lib/libppd.a (are these files really needed?), so we need to mark a
comflict and rename thelegacy libppd-dev package lippd-legacy-dev or
libppd0-dev.
The legacy libppd has no ppdc stuff and the current libppd no ppdfilt,
so there are no further conflicts.
Till
Re: Request for Removal: Unmaintained libppd in Debian
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 admit I have no idea whether it's technically possible, doable in time, and some other constraints. Principally, one can have libraries of different API generations installed on the same system, to allow old apps to continue to work. For this we have the soname, a number which is increased with each new API version. As the legacy libppd has soname 0 and the current libppd has soname 2 (and I even could still bump it again) it should work. We need to rename the source package and -dev file to things like "libppd0..." or "libppd-legacy..." though. [ Removing lpr*-based printing from Debian ] 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 right now given the bookworm freeze timeline. OK, let us aim for complete LPD/LPR/LPRng/legacy-libppd/gpr removal for bookworm+1 ... Having looked a few other fairly dusty corners I'm even more inclined to go that way, and for a brief moment considered pushing this by writing an e-mail to debian-devel right now. But it's madness - to begin with, I don't have an idea which packages will be affected by this. Also, I'm not really into printing, so I doubt I have the competence to drive the process. Write the mail to Debian Printing Team or you have already written it as this list is CCed in this thread. To find out which packages are really affected, go through these packages with apt rdepends NAME With NAME being binary packages. We need to investigate the binary packages of these source packages: lpr, lpd, lprng, libppd, ppdfilt, gpr, ... Also the found reverse dependencies need to be checked for reverse dependencies themselves. I expect this is only a small amount of packages and some could be even rebuilt without LPD/LPR/LPRng support. Thoughts on this by other folks in the loop (or are you already bored?) Unfortunately, many people get bored by printing-related subject matter, see the audience of my last OpenPrinting micro-conference here: https://openprinting.github.io/OpenPrinting-News-November-2022/#openprinting-micro-conference-on-linux-plumbers-2022---the-recordings Till
Re: Request for Removal: Unmaintained libppd in Debian
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 the changes only after that
release so that they are in place one Debian release later?
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.
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.
You mean both legacy libpd and current libppd? With main binary packages
being libppd0 and libppd2? Renaming legacy source package libppd to
libppd0, legacy dev header binary package to libppd0-dev?
Related, looking deeper into printing in Debian: While we are too close
to the bookworm release to do huge changes - it might be an idea for the
next development cycle to drop lpr-based printing support completely.
I am in favor of this, too. All the LPR/LPD/LPRng and related stuff is
unmaintained and probably buggy, even with security bugs, and nobody
cares of this. It gets also in the way of future development as we
currently see with libppd.
Not that I'm a huge fan of CUPS (although in general it works), but
lprng itself is orphaned to start with, other maintainers are more or
less MIA, and all the code is very old and likely full of bugs.
Yes, therefore better do away with his.
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 right now given the bookworm freeze timeline.
OK, let us aim for complete LPD/LPR/LPRng/legacy-libppd/gpr removal for
bookworm+1 ...
Till
Re: Request for Removal: Unmaintained libppd in Debian
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 it for good, and continue gpr ...
That's pretty exciting, and I didn't dare to think this was an option.
So if this works ...
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
glib-based one. To keep gpr happy one would need to create wrapper
functions with the new API to the outside and calling the original
functions in libppd. One would use the code of the legacy libppd, remove
each API-function's (there are ~20 API functions) inner workings and
replace them by calls of functions in the current libppd. The resulting
code could be put together all into one pp/ppd-legacy.c file.
I do not actually know how much work this would be and whether it is
worthwhile for the actual number of users of gpr or ppdfilt to do this work.
So I would suggest
4. Replace the legacy libppd by my modern libppd
... certainly put that in front of the list.
Still not sure, see above.
The gpr Debian package only needs a no-change rebuild to use libppd2
instead of libppd0.
That I can do.
In Debian we have to remove the legacy libppd then and put the modern
one into its place.
Agreed on libppd-dev and libppd0.
However, src:libppd also ships
| Package: ppdfilt
| Architecture: any
| Depends: ${misc:Depends}, ${shlibs:Depends},
| Section: utils
| Description: filter that inserts printer specific commands into print jobs
| ppdfilt is a filter program designed to be used within a filter
| script or from the command line tool to insert printer specific
| commands to a PostScript print job. This can be used to tell the printer
| to duplex or staple the print job, or tell it what paper tray to draw
| paper from. In the GNULpr printing environment, users do not call ppdfilt
| directly, but its features are accessed by using 'lpr' or 'gpr' (see)
and I was wondering where your toolset will provide an replacement as
well. While I could continue to ship legacy libppd with only this binary
package, it might be a good opportunity to drop this one and therefore
complete libppd as well. It seems ppdfilt is used by gpr and
printfilters-ppd ("filters from the GNUlpr printing system"), another
thing from old times. Both are maintained by A Mennucc1, we should take
them into the loop at some time.
One would treat ppdfilt the same way as the legacy libppd, replace the
core functionality of the executable by calling a function in the
current libppd, in this case ppdFilterPSToPS() and include this
executable in the libppd package.
For these changes I have put the priority low, as I want to get the new
cups-filters into Ubuntu at first (see my roadmap in my earlier mail). I
have also already put ab a request for Ubuntu removing the legacy libppd
and gpr:
https://bugs.launchpad.net/ubuntu/+source/gpr/+bug/2000411
Probably your (2) could perhaps be the way to go?
Till
Re: Request for Removal: Unmaintained libppd in Debian
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 needs the new cups-filters generation. So I will switch over Ubuntu-only for now and everything gets a rehearsal on Ubuntu 23.04 (probably only cups-filters 2.x and perhaps also CPDB-based print dialogs, New Architecture optional via CUPS Snap and PPA) and on Ubuntu 23.10 (New Architecture using CUPS Snap 2.4.x or 2.5.x, cups-filters 2.x, CPDB-based print dialogs, G-C-C with new Printers module, printer drivers as Printer Application Snaps). So both Ubuntu 23.04 LTS and the next Debian release will run with full New Architecture (Ubuntu with CUPS Snap 3.x, Debian with CUPS DEB packages 3.x), with the components already having being tested, debugged, and refined for several months (in the "small" Ubuntu releases). So we leave the upcoming Debian completely untouched (or maintenance/hardware-enablement-only) in terms of printing, to keep it as stable as possible and switch only over when all is already well-tested and established by Ubuntu (and I got told "It works better than Windows/Mac." on several more conferences ...). What concerns legacy libppd would mean that we could kill off this old stuff in Ubuntu only, simply removing it on syncing it from Debian any more (Seb, WDYT?) and for Debian we only need to decide on how to proceed once the release is out (when will this be?) and development has re-opened for the next Debian release. WDYT? Till
Re: Request for Removal: Unmaintained libppd in Debian
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 investigated ... The API adaption looks like rather easy, adding only some extra *.h files to my modern libppd. My modern libppd is a very sophisticated and complete rip-out of the PPD support functionality of CUPS, to conserve this functionality for CUPS-driver retro-fitting Printer Applications when it goes away in CUPS 3.x. The original CUPS APIs are mainly conserved, only a few functions renamed. The legacy libppd is also a rip-out of CUPS' PPD support functionality, but not that sophisticated and done 20 years ago to make CUPS' PPD support functionality available to LPD/LPR/LPRng users. It got rarely used, probably there were more of these LPD/LPR/LPRng users using my Foomatic instead. 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 it for good, and continue gpr ... So I would suggest 4. Replace the legacy libppd by my modern libppd As described above we add an "API adapter", some *.h files with macros to "translate" old names to new names and a *.c file with wrapper functions for changes between the APIs of CUPS 1.x and CUPS 2.x. The user will need libppd and libcups then (some of libppd's functions are not actually having to do with PPDs and so in my CUPS setup I have left them to be supplied by libcups (but using libcups does not require to run a CUPS daemon). When packaging, my libppd will have epoch 3 and so considered newer than legacy libppd, so updates should simply replace the old library by the new one and new installations of libppd-dev grab the new version. The gpr Debian package only needs a no-change rebuild to use libppd2 instead of libppd0. In Debian we have to remove the legacy libppd then and put the modern one into its place. WDYT? Till
Re: Request for Removal: Unmaintained libppd in Debian
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 that as GUI/printer setup tool the totally unmaintained gpr, with unattended severe bug, is used. My general recommendation is to switch to CUPS, the only fully maintained print environment. CUPS itself is continued to be developed by original author Michael Sweet, the integration, cups-filters, Foomatic, Common Print Dialog Backends is done by me. Also integration in GUI's is done by me, organizing appropriate Google Summer of Code projects for this. For all this I have a full-time employment at Canonical. So further maintenance is assured. Another possibility to print, without CUPS, are the Printer Applications, emulations of driverless IPP printers. With these the user does not need to deal with PostScript. They take PDF or PWG/Apple Raster as input. The PostScript Printer Applications supports ALL PostScript printers (you can add PPD files to it if needed). So the user's client software does not need to deal with PPD files (I assume on non-CUPS spoolers, like LPD, PPD files and legacy-libppd are only used for PostScript printers). The Printer Applications are also developed by Michael Sweet and me and are also part of OpenPrinting and they use my new libraries. The user could send the jobs to a Printer Application (is there an IPP backend for LPD/LPRng/lpr?). Modern desktop applications also produce PDF and not PostScript as print output, so best is to print with CUPS and/or Printer Applications with it. Also practically all modern printers are (driverless) IPP printers. CUPS just prints on them, for using any print environment which does not support IPP 2.x, one would need any fallback, like PostScript or PCL, which would need a driver again and also is not available in cheaper printer models. This all means that if a user opts for LPR/LPD/LPRng + PostScript/PPD files as printing environment, they will have a VERY special case. Extreme resource confinement, PostScript printer, no security requirements. This can only be a very small amount of users. In the existing user base there can also be users who are running a setup for decades, which simply works for them and so they do no modernize and rely on Debian to do at least a basic maintenance on it. One would need to find and ask these users, to find out why tihey do not switch to CUPS. For these few users I do not want to add such long piece as "openprinting-" to the names of my packages for the eternity, especially as this old system will fade out and all printers which worked with that, also work with CUPS and/or Printer Applications, even in a more comfortable and user-friendly way. So (3) has disqualified. I would prefer (1), but (2) will be a good compromise to keep these legacy libppd users happy. 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 one Debian release later? That later Debian release MUST adopt cups-filters 2.x as it will use CUPS 3.x, which has abolished PPD support and requires the use of Printer Applications for non-IPP-driverless legacy printers. Doing this switchove only after the relase also should give time that everything which needs to go through NEW will have enough time. In Ubuntu I will switch to cups-filters 2.x with my libppd immediately (23.04 Lunar Lobster) and ditch the old libppd and gpr there (they are only in Universe), not adopting the renamed legacy libppd. So I will package my libppd with epoch 3 and let it Breaks: and Conflicts: with equally-named packages of a lower epoch. Am I right? Do I also have to set Replaces: in this situation? WDYT about this? 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. Till On 23/12/2022 16:52, Christoph Biedl wrote: 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 libppd (I'll use the name "legacy libppd" from now on for clarity) in Debian was that package being in dire need of attention, again. Following Debian's social contract, my interest was users of that package are not harmed by its removal from the next release. Besides that, I have no particular connection to it, in other words: Once I'm convinced that package's time h
Request for Removal: Unmaintained libppd in Debian
Hi, I am Till Kamppeter, leader of the OpenPrinting project (http://www.openprinting.org/). Here we maintain practically everything printing-related, CUPS, cups-filters, Foomatic, Printer Applications, ... So I am responsible for printing in Linux and similar (POSIX-style) operating systems. Recently I have released the second generation of cups-filters: https://openprinting.github.io/cups-filters-Second-Generation-First-Beta-Release/ https://openprinting.github.io/OpenPrinting-News-November-2022/ One main feature of it is that I have separated the PPD file support completely out of libcupsfilters and put it into a new library which I have called libppd (did not know that there already existed a libppd, see below). I have done this as with CUPS 3.x we are abolishing PPD files and classic CUPS drivers: https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning This we call the "New Architecture". The new cups-filters is also split into separate upstrewam repositories, so libcupsfilters, libppd, cups-filters, braille-printer-app, and cups-browsed are independent projects, indpendent source packages. Now I have started to split the old source Debian package into 5 new source Debian packages, one being named lbppd and producing the binary packages libppd2 and libppd-dev (and perhaps some more, like libppd-utils). In the mean time, before I uploaded anything to Ubuntu, one of our GSoC 2023 candidates has tried to build the new cups-filters 2.x packages during our selection/onboarding process. They grabbed the source of cups-filters 2.0b1 right away and tried to fulfill the dependencies by Debian packages, actually finding a libcupsfilters (the wrong one, it is 1.x) and libppd (the wrong one, this old thingy we come to later here) and complained that they were not able to build cups-filters. So I got aware that there was a libppd in the repositories which I did not know about. So I entered $ apt info libppd0 and got Package: libppd0 Version: 2:0.10-8 Priority: optional Section: universe/libs Source: libppd Origin: Ubuntu Maintainer: Ubuntu Developers Original-Maintainer: Christoph Biedl Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 67.6 kB Depends: libc6 (>= 2.7) Homepage: http://sourceforge.net/project/showfiles.php?group_id=3800_id=11729 Download-Size: 21.7 kB APT-Sources: http://at.archive.ubuntu.com/ubuntu kinetic/universe amd64 Packages Description: postscript PPD file library PostScript was designed as a device independent language. To be able to access device specific features like selecting different paper trays and turning on different imaging models, each printer vendor supplies a PostScript Printer Definition or PPD file. This library reads those PPD files and provides functions that allow a program to modify PostScript print jobs to access these special features. and as a next step I followed the link under "Homepage:" and this revealed that this libppd was unmaintained for 20 (!) years, last touched in 2002! I have started working as the Linux printing guru since mid-2000 (and was one of the founders of OpenPrinting in 2001): https://openprinting.github.io/history/ and in all the time I never, ever heard about this package! No questions, no bugs, nothing! So I am very confident that there is nobody using this package and if it goes away, nobody will complain. If there is actually some other package using this, it is probably also unmaintained for at least a decade and nobody uses it. Therefore I would like to have this package removed, to avoid the name clash of my libppd with this old, unmaintained package. 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. Thanks in advance Till
First beta of the second generation of the Common Print Dialog Backends released!
Hi, We are now releasing the first beta of the second generation of the Common Print Dialog Backends (CPDB). As part of making everything ready for the New Architecture of printing we have finally added CPDB support to the print dialogs of the major desktop environments/GUI toolkits, GNOME/GTK and KDE/Qt. This was done in Gaurav Guleria's GSoC project and in the course of his work on the print dialogs he also did a lot of improvements on the CPDB framework, mainly due to missing features but also to work well in a PPD-less world. The components we are currently maintaining got all updated and released as version 2.0b1: - **cpdb-libs:** The central library package implementing both ends of the D-Bus interface (backend = server, frontend = client) and the APIs for frontends and backends. - **cpdb-backend-cups:** The CUPS backend. It allows the print dialogs (frontends) to print with CUPS. It polls the list of available printers (queues) from CUPS and also the option/setting list for a selected printer, and it passes on jobs with option settings to CUPS. It uses the current APIs of libcups for that and does not interact with PPD files at all, so that porting the backend to CUPS 3.x will be easy. - **cpdb-backend-file:** This backend allows the print dialogs to print into a file. As most print dialogs have already their own functionality for that, this backend will probably not be needed in production. We have it at least for sake of completeness, but it is also useful as code example for backend developers. We especially added support for human-readable (user interface) strings for option and setting names, better support for media sizes, especially also supporting more than one margin variant for the same page size. asynchronous functions to query printer details, cpdb-libs completely inependent of libcups, ... and many bug fixes. Here we go: https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-First-Beta-Release/ There are also GitHub discussions set up for each release now. Till
First beta the second generation of cups-filters released!
Hi, I have done another cups-filters release now! But now it is a special on: After more than 2 years of hard work and following the needs of the New Architecture for printing and scanning, of the Printer Applications, of the abolishment of PPD file use in CUPS 3.x, ... I have now completed cups-filters 2.x, the second generation of cups-filters! The cups-filters project is now split into several parts, similar to CUPS on its transition to the 3.x series. This way the PPD file support for retro-fitting legacy printer drivers is complete separated (in libppd) from the core filter code and so the filters (as filter functions in libcupsfilters) are conserved into the PPD-less future and can be used in Printer Applications for example. This way we can continue development on the filter code and have the PPD support code in maintenance mode for the retro-fitting Printer Applications. There are the following parts now: - libcupsfilters: The central library with the filter functions and some useful functions for printer drivers, human-readable strings and translation handling for IPP attributes, … It does not contain any support for PPD files. - libppd: PPD file support library providing the complete support for PPD files from libcups (2.x and earlier, see ppd/ppd.h), the CUPS PPD compiler and utilities (ppdc, see ppd/ppdc.h) and functions to convert PPD Options into IPP attributes, to add PPD file support to the filter functions of libcupsfilters, to handle collections of PPD files, … This library is only for legacy PPD and driver support, it should not motivate anyone to create new PPD files! - cups-filters: Legacy CUPS filter/backend executables for CUPS 2.x. Uses both libcupsfilters and libppd. Any XXXtoYYY filters, foomatic- rip, driverless, … - braille-printer-app: The Braille embosser driver code plus Chandresh Soni’s GSoC work to turn this code into a Printer Application. - cups-browsed: Daemon to automatically create local print queues for network printers and remote CUPS queues and to create printer clusters. Will be turned into a Printer Application later (GSoC project?). Here we go: https://openprinting.github.io/cups-filters-Second-Generation-First-Beta-Release/ There are also GitHub discussions set up for each release now. Till
Re: cups-filters 1.28.16 released!
And do not forget to add libexif-dev to the build dependencies, otherwise the changes will not work. Till On 24/08/2022 15:21, Till Kamppeter wrote: Hi, I have released cups-filters 1.28.16 now, with the following changes: - imagetoraster, imagetopdf, libcupsfilters: Added support for reading the resolution of an image from its EXIF data when loading it. This way we get the image reproduced in its original size with "print-scaling=none" (Issue #362). - libcupsfilters: Replaced deprecated data types uint16 and uint32. The function to read TIFF image files via libtiff in cupsfilters/image-tiff.c uses the deprecated types uint16 and uint32. The replacements for these types are uint16_t and uint32_t. Bug fix release, to make images be printed in their original size with "print-scaling=none" and to not use deprecated data types for reading TIFF images. Please release this on Debian so that it can be synced into Ubuntu. Thanks in advance. Till
cups-filters 1.28.16 released!
Hi, I have released cups-filters 1.28.16 now, with the following changes: - imagetoraster, imagetopdf, libcupsfilters: Added support for reading the resolution of an image from its EXIF data when loading it. This way we get the image reproduced in its original size with "print-scaling=none" (Issue #362). - libcupsfilters: Replaced deprecated data types uint16 and uint32. The function to read TIFF image files via libtiff in cupsfilters/image-tiff.c uses the deprecated types uint16 and uint32. The replacements for these types are uint16_t and uint32_t. Bug fix release, to make images be printed in their original size with "print-scaling=none" and to not use deprecated data types for reading TIFF images. Please release this on Debian so that it can be synced into Ubuntu. Thanks in advance. Till
Re: gutenprint_5.3.4.20220624T01008808d602-1_source.changes ACCEPTED into unstable
Thorsten, I would like to know why you are updating the Debian package of Gutenprint to this upstream GIT snapshot (the version number suggessts that this is a snapshot and not a release). Especially also whether I need to also update the Gutenprint Printer Application Snap. Does this fix an important bug, add support for new printer models, ...? Could you also put the reasoning for an update into the debian/changelog message in the future? Till On 17/08/2022 11:20, Debian FTP Masters wrote: > > > Accepted: > Format: 1.8 Date: Tue, 16 Aug 2022 20:10:00 + Source: gutenprint Architecture: source Version: 5.3.4.20220624T01008808d602-1 Distribution: unstable Urgency: medium Maintainer: Debian Printing Group Changed-By: Thorsten Alteholz Changes: gutenprint (5.3.4.20220624T01008808d602-1) unstable; urgency=medium . * Update to new upstream version 5.3.4.20220624T01008808d602. Checksums-Sha1: 4e299fc4928fe880347a63c1585add52861cbd7d 3186 gutenprint_5.3.4.20220624T01008808d602-1.dsc 989e85fae158cc04249f9092ce17587f7a6358fc 5345892 gutenprint_5.3.4.20220624T01008808d602.orig.tar.xz 6e8788d412333e928eaa8ebbd369c824fa3f312d 94852 gutenprint_5.3.4.20220624T01008808d602-1.debian.tar.xz 09edbf51b3dbc46d7403636c00d1e0586e787f2a 21599 gutenprint_5.3.4.20220624T01008808d602-1_amd64.buildinfo Checksums-Sha256: 09d5f35b112bfc2ef10562474723a64586114b56ab8bbede0783c237587183c0 3186 gutenprint_5.3.4.20220624T01008808d602-1.dsc ef514d4ca567b5871cfe7697127bee2c14d5d71d7fbc68d8fee96b0faaed90e7 5345892 gutenprint_5.3.4.20220624T01008808d602.orig.tar.xz a76469994087ab7325eb88f05dd101bb2295bd818e5e2ff6d324e95fab90afbf 94852 gutenprint_5.3.4.20220624T01008808d602-1.debian.tar.xz f0d5d98f39531713e61d9a7f71e70c5b6d6e8bbe6311e25719b6e6d5472a1158 21599 gutenprint_5.3.4.20220624T01008808d602-1_amd64.buildinfo Files: 3f7dfa655d4294ff52ba14d929f79852 3186 graphics optional gutenprint_5.3.4.20220624T01008808d602-1.dsc c40d554aa1c36a954775c9775ac18998 5345892 graphics optional gutenprint_5.3.4.20220624T01008808d602.orig.tar.xz 26e15409e8a556394ba181cb0eedff86 94852 graphics optional gutenprint_5.3.4.20220624T01008808d602-1.debian.tar.xz 9a8f47149e82d078993da138dda039b7 21599 graphics optional gutenprint_5.3.4.20220624T01008808d602-1_amd64.buildinfo > > > Thank you for your contribution to Debian. >
Re: HPLIP
The new version of the HPLIP Printer Application (with HPLIP 3.22.6) is available in the Snap Store now (https://snapcraft.io/hplip-printer-app). Thanks again Thorsten, for your Debian package update. Till On 16/08/2022 20:17, Thorsten Alteholz wrote: Hi Till, On 11.08.22 20:07, Till Kamppeter wrote: could you update the Debian package of HPLIP to the newest version (3.22.6?)? I did now and had to add a new patch due to stricter checks of gcc12 as well. Thorsten
Re: HPLIP
Thank you very much. I am test-building the new HPLIP Printer Application Snap right now. The Ubuntu package will be auto-synced with Debian until tomorrow. Till On 16/08/2022 20:17, Thorsten Alteholz wrote: Hi Till, On 11.08.22 20:07, Till Kamppeter wrote: could you update the Debian package of HPLIP to the newest version (3.22.6?)? I did now and had to add a new patch due to stricter checks of gcc12 as well. Thorsten
HPLIP
Hi, could you update the Debian package of HPLIP to the newest version (3.22.6?)? We have Feature Freeze at Ubuntu in 2 weeks and it would be great to have a newer HPLIP included. Thanks in advance. Till
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On 27/06/2022 19:26, Gareth Evans wrote: "testq" already exists, so I changed the queue name to avoid any potential caching effects etc in case that were possible. $ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. lpadmin: Unable to open PPD "/tmp/075ef62bac756": Missing PPD-Adobe-4.x header on line 0. That's the first time I've seen this error message. Seems that it is able to access the printer for sending a job to it (done as user "lp"?) but not to poll the printer's capabilities via IPP (when running the "lpadmin" command).
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
And are you able to print now? Till On 27/06/2022 17:57, Gareth Evans wrote: However that is when the laptop is connected to 5GHz wifi. If I change to the 2.5GHz connection (same router) on which (router and frequency) the printer is connected: $ avahi-browse -rt _ipp._tcp + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local = wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local hostname = [mfcl2740dw.local] address = [192.168.0.14] port = [631] txt = ["print_wfds=T" "UUID=e3248000-80ce-11db-8000-30055ca3d8ec" "PaperMax=legal-A4" "kind=document,envelope,label" "URF=W8,CP1,IS4-1,MT1-3-4-5-8,OB10,PQ4,RS200-300-600,V1.3,DM1" "rfo=ipp/faxout" "TBCP=F" "Transparent=T" "Binary=T" "PaperCustom=T" "Scan=T" "Fax=T" "Duplex=T" "Copies=T" "Color=F" "usb_CMD=PJL,PCL,PCLXL,URF" "usb_MDL=MFC-L2740DW series" "usb_MFG=Brother" "priority=25" "adminurl=http://mfcl2740dw.local./net/net/airprint.html; "product=(Brother MFC-L2740DW series)" "ty=Brother MFC-L2740DW series" "note=" "rp=ipp/print" "pdl=application/octet-stream,image/urf,image/pwg-raster" "qtotal=1" "txtvers=1"] $ avahi-browse -rt _uscan._tcp $
HPLIP 3.22.4 is out
Hi, HPLIP 3.22.4 got released: https://developers.hp.com/hp-linux-imaging-and-printing/gethplip?language=ko I am grateful when the Debian package could soon be updated, so that I can update the HPLIP Printer Application Snap in the Snap Store. Till
cups-filters 1.28.15 released!
Hi, I have released cups-filters 1.28.15 now, with the following changes: - pdftops: In pdftops identify old LaserJets more precisely for working around PostScript interpreter bugs, older printers need Poppler, newer models need Ghostscript (Ubuntu bug #1967816). Bug fix release, to make all HP LaserJet PostScript printers correctly work. Please release this on Debian so that it can be synced into Ubuntu. Thanks in advance. Till
Bug#1008997: cups: impossible to print on hp envy 5536 from sid
Now run the command driverless and, if you get the URI, run lpadmin -p envy -E -v ipp://localhost:6/ipp/print -m everywhere Does it work now? Till On 06/04/2022 11:28, alain wrote: Package: cups Version: 2.4.1op1-2 Followup-For: Bug #1008997 X-Debbugs-Cc: compte.perso.de-al...@bbox.fr alain@sid:~$ sudo dpkg -l ipp-usb Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi- installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ NomVersion Architecture Description +++-==---=== ii ipp-usb0.9.20-1 amd64Daemon for IPP over USB printer support alain@sid:~$ sudo systemctl status ipp-usb ● ipp-usb.service - Daemon for IPP over USB printer support Loaded: loaded (/lib/systemd/system/ipp-usb.service; static) Active: active (running) since Wed 2022-04-06 11:18:17 CEST; 7min ago Docs: man:ipp-usb(8) Main PID: 66418 (ipp-usb) Tasks: 11 (limit: 38313) Memory: 15.5M CPU: 52ms CGroup: /system.slice/ipp-usb.service └─66418 /sbin/ipp-usb udev avril 06 11:18:17 sid systemd[1]: Started Daemon for IPP over USB printer support. alain@sid:~$ lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 004: ID 1b1c:1b2e Corsair Corsair Corsair Gaming M65 Pro RGB Mouse Bus 005 Device 003: ID 1b1c:1b3d Corsair Corsair Corsair Gaming K55 RGB Keyboard Bus 005 Device 002: ID 03f0:e807 HP, Inc HP Webcam HD 4310 Bus 005 Device 006: ID 03f0:c311 HP, Inc ENVY 5530 series Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0951:16a4 Kingston Technology HyperX 7.1 Audio Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.4.1op1-2 ii cups-common2.4.1op1-2 ii cups-core-drivers 2.4.1op1-2 ii cups-daemon2.4.1op1-2 ii cups-filters 1.28.13-1 ii cups-ppdc 2.4.1op1-2 ii cups-server-common 2.4.1op1-2 ii debconf [debconf-2.0] 1.5.79 ii ghostscript9.56.0~dfsg-1 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.33-7 ii libcups2 2.4.1op1-2 ii libgcc-s1 12-20220319-1 ii libstdc++6 12-20220319-1 ii libusb-1.0-0 2:1.0.25-1 ii poppler-utils 22.02.0-3 ii procps 2:3.3.17-7+b1 Versions of packages cups recommends: ii avahi-daemon 0.8-5 ii colord1.4.6-1 Versions of packages cups suggests: ii cups-bsd 2.4.1op1-2 pn cups-pdf pn foomatic-db-compressed-ppds | foomatic-db pn smbclient ii udev 250.4-1 -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd
Bug#1008997: further information
First step is to go to http://www.openprinting.org/ There you scroll down and find a link to the "Driverless Printers" list. Click "Browse". You get onto https://openprinting.github.io/printers/ into the search field enter "Envy 553". The last digit does not matter. Different last digits usually only mean different power plugs for the different destination countries. So your printer supports AirPrint, one of the driverless IPP standards. Your printer's Wi-Fi is flaky, so use IPP-over-USB. Keep the printer connected to USB and install the "ipp-usb" package. Having done this your printer should appear already in the print dialogs of many applications. If not, create a driverless print queue: First, run driverless You will get an URI for your printer, most probably ipp://localhost:6/ipp/print Create a driverless queue with this URI: lpadmin -p envy -E -v ipp://localhost:6/ipp/print -m everywhere Now all your apps should show your printer with queue name "envy". Can you print on this queue? Till P. S.: Avoid HPLIP if you do not REALLY need it.
cups-filters 1.28.14 released!
Hi, I have released cups-filters 1.28.14 now, with the following changes: - pdftopdf: Correct the output when suppressing auto-rotation (option "nopdfAutoRotate"). Depending on the situation pages got cropped in the wrong orientation or de-centered. - pdftopdf: Correct the output when the "orientation-requested" or the "landscape" option is supplied. Output could be de-centered (Issue #456), portrait-oriented pages be wrongly cropped and division of the output page into cells for N-up done in the wrong orientation. - rastertopdf: In PCLm output mode the filter failed to generate PCLm if the printer has no "pclm-source-resolution-default" IPP attribute. Bug fix release to get correct PDF output when using "landscape", "orientation-requested", and/or "nopdfAutoRotate" options, and to get PCLm printing work on printers not telling their PCLM default resolution. Please release this on Debian so that it can be synced into Ubuntu. Thanks in advance. Till
Bug#1008175: #1008175
The log message "Unable to do two-sided printing" comes from the "ipp"
CUPS backend, part of CUPS. It seems that the backend does not find the
"sides" attribute in the printer's IPP attributes.
See the code here:
--
if (ipp_status == IPP_STATUS_OK_IGNORED_OR_SUBSTITUTED ||
ipp_status == IPP_STATUS
_OK_CONFLICTING)
{
/*
* One or more options are not supported...
*/
if (ippFindAttribute(response, "sides", IPP_TAG_ZERO))
{
/*
* The sides value is not supported, revert to one-sided as
needed...
*/
const char *sides = cupsGetOption("sides", num_options, options);
if (!sides || !strncmp(sides, "two-sided-", 10))
{
fputs("DEBUG: Unable to do two-sided printing, setting sides
to 'one-sided'.\n", stderr);
num_options = cupsAddOption("sides", "one-sided",
num_options, );
}
}
--
cups-filters 1.28.13 released!
Hi,
I have released cups-filters 1.28.13 now, with the following changes:
- pdftopdf: Fix N-up printing when paper is taken
long-edge-first by the printer.
- pdftopdf: Fix cropping ("print-scaling=none" and
"print-scaling=fill") when paper is taken long-edge-first by
the printer (Issue #454).
- pdftops: Use Poppler for all Apple LaserWriter models (Issue
#452).
Bug fix release, for correct printing on printers which take in the
paper long-edge-first and for Apple LaserWriter printers.
Please release this on Debian so that it can be synced into Ubuntu.
Thanks in advance.
Till
HPLIP 3.22.2 is out!
Hi, HPLIP 3.22.2 got released: https://developers.hp.com/hp-linux-imaging-and-printing/release_notes Could you update the Debian package? Thanks. Till
Bug#1006892: cups-browsed: Local queues are not created for discovered printers
Probably cause by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006853 Till
CUPS 2.4.1
Hi, some days ago, CUPS 2.4.1 got released, but Debian seems to be still on CUPS 2.3.3op2 from September 2021, whereas most other printing-related packages got updated. Could you update CUPS in unstable? Or is there something broken in CUPS 2.4.0 and 2.4.1? I would be very grateful if you could do it before Ubuntu 22.04 Feature Freeze on Thursday, Feb 24. If this is not possible, please tell me as soon as possible. Thanks in advance Till
cups-filters 1.28.12 released!
Hi, I have released cups-filters 1.28.12 now, with the following changes: - imagetoraster, imagetopdf: Fixed comparison of the image size with the page size for print-scaling=auto. The image size in pixels was compared with the page size in PostScript points (1/72 inch). - imagetoraster, imagetopdf: Fixed the "print-scaling=none" (crop-to-fit) mode, also use crop-to-fit always when requested, do not fall back to fit-to-page when the image size differs significantly from the page size (Issue #362). - libcupsfilters: Changed the default PPI resolution for images as input files from 128 to 200 (Pull request #446). - implicitclass: Do not check availability of "gs" and "pdftops" executables, instead, check by the presence of "gstoraster" and "pdftoraster" filters whether we have configured cups-filters for Ghostscript and/or Poppler use. - libcupsfilters: In the PPD generator for the driverless utility and cups-browsed add "*cupsFilter2: ..." lines for all supported driverless data formats (PDF, Apple/PWG Raster, PCLm), and add lines for legacy data formats (PCL, PostScript) only if no driverless formats available. - libcupsfilters: Always use encryption for ipps. RFC7472 requires that 'ipps' must be used over HTTPS, but the driverless utility does not enforce encryption (Pull request #433). - serial: Add a 10-msec sleep and at the end add a tcdrain(). For some unknown reason, every printing file need sleep a little time to make sure the serial printer receive data is right (Pull request #431). - libcupsfilters: Fix resolver functions for DNS-SD-based URIs, to make resolve_uri() also work when DEVICE_URI env variable is set and to make ippfind_based_uri_converter() not re-direct stdin. - pdftopdf: Set default for print-scaling to avoid "should never happem" log messages and undefined behavior. - pdftopdf: Fix orientation-requested = 0. Consider this as "automatic selection and not as error. - pdftopdf: Fixed all combinations of print-scaling and number-up for printers with asymmetric margins (top != bottom or left != right) and for input files containing pages with different sizes and/or orientations. Fixes backported from 2.x branch. - pdftopdf: Add 2% tolerance for input size larger than output page when "print-scaling=auto" or "print-scaling=auto-fit" is used and too large input pages should be scaled, fitting documents not. This prevents a random-looking behavior if input and output page size seem to be equal, but in reality there are slight differences between size dimensions. Bug fix release, containing backports of many of the bugs recently fixed during the preparation of the cups-filters 2.x release. This time many page geometry bugs in the pdftopdf and imageto… filters were fixed especially with print-scaling and number-up, but also bugs in cups-browsed and in the serial backend got fixed. Please release this on Debian so that it can sync into Ubuntu, preferably before Feature Freeze for Ubuntu 22.04 on Thu, Feb 22.04. Thanks in advance. Till
cups-filters 1.28.11 released!
Hi, I have released cups-filters 1.28.11 now, with the following changes: - libcupsfilters: Let PPD generator take default ColorModel from printer (CUPS issue #277). - Braille: In vectortopdf check inkscape version to call inkscape with the correct command line (Issue #315, Pull request #443). - Build system: Make missing DejaVuSans.ttf non-fatal in ./configure as the font is only needed for test programs, not for actual use of cups-filters (Issue #411). - libcupsfilters: In imagetoraster() fixed crash with SGray (Issue #435). - cups-browsed: Naming of local queues is matched to CUPS' current naming of temporary queues (no leading or trailing underscores), to avoid duplicates in print dialogs which support CUPS' temporary queues. - libcupsfilters: Make cupsRasterParseIPPOptions() work correctly with PPDs (Issue #436). - libcupsfilters: Let colord_get_profile_for_device_id() not return empty file name, to avoid error messages in CUPS error_log. - foomatic-rip: Debug message was wrongly sent to stdout and not to log (Issue #422). Bug fix release, containing backports of many of the bugs recently fixed during the preparation of the cups-filters 2.x release. Important is that cups-browsed’s queue naming is aligned with CUPS’ temporary queue naming now and several bugs affecting driverless printing are fixed. Please release this on Debian so that it can sync into Ubuntu. Thanks in advance. Till
HPLIP 3.21.10 is out
Hi, here is the new HPLIP: https://sourceforge.net/projects/hplip/files/hplip/3.21.10/hplip-3.21.10.tar.gz Till
Re: Two Debian printer driver packages unusable: c2050 and fxlinuxprint
Thank you very much. I have updated the Snap now, so that it loads the current versions of the Debian packages and does not apply the patches by itself anymore. It is up in the Snap Store now. Till On 21/10/2021 17:36, Thorsten Alteholz wrote: Hi Till, thanks a lot for the patches. Updated package should be available now. Thorsten
Two Debian printer driver packages unusable: c2050 and fxlinuxprint
Hi, above-mentioned printer driver packages are currently unusable as their filter executables segfault, especially c2050 always crashes, independent of the input. The filters of fxlinuxprint at least sometimes crash. I have fixed both, eliminating the crashes completely. For fxlinuxprint the attached patch is the solution. The second patch improves the PPD file to make the supported printer models get explicitly listed in printer setup tools (and so make users find the driver more easily). For c2050 you get the C source code corrected by running the following commands (you can use them to generate a patch, see also commit link below): perl -p -i -e 's/register i\b/register int i/' c2050.c perl -p -i -e 's/^SweepBuffer_Init\b/void SweepBuffer_Init/' c2050.c perl -p -i -e 's/SweepBuffer_Init\s*\(\s*,\s+blkbytesize\s*\)/SweepBuffer_Init(, blkbytesize * 2)/' c2050.c I have found these bugs when retro-fitting all the old printer drivers, these ones in the GhostScript Printer Application: https://github.com/OpenPrinting/ghostscript-printer-app/ https://snapcraft.io/ghostscript-printer-app https://github.com/OpenPrinting/ghostscript-printer-app/commit/6982b674 https://github.com/OpenPrinting/ghostscript-printer-app/commit/5d7d8582 Could you apply these fixes to the Debian packages? Thanks. Till--- fxlinuxprint.ppd.orig 2021-10-18 12:49:28.877351303 +0200 +++ fxlinuxprint.ppd 2021-10-18 14:04:46.341317886 +0200 @@ -24,16 +24,130 @@ *LanguageEncoding: ISOLatin1 *cupsLanguages: "ja" *PCFileName: "FXPDFPRN.PPD" -*Manufacturer: "FX" -*Product: "(FX Printer Driver for Linux)" +*Manufacturer: "Fuji Xerox" +*Product: "(PDF Printer)" +*Product: "(ApeosPort-II 3000)" +*Product: "(ApeosPort-II 4000)" +*Product: "(ApeosPort-II 5000)" +*Product: "(ApeosPort-II 6000)" +*Product: "(ApeosPort-II 7000)" +*Product: "(ApeosPort-II C2200)" +*Product: "(ApeosPort-II C3300)" +*Product: "(ApeosPort-II C4300)" +*Product: "(ApeosPort-II C5400)" +*Product: "(ApeosPort-II C6500)" +*Product: "(ApeosPort-II C7500)" +*Product: "(ApeosPort-III 3010)" +*Product: "(ApeosPort-III 4000)" +*Product: "(ApeosPort-III 5000)" +*Product: "(ApeosPort-III 6000)" +*Product: "(ApeosPort-III 7000)" +*Product: "(ApeosPort-III C2200)" +*Product: "(ApeosPort-III C2205)" +*Product: "(ApeosPort-III C3300)" +*Product: "(ApeosPort-III C3305)" +*Product: "(ApeosPort-III C4400)" +*Product: "(ApeosPort-III C4405)" +*Product: "(ApeosPort-III C5500)" +*Product: "(ApeosPort-III C6500)" +*Product: "(ApeosPort-III C7600)" +*Product: "(ApeosPort-IV 3070)" +*Product: "(ApeosPort-IV 4070)" +*Product: "(ApeosPort-IV 5080)" +*Product: "(ApeosPort-IV 6080)" +*Product: "(ApeosPort-IV 7080)" +*Product: "(ApeosPort-IV C2270)" +*Product: "(ApeosPort-IV C2275)" +*Product: "(ApeosPort-IV C3370)" +*Product: "(ApeosPort-IV C3375)" +*Product: "(ApeosPort-IV C4470)" +*Product: "(ApeosPort-IV C4475)" +*Product: "(ApeosPort-IV C5570)" +*Product: "(ApeosPort-IV C5575)" +*Product: "(ApeosPort-IV C5580)" +*Product: "(ApeosPort-IV C6680)" +*Product: "(ApeosPort-IV C7780)" +*Product: "(DocuCentre C1101)" +*Product: "(DocuCentre C2101)" +*Product: "(DocuCentre-II 3000)" +*Product: "(DocuCentre-II 4000)" +*Product: "(DocuCentre-II 5000)" +*Product: "(DocuCentre-II 6000)" +*Product: "(DocuCentre-II 7000)" +*Product: "(DocuCentre-II C2200)" +*Product: "(DocuCentre-II C3300)" +*Product: "(DocuCentre-II C4300)" +*Product: "(DocuCentre-II C5400)" +*Product: "(DocuCentre-II C6500)" +*Product: "(DocuCentre-II C7500)" +*Product: "(DocuCentre-III 2000)" +*Product: "(DocuCentre-III 3000)" +*Product: "(DocuCentre-III 3010)" +*Product: "(DocuCentre-III 4000)" +*Product: "(DocuCentre-III 5000)" +*Product: "(DocuCentre-III 6000)" +*Product: "(DocuCentre-III 7000)" +*Product: "(DocuCentre-III C2200)" +*Product: "(DocuCentre-III C2205)" +*Product: "(DocuCentre-III C3300)" +*Product: "(DocuCentre-III C3305)" +*Product: "(DocuCentre-III C4400)" +*Product: "(DocuCentre-III C4405)" +*Product: "(DocuCentre-III C5500)" +*Product: "(DocuCentre-III C6500)" +*Product: "(DocuCentre-III C7600)" +*Product: "(DocuCentre-IV 2060)" +*Product: "(DocuCentre-IV 3060)" +*Product: "(DocuCentre-IV 3070)" +*Product: "(DocuCentre-IV 4070)" +*Product: "(DocuCentre-IV 5080)" +*Product: "(DocuCentre-IV 6080)" +*Product: "(DocuCentre-IV 7080)" +*Product: "(DocuCentre-IV C2260)" +*Product: "(DocuCentre-IV C2263)" +*Product: "(DocuCentre-IV C2263N)" +*Product: "(DocuCentre-IV C2270)" +*Product: "(DocuCentre-IV C2275)" +*Product: "(DocuCentre-IV C3370)" +*Product: "(DocuCentre-IV C3375)" +*Product: "(DocuCentre-IV C4470)" +*Product: "(DocuCentre-IV C4475)" +*Product: "(DocuCentre-IV C5570)" +*Product: "(DocuCentre-IV C5575)" +*Product: "(DocuCentre-IV C5580)" +*Product: "(DocuCentre-IV C6680)" +*Product: "(DocuCentre-IV C7780)" +*Product: "(DocuPrint 2060)" +*Product: "(DocuPrint 3000)" +*Product: "(DocuPrint 3000s)" +*Product: "(DocuPrint 3050)" +*Product: "(DocuPrint 3100)" +*Product: "(DocuPrint 4050)"
Bug#990210: fixed in cups-pdf 3.0.1-12
Sorry, I had overlooked the link in the very first post.
Also thanks for the patch which shows how cups-filters (most probably
pstops) massages the file.
The file has actually 993 pages:
$ gs -q -dBATCH -dNOPAUSE -sDEVICE=bbox all.ps 2>&1 | grep
%%BoundingBox: | wc -l
993
or simply display it with
gs all.ps
(and press Enter 993 times).
evince also shows only the 422 pages which your PostScript viewer shows
to you.
The file has strange internal page numbering:
$ grep -i '%%Page: ' all.ps | wc -l
993
$ grep -i '%%Page: ' all.ps
It redefines "showpage" (the PostScript function to display/print a page
when completed rendering it:
$ grep showpage all.ps | wc -l
1
$ grep showpage all.ps
/p{pop showpage pagesave restore /pagesave save def}def
This makes a single "p" displaying/printing the page.
So let us search for those "p"s:
$ grep ' p$' all.ps | wc -l
993
So Ghostscript (or the print process) outputting 993 pages seems correct
to me, and I do not understand why evince and also your PostScript
viewer only output 422 pages. Perhaps they consider duplicate page
numbers as duplicate pages and skip them.
First numbers in "%%Page:" lines:
$ grep -i '%%Page: ' all.ps | cut -d ' ' -f 2 | sort | uniq | wc -l
422
Second numbers in "%%Page:" lines:
$ grep -i '%%Page: ' all.ps | cut -d ' ' -f 3 | sort | uniq | wc -l
422
The changes coming from cups-filters/the pstops filter mainly only
change the DSC comments, letting the second number in the "%%Page:"
lines going from 1 to 993 instead of being the same as the first number,
starting from 1 again and again. This seems to make the viewers
accepting all pages.
I hope this gives some insight.
On 01/10/2021 13:11, Andre Heider wrote:
Hi Till,
On 01/10/2021 12:32, Till Kamppeter wrote:
Andre, could you attach your PostScript file, once the original and
also the one you get after pre-processing when using "GSCall echo %s
%s %s;
cp %s /tmp"? Thanks.
attached a patch for the original .ps file, see the first post for a link.
But maybe that patch already hints at the problem?
Cheers,
Andre
Bug#990210: fixed in cups-pdf 3.0.1-12
Andre, could you attach your PostScript file, once the original and also the one you get after pre-processing when using "GSCall echo %s %s %s; cp %s /tmp"? Thanks. -- On 28/09/2021 14:20, Andre Heider wrote: Indeed, still only getting an empty pdf on that file too. That's another problem than the empty pdf files I was seeing before. That issue prevented cups-pdf to produce non-empty files at all, no matter what the input was. Even the cups test page failed. Now it seems specific to this file. My pdf viewer atril claims the original ps has 422 pages. If I fix it up with `ps2ps all.ps all2.ps` the new file reports 993 pages, atril even shows another first page... And printing that with `lp -dPDF all2.ps` works just fine. The error handling from cups-pdf sure is funky here. Cheers, Andre -- On 29/09/2021 09:11, Andre Heider wrote: Did some more digging since I reused this bug because I thought it's the same issue... If you set the GSCall config to the default value but append "1>/tmp/gs.out 2>&1" you can see an error in that file: --- 8< --- Error: /nocurrentpoint in --currentpoint-- Operand stack: (--) 80 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3 %oparray_pop 1977 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:736/1123(ro)(G)-- --dict:0/20(G)-- --dict:89/200(L)-- --dict:63/140(L)-- Current allocation mode is local Current file position is 10444 GPL Ghostscript 9.54.0: Unrecoverable error, exit code 1 --- 8< --- The reason it fails with lp but succeeds with the manual gs cmdline is that cups preprocesses the input file. If you use "GSCall echo %s %s %s; cp %s /tmp" it'll copy the actual file used for cups-pdf to /tmp, for which you then get the same error if you manually use the gs cmdline on it. I don't know enough about the printing stack/postscript to tell if that's fixable, but it all sounds like a corrupt ps file to me.
Re: Printing works but still getting error messages
I now have done a fix on the GIT of cups-filters (both branches, master and 1.x) to prevent the error you mentioned. Till On 19/09/2021 15:07, Daniel Haid wrote: Till, it is exactly as you said: After manually adding the queue, the one from cups-browsed disappeared. Then I removed the manual queue, and the one from cups-browsed appeared again. I enabled debug messages, restarted cups with an empty error_log, and printed once with the queue from cups-browsed (where the error does appear). Unfortunately /var/log/cups/error_log is still 69525 lines long. The error occurs in line 67663. Find attached. Best, D.H.
Re: Printing works but still getting error messages
Thanks for the error_log. The error message -- E [19/Sep/2021:12:16:51 +0200] [Job 13] File \'\' not found -- is harmless. It only means that no color management profile is present for this printer. In this case a standard profile of Poppler is used. We should demote this message to DEBUG instead of ERROR level. See -- D [19/Sep/2021:12:16:51 +0200] [Job 13] Color Manager: Calibration Mode/Off D [19/Sep/2021:12:16:51 +0200] [Job 13] Calling FindDeviceById(cups-Brother_DCP_ L2550DN_series) D [19/Sep/2021:12:16:51 +0200] [Job 13] Found device /org/freedesktop/ColorManag er/devices/cups_Brother_DCP_L2550DN_series D [19/Sep/2021:12:16:51 +0200] [Job 13] Calling org.freedesktop.ColorManager.Dev ice.Get(ProfilingInhibitors) D [19/Sep/2021:12:16:51 +0200] [Job 13] Calling FindDeviceById(cups-Brother_DCP_ L2550DN_series) D [19/Sep/2021:12:16:51 +0200] [Job 13] Found device /org/freedesktop/ColorManager/devices/cups_Brother_DCP_L2550DN_series D [19/Sep/2021:12:16:51 +0200] [Job 13] Calling GetProfileForQualifiers(Gray.Stationery.1200dpi...) D [19/Sep/2021:12:16:51 +0200] [Job 13] Found profile /org/freedesktop/ColorManager/profiles/Brother_DCP_L2550DN_series_Gray__ D [19/Sep/2021:12:16:51 +0200] [Job 13] Calling org.freedesktop.ColorManager.Profile.Get(Filename) D [19/Sep/2021:12:16:51 +0200] [Job 13] Use profile filename: \'\' D [19/Sep/2021:12:16:51 +0200] [Job 13] Color Manager: ICC Profile: E [19/Sep/2021:12:16:51 +0200] [Job 13] File \'\' not found -- Otherwise the log makes an impression of a job which has been processed and printed correctly. I do not find anything wrong with that. So all what I can do is demoting the error message to a debug message in the cups-filters code, so that print dialogs do not shout it out. Till On 19/09/2021 15:07, Daniel Haid wrote: Till, it is exactly as you said: After manually adding the queue, the one from cups-browsed disappeared. Then I removed the manual queue, and the one from cups-browsed appeared again. I enabled debug messages, restarted cups with an empty error_log, and printed once with the queue from cups-browsed (where the error does appear). Unfortunately /var/log/cups/error_log is still 69525 lines long. The error occurs in line 67663. Find attached. Best, D.H.
Re: Printing works but still getting error messages
[ Re-posting for Daniel Haid, original poster ] On 18/09/2021 22:30, Daniel Haid wrote: The entry is not in the 'lpstat -t' output. You are not using the Brother drivers too, are you? I'm without a good idea here. No, but I have read that the GTK printing dialog does its own searching for IPP everywhere printers and moreover only sends PDF to the printer. Maybe the problem is that my printer does not support PDF. If the GTK dialog does this, you should report it to GTK as a bug. IPP printers advertise themselves via DNS-SD (this way the dialog finds them) and in the DNS-SD record they tell what exactly they support, especially which job data formats. So the print dialog should not send blindly PDF to any IPP printer. Driverless IPP does not include by default the capabilities of spooling and of understanding PDF. Therefore we need CUPS. It spools print jobs and converts data formats. So a print dialog should print through CUPS and not directly to IPP devices. Anyway, do this: lpadmin -p L2550 -v URI_FROM_PREVIOUSLY -E -m everywhere > and print to the L2550 queue. I did it and now the error message in the log file does not appear anymore. The error still appears when using the old queue. But what is the difference between the queues? Should the command above not be what cups-browsed runs when it finds a printer? cups-browsed does not do exactly the same. cups-browsed does not only create single queues for single printers. it has the capability of creating printer clusters, for distributing high amounts of jobs in a load-balanced group of (usually equal) printers (what CUPS did before version 1.6, the clusters being called classes), or, for having a queue which by the job option settings passes on the job to the most suitable of (typically completely different) printers. For the latter use case, having completely different printers in a cluster, each member printer would need a completely different filter chain (at least the filters after pdftopdf) as the printers use different types of drivers. The queue which cups-browsed creates on CUPS has only one PPD file where the options are merged from the member printer's PPDs and the final data format to send off to the backend is always PDF. The backend is cups-browsed's own "implicitclass" then. This backend asks cups-browsed to check the option settings and to determine the cluster member(s) which can fulfill them, to select one of the suitable printers, and tell which final data format the printer needs. The backend then passes the print data through filters to convert the data into the member printer's final format and send the job off to the printer. Due to this technique filter chains can vary between a cups-browsed-generated queue and a manually created queue. We will need your error_log (in debug mode) to find out what is wrong with cups-browsed's filter chain. And can I remove the old queue without cups-browsed recreating it again immediately? Generally cups-browsed does not auto-create queues to printers for which there is already a manually created queue. You do not even need to remove the queue created by cups-browsed. Stop cups-browsed and start it again and the queue should go away. If it is your only printer, you do not need cups-browsed once after having created a queue manually, you can disable it. Only if you are in a network with many printers or you roam with a laptop between different networks with different sets of printers, cups-browsed comes in handy. By the way, the printing dialog still shows a printer error, but I do not really care about that. It seems to be buggy anyway with its detection of everywhere-printers with the wrong capabilities. Please report a bug on the GTK print dialog, to GTK. Till
cups-filters 1.28.10 released!
Hi, I have released cups-filters 1.28.10 now, with the following changes: - Sample PPDs: Add borderless page size definitions to Generic PDF Printer, HP Color LaserJet CM3530 MFP PDF, and Ricoh PDF Printer PPD files. - Sample PPDs: From the PDF PPD files removed the unneeded "*cupsFilters2: ..." line. For CUPS it does not make any difference. - libcupsfilters: Fixed pdftopdf filter to correctly support page ranges without upper limit, like "10-" (Pull request #399). - libcupsfilters: Use wildcard tag (IPP_TAG_ZERO) search for "media-type" and "media-type-supported" in the PPD generator (Pull request #398). - implicitclass, parallel: Added missing newlines at error messages. - libfontembed: Removed unneeded fontembed/main.c and ttfread executable. Eliminates the dependency on DejaVuSans.ttf (Issue #386). - gstoraster: Refactor the filter a little to clarify handling of page counts and set job-impressions for TotalPageCount in PWG-Raster header (Pull request #394). - cups-browsed: Make NotifLeaseDuration configurable and renew after half the lease duration not 60 sec before end. The early renewal improves reliability on busy systems a lot. For easier development and debugging short durations from 300 sec on can get selected (Pull request #378). Bug fix release: More reliable legacy CUPS browsing in cups-browsed, improved PDF printer sample PPDs, with borderless page sizes, eliminated unneeded dependency on DjVu font, minor fixes Please release this on Debian so that it can sync into Ubuntu. I appreciate if you could do this until Wednesday as we have Feature Freeze for 21.10 on Thursday. Thanks in advance. Till
Re: driverless printing awesomeness
Tomas, thanks for your information! Alex, another scanner working with sane-airscan: EPSON ET-3750_Series Could you add it to your list? Till On 09/07/2021 12:49, Tomas Pospisek wrote: Hi Brian, On Tue, 6 Jul 2021, Brian Potkin wrote: On Tue 06 Jul 2021 at 09:54:29 +0200, Tomas Pospisek wrote: It does 8-O $ scanimage -L device `airscan:e0:EPSON ET-3750 Series (USB)' is a eSCL EPSON ET-3750 Series (USB) ip=127.0.0.1 device `imagescan:esci:usb:/sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0' is a EPSON ET-3750_Series $ airscan-discover [devices] EPSON ET-3750 Series (USB) = http://127.0.0.1:6/eSCL/, eSCL launched xsane, did a scan preview and then a 1200dpi (max) scan and marveled about the crisply visible fibres of the paper. Oh thank you!!! Thanks. There are two devices. Please would you confirm scanning takes place with xsane "airscan:e0:EPSON ET-3750 Series (USB)" confirming. Scanning indeed takes place with that command. Thanks a lot & best greetings! *t
Re: driverless printing awesomeness
On 02/07/2021 21:52, Brian Potkin wrote: Thank you for your appreciative mail. Is the device USB- or network-connected? Also thanks for your mail. Great to also hear from an Epson user (Epson ET-3750) that our driverless printing support is working. It's USB connected. You are using ipp-usb. The author of ipp-usb, Alexander Pevzner (CCed), got inspired to create it when I tested his sane-airscan with the former ippusbxd (now discontinued and replaced by ipp-usb), and showed him that his driverless scanning does also work on USB (and that not even being IPP). I (and many other users) did a lot of testing with Alex. You should get driverless scanning too; installing sane-airscan would be a good move. If you follow this advice, please give scanimage -L airscan-discover Thanks for letting me know! Should airscan work over USB too? For me it work perfectly on the HP OfficeJet Pro 8730 (both network and USB), after a lot of testing and debugging with Alex. So if it does not work perfectly for you, please "reply-to-all" right on this e-mail and Alex will solve the problem with you (and add your printer to the "hall of fame" on https://github.com/alexpevzner/sane-airscan#compatibility). Till
cups-filters 1.28.9 released!
Hi, I have released cups-filters 1.28.9 now, with the following changes: - libcupsfilters: Silenced compiler warnings - libcupsfilters: Removed duplicate code in the apply_filters() function. - driverless: If there are no driverless IPP printers available let "driverless" terminate with exit code 0 and not 1, to follow CUPS' standard of backends in discovery mode terminating with 0 if there are no appropriate printers found (Issue #375). - gstoraster, foomatic-rip: Fixed Ghostscript command line for counting pages as it took too long on PDFs from evince when printing DjVu files (Issue #354, Pull request #371, Ubuntu bug #1920730). - cups-browsed: Renamed ldap_connect() due to conflict in new openldap (Issue #367, Pull request #370). - pdftoraster: Free color data after processing of each page (Pull request #363). - cups-browsed: Always save "...-default" option entries from printers.conf, regardless of presence or absense of PPD file (Pull request #359). - cups-browsed: Start after network-online.target (Pull request #360). - texttopdf: Set default margins when no PPD file is used (Pull request #356). Bug fix release, fixes backported from the master (2.x) branch. Please release this on Debian so that it can sync into Ubuntu. Thanks in advance. Till
Re: Release Notes for Debian 11 (bullseye)
For me this looks all OK. Thank you very much for documenting this. Till On 04/04/2021 17:03, Brian Potkin wrote: It is remiss of me not to have drawn everyone's attention to this documentation before now. Please cast an eye over it to see whether it fits the bill. https://www.debian.org/releases/testing/amd64/release-notes/ch-whats-new.en.html#driverless-operation
Re: cups-filters 1.28.8 released!
Thank you very much. Till On 30/03/2021 19:51, Didier 'OdyX' Raboud wrote: Le jeudi, 25 mars 2021, 18.54:41 h CEST Till Kamppeter a écrit : Hi, I have released cups-filters 1.28.8 now, with the following changes: - libcupsfilters: Made check whether the driverless PPD to generate should be a fax out PPD more reliable (Issue #343). - foomatic-rip: Options in the 5th command line argument of the CUPS filter command line are separated only by white space and not by comma, also make sure that an option "none" is not considered a custom page size (Issue #348). - implicitclass: Raise timeout for cups-browsed's answer from 20s to 60s (Pull request #346). - libcupsfilters: In the PPD generator really give priority to Apple Raster against PDF (Issue #331). Bug fix release, to fix several different issues Please release this on Debian so that it can sync into Ubuntu. Given the freeze, uploaded to experimental. Best, OdyX
cups-filters 1.28.8 released!
Hi, I have released cups-filters 1.28.8 now, with the following changes: - libcupsfilters: Made check whether the driverless PPD to generate should be a fax out PPD more reliable (Issue #343). - foomatic-rip: Options in the 5th command line argument of the CUPS filter command line are separated only by white space and not by comma, also make sure that an option "none" is not considered a custom page size (Issue #348). - implicitclass: Raise timeout for cups-browsed's answer from 20s to 60s (Pull request #346). - libcupsfilters: In the PPD generator really give priority to Apple Raster against PDF (Issue #331). Bug fix release, to fix several different issues Please release this on Debian so that it can sync into Ubuntu. Thanks in advance. Till
Bug#983474: ipp-usb: breaks scanning with HP Deskjet 5275
Updating SANE (libsane1, sane-backends) from 1.0.31 to 1.0.32 could perhaps fix the scanning with installed ipp-usb and the "escl" backend. 1.0.32 (released upstream a few weeks ago) has a lot of fixes and improvements on the "escl" backend. You could install sane-airscan. This is an extra SANE backend which provides more sophisticated support for driverless scanning (scanning with ipp-usb, "IPP over USB" always uses driverless scanning and printing standards). Classic drivers (as HPLIP's "hpaio" work only without ipp-usb. Till On 24/02/2021 20:47, Tzafrir Cohen wrote: Package: ipp-usb Version: 0.9.17-1 Severity: normal Dear Maintainer, I recenty realised I cannot scan with my scanner (part of a multi-function printer/scanner HP Deskjet 5275). Disabling ipp-usb enabled scanning. With ipp-usb running: $ time scanimage -L device `escl:http://127.0.0.1:6' is a HP DeskJet 5200 series [FC8002] (USB) flatbed scanner device `hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' is a Hewlett-Packard DeskJet_5200_series all-in-one real0m7.483s user0m0.102s sys 0m0.087s $ time scanimage -x 100 -y 100 --format=tiff >image.tiff scanimage: open of device escl:http://127.0.0.1:6 failed: Out of memory real0m7.511s user0m0.117s sys 0m0.109s $ time scanimage --device 'hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' -x 100 -y 100 --format=tiff >image.tiff scanimage: open of device hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C failed: Error during device I/O real0m0.051s user0m0.037s sys 0m0.013s With ipp-usb stopped: $ time scanimage -L device `hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' is a Hewlett-Packard DeskJet_5200_series all-in-one real0m7.528s user0m0.139s sys 0m0.103s $ time scanimage -x 100 -y 100 --format=tiff >image.tiff real0m9.892s user0m0.165s sys 0m0.105s $ identify image.tiff image.tiff TIFF 295x295 295x295+0+0 1-bit Bilevel Gray 11125B 0.000u 0:00.000 $ dpkg-query -W sane-utils libsane1 libsane1:amd64 1.0.31-4 sane-utils 1.0.31-4 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ipp-usb depends on: ii avahi-daemon 0.8-5 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.31-9 ii libusb-1.0-0 2:1.0.24-2 ipp-usb recommends no packages. ipp-usb suggests no packages. -- no debconf information
Printer driver meta package
Hi, I got aware about which printer drivers are auto-installed when installing a printer driver meta package (printer-driver-all, printer-driver-app-enforce): https://salsa.debian.org/printing-team/printing-metas/-/blob/master/debian/printer-driver-recommends.list The list needs a slight update. First, HPIJS is deprecated for several years now and hpcups (also part of HPLIP) should be used instead. Therefore "hpijs" should be removed from this list. We could even remove the HPIJS-related packages from HPLIP. Second, "oki" and "indexbraille" need to get added (the latter we should think about as it is really specialty). Till
Re: HPLIP 3.21.2
On 21/02/2021 18:30, Didier 'OdyX' Raboud wrote: Le vendredi, 19 février 2021, 21.44:58 h CET Till Kamppeter a écrit : Hi, HPLIP 3.21.2 is available now. I appreciate a lot if it could be packaged so that it can get synced into Ubuntu. Despite the current Bullseye freeze, I uploaded hplip 3.21.2+dfsg0-1 to unstable some minutes ago. You can sync from it to Ubuntu. I'm not yet sure it will make it to Bullseye (= "I shouldn't have uploaded it to unstable, but to experimental"), but it's too late to change the fact the upload happened. Thank you very much. I did not know about the freeze, but we can also (at least manually) sync from Experimental should uploads to Unstable be closed for the release. Till
HPLIP 3.21.2
Hi, HPLIP 3.21.2 is available now. I appreciate a lot if it could be packaged so that it can get synced into Ubuntu. Till
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
OK, no I understand, fresh installation or live ISO all works perfectly as intended, old installation shows the problem, so further investigations only on the old installation ... Till
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
On 15/02/2021 14:27, mh wrote: I then investigated the LIVE-ISO. To my surprise ipp-usb is installed within the LIVE-ISO. ipp-usb is part of the standard installation in Debian and Ubuntu, to support printers which do driverless IPP printing. Standard-conforming printers should work out-of-the-box with that. All the commands which failed/did have an empty output on my default system work here with the expected output (I guess), except for # avahi-browse -rt _ipp._tcp due to avahi-browse not being installed: # /usr/lib/cups/backend/usb DEBUG: Loading USB quirks from "/usr/share/cups/usb". DEBUG: Loaded 98 quirks. DEBUG: list_devices DEBUG: libusb_get_device_list=9 DEBUG: Failed to detach "usblp" module from 06bc:0357 The "usb" backend probably simply encounters your printer's USB occupied by some process here, not knowing that it is actually ipp-usb and not the "usblp" kernel module. The method for getting rid of the kernel module seems no to remove the connection of ipp-usb. # systemctl list-units "ipp-usb*" | grep service ipp-usb.service loaded active running Daemon for IPP over USB printer support # lpstat -t Zeitplandienst läuft Keine systemvoreingestellten Ziele Gerät für OKI_DATA_CORP_B432: ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/ OKI_DATA_CORP_B432 akzeptiert Anfragen seit Mo 15 Feb 2021 12:45:49 CET Drucker OKI_DATA_CORP_B432 ist im Leerlauf. Aktiviert seit Mo 15 Feb 2021 12:45:49 CET # lpstat -l -e OKI_B432_010E46_USB_ network none ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/ OKI_DATA_CORP_B432 permanent ipp://localhost/printers/OKI_DATA_CORP_B432 ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/ This looks like that a driverless print queue got created automatically. Could you run these two commands: lp -d OKI_B432_010E46_USB_ ~/.bashrc lp -d OKI_DATA_CORP_B432 ~/.bashrc Do you get something printed? If yes, by the first command? By the second? Both? # avahi-browse -rt _ipp._tcp Command 'avahi-browse' not found, but can be installed with: apt install avahi-utils Install this command by actually doing sudo apt install avahi-utils Then run the command again and post the output here. @ till.kamppeter As much as I'm willing to help, from what I can tell now I assume there is not much to debug *direktly* related to the printer. Tell me if you think otherwise. If the printer is capable of driverless printing via an auto-generated all is OK. But if it is not capable of that but pretends to be capable then somewhere is a bug, in our software or in the printer, in the latter case we caould perhaps work around in our software. BTW (not related the this malfunction): There are already some OKI PPD files available in the cups config, including the PPD file for the preceding model. What do you mean with this? Is there a PPD for your printer included in Debian or Ubuntu? Or did you download it directly from Oki? Could I do anything to help to include the appropriate vendor PPD file for my printer (freely availabe on their webite) in the printer-driver-oki package (or whichever package is the rightone)? If the PPDs are under a free software license we can add them to OpenPrinting (and this way to all distributions and also the PostScript Printer Application). Till
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
Alexander, on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982742 Michael Hatzold (CCed) reports a problem with ipp-usb. The printer provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB and with this, according to the standards, driverless printing (and scanning if it is a MFP). This particular model seems to have some bug though. Due to it providing 7/1/4 ipp-usb attaches to it but it does not provide driverless IPP printing then. As this can possibly be a bug in ipp-usb or the need of a quirk exception in ipp-usb, I want to ask you whether you could debug this together with Michael as you also had made my scanner work together with me. Thanks in advance. Till On 15/02/2021 11:26, Brian Potkin wrote: On Sun 14 Feb 2021 at 20:31:28 +0100, mh wrote: [...] # ippfind -T 5 ~# An IPP printer is not found. This would fit the observation that cups-browsed has not set up a print queue. I have come to the conclusion that the B432 does not implement IPP-over-USB correctly. A queue set up with a vendor PPD will not function while ipp-usb is active, so purge it and proceed as you did with the Live ISO. Also see #982190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982190 Cheers, Brian.
Bug#980973: Cups attempts to probe, configure unsupported Canon USB printers
Please report this to CUPS upstream at https://github.com/OpenPrinting/cups Note trhat CUPS is not maintained at Apple any more but at OpenPrinting now. We need the USB IDs (VID/PID) of all affected devices, at least of as many devices as possible. Till On 24/01/2021 23:46, Chris Bainbridge wrote: Package: cups Version: 2.3.3op1-7 Cups does not support Canon CAPT USB printers (this requires a proprietary driver which uses /dev/usb/lp0), but these printers are not blacklisted, so when one is plugged in, cups sets up a new, non-functional printer, and probes the USB device, the kernel logs as a USB disconnect, and disrupts operation of the Canon driver. Running lpstat also seems to do some probe and cause a USB device disconnect. The kernel logs: Jan 23 23:45:29 debian kernel: usblp0: removed It appears the fix would be to add CAPT printers to /usr/share/cups/usb/org.cups.usb-quirks as so: # Canon, Inc. LBP3010/LBP3018/LBP3050 Printer 0x04a9 0x26da blacklist etc.
PAPPL - Library for Printer Applications
Hi, PAPPL has been officially released as a stable version: https://github.com/michaelrsweet/pappl/releases/tag/v1.0.0 https://github.com/michaelrsweet/pappl/releases/tag/v1.0.1 https://openprinting.github.io/pappl-1.0.0/ I wold appreciate if it gets packaged for Debian. We will sync it also into Ubuntu then and this is a great base for printer driver developers to provide their drivers as Printer Applications, both in Debian packages and in Snaps. Till
CUPS 2.3.3op1: Possible delays when starting CUPS, autopkg tests in debian/tests/ not working
Hi, in the OpenPrinting fork of CUPS we got a contribution from Zdenek Dohnal switching cups to the systemd service typoe "notify": -- commit e96e96b4bd0d4e6f634bbb66b95d6e475501541c Author: Zdenek Dohnal Date: Wed Nov 25 08:12:32 2020 +0100 [Fedora] cups.service.in: Use 'notify' service type and run after network.target 1) If the service is defined with 'simple' type, the result of 'systemctl' is 0 regardless of actual startup result, because it reports success/failure of forking process (even before cupsd is started). This way errors due bad configuration or programming errors are masked during systemctl invocation. The 'notify' type depends on executable sending a 'Im running' type of message to systemd after successful start and systemctl's return code depends whether this message came or not, which solves the issue. 2) The service needs to be started after all units needed for network.target are activated. This prevents starting cupsd before we have ports ready. Fedora bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1153660 (adding network.target) https://bugzilla.redhat.com/show_bug.cgi?id=1088918 (change of the service type) -- This makes systemd waiting for cupsd giving an "I am up and running" notification on the socket /run/systemd/notify. As cupsd is under AppArmor control it cannot write to this socket and systemd gets stuck until reaching a timeout. This timeout leads to a significant delay when starting cupsd and also to the failure of all autopkg tests. To fix this I have added # CUPS is of systemd service type "notify" now, meaning that cupsd notifies # systemd when it is up and running, give CUPS access to systemd's # notification socket /run/systemd/notify w, to the AppArmor profile debian/local/apparmor-profile in cups_2.3.3op1-5ubuntu1. I recommend to update the Debian package appropriately. Till
Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow
I have released cups-filters 1.28.7 with the fix now. https://github.com/OpenPrinting/cups-filters/releases/tag/1.28.7
cups-filters 1.28.7 released!
Hi, I have released cups-filters 1.28.7 now, with the following changes: - driverless: Removed the support quality check from Pull request #235 as it takes significant time for each printer being listed, making cups-driverd (`lpinfo -m`) timing out when there are many printers (OpenPrinting CUPS issue #65). - libcupsfilters: In the PPD generator give priority to Apple Raster against PDF (Issue #331). - libcupsfilters: Added NULL check when removing ".Borderless" suffixes from page size names (Issue #314, Pull request #328). - libcupsfilters: In the cupsRasterParseIPPOptions() map the color spaces the same way as in the PPD generator (Issue #326, Pull request #327). - libcupsfilters: Fixed addition of grayscale mode in generated PPD files, to avoid duplicate entries (OpenPrinting CUPS issue #59). Bug fix release to remove the support quality check from the "driverless" utility to do not break CUPS' PPD listing facility and several fixes for generating PPDs for driverless printers Please release this on Debian so that it can sync into Ubuntu. Thanks in advance. Till
Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow
I have investigated the problem further and the problem is caused by "driverless" sending get-printer-attributes IPP requests to each printer it lists, to check the quality of driverless printing support. See https://github.com/OpenPrinting/cups-filters/pull/235 This makes "driverless" taking too long time, especially if there are many printers. See the investigations on https://github.com/OpenPrinting/cups/issues/65 Therefore I have removed the feature again now, on both master and 1.x branches of cups-filters: https://github.com/OpenPrinting/cups-filters/commit/3fddcf5 https://github.com/OpenPrinting/cups-filters/commit/aae86d2 Please test, this should solve your problem. I will release cups-filter 1.28.7 soon, with this change included.
Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow
The problem also got reported upstream: https://github.com/OpenPrinting/cups/issues/65 Could you also see the discussion there and try what got suggested there? I by myself am not able to reproduce it, so I need someone who can reproduce it to find out under which conditions it happens. Till
Re: Contact possibility for Odyx/Didier
On 03/12/2020 19:44, Helge Kreutzmann wrote: Thanks for the explanation. Are the man page translation are also transferred there? If so, would it be possible that I continue to (dirictly) manage it (i.e. keep the translation current)? Greetings Helge Where do your man page translations reside? In the Debian packaging GIT repo or in the CUPS upstream repo? Does the CUPS upstream repo contain any man page translations? The correct place would be the CUPS upstream repo as the original English man pages are part of CUPS. Till
cups-filters 1.28.6 released!
Hi, I have released cups-filters 1.28.6 now, with the following changes: - libcupsfilters: In generated PPDs add a grayscale mode if there are only color printing modes (from OpenPrinting CUPS). - libcupsfilters: In generated PPDs add an "OutputBin" option also if it has only one choice (OpenPrinting CUPS pull request #18). - libcupsfilters: Generated PPDs could have an "Unknown" default InputSlot (OpenPrinting CUPS issue #44). - cups-browsed: Removed unneeded IPP attribute additions preventing the created local queues from preserving a location or description the user assigns to them (Issue #323). - cups-browsed: Removed all calls of the resolve_uri() function of libcupsfilters, as these are not actually needed and in case the supplied DNS-SD-based URI is not resolvable, the function gets stuck for ~5 seconds. - cups-browsed: Fixed several memory leaks, mainly from the code to merge printer IPP attributes for clusters (Pull request #322). - cups-browsed: Silenced compiler warning. - foomatic-rip: Fix infinite loop and input from file on raw printing (Pull request #318). - foomatic-rip: Remove temporary file created during pdf-to-ps conversion (Pull request #313). Bug fix release, fixing lots of memory leaks in cups-browsed, fixed cups-browsed hanging several seconds when there are local print queue with invalid DNS-SD-based URIs, several fixes on the PPD generator for IPP printers, taken from OpenPrinting's fork of CUPS, and fixing bugs on foomatic-rip Please release this on Debian so that it can sync into Ubuntu. Thanks in advance. Till
Re: Contact possibility for Odyx/Didier
Apple seems to have stopped developing CUPS since Michael Sweet has left Apple in the end of 2019. After some time I have created together with Michael Sweet a fork of the CUPS upstream repository on OpenPrinting: https://github.com/OpenPrinting/cups Michael Sweet is actively applying pull requests from the former Apple repository, fixing bugs, and applying distro patches in this new upstream. This is now the upstream of CUPS for many distributions, especially Debian and Ubuntu. The first release, 2.3.3op1 is the current release of Debian unstable now. The Debian packaging GIT repository should have stayed the same as before. See also my monthly news posts and Michael's announcements on https://openprinting.github.io/news/ Till On 01/12/2020 21:37, Helge Kreutzmann wrote: Ok, thanks. I daily mirror the cups git repository, but for quite some time no changes appeard, however, some kind of message which I could not figure out: Your configuration specifies to merge with the ref 'refs/heads/debian/master' from the remote, but no such ref was fetched. Today, I got an updated of cups (in stable) which, amongst others, said: * Refresh manpage translation pofiles for 2.3.3op1 Did the CUPS git repository change? Where can I find the current (unstable) place to maitain the man page translation, whenever the need arises (the upstream text change)? Thanks for the correct pointers Helge
Re: cups-filters 1.28.5 released!
On 14/10/2020 18:44, Didier 'OdyX' Raboud wrote: Le mardi, 13 octobre 2020, 17.38:13 h CEST Till Kamppeter a écrit : Hi, I have released cups-filters 1.28.5 now. Uploaded. Thanks. Till
cups-filters 1.28.5 released!
Hi, I have released cups-filters 1.28.5 now, with the following changes: - cups-browsed: UUID from IPP response was used after its pointer was freed by ippDelete() (Pull request #311). Bug fix release for a quick, potential crasher correction in cups-browsed Please release this on Debian. On Ubuntu I have already uploade it as we have Final Freeze for Groovy (20.10) this Thursday. Thanks in advance. Till
Re: cups-filters 1.28.4 released!
Thank you very much. Till On 10/10/2020 10:54, Didier 'OdyX' Raboud wrote: Le jeudi, 8 octobre 2020, 12.35:58 h CEST Till Kamppeter a écrit : Hi, I have released cups-filters 1.28.4 now Uploaded.
