Updating to IPFire Core 169 Broke CUPS

I recently updated my IPFire to Build 169 and CUPS broke printing to my HP1320. I cannot seem to find a driver that will work to print to my HP1320, though I can get the local print test to function. This worked fine with my previous version of IPFire and the setup at that time was easy and quick.

With just CUPS and the associated files I get an error like this

D [13/Aug/2022:07:50:56 -0700] [Job 8] HP_LaserJet_1320_series: error while loading shared libraries: liblber-2.4.so.2: cannot open shared object file: No such file or directory
D [13/Aug/2022:07:50:56 -0700] [Job 8] libusb_get_device_list=5
D [13/Aug/2022:07:50:56 -0700] [Job 8] STATE: +connecting-to-device
D [13/Aug/2022:07:50:56 -0700] [Job 8] PID 27959 (/usr/lib/cups/filter/gstoraster) stopped with status 127 (File too large)
D [13/Aug/2022:07:50:56 -0700] [Job 8] PDF interactive form and annotation flattening done via QPDF

It claims it send the data but that just fails.

I did get an error about some dropping of support in new versions of CUPS, so maybe this is affecting me.

I tried to install hplip and I get an error like this.

I [13/Aug/2022:07:53:50 -0700] [Job 9] Queued on “HP_LaserJet_1320_series” by “DEATHKNIGHT\Terrence”.
I [13/Aug/2022:07:53:51 -0700] [Job 9] File of type application/pdf queued by “DEATHKNIGHT\Terrence”.
I [13/Aug/2022:07:53:51 -0700] [Job 9] Adding end banner page “none”.
I [13/Aug/2022:07:53:51 -0700] [Job 9] Started filter /usr/lib/cups/filter/pdftopdf (PID 28263)
I [13/Aug/2022:07:53:51 -0700] [Job 9] Started filter /usr/lib/cups/filter/gstoraster (PID 28264)
E [13/Aug/2022:07:53:51 -0700] HP_LaserJet_1320_series: File "/usr/lib/cups/filter/hpcups" not available: No such file or directory
E [13/Aug/2022:07:53:51 -0700] [Job 9] Unable to start filter “hpcups” - No such file or directory.
E [13/Aug/2022:07:53:51 -0700] [Job 9] Stopping job because the scheduler could not execute a filter.
I [13/Aug/2022:07:53:53 -0700] [Client 6192] Started “/usr/lib/cups/cgi-bin/printers.cgi” (pid=28267, file=18)
I [13/Aug/2022:07:53:54 -0700] [Client 6192] Started “/usr/lib/cups/cgi-bin/printers.cgi” (pid=28269, file=18)

That directory does not exist as stated in the logs. You can download hpcups but of course it does not like IPFire that much.

I did see some indication that a slightly newer version of CUPS might work better, but I am not sure how to approach that with IPFire.

Hi @coilla42

Welcome to the IPFire community.

Normally if a program is unable to find a required library then this would be the reason for any problems being experienced.

However, in this case I am very puzzled. cups does not use liblber now or in the past. liblber is used by LDAP (Lightweight Directory Access Protocol) but cups doesn’t have any linkage with LDAP. LDAP was updated in CU168 and as part of that the liblber library was updated from

liblber-2.4.so.2 and
liblber-2.4.so.2.10.12

to

liblber.so.2 and
liblber.so.2.0.200

and the liblber-2.4.so libraries were removed.

So liblber-2.4.so.2 being missing after CU168 makes sense but not the fact that the HP LaserJet 1320 printer seems to be looking for it.

I have googled but not been able to find anything that mentioned cups and liblber together. All searches that found liblber were related to ldap.
Are you using LDAP in your network by any chance?

This also looks like an error. The ghostscript to raster convertor apparently stopped because the file it was being asked to work on was too large.
I didn’t find much when googling this either but the same error but with a different backend on another distro was solved by uninstalling and re-installing cups.

So my only suggestion at the moment is to try that with cups on IPFire.

1 Like

Hi!

Thanks for the response.

