hplip 2.7.10 is not working with cups 1.3.4

Bug #162196 reported by Zbigniew Luszpinski on 2007-11-12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
hplip (Debian)

Bug Description

printer: HP DeskJet 5940
cups 1.3.4
hplip 2.7.10

error: Printer queue setup failed.Please restart CUPS and try again.

Restarting and reinstallation of cups not solves the problem.

hplip 2.7.10 fails because of cups 1.3.4

fix: downgrade to cups 1.3.3
(remember: it is not enough to downgrade cups, you also have to restart cups service to make hplip working)

for hplip developers: how to reproduce cups 1.3.4 problem:
1. install cups 1.3.4
2. restart cupsd service
3. run hp-toolbox - it will not find printer -> hp-setup will start
During setup the folowing error messages appear:
"PPD not file found." (this is not typing mistake this is real messagebox text)
when hp-setup finishes, on last page, "Printer queue setup failed."
4. downgrade to cups 1.3.3
5. run hp-toolbox to make sure you still get errors
6. restart cupsd service
7. run hp-toolbox -> works

Thanks for the bug report.

What distro/version are you using?


Zbigniew Luszpinski (zbiggy) wrote :

What distro/version are you using?

Lunar Linux 1.6.0-i686 (Indium Antimonide - 20060323)
Kernel on an i686

This is source based distro so I can test any source patches.

P.S. If someone will make non official patch fixing cups 1.3.4 send it to me.

The reproduce way I provided is the easiest one. This bug is not hp-toolbox problem - it was only provided as an example because there are visible error boxes. This is printing problem, looks to be PPD related. With cups 1.3.3 the ppd driver is autodetected (foomatic:/usr/share/foomatic/db/ppd/HP-DeskJet_5940-hpijs.ppd) thanks to foomatic-3.0.
With cups 1.3.4 hp-setup says the ppd driver can not be found and asks to find the path manually.
So I browse to /usr/share/foomatic/db/ppd/HP-DeskJet_5940-hpijs.ppd and then hp-setup says "Printer queue setup failed."

Zbigniew Luszpinski (zbiggy) wrote :

more detailed report:
Printing in KDE and OO or other apps is working.
Console hp-* tools are working except:
hp-toolbox (lies there is no HP printer installed "No installed HP devices found", no access to printer tools because there is no printer, etc)
hp-testpage (when executed, test page lands in printer queue with error and is not printed)
hp-setup (all these messageboxes: "PPD not file found.", "Printer queue setup failed.")

So solving this issue is to fix hp-toolbox, hp-testpage and hp-setup by adding cups 1.3.4 support.
I think problem lies in handling ppd/printer scheduler/queue.

Here is 1.3.3->1.3.4 changelog:

changes which may have impact on this issue:
-The scheduler now validates device URIs when adding printers.
-Updated httpSeparateURI() to support hostnames with the backslash character.
-The scheduler did not reject requests with charsets other than US-ASCII or UTF-8, and the CUPS API incorrectly passed the locale charset to the scheduler instead of UTF-8
-cups-deviced did not filter out duplicate devices.

If you need additional info feel free to ask.

Thanks I'll need to do some additional testing and see if I can reproduce. I should have some results later this week.


Changed in hplip:
status: New → In Progress
Zbigniew Luszpinski (zbiggy) wrote :

Thank you Aaron. Let me know your findings (good or bad). I'm particularly interested if bug is reproducible or not. Thanks to this I will know if I have any chances in fixing my box myself or just have to wait for global fix.
cups 1.3.4 issue is not painful but just nice to have fixed.

This is source of problem (I suppose):
From cups 1.3.4 changelog:
"The scheduler did not reject requests with charsets other than US-ASCII or UTF-8, and the CUPS API incorrectly passed the locale charset to the scheduler instead of UTF-8"

hp-toolbox fails if LC_ALL=pl_PL is set (Polish locale, usually ISO-8859-2 codepage, my default locale)

general fix, run from console to set LC_ALL to default English:
LC_ALL=C hp-toolbox

when I still use pl_PL for every localization variable and type:
LANG=C hp-toolbox
then hp-toolbox says there is no printer and red error appears on console:
"error: Invalid locale: C.utf8"

