There is an openQA test which opens a text editor, types some text, then prints it to a PDF file, opens the PDF file, and makes sure it looks right. Since Ghostscript 9.54.0 landed in Rawhide, it does not: the PDF file is just a blank page. This affects both KDE and GNOME. It broke on both KDE and GNOME in Fedora-Rawhide-20210517.n.0 , which is exactly the compose where ghostscript-9.54.0-1.fc35 landed. To reproduce: run gedit (GNOME) or kwrite (KDE), type some text, print it to PDF, and open the PDF. Proposing as a Fedora 35 Final blocker as a violation of "Printing must work in release-blocking desktops on at least one printer using each of the following drivers: The built-in print-to-PDF driver..." - https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Printing
(In reply to Adam Williamson from comment #0) > There is an openQA test which opens a text editor, types some text, then > prints it to a PDF file, opens the PDF file, and makes sure it looks right. > > Since Ghostscript 9.54.0 landed in Rawhide, it does not: the PDF file is > just a blank page. This affects both KDE and GNOME. It broke on both KDE and > GNOME in Fedora-Rawhide-20210517.n.0 , which is exactly the compose where > ghostscript-9.54.0-1.fc35 landed. > > To reproduce: run gedit (GNOME) or kwrite (KDE), type some text, print it to > PDF, and open the PDF. > > Proposing as a Fedora 35 Final blocker as a violation of "Printing must work > in release-blocking desktops on at least one printer using each of the > following drivers: The built-in print-to-PDF driver..." - > https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Printing Yes, ghostscript is broken in rawhide due to missing dependencies: On a fresh install, you'll be missing ghostscript-{tools-printing,tools-fonts}. (Apparently, the new matinainer tried a bit too much in one go.) That update has been unpushed from F3{2,3,4}. A possible fix for F35 is sitting in an extra branch in dist-git, but that's all I know. In any case, this bug should be fixed if #1962993 is. You can confirm by doing `dnf install ghostscript-{tools-printing,tools-fonts}` and doing the QA test then.
Hum - I did see that bug, but from the description it wasn't immediately obvious that it would affect a *fresh* install, it read more as if it was about upgrades only. If it's the same problem, though, we can combine them. I'll look into it a bit more later. Thanks!
Risa, would you mind verifying if your proposed fix from the private branch fixes the issue? Thank you!
Hi, Thank you for your report. I'll try to reproduce the problem and verify if the problem is because of the missing ghostscript-tools. If so, it should be fixed, as Michael said, with fix for a broken gs update soon.
Hello Adam, could you please let me know which gs packages do you have installed by rpm -qa | grep ghostscript and rpm -q libgs. Also could you verify that you have same problem on current rawhide? I've tried to reproduce your problem on rawhide with ghsotscript 9.54 and without ghostscript-tools-* packages and didn't encounter the problem with gedit. Thanks.
openQA tests every Rawhide compose when it finishes, and tests with whatever packages are in the compose. It does a default install of the Workstation live and KDE live, installs cups-pdf, and then runs the test. The latest update for F34 - https://bodhi.fedoraproject.org/updates/FEDORA-2021-41049aa9ae - causes the problem to start happening there too.
I pulled the log of installed packages from a failed test of the F33 update, it is: libgs-9.54.0-2.fc33.x86_64 ghostscript-9.54.0-2.fc33.x86_64 ghostscript-tools-fonts-9.54.0-2.fc33.x86_64 ghostscript-tools-printing-9.54.0-2.fc33.x86_64
(In reply to Adam Williamson from comment #6) > It does a default install of the Workstation live and KDE live, installs cups-pdf, Aha, that would be good to mention in the initial report - currently GTK provides their native 'Print to File' 'print queue', which works regardless of ghostscript, and the initial report looked like the test is using 'Print to File'. cups-pdf is a different component outside of cups and ghostscript, we'll try to reproduce it with cups-pdf then. But I'm not sure whether the bug can still be marked as a final blocker, since printing to PDF (though via different means and only in GTK apps) works. (In reply to Adam Williamson from comment #7) > I pulled the log of installed packages from a failed test of the F33 update, > it is: > > libgs-9.54.0-2.fc33.x86_64 > ghostscript-9.54.0-2.fc33.x86_64 > ghostscript-tools-fonts-9.54.0-2.fc33.x86_64 > ghostscript-tools-printing-9.54.0-2.fc33.x86_64 So it seems it is not connected to ghostscript-core removal.
The original report mentioned that both Gnome and KDE were affected. Is this still true with the compose which has 9.54.0-2 (and, thus, the tools-* packages)?
(In reply to Michael J Gruber from comment #9) > The original report mentioned that both Gnome and KDE were affected. Is this > still true with the compose which has 9.54.0-2 (and, thus, the tools-* > packages)? Yes, I'm able to reproduce the issue on Fedora Workstation and via cups-pdf. How to reproduce: - have cups running - we need this because cups-pdf install its print queue via lpadmin during its installation scriptlet and it is done only when cups.service is running - install cups-pdf - open gedit, type something, print to 'Cups-PDF' print queue - there is an empty pdf in ~/Desktop After I turned on cups debugging ($ cupsctl --debug-logging) I saw in logs: Jun 03 08:56:05 fedora cupsd[29141]: [Job 3] PID 29708 (gs) exited with no errors. Jun 03 08:56:05 fedora cupsd[29141]: [Job 3] PID 29706 (/usr/lib/cups/filter/pdftops) exited with no errors. Jun 03 08:56:06 fedora cupsd[29141]: [Job 3] GPL Ghostscript 9.54.0: Unrecoverable error, exit code 1 Jun 03 08:56:06 fedora cupsd[29141]: [Job 3] PID 29707 (/usr/lib/cups/backend/cups-pdf) exited with no errors. However, cups doesn't show any error - all its filters ended with no errors, so I got a suspicion that gs error might come from cups-pdf backend (and cups-pdf doesn't send a proper error code or logs to cups logging unit...) When I turned on cups-pdf debugging in /etc/cups/cups-pdf.conf I saw in /var/log/cups/cups-pdf-Cups-PDF-log: Thu Jun 3 08:39:18 2021 [STATUS] PDF creation successfully finished Thu Jun 3 08:49:09 2021 [STATUS] PDF creation successfully finished Thu Jun 3 08:56:06 2021 [ERROR] ghostscript reported an error Thu Jun 3 08:56:06 2021 [STATUS] PDF creation successfully finished . . . Thu Jun 3 09:08:50 2021 [DEBUG] output filename created: /home/user/Desktop/Untitled_File_1.pdf Thu Jun 3 09:08:50 2021 [DEBUG] ghostscript commandline built: /usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/home/user/Desktop/Untitled_File_1.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-30113 Thu Jun 3 09:08:50 2021 [DEBUG] output file unlinked: /home/user/Desktop/Untitled_File_1.pdf When I took the ghostscript command line and tried to run it separately, I got: $ /usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/home/user/Desktop/Untitled_File_1.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-30113 Error: /undefined in .setpdfwrite Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:736/1123(ro)(G)-- --dict:0/20(G)-- --dict:75/200(L)-- Current allocation mode is local GPL Ghostscript 9.54.0: Unrecoverable error, exit code 1 Risa told me then .setpdfwrite was removed in ghostscript-9.54.0, so cups-pdf should substitute the option in their GS call. IIRC Risa already solved this in several test, so he can provide more information how to migrate. We're sorry about the issue, we haven't realized cups-pdf uses the option. gs-9.54 will be reverted from F33 and F34 to be sure there isn't any other breakage in stable releases.
Thanks for the detailed analysis (and sorry for the wrong pointer). The following has been there since gs 9.50 already: **** WARNING: The .setpdfwrite operator has been deprecated and will be removed entirely in the next release of Ghostscript. The functionality of this operator has been reduced to increasing the size of the VM threshold. If you believe you have a real need for this then you should replace your call to .setpdfwrite with: 3000000 setvmthreshold So, I'm not sure we should blame the gs update here... Scripts which ignored the warning will break at some point. Since the warning turns into an error with gs 9.54 this may prevent a push to stable releases, although Artifex themselves do not consider that an incompatible change - after all, the operator has been deprecated since 9.50. BTW: The fix is to omit `-c .setpdfwrite`, this should work in most cases, unless you really need more memory and you do `-c 3000000 setvmthreshold`.
(In reply to Michael J Gruber from comment #11) > So, I'm not sure we should blame the gs update here... Scripts which ignored > the warning will break at some point. > IMO it would be great if an email was sent to fedora devel about option's removal and ask maintainers of dependent packages to update their scripts if we know there is a removal. Or (more proactive way) - find out which packages require ghostscript+ghostscript-core and 'grep' their sources for the affected option. If the option is present, file them a bug for its removal, give them a deadline for changing the script in case of some unresponsive maintainers, and push the new ghostscript afterwards. The bottom line of the idea is to give maintainers a chance to repair their scripts before the rebase is pushed in and breaks stuff. (I know, there will be still a grey zone of packages, which escape those means mentioned above, but IMO it is better than breaking it for everyone). > Since the warning turns into an error with gs 9.54 this may prevent a push > to stable releases, although Artifex themselves do not consider that an > incompatible change - after all, the operator has been deprecated since 9.50. Unfortunately, I'm afraid of other 'hidden treasures' - we found out cups-pdf thanks to openqa, but there can be other packages in stable, which depends on the removed option. IMHO we shouldn't go for rebase to 9.54.0 in stable release, unless 'the more proactive way' is done in those releases - then we can be certain we don't break something else. And it would be great if it was done for rawhide too. > > BTW: The fix is to omit `-c .setpdfwrite`, this should work in most cases, > unless you really need more memory and you do `-c 3000000 setvmthreshold`. Thank you for the fix! It will help cups-pdf maintainer a lot!
FEDORA-2021-4107a2a3d7 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4107a2a3d7
FEDORA-2021-e5efc6c874 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e5efc6c874
"Aha, that would be good to mention in the initial report" Yeah, sorry, I had actually forgotten that it does that. :D I don't recall why, actually. I'll have to check. But hey, it found a bug...
BTW, it would have been better to add the fixed cups-pdf to the ghostscript update than to submit it separately. Now the ghostscript update cannot be pushed stable till after the cups-pdf update is, because the tests will not pass for ghostscript till cups-pdf is in stable.
(In reply to Adam Williamson from comment #16) > BTW, it would have been better to add the fixed cups-pdf to the ghostscript > update than to submit it separately. Now the ghostscript update cannot be > pushed stable till after the cups-pdf update is, because the tests will not > pass for ghostscript till cups-pdf is in stable. Sorry, I have never coordinated side tags for coordinated updates. I can still cancel the update request.
Bodhi is unfortunately a bit dumb about this situation. I'm dealing with it, in the dumb way that's the only choice: rebuild the package with no changes and obsolete the single-package update.
FEDORA-2021-738a7a9c2b has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-738a7a9c2b
So the tests are still failing because somehow now the update changes the *default output location* for cups-pdf. It used to default to ~/Desktop/(whateverfilename).pdf ; it now defaults to just ~/(whateverfilename).pdf . I could change openQA to handle that, but it seems like an unexpected and possibly unintentional change?
FEDORA-2021-41049aa9ae has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-41049aa9ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-41049aa9ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-738a7a9c2b has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-738a7a9c2b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-738a7a9c2b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Adam, As I wrote in comment#12, I cannot recommend pushing the new ghostscript down to the stable releases (we don't know for sure what other packages in the wild will be broken by '.setpdfwrite' removal), but the final word has Risa as the main admin. IMHO the correct course of action for now would be to let the new gs in rawhide and at least announce the '.setpdfwrite' removal on devel list. We would need to do further investigation in case of stable releases to prevent regressions. Risa did updates for F33 and F34 after I recommended him to do so, but I wasn't informed that there is a option removal which can break scripts.
Ah, well I don't disagree with you there. Sorry, didn't realize you intended the unpush to be permanent and not just until cups-pdf was fixed. I'll unpush the new update and put cups-pdf on its own again.
FEDORA-2021-41049aa9ae has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-41049aa9ae
*** Bug 1967791 has been marked as a duplicate of this bug. ***
(In reply to Adam Williamson from comment #25) > Ah, well I don't disagree with you there. Sorry, didn't realize you intended > the unpush to be permanent and not just until cups-pdf was fixed. I wouldn't say permanently, but only till at least some stupid 'grep' checkup is done over dependent packages in stable. I don't mind pushing new gs into stable Fedoras once we are sure other Fedora packages don't use the removed option, but we aren't there yet. > > I'll unpush the new update and put cups-pdf on its own again. Thanks! The updated cups-pdf can arrive earlier or at the same time as new gs - the updated cups-pdf works even with old gs, so that's fine, the only problem with cups-pdfxgs happens if gs arrives earlier :) I'll try to verify whether there aren't other breakages next week, and if not, I or Risa will contact you about adding the new gs to cups-pdf update (if it won't be in stable already).
(In reply to Adam Williamson from comment #21) > So the tests are still failing because somehow now the update changes the > *default output location* for cups-pdf. It used to default to > ~/Desktop/(whateverfilename).pdf ; it now defaults to just > ~/(whateverfilename).pdf . > > I could change openQA to handle that, but it seems like an unexpected and > possibly unintentional change? The output is still at ${DESKTOP}. The change is to the Label configuration variable in order to add a suffix to every generated filename (-job_#) in order to close bugs where the user reports file previously printed being overwritten Bug #1419308.
ah, okay. Will it always be -job_1 (or _01 or _001 or whatever) for the first time it's used on a given system?
IIRC it uses CUPS job id, so in a testing environment with a clean CUPS with the printer recently added I expect to it always be the same.
FEDORA-2021-41049aa9ae has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-738a7a9c2b has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.