Bug 515005

There was no update for hplip for openSUSE 11.0.
Therefore an update of something else is the root cause
of the issue.

Without information which excact packages were updated and
from which exact package repository the new packages came
I cannot even guess what the root cause is.

Run the command (type it all in one single line)
---------------------------------------------------------------------
for p in $( rpm -qa --last | cut -s -d ' ' -f 1 ) ; 
 do echo $p ; rpm -qi $p | egrep '^Install Date|^Distribution' ; 
 echo ; done >/tmp/rpminfo
---------------------------------------------------------------------
and then attach its output file /tmp/rpminfo
as MIME type text/plain to this bug.

You wrote "The hplip tarball people suggested".
Please provide the URL to your question or bug report
regarding HPIP on launchpad.net or attach your e-mail
conversation with them so that we have a chance
to understand what goes on on your particular system.

hplip functions broken - see below

=========================================
jdenman@lanya:~> hp-check

HP Linux Imaging and Printing System (ver. 3.9.6)
Dependency/Version Check Utility ver. 14.3

Copyright (c) 2001-9 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.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling the HPLIP supplied tarball (.tar.gz or .run) to determine if the proper dependencies are
installed to successfully compile HPLIP.
2. Run-time check mode (-r or --run): Use this mode to determine if a distro supplied package (.deb, .rpm, etc) or an already built HPLIP supplied tarball has the proper
dependencies installed to successfully run.
3. Both compile- and run-time check mode (-b or --both) (Default): This mode will check both of the above cases (both compile- and run-time dependencies).

Saving output in log file: hp-check.log

Initializing. Please wait...

---------------
| SYSTEM INFO |
---------------

Basic system information:
Linux lanya 2.6.25.20-0.4-pae #1 SMP 2009-06-01 09:57:12 +0200 i686 i686 i386 GNU/Linux

Distribution:
suse 11.0

Checking Python version...
OK, version 2.5.2 installed

Checking PyQt 4.x version...
Traceback (most recent call last):
  File "/usr/bin/hp-check", line 297, in <module>
    from PyQt4 import QtCore
RuntimeError: the sip module implements API v5.0 but the PyQt4.QtCore module requires API v3.7
=========================================
jdenman@lanya:~> hp-devicesettings

HP Linux Imaging and Printing System (ver. 3.9.6)
Device Setup Utility ver. 0.1

Copyright (c) 2001-9 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.

Segmentation fault
=========================================
jdenman@lanya:~> hp-fab

HP Linux Imaging and Printing System (ver. 3.9.6)
Fax Address Book ver. 6.0

Copyright (c) 2001-9 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.

Segmentation fault
========================================
jdenman@lanya:~> hp-info

HP Linux Imaging and Printing System (ver. 3.9.6)
Device Information Utility ver. 5.2

Copyright (c) 2001-9 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.

Using device: hp:/usb/OfficeJet_6100_Series?serial=MY3BIH63Z62R

Segmentation fault
=========================================
jdenman@lanya:~> hp-setup

HP Linux Imaging and Printing System (ver. 3.9.6)
Printer/Fax Setup Utility ver. 9.0

Copyright (c) 2001-9 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.

Segmentation fault
=========================================
jdenman@lanya:~> hp-toolbox

HP Linux Imaging and Printing System (ver. 3.9.6)
HP Device Manager ver. 15.0

Copyright (c) 2001-9 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.

Segmentation fault
=========================================
jdenman@lanya:~> hp-sendfax

HP Linux Imaging and Printing System (ver. 3.9.6)
PC Sendfax Utility ver. 9.0

Copyright (c) 2001-9 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.

Segmentation fault
==========================================
jdenman@lanya:~> hp-firmware
Segmentation fault
==========================================

/var/log/messages reveals
Jun 26 12:49:01 lanya kernel: python[11060]: segfault at 6e74825a ip b7ceef5b sp bfc7c9bc error 4 in libc-2.8.so[b7c7c000+13d000]

Created attachment 300793 [details]
As per request

This is a new buf that happened sometime in the last couple of weeks when the HP icon disappeared from the tray

.pm. means packman packages. reassign to pascal as one of the packman guys

Comment #6 is based on special insider knowledge meta information.

I am still very interested to learn how I could determine
without special insider knowledge meta information
via commands running on the end-user's system
if an end-user has third-party packages installed.

In this case I wonder in particular why packman packages
have a RPM "Distribution: openSUSE 11.0 (i586)".

