Description of problem: After update to 2.2.4-1 hp officejet pro 8600 does not print at all. somme others printers seem to print blank page or nothing. Version-Release number of selected component (if applicable): cups-2.2.4-1.mga6 How reproducible: - update to cups -2.2.4-1 - intent printing some file - if remove printer with system-setting-printer and add a new one, then test page doas not work with message : Inactif - Can't detect file type (but printer is active) .
Thanks for the report. I think it's the same as bug 21424 which had been initially considered as Cauldron-specific, but it seems to affect Mageia 6 too based on reports on the mailing lists. Let's keep debugging and discussion there then, closing this one as duplicate. *** This bug has been marked as a duplicate of bug 21424 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE
Actually changing my mind, the two bug reports are about CUPS 2.2.4 issues but mention different symptoms. This bug report should stay about the fact that printers are recognized but are not functional: printing blank page or printing nothing.
Priority: Normal => HighResolution: DUPLICATE => (none)Status: RESOLVED => REOPENEDAssignee: bugsquad => thierry.vignaud
heres the failure from my syslog file Aug 4 12:34:14 localhost cupsd[1715]: Started filter /usr/lib/cups/filter/pdftopdf (PID 27166) Aug 4 12:34:14 localhost cupsd[1715]: Started backend /usr/lib/cups/backend/hp (PID 27167) Aug 4 12:34:14 localhost cupsd[1715]: REQUEST localhost - - "POST /printers/Hewlett-Packard-HP-LaserJet-200-color-M251n HTTP/1.1" 200 22347 Send-Document successful-ok Aug 4 12:34:14 localhost cupsd[1715]: pdftopdf: Last filter determined by the PPD: -; FINAL_CONTENT_TYPE: application/pdf => pdftopdf will log pages in page_log. Aug 4 12:34:14 localhost kernel: [11196.096010] pdftopdf[27166]: segfault at 10 ip 00007fd579ba4c63 sp 00007ffdb4b05760 error 6 in libc-2.22.so[7fd579b28000+1a9000] Aug 4 12:34:14 localhost cupsd[1715]: prnt/backend/hp.c 913: ERROR: null print job total=0 Aug 4 12:34:14 localhost cupsd[1715]: PID 27166 (/usr/lib/cups/filter/pdftopdf) crashed on signal 11. Aug 4 12:34:14 localhost hp[27167]: prnt/backend/hp.c 913: ERROR: null print job total=0 Aug 4 12:34:14 localhost cupsd[1715]: Hint: Try setting the LogLevel to "debug" to find out more. Aug 4 12:34:14 localhost cupsd[1715]: PID 27167 (/usr/lib/cups/backend/hp) exited with no errors. Aug 4 12:34:14 localhost cupsd[1715]: Job stopped due to filter errors; please consult the error_log file for details. regards peter
CC: (none) => peter.winterflood
For three days and dozens of print jobs cups-2.2.4 worked perfectly for me. However, since installing the following updates: libsqlite3_0-3.17.0-2.1.mga6.i586 Fri 04 Aug 2017 12:58:36 BST lib64qpdf17-6.0.0-2.20170730.1.mga6.x86_64 Fri 04 Aug 2017 12:58:35 BST gnupg-1.4.22-1.mga6.x86_64 Fri 04 Aug 2017 12:58:34 BST sqlite3-tools-3.17.0-2.1.mga6.x86_64 Fri 04 Aug 2017 12:58:26 BST lib64sqlite3_0-3.17.0-2.1.mga6.x86_64 Fri 04 Aug 2017 12:58:26 BST I am now seeing the filter failed message on all print jobs. LO and kwrite still print (although cups reports filter failed) but okular does not print at all. I've no idea if this is coincidence or if there is an inconsistency between cups 2.2.4 and one or more of those packages.
CC: (none) => jim
(In reply to James Kerr from comment #4) > lib64qpdf17-6.0.0-2.20170730.1.mga6.x86_64 Fri 04 Aug 2017 12:58:35 BST That could be the culprit. Maybe we need to rebuild cups-filters against this qpdf testing version after all (see bug 20915). Can you try: urpmi --searchmedia "Release" --downgrade qpdf lib64qpdf17 (maybe also lib64qpdf-devel and qpdf-doc if there are installed, for consistency)
FWIW evince prints a file that okular fails to print but CUPS still reports filter failed and does not show the job as completed. My printer is HP ENVY 4502 and I am using plasma.
# urpmi --searchmedia "Release" --downgrade qpdf lib64qpdf17 The following package has to be removed for others to be upgraded: lib64qpdf17-6.0.0-2.20170730.1.mga6.x86_64 (in order to install lib64qpdf17-6.0.0-2.mga6.x86_64) (y/N) y installing lib64qpdf17-6.0.0-2.mga6.x86_64.rpm qpdf-6.0.0-2.mga6.x86_64.rpm from /var/ftp/pub/mirror/Mageia/distrib/6/x86_64/media/core/release Preparing... 1/2: lib64qpdf17 2/2: qpdf 1/1: removing lib64qpdf17-6.0.0-2.20170730.1.mga6.x86_64 I restarted CUPS just to be sure. That seems to have corrected the problem. okular, kwrite and LO now print successfully and CUPS web interface shows the jobs as completed jobs. There are no filter failed messages.
Summary: cups does not print => cups does not print due to qpdf security update
Thanks, that confirms the culprit. What we should try now is to rebuild cups-filter against qpdf-6.0.0-2.20170730.1.mga6 and see if that fixes the issue; that qpdf version is a development snapshot, and I guess I should have pushed a cups-filters rebuild to be on the safe side. I'll be away from my dev environment until Sunday evening, so I hope another packager can prepare an update candidate with a rebuild of cups-filters against qpdf. If that's not sufficient, we may need to dig in a bit deeper in what broke qpdf, or revert that qpdf update.
Assignee: thierry.vignaud => pkg-bugsSee Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=20915
Source RPM: cups-2.2.4-1.mga6 => qpdf17-6.0.0-2.20170730.1.mga6
Source RPM: qpdf17-6.0.0-2.20170730.1.mga6 => qpdf-6.0.0-2.20170730.1.mga6
As said Juergen Harms definitve command for workaround is : urpmi --searchmedia "Release" --downgrade cups cups-common cups-filesystem lib64cups2 lib64qpdf17 (or "Release2" if cdrom sources have been deleted.)
Update, as indicated by James Kerr and Remi Verschelde: only downgrading lib64qpdf17 is sufficient: urpmi --searchmedia "Release" --downgrade lib64qpdf17 (and, I put lib64qpdf17 into my /etc/urpmi/skip.list)
CC: (none) => juergen.harms
sudo urpmi --searchmedia "Core Release" --downgrade lib64qpdf17 This downgrade changed the behavior of okular printing a blank page to okular printing the same two pages of a pdf in duplex, thanks. Brother MFC-J5620DW Brother-provided drivers installed via linux-brprinter-installer-2.0.0-1
CC: (none) => rolfpedersen
Not agree with downgrading only lib64qpdf (or libqt on i586). I tested it and If I skip lib64qpdf with urpmi/skip.list, cups upgrades and my printer is lost (hp officejet pro 8600). To prevent I have to downgrade all : urpmi --searchmedia "Release" --downgrade cups cups-common cups-filesystem lib64cups2 lib64qpdf17 and then I have to add in /etc/urpmi/skip/list : lib64qpdf17 /cups/
(In reply to andre salaun from comment #12) > Not agree with downgrading only lib64qpdf (or libqt on i586). I tested it > and If I skip lib64qpdf with urpmi/skip.list, cups upgrades and my printer > is lost (hp officejet pro 8600). > To prevent I have to downgrade all : > > urpmi --searchmedia "Release" --downgrade cups cups-common cups-filesystem > lib64cups2 lib64qpdf17 > > and then I have to add in /etc/urpmi/skip/list : > > > lib64qpdf17 > /cups/ Not libqt of course but libqpdf, sorry
If you're running Cauldron, please test with the cups-filters rebuild (cups-filters-1.14.1-2.mga7) and see if it helps.
Mga6, same problem and solution here (i guess, did not check logs, urgent print) Printer: Canon i-SENSYS LBP 7750Cdn Workaround: Issued as root: urpmi --searchmedia "Release" --downgrade lib64qpdf17 urpmi --searchmedia "Release" --downgrade qpdf urpmi --searchmedia "Release" --downgrade qpdf-doc urpmi --searchmedia "Release" --downgrade lib64qpdf-devel (i had them all) systemctl restart cups And then browsed to https://localhost:631/jobs/ and restarted the jobs and they succeeded.
CC: (none) => fri
I suggest the printing blocking qpdf be removed from updates ASAP - Some people do use Mageia for production ;)
(In reply to Morgan Leijström from comment #16) > I suggest the printing blocking qpdf be removed from updates ASAP > - Some people do use Mageia for production ;) Or better: recompile cups-filters for Mageia 6 as we know this fixes the problem, see bug 21424 comment 11.
I made that but it does not work with cups-filters-1.14.1-2 rebuilded on a mageia6.
We must most importantly ASAP stop pusing printing braking updates to users Correct fix need some testing (takes time) before shipping to updates
Fedora did an update for qpdf too: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/RDER22UZHGCCNSH52ALTIPF4W6YKQKBP/ Are we actually sure we know what the issue is? There seem to be conflicting reports.
(In reply to David Walser from comment #20) > Are we actually sure we know what the issue is? There seem to be > conflicting reports. See comment 8. The qpdf ugprade is the culprit. There are two possible solutions: - 1) rebuild cups-filters against the new qpdf and see if that fixes the issue - 2) if not, revert the qpdf upgrade, or find in the upstream changelog what breaks everything Sadly even though I asked for it nobody cared enough to do 1) by just adding a subrel and pushing to core/updates_testing in 3 days... So I'll have to do it myself tonight.
(In reply to andre salaun from comment #18) > I made that but it does not work with cups-filters-1.14.1-2 rebuilded on a > mageia6. What version of qpdf did you rebuild against? The one of Core Release or the one of Core Updates?
(In reply to Morgan Leijström from comment #19) > We must most importantly ASAP stop pusing printing braking updates to users > > Correct fix need some testing (takes time) before shipping to updates We do what we can. Feel free to get more involved in the QA team and test those updates before we push them.
The re-build of cups-filters in cauldron fixed the problems on my cauldron system. https://bugs.mageia.org/show_bug.cgi?id=21424#c11
cups-filters-1.13.4-2.1.mga6 pushed to Mageia 6 Core Updates Testing, please test it (together with qpdf-6.0.0-2.20170730.1.mga6 and lib64qpdf17-6.0.0-2.20170730.1.mga6 from Core Updates) to confirm that it fixes this bug. Advisory: ========= Updated cups-filters fixes compatibility with qpdf update A security update for qpdf (mga#20915) introduced an incompatibility with Mageia 6's cups-filters, causing issues with most printers. cups-filters was rebuilt against that updated qpdf to fix this mismatch. References: - https://bugs.mageia.org/show_bug.cgi?id=20915 RPMs in core/updates_testing: ============================= cups-filters-1.13.4-2.1.mga6 lib(64)cups-filters1-1.13.4-2.1.mga6 lib(64)cups-filters-devel-1.13.4-2.1.mga6 SRPM in core/updates_testing: ============================= cups-filters-1.13.4-2.1.mga6
Assignee: pkg-bugs => qa-bugsQA Contact: (none) => rverschelde
Just tested as requested in Comment 8 (with lib64qpdf17-6.0.0-2.mga installed): no problems any more, printing works perfectly. Thanks Rémi!
Thank you Rémi! Test OK here on 64 bit mga6: 1) First i let the system update to broken printing by the update applet: It reupgraded the four packages i had downgraded in Comment 15 (incl qpdf-6.0.0-2.20170730.1.mga6 and lib64qpdf17-6.0.0-2.20170730.1.mga6 ) 2) test print got "filter failed" (before this update it was working) 3) installed from updates_testing cups-filters-1.13.4-2.1.mga, which also updated to lib64cups-filters1-1.13.4-2.1.mga6.x86_64 4) browsed to http://localhost:631/jobs/ and i could print the failed job 5) new print of the same page that fail in 2) now succeed immediately.
Whiteboard: (none) => MGA6-64-OK
Thanks for the tests! Since it's just a rebuild and we already have two positive feedback (and the current state is broken), validating.
Whiteboard: MGA6-64-OK => advisory MGA6-64-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGAA-2017-0055.html
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
*** Bug 21467 has been marked as a duplicate of this bug. ***
CC: (none) => joselp