From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0) Opera 7.54 [en] Description of problem: Raw printing from windows box to samba/cups printer worked fine until foomatic update was installed. For raw printing to work, one needs to uncomment line 157 in /etc/ cups/mime.types to enable the application/octet-stream mime-type. After update, this was commented out again. It broke windows printing. In /etc/cups/printers.conf, I had this printer setup (copied from backup): <DefaultPrinter ML1510> Info Samsung ML-1510. Accepts Samsung SPL or CUPS Postscript jobs Location Bookshelf DeviceURI usb:/dev/usb/lp0 State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 </Printer> The 'Info' line got changed to the default "Created by redhat-config- printer 0.6.x". On another server, I chmod those config files to read-only and still they were touched! Version-Release number of selected component (if applicable): foomatic-3.0.1-3.1 How reproducible: Always Steps to Reproduce: 1. Edit the config files 2. RPM -Uvh foomatic-3.0.1-3.1 Additional info:
For raw printing, either use 'lpr -oraw ...' or create a raw queue. Creating a raw queue in system-config-printer has the effect of causing the mime.types file to be correctly updated. You should not change system-config-printer-created queues in printers.conf by hand, or edit them via the CUPS web interface, as your changes will be undone. Either change the queues with system-config-printer, or create queues using the CUPS web interface.
The nice thing about the raw mimetype setting is that cups can automagically print either raw or postscript data. This is very usefull for samba network clients. Windows using the printers native driver and unix/OS2/mac clients using a postscript/ppd driver. The solutions you present do not allow that as far as I know. System- config-printer only lets you create a raw OR cups queue. The mime.types file clearly states: "# Uncomment the following type and the application/octet-stream filter line in mime.convs to allow raw file printing without the - oraw option." It does not say anything about not editing these files, so how should I know? Bluntly overwriting config files without warning or backup undermines the good old Linux config file editing spirit imho. My solution is "rpm -e system-config-printer". I hope it works. Maybe I should move this bug to the system-config-printer component?
If you create a raw queue, called anything you like, and don't use it, the octet-stream mime type will be enabled. Perhaps system-config-printer should only ever *uncomment* that line, and never *comment* it out.
I think that is a good idea. You may even *comment* the line again when s-c-p deletes the last raw queue, but leave otherwise untouched. The 'Info' line is usefull to edit as it shows up as comment on the printer properties page on the windows/samba client. I suggest you insert the 'Info Created by..' line only when the printer is being created, not when it is already there.
Unfortunately that Info line is needed, otherwise deleted queues won't get cleaned up.
Couldn't you make the Info line take the form Something useful (SOMETAG) instead? SOMETAG could then be used to identify queues needing cleaning up, but the "Something useful" could be the name of the printer? "Info" is interpreted as printer name by at least Mac OS X, so that my Linux cups printers appear nicely on my Mac OS X box but with all the same name: "Created by redhat-config-printer 0.6.x". Not the end of the world but irritating. SOMETAG could be RCP0.6.x or even use characters like § which are very unlikely to appear in a printer description. And I want to reiterate what is said by Joost - overwriting config files without even leaving a backup is bad, bad, bad.
The fact that Mac OS X basically can't use the print queues we create (because of this Info line thing) is detailed in a separate bugzilla. Your idea is a good one to work around this problem; thank you.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
(Closing.)