Hey all, I wonder about the compat of local configurations with ongoing updates.
I’m managing a remote workstation based on f35. Printing worked after the hp-setup process for some time. In the last days hplip was update to hplip-3.22.2 (was hplip-3.21.12). Today i noticed that this update breaks printing (error was similar to something like "version mismatch 3.22.2 vs 3.21.12 ). A downgrade to 3.21.12 was not possible anymore (not in the repositories), the downgrade went directly to hplip-3.21.2 which produced the same version mismatch error. A manual intervention was needed to get the exact version 3.21.12 running again.
Two question arised:
specific to this issue: does the remote user need to setup the printer everytime again when hplip is updated?
general: how long does updates (packages) survive in the repositories? Why are they not archived at least some overlapping time?
There are always two/possibly three versions of packages in the repositories:
the version when a Fedora release is made in the fedora repository
the newest update in the updates repository
while an update is in testing, it is kept in the updates-testing repository until it is pushed to the updates repo (or unpushed if it gets negative feedback).
Intermediate packages are not archived, but can be obtained from the koji build system if required:
If your printer requires a proprietary plugin to work, then plugin’s version and hplip version must match with each other. Thus when you update hplip, you also need to update the proprietary plugin.
As stated by @ersen , a proprietary plugin would also need manually updated. However, for HP printers the only plugin I know of is the one (proprietary) that supports the scanner in their MFP printers and that is not needed for printing.
It is possible that there is a conflict between installed software bits if you have at some time installed hplip directly from the hplip web site using the .run file, then later installed it (or updated it) from the fedora repo. This is particularly common since fedora breaks the software into 3 packages (hplip, hplip-libs, and hplip-common). If you have done that then you should (using the .run file) uninstall what was installed directly from hplip then reinstall the fedora version so it gets rid of conflicting software bits.
I had access to the workstation again and the log file shows (the same for hplip 3.21.2 and 3.22.2 ):
Mar 25 16:09:27 fedora cupsd[810]: REQUEST localhost - - "POST /printers/HP-LaserJet-P1006 HTTP/1.1" 200 377 Create-Job successful-ok
Mar 25 16:09:27 fedora cupsd[810]: REQUEST localhost - - "POST /printers/HP-LaserJet-P1006 HTTP/1.1" 200 22332 Send-Document successful-ok
Mar 25 16:09:27 fedora hpcups[3279]: common/utils.c 177: validate_plugin_version() Plugin version[3.21.12] mismatch with HPLIP version[3.22.2]
Mar 25 16:09:27 fedora hpcups[3279]: common/utils.c 210: Plugin version is not matching
Mar 25 16:09:27 fedora hpcups[3279]: common/utils.c 281: Invalid Library hanlder pLibHandler = NULL.
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=0, index=1
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 535: claimed 7/1/2 interface
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 780: read actual device_id successfully fd=1 len=107
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 561: released 7/1/2 interface
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 960: new PRINT channel=2 clientCnt=1 channelCnt=1
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 427: Found interface conf=0, iface=0, altset=0, index=1
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 389: Active kernel driver on interface=0 ret=0
Mar 25 16:09:27 fedora hp[3280]: io/hpmud/musb.c 535: claimed 7/1/2 interface
Mar 25 16:09:28 fedora hp[3280]: prnt/backend/hp.c 376: read new pjl status: 10023
Mar 25 16:09:28 fedora hp[3280]: prnt/backend/hp.c 378: read pjl job_end: 0
Mar 25 16:09:28 fedora hp[3280]: prnt/backend/hp.c 376: read new pjl status: 10001
Mar 25 16:09:47 fedora hp[3280]: io/hpmud/musb.c 561: released 7/1/2 interface
Mar 25 16:09:47 fedora hp[3280]: io/hpmud/musb.c 975: removed PRINT channel=2 clientCnt=0 channelCnt=0
Mar 25 16:09:47 fedora cupsd[810]: HP-LaserJet-P1006 admin 14 [25/Mar/2022:16:09:47 +0000] total 0 - localhost 1648224563.pdf a4 -
Mar 25 16:09:47 fedora cupsd[810]: [Job 14] Job stopped due to filter errors; please consult the syslog file for details.
so as @ersen pointed out; a manual interaction is needed. The printing part on this workstation are only using fedora packages and the usage of hp-setup. The printer needs the proprietary part. I was expecting that the firmware (the binary blobs that hp-setup downloaded) is independed from the userland tools. I mean in the context of semantic versioning even 3.21.2 is not compatible with 3.21.12? Technically all this is comprehensible but I am arguing from the users point of view and not sure where to complain :-).
# grep Model /etc/cups/printers.conf
MakeModel HP LaserJet p1006, hpcups 3.21.12, requires proprietary plugin
Our solution is keeping the local version 3.21.12 now (maybe until being present at the remote side) and
PS: @ankursinha the problem with koji packages, they are not signed. I’m still convinced that keeping some intermediate updates for a small time window is beneficial. The storage usage
at the end of life will be the same as it is now.
BTW: Its crazy what this hp-setup tool does. Downloading obscure stuff and spreading it all over the filesystem witout a bill of material. Even scanning stuff while just needing the blobs for a b/w laserjet.
The dnf versionlock plugin is probably an easier way?
I’m sure this has been discussed before, and the infrastructure team has good reason for not keeping intermediate package versions, but feel free to discuss it with them here: