hp-plugin fails to detect already installed plugin

Bug #1018303 reported by Johannes Meixner
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
HPLIP
Fix Released
Undecided
Amarnath Chitumalla

Bug Description

On my SLED11-SP1 32-bit/i586 workstation I run HPLIP 3.12.6 from
http://download.opensuse.org/repositories/Printing/SLE_11_SP1/i586/

I have a HP LaserJet 1020 connected via USB.

hp-setup downloads and installs the plugin but
directly afterwards it aborts with an error message
that my printer requires a plugin - same as in
https://answers.launchpad.net/hplip/+question/201190

I got those files installed:
------------------------------------------------------------------------
# ls -lh /tmp/hplip*plugin*
-rw-r--r-- 1 root root 1.8M Jun 21 00:52 /tmp/hplip-3.12.6-plugin.run
-rw-r--r-- 1 root root 198 Jun 21 00:52 /tmp/hplip-3.12.6-plugin.run.asc

# for f in $( find /usr/share/hplip/ | grep plugins/ ) ; do ls -lh $f ; done
-rwxr-xr-- 1 root root 4.6K Jun 27 11:03 /usr/share/hplip/data/plugins/license.txt
-rwxr-xr-- 1 root root 6.9K Jun 27 11:03 /usr/share/hplip/fax/plugins/fax_marvell-x86_32.so
lrwxrwxrwx 1 root root 50 Jun 27 11:03 /usr/share/hplip/fax/plugins/fax_marvell.so
 -> /usr/share/hplip/fax/plugins/fax_marvell-x86_32.so
-rwxr-xr-- 1 root root 48K Jun 27 11:03 /usr/share/hplip/prnt/plugins/hbpl1-x86_32.so
lrwxrwxrwx 1 root root 45 Jun 27 11:03 /usr/share/hplip/prnt/plugins/hbpl1.so
 -> /usr/share/hplip/prnt/plugins/hbpl1-x86_32.so
-rwxr-xr-- 1 root root 53K Jun 27 11:03 /usr/share/hplip/prnt/plugins/lj-x86_32.so
lrwxrwxrwx 1 root root 42 Jun 27 11:03 /usr/share/hplip/prnt/plugins/lj.so
 -> /usr/share/hplip/prnt/plugins/lj-x86_32.so
-rwxr-xr-- 1 root root 34K Jun 27 11:03 /usr/share/hplip/scan/plugins/bb_marvell-x86_32.so
lrwxrwxrwx 1 root root 50 Jun 27 11:03 /usr/share/hplip/scan/plugins/bb_marvell.so
 -> /usr/share/hplip/scan/plugins/bb_marvell-x86_32.so
-rwxr-xr-- 1 root root 18K Jun 27 11:03 /usr/share/hplip/scan/plugins/bb_soap-x86_32.so
lrwxrwxrwx 1 root root 47 Jun 27 11:03 /usr/share/hplip/scan/plugins/bb_soap.so
 -> /usr/share/hplip/scan/plugins/bb_soap-x86_32.so
-rwxr-xr-- 1 root root 53K Jun 27 11:03 /usr/share/hplip/scan/plugins/bb_soapht-x86_32.so
lrwxrwxrwx 1 root root 49 Jun 27 11:03 /usr/share/hplip/scan/plugins/bb_soapht.so
 -> /usr/share/hplip/scan/plugins/bb_soapht-x86_32.so
------------------------------------------------------------------------

I removed those files and run hp-plugin which also
downloads and installs the plugin again.

But a subsequent second run of hp-plugin fails to
detect that the plugin is alredy installed:
=======================================
# hp-plugin -i -g
HP Linux Imaging and Printing System (ver. 3.12.6)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-14 Hewlett-Packard Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

hp-plugin[11700]: debug: Locking: /var/hp-plugin.lock
.
.
.
hp-plugin[11700]: debug: Plug-in version=3.12.6
hp-plugin[11700]: debug: Plug-in=hplip-3.12.6-plugin.run

-----------------------------------------
| PLUG-IN INSTALLATION FOR HPLIP 3.12.6 |
-----------------------------------------

hp-plugin[11700]: debug: Unable to open file /var/lib/hp/hplip.state for reading.
hp-plugin[11700]: debug: Plugin is not installed
  Option Description
  ---------- --------------------------------------------------
  d Download plug-in from HP (recomended)
  p Specify a path to the plug-in (advanced)
  q Quit hp-plugin (skip installation)