Additionally I am very interested to learn how I could determine
via commands running on the end-user's system
from where which of his installed packages came
(i.e. first of all from where he got the binary RPM and
secondly preferably where the matching source RPM is).

Hope this helps somewhat!
I used the the following OpenSuSE repositories from the start of the 11.0 Installation. All of the installation and updates were from Yast and the repositories. The fax worked until recently (the last three weeks or so). The HP icon disappeared from the bottom panel of KDE when the trouble started. I could not find the repository list anywhere on my system (frustration+). You might notice that I disabled the SAX repository for 11.0 and added 11.1 in it's place. That's because the 11.0 SAX repository disappeared. I have not checked recently to see if the 11.0 version is somehow resurrected.

However I took a graphic snapshot of the repository list that can be seem from any good browser on my personal web age and with the link below.

I also used a link to the original installation DVD disk copied to the hard disk so that I would not need the DVD in the drive for updates. The md5sum of the copy and the DVD disk checks.

http://home.roadrunner.com/~cashmere/snapshot53.png

Additional remarks:
The hplip.rpm and the hplip-cups.rpm came from the packman repositories but the hplip-hpjis.rpm did not. I do not know where it cam from.

The kpackage of hplip-hpjis notes reports:
===========================================================
"* Tue Apr 29 2008 jsmeix@suse.de
- Added RPM requirement for python-gobject2 because the dbus stuff
  in HPLIP requires the Python module gobject but there is no
  automated RPM requirement for python-gobject2, see
  https://answers.launchpad.net/hplip/+question/30741
 
* Thu Apr 10 2008 jsmeix@suse.de
- HPLIP-2.8.4-systray_exit_if_no_device_2.patch lets hp-systray
  exit if the HPLIP driver seems to be not in use (i.e. if there
  is neither a 'hp:/...' nor a 'hpfax:/...' print queue), see
  https://bugs.launchpad.net/hplip/+bug/213938
  This patch obsoletes the whole hp-systray.wrapper stuff,
  see the entry below and Novell/Suse Bugzilla bnc#377885.
 
* Tue Apr 08 2008 jsmeix@suse.de
- Added hp-systray.wrapper which is a wrapper for hp-systray
  which runs it only if there is a 'hp:/...' print queue
  and changed /etc/xdg/autostart/hplip-systray.desktop
  to run the wrapper, see Novell/Suse Bugzilla bnc#377885.
 
* Thu Apr 03 2008 jsmeix@suse.de
- Updated to version 2.8.4:
  Elimination of all persistent startup daemons.
  The last daemon hpssd has been replaced with hp-systray.
  All interprocess communication uses now dbus.
  Therefore dbus-1-python version 0.80 or greater is required.
  PC send fax requires dbus and a running hp-systray to operate
  but hp-toolbox and hp-sendfax launch hp-systray automatically
  and there is also /etc/xdg/autostart/hplip-systray.desktop.
  When no HPLIP tools are running (e.g. hp-toolbox),
  and the user closes or disables hp-systray,
  there will be no HPLIP processes running whatsoever.
  Many bug fixes (no Suse bugs).
  One more supported LaserJet ZJStream printers (M1120),
  one OfficeJet (J6400), and two Photosmart (C4340, B8800)
  where the latter has a new printer device class (PSB9100).
  For details see release_notes.html
- Adapted the hplip init script to provide backward compatibility:
  It still exists to avoid that printer/scanner setup tools fail
  when they try to enable the "hplip" service but all it does
  is to stop a possibly running hpssd.
=========================================================

The hplip.rpm and the hplip-cups.rpm from the packman repositories
are what currently runs as HPLIP software on your machine
which does not work.

The hplip-hpjis.rpm is the original openSUSE package and just
a leftover from the original openSUSE HPLIP installation
which had worked.
This is another (minor) bug in HPLIP packman packages because
the HPLIP packman packages which claim to be made for
"Distribution: openSUSE 11.0 (i586)" fail to do a perfect
replacement of our original openSUSE packages (i.e. the HPLIP
packman packages should obsolete our original openSUSE packages).

In your case to get back a working HPLIP,
remove the HPLIP packman packages and
re-install our original openSUSE packages.

Great!

Done!
JD

I do not exactly know what happened. Sometime this last month the fax utility became broken. 

