Attempts to print a CUPS test page on a Canon MF217w (from the Canon MF210 series) fail silently. Reproducible: Always Steps to Reproduce: 1. Add a Canon MF217w network printer in CUPS. The printer is automatically detected on the network. Choose the Canon MF210 series (en) driver. 2. Attempt to print a test page. Actual Results: The job fails silently (it appears in the CUPS completed jobs list). The following error message appears in /var/log/cups/error_log: E [12/Apr/2020:15:58:17 -0600] [Job 5] src = bidiCommon.c, line = 628, err = 0¥nERROR: src = bidiCommon.c, line = 655, err = 1¥nERROR: src = bidiCommon.c, line = 1873, err = 0¥nERROR: src = libcanon_pdlwrapper.c, line = 634, err = -1¥nERROR: src = libcanon_pdlwrapper.c, line = 345, err = 0¥nINFO: Processing page 2... Expected Results: The test page prints. Users of other distributions have encountered similar problems with the Canon drivers, and apparently the answer is often to use 32-bit versions of the dependencies. But it seems mad to me that in 2020 Canon would still be allowing these dependencies for 64-bit versions of the driver. See https://askubuntu.com/questions/418215/error-with-canon-imageclass-d480-driver-in-ubuntu-12-04-x64 for an example.
Created attachment 632556 [details] emerge --info
First thing: Does it work with net-print/cndrvcups-lb? (Note the difference with net-print/cnrdrvcups-lb) 2ndly does installing media-libs/libjpeg-turbo help? I've seen people report weird problems that are fixed after installing libjpeg-turbo, however I haven't found out which part of these Canon drivers depends on that. Still under investigation (however it might be some dependency of dependency thing).
(In reply to Joonas Niilola from comment #2) > First thing: Does it work with net-print/cndrvcups-lb? (Note the difference > with net-print/cnrdrvcups-lb) > > 2ndly does installing media-libs/libjpeg-turbo help? I've seen people report > weird problems that are fixed after installing libjpeg-turbo, however I > haven't found out which part of these Canon drivers depends on that. Still > under investigation (however it might be some dependency of dependency > thing). When I attempt to install cndrvcups-lb, I get the following output: # emerge -1av cndrvcups-lb * IMPORTANT: 6 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-libs/zlib-1.2.11-r2:0/1::gentoo USE="minizip (split-usr) -static-libs" ABI_X86="32* (64) (-x32)" 0 KiB [ebuild R ] dev-libs/icu-65.1-r1:0/65.1::gentoo USE="-debug -doc -examples -static-libs" ABI_X86="32* (64) (-x32)" 0 KiB [ebuild R ] dev-libs/libxml2-2.9.9-r3:2::gentoo USE="icu ipv6 python readline -debug -examples -lzma -static-libs -test" ABI_X86="32* (64) (-x32)" PYTHON_TARGETS="python2_7 python3_6 -python3_7 (-python3_8)" 0 KiB [ebuild N ~] net-print/cndrvcups-common-lb-3.70::gentoo 0 KiB [ebuild N ~] net-print/cndrvcups-lb-3.70::gentoo 0 KiB Total: 5 packages (2 new, 3 reinstalls), Size of downloads: 0 KiB The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by net-print/cndrvcups-lb-3.70::gentoo # required by cndrvcups-lb (argument) >=dev-libs/libxml2-2.9.9-r3 abi_x86_32 # required by dev-libs/libxml2-2.9.9-r3::gentoo # required by net-print/cndrvcups-common-lb-3.70::gentoo # required by net-print/cndrvcups-lb-3.70::gentoo # required by cndrvcups-lb (argument) >=sys-libs/zlib-1.2.11-r2 abi_x86_32 # required by dev-libs/libxml2-2.9.9-r3::gentoo[icu] # required by net-print/cndrvcups-common-lb-3.70::gentoo # required by net-print/cndrvcups-lb-3.70::gentoo # required by cndrvcups-lb (argument) >=dev-libs/icu-65.1-r1 abi_x86_32 The following license changes are necessary to proceed: (see "package.license" in the portage(5) man page for more details) # required by cndrvcups-lb (argument) >=net-print/cndrvcups-lb-3.70 Canon-UFR-II # required by net-print/cndrvcups-lb-3.70::gentoo # required by cndrvcups-lb (argument) >=net-print/cndrvcups-common-lb-3.70 Canon-UFR-II Would you like to add these changes to your config files? [Yes/No] n It wants 32-bit versions of these dependencies (dev-libs/libxml2, sys-libs/zlib, dev-libs/icu). I already have these installed (and working) and I don't want to go back to 32-bit versions (especially not icu!). Also, the driver Canon recommends for the MF217w is the UFR II v 5.10. I had started working on an ebuild for this driver and had spent many hours on it before I discovered your ebuild (thanks for your work on this!). The driver naming is confusing. I think it would be best to combine all the ebuilds and have a common, intuitive name for all the UFR II drivers; net-print/cndrvcups-lb and net-print/cndrvcups-common-lb are without a package maintainer at the moment anyway. I already had libjpeg-turbo installed when I tested this: [I] media-libs/libjpeg-turbo Available versions: 1.5.3-r2 2.0.3 2.0.4 {java static-libs ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64 lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" ELIBC="FreeBSD"} Installed versions: 2.0.4(19:20:41 03/30/20)(-java -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" ELIBC="-FreeBSD") Homepage: https://libjpeg-turbo.org/ https://sourceforge.net/projects/libjpeg-turbo/ Description: MMX, SSE, and SSE2 SIMD accelerated JPEG library My suspicion is that if libjpeg-turbo resolves this, it will be because a 32-bit version was installed. Are you using all 64-bit versions of your dependencies? I thought 5.10 was supposed to have full 64-bit support.
I run a full multilib system for convenience, but yes, 5.00 _should_ be pure 64-bit by Canon. Although they provide some pre-built binaries, it doesn't look to me like it calls anything from /usr/lib32 One thing that does come to mind are dosym ../../../$(get_libdir)/cups/backend/cnusb /usr/libexec/cups/backend/cnusb dosym ../../../$(get_libdir)/cups/filter/pdftocpca /usr/libexec/cups/filter/pdftocpca dosym ../../../$(get_libdir)/cups/filter/rastertoufr2 /usr/libexec/cups/filter/rastertoufr2 that are rather hacky, but you seem to be using 17.1 profile so it should work for you. I think initially this was broken on 17.0 profile. Still I could suspect some of these may be broken for you.
(In reply to Joonas Niilola from comment #4) > I run a full multilib system for convenience, but yes, 5.00 _should_ be pure > 64-bit by Canon. Although they provide some pre-built binaries, it doesn't > look to me like it calls anything from /usr/lib32 > > One thing that does come to mind are > dosym ../../../$(get_libdir)/cups/backend/cnusb > /usr/libexec/cups/backend/cnusb > dosym ../../../$(get_libdir)/cups/filter/pdftocpca > /usr/libexec/cups/filter/pdftocpca > dosym ../../../$(get_libdir)/cups/filter/rastertoufr2 > /usr/libexec/cups/filter/rastertoufr2 > > that are rather hacky, but you seem to be using 17.1 profile so it should > work for you. I think initially this was broken on 17.0 profile. Still I > could suspect some of these may be broken for you. The symlinks seem to be ok: # ls -liah /usr/libexec/cups/filter/pdftocpca 664682 lrwxrwxrwx 1 root root 36 13. Apr 07:39 /usr/libexec/cups/filter/pdftocpca -> ../../../lib64/cups/filter/pdftocpca # ls -liah /usr/libexec/cups/filter/rastertoufr2 664683 lrwxrwxrwx 1 root root 39 13. Apr 07:39 /usr/libexec/cups/filter/rastertoufr2 -> ../../../lib64/cups/filter/rastertoufr2 # ls -liah /usr/lib64/cups/filter/ total 44K 12716194 drwxr-xr-x 2 root root 4.0K Apr 13 07:39 . 12716192 drwxr-xr-x 4 root root 4.0K Apr 13 07:39 .. 8285241 -rwxr-xr-x 1 root root 14K Apr 13 07:39 pdftocpca 8285234 -rwxr-xr-x 1 root root 19K Apr 13 07:39 rastertoufr2 # ls -liah /usr/libexec/cups/backend/cnusb 393227 lrwxrwxrwx 1 root root 33 13. Apr 07:39 /usr/libexec/cups/backend/cnusb -> ../../../lib64/cups/backend/cnusb # ls -liah /usr/lib64/cups/backend/ total 28K 12716193 drwxr-xr-x 2 root root 4.0K Apr 13 07:39 . 12716192 drwxr-xr-x 4 root root 4.0K Apr 13 07:39 .. 8286906 -rwxr-xr-x 1 root root 19K Apr 13 07:39 cnusb What component is generating the error message in error_log? How can we verify that the pre-built binaries in use are the correct ones? Have you tested the ebuild on a 64-bit system with 64-bit libraries? Have you got 32-bit dependencies for net-print/cnrdrvcups-lb installed? I'm not suggesting that an ABI conflict must be the only possible cause of the problem I am observing. But I can't make any sense of the error message in CUPS and it appears similar to a problem others have encountered in which the solution was getting 32-bit dependencies, see the description. If we could trace the error in more detail it might give us useful clues.
Well I think your only options here are: 1: test cndrvcups-lb, 2: try to install multilibbed dependencies and use cnrdrvcups-lb, 3: run ldd/scanelf on every library & binary of cnrdrvcups-lb. Indeed it looks like people are having problems on a pure 64-bit systems, but when I ldd'd few of the libraries and binaries, everything seemed to be ok here. $ file /usr/lib64/libcanonufr2r.so.1.0.0 /usr/lib64/libcanonufr2r.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, stripped however the static linking which was a surprise to me may cause some issues. ldd looks fine for me though, but you may find some missing deps through it. I may have to spin up some pure 64bit qemu image too, but doubt I'll have time for that before next weekend.
Created attachment 636064 [details] ebuild with new path assignment for cnpkbidir_info files Hi Joonas, I think I've located the source of the error. You are right about the driver being pure 64-bit. The error message has nothing to do with that. After turning on log-level debugging with 'cupsctl --debug-logging' and printing a test page, I see this in error_log: D [04/May/2020:12:50:53 -0600] [Job 10] Start rendering... D [04/May/2020:12:50:53 -0600] cupsdMarkDirty(---J-) D [04/May/2020:12:50:53 -0600] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files" D [04/May/2020:12:50:53 -0600] [Job 10] Set job-printer-state-message to "Start rendering...", current level=INFO D [04/May/2020:12:50:53 -0600] [Job 10] Processing page 1... D [04/May/2020:12:50:53 -0600] cupsdMarkDirty(---J-) D [04/May/2020:12:50:53 -0600] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files" D [04/May/2020:12:50:53 -0600] [Job 10] Set job-printer-state-message to "Processing page 1...", current level=INFO D [04/May/2020:12:50:53 -0600] Discarding unused job-progress event... D [04/May/2020:12:50:53 -0600] Discarding unused printer-state-changed event... D [04/May/2020:12:50:54 -0600] [Job 10] I/O warning : failed to load external entity \"/usr/share/cnpkbidir/cnpkbidir_info_004.xml\" D [04/May/2020:12:50:54 -0600] [Job 10] PID 11993 (/usr/libexec/cups/filter/rastertoufr2) did not catch or ignore signal 13. D [04/May/2020:12:50:54 -0600] [Job 10] PID 11994 (/usr/libexec/cups/backend/socket) exited with no errors. E [04/May/2020:12:50:54 -0600] [Job 10] src = bidiCommon.c, line = 628, err = 0¥nERROR: src = bidiCommon.c, line = 655, err = 1¥nERROR: src = bidiCommon.c, line = 1873, err = 0¥nERROR: src = libcanon_pdlwrapper.c, line = 634, err = -1¥nERROR: src = libcanon_pdlwrapper.c, line = 345, err = 0¥nINFO: Processing page 2... D [04/May/2020:12:50:54 -0600] cupsdMarkDirty(---J-) D [04/May/2020:12:50:54 -0600] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files" D [04/May/2020:12:50:54 -0600] [Job 10] Set job-printer-state-message to "src = bidiCommon.c, line = 628, err = 0¥nERROR: src = bidiCommon.c, line = 655, err = 1¥nERROR: src = bidiCommon.c, line = 1873, err = 0¥nERROR: src = libcanon_pdlwrapper.c, line = 634, err = -1¥nERROR: src = libcanon_pdlwrapper.c, line = 345, err = 0¥nINFO: Processing page 2...", current level=ERROR D [04/May/2020:12:50:54 -0600] Discarding unused job-progress event... D [04/May/2020:12:50:54 -0600] Discarding unused printer-state-changed event... D [04/May/2020:12:50:54 -0600] [Job 10] Rendering completed The clue is D [04/May/2020:12:50:54 -0600] [Job 10] I/O warning : failed to load external entity \"/usr/share/cnpkbidir/cnpkbidir_info_004.xml\" D [04/May/2020:12:50:54 -0600] [Job 10] PID 11993 (/usr/libexec/cups/filter/rastertoufr2) did not catch or ignore signal 13. D [04/May/2020:12:50:54 -0600] [Job 10] PID 11994 (/usr/libexec/cups/backend/socket) exited with no errors. (Canon drivers are notorious for non-existent error messages.) The issue is that something (rastertoufr2?) expects to find cnpkbidir_info_004.xml in /usr/share/cnpkbidir. The ebuild places it in /usr/share/caepcm/ufr2. After creating a symlink: ln -s /usr/share/caepcm/ufr2 /usr/share/cnpkbidir and restarting cupsd, printing a new test page is successful. At this point I have a confession to make. I am using a slightly modified version of the ebuild that takes the most current version of the UFR2 tarball. I did this because I have a Canon MF210 series printer. This could explain the path conflict. I've updated my ebuild so that the cnpkbidir_info files are placed into the expected directory. I've attached it. Can you test it on your end and see if it works for you?
(In reply to Stephen Bosch from comment #7) > > After turning on log-level debugging with 'cupsctl --debug-logging' and > printing a test page, I see this in error_log: > > The issue is that something (rastertoufr2?) expects to find > cnpkbidir_info_004.xml in /usr/share/cnpkbidir. The ebuild places it in > /usr/share/caepcm/ufr2. > > After creating a symlink: > > ln -s /usr/share/caepcm/ufr2 /usr/share/cnpkbidir > > and restarting cupsd, printing a new test page is successful. Heh, good job. I've tried following the included "install.sh" as close to possible. Well basically the ebuild is install.sh written so portage can manage the files. It could be that it's been updated, or wrong upstream. > > At this point I have a confession to make. I am using a slightly modified > version of the ebuild that takes the most current version of the UFR2 > tarball. I did this because I have a Canon MF210 series printer. This could > explain the path conflict. > > I've updated my ebuild so that the cnpkbidir_info files are placed into the > expected directory. *Sigh* I wasn't aware they update their drivers with uken-VER. Need to pay closer attention for that. > > I've attached it. Can you test it on your end and see if it works for you? I build-tested it, I'll print-test later today. If you want to be credited in our git history with this, make a pull request in Github or send a git-format patch attachment with proper author and sign-off lines, https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin otherwise I'll investigate and fix it by myself later today. Note that: - This will need a revbump (-r1) with resetted keywords (ekeyword ~all cnrdrvcups-lb-5.10-r1.ebuild). It would be proper to name this as _p1 instead, but it will be a maintenance hell and require major rewrite in the ebuild, so I'll settle with a revbump. - I'd prefer if the previous directory was also used, your newly found directory could be symlinked so both work. Thanks!
Printing works.
(In reply to Joonas Niilola from comment #9) > Printing works. How is the print quality? It's pretty awful on my end. I don't know if that's due to configuration or whether it's inherent in the Canon printers.
(In reply to Joonas Niilola from comment #8) > (In reply to Stephen Bosch from comment #7) > I build-tested it, I'll print-test later today. > > If you want to be credited in our git history with this, make a pull request > in Github or send a git-format patch attachment with proper author and > sign-off lines, > https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin > > otherwise I'll investigate and fix it by myself later today. > > Note that: > - This will need a revbump (-r1) with resetted keywords (ekeyword ~all > cnrdrvcups-lb-5.10-r1.ebuild). It would be proper to name this as _p1 > instead, but it will be a maintenance hell and require major rewrite in the > ebuild, so I'll settle with a revbump. > - I'd prefer if the previous directory was also used, your newly found > directory could be symlinked so both work. > > Thanks! Yes, I'd like to contribute and be credited, but I won't get to it for a few hours. Can it wait until then?
(In reply to Stephen Bosch from comment #10) > (In reply to Joonas Niilola from comment #9) > > Printing works. > > How is the print quality? > Looks the same as ever. Really good here. Of course I'll wait, it's your discovery after all.
Ping, how's it going? Let me know if you need help.
(In reply to Joonas Niilola from comment #13) > Ping, how's it going? Let me know if you need help. Thanks for the ping! I will try to get to it in the next two days. Thanks also for the offer of help, I'll let you know.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=69f972b2799b857f2e68ac5101e572460f0611c3 commit 69f972b2799b857f2e68ac5101e572460f0611c3 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2020-07-04 07:29:43 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-07-04 07:35:56 +0000 net-print/cnrdrvcups-lb: fix printing on some models, #717260 Closes: https://bugs.gentoo.org/717260 Signed-off-by: Joonas Niilola <juippis@gentoo.org> net-print/cnrdrvcups-lb/Manifest | 1 + .../cnrdrvcups-lb/cnrdrvcups-lb-5.10-r1.ebuild | 189 +++++++++++++++++++++ 2 files changed, 190 insertions(+)