Enter option (d=download*, p=specify path, q=quit) ? q
hp-plugin[11700]: debug: Unlocking: /var/hp-plugin.lock

# ls -l /var/lib/hp/hplip.state
ls: cannot access /var/lib/hp/hplip.state: No such file or directory
=======================================

Because of this I cannot set up my HP LaserJet 1020 with hp-setup.

As a woraround I set up the printer using YaST (YaST does not know
about plugins and such stuff - as long as a PPD file exists YaST can
create a print queue) using those two PPD files:
"HP LaserJet 1020 hpijs, 3.12.6, requires proprietary plugin"
and
"HP LaserJet 1020, hpcups 3.12.6, requires proprietary plugin"

Both queues work well which means that the plugin is actually
correctly installed so that all what goes wrong here is the test
whether or not the plugin is installed but this results in the end
that one cannot use hp-setup to set up such printers.

Revision history for this message
Amarnath Chitumalla (amarnath-chitumalla) wrote :

Hi Johannes Meixner,

I think, if /var/lib/hp folder is doesn't exist, then this issue will happen.

Please create "/var/lib/hp" folder using root. and re-install plugin using hp-plugin command.

If you are still facing problem, please install hplip-3.12.6 from http://hplipopensource.com/hplip-web/install/install/index.html site instead of repo.

Thanks & Regards,
Amarnath

Revision history for this message
Johannes Meixner (jsmeix) wrote :

I am the package maintainer of the HPLIP packages in openSUSE.

Your reply helps end-users of HPLIP but it is not what helps Linux distributors.

Linux distributors build HPLIP from source via HPLIP's "configure/make/make install"
and provide what comes out of HPLIP's "configure/make/make install"
as readymade binary software packages to the users of the Linux distribution.

For Linux distributors it does not work to install HPLIP from
http://hplipopensource.com/hplip-web/install/install/index.html

At least for some users of HPLIP it also does not work
to install HPLIP from http://hplipopensource.com

Users of Linux distributions install the binary software packages
from the official software repositories of the Linux distributions.
If they install software from another repository they will no longer
get any kind of support at least for that software from the Linux distributor.

In particular business customers of enterprise Linux distributions
who have a maintenance and support contract with the Linux distributor
will not install HPLIP from http://hplipopensource.com because this
could invalidate their maintenance and support contract.
Additionally when the Linux distributor provides a maintenance update
of the Linux distributor's HPLIP software (in particular security fixes like the
fixes of the insecure foomatic-rip-hplip and the insecure tmp file handling
in hpcupsfax.cpp) the maintenance update may overwrite an
installed HPLIP from http://hplipopensource.com or the
maintenance update on top of an installed HPLIP from
http://hplipopensource.com may result a messed up HPLIP.
Therefore business customers would usually never ever install HPLIP
from http://hplipopensource.com

If the /var/lib/hp directory is required but HPLIP's "configure/make/make install"
does not create it, the bug is in HPLIP's "configure/make/make install" which
must make everything what HPLIP needs.

In the end what I like to tell you is that the HPLIP authors must make sure
that HPLIP's "configure/make/make install" produces complete and
correct HPLIP binary software so that Linux distributors provide
complete and correct binary software packages of HPLIP to their users
because "install HPLIP from http://hplipopensource.com" is not an option
for every user of HPLIP.

Of course I can work around this bug in HPLIP's "configure/make/make install"
by creating the /var/lib/hp directory during our build process (and I will do
this for our HPLIP 3.12.6 packages as workaround for now) but this is not
the way how it should work in general.

Revision history for this message
Johannes Meixner (jsmeix) wrote :

I can confirm that after
==============================================
# mkdir /var/lib/hp/

# ls -ld /var/lib/hp/
drwxr-xr-x 2 root root 4096 Jun 28 10:03 /var/lib/hp/
==============================================
both hp-plugin and hp-setup work well.

Revision history for this message
Amarnath Chitumalla (amarnath-chitumalla) wrote :

Hi Johannes Meixner,

Thank you for reply.
Generally HPLIP Makefile generates the "/var/lib/hp" folder during "make install" command.
I am not sure why "/var/lib/hp" folder is not created.

Please find the following snippet to generate "/var/lib/hp" from Makefile and Makefile.am
---> From Makefile.am
#hplip.state
hplip_statedir = /var/lib/hp
dist_hplip_state_DATA =

--> From generated Makefile.