fix for Polish locale (Polish locale remains Polish but default ISO-8859-2 codepage is changed to UTF8:
LC_ALL=pl_PL.UTF8 hp-toolbox

Now the bad thing:
hp-testpage always fails:
LC_ALL=C hp-testpage
LC_ALL=pl_PL.UTF8 hp-testpage
so LC_ALL fix not works in this case at all.
However hp-testpage is not used very often so is not very important. However people may start reporting false bugs when they realize hp-testpage fails.

The problem may appear to all people using ISO-8859-* codepages selected by locale. It only exist since cups 1.3.4 so this error may appear more often when distro makers will begin to use cups 1.3.4

Here are my locale:

Zbigniew Luszpinski (zbiggy) wrote :

Sorry for the mess but I found universal trick:
LC_ALL=$LANG.UTF8 hp-toolbox
(it takes current language and sets LC_ALL to UTF8 for hp-toolbox)
the advantage is it is language/country independent so easy to use in programming :-)

Stefan Skotte (screemo) wrote :

I can confirm this problem as well. Setting my locale to LC_ALL=C, everything works. I have the following locale:


Zbigniew Luszpinski (zbiggy) wrote :


more comfortable is LC_ALL=$LANG.UTF8 hp-toolbox
just type it into text console.

If you use KDE you can apply the fix to hp-toolbox icon in K menu.
(see attached picture to learn how to do it in K menu editor)

Bourdieu (mathieu-bouillaguet) wrote :

Confirmed on slackware current with cups 1.3.5 and hplip 2.7.10

Is this still happening if you use the latest release of hplip?



Johannes Meixner (jsmeix) wrote :

It doesn't work at least for me using HPLIP 2.8.2 from
on openSUSE 10.3 with CUPS 1.3.5 from

When I start as user with en_GB.iso885915 locale
the hp-toolbox,
I get a "No Installed HP Devices Found" error popup
and /var/log/cups/error_log (with LogLevel debug) shows

CUPS-Get-Printers client-error-bad-request:
Unsupported character set "iso-8859-15"!

But hp-toolbox works well when I run it with the command

The solution is that hp-toolbox must use only UTF-8
when it talks to the cupsd because UTF-8 (which includes
7bit-ASCII) is the only character set which is supported
by CUPS 1.3 (see the mails on <email address hidden>).

I.e. the application must convert any non-7bit-ASCII
string to UTF-8 before it is sent to the cupsd.

Bourdieu (mathieu-bouillaguet) wrote :

The bug is confirmed with hplip 2.7.12 or 2.8.2. I'm using cups 1.3.5.

The workaround suggested by Zbigniew Luszpinski works in both cases for me (set LC_ALL to $LANG.UTF8).

The only difference is that with hplip 2.8.2 the ppd file isn't found automatically. I have to to browse and select the right file.

Sorry guys, I'm not 100% clear on how to reproduce this and/or how your systems are configured.

Apparently it's happening on at least these distros:

Suse 10.3

We don't test Slackware or Lunar, we do test Suse 10.3 and we haven't seen this. So I must be missing some essential step on configuring my test system. What language are you choosing as the default? What languages are you guys using and see to be effected? Also any steps that will help me to reproduce this will help me in getting this solved in our tip for the next release.

Thanks for the help!


Zbigniew Luszpinski (zbiggy) wrote :

@Aaron, to reproduce the error your locale have to be set to any ISO codepage.
This bug is not bound to any particular distro. It depends on which locale settings the user will choose during distro install. For example for UTF8 or ascii there should be no problem. Look at what codepages the error reporters have on their systems and how changing to other codepage makes hplip working.

The bug exist only on machines which do not use UTF8 or raw ascii codepage/locales.
This happens because new cups can not accept anything except UTF8 (see cups changelog or read this bug report from the top). So before talking with cups API conversion from user codepage to UTF8 have to be done (just use my trick: LC_ALL=$LANG.UTF8 at the beginning execution of hplip tools to auto convert user codepage to UTF8 to make cups happy)

How to reproduce the bug on your system:
aaron@localhost ~ $ locale -a
pl_PL.iso88592 ----------------------------
pl_PL.iso8859-2 |
en_GB.iso885915 |
aaron@localhost ~ $ LC_ALL=pl_PL.iso88592 hp-toolbox
(hp-toolbox will run saying there is no printer)
locale -a may return different codepages available on your distro. If you will find any with name *.iso8859* use it as LC_ALL= to trigger on the bug.
If this will be not enough to trigger the bug try this:
export LANG=pl_PL.iso88592
and do it for all locale. When you finish locale should tell this:
aaron@localhost ~ $ locale

