Hi,
I have a weird situation here. I hit it trying to help another user.
openSUSE 12.3 32 bits, new install.
Desktop - irrelevant (several).
Yast -> hardware -> printer -> Add new printer configuration.
On “find and select a driver”, type anything, like “hp”, then click
“search”. No drivers are found.
Equivalent procedure on localhost:631 cups web page - “Unable to get
list of printer drivers:”
openSUSE 12.3 64 bits. System upgraded many times.
Do same thing - many drivers found.
64 bits:
Telcontar:~ # rpm -qa | grep cups
liboyranos0-cups-0.9.1-2.1.1.x86_64
cups-pk-helper-0.2.4-3.1.1.x86_64
cups-devel-1.5.4-5.2.1.x86_64
python-cups-1.9.61-5.1.1.x86_64
python-cupshelpers-1.3.12-4.2.1.noarch
cups-1.5.4-5.2.1.x86_64
cups-libs-1.5.4-5.2.1.x86_64
cups-backends-1.0-273.1.1.x86_64
cups-libs-32bit-1.5.4-5.2.1.x86_64
libgnomecups-0.2.3-131.1.1.x86_64
cups-client-1.5.4-5.2.1.x86_64
Telcontar:~ #
32 bits:
AmonLanc:~ # rpm -qa | grep -i cups
cups-backends-1.0-273.1.1.i586
cups-client-1.5.4-5.2.1.i586
cups-libs-1.5.4-5.2.1.i586
python-cups-1.9.61-5.1.1.i586
cups-1.5.4-5.2.1.i586
python-cupshelpers-1.3.12-4.2.1.noarch
cups-pk-helper-0.2.4-3.1.1.i586
AmonLanc:~ #
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2013-09-14 00:56, deano ferrari wrote:
>
> Strange indeed - likely bug I guess. Do you think this old thread may be
> related or provide some clue?
>
> http://tinyurl.com/m3f4ffe
It is the same problem, yes. Thanks for locating it, my thunderbird does
not go that far back (but it should).
It mentions the directory “/usr/share/cups/model/manufacturer-PPDs/”. I
have that directory, and as far as I can see, it is the same on both
machines.
Baffling.
Maybe there is a bad configuration file somewhere.
The thing is, I do not really need the printer in that machine, I was
trying to replicate another user problem, and for that I needed to
configure any printer first… Sigh.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I note in post #3 that user ‘relative’ simply copies the directory to a backup location, then back again. In doing that, it seemed to restore ‘readability’ somehow. Might be worth a try?
Update: Couldn’t let this go. I had copied the entire /usr/share/cups/model directory to a backup. I restored each of the subdirectories from the backup and tested after each one and couldn’t repeat the failure. I am back where I started and everything works normally. My only guess is that one or more of the .gz files was unreadable (although the copy and copy back seemed to work), and now there are no unreadable files.
On 2013-09-14 02:16, deano ferrari wrote:
>
> I note in post #3 that user ‘relative’ simply copies the directory to a
> backup location, then back again. In doing that, it seemed to restore
> ‘readability’ somehow. Might be worth a try?
But he also copies in a ppd file from outside.
Ok, I’ll try.
/usr/share/cups/model backup made.
/manufacturer-PPDs directory removed.
/OpenPrintingPPDs removed.
/gutenprint removed.
Run yast printer module.
Add printer.
“Search for” now finds two HP (generic?) printers… go figure. None is
mine, though.
Hit cancel. Hit Ok. Config written (no printer).
Restore backed-up directories.
Run yast printer module.
Add printer.
Takes a long time searching for printer drivers.
Type “HP” in dialog, hit search… takes time… and drivers are found!
And I can print a “hello world” sample page.
I hate this. O:-)
It works, but it is a black magic solution. We have no idea why it did
not work and now it works, the files are exactly the same!
There must be a database built somewhere that fails to build correctly.
Thank you for convincing me to try, though…
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I wonder if the error would have revealed itself in /var/log/cups/error_log perhaps?
On 2013-09-14 07:56, deano ferrari wrote:
>
> I wonder if the error would have revealed itself in
> /var/log/cups/error_log perhaps?
Nope. I looked. I also looked on yast logs.
/Maybe/ if I had increased verbosity…
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)