Due to system integration issues the printer would not work after I used Yast to remove the hplip rpms and reinstalled the original rpms using Yast

 I fixed the problem by adding back the Pakman repository updated to python-qt4-4.5.1-1000.12.1.i586.rpm and adding a python repository and the KDE repository. After I did that, it now works.

This whole idea of the repository needs a review from the perspective of dependencies because rpms can no longer resolve them.

JD

*** Bug 551785 has been marked as a duplicate of this bug. ***

*** Bug 559038 has been marked as a duplicate of this bug. ***

In openSUSE 11.2 I noticed several such user reports:
--------------------------------------------------------------------
Running "hp-setup" exits with
"error: Unable to locate models.dat file"
--------------------------------------------------------------------

The reason is that Packman's hplip-hpcups package is installed.

Removing Packman's hplip-hpcups package and (re-)installing
openSUSE's hplip and hplip-hpijs packages solves the issue.

I wonder why users seem to blindly trust when whatever packages
from whatever repositories become installed on their systems?
And I wonder why users install Packman's hplip at all
when it does not work?

As I mentioned in another report it's openSUSE's fault.

The packages from packman worked in 11.1 and probably will do in 11.2 as well if both came from packman, surprise, surprise.

Yet zypper, i.e. openSUSE, mixes opensuse and packman hplip packages, i.e. does not remove hplip-cups (packman) if the opensuse hplip package replaces the packman hplip package. Installing the opensuse package should remove hplip-cups and force hplip-hpijs, that's the correct fix.

Again your point of view: Every issue is openSUSE's fault.
Even issues caused by hardware crap are openSUSE's fault (bug #556819).
Great!

By the way:
I may have even looked at those "another report"
if you provided an URL to it...


Seriously:

As already explained in comment #17 it is Packman's fault
because the HPLIP packman packages which claim to be made for
"Distribution: openSUSE ..." fail to do a perfect replacement
of our original openSUSE packages.

On the other hand our our openSUSE HPLIP packages also fail
to do a perfect replacement of Packman's HPLIP packages
because the openSUSE HPLIP packages do not obsolete
Packman's hplip-hpcups package simply because in the
openSUSE world there is no hplip-hpcups package at all
and I cannot know magically which package names
whatever third-party package repository may use.

Installing the openSUSE 11.2 hplip package does already
enforce its exact matching hplip-hpijs package via
the following entry in hplip.spec:
-----------------------------------------------------------------
# Require the exact matching version-release of the hpijs
# sub-package to make sure to have the exact matching version
# of libhpip and libhpmud installed.
# The exact matching version-release of the sub-package
# is available on the same repository where the main-package is
...
Requires:       %{name}-hpijs = %{version}-%{release}
-----------------------------------------------------------------
But even this is no guarantee that the exact matching
version-release of hplip-hpijs is only available in the
exact same repository wherefrom hplip was installed.
On plain RPM level any exact matching version-release
of any hplip-hpijs package from any repository satisfies
this RPM requirement.

For openSUSE 11.3 I will add
  Obsoletes: hplip-hpcups
in the hplip.spec file to mitigate further issues
but this is not more than a band-aid workaround.

It cannot work on the current plain RPM level that
various sets of packages for the same functionality
from various package repositories can do a perfect
replacement of each other because the precondition is
that each package maintainer for each package repository
would have to have the full overall knowledge about
all the various sets of packages in all the various
package repositories to provide sufficient RPM requirements
and obsoloetes for all possible cases in each of the spec files.

As mentioned in comment #23 it seems the root cause of the issue
is the the package and repository management software which seems
to mix up particular packages which belong to the same functionality
but come from different repositories.

But I have no idea how a package and repository management software
could currently avoid such a mix-up because to avoid this,
the package and repository management software would have to know
which set of packages belong to the same functionality.

Here the package and repository management software
would have to know that for the openSUSE repository
the packages hplip and hplip-hpijs belong to the HPLIP functionality
but for the Packman repository the packages hplip and hplip-hpcups
belong to the HPLIP functionality.

Therefore currently - as far as I see - it is up to the user
to avoid such a package mix-up from different repositories.

To avoid such a package mix-up from different repositories
by the package and repository management software
it seems to be missing (according to my knowledge about RPM)
that one can define in the RPM spec file which packages belong
to the same functionality or more generally which set of packages
should be considered to belong to each other.
(Plain RPM "Requires" is not sufficient, see above.)

