Package Details: cnrdrvcups-lb 5.20-1

Git Clone URL: (read-only, click to copy)
Package Base: cnrdrvcups-lb
Description: CUPS Canon UFR II LIPSLX CARPS2 printer driver for LBP iR MF ImageCLASS ImageRUNNER Laser Shot i-SENSYS ImagePRESS ADVANCE printers and copiers
Upstream URL:
Licenses: GPL2, custom, MIT
Conflicts: cndrvcups-common-lb, cndrvcups-lb
Submitter: Lone_Wolf
Maintainer: Lone_Wolf (severach)
Last Packager: Lone_Wolf
Votes: 9
Popularity: 0.027279
First Submitted: 2019-09-28 12:34
Last Updated: 2020-09-09 13:07

Pinned Comments

Lone_Wolf commented on 2020-01-27 22:15

The printers supported by this package are often networked.

problems can be in the cnrdrvcups-lb driver, but also with authentication over smb, vpn settings etc .

Troubleshooting those is often very hard.

Archlinux and derivatives are not supported by canon. Use whatever works for you, even if that means using canon drivers in a VM that runs a supported distro .

Lone_Wolf commented on 2020-01-27 22:07

Main difference between 3.70 and 5.x versions :

3.70 has 64-bit & 32-bit code and needs to be built as a multilib application. Also it includes proprietary binaries from canon.

5.x is pure 64-bit and all components in it come with sourcecode. Some parts are still proprietary, but atleast we can build them ourselves now.

Lone_Wolf commented on 2019-09-28 12:41

People coming from cndrvcups-lb / cndrvcups-common-lb or cndrvcups-lb-bin :

You will have to start afresh.

remove the 3.70 versions and created printer definitions in cups
build this package and install
recreate your printer definitions

html documentation from canon is in /usr/share/doc/cnrdrvcups-lb

Latest Comments

1 2 3 4 5 6 Next › Last »

Lone_Wolf commented on 2021-01-18 12:46

I checked and it does appear debian patches jbigkit heavily [1][2].

If I understand you correctly, the problem is that UFR2 is hardcoded to use a library that's present in debian jbigkit but not in archlinux jbigkit ?

The contents of cnrdrvcups-common-5.20/cnjbig/cnjbig.c do reference .

Wonder if redHat / fedora use the same patches as debian.

I'll consider adding jbigkit and your libjbig-shared packges as optional dependencies, but do have some comments about the new package and will post them there.



SmashedSqwurl commented on 2021-01-17 22:01

I went ahead and built an AUR package that just builds and installs the libjbig shared library:

If you add this to the dependencies it should fix the 100% CPU bug everyone is having.

SmashedSqwurl commented on 2021-01-17 21:26

I figured out the solution to the 100% CPU bug. There's an intermediate process that attempts to dynamically load the shared library - the only problem is, that library doesn't exist in the jbigkit package.

In fact, that library is completely made up by the Debian maintainers (see for a list of the patches they add).

I manually built the shared library by applying the allNewMainMakefile.diff, pbmtoolsMakefile.diff, and shared-lib.diff patches to the jbigkit source tree and copied the resulting library to /usr/lib. Then I restarted CUPS and was able to print a test page.

Lone_Wolf commented on 2020-10-26 12:37

Those lines appear to come from the package() function, but I'll need more info to investigate.

You do have base-devel group installed ?

run LC_ALL=C makepkg --log to get output in english and post the logs somewhere publicly accessible

(if you don't know how to do that, check )

snail commented on 2020-10-25 14:21

I Makepkg install, it print some error,(sry, my chinese environment): target=install; for dir in cngplp buftool backend rasterfilter cnjbig; do (cd $dir; make $target)|| exit 1; done make[1]: 警告: jobserver 不可用: 正使用 -j1。添加 “+” 到父 make 的规则。 make[1]: 进入目录“/home/snail/Aur/cnrdrvcups-lb/src/extracted-cnrdrvcups-lb-5.20/cnrdrvcups-common-5.20/cngplp” make[1]: 没有规则可制作目标“install”。 停止。 make[1]: 离开目录“/home/snail/Aur/cnrdrvcups-lb/src/extracted-cnrdrvcups-lb-5.20/cnrdrvcups-common-5.20/cngplp” make: [Makefile:18:install] 错误 1

It seems like the first service(cngplp) can't install, then the for script exit, this problem makes cups to miss rasterfilter directory, the system log print:

File \"/usr/lib/cups/filter/rastertoufr2\" not available: No such file or directory

fireofearth commented on 2020-09-12 20:29

I have virtually the same problem as redeyed. I use a CANON imageCLASS MF229dw via USB. I add the printer using the CUPS web administration page. When printing it's clear the laptop communicates with the printer and there's blinking lights but printer just hangs.

I'm migrating from another laptop that uses cndrvcups-lb which prints using the same printer. In this laptop I can't even downgrade to cndrvcups-lb since I have a build src error when installing the dependency cndrvcups-common-lb... I also tried cnrdrvcups-lb-bin. I think it gave me the same problem.

Let me know if you have suggestions to debug.

edit: my printer is supported UFR II v5.10 on Ubuntu.

defab67 commented on 2020-07-07 13:11

I have not tried that; that's a good idea. I don't have a box with such a distro handy; I'll set one up and try this weekend. If that doesn't work maybe I'll try to get in touch with Canon about it.

Lone_Wolf commented on 2020-07-07 10:13

Canon does mention the MF632C as being supported by this version on the README-ufr2-5.1xUK.html .

Have you tried this version on canon-supported linux distro like fedora or ubuntu to verify if this version does work with your printer ?

defab67 commented on 2020-07-06 17:36

I have a Canon imageCLASS MF632Cdw. Unfortunately, I was not able to get it to print using this package; I had to fall back to the deprecated cndrvcups-lb. Even after installation of libjpeg6-turbo (which solved a problem wherein cnpkmoduleufr2r would consume 100% CPU), the printer never actually printed anything, and instead waited forever for the computer to send the file to be printed.

I did not find cndrvcups-lb to be in a building state--some symbols were multiply defined in cgnplp. Specifically, load.h defines some function pointers; that file is then included in mainwnd.c and load.c. Objects from both translation units are then linked into the cgnplp executable, which causes the function pointers to be multiply defined. I fixed it by declaring them external in load.h and defining them in load.c.

Lone_Wolf commented on 2020-05-20 12:56

hnws, sounds like you managed to make the changes needed to build with gcc 10?

If so, please email me your PKGBUILD (address is in the PKGBUILD).