Description of problem: Attempted print to the virtual printer boomaga: § a pdf from Okular § from java program FriBok In both cases boomaga main window comes up, then a "Boomaga <2>" named popup saying: " I can't start gs converter: "GPL Ghostscript 10.00.0: Unrecoverable error, exit code 1 " What works: Printing same document using Okular to a network printer works. Printing a test page from MCC printer settings to boomaga also works. Version-Release: boomaga-3.0.0-5.mga9.src.rpm
Possibly a fix: https://github.com/Boomaga/boomaga/pull/108 Suggested by https://bugs.launchpad.net/ubuntu/+source/lazarus/+bug/1949192
Most applications can print to Boomaga successfully, like Kwrite, Firefox, LibreOffice, Gimp... But not the two I first tried... :^|
Summary: Boomaga fail to render => Boomaga fail to use GhostScript when printing from some programs, i.e Okular
"Error when printing from Okular" https://github.com/Boomaga/boomaga/issues/110 They thought it got fixed before: https://github.com/Boomaga/boomaga/issues/107 For errata: Acknowledge the problem and suggest alternative program(s)/methods, like for printing pdf to boomaga use another program than Okular.
Keywords: (none) => FOR_ERRATA9
should be fixed in next boomaga-3.0.0-6.mga9 update, including the possibly fix: https://github.com/Boomaga/boomaga/pull/108
CC: (none) => geiger.david68210
Thank you David! Tested OK printing to this Boomaga version from Okular and my Invoicing program (did not work per comment 0) as well as other applications, and printing from Boomaga to real network printer. Problem: It do however crash randomly/seldom. Tried printing invoice 2102, Boomaga window came up but a second later when i expect it to show the rendered page it crashed and vanished. Tried the same again and it did not crash. Similar for pdf (not tied to one document) printed from Okular to Boomaga. Tried several times, closing Boomaga in between (when it did not crash), it crash in maybe 2 of ten times. So far, it did not crash if i start Boomaga before printing to it. Tried printing from Evince to Boomaga, one of same pdf tested with Okular, and it did not crash, tested twelve times, closing Boomaga in between. It never crashed on mga8. __Verdict: In my opinion, current state is good enough (we already do better than some other distros) with a note in errata that Boomaga crash when printing to it from some applications, notably Okular, and workarounds are 1) just try again, 2) launch Boomaga first, 3) use another application. - But if you want to have a go at it, tell me how to test more. ------ I see it report an issue when starting: does it optimally need a directory specified or created for it? $ LC_ALL=C boomaga Failed to create for shader cache (No such file or directory)---disabling. (I wonder what it intended to say between the spaces in "create for". File?)
Assignee: bugsquad => geiger.david68210Keywords: (none) => feedbackSummary: Boomaga fail to use GhostScript when printing from some programs, i.e Okular => Boomaga sometimes crash when printing to it from some programs, i.e Okular
Source RPM: boomaga-3.0.0-5.mga9.src.rpm => boomaga-3.0.0-6.mga9.src.rpm
I commented at https://github.com/Boomaga/boomaga/issues/110, linking here. I entered this issue in our errata under https://wiki.mageia.org/en/Mageia_9_Errata#Printing
URL: (none) => https://github.com/Boomaga/boomaga/issues/110Keywords: FOR_ERRATA9 => IN_ERRATA9, UPSTREAM
@Morgan something to look into: If you recall, the update process for boomaga can be problematic, depending on if the printer is or is not installed when the update is done. Upgrading an existing install with boomaga can also be a problem where the original boomaga isn't removed, so that there will be two of them installed. That happened with mga7->mga8 upgrades, and I have seen it with mga8->mga9 upgrades, as well. I suspect that having two or more boomaga versions installed could be highly confusing to the system. I would check for multiple boomagas. If you find them, remember that you will not be able to remove the wrong one with MCC. It will look like it happens, but when you go back it will still be installed. I'd recommend removing the boomaga printer with system-config-printer (MCC), then use "urpme --noscripts boomaga" to remove all of the boomaga packages. (Or you can modify the rpm command from https://wiki.mageia.org/en/Mageia_8_Errata#Various_upgrade_issues if you prefer) Then you can re-install the one you want and re-install it to the system with system-config-printer in MCC. BTW, we should probably add the boomaga upgrade issue from mga8 errata to mga9 errata if it isn't already there,(properly modified) since it is also an issue with those upgrades.
CC: (none) => andrewsfarm
I have so far only tested clean install. For Mageia upgrade issues like bug 28419 for mga7 -> 8 please open a new for mga8 -> 9, referring to that bug, CC me and Dave Hodgins, and set it for errata for now. (crap, we thought it was solved...)
If you read through bug 28419 to the end, you'll see the issue of the old boomaga not being removed when upgrading using the CI was never really "fixed." Dave Hodgins determined that cups had to be running for it to happen, and there's just no way for that to happen from the CI. Upgrades using urpmi might be working OK now, as cups would be running. For CI upgrades we settled for advising users to remove boomaga before the upgrade and then installing again after, and giving them a command to use that would remove the old boomaga if they missed that advice and found themselves with it installed. That situation would still exist with a mga8->mga9 upgrade from the CI, as far as I know. I suppose it might have been fixed upstream by now, if the boomaga developers were so inclined. I will set up a vbox guest that will check just that issue without other distractions to be sure.
OK, thanks. I now corrected mga8 errata. Please check mga8->9, and reopen that relevant bug (or create a new). This bug we write in here is not for that issue. I can make the mga9 errata edit when you have checked.