Description of problem:
We use now Centos 4.5 which is klone of Redhat Enterprise Linux 4.5. We noticed
that system-config-printer modyfied file /etc/cups/mime.types in such way: it
commented as default line with application/octet-stream, se we can not print any
more from windows clients: samba+CUPS+raw queues. We think, it shouldn't
happend, system-config-printers shouldn't change mime.types in such way. We
think it is bug in system-config-printer and it is located probably in
util/backend.py in def adjust_mime_type
Version-Release number of selected component (if applicable):
In simply way :)
Steps to Reproduce:
In /etc/cups/mime.types uncomment application/octet-stream then update or
install again system-config-printer - then application/octet-stream will be
commenetd entry for application/octet-steram
don't modify our mime.types - we need uncommented entry: application/octet-stream
It is in Centos 4.5 but it should be for Red hat Linux 4.5, cause
system-config-printer is rebuild for redhat source RPM with no changes in source
This is intentional behaviour. Create a raw queue and you will have that entry
Note: in Red Hat Enterprise Linux 5 the mime.types file is not adjusted by
Created attachment 155082 [details]
screenshot with cups raw printers
Hi. I agree, but we have many cups raw printers, see attachment,
system-config-printers shoudln't change our mime.types ! system-config-printer
don't see, that in our system is raw queue !! So it is bug. When i good
understand, when system-config-printer sees, that in system is one or more raw
queue doesn't comment application/octet-stream ?
Unless you created those printers using system-config-printer, it will not know
about them. I'm afraid this was how the tool was designed. As I said, this
limitation is removed in Red Hat Enterprise Linux 5.
As a work-around you need to create a (dummy) raw queue using system-config-printer.
Ok, we simply uninstalled system-config-printer - when we don't uses this tool
at all. Thx for Your time. Maybe, when resource will be available, this will be
fixed in RHEL 4 update 6 ...