Then the package and repository management software could avoid
that within such a set of related packages a package becomes
replaced with a "foreign" package from a different repository.

The package and repository management software may not strictly
forbid such kind of package mix-up but it could at least
show a warning message to the user so that such kind of mix-up
does at least no longer happen "silently".

As far as I see it is not mandatory that such package sets
must have the same name in each of the various repositories.
Assume in the openSUSE repository the set is called "HPLIP"
and contains the packages "hplip" and "hplip-hpijs" but
in Packman the set is called "HP Linux Imaging Printing"
and contains the packages "hplip" and "hplip-cups".
The same package name "hplip" in both sets should be sufficient
to indicate for the package and repository management software
that both sets are about the same kind of functionality.

(In reply to comment #24)
> Again your point of view: Every issue is openSUSE's fault.
> Even issues caused by hardware crap are openSUSE's fault (bug #556819).

Calling people's hardware "crap" is really going to help! I never used such wording. I wonder what you would say if people called your work crap?

> Great!

Yes, openSUSE's faults are openSUSE's faults because ignoring packman and updates from 11.1 to 11.2 during the QA is a fault, see below.

> By the way:
> I may have even looked at those "another report"
> if you provided an URL to it...

You marked it as resolved duplicate, so you knew about it already.

> Seriously:
> 
> As already explained in comment #17 it is Packman's fault
> because the HPLIP packman packages which claim to be made for
> "Distribution: openSUSE ..." fail to do a perfect replacement
> of our original openSUSE packages.

> On the other hand our our openSUSE HPLIP packages also fail
> to do a perfect replacement of Packman's HPLIP packages
> because the openSUSE HPLIP packages do not obsolete
> Packman's hplip-hpcups package simply because in the
> openSUSE world there is no hplip-hpcups package at all
> and I cannot know magically which package names
> whatever third-party package repository may use.

Let me put it this way:

Everybody knows that packman is used by most opensuse users, i.e. a must. If one wanted to do the best job for the users one would acknowledge that fact and act accordingly.

> Installing the openSUSE 11.2 hplip package does already
> enforce its exact matching hplip-hpijs package via
> the following entry in hplip.spec:
> -----------------------------------------------------------------
> # Require the exact matching version-release of the hpijs
> # sub-package to make sure to have the exact matching version
> # of libhpip and libhpmud installed.
> # The exact matching version-release of the sub-package
> # is available on the same repository where the main-package is
> ...
> Requires:       %{name}-hpijs = %{version}-%{release}
> -----------------------------------------------------------------

Then I wonder why zypper dup did update the hplip package but failed to meet the "Requires...". Because after doing a zypper dup the %{name}-hpijs = %{version}-%{release} was not installed. "Enforcing" is something different for me, i.e. throws at least a warning that some requirement could not be met.

> But even this is no guarantee that the exact matching
> version-release of hplip-hpijs is only available in the
> exact same repository wherefrom hplip was installed.
> On plain RPM level any exact matching version-release
> of any hplip-hpijs package from any repository satisfies
> this RPM requirement.
> 
> For openSUSE 11.3 I will add
>   Obsoletes: hplip-hpcups
> in the hplip.spec file to mitigate further issues
> but this is not more than a band-aid workaround.

If one does not want to get in contact with the packman people to fix the issue at the root of this problem this is the solution that serves the community best since it does not assume a perfect world but packman as part of the openSUSE installation. Hence this solution is in accordance with:

"The goals of the openSUSE project are:

    * Make openSUSE the easiest Linux distribution for anyone to obtain and the most widely used open source platform.
    * Provide an environment for open source collaboration that makes openSUSE the world's best Linux distribution for new and experienced Linux users. "

and should have been there before 11.2 was released instead of blaming it on packman which might be right but fails to serve the community.

And btw. The general statement "HPLIP packman packages do not work for openSUSE 11.0 11.1 11.2" is certainly wrong since it did work for at least three different computers and printers I know.

Every issue is openSUSE's fault.
Even when "zypper dup" does what "man zypper" reads.

This is an autogenerated message for OBS integration:
This bug (515005) was mentioned in
https://build.opensuse.org/request/show/54402 Factory / hplip

Dear Reporter,

Thank you for taking the time to report this bug and helping to make openSUSE better.

We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in openSUSE since the time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test it on a current, supported openSUSE version.

When you test it and it is still an issue, kindly reopen this bug and move it to the tested version of openSUSE. 

Truly yours.