hplip 2.7.10 is not working with cups 1.3.4

[Zbigniew Luszpinski]

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

[Aaron Albright (albrigha-deactivatedaccount)]

Thanks for the bug report.

What distro/version are you using?

A

[Zbigniew Luszpinski (zbiggy)]

What distro/version are you using?

Lunar Linux 1.6.0-i686 (Indium Antimonide - 20060323)
Kernel 2.6.22.10 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)]

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:
http://www.cups.org/articles.php?L508

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.

[Aaron Albright (albrigha-deactivatedaccount)]

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

A

[Zbigniew Luszpinski (zbiggy)]

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.

[Zbigniew Luszpinski (zbiggy)]

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"

evidence:
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:
LANG=pl_PL
LC_CTYPE="pl_PL"
LC_NUMERIC="pl_PL"
LC_TIME="pl_PL"
LC_COLLATE="pl_PL"
LC_MONETARY="pl_PL"
LC_MESSAGES="pl_PL"
LC_PAPER="pl_PL"
LC_NAME="pl_PL"
LC_ADDRESS="pl_PL"
LC_TELEPHONE="pl_PL"
LC_MEASUREMENT="pl_PL"
LC_IDENTIFICATION="pl_PL"
LC_ALL=pl_PL

[Zbigniew Luszpinski (zbiggy)]

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)]

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

LANG=da_DK
LC_CTYPE="da_DK"
LC_NUMERIC="da_DK"
LC_TIME="da_DK"
LC_COLLATE="da_DK"
LC_MONETARY="da_DK"
LC_MESSAGES="da_DK"
LC_PAPER="da_DK"
LC_NAME="da_DK"
LC_ADDRESS="da_DK"
LC_TELEPHONE="da_DK"
LC_MEASUREMENT="da_DK"
LC_IDENTIFICATION="da_DK"
LC_ALL=

[Zbigniew Luszpinski (zbiggy)]

Stefan,

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)]

Confirmed on slackware current with cups 1.3.5 and hplip 2.7.10

[Aaron Albright (albrigha-deactivatedaccount)]

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

Thanks.

A

[Johannes Meixner (jsmeix)]

It doesn't work at least for me using HPLIP 2.8.2 from
http://download.opensuse.org/repositories/home:/jsmeix/
on openSUSE 10.3 with CUPS 1.3.5 from
http://download.opensuse.org/repositories/Printing/

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
LC_ALL=POSIX LANG=POSIX hp-toolbox

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)]

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.

[Aaron Albright (albrigha-deactivatedaccount)]

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:

Slackware
Lunar
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!

Aaron

[Zbigniew Luszpinski (zbiggy)]

@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
C
pl_PL
pl_PL.iso88592 ----------------------------
pl_PL.iso8859-2 |
POSIX |
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
LANG=pl_PL.iso88592
LC_CTYPE="pl_PL.iso88592"
LC_NUMERIC="pl_PL.iso88592"
LC_TIME="pl_PL.iso88592"
LC_COLLATE="pl_PL.iso88592"
LC_MONETARY="pl_PL.iso88592"
LC_MESSAGES="pl_PL.iso88592"
LC_PAPER="pl_PL.iso88592"
LC_NAME="pl_PL.iso88592"
LC_ADDRESS="pl_PL.iso88592"
LC_TELEPHONE="pl_PL.iso88592"
LC_MEASUREMENT="pl_PL.iso88592"
LC_IDENTIFICATION="pl_PL.iso88592"
LC_ALL=pl_PL.iso88592

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)]

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)]

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

[Aaron Albright (albrigha-deactivatedaccount)]

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...

A

[Johannes Meixner (jsmeix)]

It does not work with CUPS 1.3.7 for us,
see for example
https://bugzilla.novell.com/show_bug.cgi?id=386853

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:
https://bugzilla.novell.com/show_bug.cgi?id=387130
and follow the links therein.

[Johannes Meixner (jsmeix)]

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 3.1.4.1
---------------------------------------------------
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
https://answers.launchpad.net/hplip/+question/35351

[Johannes Meixner (jsmeix)]

FYI:
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\"!"),
                  charset->values[0].string.text);
}
--------------------------------------------------------------------
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)]

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)]

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)]

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.

[dwelch91 (dwelch91)]

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.
>

[Aaron Albright (albrigha-deactivatedaccount)]

Fix released 3.9.2.

A

[David Levine (levinedl)]

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.

[Mark Purcell (msp)]

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

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

Hello,

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

LANG=de_DE@euro
LANGUAGE=
LC_CTYPE=de_DE@euro
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES=de_DE@euro
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=

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.

regards,
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>
http://lists.alioth.debian.org/mailman/listinfo/pkg-hpijs-devel

-----------------------------------------

[David Levine (levinedl)]

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.

Thanks.

[David Levine (levinedl)]

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).

Workaround:
  $ LC_CTYPE=C hp-setup

Thanks!

[David Levine (levinedl)]

See https://bugs.launchpad.net/hplip/+bug/678263

[emarkay (mrk)]

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)]

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