install-dist_hplip_stateDATA: $(dist_hplip_state_DATA)
 @$(NORMAL_INSTALL)
 test -z "$(hplip_statedir)" || $(MKDIR_P) "$(DESTDIR)$(hplip_statedir)"
 @list='$(dist_hplip_state_DATA)'; test -n "$(hplip_statedir)" || list=; \
 for p in $$list; do \
   if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
   echo "$$d$$p"; \
 done | $(am__base_list) | \
 while read files; do \
   echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(hplip_statedir)'"; \
   $(INSTALL_DATA) $$files "$(DESTDIR)$(hplip_statedir)" || exit $$?; \
 done

Please let us know if anything is missing or needs to be corrected.

We have found that there are 3 hplip rpm packages (hplip-3.12.6-55.1.i586.rpm , hplip-hpijs-3.12.6-55.1.i586.rpm , hplip-sane-3.12.6-55.1.i586.rpm ) in "http://download.opensuse.org/repositories/Printing/SLE_11_SP1/i586/" repo. If possible make it only single hplip rpm package.

Thanks & Regards,
Amarnath

Revision history for this message
Johannes Meixner (jsmeix) wrote :

Meanwhile it seems there is no bug in HPLIP
but something is wrong in the openSUSE build system:

Actually HPLIP's "configure/make/make install" creates
the var/lib/hp directory but the openSUSE build system
does not complain when it is not packaged into the RPMs.
Usually our build stops with an error message
about "installed but unpackaged files" in such cases.
Because the openSUSE build system did not detect that
the var/lib/hp directory was created but not packaged
we provide HPLIP packages without it.

By the way:

I think I found an inconsistency in HPLIP's Makefile.in regarding
"/var/log/hp" versus "/var/lib/hp" which results the below output
while "make install" runs.
In the openSUSE build system "make install" is run as
make install DESTDIR=/var/tmp/hplip-3.12.6-build
==================================================
test -z "/var/tmp/hplip-3.12.6-build/var/log/hp" || mkdir -p /var/tmp/hplip-3.12.6-build/var/log/hp
chmod 774 /var/tmp/hplip-3.12.6-build/var/log/hp
test -z "/var/lib/hp" || /bin/mkdir -p "/var/tmp/hplip-3.12.6-build/var/lib/hp"
==================================================
It seems for the 'test -z "/var/lib/hp"' the $(DESTDIR) is missing in Makefile.in
(but I think this is basically only a cosmetic issue).

Revision history for this message
Johannes Meixner (jsmeix) wrote :
Download full text (3.7 KiB)

Hello Amarnath,

many thanks for your explanation!

I found out what went wrong here during the build.
Basically it is one more instance of the "RPM and directories" annoyance.

If "make install" creates an empty directory, RPM does not care.

I added "touch %{buildroot}/var/lib/hp/foo" in my hplip.spec file
and - voila - I got:
========================================
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /var/lib/hp/foo
========================================

This "RPM and directories" behaviour make it hard to provide
complete RPMs because usually I rely on that RPM detects
changes in what is installed by "make install".

FYI, regarding "RPM and directories annoyance" you may have a look at
http://sourceforge.net/mailarchive/message.php?msg_id=27032884

Regarding "3 hplip rpm packages" at openSUSE:

If it was only me who makes the decisions I would usually provide
software that comes as one piece in one tar ball from upstream
also in one piece of binary package because it would be much more simple
for me and for most (but not all) of our users.

But there are some users and decision makers who believe in
splitting software is THE right thing (TM). Their reasoning is that
this way users can install only those exact parts of the whole
software that the particular user actually needs.

To a certain extent I even agree in particular when the question is
if a software is used on a server system or on a desktop system.
From my point of view the main difference here is that on a
server system there is usually neither X11 nor graphical GUI software
like Gtk or QT installed and the server admins do not want to have
such software installed because they want to keep their server systems
small because they do not want to care about maintenance (in particular
security updates) for software which is not really needed on their servers.

Therefore I agree that the core parts of HPLIP so that plain printing is possible
are split from the rest of HPLIP.

I even agree that those parts of HPLIP so that plain scanning is possible
are split from the rest of HPLIP.

Both splits make it possible to install HPLIP for plain printing (and optionally
additionally for plain scanning) on a server system.

Therefore openSUSE has split HPLIP into three binary sub-packages as follows:

hplip-hpijs:
The core parts of HPLIP so that plain printing is possible, see
https://bugzilla.novell.com/show_bug.cgi?id=546893
and
https://bugzilla.novell.com/show_bug.cgi?id=546856

