From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux; X11; en_US) KHTML/3.4.1 (like Gecko)
Description of problem:
In my particular case I did not have PyQt package installed, which failed the toolbox.
Need dependence for this, sip, sane, etc.
PS: The source rpm does not build these packages...seems like a bogus spec file.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install hplip without PyQt
Oops, I thought I had fixed that but obviously it got lost between my test
package and actually committing to CVS.
Fixed in CVS.
Requires: PyQt added, and this brings in sip.
> PS: The source rpm does not build these packages...seems like a bogus spec
I think you must be referring to the fact that hplip is not listed in the
components in bugzilla. I'll see about fixing that.
No....actually the spec file from source rpm is incomplete. For example it
calls desktop-utils on a .desktop file which does not exist. The source
does not contain any desktop files and in Mardriva spec file the desktop file
is created in the spec file itself, so I don't see how this source rpm produced
the installed rpms!
# rpm -ql hplip|grep desktop
It really is in the tarball, if you look closely.
It is generated in the Makefile .... BUT there are two options depending
on what the configure script assigns to ICON_FILE variable. If this is
assigned hplip.desktop then it creates a hplip.desktop file. If it is
assigned just hplip then it creates a file called hplip. In my case when
the configure runs it is setting ICON_FILE to hplip and thus not generating
a hplip.desktop file. I could not figure out the code in the configure
script that assigns this variable and why it gives different answers. I do
not have GNOME stuff installed just KDE.
Created attachment 115263 [details]
This patch fixes my rpm build problem
The attached patched fixes the problem. In principle this should also be fixed
in configure.in file.
Can you try just changing this line (further down):
That looks like a typo to me, and might be causing the probems you are seeing.
Actually, why do you have a /usr/lib/menu directory in the first place? What
does 'rpm -qf /usr/lib/menu' say?
No....doing that did not fix the problem.
I did have an empty /usr/lib/menu directory that does not belong to any rpm.
OK.... if I don't have /usr/lib/menu than it works without the patch!
Well, anyway I'll apply that patch for 0.9.3-1.