On Thu, 2010-05-06 at 17:35 -0700, George Liu wrote:
If it's OK with you, Ricoh will update all 1300+ PPD files and add 1284DeviceID field. (We had a script to generate those PPD files)
Yes, sure.
Is there a timeline by when you absolutely need it done? (Will the package be part of Fedora 13 DVD or just sit in the repository)? Our current plan is get it done in two weeks since you clarified exactly what we need to put in PPD files. (We'll put "MFG:xxx;MDL:xxx;")
No, there's no real hurry. It's already too late for a new foomatic-db package in Fedora 13 really, so it will be an update anyway at this point. Fedora 13 is already past final freeze: https://fedoraproject.org/wiki/Releases/13/Schedule
(In Fedora 13 I have modified the CUPS dnssd backend since F-13 Beta
so that it adds a special field "FZY" to aid with debugging this sort of thing. If I see that "FZY:1;" I know the ID is fabricated. On the other hand, if I see "FZY:0;" I know it's from usb_* fields.)
For the case of "fabricated" device ID done by dnssd, does Fedora 13 treat those as legitimate, and performs the same PackageKit matching algorithm?
Yes. The "FZY" thing is just so I can see from bug reports whether we're dealing with real Device IDs or whether a CUPS backend has invented it.
I hope to phase out the OpenPrinting web query mechanism in favour
of PackageKit once all the pieces are in place. Similarly with Jockey, if possible. We still need that mechanism for devices that does not provide 1284DeviceID. Can you point me to the source code where it does the web query?
I'm still not convinced that any other mechanism is required once:
1. CUPS backends invent Device IDs for devices that do not provide them but which do provide something akin to make-and-model
and
2. PPDs for affected printers include these invented IDs
For reference, though, the openprinting web query client is in cupshelpers/openprinting.py.
Tim. */