hplip-sane:
What is needed in addition to hplip-hpijs so that scanning is
possible with generic scanning frontends (in particular with the
command line tool "scanimage"), see
https://bugzilla.novell.com/show_bug.cgi?id=723870
and
https://bugzilla.novell.com/show_bug.cgi?id=726316

hplip:
All the rest of HPLIP.

Be happy that up to now nobody had detected that one could split
HPLIP even more: Into a sub-package that contains only libraries
and one more sub-package that contains only development files
(mainly header files) and so on ad nauseam.

To mitigate possibly bad consequences of the split I have in hplip.spec
===================================================
Name: ...

Read more...

Revision history for this message
Amarnath Chitumalla (amarnath-chitumalla) wrote :

Hi Johannes Meixner,

Thank you for the reply.

"var/log/hp" folder creation snippet added in Makefile.am to add extra permissions. So here over-ridden "install-dist_hplip_LogDATA" rule.
===============================================
install-dist_hplip_LogDATA:
if FULL_BUILD
 test -z "$(DESTDIR)$(hplip_Logdir)" || mkdir -p $(DESTDIR)$(hplip_Logdir)
 chgrp "lp" -R $(DESTDIR)$(hplip_Logdir)
 chmod 774 $(DESTDIR)$(hplip_Logdir)
endif #FULL_BUILD
===============================================

Various, "/var/lib/hp" folder is creation snippet added in Makefile.in using automake tool.
I think, automake tool may needs to be add the $(DESTDIR) flag while checking for dir.

I am not sure, but found following snippet in scripts.am file (line no. 29) of automake tool.
=============================================
.PHONY install-%EXEC?exec:data%-am: install-%DIR%SCRIPTS
install-%DIR%SCRIPTS: $(%DIR%_SCRIPTS)
 @$(NORMAL_INSTALL)
 test -z "$(%NDIR%dir)" || $(MKDIR_P) "$(DESTDIR)$(%NDIR%dir)"
==============================================
Probably $(DESTDIR) need to add in above snippet.

If my understanding is correct, automake tool has to correct this.

Thanks & Regards,
Amarnath

Revision history for this message
Johannes Meixner (jsmeix) wrote :

In older HPLIP versions (e.g. 3.11.10 on my SLED11-SP2 system)
I have the /var/lib/hp directory in the RPM because there
was also a /var/lib/hp/hplip.state installed by "make install".

Only since a newer HPLIP version where "make install"
installs the empty /var/lib/hp directory the issue can happen.

Because other Linux distributors also use RPM as package format
I like to suggest that HPLIP's "make install" does not install
empty directories but have at least an empty dummy file therein
(e.g. an empty /var/lib/hp/hplip.state) to help Linux distributors
to avoid provide incomplete HPLIP RPMs to their users.

In the end this is no bug in HPLIP but an enhancement request
to let "make install" be again more friendly for lazy packagers
(at least at Linux distributors that use RPM).

Revision history for this message
Amarnath Chitumalla (amarnath-chitumalla) wrote :

Hi Johannes Meixner,

Have doubt, even "var/log/hp" also empty folder and this is also not getting created?

I mean both "/var/log/hp" and "/var/lib/hp" are empty folders. I think, this issue should happen for both folders.

Thanks & Regards,
Amarnath

Revision history for this message
Johannes Meixner (jsmeix) wrote :

For "/var/log/hp" I have in the hplip.spec file
=================================================
%files hpijs
...
%dir %attr(0774,root,lp) /var/log/hp
=================================================
which tells RPM to include the /var/log/hp directory with the specified
owner, group, and permissions in the binary RPM package.

Such an entry was missing for "/var/lib/hp" in the hplip.spec file.
I added it now and this way the issue is fixed in openSUSE's
hplip-hpijs package.

FYI:

Why I set the owner, group, and permissions in the hplip.spec file
see the comments in the hplip.spec file:
==================================================
# Patch102 deactivates the "chgrp lp -R /var/log/hp" in Makefile.am
# because during install this results "Operation not permitted"
# this is done in the files section via attr(0774,root,lp)
# where mode 0774 matches to what is set in Makefile.am:
Patch102: no-chgrp_lp_hplip_Logdir.diff
==================================================

The reasoning behind is that our build runs in a "sandbox"
which is a clean system that is for each build installed from scratch
and runs in a virtual machine.

The user who actually does the build therein is not 'root'
but a normal user and for that normal user "chgrp lp -R /var/log/hp"
results "Operation not permitted".

Therefore I must deactivate this during "make/ make install"
and do it instead in the files section in hplip.spec
via "attr(0774,root,lp)" which results that this file is packaged
into the RPM binary package with those owner, group, and permissions
so that it will be installed this way on the end-users system.

