[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#600447: marked as done (Non UTF8/En locales bug reappeared (renders hplip useless for non US/UTF8 users))

Your message dated Mon, 10 Jan 2022 18:49:47 +0000
with message-id <10012022184805.6f88e9cc7544@desktop.copernicus.org.uk>
and subject line Re: Bug#435047: /usr/lib/hplip/base/g.py: assumes en_US.UTF-8 as default locale
has caused the Debian Bug report #435047,
regarding Non UTF8/En locales bug reappeared (renders hplip useless for non US/UTF8 users)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
435047: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435047
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: hplip
Version: 3.10.6-1
Severity: important
Tags: patch


In 3.10.6-1 there is still a serious issue with CUPS *requiring* either
an US-ASCII locale, or a UTF8 locale. As a consequence, all programs
communicating with CUPS to discuver printers/install printers, and the
like, fail miserably with errors of various kind, like hp-setup not
finding the printer (#515720), or not finding the proper PPD files, hp-clean
complaining that there is no printer, etc.

These extra errors *all* come from the inability of the hplip tools
to communicate properly with CUPS, because the locale forces an
encoding of the messages in a format that CUPS refuses to interpret.

According to what is said in #471228, CUPS is not going to change this
behaviour, so hplip needs to do either:

 * be patched to convert everything to UTF8 no matter what the user's 
   locale is, as done in hplip-2.8.12-force-utf8.patch submitted by 
   Tiago Salem Herrmann (ref: https://bugs.launchpad.net/bugs/162196)
   that was used in 3.9.2, but is gone in 3.10.6-1

 * or at least pop up a warning box if it detects a non UTF8 locale
   telling the user that it will not work with CUPS without an UTF8 locale
   (and saving the user, the Debian maintainers, and a lot of other
   people a sizeable amount of time)

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/bash

Versions of packages hplip depends on:
ii  adduser                       3.112      add and remove users and groups
ii  coreutils                     8.5-1      GNU core utilities
ii  cups                          1.4.4-3    Common UNIX Printing System(tm) - 
ii  cups-client                   1.4.4-3    Common UNIX Printing System(tm) - 
ii  hplip-cups                    3.10.6-1   HP Linux Printing and Imaging - CU
ii  hplip-data                    3.10.6-1   HP Linux Printing and Imaging - da
ii  libc6                         2.11.2-6   Embedded GNU C Library: Shared lib
ii  libcups2                      1.4.4-3    Common UNIX Printing System(tm) - 
ii  libdbus-1-3                   1.2.24-3   simple interprocess messaging syst
ii  libhpmud0                     3.10.6-1   HP Multi-Point Transport Driver (h
ii  libsane                       1.0.21-4   API library for scanners
ii  libsane-hpaio                 3.10.6-1   HP SANE backend for multi-function
ii  libssl0.9.8                   0.9.8o-2   SSL shared libraries
ii  lsb-base                      3.2-23.1   Linux Standard Base 3.2 init scrip
ii  policykit-1                   0.96-3     framework for managing administrat
ii  python                        2.6.5-13   interactive high-level object-orie
ii  python-dbus                   0.83.1-1   simple interprocess messaging syst
ii  python-imaging                1.1.7-2    Python Imaging Library
ii  python-pexpect                2.3-1      Python module for automating inter
ii  python-support                1.0.10     automated rebuilding support for P

Versions of packages hplip recommends:
ii  avahi-daemon                  0.6.25-1   Avahi mDNS/DNS-SD daemon
ii  sane-utils                    1.0.21-4   API library for scanners -- utilit

Versions of packages hplip suggests:
pn  hplip-doc        <none>                  (no description available)
ii  hplip-gui        3.10.6-1                HP Linux Printing and Imaging - GU
ii  kdeprint         4:3.5.9.dfsg.1-6+lenny1 print system for KDE
ii  python-notify    0.1.1-2+b2              Python bindings for libnotify

-- no debconf information

--- End Message ---
--- Begin Message --- 
On Sat 28 Jul 2007 at 13:54:22 -0700, root wrote:

> Package: hplip
> Version: 1.6.10-3
> Severity: normal
> File: /usr/lib/hplip/base/g.py
> 
> 
> When using hp-sendfax, I found these messages in the CUPS error log:
> 
>   D [] [Job 228] error: Unable to set locale.
>   D [] [Job 228] Traceback (most recent call last):
>   D [] [Job 228] File "/usr/lib/cups/backend/hpfax", line 60, in ?
>   D [] [Job 228] from base.g import *
>   D [] [Job 228] File "/usr/lib/hplip/base/g.py", line 136, in ?
>   D [] [Job 228] locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
>   D [] [Job 228] File "/usr/lib/python2.4/locale.py", line 381, in setlocale
>   D [] [Job 228] return _setlocale(category, locale)
>   D [] [Job 228] locale.Error: unsupported locale setting
>   E [] PID 9206 (/usr/lib/cups/backend/hpfax) stopped with status 1!
> 
> Because of this error, hp-sendfax will not work...
> 
> I solved the problem thusly:
> 
>   --- /usr/lib/hplip/base/g.py.org  2007-07-28 13:49:09.000000000 -0700
>   +++ /usr/lib/hplip/base/g.py      2007-07-28 13:49:45.000000000 -0700
>   @@ -133,7 +133,7 @@
>    except locale.Error:
>        # TODO: Is this the right thing to do?
>        log.error("Unable to set locale.")
>   -    locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
>   +    locale.setlocale(locale.LC_ALL, 'C')
> 
> Is it proper to assume the system has 'en_US.UTF-8'...?

Dear Debian User,                                                                                                   
                                                                                                                    
Use of our limited, volunteer supported resources is best served by not                                             
keeping open inactive bugs any longer than desirable, especially in                                                 
cases where the package concerned is older than the current stable                                                  
Debian version and upstream support has been limited. Consequently, the                                             
report is now being closed.                                                                                         
                                                                                                                    
Regards,                                                                                                            
                                                                                                                    
Brian.

--- End Message ---
Reply to: