Bug#1001440: /usr/bin/foo2zjs: fails to load firmware into printer
I'm not sure if it's the same issue, but I'm also seeing firmware failing to load on my LaserJet 1020 using foo2zjs. My guess is that there's a conflict between the firmware loading script and udev-configure-printer trying to access the printer at the same time. Here is a snippet from journalctl when the printer was turned on: May 11 18:02:34 cyclops kernel: usb 2-14: new high-speed USB device number 14 using xhci_hcd May 11 18:02:34 cyclops kernel: usb 2-14: New USB device found, idVendor=03f0, idProduct=2b17, bcdDevice= 1.00 May 11 18:02:34 cyclops kernel: usb 2-14: New USB device strings: Mfr=1, Product=2, SerialNumber=3 May 11 18:02:34 cyclops kernel: usb 2-14: Product: HP LaserJet 1020 May 11 18:02:34 cyclops kernel: usb 2-14: Manufacturer: Hewlett-Packard May 11 18:02:34 cyclops kernel: usb 2-14: SerialNumber: JL1K941 May 11 18:02:34 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 14 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 18:02:40 cyclops kernel: usblp1: removed May 11 18:02:40 cyclops /lib/udev/hplj1020[162068]: foo2zjs: loading HP LaserJet 1020 firmware /lib/firmware/hp/sihp1020.dl to CUPS USB device ... May 11 18:02:40 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 14 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 18:02:40 cyclops kernel: usblp1: removed May 11 18:02:40 cyclops systemd[1]: Started Configure Plugged-In Printer. May 11 18:02:40 cyclops udev-configure-printer[162071]: add usb-002-014 May 11 18:02:40 cyclops udev-configure-printer[162071]: device devpath is /devices/pci:00/:00:14.0/usb2/2-14 May 11 18:02:40 cyclops udev-configure-printer[162071]: Device vendor/product is 03F0:2B17 May 11 18:02:41 cyclops udev-configure-printer[162071]: failed to claim interface May 11 18:02:41 cyclops systemd[1]: configure-printer@usb-002-014.service: Main process exited, code=exited, status=1/FAILURE May 11 18:02:41 cyclops systemd[1]: configure-printer@usb-002-014.service: Failed with result 'exit-code'. And here's a snippet of the same scenario with a work-around in place: May 11 17:58:15 cyclops kernel: usb 2-14: new high-speed USB device number 13 using xhci_hcd May 11 17:58:15 cyclops kernel: usb 2-14: New USB device found, idVendor=03f0, idProduct=2b17, bcdDevice= 1.00 May 11 17:58:15 cyclops kernel: usb 2-14: New USB device strings: Mfr=1, Product=2, SerialNumber=3 May 11 17:58:15 cyclops kernel: usb 2-14: Product: HP LaserJet 1020 May 11 17:58:15 cyclops kernel: usb 2-14: Manufacturer: Hewlett-Packard May 11 17:58:15 cyclops kernel: usb 2-14: SerialNumber: JL1K941 May 11 17:58:15 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 17:58:21 cyclops kernel: usblp1: removed May 11 17:58:21 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 17:58:21 cyclops /lib/udev/hplj1020[161939]: foo2zjs: loading HP LaserJet 1020 firmware /lib/firmware/hp/sihp1020.dl to CUPS USB device ... May 11 17:58:21 cyclops kernel: usblp1: removed May 11 17:58:31 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 17:58:31 cyclops /lib/udev/hplj1020[161944]: foo2zjs: usb://HP/LaserJet%201020?serial=JL1K941... download successful. May 11 17:58:31 cyclops systemd[1]: Started Configure Plugged-In Printer. May 11 17:58:31 cyclops udev-configure-printer[161953]: add usb-002-013 May 11 17:58:31 cyclops udev-configure-printer[161953]: device devpath is /devices/pci:00/:00:14.0/usb2/2-14 May 11 17:58:31 cyclops udev-configure-printer[161953]: MFG:Hewlett-Packard MDL:HP LaserJet 1020 SERN:- serial:JL1K941 May 11 17:58:36 cyclops kernel: usblp1: removed May 11 17:58:36 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 17:58:37 cyclops kernel: usblp1: removed May 11 17:58:37 cyclops kernel: usblp 2-14:1.0: usblp1: USB Bidirectional printer dev 13 if 0 alt 0 proto 2 vid 0x03F0 pid 0x2B17 May 11 17:58:38 cyclops udev-configure-printer[161953]: URI contains USB serial number May 11 17:58:38 cyclops udev-configure-printer[161953]: URI match: usb://HP/LaserJet%201020?serial=JL1K941 May 11 17:58:38 cyclops udev-configure-printer[161953]: URI of detected printer: usb://HP/LaserJet%201020?serial=JL1K941, normalized: laserjet 1020 serial jl1k941 May 11 17:58:38 cyclops udev-configure-printer[161953]: URI of print queue: usb://HP/LaserJet%201020?serial=JL1K941, normalized: laserjet 1020 serial jl1k941 May 11 17:58:38 cyclops udev-configure-printer[161953]: Queue ipp://localhost/printers/HP_LaserJet_1020 has matching device URI May 11 17:58:38 cyclops udev-configure-printer[161953]: Re-enabled printer ipp://localhost/printers/HP_LaserJet_1020 May 11 17:58:38 cyclops systemd[1]:
Bug#594753: (no subject)
I've been investigating this since I discovered that Brasero won't burn valid data discs for me. I don't believe this is a burning problem at all, but an image generation problem. Brasero burns existing ISOs with no problems, but fails to create valid ISOs most of the time. This makes it easy to test, since there's no need to expend discs. Furthermore, I think the problem is a race condition, but I haven't been able to fully understand it. Console output clearly shows that there is a problem, however: brasero (libisofs)DEBUG : Skipping excluded file /home/kevin/test/Data Disc/Test File 01 brasero (libisofs)DEBUG : Skipping excluded file /home/kevin/test/Data Disc/Test File 02 brasero (libisofs)DEBUG : Creating low level ECMA-119 tree... brasero (libisofs)DEBUG : Matching hardlinks... brasero (libisofs)DEBUG : Sorting the low level tree... brasero (libisofs)DEBUG : Mangling names... brasero (libisofs)DEBUG : Creating low level Joliet tree... brasero (libisofs)DEBUG : Sorting the Joliet tree... brasero (libisofs)DEBUG : Mangling Joliet names... brasero (libisofs)DEBUG : Computing position of dir structure brasero (libisofs)DEBUG : Computing length of pathlist brasero (libisofs)DEBUG : Computing position of Joliet dir structure brasero (libisofs)DEBUG : Computing length of Joliet pathlist brasero (libisofs)DEBUG : Reader thread being cancelled brasero (libisofs)DEBUG : Starting image writing... brasero (libisofs)DEBUG : Write volume descriptors brasero (libisofs)DEBUG : Write Primary Volume Descriptor brasero (libisofs)DEBUG : Write SVD for Joliet brasero (libisofs)DEBUG : Writing ISO Path tables brasero (libisofs)DEBUG : Writing Joliet Path tables brasero (libisofs)DEBUG : Writing Files... brasero (libisofs)DEBUG : Processed 558 of 11158 KB (5 %) brasero (libisofs)DEBUG : Processed 1116 of 11158 KB (10 %) brasero (libisofs)DEBUG : Processed 1674 of 11158 KB (15 %) brasero (libisofs)MISHAP : Image write cancelled brasero (libisofs)DEBUG : Writer thread joined brasero (libisofs)DEBUG : Reader thread being cancelled brasero (libisofs)DEBUG : Writer thread joined Skipping excluded file looks suspicious, but I don't believe it's actually a problem. I'm not sure why, but Brasero seems to set most files as excluded in the libisofs image object, then add them individually. The first real sign of trouble is Reader thread being cancelled. For comparison, a run where it succeeded: brasero (libisofs)DEBUG : Skipping excluded file /home/kevin/test/Data Disc/Test File 01 brasero (libisofs)DEBUG : Skipping excluded file /home/kevin/test/Data Disc/Test File 02 brasero (libisofs)DEBUG : Creating low level ECMA-119 tree... brasero (libisofs)DEBUG : Matching hardlinks... brasero (libisofs)DEBUG : Sorting the low level tree... brasero (libisofs)DEBUG : Mangling names... brasero (libisofs)DEBUG : Creating low level Joliet tree... brasero (libisofs)DEBUG : Sorting the Joliet tree... brasero (libisofs)DEBUG : Mangling Joliet names... brasero (libisofs)DEBUG : Computing position of dir structure brasero (libisofs)DEBUG : Computing length of pathlist brasero (libisofs)DEBUG : Computing position of Joliet dir structure brasero (libisofs)DEBUG : Computing length of Joliet pathlist brasero (libisofs)DEBUG : Starting image writing... brasero (libisofs)DEBUG : Write volume descriptors brasero (libisofs)DEBUG : Write Primary Volume Descriptor brasero (libisofs)DEBUG : Write SVD for Joliet brasero (libisofs)DEBUG : Writing ISO Path tables brasero (libisofs)DEBUG : Writing Joliet Path tables brasero (libisofs)DEBUG : Writing Files... brasero (libisofs)DEBUG : Processed 558 of 11158 KB (5 %) brasero (libisofs)DEBUG : Processed 1116 of 11158 KB (10 %) brasero (libisofs)DEBUG : Processed 1674 of 11158 KB (15 %) brasero (libisofs)DEBUG : Processed 2232 of 11158 KB (20 %) brasero (libisofs)DEBUG : Processed 2790 of 11158 KB (25 %) brasero (libisofs)DEBUG : Processed 3348 of 11158 KB (30 %) brasero (libisofs)DEBUG : Processed 3906 of 11158 KB (35 %) brasero (libisofs)DEBUG : Processed 4464 of 11158 KB (40 %) brasero (libisofs)DEBUG : Processed 5022 of 11158 KB (45 %) brasero (libisofs)DEBUG : Processed 5580 of 11158 KB (50 %) brasero (libisofs)DEBUG : Processed 6138 of 11158 KB (55 %) brasero (libisofs)DEBUG : Processed 6696 of 11158 KB (60 %) brasero (libisofs)DEBUG : Processed 7254 of 11158 KB (65 %) brasero (libisofs)DEBUG : Processed 7812 of 11158 KB (70 %) brasero (libisofs)DEBUG : Processed 8370 of 11158 KB (75 %) brasero (libisofs)DEBUG : Processed 8928 of 11158 KB (80 %) brasero (libisofs)DEBUG : Processed 9486 of 11158 KB (85 %) brasero (libisofs)DEBUG : Processed 10044 of 11158 KB (90 %) brasero (libisofs)DEBUG : Processed 10602 of 11158 KB (95 %) brasero (libisofs)DEBUG : Processed 11158 of 11158 KB (100 %) brasero (libisofs)DEBUG : Writer thread joined This is with brasero 2.30.3-2 on Squeeze. There seem to be some indications that the failure is more likely to happen with more data, or with more files. I tested with a
Bug#649562: acpi-support: Fails to lock screen
Package: acpi-support Version: 0.138-9 Severity: important Dear Maintainer, I have encountered two problems with the built-in screen locking functionality: 1) /usr/share/acpi-support/screenblank invokes su with $user as the username. Presumably this was supposed to use the variable set by getXuser, but that function exports $XUSER, not $user. Note that this mistake occurs several times in the file. 2) In my case, getXuser set $XAUTHORITY to the wrong value. It seems to get this value by searching /proc/$pid/environ and taking the first $XAUTHORITY it finds. In my case, it found an mpd process that had been started in an earlier session. The XAUTHORITY value was no longer valid. This may seem like a fluke, but it looks like older processes (or at least lower PIDs) are checked first, making this somewhat likely if the user happens to have processes from an older session. Perhaps the ps call in getXuser could be modified to sort newest processes first. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages acpi-support depends on: ii acpi-fakekey 0.138-9 ii acpi-support-base 0.138-9 ii acpid 1:2.0.12-1 ii lsb-base 3.2-28 ii pm-utils 1.4.1-8 ii x11-xserver-utils 7.6+3 Versions of packages acpi-support recommends: ii dbus 1.4.16-1 ii gnome-screensaver 3.0.1-3 ii radeontool none ii vbetool1.1-2 ii xscreensaver 5.15-2 Versions of packages acpi-support suggests: ii rfkill 0.4-1 ii xinput 1.5.3-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595046: sulogin: Check for locked root password is wrong
Package: sysvinit-utils Version: 2.88dsf-12 Severity: normal sysvinit includes a patch, 91_sulogin_lockedpw.dpatch, which is intended to make sulogin skip asking for the root password when the root password is locked (via passwd -l). This patch was taken from Ubuntu, where the root password is locked by default. However the patch does not work correctly if the root password was ever set, meaning it is sometimes broken in Ubuntu and pretty much always broken in Debian. It relies on the encrypted password being exactly !, but locking a password only prepends ! to the existing encrypted password, it does not replace it. The Ubuntu bug is: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/268271 The Debian bug that included the patch is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326678 It looks like it should be rather easy to replace, e.g.: strcmp(pwd.pw_passwd, !) == 0 with pwd.pw_passwd[0] == '!' Though perhaps a more general check for invalid passwords is warranted. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sysvinit-utils depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1 SELinux runtime shared libraries sysvinit-utils recommends no packages. Versions of packages sysvinit-utils suggests: pn sash none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584947: pinentry-gtk2: Segmentation fault
Package: pinentry-gtk2
Version: 0.8.0-1
Severity: normal
Tags: upstream patch
Steps to reproduce:
1. At a terminal, enter:
$ echo GETPIN | pinentry-gtk-2
2. In the pinentry window, click the mimimize button.
Result:
The window disappears and Segmentation fault is printed in the terminal.
pinentry-gtk-2 also crashes on startup for me when maximus is running,
making it unusable. (maximus maximizes all windows and removes the window
decorations. I use it on a netbook with limited screen real estate.)
Here is a patch adapted from:
http://osdir.com/ml/general/2010-04/msg23999.html
--- pinentry-0.8.0.orig/gtk+-2/pinentry-gtk-2.c
+++ pinentry-0.8.0/gtk+-2/pinentry-gtk-2.c
@@ -145,7 +145,8 @@ ungrab_keyboard (GtkWidget *win, GdkEven
{
gdk_keyboard_ungrab (gdk_event_get_time (event));
/* Unmake window transient for the root window. */
- gdk_window_set_transient_for (win-window, NULL);
+ gdk_property_delete (win-window,
+gdk_atom_intern_static_string (WM_TRANSIENT_FOR));
}
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pinentry-gtk2 depends on:
ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
ii libglib2.0-0 2.24.1-1 The GLib library of C routines
ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface
ii libncurses5 5.7+20100313-2 shared libraries for terminal hand
ii libpango1.0-0 1.28.0-1 Layout and rendering of internatio
pinentry-gtk2 recommends no packages.
Versions of packages pinentry-gtk2 suggests:
pn pinentry-doc none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584969: libatasmart4: Reports healthy disks as failing
Package: libatasmart4
Version: 0.17+git20100219-1
Severity: important
Tags: upstream patch
libatasmart incorrectly interprets SMART data in a way that causes it to
report healthy hard drives as failing. There are at least two specific
problems centering on reallocated sectors.
First problem:
It assumes that the raw value is exactly equal to the number of
reallocated sectors. According to the man page from smartctl:
The conversion from Raw value to a quantity with physical units is not
specified by the SMART standard. In most cases, the values printed by
smartctl are sensible. For example the temperature Attribute generally
has its raw value equal to the temperature in Celsius. However in some
cases vendors use unusual conventions. For example the Hitachi disk on
my laptop reports its power-on hours in minutes, not hours. Some IBM
disks track three temperatures rather than one, in their raw values.
And so on.
Examples can be found of drives that report a raw value that is almost
certainly not the real number of reallocated sectors. Some solid state
drives like the Samsung MCCOE64GEMPP have a raw value of over 2 million
out of the box. The Hitachi HTS541010G9SA00 seems to have similarly
large raw values.
Second problem:
It uses arbitrarily selected thresholds for reallocated sectors to
determine that a drive is at risk, even when the SMART data clearly
indicates that the threshold selected by the manufacturer is far from
being reached.
There are two of these arbitrary thresholds. First, if the apparent
number of reallocated sectors exceeds log2 of the disk size, it reports
it as failing with many bad sectors. Second, if the apparent number of
reallocated sectors or pending reallocations is greater than 0, it
reports the disk as failing with bad sectors. Keep in mind that this
number of reallocated sectors may be no such thing.
This problem becomes particularly apparent when gnome-disk-utility
begins showing alarming pop-up warnings at every login. The issue has
been reported several times in different distributions. Here are some
examples:
https://bugzilla.redhat.com/show_bug.cgi?id=498115
https://bugzilla.redhat.com/show_bug.cgi?id=500079
https://bugzilla.redhat.com/show_bug.cgi?id=506254
https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/438136
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/477280
http://bugs.freedesktop.org/show_bug.cgi?id=25772
Additionally, the upstream author seems reluctant to address this
problem, so I suggest a patch in Debian to address it in the meantime.
The author's response can be seen in the freedesktop.org bug above.
I'm attaching a proposed patch. It removes warnings in skdump for when
the raw value of reallocated-sector-count or current-pending-sector is
greater than 0, prevents the BAD_SECTOR_MANY and BAD_SECTOR overall
status flags from being used, and removes some stuff that becomes unused
with the other changes. Note that suppressing BAD_SECTOR and
BAD_SECTOR_MANY only prevents the arbitrary warnings. Actual SMART
failures are still reported.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libatasmart4 depends on:
ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
ii libudev0 154-1 libudev shared library
libatasmart4 recommends no packages.
libatasmart4 suggests no packages.
-- no debconf information
diff -u -r libatasmart-0.17+git20100219.orig//atasmart.c libatasmart-0.17+git20100219/atasmart.c
--- libatasmart-0.17+git20100219.orig//atasmart.c 2010-06-06 12:07:45.0 -0700
+++ libatasmart-0.17+git20100219/atasmart.c 2010-06-07 15:18:29.0 -0700
@@ -1265,11 +1265,6 @@
if (max_sectors 0 a-pretty_value max_sectors) {
a-pretty_value = SK_SMART_ATTRIBUTE_UNIT_UNKNOWN;
d-attribute_verification_bad = TRUE;
-} else {
-if ((!strcmp(a-name, reallocated-sector-count) ||
- !strcmp(a-name, current-pending-sector))
-a-pretty_value 0)
-a-warn = TRUE;
}
}
@@ -2106,6 +2101,7 @@
*good = FALSE;
}
+#if 0
static uint64_t u64log2(uint64_t n) {
unsigned r;
@@ -2120,10 +2116,13 @@
r++;
}
}
+#endif
int sk_disk_smart_get_overall(SkDisk *d, SkSmartOverall *overall) {
SkBool good;
+#if 0
uint64_t sectors, sector_threshold;
+#endif
assert(d);
assert(overall);
@@ -2137,6 +2136,7 @@
return 0;
}
+#if 0
/* Second, check if the number of bad sectors is greater than
* a certain threshold */
if
Bug#552506: gnome-power-manager: xset dpms force off don't keep display off
When you’re using a power management application, don’t complain if it tries to manage power. If you stomp on what it is doing using lower-level interfaces, you can’t obtain correct results. g-p-m has a D-Bus interface that allows to force a display to be shut down, you should use this interface instead. This is a very sensible reply, however it seems to be incorrect. I may be mistaken, but after much hunting I have been unable to find such an interface. If it does exist please provide details and ideally a working example using dbus-send (that would be great because it would provide a drop-in replacement for the xset command). Unless this interface exists and I simply failed to locate it, it appears gnome-power-manager has made the only existing option non-functional. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