then run hp-toolbox and other HP tools.

If you will still have troubles by reproducing the error, post locale -a output.

Johannes Meixner (jsmeix) wrote :

Hello Aaron,

it does not happen on openSUSE 10.3 "out-of-the-box"
because this has a CUPS 1.2 version installed which
still accepts non-UTF-8.

To reproduce it on openSUSE 10.3, you must update
to CUPS 1.3, see my above comment where you can
download appropriate RPMs.

Additionally you must set a non-UTF-8 locale like
  export LC_ALL=en_GB.iso885915
  export LANG=en_GB.iso885915
and then run e.g. hp-toolbox from the termial window
where you have set the non-UTF-8 locale.

linuxuser63 (leon244) wrote :

Still a problem under hplip 2.8.4 and CUPS 1.3.6 in Mandriva 2008.1 and kernel
See Question # 31086

If possible please try CUPS 1.3.7 from cups.org.

There seems to be a cups problem with cups 1.3.0 to 1.3.6...


Johannes Meixner (jsmeix) wrote :

It does not work with CUPS 1.3.7 for us,
see for example

Does it work for you with CUPS 1.3.7?
If yes, I am very interested about the details
to learn why it works for you but not for me.

I don't find anything in the CUPS 1.3.7 CHANGES.txt file
which indicates that CUPS 1.3.7 is less strict regarding
which encodings it accepts so that from my point of view
it is still the same:
Since CUPS 1.3.4 all communication with the cupsd must
happen in any case only in UTF-8 encoding or 7-bit ASCII.

This means

- a client which talks to the cupsd must use UTF-8 encoding

- all strings which are sent to the cupsd must be in UTF-8
  in particular stuff like file names, queue names, job title,...

- all strings which the cupsd responds are in UTF-8
  in particular stuff like queue state messages,...

- all input files which are sent to the cupsd must be in UTF-8
  in particular files with MIME type text/plain

See also:
and follow the links therein.

Johannes Meixner (jsmeix) wrote :

I am no IPP protocol expert but I found the following
which might be perhaps of interest for you:

See RFC 2911 section 3.1.4
The "attributes-charset" attribute MUST be the first
attribute in the group and the "attributes-natural-language"
attribute MUST be the second attribute in the group.
In other words, these attributes MUST be supplied
in every IPP request
and sub-section
All clients and IPP objects MUST support the 'utf-8' charset
[RFC2279] and MAY support additional charsets provided that
they are registered with IANA [IANA-CS]. If the Printer object
does not support the client supplied charset value, the Printer
object MUST reject the request, set the "attributes-charset" to
'utf-8' in the response, and return the 'client-error-charset-
not-supported' status code

Here the client-error-charset-not-supported status code
is mentioned while the cupsd returns a client-error-bad-request
so that the above is perhaps not the exact right part of
the IPP specification but I hope it points at least into the
right direction.

Does HPLIP explicitely set the attributes-charset
to utf-8 in every IPP request?

By the way. see also my question

Johannes Meixner (jsmeix) wrote :

