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

Bug#458803: marked as done (hplip: hp-{toolbox,sendfax,setup} no longer work)



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 hplip: hp-{toolbox,sendfax,setup} no longer work
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: 2.7.10-5
Severity: important


When first tested a few weeks back, 2.7.10-5 worked fine. A few
"aptitude dist-upgrade" runs later, it has stopped working. Oddly
enough, the CUPS back end still works fine: I can print to the printer,
but I can't use any of the hplip tools to configure or manage the
printer.

The printer is connected by wifi, is accessible to hp-makeuri, and can
be pinged from the host. So, connectivity doesn't seem to be the issue,
and the configuration has been tested with all firewall rules turned
off just to ensure a clean test.

Attempting to use hp-setup fails, even when it can identify the printer.
It claims it can't read the PPD files, even when they're manually
assigned, and doesn't seem to see the existing CUPS configuration when
it exists.

Also, if it's important, hpssd is running, although it doesn't seem to
be starting from anything in /etc/init.d, so I'm not sure *how* it's
getting launched. It comes up after every reboot, though, so that seems
to be reliable.

In short, I'm at a complete loss as to why it suddenly stopped working.
The only saving grace is that paper (not fax) printing remains viable,
which keeps the bug from making the whole package unusable.

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

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages hplip depends on:
ii  adduser             3.105                add and remove users and groups
ii  coreutils           5.97-5.3             The GNU core utilities
ii  cupsys              1.3.4-4              Common UNIX Printing System(tm) - 
ii  hplip-data          2.7.10-5             HP Linux Printing and Imaging - da
ii  libc6               2.7-5                GNU C Library: Shared libraries
ii  libcupsys2          1.3.4-4              Common UNIX Printing System(tm) - 
ii  libjpeg62           6b-14                The Independent JPEG Group's JPEG 
ii  libsane             1.0.19~cvs20071213-1 API library for scanners
ii  libsnmp15           5.4.1~dfsg-4         SNMP (Simple Network Management Pr
ii  libssl0.9.8         0.9.8g-3             SSL shared libraries
ii  libusb-0.1-4        2:0.1.12-8           userspace USB programming library
ii  lsb-base            3.1-24               Linux Standard Base 3.1 init scrip
ii  python              2.4.4-6              An interactive high-level object-o
ii  python-support      0.7.5                automated rebuilding support for p

Versions of packages hplip recommends:
ii  cupsys-client            1.3.4-4         Common UNIX Printing System(tm) - 
ii  hpijs                    2.7.10+2.7.10-5 HP Linux Printing and Imaging - gs
ii  hpijs-ppds               2.7.10+2.7.10-5 HP Linux Printing and Imaging - HP
ii  hplip-gui                2.7.10-5        HP Linux Printing and Imaging - GU
pn  openprinting-ppds        <none>          (no description available)
ii  python-reportlab         2.0dfsg-1       ReportLab library to create PDF do

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