Tagging PPD package with DeviceID.
by George Liu
Tim,
Do you think you can loosen up the requirement for 1284DeviceID string a bit, so PackageKit could be used for a wider array of devices?
Although Port Monitor MIB has been 4-5 years old, it has not been adopted by all printer manufactures.
Most Ricoh devices do not support it. Combined with the seven brands we have, Ricoh has 23.1% copier market share in the US in 2009. http://www.ricoh-usa.com/about/press/releases.asp?id=620 I believe Ricoh has similar market share in Europe and Japan as well.
I believe packageKit can still work for devices without port monitor mib support.
CUPS still can use hrDeviceDesc mib to get manufacture name and model name. ("make-and-model" ipp attribute.).
With that attribute, one can simply construct 1284deviceID as "MFG:make;MDL:model".
If def "examine_file (self, path):" can put in this extra bit of logic (if no 1284DeviceID, construct one using Manufacturer and ModelName", it will be able to tag the PPD package correctly. (Alternatively, if openprinting.org is to create the PPD package, Till could deploy the similar logic)
Then, the next question become how do s-c-p matches a device to a PPD file. Can you elaborate on this session?
-----------------------------------------------------------------------
If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible.
-----------------------------------------------------------------------
George
-----Original Message-----
From: Tim Waugh [mailto:twaugh@redhat.com]
Sent: Wednesday, April 28, 2010 9:19 AM
To: George Liu
Cc: Till Kamppeter; Bin Li
Subject: RE: [Printing-summit] OpenPrinting Summit 2010 - Assigned the Sessions to Hours
Hi George,
You might like to subscribe to the new system-config-printer-devel mailing list:
https://fedorahosted.org/mailman/listinfo/system-config-printer-devel
That's the sort of thing we can discuss there.
On Tue, 2010-04-27 at 13:16 -0700, George Liu wrote:
> Ricoh liked the idea you had for using PackageKit to download/update
> driver very much. We would like to update our PPD file (currently we
> don't put 1284DeviceID in them), and test out the Ricoh PPD package
> with System-Config-Printer (scp).
>
> Can you guide me through the process? I have a couple questions that I
> want to clarify.
>
> 1. How exactly does scp aquires 1284DeviceID? Which CUPS API does it
> use?
Here is the full cycle:
First, you add the 1284DeviceID attributes to your PPD files.
Then you get those PPD files into an RPM source package. One way to do that would be to add/update them in foomatic-db. I periodically pull a new foomatic-db snapshot from openprinting.org into the Fedora 'foomatic-db' package.
Next, the binary RPM is built on Fedora 13. At the very end of this process, Fedora 13's version of rpm will run a special 'provides'
script, /usr/lib/rpm/postscriptdriver.prov, will get run on each of the PPD-providing files to be packaged up in the RPM. You can see that script here:
http://cvs.fedoraproject.org/viewvc/devel/rpm/rpm-4.8.0-psdriver-deps.pat...
(as well as the changes we made to rpm to get it to identify which files provide PPDs)
The provides script is written in Python. Here's the bit that extracts the IEEE 1284 Device ID from a simple PPD file:
class PPDDriver(Driver):
...
def examine_file (self, path):
try:
ppd = cups.PPD (path)
except RuntimeError, e:
# Not a PPD file. Perhaps it's a drv file.
drv = DrvDriver (path)
self.ids += drv.list ()
return
attr = ppd.findAttr ('1284DeviceID')
while attr:
self.ids += attr.value
attr = ppd.findNextAttr ('1284DeviceID')
i.e. it uses the CUPS PPD API from libcups (via pycups).
That provides script tells rpm what tags to attach to the binary RPM package.
When that binary RPM is made available as an update to Fedora, it will be in a yum repository. The repository contains some comparatively small files containing all of the 'Provides:' tags from the packages in the repository, along with which package provides each. In this way, PackageKit running on a Fedora installation is able to download this file, examine it, and decide which packages it would need to download in order to satisfy a given 'Requires:' requirement.
So, the next thing is that a user comes along with their printer, and they plug it into their Fedora installation (or set up a network queue for it, if it's a network printer).
If it's a USB printer, the system-config-printer-udev program collects the IEEE 1284 Device ID from the kernel, asks CUPS for a list of local devices (with IDs) and tries to match the printer against one of the available CUPS devices.
If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible.
When it has got a Device ID, system-config-printer asks PackageKit to install all drivers providing it. (In fact, it asks the PackageKit session daemon to do it, which in turn asks the PackageKit system
daemon.)
> 2. How does scp handles the case for printers without Port Monotor MIB
> support?
If a network printer does not report its IEEE 1284 Device ID in a way that the CUPS backends can collect, system-config-printer won't get a Device ID for it and so won't be able to ask PackageKit to install any drivers.
> 3. I got scp source from git fedora repository. Which file should I
> look at?
The implementation of the automatic printer driver download feature spans several packages actually, so for testing it out, by *far* the easiest way to do it is to download and install Fedora 13 Beta and set up a queue for the printer.
If you're interested in the implementation, it takes quite a bit of
following:
rpm (see the link above)
system-config-printer:
ppdsloader.py contains a class that fetches a list of PPDs from CUPS given an IEEE 1284 Device ID. First it asks both Jockey and PackageKit if they'd like to install any relevant drivers. This is used in system-config-printer.py when a queue is set up.
installdriver.py contains a D-Bus system service that runs in the user's session, and simply forwards the udev hook's D-Bus request on to the PackageKit session daemon. That way, the user gets to accept/decline package installation. See udev/udev-add-printer for the client part of it.
gnome-packagekit:
src/gpk-dbus-task.c (gpk_dbus_task_install_printer_drivers): this handles the actual PackageKit transactions and user interactions
PackageKit:
new enum type for postscriptdriver, as well as special handling in the yum backend
> 4. What are the stesp needed to setup development environment for scp?
> When I run "make" under pycups directory, it tells me "unable to open
> /usr/lib/python2.6/config/Makefile"
I haven't had any other reports of pycups failing to build. What system are you trying that on?
The development environment is quite simple. You don't even have to install anything if you just want to run the main application:
Check out pycups and system-config-printer
# If you don't have pycups installed already:
cd pycups
make
ln -sf ../pycups/cups.so ../system-config-printer cd ..
cd system-config-printer
make run-applet # for the applet
make run # for the main app
But as I said, if you're wanting to try out the automatic printer driver installation you need more than just the system-config-printer changes.
Really you need Fedora 13 Beta.
Tim.
*/
13 years, 6 months
Re: More patches for system-config-printer
by Tim Waugh
...moving this conversation from private mail. I'm going through
patches Till has sent me for system-config-printer with two main
improvements:
* the use of PPD '*Product:' attributes to gather extra names for the
models list
* extra foomatic handling
I've started committing them on the master branch, and am trying to make
sure they are done in order.
This first patch added the ppd-product support and included some extra
PPD filtering:
On Wed, 2010-10-20 at 12:14 +0200, Till Kamppeter wrote:
> On 10/19/2010 05:14 PM, Tim Waugh wrote:
> > Secondly, I'm looking at this hunk of patch:
> >
> > - (make, model) = ppdMakeModelSplit (ppd_make_and_model)
> > + if (not ppdname.startswith("drv:///sample.drv/") and
> > + ppdname.find("/ghostscript/") == -1):
> > + (make, model) = ppdMakeModelSplit (ppd_make_and_model)
> > + else:
> > + try:
> > + make, model = ppd_make_and_model.split(" ", 1)
> > + except:
> > + make = ppd_make_and_model
> > + model = ''
> >
> > and wondering about the exceptions. Looking at the sample.drv drivers,
> > they seem to have reasonably sensible ppd-make-and-model values, don't
> > they?
> >
> > Also, I'm not sure which PPDs you are filtering out whose names contain
> > "/ghostscript/", or why -- can you elaborate?
>
> These PPDs come from the Ghostscript package. The Make/Model
> purification in ppdMakeModelSplit() cuts off everything beginning from
> "Series" assuming that that part of the NickName is about the driver and
> not the model name any more. This works well for the
> manufacturer-supplied PPD files but for the Ghostscript ones it gives
> "HP LaserJet" and "HP Color LaserJet", putting the PCL 6/XL driver
> choice to old HP printers which do only PCL 4 or PCL 5c. So here I make
> the exception not to purify at all so that the user knows that these are
> generic PPDs for PCL 6/XL.
>
> A similar problem happens also with the PPDs generated by sample.drv.
> Cutting the NickName at "Series" here also assigns all PPDs to the very
> first models.
I see. I wonder whether stripping "Series" is the right thing to do
anyway if we are able to use *Product: attributes. It seems like "HP
DeskJet Series" is a reasonable ppd-make-and-model when someone wants to
look through and find a driver but their specific model isn't listed.
Tim.
*/
13 years, 6 months
pysmbc port to Python 3.x
by Patrick Geltinger
Hello out there,
I'm posting this to this list because I didn't know where to put it
instead or rather who I should send it to.
Well, as part of our work on pyNeighborhood [1], we were thinking about
changing the Samba/NetBIOS lookup procedure to use pysmbc instead of
additional system calls to tools like smbtree or smbclient.
But we had problems with the fact, that pysmbc doesn't work with Python
3.x versions, which we wanted to use for our future releases. Therefore
I've ported pysmbc to support both Python 2.x and Python 3.x versions.
I've you're interested in merging it into your upstream sources, you can
find both a whole new tarball and a patch file here:
tarball: http://www.patlkli.org/static/pysmbc-py3k.tar.gz
patch: http://www.patlkli.org/static/python3-port.patch
Sincerely,
Patrick Geltinger
[1] https://launchpad.net/pyneighborhood
13 years, 6 months
Per-printer preference overrides for arbitrary drivers
by Tim Waugh
Hi,
I've just pushed a branch called xml-driver-preferences which contains
some work I've been doing for this feature:
https://bugzilla.redhat.com/show_bug.cgi?id=550315
The idea is to have the "preferred driver order" come from an XML
definition. This can embody rules such as "use hpcups on HP printers",
as well as having the default "best order".
This can be as coarse- or fine-grained as you choose. The order is
based on driver "types", e.g. gutenprint, generic driver, hpcups,
foomatic-recommended, etc, and these types are defined in terms of
regular expressions applied on PPD names and attributes.
The preference order, in terms of driver types, is then created by
applying regular expressions to the device-make-and-model and the IEEE
1284 Device ID.
The resulting list of driver types is then converted into a list of
actual PPDs, those that are a likely match for this printer.
See what you think. I'm especially interested in feedback about the XML
format because I'd rather not have to change it later. There are RELAX
NG schemas for both types of file.
Tim.
*/
13 years, 6 months
CUPS 1.4.4 slows down with system-config-printer-applet
by John A. Murdie
Tim - I'm continuing the thread "CUPS 1.4.4 slow - problem checklist?" I
started in the cups.general forum, here. I'll summarise the problem.
We have two cupsd processes (staff, student) on a Slackware Linux 13.1
print server running as a virtual machine on server hardware.
I found that only two users running system-config-printer-applet
('scpa') on their Linux desktops was enough to take cupsd CPU% (as
measured by top(1)) to 99% - just one will take it to 60-80%. I don't
know what version of scpa we have as default on our system, but version
1.2.5 from the 13th October also causes the problem.
Running scpa as 'system-config-printer-applet --debug', I saw:
> $ /usr/share/system-config-printer/system-config-printer.py --debug
> Connected as user john
> refresh
> <monitor.Monitor instance at 0x9b13eec>: CUPS IPP error (1025, 'client-error-forbidden')
> Created subscription -1
> <monitor.Monitor instance at 0x9b13eec>: printers and jobs lists provided
> update_jobs
> Authentication pass: 1
> Authentication: password callback set
> Authentication pass: 1
> Authentication: password callback set
> Authentication pass: 1
> Authentication: password callback set
> get_notifications
> refresh
> <monitor.Monitor instance at 0x9b13eec>: CUPS IPP error (1025, 'client-error-forbidden')
> Created subscription -1
> <monitor.Monitor instance at 0x989eeec>: printers and jobs lists provided
> update_jobs
> get_notifications
> refresh
> <monitor.Monitor instance at 0x989eeec>: CUPS IPP error (1025, 'client-error-forbidden')
> ...
Now, to discuss the problems:
1. You wrote:
>> <monitor.Monitor instance at 0x9b13eec>: CUPS IPP error (1025, 'client-er=
> ror-forbidden')
>> Created subscription -1
>
> This looks like IPP-Create-Subscription is not allowed for this client,
> due to the way CUPS is configured. Subscriptions are more efficient for
> this sort of application because it can be told about relevant changes
> rather than having to fetch the entire list each time:
I attach our server's cupsd.conf file (bowdlerised with "whatever"s!),
which contains:
> # Set the default printer/job policies...
> <Policy default>
>
> # Job-related operations must be done by the owner or an adminstrator...
> # Note that we need to 'Allow from localhost' for Windows LPR printing
> <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs
> Set-Job-Attributes Create-Job-Subscription Renew-Subscription
Cancel-Subscription
> Get-Notifications Reprocess-Job Cancel-Job Cancel-Current-Job
Suspend-Current-Job
> Resume-Job CUPS-Move-Job Get-Job-Attributes
CUPS-Authenticate-Job>
> Order allow,deny
> AuthType Default # required to force authentication
> Require user @OWNER @SYSTEM
> Allow from localhost
> Satisfy any
> </Limit>
That has Create-Job-Subscription etc permissions for all users. Perhaps
the 'Allow from localhost' - i.e. the print server - ought to be applied
more selectively, but it was there to allow print jobs coming in by
cups-lpr from Windows systems to proceed. I see from the CUPS document
'Managing Operations Policies' -
http://www.cups.org/documentation.php/doc-1.4/policies.html - that I'd
missed various subscription-related policies (Yes: I have it; No - I
don't have it):
Create-Printer-Subscription No
Create-Job-Subscription Yes
Get-Subscription-Attributes No
Get-Subscriptions No
Renew-Subscription Yes
Cancel-Subscription Yes
Get-Notifications Yes
Send-Notifications No
Do I need all of the ones I have not used? I think I took the original
set from an example CUPS configuration file, long ago.
2. You also wrote:
>> <monitor.Monitor instance at 0x9b13eec>: printers and jobs lists provided
>
> But how often is it doing that? Does it happen continuously even when
> there is no activity, or does it only happen whenever there is some
> change in the status of a job?
It does seem to happen continually even when there is no activity, as
fast as CUPS can respond - which is presumably why the CPU% of cupsd
rises to 99%.
John A. Murdie
13 years, 6 months
pycups: new getPPDs2() method
by Tim Waugh
I've just pushed a change to the pycups repository that indicates the
general direction I'd like to take the pycups interface.
Generally, IPP responses are returned as dicts, with the attribute names
being the keys and the attribute values being the values. For specific
attribute values that are known to be lists, the values are encoded as
lists even if there is only one value in the list; other values are
encoded as a single object.
This is hard to get right in pycups, and hard to predict in applications
that use it. I'd like to make it much more consistent.
To that end, I'd like to have all attribute values encoded as lists,
even if there is only one value and only ever could be.
This is how cups.Connection.getPPDs2() behaves.
>>> from pprint import pprint
>>> import cups
>>> c=cups.Connection()
>>> p=c.getPPDs2()
>>> pprint(p[p.keys()[0]])
{'ppd-device-id': [u''],
'ppd-make': [u'Epson'],
'ppd-make-and-model': [u'Epson Stylus Photo 2200 - CUPS+Gutenprint
v5.2.5 Simplified'],
'ppd-model-number': [0],
'ppd-natural-language': [u'en'],
'ppd-product': [u''],
'ppd-psversion': [u''],
'ppd-type': [u'postscript']}
The old behaviour is still present, for compatibility, in
cups.Connection.getPPDs().
Tim.
*/
13 years, 6 months
system-config-printer-1.2.5 is released
by Tim Waugh
I've released system-config-printer 1.2.5. A summary of the changes:
- CMD-field matching for PPDs (bug #630058).
- Avoid crash in jobviewer (bug #640904).
- Don't try to modify firewall for SNMP broadcast responses
as it doesn't work (trac #214).
- Correctly parse snmp backend output when fetching
Device ID (bug #639394).
- XmlHelper: Don't indent output when saving to file (bug #639586).
- GroupsPaneModel: Avoid crash when removing queue (bug #639586).
- Use "Do It Later" instead of "Cancel" for adjust firewall
dialog (trac #213).
- Delete Bluetooth printer's queue when unpaired.
- Show examples of IPP URIs (bug #575795).
- Use actual Device ID strings in 'no match' debug
message (bug #630350).
- Prevent disallowed characters in text entry fields when adding
new printer (bug #621199).
- Fixed race condition while renaming printer (bug #625502).
- Request required job attributes rather than assuming they will
be present in response (bug #635719).
- Discard disallowed characters when renaming (bug #612315).
- Mark more translatable strings (bug #634436).
Tim.
*/
13 years, 6 months