In the CUPS 1.3.7 sources scheduler/ipp.c
there is (starting at line 362):
if (charset &&
    strcasecmp(charset->values[0].string.text, "us-ascii") &&
    strcasecmp(charset->values[0].string.text, "utf-8"))
  send_ipp_status(con, IPP_BAD_REQUEST,
                  _("Unsupported character set \"%s\"!"),
I.e. you can either use the exact string "utf-8" or "us-ascii"
for the"attributes-charset" attribute in IPP requests.

Best read the cupsdProcessIPPRequest function
in scheduler/ipp.c completely to find out what exactly
the cups requires, tests, and accepts.

MaurizioB (mauriziob) wrote :

I can confirm this bug also: hp-toolbox runs with LC_ALL=POSIX LANG=POSIX hp-toolbox (not appending UTF8). Local printing actually works, but network (via samba) doesn't seem to; btw, this one could be my fault (hp-check reports problem with libnetsnmp).
Using Gentoo Linux, hplip 2.7.10, cups 1.3.7-r1, LC_ALL=it_IT@euro, charset 8859-15

Frederik Himpe (fhimpe) wrote :

The attached patch was created by Mandriva developer Tiago Salem Herrmann and forces UTF-8 communication with cups,no matter what the current user's locale is. See https://qa.mandriva.com/show_bug.cgi?id=35782

Michele D (mk71a) wrote :

I've tried the patch cited by Frederik Himpe, on a Debian Testing system. I've made some modification to the patch to make it working when some locale variables are missing or wrong.

Aclually it checks both LANG and LC_CTYPE, and more importantly does not fail if one of the is not set.
In this case C locale (with US-ASCII encoding) is used, mainly to make it working when the system has not utf-8 locales installed or the configuration is erroneous.

This patch will by applied in HPLIP 3.9.1 (upcoming release this month).

On Sun, Dec 28, 2008 at 1:50 PM, Michele D <email address hidden> wrote:

> I've tried the patch cited by Frederik Himpe, on a Debian Testing
> system. I've made some modification to the patch to make it working when
> some locale variables are missing or wrong.
> Aclually it checks both LANG and LC_CTYPE, and more importantly does not
> fail if one of the is not set.
> In this case C locale (with US-ASCII encoding) is used, mainly to make it
> working when the system has not utf-8 locales installed or the configuration
> is erroneous.
> ** Attachment added: "workaround-utf-8.diff"
> http://launchpadlibrarian.net/20783110/workaround-utf-8.diff
> --
> hplip 2.7.10 is not working with cups 1.3.4
> https://bugs.launchpad.net/bugs/162196
> You received this bug notification because you are a member of HP Linux
> Imaging and Printing, which is subscribed to HPLIP.

Fix released 3.9.2.


Changed in hplip:
assignee: nobody → kalosaurusrex
status: In Progress → Fix Released
David Levine (levinedl) wrote :

Fedora 11 fresh install.
hplip 3.9.2 that comes with Fedora 11. Also happens with hplip 3.9.6b.

My LC_CTYPE environment variable is set to en_US. hp-setup fails with the same symptoms (can't find .ppd file and "Printer queue setup failed. Please restart CUPS and try again.").

If I set my LC_CTYPE to C, hp-setup succeeds.

Could hp-setup be augmented to set the LC_CTYPE to C or some other safe value?

If not, how about adding a check for the value of LC_CTYPE to hp-check? I ran it and it did not report any problems.

---------- Forwarded Message ----------

Subject: [Pkg-hpijs-devel] Bug#458803: HPLIP 3.10.2-3 does not work on
Date: Tuesday 04 May 2010, 05:19:16
From: Stefan Seide <email address hidden>
To: <email address hidden>


i have HPLIP and HPLIP-GUI version 3.10.2-3 installed, my locale is


hp-systray does not see any printer installed. On startup of hp-systray i see
the following error messages in /var/log/cups/error_log:

E [03/May/2010:21:09:55 +0200] Unsupported character set "iso-8859-15"!
E [03/May/2010:21:09:55 +0200] Returning IPP client-error-bad-request for
CUPS-Get-Printers (no URI) from localhost

starting hp-systray with "LC_ALL=C /usr/bin/hp-systray" it works as expected
and the printer is seen.

Stefan Seide

The Land of the Free*
* Freedom sold separatly. Freedom not available in all regions.
Limited supply, will be sold to highest bidder.

Pkg-hpijs-devel mailing list
<email address hidden>


Changed in hplip (Debian):
status: Unknown → Confirmed
David Levine (levinedl) wrote :

The problem is still present with hplip 3.10.5.

Should hplip check the LC_CTYPE setting and change it (or unset it?) if necessary?

Should hp-check check the LC_CTYPE setting? It does not appear to.


Changed in hplip:
status: Fix Released → Confirmed
David Levine (levinedl) wrote :

Still present in hplip 3.10.9.

To replicate:
  $ LC_CTYPE=en_US hp-setup
Then hplip will not be able to find .ppd file (for Photosmart C7280, at least).

  $ LC_CTYPE=C hp-setup


emarkay (mrk) wrote :

Well, i's 4 years later - Today, I just found I can't install my PSC-1350 on my Dell Precision 90 with Lucid LTS.
Where are we on this?

David Levine (levinedl) wrote :

Does unsetting your LANG, LC_CTYPE, and LC_ALL environment variables allow the install to proceed?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.