Thanks for the insight on the source of that error that it is related to an LDAP library.

I do not use LDAP, at least not intentionally, here are the components I have added to IPFire

avahi, cups, cups-filters, dbus, ghostscript, hplip, libdaemon, speedtest-cli, traceroute

I backed out all of what was related to cups and re-installed it, I had a few errors, but it looks like it is on, and the avahi and cups daemon are running.

Here is what is in the log immediate after re-install, what makes me wonder about this issue is the line about printer drivers being deprecated. My printer may be old, but it works very well.

Going to the GitHub page talks about hp-printer-app, I can try to investigate that. It is just annoying if the reason that my CUPS stopped working is because of that decision.

I [13/Aug/2022:13:12:20 -0700] Loaded MIME database from "/usr/share/cups/mime" and "/var/ipfire/cups": 78 types, 114 filters...
E [13/Aug/2022:13:12:20 -0700] HP_LaserJet_1320_series: File \"/usr/lib/cups/filter/hpcups\" not available: No such file or directory
W [13/Aug/2022:13:12:20 -0700] Printer drivers are deprecated and will stop working in a future version of CUPS. See https://github.com/OpenPrinting/cups/issues/103
I [13/Aug/2022:13:12:20 -0700] Loading job cache file "/var/cache/cups/job.cache"...
I [13/Aug/2022:13:12:20 -0700] Full reload complete.
I [13/Aug/2022:13:12:20 -0700] Cleaning out old files in "/var/spool/cups/tmp".
I [13/Aug/2022:13:12:20 -0700] Cleaning out old files in "/var/cache/cups".
W [13/Aug/2022:13:12:20 -0700] CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
I [13/Aug/2022:13:12:20 -0700] Registering ICC color profiles for "HP_LaserJet_1320_series".
W [13/Aug/2022:13:12:20 -0700] CreateDevice failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files
I [13/Aug/2022:13:12:20 -0700] Listening to 0.0.0.0:631 on fd 4...
I [13/Aug/2022:13:12:20 -0700] Listening to [v1.::]:631 on fd 7...
I [13/Aug/2022:13:12:20 -0700] Listening to /var/run/cups/cups.sock on fd 8...
I [13/Aug/2022:13:12:20 -0700] Resuming new connection processing...

Here is the log from an attempted test job

I [13/Aug/2022:13:23:19 -0700] [Job 1] Queued on "HP_LaserJet_1320_series" by "anonymous".
I [13/Aug/2022:13:23:19 -0700] [Job 1] Started filter /usr/lib/cups/filter/bannertopdf (PID 25308)
I [13/Aug/2022:13:23:19 -0700] [Job 1] Started filter /usr/lib/cups/filter/pdftopdf (PID 25309)
I [13/Aug/2022:13:23:19 -0700] [Job 1] Started filter /usr/lib/cups/filter/gstoraster (PID 25310)
E [13/Aug/2022:13:23:19 -0700] HP_LaserJet_1320_series: File \"/usr/lib/cups/filter/hpcups\" not available: No such file or directory
E [13/Aug/2022:13:23:19 -0700] [Job 1] Unable to start filter "hpcups" - No such file or directory.
E [13/Aug/2022:13:23:19 -0700] [Job 1] Stopping job because the scheduler could not execute a filter.
I [13/Aug/2022:13:23:21 -0700] [Client 6] Started "/usr/lib/cups/cgi-bin/printers.cgi" (pid=25313, file=15)
I [13/Aug/2022:13:23:31 -0700] [Client 6] Started "/usr/lib/cups/cgi-bin/printers.cgi" (pid=25325, file=15)
I [13/Aug/2022:13:23:31 -0700] [Client 10] Limiting Get-Jobs response to 500 jobs.

hpcups can be found from HP, the issue is that the installer does not recognize IPFire of course…

It looks like the HP LaserJet 1320 series is now expecting hpcups to be present. hpcups is part of hplip but the IPFire build of hplip does not have the hpcups element enabled.

Also cups does not have hplip defined as a dependency which it would need to be if hpcups was enabled in hplip but required by cups.

