Red Hat Bugzilla – Bug 133475
Errata rpm messes with cups config files
Last modified: 2007-11-30 17:10:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0) Opera
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
In /etc/cups/printers.conf, I had this printer setup (copied from
Info Samsung ML-1510. Accepts Samsung SPL or CUPS Postscript jobs
JobSheets none none
The 'Info' line got changed to the default "Created by redhat-config-
On another server, I chmod those config files to read-only and still
they were touched!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Edit the config files
2. RPM -Uvh foomatic-3.0.1-3.1
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 -
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.