The openSUSE hplip.spec files are public readable:

For the openSUSE development project "Printing" at
https://build.opensuse.org/package/view_file?file=hplip.spec&package=hplip&project=Printing

And e.g. for the released openSUSE 12.1 product at
https://build.opensuse.org/package/view_file?file=hplip.spec&package=hplip&project=openSUSE%3A12.1

Revision history for this message
Johannes Meixner (jsmeix) wrote :

Hello Amarnath,

currently I do not use a special %attr for /var/lib/hp in hplip.spec
so that it becomes installed as follows on the end-users system:

drwxr-xr-x 2 root root 4096 Jun 28 12:04 /var/lib/hp

Therefore only root can write to it.

I don't know if perhaps also the user "lp" may need to write to it
i.e. that "lp" may need to create files therein - e.g. "lp" might
need to create /var/lib/hp/hplip.state if is does not yet exist?

Revision history for this message
Amarnath Chitumalla (amarnath-chitumalla) wrote :

Hi Johannes Meixner,

Thank you for detail information.

"/varlib/hp/hplip.state" file will be created by root user using "hp-plugin" command.

Thanks & Regards,
Amarnath

Revision history for this message
Johannes Meixner (jsmeix) wrote :

For the log:

The issue is fixed in openSUSE's hplip.spec file
of the openSUSE development project "Printing"
(where the upgrade to HPLIP 3.12.6 happened) via
=============================================
%files hpijs
...
# Use fixed "/var/lib/hp" because this is hardcoded in the HPLIP sources:
%dir /var/lib/hp
=============================================
I provide the /var/lib/hp directory in the hplip-hpijs sub-package
to be on the safe side because hplip-hpijs is the minimal
(printing-only) way to use HPLIP so that the directory exists
in any case when HPLIP is used.

Amarnath,
feel free to close this bug report either as invalid
because it is no bug in HPLIP or enhance "make install"
to be precautionary against such issues by not installing
empty directories but have an (empty) dummy file therein.

Changed in hplip:
status: New → Invalid
Revision history for this message
Johannes Meixner (jsmeix) wrote :

Somehow it does not work on openSUSE 12.2:

The /var/lib/hp directory is created everywhere
except on openSUSE 12.2 and later versions
(could this be an autoconf issue ?).

I don't see errors during RPM package build
on openSUSE 12.2 - it seems the creation of
the /var/lib/hp directory is somehow skipped.

At least for now I will create it in our RPM install section
if it does not exist as a simple and fail-safe workaround
see also
https://bugzilla.novell.com/show_bug.cgi?id=780413

Revision history for this message
Johannes Meixner (jsmeix) wrote :

Hello Amarnath,

do you have an idea why the /var/lib/hp directory is created
everywhere except on openSUSE 12.2 and later (i.e. openSUSE Factory).

Could there be something in the HPLIP sources why it does not
work reliably everywhere?

Changed in hplip:
status: Invalid → New
Revision history for this message
Johannes Meixner (jsmeix) wrote :

For the log:

This one is a duplicate:

https://bugs.launchpad.net/hplip/+bug/1048732

Changed in hplip:
status: New → Fix Released
assignee: nobody → Amarnath Chitumalla (amarnath-chitumalla)
Revision history for this message
Brent Creech (brentcreech) wrote :

LinuxMint
Release 1 (debian) 64-bit
Kernel Linux 3.2.0-4-amd64
GNOME 3.4.2
Memory: 7.8 GiB
Processor: Intel® Core™2 Quad CPU Q9650 @ 3.00GHz × 4
Available disk space: 558.6 GiB
Printer HP MFP CM1017

I just wanted to note that I had this exact same problem with the "fix" work around mentioned above solving my issue also.
from synaptic package manager:
hplip-dbg
hplip-doc
hplip-gui
libhpmud-dev
xsane

During troubleshooting:
sudo aptitude install --assume-yes libcups2 cups libcups2-dev cups-bsd cups-client libcupsimage2-dev libdbus-1-dev build-essential ghostscript openssl libjpeg62-dev libsnmp-dev libtool libusb-dev python-imaging policykit-1 policykit-1-gnome python-qt4 python-qt4-dbus python-dbus python-gobject python-dev python-notify python python-reportlab libsane libsane-dev sane-utils xsane

Last commands used to get the printer installed:
sudo mkdir -p /var/lib/hp
sudo touch /var/lib/hp/hplip.state

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.