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): samba-3.0.26a-6.fc8 How reproducible: 100% Steps to Reproduce: 0.Install a CUPS version with the UTF-8 restriction in place, such as cups-1.3.4-2.fc8. 1.Edit /etc/sysconfig/i18n and set LANG to 'en_US' instead of 'en_US.UTF-8'. 2.Reboot. 3.CUPS printers are no longer available via samba.
Created attachment 257131 [details] samba-cups-utf8.patch
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)
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.
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 well.
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. Simo.
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.
Sorry for the slow progress on this. I hope to be able to get back to it soon.
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").
Created attachment 292389 [details] samba-cups-utf8.patch 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?
Make sense to me, do you want to test it in F8 and then commit it upstream if it works completely as expected ?
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 ?
Is there a requirement that samba still compiles against CUPS-1.1.x? The ippNewRequest() interface has been around since CUPS-1.2.x.
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.
> 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 requested. 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).
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; ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_CHARSET, "attributes-charset", NULL, "utf-8"); ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_LANGUAGE, "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: #define HAVE_CUPS_IPPNEWREQUEST \ (CUPS_MAJOR_VERSION >= 1 || \ (CUPS_MAJOR_VERSION == 1 && \ CUPS_MINOR_VERSION >= 2)) #if !(HAVE_CUPS_IPPNEWQUEST) 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; ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_CHARSET, "attributes-charset", NULL, "utf-8"); ippAddString(request, IPP_TAG_OPERATION, IPP_TAG_LANGUAGE, "attributes-natural-language", NULL, language->language); return request; } #endif
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.