/usr/share/ppd is where the PPDs are located for me.
And, sorry, by removing the recursive symlinks, I no longer have this issue.
It was pretty straightforward, as I remember. In /usr/share/ppd/foo/bar there
would be a link to /usr/share/ppd/foo.
When the update script ran, it would recursively
Justin, which directory do you call "PPD cache"? Can you still reproduce
this? If you have a directory of PPDs which exhibits this issue, can you
please tar it and attach it here, so that we can reproduce it as well?
Thank you!
** Changed in: cupsys (Ubuntu)
Status: Confirmed => Incomplete
Resolved the issue by deleting the ppd cache. Apparently there were
recursive symlinks in the ppd directory which had caused an over 81k
ppds to be cached. I do not know how this came to be; but, somewhere in
the various and sundry upgrades it happened.
--
gnome-cups-add causes cupsd/cups-driverd
ran 'cups-driverd list 1 0 name=""' and found where the process hangs.
cups-driverd churns through PPDs at a rate of several per second until
it hits this point
DEBUG: [cups-driverd] Adding ppd
"lsb/opt/hpijs/HP/HP-OfficeJet_Series_580-hpijs.ppd"...
DEBUG: [cups-driverd] Adding ppd
"lsb/opt/hpij
Confirmed, so I changed status.
** Changed in: cupsys (Ubuntu)
Status: Invalid => Confirmed
--
gnome-cups-add causes cupsd/cups-driverd to spin forever
https://bugs.launchpad.net/bugs/39078
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subsc
I am experiencing this issue on a server running Intrepid. Using the
CUPS web interface to add a printer triggers a seemingly endless wait
with cups-driverd using all available CPU cycles. So far I have let it
run for over two hours and twenty minutes. Admittedly, this is an old
box (PIII-500/512MB
