Bug#883182: libsane-hpaio: SCL scan resolutions list too restrictive
I have reported this upstream as suggested by Brian. See https://bugs.launchpad.net/hplip/+bug/1784118
Bug#590895: sysvinit: shutdown -hP sets INIT_HALT to POWERDOWN not POWEROFF
I see that bugs.debian.org says this bug is "No longer marked as found in versions sysvinit/2.86.ds1-61." However, the bug is still present in sysvinit 2.88 as can be seen from: https://sources.debian.org/src/sysvinit/2.88dsf-59.10/src/shutdown.c/#L518 case 'P': halttype = "POWERDOWN"; and: https://sources.debian.org/src/sysvinit/2.88dsf-59.10/man/shutdown.8/#L174 \fIINIT_HALT\fP to \fIHALT\fP, and the \fB-P\fP option just sets that variable to \fIPOWEROFF\fP. The shutdown script that calls I believe the severity of this bug should be increased, as it can cause loss of service when a UPS is involved. This is because if UPS software is configured to execute "shutdown -hP now" when the battery level becomes critically low, /etc/init.d/halt powers off the system without invoking "/etc/init.d/ups-monitor poweroff" to tell the UPS to kill the power. If A/C power is restored before the UPS turns itself off (which is likely, as the UPS now has no load) the system does not get restarted and has to be powered up manually. Of course the simple work-around for this problem is to configure "shutdown -h now" instead of "shutdown -hP now", but fixing the bug in shutdown.c would prevent it happening to admins who are not (yet) aware of it and who are misled by the man page into thinking that specifying -P would be prudent to ensure poweroff. Please change: halttype = "POWERDOWN"; to: halttype = "POWEROFF"; ASAP.
Bug#883182: libsane-hpaio: SCL scan resolutions list too restrictive
Package: libsane-hpaio Version: 3.14.6-1+deb8u1 Severity: normal Dear Maintainer, Somewhere between 3.10 and 3.14 the supported resolutions for SCL scanners changed from a range to a list. This manifests in xsane as a change from a text box where you can enter any resolution you want to a drop-down list of resolutions to choose from. To me this change is an unacceptable loss of functionality. (I'll explain why at the end). I found that I could reinstate the old functionality by commenting out one line in the SetResolutionListSCL() function in scan/sane/scl-pml.c: hpaio->option[OPTION_SCAN_RESOLUTION].constraint_type = SANE_CONSTRAINT_WORD_LIST; Please consider making one of the following changes: 1. Comment out that line (or make an equivalent change). This is the simplest option, but I suppose is unlikely to be accepted upstream and so would need to be maintained indefinitely as a debian patch. 2. Provide a configuration option (in /etc/hp/hplip.conf?) so that it is possible to choose between a resolution range and a list. 3. Provide a configuration option to override the default list of supported resolutions, which is hard-coded in SetResolutionListSCL(). 4. Change the list of supported resolutions in SetResolutionListSCL() so that it has a few new ones in between the existing ones. E.g. instead of: ... 300, 600, 1200, 2400, ... it has: ... 300, 400, 500, 600, 700, 800, 900, 1000, 1200, 1400, 1600, 1800, 2000, 2400, ... These options are in decreasing order of preference for me, but your preference may differ (as may upstream's). As to why the new SCL resolution list is an unacceptable loss of functionality for me, it's because I like to scan 6x4 photos at 800 dpi. I could achieve the same result by scanning at 1200 and then scaling the photo afterwards, but this is not an acceptable solution because my scanner behaves completely differently at 1200 dpi. Instead of scanning quite quickly in one continuous motion like it does at 800, at 1200 it scans extremely slowly with many back-and-forth motions that drive me nuts. I'm sure there must be many other Debian users with HP SCL scanners who would prefer that the list of resolutions was not so restrictive. -- System Information: Debian Release: 8.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libsane-hpaio depends on: ii libc62.19-18+deb8u10 ii libcups2 1.7.5-11+deb8u1 ii libdbus-1-3 1.8.22-0+deb8u1 ii libhpmud03.14.6-1+deb8u1 ii libssl1.0.0 1.0.1t-1+deb8u7 Versions of packages libsane-hpaio recommends: ii hplip 3.14.6-1+deb8u1 ii sane-utils 1.0.24-8+deb8u2 libsane-hpaio suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/sane/libsane-hpaio.so.1.0.0 (from libsane-hpaio package) ** This is because I have replaced it with the "fixed" one I built.
Bug#548744: mksh: exit status of non-interactive file-not-found
Thorsten Glaser t...@mirbsd.de wrote, on 28 Sep 2009: Clint Adams dixit: % mksh /tmp/horsies ; echo $? /tmp/horsies: /tmp/horsies: No such file or directory 1 t...@herc:~ $ mksh /tmp/horsies; print $? /tmp/horsies: /tmp/horsies: No such file or directory 1 t...@herc:~ $ mksh -c /tmp/horsies; print $? mksh: /tmp/horsies: not found 127 According to SUSv3, the exit code should be 127: 127 A specified command_file could not be found by a non-interactive shell. I tend to disagree. While GNU bash, ATT ksh93 and zsh do the same thing for both, neither does dash, nor can I find (quickly) something in SUSv3 which says anything about the return code when the input file (as stdin replacement) cannot be opened. The case you bring forward is *not* a command_file. Geoff, can you shed some light on this? Clint is right. Look at the synopsis for sh: sh [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]... [command_file [argument...]] sh -c [-abCefhimnuvx] [-o option]... [+abCefhimnuvx] [+o option]... command_string [command_name [argument...]] In the command sh /tmp/horsies the /tmp/horsies argument is a command_file operand. In the command sh -c /tmp/horsies the /tmp/horsies argument is a command_string operand. So the 127 exit is required for sh /tmp/horsies if /tmp/horsies could not be found. (127 is also required for sh -c /tmp/horsies, but for a different reason.) Is there, by chance, an eMail address (mailing list, maybe) where people can ask such questions on SUSv3 and shell behaviour? The Austin Group mailing list is open to anyone to join. See www.opengroup.org/austin/lists.html David Korn and Chet Ramey are both subscribers, and sometimes contribute to shell-related discussions. By the way, the base specifications (XBD, XSH, XCU, XRAT) of SUSv3 were superseded by the SUSv4 equivalents about a year ago. You can access the HTML version of the new specifications via www.opengroup.org/bookstore/catalog/c082.htm If you join the Austin Group mailing list you can also get access to the PDF version. Regards, Geoff. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496718: vpnc: Disconnects after an hour and loops trying to reconnect
After upgrading to lenny, I have the same problem. Looks like it is a rekeying problem. Previously I was running a backport of 0.5.1r275-1 on etch, and this did not have the problem. I still had that .deb so I downgraded vpnc by installing it with dpkg, and the problem has gone away. This narrows down the breakage to sometime after r275. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509571: gcc-4.3: stddef.h sometimes does not define ptrdiff_t
Package: gcc-4.3 Version: 4.3.2-1 Severity: important File: /usr/lib/gcc/i486-linux-gnu/4.3/include/stddef.h When certain combinations of headers precede stddef.h, ptrdiff_t does not get defined. The particular sequence that triggered it for me was wchar.h, wctype.h, stddef.h but that might not be the only one. $ cat tmp1.c #includewchar.h #includewctype.h #includestddef.h ptrdiff_t x = 1; $ gcc -c tmp1.c tmp1.c:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'x' The problem doesn't happen if wchar.h and wctype.h are the other way round. $ cat tmp2.c #includewctype.h #includewchar.h #includestddef.h ptrdiff_t x = 1; $ gcc -c tmp2.c $ -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.3 depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii cpp-4.3 4.3.2-1 The GNU C preprocessor ii gcc-4.3-base4.3.2-1 The GNU Compiler Collection (base ii libc6 2.7-16 GNU C Library: Shared libraries ii libgcc1 1:4.3.2-1GCC support library ii libgomp14.3.2-1 GCC OpenMP (GOMP) support library Versions of packages gcc-4.3 recommends: ii libc6-dev 2.7-16 GNU C Library: Development Librari Versions of packages gcc-4.3 suggests: pn gcc-4.3-doc none (no description available) pn gcc-4.3-locales none (no description available) pn gcc-4.3-multilib none (no description available) pn libgcc1-dbg none (no description available) pn libgomp1-dbg none (no description available) pn libmudflap0-4.3-dev none (no description available) pn libmudflap0-dbg 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
