Bug 380591 - CUPS requires UTF-8 IPP requests
CUPS requires UTF-8 IPP requests
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Simo Sorce
Fedora Extras Quality Assurance
Depends On:
Blocks: 380431
  Show dependency treegraph
Reported: 2007-11-13 12:48 EST by Tim Waugh
Modified: 2009-07-14 12:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 12:30:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
samba-cups-utf8.patch (12.19 KB, patch)
2007-11-13 12:48 EST, Tim Waugh
no flags Details | Diff
samba-cups-utf8.patch (21.76 KB, patch)
2008-01-21 12:35 EST, Tim Waugh
no flags Details | Diff

  None (edit)
Description Tim Waugh 2007-11-13 12:48:01 EST
Description of problem:
The latest upstream version of CUPS, 1.3.4, requires IPP requests to be made
with attributes-charset 'utf-8'.  Other requests are rejected.

For Fedora I have built a cups-1.3.4-3.fc8 package which relaxes this
restriction altogether, but I will not keep this patch around forever.

I have started a patch for samba to create UTF-8 requests.  However, more work
is needed to deal with UTF-8 responses.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0.Install a CUPS version with the UTF-8 restriction in place, such as
1.Edit /etc/sysconfig/i18n and set LANG to 'en_US' instead of 'en_US.UTF-8'.
3.CUPS printers are no longer available via samba.
Comment 1 Tim Waugh 2007-11-13 12:48:01 EST
Created attachment 257131 [details]
Comment 2 Simo Sorce 2007-11-13 15:56:52 EST
Tim, this poatch seem to simply remove any way to specify which language is
used, but does not so anything to convert to utf-8 any data being passed. As it
is I don't think it makes much sense upstream.
Or is there something I am missing? (I gave only a very quick look so far)
Comment 3 Tim Waugh 2007-11-14 04:59:00 EST
Yes, indeed, you are right.  Things like printer-uri and (probably)
requesting-user-name may contain non-ASCII characters and so those strings will
need to be converted to utf-8 before putting them in the request.

Should this be done with iconv() or does samba have its own helper functions for
doing this?  I'd like to help out with the patch but don't know the samba source
very well.
Comment 4 Tim Waugh 2007-11-14 05:02:01 EST
Incidentally, while looking at other print methods to see how they do it, it
looks like print_iprint.c is missing the necessary character set conversions as
Comment 5 Simo Sorce 2007-11-14 09:58:08 EST
We have our own wrappers serach for utf8 in /source/util/*str*
We will probably need to translate from the "unix charset" to utf8 in this case.

Comment 6 Simo Sorce 2007-11-14 10:01:30 EST
Tim btw, please make any patch against the 3.2.x git branch, the 3.0.x series is
in maintenance mode only, any new development is done in 3.2 now.
Comment 7 Tim Waugh 2008-01-10 13:00:20 EST
Sorry for the slow progress on this.  I hope to be able to get back to it soon.
Comment 8 Tim Waugh 2008-01-21 12:34:39 EST
Re-reading this I see that the existing patch needs some explanation.  The
old-style ippNew() call just creates a new IPP request structure, and the caller
fills in the required attributes-charset and attributes-natural-language attributes.

The new-style way of doing that is to call ippNewRequest().  This creates an IPP
request structure and fills in the minimally-required attributes, including
attributes-charset (which is set to "utf-8").
Comment 9 Tim Waugh 2008-01-21 12:35:40 EST
Created attachment 292389 [details]

Here is a new version of the patch, using push/pull_utf8 functions to convert
to/from UTF-8 as necessary.

What do you think?
Comment 10 Simo Sorce 2008-01-21 12:52:43 EST
Make sense to me, do you want to test it in F8 and then commit it upstream if it
works completely as expected ?
Comment 11 Simo Sorce 2008-01-21 12:54:45 EST
Pressed enter too quick. The problem I see with this patch upstream is that, if
I understood correctly, this patch will work only with newer versions of CUPS.

I guess upstream should instead support both new and old ones and a different
patch that detects what we have at compile time (or maybe if possible at runtime
?) would be required there ?
Comment 12 Tim Waugh 2008-01-21 13:01:10 EST
Is there a requirement that samba still compiles against CUPS-1.1.x?  The
ippNewRequest() interface has been around since CUPS-1.2.x.
Comment 13 Tim Waugh 2008-01-21 13:02:21 EST
Another thing is that need not necessarily go into Fedora 8, but instead could
stay in rawhide until it's tested some more.  In Fedora 8 I have patched CUPS so
that it accepts non-UTF-8 IPP requests, but in rawhide I no longer apply that patch.
Comment 14 Simo Sorce 2008-01-21 13:14:33 EST
> Is there a requirement that samba still compiles against CUPS-1.1.x?

We build samba on *many* different platforms, if CUPS 1.1.x is still in use then
yes we should try not to require one specific version. I guess we need to ask
the broader samba community in this regard though. If we drop support for 1.1.x
we need to detect that in configure and fail to compile if cups support is

For Rawhide, have you tried to patch samba 3.2.0preX ? that is what we have
there, I can't recall that code changing, but if we want it there at this point
it may make sense to move the discussion upstream and have it included in pre2
(to be released very soon).
Comment 15 Tim Waugh 2008-01-23 07:22:13 EST
Well, it's simple to cope with 1.1.x really.  This call:

request = ippNewRequest(x);

needs to be replaced with:

cups_lang_t *language = cupsLangDefault();
request = ippNew();
request->request.op.operation_id = x;
request->request.op.request_id = 1;
             "attributes-charset", NULL, "utf-8");
             "attributes-natural-language", NULL, language->language);

This can be done by defining ippNewRequest() ourselves if the CUPS we are
compiling against is earlier than 1.2.x:

   (CUPS_MAJOR_VERSION == 1 && \

static ipp_t *
ippNewRequest(ipp_op_t x)
  cups_lang_t *language = cupsLangDefault();
  ipp_t *request = ippNew();
  request->request.op.operation_id = x;
  request->request.op.request_id = 1;
               "attributes-charset", NULL, "utf-8");
               "attributes-natural-language", NULL, language->language);
  return request;
Comment 16 Bug Zapper 2009-06-09 19:10:44 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 17 Bug Zapper 2009-07-14 12:30:43 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.