You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
/usr/lib/cups/filter/rastertogutenprint.5.3 crashed on signal 6 #43534
Does a report exist for this bug with the project's home (upstream) and/or another distro?
No response
Expected behaviour
My printer EPSON L121 should work after installing gutenprint, instead it shows stopped "Filter failed" in cups' web interface.
Actual behaviour
Web interface tells: 'stopped "Filter failed"'.
Steps to reproduce
Own an EPSON L121 printer
Setup using the web interface then choose EPSON L120 Series or system-config-printer(this should detect the appropriate driver from gutenprint automatically) .
I think this line's the culprit D [20/Apr/2023:07:24:12 +0800] [Job 25] PID 6869 (/usr/lib/cups/filter/rastertogutenprint.5.3) crashed on signal 6.
Just close if you guys think this is on gutenprint. Just tell me if you need more info.
Same here - Canon PIXMA MG2555S.
I first came across this bud about a year ago and then left Void for a while. Strangely, on Fedora and Ubuntu with this and even previous versions of the Gutenprint package, printing worked.
Same here - Canon PIXMA MG2555S. I first came across this bud about a year ago and then left Void for a while. Strangely, on Fedora and Ubuntu with this and even previous versions of the Gutenprint package, printing worked.
I would like to add my experience with the same problem.
I'm in the process of switching my main computer to Void and one of the issue that was annoying me is that I could not print on my old trusted Canon Pixma MG6200 even if I could configure it through CUPS and Gutenprint. I suffered also from filter error (assertion failed) in rastertogutenprint.
As mentioned by @tomo90 I uninstalled the gutenprint void package and compiled from source. It works now flawlessly.
Either we all miss something in the install/config or there is something wrong in the packaging of the gutenprint drivers. I could try to have a look at it but I fear it is far beyond my current knowledge of this kind of stuff.
When I got this problem, I found it was due to an interaction of void-packages with gutenprint's build system, which led to the path to gutenprint's modules being defined incorrectly as:
This was due to these lines in void-packages which specified libdir on the configure command line in terms of exec_prefix, which gutenprint's configure script put directly into config.h instead of allowing it to have prefix variables substituted.
Hit this on 5.3.5 (and it affects 5.3.4 as shipped): rastertogutenprint
SIGABRTs at startup because the default --libdir=${exec_prefix}/lib64 is
never expanded, so files land in a literal "lib64" directory.
Fixed on my side by appending --libdir=/usr/lib to configure_args (plus
pkg-config in hostmakedepends). After the rebuild: no /usr/lib64 paths in
the filelist, libgutenprint.so.9 lands in /usr/lib, cups-genppd.5.3 -M
lists 3604 printer models, and rastertogutenprint exits cleanly instead
of aborting. Tested on x86_64, template bumped 5.3.4 → 5.3.5
(checksum f5a9f47…).
No PR attached — just leaving the findings here in case they're useful
to anyone hitting the same crash.
@enricopitea This is the issue that the upstream change I mentioned above was intended to fix. With it, manually setting $(libdir) in configure_args should be unnecessary. Have you tried building the package at ac17550 ? This commit worked for me.
Activity
triallax commentedon Apr 21, 2023
Seems like this has already been reported upstream, with no real progress so far: https://sourceforge.net/p/gimp-print/bugs/734/?limit=25
tomo90 commentedon May 3, 2023
Same here - Canon PIXMA MG2555S.
I first came across this bud about a year ago and then left Void for a while. Strangely, on Fedora and Ubuntu with this and even previous versions of the Gutenprint package, printing worked.
triallax commentedon May 3, 2023
You might want to try to comment on the upstream issue (https://sourceforge.net/p/gimp-print/bugs/734/?limit=25) with your printer and system information, perhaps they would be able to help fix your issue.
fjbaldon commentedon May 4, 2023
Works on openSUSE MicroOS too
tomo90 commentedon Jul 3, 2023
Today I uninstalled the Void's gutenprint package (5.3.4) and compiled it from source - printing started working
used just default
https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.4/gutenprint-5.3.4.tar.bz2/download
Also tried compiling previous versions 5.3.3 and 5.2.15 - those work aswell
https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.3/gutenprint-5.3.3.tar.xz/download
https://sourceforge.net/projects/gimp-print/files/gutenprint-5.2/5.2.15/gutenprint-5.2.15.tar.bz2/download
pondichys commentedon Aug 30, 2023
I would like to add my experience with the same problem.
I'm in the process of switching my main computer to Void and one of the issue that was annoying me is that I could not print on my old trusted Canon Pixma MG6200 even if I could configure it through CUPS and Gutenprint. I suffered also from filter error (assertion failed) in rastertogutenprint.
As mentioned by @tomo90 I uninstalled the gutenprint void package and compiled from source. It works now flawlessly.
Either we all miss something in the install/config or there is something wrong in the packaging of the gutenprint drivers. I could try to have a look at it but I fear it is far beyond my current knowledge of this kind of stuff.
Thanks for the great distribution that is Void.
Gorggg commentedon Mar 19, 2025
This should now be fixed in the 5.3.5 release (pull request #54678), which includes this fix:
https://sourceforge.net/p/gimp-print/source/merge-requests/10/
When I got this problem, I found it was due to an interaction of void-packages with gutenprint's build system, which led to the path to gutenprint's modules being defined incorrectly as:
This was due to these lines in void-packages which specified libdir on the configure command line in terms of exec_prefix, which gutenprint's configure script put directly into config.h instead of allowing it to have prefix variables substituted.
enricopitea commentedon Sep 6, 2026
Hit this on 5.3.5 (and it affects 5.3.4 as shipped): rastertogutenprint
SIGABRTs at startup because the default --libdir=${exec_prefix}/lib64 is
never expanded, so files land in a literal "lib64" directory.
Fixed on my side by appending --libdir=/usr/lib to configure_args (plus
pkg-config in hostmakedepends). After the rebuild: no /usr/lib64 paths in
the filelist, libgutenprint.so.9 lands in /usr/lib, cups-genppd.5.3 -M
lists 3604 printer models, and rastertogutenprint exits cleanly instead
of aborting. Tested on x86_64, template bumped 5.3.4 → 5.3.5
(checksum f5a9f47…).
No PR attached — just leaving the findings here in case they're useful
to anyone hitting the same crash.
Gorggg commentedon Sep 6, 2026
@enricopitea This is the issue that the upstream change I mentioned above was intended to fix. With it, manually setting
$(libdir)inconfigure_argsshould be unnecessary. Have you tried building the package at ac17550 ? This commit worked for me.