The last update of cups was in CU165 which was in March 2022. The last update of hplip was in September 2021 so I don’t understand yet why the problem you are experiencing started with CU169.

What CU version of IPFire was your system at when you did the update to CU169.

1 Like

IPFire has the --enable-hpijs-only-build defined in the configure. In the Fedora hplip page it mentions that hpijs is the cups filter hpcups.

In the hp site giving details about building hplip from source it doesn’t even mention the enable-hpcups ./configure option.

So still trying to understand what has changed and why and how it changed with CU169 when neither cups nor hlip were changed in that update.

Will continue trying to find out about hpcups.

1 Like

Found a page on the hp web site for hplip that covers manual building of the source tarball.

They have the hpijs option disabled and they have the hpcups enabled. I also found that Arch Linux is running with the hpcups option enabled and I believe it looks like Fedora might be doing the same.

I also found a section that says hpijs was the previous default but is no longer being worked on and has been superseded by hpcups. Based on this then the IPFire hplip build needs to be changed to replace the hpijs with hpcups.

Still not clear why this would have become a problem with CU169. Also still looking to find out if hplip needs cups or not. Currently within IPFire it does not have cups as a dependency.

Just found in Arch Linux that cups is a make dependency but not an execution dependency so that is fine with the current IPFire build status.

Looks like 167 from May

-rw-r–r-- 1 root root 408978 May 19 16:47 update-core-upgrade-167.log
-rw-r–r-- 1 root root 71323 Aug 10 13:00 update-core-upgrade-168.log
-rw-r–r-- 1 root root 901221 Aug 10 13:01 update-core-upgrade-169.log

Is it possible that CUPS was for some reason not updated? I definitely was printing with 167, does this indicate that cups was updated on the 10th?

-rw-r–r-- 1 root root 93602 Aug 10 13:06 update-cups.log

Terrence

It indicates that cups was uninstalled and then installed again. This was related to a bug fix for cups because cups did not have a backup step defined in it so if you do a restore from an IPFire backup the cups.conf file would not be restored as it wasn’t backed up before. This fix was implemented in CU168 so would have been included in your move from CU167 to CU169.
However it was only the inclusion of a backup step. Nothing was changed with cups itself. The version of cups stayed at 2.4.1 and nothing was changed in terms of the files installed for it.

The next update version to 2.4.2 is in the build that will be CU170 and is likely to be released for testing before to long, I would expect.

Can you post the output from the update-cups.log?

I have also continued investigating the hplip question about hpcups.

In 2009 hplip made the hpijs drivers deprecated but still available and made the hpcups drivers the default build.

IPFire explicitly specifies hpijs build.

From 2009 to 2017 two sets of ppd’s were shipped in the source tarball, one for hpijs and one for hpcups.

Since 2018 only the hpcups ppd’s have been shipped in the source tarball. The hpijs ones are created as part of the build process if hpijs is specified.

I am not sure for how long but for some time no maintenance or development has been done on the hpijs driver ppd’s or the hpijs driver capability in general.

Arch Linux, Fedora, Red Hat and Ubuntu are using the hpcups drivers not the hpijs drivers.

Based on all the above I will do an update to the hplip addon package to change it over to the hpcups drivers as those are the ones being maintained and developed and probably bug fixes are only done for them.

4 Likes

I can post it, but it is a lot,

wc update-cups.log
2067 3179 93602 update-cups.log

Is there a better way to send it?

Yes, that log keeps an ongoing history of every update that has been run.

Only the last two updates would be of potential interest not the whole history.
Each update usually starts with the following words

Extracting backup includes...
However this might not be the case for cups as it did not used to have a backup option defined.

In which case each section would start with

Removing files...
That is a standard section for all addon update operations.

cups-update.log.gz (5.0 KB)

Hope this helps, I think it is the last two updates.

It is just the last update and some of that is missing.

The file starts with

Extracting files…

There must be a section before that, that has a line

Removing files…

Then from that line you should go back to the next occurrence of

Removing files…

and that will then cover the last two updates.