Bug#955215: keyboard-configuration: fails to set correct keyboard layout
Hi, I'm currently on the same page (Ubuntu 20.04.1 fails to activate keyboard state after dpkg-reconfigure keyboard-configuration, and - USABILITY! - keyboard-configuration does not even mention that such a manual state change trigger might be required! *)), thus replying here. > sudo service keyboard-setup restart > >* What was the outcome of this action? > > Nothing at all : no change of layout Did you actually also do what Debian Wiki (currently!?) additionally lists?: | To apply new settings, restarting the keyboard-setup service should suffice, otherwise you can try to restart kernel input system via udev: | | udevadm trigger --subsystem-match=input --action=change Case in point: sudo service keyboard-setup restart didn't work for me, whereas udevadm trigger --subsystem-match=input --action=change as executed subsequently then did successfully update keyboard state in-place, within an xfce4 session. *) dpkg-reconfigure keyboard-configuration logging: # dpkg-reconfigure keyboard-configuration Your console font configuration will be updated the next time your system boots. If you want to update it now, run 'setupcon' from a virtual console. update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools (0.136ubuntu6.2) ... update-initramfs: Generating /boot/initrd.img-4.9.230-35 # (at least it does mention some setupcon aspects, but it fails to mention that keyboard layout state may fail to be updated immediately, as detailed by Debian Wiki) I am about to file an Ubuntu launchpad bug on this annoying usability omission. HTH, Andreas Mohr
Bug#839785: am-utils: broken shutdown: amq -p causes abort, results in complete hang due to stale /net mount
Package: am-utils
Version: 6.2+rc20110530-3.2
Severity: critical
Justification: makes unrelated software on the system break (unrelated
processes hanging)
Hello,
I installed am-utils package today,
and then uninstalled it.
Was pretty astonished to find that
after package uninstall
unrelated processes started hanging (df etc.).
[the usual very annoying symptoms of stale mounts]
Thus figured out rather quickly that there was a stale mount left, despite
am-utils stop having been initiated by package uninstall already:
andi:(pid4532,port1022) on /net type nfs
(rw,relatime,sync,vers=2,rsize=1024,wsize=1024,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,nolock,proto=udp,port=1022,timeo=7,retrans=3,sec=sys,local_lock=all,addr=127.0.0.1)
# sh -x /etc/init.d/am-utils stop
+ PATH=/usr/sbin:/sbin:/usr/bin:/bin
+ export PATH
+ CONF=/etc/default/am-utils
+ test -x /usr/sbin/amd
+ stop_amd
+ amq -p
+ pid=
+ [ -z ]
+ echo Stopping automounter: amd not running
Stopping automounter: amd not running
+ [ 0 -eq 0 ]
+ exit 0
[subsequent shutdown handling is thus completely and fully out-maneuvered]
I realized that in fact amd was not running any more at this point.
So, I re-start:ed the service.
At this point, manually doing
# strace -f amq -p
will show:
stat64("/usr/lib/cmov", 0xbfb262d0) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libnss_db.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=86016, ...}) = 0
munmap(0xb771b000, 163182) = 0
open("/etc/protocols", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2932, ...}) = 0
read(3, "# Internet (IP) protocols\n#\n# Up"..., 1024) = 1024
close(3)= 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
gettimeofday({1475612569, 410100}, NULL) = 0
futex(0xb7678180, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xb76782e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(3,
"\200\0\0008Y\304\273\254\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0\0\0\0"...,
60) = 60
poll([{fd=3, events=POLLIN}], 1, 6) = 1 ([{fd=3, revents=POLLIN}])
read(3,
"\200\0\0\34Y\304\273\254\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\371",
400) = 32
close(3)= 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
open("/etc/bindresvport.blacklist", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=367, ...}) = 0
read(4, "#\n# This file contains a list of"..., 1024) = 367
read(4, "", 1024) = 0
close(4)= 0
bind(3, {sa_family=AF_INET, sin_port=htons(604),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1017),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
write(3,
"\200\0\0(m.M]\0\0\0\0\0\0\0\2\0\4\223\363\0\0\0\1\0\0\0\t\0\0\0\0"...,
44) = 44
poll([{fd=3, events=POLLIN}], 1, 4) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 4000) = 0
write(2, "amq: failed to get PID of amd\n", 30amq: failed to get PID of
amd
) = 30
exit_group(1) = ?
+++ exited with 1 +++
Having attached to a running amd process right before that amq invocation
this will then have resulted in the following report there:
# strace -f -p 4657
strace: Process 4657 attached
_newselect(1024, [3 4 5 6], NULL, NULL, {282, 847391}) = 1 (in [5], left
{281, 93032})
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM CHLD], NULL, 8) = 0
gettimeofday({1475612569, 412383}, NULL) = 0
accept(5, {sa_family=AF_INET, sin_port=htons(604),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
dup(0) = 8
close(8)= 0
gettimeofday({1475612569, 412959}, NULL) = 0
gettimeofday({1475612569, 413030}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
_newselect(1024, [3 4 5 6 7], NULL, NULL, {281, 0}) = 1 (in [7], left
{280, 999649})
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM CHLD], NULL, 8) = 0
gettimeofday({1475612569, 413806}, NULL) = 0
poll([{fd=7, events=POLLIN}], 1, 35000) = 1 ([{fd=7, revents=POLLIN}])
read(7,
"\200\0\0(m.M]\0\0\0\0\0\0\0\2\0\4\223\363\0\0\0\1\0\0\0\t\0\0\0\0"...,
16384) = 44
open("/etc/hosts.allow", O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=707, ...}) = 0
read(8, "# /etc/hosts.allow: list of host"..., 1024) = 707
read(8, "", 1024) = 0
close(8)= 0
open("/etc/hosts.deny", O_RDONLY) = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=858, ...}) = 0
read(8, "# /etc/hosts.deny: list of hosts"..., 1024) = 858
close(8)= 0
time([1475612569]) = 1475612569
socket(AF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
connect(8, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT
(No suc
Bug#832654: debian-policy: 3.5 Dependencies possibly not detailed enough (about versioning etc.)
Package: debian-policy Version: 3.9.8.0 Severity: wishlist Hello, I just filed #832650 (insufficient Depends of systemd 230-7), and also had several similar package issues reported in earlier times. I just realized that debian-policy section "3.5 Dependencies" perhaps is insufficiently worded: It does not mention e.g. "versioning" of a dependency (this may be intentional after all, since this section may want to be a more general, short/concise statement that dependencies simply need to be "correct", regardless of whether this then applies to specific dependency information stuff such as version values, etc.). One additional aspect here (which may also need mentioning via explaining) is the question of whether (or: how strongly) reliability of these dependency requirements also apply to the use case of inter-distro-version upgrading (i.e., upgrading from a rather old distro base). A key phrase which may be missing from that section (especially near "Every package must specify the dependency information") is "require a sufficiently fully qualified dependency", to "always guarantee successful operation of the depender after installation or upgrades". Worded differently, perhaps a good form is "require dependencies stated in sufficiently fully precisely qualified information form (package name, version level, etc.), to achieve always guaranteeing successful operation of the depender after whichever installation or upgrade occurs". [or "after any installation or upgrade"] Policy demands here ought to be clarified a bit I believe (without this section then ending up overly verbose, of course), in order to achieve maximally precisely stating what is or is not the requirement that package maintenance efforts are expected to meet. Thanks, Andreas Mohr
Bug#832650: systemd 230-7: boot fail panic abort due to wrong (outdated) Depends on libseccomp2, libidn11
:36:48 startup archives unpack 2016-07-28 07:36:54 upgrade libidn11:i386 1.32-3 1.32-3.1 2016-07-28 07:36:54 status triggers-pending libc-bin:i386 2.23-2 2016-07-28 07:36:55 status half-configured libidn11:i386 1.32-3 2016-07-28 07:36:55 status unpacked libidn11:i386 1.32-3 2016-07-28 07:36:55 status half-installed libidn11:i386 1.32-3 2016-07-28 07:36:55 status half-installed libidn11:i386 1.32-3 2016-07-28 07:36:55 status unpacked libidn11:i386 1.32-3.1 2016-07-28 07:36:55 status unpacked libidn11:i386 1.32-3.1 2016-07-28 07:36:55 trigproc libc-bin:i386 2.23-2 2016-07-28 07:36:55 status half-configured libc-bin:i386 2.23-2 2016-07-28 07:36:57 status installed libc-bin:i386 2.23-2 2016-07-28 07:36:58 startup packages configure 2016-07-28 07:36:58 configure libidn11:i386 1.32-3.1 2016-07-28 07:36:58 status triggers-pending libc-bin:i386 2.23-2 2016-07-28 07:36:58 status unpacked libidn11:i386 1.32-3.1 2016-07-28 07:36:58 status half-configured libidn11:i386 1.32-3.1 2016-07-28 07:36:58 status installed libidn11:i386 1.32-3.1 2016-07-28 07:36:58 trigproc libc-bin:i386 2.23-2 2016-07-28 07:36:58 status half-configured libc-bin:i386 2.23-2 2016-07-28 07:36:58 status installed libc-bin:i386 2.23-2 Thanks, Andreas Mohr
Bug#826703: gvfs-common: Trying to overwrite gvfs.mo which is also in package gvfs
tree Reading state information... Done Correcting dependencies... Done The following additional packages will be installed: gvfs-common gvfs-daemons The following NEW packages will be installed: gvfs-common gvfs-daemons 0 upgraded, 2 newly installed, 0 to remove and 2042 not upgraded. 12 not fully installed or removed. Need to get 0 B/1254 kB of archives. After this operation, 5098 kB of additional disk space will be used. Do you want to continue? [Y/n] Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 236514 files and directories currently installed.) Preparing to unpack .../gvfs-common_1.28.2-1_all.deb ... Unpacking gvfs-common (1.28.2-1) ... Preparing to unpack .../gvfs-daemons_1.28.2-1_i386.deb ... Unpacking gvfs-daemons (1.28.2-1) ... Processing triggers for man-db (2.7.5-1) ... Setting up libmtp9:i386 (1.1.11-1) ... Setting up liboauth0:i386 (1.0.1-1) ... Setting up gvfs-common (1.28.2-1) ... Setting up gvfs-libs:i386 (1.28.2-1) ... Setting up gvfs-daemons (1.28.2-1) ... Setting up gvfs:i386 (1.28.2-1) ... Setting up libgoa-1.0-common (3.20.1-1) ... Setting up libgoa-1.0-0b:i386 (3.20.1-1) ... Setting up libgdata-common (0.17.4-1) ... Setting up libgdata22:i386 (0.17.4-1) ... Setting up libgphoto2-port12:i386 (2.5.10-2) ... Setting up libgphoto2-6:i386 (2.5.10-2) ... Setting up gvfs-backends (1.28.2-1) ... Setting up libmtp-runtime (1.1.11-1) ... Processing triggers for libc-bin (2.21-9) ... localepurge: Disk space freed in /usr/share/locale: 3948 KiB localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB Total disk space freed by localepurge: 3948 KiB Thanks, Andreas Mohr
Bug#808599: cups: lpstat -m Internal Server Error, most certainly due to outdated libcupsppdc1 (incompletely versioned dependencies??)
51:48 +0100] [Client 6] Waiting for CGI data. d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] [cups-driverd] list_ppds(request_id=1, limit=0, opt=\"requested-attributes=all\" d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 I [21/Dec/2015:11:51:48 +0100] [cups-driverd] Read \"/var/cache/cups/ppds.dat\", 19 PPDs... I [21/Dec/2015:11:51:48 +0100] [cups-driverd] Read \"/var/cache/cups/ppds.dat\", 19 PPDs... d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] [CGI] Directory \"/usr/share/cups/model\" permissions OK (043775/uid=0/gid=101). d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 D [21/Dec/2015:11:51:48 +0100] [cups-driverd] Loading \"/usr/share/cups/model\"... d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] [CGI] Directory \"/usr/share/cups/drv\" permissions OK (040755/uid=0/gid=0). d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 D [21/Dec/2015:11:51:48 +0100] [cups-driverd] Loading \"/usr/share/cups/drv\"... d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] [CGI] File \"/usr/share/cups/drv/cupsfilters.drv\" permissions OK (0100644/uid=0/gid=0). d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] [Client 6] write_pipe: CGI output on fd 17. d [21/Dec/2015:11:51:48 +0100] cupsdRemoveSelect(fd=17) d [21/Dec/2015:11:51:48 +0100] cupsdAddSelect(fd=15, read_cb=(nil), write_cb=0x800bf3f0, data=0x80190fd0) D [21/Dec/2015:11:51:48 +0100] [Client 6] CGI data ready to be sent. d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 D [21/Dec/2015:11:51:48 +0100] [Client 6] con->http=0x80192410 D [21/Dec/2015:11:51:48 +0100] [Client 6] cupsdWriteClient error=0, used=0, state=HTTP_STATE_POST_SEND, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=2147483647, response=(nil)(), pipe_pid=25776, file=17 d [21/Dec/2015:11:51:48 +0100] cupsdAddSelect(fd=17, read_cb=0x800bd2e0, write_cb=(nil), data=0x80190fd0) D [21/Dec/2015:11:51:48 +0100] [Client 6] Waiting for CGI data. d [21/Dec/2015:11:51:48 +0100] [Client 6] cupsdSendError code=500, auth_type=0 D [21/Dec/2015:11:51:48 +0100] [Client 6] cupsdSendHeader: code=500, type="text/html", auth_type=0 d [21/Dec/2015:11:51:48 +0100] cupsdAddSelect(fd=15, read_cb=0x800bfdd0, write_cb=(nil), data=0x80190fd0) D [21/Dec/2015:11:51:48 +0100] [Client 6] Waiting for request. d [21/Dec/2015:11:51:48 +0100] cupsdRemoveSelect(fd=17) d [21/Dec/2015:11:51:48 +0100] cupsdEndProcess(pid=25776, force=0) D [21/Dec/2015:11:51:48 +0100] [Client 6] Closing because Keep-Alive is disabled. D [21/Dec/2015:11:51:48 +0100] [Client 6] Closing connection. D [21/Dec/2015:11:51:48 +0100] cupsdSetBusyState: newbusy="Not busy", busy="Active clients" d [21/Dec/2015:11:51:48 +0100] cupsdRemoveSelect(fd=15) d [21/Dec/2015:11:51:48 +0100] cupsdRemoveSelect(fd=-1) d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] process_children() d [21/Dec/2015:11:51:48 +0100] cupsdFinishProcess(pid=25776, name=0xbfb95c5c, namelen=1024, job_id=0xbfb95c58(0)) = "/usr/lib/cups/daemon/cups-driverd" D [21/Dec/2015:11:51:48 +0100] PID 25776 (/usr/lib/cups/daemon/cups-driverd) was terminated normally with signal 15. d [21/Dec/2015:11:51:48 +0100] select_timeout: JobHistoryUpdate=0 d [21/Dec/2015:11:51:48 +0100] select_timeout(-1): 34184 seconds to expire subscription d [21/Dec/2015:11:51:57 +0100] cupsdAcceptClient(lis=0x80144a90(10)) Clients=0 Thanks for listening and coding, Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you.
Bug#743955: coreutils: corrupted files on heavily fragmented ext3 and ext4 partitions
Hi, just wanted to ask: what is the status on this now sufficiently old issue? I keep hitting this via apt-listbugs reports when trying to upgrade from coreutils 8.13-3 to 8.23-4. However, note that the original report said "[bug introduced in coreutils-8.11]" (upstream version value, I assume) So, while I am currently upgrading, it looks like the issue actually already *is* present on my system since I'm *post* 8.11, thus the apt-listbugs warning is somewhat moot/useless here since I'm already past potentially hitting a regression. Thus, perhaps original attributes which were given as: Package: coreutils Version: 8.13-3.5 Severity: grave ought to be request-corrected to properly indicate an *earlier* Debian package version that already was affected (that way my apt-listbugs activity probably would not list this issue during upgrade of the versions that are relevant on my system, since there actually is no status change during this transition). But perhaps the more modern version value was intentionally specified in order to *do* always warn about this issue, even on systems which already upgraded to an affected coreutils version... And then, of course, there remains the question of whether the currently provided (upgrade target) version (8.23-4) already is one where this issue indeed is fixed. However since original report said "It is present in the wheezy coreutils version and is fixed in jessie/sid. A backport of the fix or an update of coreutils would be welcomed for wheezy." yet https://packages.debian.org/search?keywords=coreutils reports version in jessie as 8.23-4 which is exactly my upgrade target and which is a version which is said to be fixed, I'd come to think that this bug report is missing specification of some sort of "fixed-in" attribute. Hmm, but there's no "fixed-in" tag (since I assume the way to mark this is to simply and properly close a bug), but perhaps using "wheezy" (https://www.debian.org/Bugs/Developer#tags) would be the way to go? As it stands, I'm predominantly irritated by the fact that apt-listbugs somehow decides to keep reporting an issue which *is* said to be fixed in this very upgrade target version (and, to make matters much worse, this warning report may actively and strongly deter people from promoting an unhealthy system to a healthy state i.e. an actually fixed version!!!) [personally, I have now decided to proceed with the upgrade since it seems correct and important] Thanks, Andreas Mohr
Bug#772628: Patch for kmod package to support compression
Since I managed to mess up things by telling my own new story rather than having stumbled upon this detailed pre-existing item (via proper research, that is...), I now see it as my duty to at least reference the new discussion's URL here: "[PATCH] modules: CONFIG_MODULE_COMPRESS: add hint that userspace support may easily be missing." https://lkml.org/lkml/2015/5/31/90 Given current direction / results of that discussion, I'd want to vote for gaining at least *some* amount of compression support directly in Debian binary package defaults. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687172: Fontconfig file warnings
For message documentation reasons, the exact error output as experienced on iceweasel startup is: Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 14: Having multiple values in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Fontconfig warning: "/etc/fonts/conf.d/65-ttf-sil-andika.conf", line 32: Having multiple in isn't supported and may not work as expected Currently occurring at: (latest) ttf-sil-andika 1.0.basic-4 (fonts-sil-andika 1.004-2). Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#777030: audacity: crashes on startup (debug info included)
Char = {m_str = 0x0, m_len = 3083145968}}
logoimage =
project = 0x8b43c30
didRecoverAnything = 87
tmpDirLoc = {static npos = 4294967295, m_impl = L"/tmp",
m_convertedToChar = {m_str = 0x0, m_len = 3083145968}}
temporarywindow = 0x8a7f2b8
pWnd = 0x0
#2 0xb7491c96 in wxEntry(int&, wchar_t**) ()
from /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#3 0xb7491d33 in wxEntry(int&, char**) ()
from /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
No symbol table info available.
#4 0x0812d97a in main (argc=1, argv=0xb8a4) at AudacityApp.cpp:642
No locals.
A debugging session is active.
Inferior 1 [process 27811] will be killed.
Quit anyway? (y or n)
Address 0x00ab08a7 seems to be a random one which does not seem to correlate
with output of "info sharedlibrary".
$ LANG=en_US.UTF-8 aplay -l
List of PLAYBACK Hardware Devices
card 0: ALS4000 [Avance Logic ALS4000], device 0: ALS4000 DSP []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: AZF3328PCI168 [Aztech AZF3328 (PCI168)], device 0: AZF3328 DSP [Aztech
AZF3328 (PCI168)]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: AZF3328PCI168 [Aztech AZF3328 (PCI168)], device 1: AZF3328 I2S OUT
[Aztech AZF3328 (PCI168)]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: V8235 [VIA 8235], device 0: VIA 8235 [VIA 8235]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
card 2: V8235 [VIA 8235], device 1: VIA 8235 [VIA 8235]
Subdevices: 1/1
Subdevice #0: subdevice #0
$ dpkg -l|grep alsa
ii alsa-base 1.0.27+1
all dummy package to ease purging of obsolete conffiles
ii alsa-oss 1.0.28-1
i386 ALSA wrapper for OSS applications
ii alsa-tools1.0.28-1
i386 Console based ALSA utilities for specific hardware
ii alsa-utils1.0.28-1
i386 Utilities for configuring and using ALSA
ii alsamixergui 0.9.0rc2-1-9
i386 graphical soundcard mixer for ALSA soundcard driver
ii alsaplayer0.99.76-0.3
i386 PCM player designed for ALSA
ii alsaplayer-alsa 0.99.80-5+b1
i386 PCM player designed for ALSA (ALSA output module)
ii alsaplayer-common 0.99.80-5+b1
i386 PCM player designed for ALSA (common files)
ii alsaplayer-gtk0.99.80-5+b1
i386 PCM player designed for ALSA (GTK+ version)
ii alsaplayer-text 0.99.80-5+b1
i386 PCM player designed for ALSA (text version)
ii gnome-alsamixer 0.9.7~cvs.20060916.ds.1-2
i386 ALSA sound mixer for GNOME
ii gstreamer0.10-alsa:i386 0.10.36-1
i386 GStreamer plugin for ALSA
ii libsox-fmt-alsa 14.4.0-3
i386 SoX alsa format I/O library
$ dpkg -l|grep libaso
ii libasound2:i386 1.0.28-1
i386 shared library for ALSA applications
ii libasound2-data 1.0.28-1
all Configuration files and profiles for ALSA drivers
ii libasound2-dbg:i386 1.0.28-1
i386 debugging symbols for libasound2
ii libasound2-dev:i386 1.0.28-1
i386 shared library for ALSA applications -- development files
ii libasound2-doc1.0.28-1
all documentation for user-space ALSA application programming
ii libasound2-plugins:i386 1.0.28-1+b1
i386 ALSA library additional plugins
Purging the dummy alsa-base package did not help.
I will examine the various ALSA warnings that are coming up,
but nevertheless such issues (even if relevant)
should never end up with the application crashing on startup.
My report might perhaps be related to #423007.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748485: audacity: steals window manager focus frequently
Hi, comment from an interested user: it might be useful to have this report become fully and easily reproducible, by amending a simple yet nicely documented test case (automated execution script etc.). And yeah, I fully support your "complaint" about undesirable app behaviour. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728113: [smartmontools] Fails to run on a Wheezy/Jessie mixed system
Hi, I'm mildly confused about what the status/situation now is. Reason being that I just upgraded various packages *without* apt-listbugs yelling about a sufficiently grave situation of smartmontools, with the result of having a broken upgrade, which necessitated a (albeit simple) downgrade to fix things. I'm somewhat surprised that apt-listbugs did not yell (which would have been a good thing), but this might have been due to it possibly triggering for >= "grave", whereas this bug is currently (and possibly rightfully?) at "serious" rating (--> https://www.debian.org/Bugs/). So, given this bug's records/history I don't know easily which dependency exactly is causing issues here. I'm obviously not concerned about my local status - I can fix up things easily (I'm now pondering doing some modifications in the libc6 / libselinux1 area). I'd want to repeat the question asked initially, "All the dependencies seem to be satisfied. Maybe they are not stated correctly/strictly enough?". If there's any clarification that's available and worth stating, that would be great. Thanks a ton for your highly appreciated work, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763914: xdotool: slightly more detailed description line desirable
Package: xdotool Version: 1:3.20130111.1-5 Severity: wishlist Hi, currently e.g. xdotool Debian package has the following description: xdotool - simulate X11 keyboard/mouse input Description-de: Simuliert X11-Tastatur- und Mauseingabe This meant that I failed to locate this package, hard: neither searching for keyword "event" - as is rather common since it's a "Linux input event" subsystem - nor "generate" managed to spit out this package (trying to do something like apt-cache search event). Use of debtags might have been more successful, but I didn't try it. I would thus strongly recommend extending package/software description line (or at least its extended description) to something like: xdotool - simulate (generate) X11 keyboard/mouse input events Description-de: Simuliert (generiert) X11-Tastatur- und Mauseingabe-Ereignisse Thanks for a very nice tool! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760768: libfontenc1: outdated zlib1g Depends (causing xfonts-utils mkfontscale Segmentation fault crash)
Package: libfontenc1
Version: 1:1.1.2-1
Hi,
during some updates / reinstalls of xfonts-unifont, I saw
Setting up xfonts-unifont (1:6.3.20140214-1) ...
Segmentation fault
Turned out that the inner command which segfaulted is:
mkfontscale -b -s -l -e /usr/share/fonts/X11/encodings -e
/usr/share/fonts/X11/
which crashes in some libfontenc1 code:
(gdb) run
Starting program: /usr/bin/mkfontscale -e .
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Breakpoint 1, FontEncIdentify (fileName=0x8050008 "./.")
at ../../src/encparse.c:906
906 {
(gdb) n
912 if((f = FontFileOpen(fileName))==NULL) {
(gdb)
915 encoding = parseEncodingFile(f, 1);
(gdb) s
parseEncodingFile (f=f@entry=0x80583c8, headerOnly=headerOnly@entry=1)
at ../../src/encparse.c:462
462 {
(gdb) n
465 unsigned short *enc=NULL;
(gdb)
467 unsigned i, first = 0x, last=0, encsize=0, namsize=0;
(gdb)
480 line = getnextline(f);
(gdb) s
getnextline (f=f@entry=0x80583c8) at ../../src/encparse.c:196
196 {
(gdb) n
198 c = FontFileGetc(f);
(gdb) n
196 {
(gdb) n
198 c = FontFileGetc(f);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0xb7fb02b6 in getnextline (f=f@entry=0x80583c8) at ../../src/encparse.c:198
198 c = FontFileGetc(f);
(gdb)
Eventually found out that it works on a system with zlib1g 1.2.7.dfsg-13,
yet crashes on a system with 1:1.2.3.4.dfsg-3 .
A simple and successful test is to downgrade a (working) 1.2.7 system
via the 1.2.3.4 package (on my system there fortunately
were no packages installed which had a zlib1g Depends which disallowed that),
and then execute the well-known
mkfontscale -b -s -l -e /usr/share/fonts/X11/encodings -e
/usr/share/fonts/X11/
command again, which now ends up crashing rather than previously working.
Not sure what the policy of specifying newer versions is, though
(theoretically you could simply demand "> 1:1.2.3.4.dfsg-3"
to force an update from the non-compatible older zlib1g version,
or alternatively specifically demand ">= 1.2.7.dfsg-13"
which in this case has been proven to be working.
Finally, it's not quite known
what would constitute a sane libfontenc1 code implementation handling here
anyway - after all we're talking of a somewhat weird gzgetc()
of a gzopen() of filename "./.", i.e. the current-dir entry -
this probably would work for regular files but chooses to crash
for a dir entry (in the older zlib1g version, that is).
So perhaps libfontenc1 should be fixed (instead / as well)
to not do such shenanigans...
ii libfontenc1:i386 1:1.1.2-1 i386
X11 font encoding library
ii xfonts-utils 1:7.7+2 i386
X Window System font utility programs
ii zlib1g 1:1.2.3.4.dfsg-3 i386
compression library - runtime
Thanks,
Andreas Mohr
--
GNU/Linux. It's not the software that's free, it's you.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742211: zenity: --info destroys X11 primary selection content, and does not document that either
control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=734196 -- GNU/Linux. It's not the software that's free, it's you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742211: zenity: --info destroys X11 primary selection content, and does not document that either
Hi, On Mon, Jul 28, 2014 at 11:09:17AM +0200, intrigeri wrote: > Control: found -1 + 3.12.1-1 > > Hi, > > Andreas Mohr wrote (20 Mar 2014 18:59:32 GMT) : > > Witness your primary selection getting zilched, nullified > > as soon as zenity is launched, on this environment and some others > > Reproduced on current Debian sid. > > Andreas, I think the best course of action would now be to 1. check if > this bug is known upstream; 2. if it isn't, then report it there. Nice to have a status report, thanks. > Do you want to do that? OK, I'll do it soon (noted), but it'll have to wait a couple days until I'm less busy. Thank you, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742211: zenity: --info destroys X11 primary selection content, and does not document that either
Package: zenity Version: 3.8.0-1 Severity: important Justification: data loss Dear Maintainer, * What led up to the situation? Select something with left mouse key, then run e.g. sleep 10 && /usr/bin/zenity --info --text foobar or sleep 10 && /usr/bin/zenity --error --text foobar * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? Witness your primary selection getting zilched, nullified as soon as zenity is launched, on this environment and some others (bug discovered on u1204LTS). * What outcome did you expect instead? Middle mouse button ought to still have been able to re-paste the left-button-copied content, just like it *does work* for sleep 10 && /usr/bin/zenity --entry (!!) sleep 10 && /usr/bin/zenity --file-selection (!!) sleep 10 && /usr/bin/kdialog --msgbox foobar (4:4.11.3-1) Fooled once, fooled twice, but then I got wise ;) Severity important since it's *very* annoying to lose copy&paste content of possibly already vanished or forgotten origin content (this problem does not apply to the case of windows having been closed though since it appears their selection is gone anyway), seemingly without any indication by zenity on why this is the case, and why for *certain* zenity modes only (so, this problem should either be fixed, or properly documented). Anyway, in my case it was an annoyance at least a couple times already when losing mouse selection content midstream due to having chosen to use zenity as a cron-based reminder message launcher... Thanks a lot for your work, Andreas Mohr -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12.0-rc2+ 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 zenity depends on: ii libc6 2.17-3 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-02.38.2-5 ii libgtk-3-0 3.10.7-1 ii libnotify4 0.7.4-1 ii libpango-1.0-0 1.36.0-1+b1 ii libwebkitgtk-3.0-0 2.2.5-1 ii libx11-62:1.6.0-1 ii zenity-common 3.8.0-1 zenity recommends no packages. zenity suggests no packages. -- no debconf information -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721792: mtr fails without IPv6 socket
Hi, > Yes. This bug is "fix committed" in the git repository. But I haven't > released the next version yet. OK, manual build (b46c5598593) near-fully worked, thanks! I'm interested in this since # mtr -4 www.sueddeutsche.de Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol had catastrophic failure (shortly flashing mtr X11 window, then quit) despite -4 option given. (running with # CONFIG_IPV6 is not set here, more or less for archaic-hardware reasons) With the manual build I still get the # mtr -4 www.sueddeutsche.de Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol but the window does work. :) Given that I did explicitly specify -4 option (quoting mtr(8): "Use IPv4 only." - note "only.") I'm a bit puzzled why there's still this IPv6-side error (well, warning) message displayed/processed at all. Seems like slightly erroneous program flow in IPv4-only case? Other than that, very useful stuff! Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721190: debirf: random suggestions
Package: debirf
Version: 0.33
Severity: wishlist
Would possibly be useful for debirf to have a highly user-visible (yet
non-stalling)
warning in case a package setup is drawing in a GUI bloat dependency,
i.e., GUI-dependent packages are being installed
(this could possibly be determined via appearance of libx11-data package).
Perhaps debirf should offer an option (-m? -b?) to be doing a bind mount
of /proc? (hmm, and /dev, /sys??)
See http://forums.debian.net/viewtopic.php?t=34902
At least in the fakechroot case bind mounts of /dev /proc /sys
should be ok, right?
The following packages fail:
tgt: throws some stupid tgtadm "Transport endpoint is not connected"
errors, likely due to missing /proc
zfs-fuse: cannot find /proc/PID/oom_adj (and locks up with 100% CPU to
boot!!)
chrony and samba: start-stop-daemon barfs on missing /proc
DEBIRF_ARCH not mentioned in debirf.conf - perhaps this is intentional
(possibly due to issues; especially since there may easily be problems
on same-arch even), perhaps not
# Which manually specified arch override to pass to debootstrap?
# Example value: "i386".
Note that debirf seems to be doing fakeroot / chroot / fakechroot in an order
that is NOT officially sanctioned by a recent fakechroot man page:
"It is important to start fake environment in proper order. fakeroot
should be started inside fakeroot:" ... "fakechroot fakeroot chroot ..."
Trying to manually invoke a corrected order (debirf script has some
layering here which seems to make it difficult to achieve the correction)
did not help with the Permission Denied issue, though -
ultimately I had to resort to debirf -r to get through processing unscathed,
unfortunately.
modules/install-kernel:
"generating modules.dep..." (should perhaps log $KVERS here, too)
debirf possibly does not have support for a rootfs.tar.bz2 (e.g.
ping.windowsdream.com has that)
Possibly much better compression...
bashisms (while the script implementation clearly is bash-specific,
some reduction might be useful, via devscripts' checkbashisms)
Package suggestions (need to watch out for Wintel specifics?):
Possibly good rescue packages, smallish:
sshfs xmount fusedav
memtester dmidecode vbetool
netcat buffer cpipe
ethtool
hexedit
strace ltrace
perforate fdupes
larger ones:
ntfs-3g partclone
ntpdate
elinks-lite (probably size-preferable to curl and especially to
wget)
less relevant ones:
superiotool mii-diag (mii-tool provided by ethtools)
And some patches following which may or may not get applied,
in this or not this form. ;)
Thanks for a very nice tool!
commit 185759d268bd044b5e79a7db0cfbb455fb917511
Author: Andreas Mohr
Date: Wed Aug 28 21:09:11 2013 +0200
Random usability improvement comments.
- point out that DEBIRF_DISTRO may not always be available
at the moment that you'd expect it
- mention kernel image specifics
- misc.
diff --git a/doc/README b/doc/README
index 57808fd..16e9691 100644
--- a/doc/README
+++ b/doc/README
@@ -62,7 +62,9 @@ If this run is successful, there should be a bootable ISO
image stored
at ~/debirf/minimal/debirf-minimal.iso. You can burn this .iso image format
as (into) CD format using a tool like wodim, or use it via USB multi-boot.
-Have fun! Create new modules and profiles for your specific needs.
+Have fun! Create new modules and profiles for your specific needs
+(storing your module files in a parent directory of the profile-specific dir
+may sometimes be useful, for easy duplicated symlinking and central updating).
If you think your module or profile would be generally useful, please
let us know and we'll include it with future versions of debirf. Also
please let us know of any issues, bugs, or requests.
diff --git a/doc/example-profiles/minimal/debirf.conf
b/doc/example-profiles/minimal/debirf.conf
index 66f2a54..79cc2c1 100644
--- a/doc/example-profiles/minimal/debirf.conf
+++ b/doc/example-profiles/minimal/debirf.conf
@@ -23,7 +23,7 @@ DEBIRF_LABEL="debirf-minimal"
#DEBIRF_DISTRO=
# What mirror should debirf pull the suite from? By default, this is
-# based on the DEBIRF_DISTRO
+# based on the DEBIRF_DISTRO setting that may be chosen by the script.
# (eg. "http://mirrors.kernel.org/${DEBIRF_DISTRO}";).
#
#DEBIRF_MIRROR=
diff --git a/doc/example-profiles/rescue/debirf.conf
b/doc/example-profiles/rescue/debirf.conf
index 4ca0cb9..e3bb2f6 100644
--- a/doc/example-profiles/rescue/debirf.conf
+++ b/doc/example-profiles/rescue/debirf.conf
@@ -23,7 +23,7 @@ DEBIRF_LABEL="debirf-rescue"
#DEBIRF_DISTRO=
# What mirror should debirf pull the suite from? By default, this is
-# based on the DEBIRF_DISTRO
+# based on the DEBIRF_DISTRO that may be chosen by the script.
# (eg. "http://mirrors.kernel.org/${DEBIRF_DISTRO}";).
#
#DEBIRF_MIRROR=
diff --git a/doc/exa
Bug#721094: debirf: imprecise (redundant/confusing) -n/-o/-s options
Did new git show to diff file, re-executed vim line to reread file, yet old
patch was
included. WTH. Ah, it was because I then had renamed the diff file, ouch, sorry!
commit ce4489aa88f8439c2bca79c2d2b3088b535222bb
Author: Andreas Mohr
Date: Wed Aug 28 10:00:59 2013 +0200
Protect against the user passing multiple different debirf write mode
options.
Since there are multiple redundant -n/-o/-s switches rather than a
single mode switch, we need to guard against the user accidentally passing
in
multiple incompatible (and thus overriding/overwriting! as in the "-s -n"
i.e. want-skip yet then overridden by --new case) write mode requests.
diff --git a/src/debirf b/src/debirf
index d1a54cc..d91c9bc 100755
--- a/src/debirf
+++ b/src/debirf
@@ -349,14 +349,17 @@ make() {
;;
-n|--new)
WRITE_MODE=rewrite
+ write_mode_rewrite_given=1
shift 1
;;
-o|--overwrite)
WRITE_MODE=overwrite
+ write_mode_overwrite_given=1
shift 1
;;
-s|--skip)
WRITE_MODE=skip
+ write_mode_skip_given=1
shift 1
;;
-r|--root-build)
@@ -393,6 +396,18 @@ make() {
;;
esac
done
+# Protect against misuse of redundant write mode implementation
+# (multiple -n/-o/-s switches), see #721094.
+# Do this by adding extra helper flags above
+# that are to be increment-evaluated here,
+# to avoid disallowing e.g. a duplicate -s -s case.
+write_mode_argcount=0
+[ -n "${write_mode_rewrite_given}" ] &&
write_mode_argcount=$((write_mode_argcount+1))
+[ -n "${write_mode_overwrite_given}" ] &&
write_mode_argcount=$((write_mode_argcount+1))
+[ -n "${write_mode_skip_given}" ] &&
write_mode_argcount=$((write_mode_argcount+1))
+if [ ${write_mode_argcount} -gt 1 ]; then
+ failure "Multiple different write mode switches (-n/-o/-s) given -
please resolve this command line conflict."
+fi
if [ $(id -u) = '0' ] ; then
cat <
Bug#721094: debirf: imprecise (redundant/confusing) -n/-o/-s options
Hi,
On Tue, Aug 27, 2013 at 06:44:09PM -0400, Daniel Kahn Gillmor wrote:
> On 08/27/2013 05:40 PM, Andreas Mohr wrote:
> > (witness --skip getting overwritten by any subsequent --new / --overwrite
> > in this while loop)
> >
> >
> > The root cause of my confusion case is that -n -o -s parameters are
> > wholly redundant: instead, they are supposed to be a *single* *mode* switch,
> > to cleanly reflect exactly how it's implemented within-script
> > (WRITE_MODE=xxx),
> > since this seems appropriate here.
> >
> > These redundant options should thus be deprecated in favour of e.g. a
> > combined
> > -m (--mode) switch taking rewrite/overwrite/skip arguments, I'd think
> > (and probably add a deprecation warning for a while,
> > whenever the old switches happen to get used).
>
> If i understand correctly, checking for redundant options and
> terminating with a non-zero error code and a warning would have avoided
> your problem without breaking compatibility with existing scripts that
> use only one of the options.
>
> I'd welcome a patch that implements such a check. I'd rather not add a
> new command-line option (e.g. --mode) if we can avoid it.
Yeah, it's probably better after all to preserve userspace behaviour, to reduce
confusion.
> Thanks for pointing this out!
N.p., I've got some more debirf hints in the pipe ;)
Preliminary untested (just got rid of my environment here) patch
(any comments? improvements?):
commit 860e666815264c179141289c6e7d59a8f753a252
Author: Andreas Mohr
Date: Wed Aug 28 10:00:59 2013 +0200
Protect against the user passing multiple different debirf write mode
options.
Since there are multiple redundant -n/-o/-s switches rather than a
single mode switch, we need to guard against the user passing multiple
incompatible write mode requests.
diff --git a/src/debirf b/src/debirf
index d1a54cc..d7b1f17 100755
--- a/src/debirf
+++ b/src/debirf
@@ -349,14 +349,17 @@ make() {
;;
-n|--new)
WRITE_MODE=rewrite
+ write_mode_rewrite_given=1
shift 1
;;
-o|--overwrite)
WRITE_MODE=overwrite
+ write_mode_overwrite_given=1
shift 1
;;
-s|--skip)
WRITE_MODE=skip
+ write_mode_skip_given=1
shift 1
;;
-r|--root-build)
@@ -393,6 +396,18 @@ make() {
;;
esac
done
+# Protect against misuse of redundant write mode implementation
+# (multiple -n/-o/-s switches), see #721094.
+# Do this by adding extra helper flags above
+# that are to be increment-evaluated here,
+# to avoid disallowing e.g. a duplicate -s -s case.
+WRITE_MODE_ARGCOUNT=0
+[ -n "${write_mode_rewrite_given}" ] &&
WRITE_MODE_ARGCOUNT=$((WRITE_MODE_ARGCOUNT+1))
+[ -n "${write_mode_overwrite_given}" ] &&
WRITE_MODE_ARGCOUNT=$((WRITE_MODE_ARGCOUNT+1))
+[ -n "${write_mode_skip_given}" ] &&
WRITE_MODE_ARGCOUNT=$((WRITE_MODE_ARGCOUNT+1))
+if [ ${WRITE_MODE_ARGCOUNT} -gt 1 ]; then
+ failure "Multiple different write mode switches (-n/-o/-s) given -
please resolve this command line conflict."
+fi
if [ $(id -u) = '0' ] ; then
cat <
Bug#721094: debirf: imprecise (redundant/confusing) -n/-o/-s options
Package: debirf Version: 0.33 Severity: wishlist Hi, after some progress with debirf (i.e., a rootfs finally successfully created), I decided to start using debirf -s (WRITE_MODE=skip) yet by simply having it *inserted* to my prior cmdline without realizing that -s WRITE_MODE setting would get overwritten by my leftover subsequent -n (WRITE_MODE=rewrite) or -o (WRITE_MODE=overwrite) options. --> Result: debootstrap called again despite not wanting it this time... while true ; do case "$1" in ... -n|--new) WRITE_MODE=rewrite shift 1 ;; -o|--overwrite) WRITE_MODE=overwrite shift 1 ;; -s|--skip) WRITE_MODE=skip shift 1 ;; ... (witness --skip getting overwritten by any subsequent --new / --overwrite in this while loop) The root cause of my confusion case is that -n -o -s parameters are wholly redundant: instead, they are supposed to be a *single* *mode* switch, to cleanly reflect exactly how it's implemented within-script (WRITE_MODE=xxx), since this seems appropriate here. These redundant options should thus be deprecated in favour of e.g. a combined -m (--mode) switch taking rewrite/overwrite/skip arguments, I'd think (and probably add a deprecation warning for a while, whenever the old switches happen to get used). Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721093: debootstrap: possibly add clarifying comment about $SECOND_STAGE_ONLY
Package: debootstrap Version: 1.0.53 Severity: wishlist Hi, turns out that I used debootstrap (via debirf) in a completely wrong manner: I used a subsequent manual debootstrap invocation with --second-stage, but I failed to realize at that time that this should likely be done *within-target* (chroot) rather than from the outside, in order to be able to successfully locate suite and arch files within the correct $DEBOOTSTRAP_DIR. Thus it would be useful to have comment if [ "$SECOND_STAGE_ONLY" = "true" ]; then # Within-target handling - read existing content # established there by a prior complete run: SUITE=$(cat $DEBOOTSTRAP_DIR/suite) ARCH=$(cat $DEBOOTSTRAP_DIR/arch) added to debootstrap script. Yeah, I know: docs do contain hints at this handling - but who reads docs anyway? ;) Thanks for a very useful package and an impressively clean script, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720584: initscripts.postinst: wrong --compare-versions checks (causing debootstrap fakechroot failure)
Package: initscripts
Version: 2.88dsf-43
Severity: important
Tags: d-i patch
Dear Maintainer,
I'm unsuccessfully trying to use debirf to create a Debian testing initrd,
i.e. using debootstrap in fakechroot mode.
* What led up to the situation?
debootstrap fails, with an sh -ex enabled debootstrap.log containing:
+ info CONFIGURING Configuring %s... initscripts
+ local name=CONFIGURING
+ local fmt=Configuring %s...
+ shift
+ shift
+ [ ]
+ printf I: Configuring %s...\n initscripts
+ expect=installed
+ read status pkg qstate
sed: couldn't open temporary file /etc/default/sedUlNpID: Permission denied
dpkg: error processing initscripts (--configure):
subprocess installed post-installation script returned error exit status 4
+ [ status: = EXITCODE ]
+ [ : error : subprocess installed post-installation script returned error exit
status 4 = installed ]
I then did
debirf enter (enter chroot)
and there did a manual
dpkg -D777 --configure initscripts
and then
sh -x /var/lib/dpkg/info/initscripts.postinst configure
which both successfully exhibited the sed failure above.
Narrowing it down some more via a
strace -f sed -i 's:foobar:foobaz:' /etc/default/rcS|less
showed
open("/etc/default/sedO6lzxA", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1
EACCES (Permission denied)
umask(022) = 0700
write(2, "sed: ", 5sed: )= 5
write(2, "couldn't open temporary file /et"..., 70couldn't open temporary file
/etc/default/sedO6lzxA: Permission denied) = 70
write(2, "\n", 1
* What exactly did you do (or not do) that was effective (or
ineffective)?
Nothing.
* What was the outcome of this action?
Complete debirf (debootstrap) failure so far, for any install of Debian testing.
== "WTF" ==
This failure was not avoided, due to postinst improperly deciding
to enter the sed fixup section despite it being an initial-install,
thus dpkg --compare-versions with empty $PREV_VER ought to have been false
(see dpkg(1)).
Or, to put it more clearly, this perhaps unfixable permission failure
(see also related bugs #596284 / #694986 / #649148 ) would at least
have been avoided in *my* situation of an initial-install -
*if* the version checks had been correct.
* What outcome did you expect instead?
Given that I expect debootstrap to be an absolute hotpath
(thousands of server installs) this should have Nothing But Worked.
Will soon try non-fakechroot mode of debootstrap instead,
since I'm hopeful that this will avoid the Permission Denied issue.
I'm quickly running out of ideas on how to get a Debian testing debootstrap
up and running, however, since I'm unsure whether I'm able to locally supply a
custom-patched package, or use any other suitable methods to avoid that failure.
There are several similar Internet reports about debootstrap-related problems
in this area.
This reportbug template produced by host system (aptosid 2013-01),
not semi-bootstrapped one - some info may be slightly(!) mismatching.
Untested patch included here.
It corrects the comparison operators where suitable, and only there!
(some others further below talk of those being necessary
for both specific version ranges and initial-install empty-string, too)
With this patch it means that postinst now depends on solid availability
of the possibly too modern lt-nl variants (perhaps that kind of dpkg support
may happen to be not old enough?).
Thank you for maintaining a very important and thus sizeable core package!
Andreas Mohr
--- initscripts.postinst.orig 2013-08-23 15:39:09.021852346 +0200
+++ initscripts.postinst2013-08-23 15:41:39.228899560 +0200
@@ -61,16 +61,16 @@
}
# In 2.88dsf-23 the "mountoverflowtmp" script was dropped entirely.
-if dpkg --compare-versions "$PREV_VER" lt "2.88dsf-23" ; then
+if dpkg --compare-versions "$PREV_VER" lt-nl "2.88dsf-23" ; then
update-rc.d -f mountoverflowtmp remove >/dev/null
fi
# In 2.88dsf-41+jessie1 the "mtab.sh" script was dropped entirely.
-if dpkg --compare-versions "$PREV_VER" lt "2.88dsf-41+jessie1" ; then
+if dpkg --compare-versions "$PREV_VER" lt-nl "2.88dsf-41+jessie1" ; then
update-rc.d -f mtab.sh remove >/dev/null
fi
# Comment out obsolete options in rcS.
-if dpkg --compare-versions "$PREV_VER" lt "2.88dsf-23" ; then
+if dpkg --compare-versions "$PREV_VER" lt-nl "2.88dsf-23" ; then
if [ -f /etc/default/rcS ]; then
sed -i \
-e 's:^\(RAMRUN=.*\)$:#\1 # OBSOLETE; see /etc/default/tmpfs and tmpfs(5).:' \
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i586)
Kernel: Linux 3.9-0.slh.4-aptosid-686 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE
Bug#717389: libgtk-3-0: sysmalloc assertion when libxi6 2:1.4.2-1 rather than 2:1.7.1.901-1 (using gnome-terminal)
08:36:02 configure libgtk-3-0-dbg:i386 3.8.2-3 2013-07-20 08:36:02 status unpacked libgtk-3-0-dbg:i386 3.8.2-3 2013-07-20 08:36:02 status half-configured libgtk-3-0-dbg:i386 3.8.2-3 2013-07-20 08:36:02 status installed libgtk-3-0-dbg:i386 3.8.2-3 == TRANSITION LINE: START OF ACTIVITIES which caused gnome-terminal to go from failing to working == 2013-07-20 08:40:12 startup archives unpack 2013-07-20 08:40:17 upgrade libx11-dev:i386 2:1.5.0-1+deb7u1 2:1.6.0-1 2013-07-20 08:40:18 status half-configured libx11-dev:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:18 status unpacked libx11-dev:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:18 status half-installed libx11-dev:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:19 status half-installed libx11-dev:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:19 status unpacked libx11-dev:i386 2:1.6.0-1 2013-07-20 08:40:19 status unpacked libx11-dev:i386 2:1.6.0-1 2013-07-20 08:40:20 upgrade libx11-6:i386 2:1.5.0-1+deb7u1 2:1.6.0-1 2013-07-20 08:40:20 status half-configured libx11-6:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:20 status unpacked libx11-6:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:20 status half-installed libx11-6:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:21 status half-installed libx11-6:i386 2:1.5.0-1+deb7u1 2013-07-20 08:40:21 status unpacked libx11-6:i386 2:1.6.0-1 2013-07-20 08:40:21 status unpacked libx11-6:i386 2:1.6.0-1 2013-07-20 08:40:22 upgrade libxi-dev:i386 2:1.4.2-1 2:1.7.1.901-1 2013-07-20 08:40:22 status half-configured libxi-dev:i386 2:1.4.2-1 2013-07-20 08:40:22 status unpacked libxi-dev:i386 2:1.4.2-1 2013-07-20 08:40:22 status half-installed libxi-dev:i386 2:1.4.2-1 2013-07-20 08:40:22 status triggers-pending man-db:i386 2.6.3-6 2013-07-20 08:40:23 status half-installed libxi-dev:i386 2:1.4.2-1 2013-07-20 08:40:23 status unpacked libxi-dev:i386 2:1.7.1.901-1 2013-07-20 08:40:23 status unpacked libxi-dev:i386 2:1.7.1.901-1 2013-07-20 08:40:24 upgrade libxi6:i386 2:1.4.2-1 2:1.7.1.901-1 2013-07-20 08:40:24 status half-configured libxi6:i386 2:1.4.2-1 2013-07-20 08:40:24 status unpacked libxi6:i386 2:1.4.2-1 2013-07-20 08:40:24 status half-installed libxi6:i386 2:1.4.2-1 2013-07-20 08:40:24 status half-installed libxi6:i386 2:1.4.2-1 2013-07-20 08:40:25 status unpacked libxi6:i386 2:1.7.1.901-1 2013-07-20 08:40:25 status unpacked libxi6:i386 2:1.7.1.901-1 2013-07-20 08:40:25 install libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:40:25 status half-installed libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:40:26 status unpacked libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:40:26 status unpacked libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:40:26 trigproc man-db:i386 2.6.3-6 2.6.3-6 2013-07-20 08:40:26 status half-configured man-db:i386 2.6.3-6 2013-07-20 08:41:04 status installed man-db:i386 2.6.3-6 2013-07-20 08:41:07 startup packages configure 2013-07-20 08:41:07 configure libx11-6:i386 2:1.6.0-1 2013-07-20 08:41:07 status unpacked libx11-6:i386 2:1.6.0-1 2013-07-20 08:41:07 status half-configured libx11-6:i386 2:1.6.0-1 2013-07-20 08:41:10 status installed libx11-6:i386 2:1.6.0-1 2013-07-20 08:41:10 configure libx11-dev:i386 2:1.6.0-1 2013-07-20 08:41:10 status unpacked libx11-dev:i386 2:1.6.0-1 2013-07-20 08:41:10 status half-configured libx11-dev:i386 2:1.6.0-1 2013-07-20 08:41:10 status installed libx11-dev:i386 2:1.6.0-1 2013-07-20 08:41:10 configure libxi6:i386 2:1.7.1.901-1 2013-07-20 08:41:10 status unpacked libxi6:i386 2:1.7.1.901-1 2013-07-20 08:41:10 status half-configured libxi6:i386 2:1.7.1.901-1 2013-07-20 08:41:10 status installed libxi6:i386 2:1.7.1.901-1 2013-07-20 08:41:11 configure libxi-dev:i386 2:1.7.1.901-1 2013-07-20 08:41:11 status unpacked libxi-dev:i386 2:1.7.1.901-1 2013-07-20 08:41:11 status half-configured libxi-dev:i386 2:1.7.1.901-1 2013-07-20 08:41:11 status installed libxi-dev:i386 2:1.7.1.901-1 2013-07-20 08:41:11 configure libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:41:11 status unpacked libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:41:11 status half-configured libxi6-dbg:i386 2:1.7.1.901-1 2013-07-20 08:41:11 status installed libxi6-dbg:i386 2:1.7.1.901-1 And, well, running gnome-terminal finally started happening to work... So, perhaps we're missing a proper version Depends in libgtk-3-0, since it currently has: Depends: ... libxi6 (>= 2:1.2.99.4) ... [current setting obviously not sufficient...] (and the problem quite likely *is* about libxi6 since XIQueryDevice() was the last backtrace frame to seemingly have caused the issue) #699531 might be related, since that one is complaining about _gdk_device_xi2_reset_scroll_valuators segfault, with merely a libxi6 2:1.6.1-1 installed there (this additional bug might nail it down to requiring a Depends: indicating something *newer than* 2:1.6.1-1 and *less-equal* 2:1.7.1.901-1 as installed and working on my machine) Thanks, Andreas Mohr -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linu
Bug#710670: ruby-gettext: install fails, tries overwriting libgettext-ruby1.8 2.1.0-2.1 file man1/rmsgmerge.1.gz
Package: ruby-gettext Version: 2.3.9-1 Severity: normal Hi, perhaps something like a missing Replaces: or Breaks: line somewhere? Thanks! (Reading database ... 233730 files and directories currently installed.) Unpacking libppl12 (from .../libppl12_1%3a1.0-7_i386.deb) ... Selecting previously unselected package libcloog-ppl1. Unpacking libcloog-ppl1 (from .../libcloog-ppl1_0.16.1-2_i386.deb) ... Selecting previously unselected package libitm1. Unpacking libitm1 (from .../libitm1_4.8.0-7_i386.deb) ... Selecting previously unselected package gcc-4.7-base. Unpacking gcc-4.7-base (from .../gcc-4.7-base_4.7.3-4_i386.deb) ... Preparing to replace ruby1.8-dev 1.8.7.352-2 (using .../ruby1.8-dev_1.8.7.358-7_i386.deb) ... Unpacking replacement ruby1.8-dev ... Preparing to replace ruby1.8 1.8.7.352-2 (using .../ruby1.8_1.8.7.358-7_i386.deb) ... Unpacking replacement ruby1.8 ... Preparing to replace libruby1.8 1.8.7.352-2 (using .../libruby1.8_1.8.7.358-7_i386.deb) ... Unpacking replacement libruby1.8 ... Preparing to replace liblocale-ruby1.8 2.0.5-2 (using .../liblocale-ruby1.8_2.0.5-6_all.deb) ... Unpacking replacement liblocale-ruby1.8 ... Selecting previously unselected package ruby-locale. Unpacking ruby-locale (from .../ruby-locale_2.0.5-6_all.deb) ... Selecting previously unselected package ruby-text. Unpacking ruby-text (from .../ruby-text_1.0.3-1_all.deb) ... Selecting previously unselected package ruby-gettext. Unpacking ruby-gettext (from .../ruby-gettext_2.3.9-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/ruby-gettext_2.3.9-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man1/rmsgmerge.1.gz', which is also in package libgettext-ruby1.8 2.1.0-2.1 Preparing to replace libxml-parser-ruby1.8 0.7.1-1 (using .../libxml-parser-ruby1.8_0.7.2-2_all.deb) ... Unpacking replacement libxml-parser-ruby1.8 ... Selecting previously unselected package ruby-xmlparser. Unpacking ruby-xmlparser (from .../ruby-xmlparser_0.7.2-2_i386.deb) ... Preparing to replace libhttpclient-ruby1.8 2.1.5.2-1 (using .../libhttpclient-ruby1.8_2.2.4-2_all.deb) ... Unpacking replacement libhttpclient-ruby1.8 ... Selecting previously unselected package ruby-httpclient. Unpacking ruby-httpclient (from .../ruby-httpclient_2.2.4-2_all.deb) ... Preparing to replace apt-listbugs 0.1.4 (using .../apt-listbugs_0.1.9_all.deb) ... Unpacking replacement apt-listbugs ... Preparing to replace binutils-dev 2.21.52.20110606-2 (using .../binutils-dev_2.22-8_i386.deb) ... Unpacking replacement binutils-dev ... Preparing to replace binutils 2.21.52.20110606-2 (using .../binutils_2.22-8_i386.deb) ... Unpacking replacement binutils ... Selecting previously unselected package cpp-4.7. Unpacking cpp-4.7 (from .../cpp-4.7_4.7.3-4_i386.deb) ... Preparing to replace cpp 4:4.6.0-6 (using .../cpp_4%3a4.7.2-1_i386.deb) ... Unpacking replacement cpp ... Selecting previously unselected package libgcc-4.7-dev. Unpacking libgcc-4.7-dev (from .../libgcc-4.7-dev_4.7.3-4_i386.deb) ... Selecting previously unselected package gcc-4.7. Unpacking gcc-4.7 (from .../gcc-4.7_4.7.3-4_i386.deb) ... Preparing to replace gcc 4:4.6.0-6 (using .../gcc_4%3a4.7.2-1_i386.deb) ... Removing old gcc doc directory. Unpacking replacement gcc ... Preparing to replace gpm 1.20.4-1 (using .../archives/gpm_1.20.4-6_i386.deb) ... Unpacking replacement gpm ... Preparing to replace iucode-tool 0.8.3-1 (using .../iucode-tool_0.9-1_i386.deb) ... Unpacking replacement iucode-tool ... Preparing to replace tcsh 6.17.06-2 (using .../tcsh_6.18.01-2_i386.deb) ... Unpacking replacement tcsh ... Preparing to replace testdisk 6.11-1 (using .../testdisk_6.13-1_i386.deb) ... Unpacking replacement testdisk ... Preparing to replace intel-microcode 1.20120606.v2.2 (using .../intel-microcode_1.20130222.1_i386.deb) ... Unpacking replacement intel-microcode ... Processing triggers for man-db ... Processing triggers for menu ... Processing triggers for install-info ... install-info: warning: no info dir entry in `/usr/share/info/quelcom.info.gz' Errors were encountered while processing: /var/cache/apt/archives/ruby-gettext_2.3.9-1_all.deb localepurge: Disk space freed in /usr/share/locale: 6336 KiB localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB Total disk space freed by localepurge: 6336 KiB E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.39 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 ruby-gettext depends on: ii ruby 4.8 Transitional package for ruby1.8 iu ruby-locale 2.0.5-6 Locale library for Ruby iu ruby-
Bug#699076: live-initramfs: file overwrite install conflict with live-boot-initramfs-tools
Package: live-initramfs Version: 1.236.2-1 apt-cache show live-initramfs: " You probably do not want to install this package onto a non-live system, although it will do no harm." Yeah, right. (Reading database ... 370048 files and directories currently installed.) Unpacking live-initramfs (from .../live-initramfs_1.236.2-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/live-initramfs_1.236.2-1_all.deb (--unpack): trying to overwrite '/usr/share/initramfs-tools/hooks/live', which is also in package live-boot-initramfs-tools 3.0~a35-1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for initramfs-tools ... update-initramfs: Generating /boot/initrd.img-3.2.0-4-486 live-boot: core filesystems devices utils:memdisk udev wget blockdev. Errors were encountered while processing: /var/cache/apt/archives/live-initramfs_1.236.2-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) root@andinet:/home/andi# apt-cache show live-boot-initramfs-tools Package: live-boot-initramfs-tools Source: live-boot Version: 3.0~a35-1 Installed-Size: 63 Maintainer: Debian Live Project Architecture: all Replaces: live-boot-backend Provides: live-boot-backend Depends: busybox | busybox-initramfs, initramfs-tools, udev Conflicts: live-boot-backend Description-en: Debian Live - System Boot Scripts (initramfs-tools backend) live-boot contains the scripts that configure a Debian Live system during the boot process (early userspace). . This package contains the initramfs-tools backend. Homepage: http://live.debian.net/devel/live-boot/ Description-md5: 8ba60fe08aa09f645ad67d3032254b43 Section: misc Priority: optional Filename: pool/main/l/live-boot/live-boot-initramfs-tools_3.0~a35-1_all.deb Size: 23770 MD5sum: 9995b1b56597204d18162c6c8c5a3460 SHA1: 5d2b83c2a81585e15049bed22c3e197df6d9d7aa SHA256: 7f3eef83001f2c7251897fc714fc5a84afb02c90d65c1f465cb3df0bb133a9da # apt-cache show live-initramfs Package: live-initramfs Version: 1.236.2-1 Architecture: all Maintainer: Debian Live Project Installed-Size: 500 Depends: busybox, file, initramfs-tools, sudo, udev, user-setup Recommends: cryptsetup, eject, rsync, uuid-runtime, wget Suggests: loop-aes-utils, curlftpfs, genext2fs (>= 1.4.1), httpfs2, squashfs-tools, mtd-tools, unionfs-fuse Homepage: http://live.debian.net/devel/live-initramfs/ Priority: optional Section: misc Filename: pool/import/l/live-initramfs/live-initramfs_1.236.2-1_all.deb Size: 112366 SHA1: e8c6d4967cdbedca543ac8ffa78c2e9db1a7e61f MD5sum: 919b2e8472f255c08440be0fd312470c Description: Debian Live initramfs hook live-initramfs is a hook for the initramfs-tools, used to generate a initramfs capable to boot live systems, such as those created by live-helper. This includes the Debian Live isos, netboot tarballs, and usb stick images. . At boot time it will look for a (read-only) media containing a "/live" directory where a root filesystems (often a compressed filesystem image like squashfs) is stored. If found, it will create a writable environment, using aufs or unionfs, for Debian like systems to boot from. . You probably do not want to install this package onto a non-live system, although it will do no harm. . live-initramfs is a fork of casper <http://packages.ubuntu.com/casper/>. This happened while doing a full Mint 12.04 LMDE LXDE 32bit reinstall trying to recover from fatal usb storage reboot non-flush data corruption (quite likely kernel issue, f*ck). I installed base ISO, completed a dist-upgrade, then grabbed the package list of the previous broken install and installed all of those packages that were installable, and at this step things failed. Possibly something is missing a Conflicts: header somewhere, or something else? Thanks! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698644: mobile-broadband-provider-info: critical search keyword missing (APN)
Package: mobile-broadband-provider-info Version: 20120708-1 Severity: wishlist Hi, doing an "apt-cache search APN" does NOT end up listing the mobile-broadband-provider-info package, which is somewhat of a shame since APN (Access Point Name) is the very usual naming convention, thus many users will lose time trying to locate the package. I therefore strongly recommend to change the existing package description from Description-en: database of mobile broadband service providers This package contains database of service provider specific settings of mobile broadband providers in different countries. Its functioning through Network Manager makes it easy for users to choose their mobile broadband service provider. to something like: Description-en: database of mobile broadband service providers This package contains database of service provider specific settings (e.g. APN) of mobile broadband providers in different countries. Its functioning through Network Manager makes it easy for users to choose their mobile broadband service provider. If this description is originating from upstream, then it should obviously be fixed there as well. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631245: lynx-cur postinst fails due to old diversion by lynx-ssl
Hi, > I think you are right. > You might already done so but do the followings fix > the problem? > > dpkg-divert --remove --rename --divert /usr/bin/lynx.nossl /usr/bin/lynx > dpkg-divert --remove --rename --divert /usr/share/man/man1/lynx.nossl.1.gz > /usr/share/man/man1/lynx.1.gz I do have a methusalem installation (prior to 1997 I believe), and I did have the /usr/bin/lynx.nossl diversion, and doing these two suggestions (followed by purge of lynx and lynx-cur) was the part that finally fixed an apt-get install lynx run. Probably the only thing that's left to wonder now is whether there's something useful to be done about this upgrade issue programmatically, or whether this bug report's content is sufficient documentation for this ancient fact. Thank you for your input! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#278442: #278442: RFH: athcool -- Enable powersaving mode for Athlon/Duron processors
Hi, JFTR: still have an EPOX 8K5A2+ (KT333CE?) with some kind of Athlon XP. athcool enabled on startup, working at least 95% fine (I think I did experience some sound crackling, but everything seems fine now). Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#662046: manpages-dev: mbsrtowcs() (et al.) is an accident waiting to happen (mbstate_t)
Package: manpages-dev
Version: 3.35-0.1
Hi,
sorry for the loaded title, but that's simply how I'm feeling right now
about this (admittedly not really on the side of manpages-dev) issue.
I'm somewhat semi-appalled about the state (pun intended) of
mbsrtowcs().
- man mbsrtowcs does not mentioning ANYTHING about the heavy
(and sufficiently non-sequitur, see below)
initialization requirements of mbstate_t *)
- http://www.gnu.org/software/libc/manual/html_node/Keeping-the-state.html
finally does explain it, but it also says
"There is no specific function or initializer to put the state object
in any specific state."
I would guess that this is because it's the _standard_ which did not
originally define such a function. Which really is a shame
since expecting people to be using a dirt-ugly open-coded memset()
(not domain-specific, easily haywireable length argument, ...) on mbstate_t
in light of even providing a clean mbsinit() to _query_ the state
seems to be fr _dirty_ and _asymmetric_ handling
of mbstate_t lifetime.
Besides, one could even postulate that mbsrtowcs() ought to be (have been...)
the one to fully "own" (thus initialize/maintain) the state,
since it's doing a complete, well-formed operation on the string,
from beginning to end.
Thus for me there doesn't appear to be much of a reason for mbsrtowcs()
to (historically) not initialize the foreign variable.
mbstate_t simply is a helper (an opaque memory location) to achieve
proper isolation of program state (per-thread etc.).
BTW, the GNU-specific introduction of mbsnrtowcs() (to work around
problems) indicates that design of the mbs*() API standard
appears to have a history of problems...
*)
on a more modern system (libc-bin 2.13-18),
with uninitialized (random) mbstate_t you get:
mbsrtowcs: mbsrtowcs_l.c:148: __mbsrtowcs_l: Assertion
`((data.__statep)->__count == 0)' failed.
On an older (well, medieval) RHEL5,
you get nothing (other than a very buggy app...), except for:
==18039== Conditional jump or move depends on uninitialised value(s)
==18039==at 0x4EC279A: gconv (in /usr/lib/gconv/EUC-CN.so)
==18039==by 0x5880BB: __mbsrtowcs_l (in /lib/libc-2.5.so)
==18039==by 0x57D4C9: mbsrtowcs (in /lib/libc-2.5.so)
...
==18039== Uninitialised value was created by a stack allocation
iff you've been wise (the pessimist would say: burnt...) enough
to now actually do some Valgrind runs from time to time.
The corresponding test app is:
#include
#include /* memset() */
#include // stdout
void main () {
wchar_t arrW[256];
const char *testA = "Hello World\n";
const char **ptr_test = &testA;
mbstate_t mbs;
//memset(&mbs, 0, sizeof(mbs));
mbsrtowcs(arrW, ptr_test, sizeof(arrW)/sizeof(*arrW), &mbs);
fwprintf(stdout, L"%ls", arrW);
}
So, after a long and tiresome tirade, what actually can be done about it?
I'd say the acceptable minimal solution would be to enhance mbsrtowcs()
dox to not fail to mention these crucial init requirements
(but probably there are certain other function dox with the same requirement?).
Perhaps there should be a man page specifically for mbstate_t even!?
So, unless we want "every third" user of mbsrtowcs(3)
to get it wrong, fatally, the documentation should be extended.
A sample phrase would be
"for mbstate_t parameter init, there's no initializer function
defined by the standard - the user is required to have done a proper memset()
on it."
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658338: rocksndiamonds: could provide download traffic warning at game selection screen
Package: rocksndiamonds Version: 3.3.0.1+dfsg1-2 Severity: wishlist Hi, it would be very useful to have a download traffic warning displayed on the main game selection screen, since I was a bit shocked to see some level files downloaded from artsoft.org to be in the 20MB range (which is a medium PITA from a thoroughly remote location such as China). Sample traffic warning text: "Note that each level file can be up to 20MB in size - select less games if you want to reduce download time / server traffic / client traffic." Thanks! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613068: Could not connect, passive socket
Same issue on Debian stable _mips_: Reading package lists... Building dependency tree... Reading state information... The following packages were automatically installed and are no longer required: ... Use 'apt-get autoremove' to remove them. The following extra packages will be installed: liblwres60 Suggested packages: rblcheck krb5-doc libschroedinger-dev libx11-dev libxext-dev libraw1394-dev libdc1394-22-dev cups-common krb5-user Recommended packages: asterisk The following packages will be upgraded: asterisk-config asterisk-sounds-main bind9-host dnsutils krb5-multidev libavcodec-dev libavcodec52 libavutil-dev libavutil49 libbind9-60 libcups2 libdns69 libgssapi-krb5-2 libgssrpc4 libisc62 libisccc60 libisccfg62 libk5crypto3 libkadm5clnt-mit7 libkadm5srv-mit7 libkdb5-4 libkrb5-3 libkrb5-dev libkrb5support0 liblwres60 25 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 10.6 MB of archives. After this operation, 4096 B of additional disk space will be used. Do you want to continue [Y/n]? Get:1 ftp://security.debian.org/debian-security/ squeeze/updates/main libkrb5-dev mipsel 1.8.3+dfsg-4squeeze5 [37.6 kB] Err ftp://security.debian.org/debian-security/ squeeze/updates/main libkrb5-dev mipsel 1.8.3+dfsg-4squeeze5 Could not connect passive socket. [IP: 200.17.202.197 21] Get:2 ftp://security.debian.org/debian-security/ squeeze/updates/main krb5-multidev mipsel 1.8.3+dfsg-4squeeze5 [104 kB] Err ftp://security.debian.org/debian-security/ squeeze/updates/main krb5-multidev mipsel 1.8.3+dfsg-4squeeze5 Could not connect passive socket. [IP: 200.17.202.197 21] ... E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? ii apt 0.8.10.3+squeeze1Advanced front-end for dpkg ii apt-listbugs 0.1.3tool which lists critical bugs before each apt installation ii apt-utils 0.8.10.3+squeeze1APT utility programs ii aptitude 0.6.3-3.2+squeeze1 terminal-based package manager (terminal interface only) ii libapt-pkg-perl 0.1.24+b1Perl interface to libapt-pkg ... ii python-apt0.7.100.1+squeeze1 Python interface to libapt-pkg ii python-apt-common 0.7.100.1+squeeze1 Python interface to libapt-pkg (locales) Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629983: libc6 install aborts with "A non-dpkg owned copy of the C library was found in /lib."
On Wed, Jun 29, 2011 at 10:48:49AM -0500, Jonathan Nieder wrote: > Hi Andreas, > > Andreas Mohr wrote: > > > Don't tell me that this upgrade just successfully and singlehandedly > > broke any and all libc4/5 compat... (not that I personally would still much > > rely on that at this moment ;-)). > > This upgrade indeed broke libc4/5 compat. If there is anyone still > using it (you?), my hunch is that the best thing to do is to get in > touch with us and we can work on an unofficial package to get it > working again using the new paths with in the name. > Supporting installations with libc installed at two paths would be > much more painful. If I still had that main Debian gateway which had been running since 1996 (usability-killed recently, by boot/network setup complications after that ill-fated Squeeze upgrade, read: dead box at a most unwelcome time), then I'd have remained happy to use the binary-only estic config app for ISTEC PBXes. And the other box won't be available to run it either (has been breakage-converted to Windoze 7 e.g. due to annoyances caused by idiotic Firefox (and thus: iceweasel) versioning incompatible with similarly idiotic versioning expectations of the banking site [but sure, they'll readily support IE6]). Apart from that, no more use cases for libc5 stuff here. Since you appear to say that current status is official breakage of libc4/5, the (very confusing) abort message should best be reworded to indicate that this applies to "officially" managed binaries as well (e.g. ldso package etc.) and not just rogue manually installed ones. And perhaps even directly indicate that 4/5 support is currently not offered any more, which is the reason for the conflict. Thanks a lot for your support! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629983: libc6 install aborts with "A non-dpkg owned copy of the C library was found in /lib."
Judging from my upgrade experience I'd now say that the entire handling to me seems pretty much solidly wrong. I believe that I (as opposed to some other people?) _do_ have (almost) all files properly dpkg-managed, by the ldso package. Package: ldso Status: purge ok installed Priority: required Section: base Installed-Size: 188 Maintainer: David Engel Source: ld.so Version: 1.9.11-15 Replaces: libc6 Provides: libdl1 Depends: libc6 (>= 2.1.94) Description: The Linux dynamic linker and library for libc4 and libc5. This dynamic linker provides the user-level support for loading and linking DLL and ELF shared libraries. You do not need this package unless you have very old programs which use libc4 or libc5. The libc6 package has its own dynamic linker that is used for all current programs. The only file that was "actually" rogue was /bin/ld.so, and even moving away that single remaining non-managed file did not suffice to satisfy the (woefully incorrect?) preinst check. Thus I had to FORCEFULLY remove files belonging to the ldso package to make the upgrade proceed. I'm now having severe questions about glibc upgrade at this package version and especially its compatibility versus a pre-installed and existing ldso package (which is to be used for __FOREIGN__ purposes such as libc4/5 compat!!). Hrm... Don't tell me that this upgrade just successfully and singlehandedly broke any and all libc4/5 compat... (not that I personally would still much rely on that at this moment ;-)). [note that I recently changed package status to "purged" - which was ultimately unsuccessful since ldso is obviously required by the properly installed libc5 package] Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629983: libc6 install aborts with "A non-dpkg owned copy of the C library was found in /lib."
IIUC something is still amiss with this stuff: Preparing to replace libc6 2.13-2 (using .../archives/libc6_2.13-7_i386.deb) ... A non-dpkg owned copy of the C library was found: '/lib/ld-linux.so.1.9.11' It is not safe to upgrade the C library in this situation; please remove that copy of the C library or get it out of '/lib' and try again. dpkg: error processing /var/cache/apt/archives/libc6_2.13-7_i386.deb (--unpack): subprocess new pre-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: /var/cache/apt/archives/libc6_2.13-7_i386.deb OK so it says "non-dpkg owned", _and_ now mentions the exact file after that has been properly complained about by other people in this bug. Well, doing this on the very file mentioned in the output: # dpkg -S /lib/ld-linux.so.1.9.11 ldso: /lib/ld-linux.so.1.9.11 Ermm... HOWEVER, doing: # dpkg -S /lib/ld.so dpkg-query: no path found matching pattern /lib/ld.so. Am I right in that the check has a list of ld.so binaries and on error condition brainlessly dumps the first one it contains, no matter whether that's the culprit or not? Might want to refine that printout logic... (and especially since it's crucial that users get the name of the to-be-removed file right, otherwise --> pile of smoke) Here, the configuration is as such: # ls -l /lib/ld* -rwxr-xr-x 1 root root 117960 May 2 12:19 /lib/ld-2.13.so* lrwxrwxrwx 1 root root 18 Jun 7 2003 /lib/ld-linux.so.1 -> ld-linux.so.1.9.11* -rwxr-xr-x 1 root root 24817 Mar 7 2001 /lib/ld-linux.so.1.9.11* lrwxrwxrwx 1 root root 10 May 9 22:39 /lib/ld-linux.so.2 -> ld-2.13.so* -rwxr-xr-x 2 root root 99568 Mar 7 2001 /lib/ld.so* -rwxr-xr-x 2 root root 99568 Mar 7 2001 /lib/ld.so.1.9.11* Confused users will rightfully ask the questions: - whether to plainly remove (rename-away) all non-dpkg-managed files and only those - which files exactly these are supposed to be - whether these former files will then be automatically replaced with some symlinks or so (not so important though) Thanks for some very nice work! (15 years and counting on this box) Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516214: Charachter ' produce error in ~/.Xresources
Seconded. Just found the same issue in my ~/.xsession-errors (and thus ~/.Xresources ) about last week. Version 0.69 here as well. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624079: udev: should probably protect against silent yet fatal failure (check and verbosely announce incorrect CONFIG_* setup)
Hi, On Mon, Apr 25, 2011 at 09:22:13PM +0200, Marco d'Itri wrote: > On Apr 25, Andreas Mohr wrote: > > > While the current init script version does check for some prominent > > environment setup items, at least on my system given my custom-built > > kernels I violated README.gz items CONFIG_SYSFS_DEPRECATED (ouch), > This one is checked in preinst and it aborts the upgrade if you are > running the lenny kernel and not upgrading it at the same time. Indeed, I've already been wondering about this: I didn't have _any_ Debian-provided kernel installed any more, and I (thus obviously) did _not_ get the kernel package upgraded in one go, too. Yet it seems udev did get upgraded up to a version with incompatible requirements anyway. (most likely because I was missing the standard Debian kernel package which would have that compatibility check activated in the first place? ;-P) Unfortunately I did not run an upgrade script, thus I don't have any log of the upgrade procedure, but I'm afraid this is what may have happened. > Newer kernels removed the compatibility links which the check tested, > but I improved it in 167-3. > So I am not sure that it would be useful to repeat the check in the init > script, and I think that it could make some upgrade scenarios much > harder to handle. The check in the init script could simply be a passive check with a warning message, but indeed it's questionable whether this would be useful. Much better to try to figure out a way to prevent the upgrade situation that it seems I had from occurring in the first place. > > > CONFIG_TMPFS_POSIX_ACL and CONFIG_BLK_DEV_BSG. > Do you know a cheap way to test for these? Anyway, lack of these > features is not supposed to cause problems except for sound and tape > devices. Thought so (especially since they are found at the bottom of the list). I'm currently attempting to recover from this problem (doing some minor network setup emergency hardcoding, installed standard Debian kernel and migrated to libata-compatible configuration, building my own corrected kernel, ...). Thank you very much for your fast reply! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624079: udev: should probably protect against silent yet fatal failure (check and verbosely announce incorrect CONFIG_* setup)
Package: udev
Version: 164-3
I (like some other people) am having a hell of a time trying to get
a Squeeze upgrade working. I've been trying to read up on and figuring out
during the last 4 hours why 70-persistent-net.rules does
a) not get processed any more (since Squeeze upgrade - obviously was
working properly previously given its effects)
b) not get created any more on boot, if removed, no matter whichever
things are being attempted
Result was loss of routing for the main router
due to mismatching interface names in /etc/network/interfaces...
Since udev, due to being a central part of the system,
has a rather abnormally large list of dependency requirements
which may easily cause problems, IMHO the udevd start script itself should best
invoke a checking helper function/script to verify that all/most
currently required (as listed by doc...README.gz) CONFIG_* options
are available (and ideally there would also be a note requesting
the two configuration lists/checks in script/README to be kept in sync).
While the current init script version does check for some prominent
environment setup items, at least on my system given my custom-built
kernels I violated README.gz items CONFIG_SYSFS_DEPRECATED (ouch),
CONFIG_TMPFS_POSIX_ACL and CONFIG_BLK_DEV_BSG.
Despite all this, 3 udevd processes got _successfully_ launched,
and even low-level analysis steps don't show many bumps
other than a potentially(!) relevant ECONNREFUSED on strace udevd
(and udev.conf log level debug doesn't seem to do much either).
I tried to have persistent-net rule created manually via
for NIC in /sys/class/net/eth0; do INTERFACE=${NIC##*/}; echo $INTERFACE;
udevadm trigger --action=add $NIC; done
(supplying both trigger and test arguments)
Also, trying to log env and a start message in /lib/udev/write_net_rules was
unsuccessful, too, more or less proving that that script never got started
at all.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572951
sounded somewhat relevant, however that bug was closed quite early
unfortunately.
https://bugzilla.redhat.com/show_bug.cgi?id=557771 might be related,
too.
All in all there's too much silent failure occurring, there should be
additional and more verbose checks against an incomplete/wrong setup,
ideally both in init script and udevadm invocation processing.
Especially since IMHO there's quite a lot of (read: too much?)
compatibility pressure between kernel and udev configuration/versioning.
I'll now revert to installing a standard Debian kernel with currently
fashionable settings ;)
(and make oldconfig:ing further custom kernels based on a _current_ .config);
this should hopefully correct these problems.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622309: 167-3 works fine on EEEPC though
> Md> Try to rm -rf /run and reboot. > OK, thanks! I will try it on Monday. No you shouldn't. ;) mv /run /run.old_possibly_broken Otherwise you'd destroy a large amount of criminal evidence :) (and then perhaps run a diff -urN on the two directories, or some comparational debug invocation of rsync, or some such) Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623961: xserver-xorg-input-evdev: X11 "mouse keys" / "plot mode" completely unusable post-Lenny, on 3 machines
Hi, On Sun, Apr 24, 2011 at 10:28:08PM +0200, Cyril Brulebois wrote: > Hi, > > Andreas Mohr (24/04/2011): > > Package: xserver-xorg-input-evdev > > Version: 1:2.3.2-6 > > Severity: grave > > Justification: use of entire desktop almost impossible, occurring on 3 > > quite different hardware environments > > why did you strip the bug script output? 'cause I had used the human script "variant" ;) > I'd suggest tracking it down on your sid machine, so that we can get > upstream feedback with failures reported against latest versions. See > the proposed backports policy[1], you could then enjoy a backported > fixed version at some point on your squeeze machine. Will do ASAP, as circumstances allow. Thanks for a very fast reply! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623961: xserver-xorg-input-evdev: X11 "mouse keys" / "plot mode" completely unusable post-Lenny, on 3 machines
Package: xserver-xorg-input-evdev Version: 1:2.3.2-6 Severity: grave Justification: use of entire desktop almost impossible, occurring on 3 quite different hardware environments Hi, on one notebook where I had some rare intermittent touchpad failure I temporarily had to resort to "mouse keys" mode (see http://en.wikipedia.org/wiki/Mouse_keys ). However, I observed that it didn't work on that machine (Debian unstable), whereas on the machine that _now_ starts to have the same issue (MEPIS 11 - Debian Squeeze) it did work perfectly well. To clarify "didn't work": When enabling mouse keys via Alt-Shift-NumLock, I do get some cursor movement activity, however it's VERY erratic / distorted (cursor progresses in - also erraticely updated - steps of perhaps up to one inch each, i.e. even semi-precise navigation is impossible). Thus current behaviour is almost unusable compared to a previously fully working setup with nicely linearly updating mouse cursor. I managed to figure out that actual internal X11 cursor position _does_ get precisely updated, however: by Alt-Tabbing between some windows, one observes that the cursor does in fact properly make tiny jumps corresponding to previous minor mouse keys activity, but this unfortunately means that Alt-Tabbing is REQUIRED to make it do so properly (thus one would have to do a couple dozen Alt-Tabs to finally approach the precise cursor position to be able to Hit-Test a button rectangle _each time_). I had actually planned to submit a bug report about it previously already, and since I now hit the same issue on the third machine (where I never had a mouse connected) during upgrade, it's finally about damn time to do so ;) Machine 1 (Debian unstable): Notebook Dell Inspiron 8000, Rage Mobility M4 Machine 2 (upgraded to MEPIS 11): HP ePC, P3/1GHz, Intel i815 Machine 3 (Debian testing(?)): Athlon XP, also not working properly any more IIRC, Radeon (R100 or some such) I didn't find much information about this bug (X11 "mouse keys" are such damn fine search keywords, almost as good as"KVM"...), only a current report of "No more Xorg Mousekeys" https://bbs.archlinux.org/viewtopic.php?pid=904880 which is actually unrelated since I _do_ have (barely) working cursor activity, thus it is properly flag-enabled at least. Not sure whether the xserver-xorg-input-evdev component is the correct one to report it at, though (since the X11 server actually does record the correct cursor position, perhaps this would be more of a server-side or display-side component issue?). The pre-upgrade version of -input-evdev was 1:2.0.8-1 . At this upgrade: xserver-xorg-core: 2:1.4.2-10.lenny3 --> 2:1.7.7-13 xserver-xorg: 1:7.3+20 --> 1:7.5+8 As far as I am concerned, a rather important base feature of X11 is thus unusably broken. Is there any info yet, or ideas on current status and how to get it fixed? Thanks a lot for all your work, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#623926: desktop-base: .postinst failure (refers to relocated/removed debblue-1600x1200.png etc.)
Package: desktop-base Version: 5.0.3 Hi, on a MEPIS 8.5 (lenny) system, I get: Setting up desktop-base (5.0.3) ... update-alternatives: error: alternative path /usr/share/images/desktop-base/debblue-1600x1200.png doesn't exist. dpkg: error processing desktop-base (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: desktop-base This seems to be because according to #500377 , debblue got moved into gdm-themes which I don't actually have installed here (XFCE / kdm combo). Testing whether gdm-themes install will fix it... [12.6MBs of super-dozen dependencies installing] ...no, that did not fix that configuration failure. Reviewing #500377 makes it obvious that that report was about a gdm-themes-side _symlink_ only, it does not actually provide that file. IOW, we have a quite problematic dependency issue, and .postinst simply needs to be fixed to not refer to debblue any more (most likely a step that has been forgotten during the debblue file's package relocation). Manually removing the reference lines from .postinst makes postinst complete successfully. These were the lines debblue , debian-background.svg , bluedeb-1024x768 , Debian.jpg , Splash-debblue.png , Splash-Debian , Splash-Debian_red . This issue should hopefully be reproducible by: - (perhaps running Lenny? [ouch]) - making sure that gdm-themes is removed from the system - apt-get install --reinstall desktop-base Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#414199: Configuring capiutils fails when no capifs available
Hi, happens for me as well, now on presumably slightly newer 1:3.9.20060704+dfsg.2-4.1. Setting up capiutils (1:3.9.20060704+dfsg.2-4.1) ... Note: running MAKEDEV to create CAPI devices in /dev... .udevdb or .udev presence implies active udev. Aborting MAKEDEV invocation. mount: unknown filesystem type 'capifs' invoke-rc.d: initscript capiutils, action "start" failed. dpkg: error processing capiutils (--configure): subprocess installed post-installation script returned error exit status 32 Errors were encountered while processing: capiutils Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618743: qemu-system: Tap interface doesn't work anymore
Turns out that dash 0.5.4-12 is NOT affected. Re-upgrading to current 0.5.5.1-7.4 package then makes it lock up again. Non-sudo-prefixed lines (e.g. tested via echo, ls, find, ...) in the script work fine, it's specifically sudo-based commands which are problematic. Note that manually executing a test script such as #!/bin/sh /usr/bin/sudo echo Hi /usr/bin/sudo whoami does terminate properly, when executed as the same user that kvm would execute the scripts as (and when indeed having dash-as-sh). Thus it appears that _something_ about the way that kvm sets up its startup shell scripts context makes things break, i.e. within kvm only. Thus I'm keeping this bug filed under qemu-system instead of reassign dash 0.5.5.1-7.4, for now. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618743: qemu-system: Tap interface doesn't work anymore
Hi,
On Wed, Mar 30, 2011 at 05:53:48PM +0200, Christian Marillat wrote:
> Andreas Mohr writes:
> > dpkg-reconfigure dash, reverting to bash (which I normally never do,
> > since it's all working perfectly fine provided one knows to avoid
> > bashisms - devscript package's checkbashism script - in custom
> > scripts) finally makes it work again.
>
> I think the best/more easy is to change the shebang for the
> /etc/qemu-ifup script.
Definitely easier, but... IMHO the problem should be squashed if at all
possible instead of having this workaround (and you can bet some Debian
maintainer would inadvertently switch it back within months ;)).
> > So, I don't know _why_ on dash it gets stuck (possibly due to specific
> > shell execution environment limitations as imposed by kvm startup??),
> > but IMHO such a strange issue should be investigated ASAP
> > (also since dash appears to be the new default).
>
> Would be nice to know why sh still works with qemu 0.9.1 and not with
> the latest qemu.
OK, so we have data point:
- worked on 0.9.1
And I can add:
- could be sudo-related ("echo" or "test" commands in the script
don't hang) - but this could instead be a more global "shell builtins working"
vs. "external commands hanging" issue...
Will nail this data point down soon (once I can test again).
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618743: qemu-system: Tap interface doesn't work anymore
Hello Christian (and tons of Packaging Thanks! :), same issue here. Turns out this line > Shell: /bin/sh linked to /bin/dash was the most important one in your report. When using dash, _EVERY_ _SINGLE_ _PROCESS_ as spawned by dash from within that kvm-launched kvm-ifup script ends up as defunct == zombie. I finally got that Aha! moment when kill -9'ing the currently stuck process and fortunately realizing that it proceeded with executing the subsequent shell line script process and got stuck again. dpkg-reconfigure dash, reverting to bash (which I normally never do, since it's all working perfectly fine provided one knows to avoid bashisms - devscript package's checkbashism script - in custom scripts) finally makes it work again. So, I don't know _why_ on dash it gets stuck (possibly due to specific shell execution environment limitations as imposed by kvm startup??), but IMHO such a strange issue should be investigated ASAP (also since dash appears to be the new default). Myself, I'm executing kvm as non-root user, BTW (not sure at all whether that actually makes any difference here, though). Side note: Gaad, I really hate having to experience odd little thoroughly annoying kvm setup quirks on almost every friggin' single §%&damn kvm upgrade I do. Oh well, at least _this time_ again it's working again ;) HTH, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607136: initscripts: mountkernfs.sh: illegal handling of _non_-virtual filesystems (RAMRUN mode), leading to multiple daemon startup failure
Package: initscripts
Version: 2.86.ds1-61
I kept wondering why openvpn failed on each bootup attempt every couple of
weeks.
Now I know that this is because mountkernfs.sh illegally attempts to
additionally handle RAMRUN mode:
# Mount /var/run and /var/lock as tmpfs if enabled
if [ yes = "$RAMRUN" ] ; then
RUN_OPT=
[ "${RUN_SIZE:=$TMPFS_SIZE}" ] && RUN_OPT=",size=$RUN_SIZE"
domount tmpfs "" /var/run varrun -omode=0755,nosuid$RUN_OPT
touch /var/run/.ramfs
fi
if [ yes = "$RAMLOCK" ] ; then
LOCK_OPT=
[ "${LOCK_SIZE:=$TMPFS_SIZE}" ] && LOCK_OPT=",size=$LOCK_SIZE"
domount tmpfs "" /var/lock varlock
-omode=1777,nodev,noexec,nosuid$LOCK_OPT
touch /var/lock/.ramfs
fi
IMHO mountkernfs.sh is so early in bootup stage that it shouldn't
have any business dealing with _any_ directory components which are non-virtual.
Probably someone misplaced this RAMRUN stuff since he thought that RAMRUN is a
virtual
fs (tmpfs), however the intent of mountkernfs.sh IMHO is not so much about the
_type_
of file system that is being processed, but about the _destination_ of the mount
(namely, being fully virtual on a _root_-partition-based mount point).
In my case of a flash-based server I have a mount that I have /var as a
_symlink_ pointing to
(yes, I know, bad dog, no cookies).
However I'd say simply deciding to mount /var as an extra partition
(a fully legal and often-implemented way) is entirely equivalent to my symlink
HACK,
since both methods would make /var available at the same time during bootup.
And that's simply not at that point in time when mountkernfs.sh RAMRUN parts
already attempt to do their tweaking.
mountkernfs.sh very early --> no /var tree (mount or directory) available -->
RAMRUN tmpfs mount fails
--> usual persistent /var/run directory will appear somewhat later
--> /var/run cleanup will get skipped by mountall-bootclean.sh due to simple
RAMRUN=true check
--> stale PID files left in /var/run --> FUBAR
Conclusion: RAMRUN parts should not get handled at dangerously early
mountkernfs.sh stage due to
/var tree involvement.
Or RAMRUN would have to state a "fixed /var tree" requirement - but in such a
case
the mountall-bootclean.sh /var/run cleanup check should not be done simply
based on
having RAMRUN set to true, but instead on whether it's _actually_ tmpfs-based
or not.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#475580: [flashplugin-nonfree] Check for updates regularly
Seconded. It could easily be considered unacceptable to have a single
piece of an otherwise entire quite properly updated distribution remain
woefully stale.
Especially since Flash is known to be at the very top of the
most problematic attack vectors.
IMHO simply tagging this bug as wont-fix is a bold cop-out.
I'm starting to wonder whether I should have CC'd debian-security on
this ;)
Personally, I have several systems which use (are forced to use...)
Flash via flashplugin-nonfree and where admittedly I did not have the
faintest idea that it would eternally remain stale unless running
update-flashplugin-nonfree --install.
("oh, you didn't read docs!?" "what docs, you mean all the
`dpkg -l|wc -l` ones??")
The reasoning that only the local admin should be the one to decide
when to do an update or not may be considered ok given Flash's reliability
issues.
Thus IMHO a good (and necessary!) compromise would be to state something
to the effect of
"Please note that further version upgrades of Flash will NOT be executed
automatically. We expect the local administrator to be the one to decide when
it is appropriate to update. This can be done by running
update-flashplugin-nonfree --install"
, on every single install and upgrade of the flashplugin-nonfree
package.
That's the minimum that should be done, IMHO, since one strays so far
from (admittedly assumed) usual Debian best practice by not updating at all.
Also, right now purging and reinstalling flashplugin-nonfree does not print
even a single explanatory line (could be caused by some of my local debconf
settings, but I doubt it).
OTOH this still doesn't seem kosher. An IMHO much better practice would
be to have a local configuration, the default setting of which
_does_ automatically upgrade the flash binary on every upgrade of the package,
and to state something to that effect on package install/upgrade,
e.g. combined with "to disabled forced upgrades (thus rendering timely
security upgrades the responsibility of the local admin), see config
switch yadda-yadda".
(hmm, but this might give way to a DoS on Adobe servers after all)
And Steven Hudson: this is exactly the problem which a cron-based
implementation would excel at causing ;)
If thoughtless re-upgrading on every upgrade is considered to be a problem,
then one should stamp the currently downloaded file and compare attributes
before re-downloading.
The more I think of that the more convinced I am that the current less
featureful mode of operation is a bad thing, e.g. due to my reasons
given initially.
So, what could be done about this? Since Flash support is such a damn
important part (unfortunately), I may be willing to implement such a solution
over the xmas break, given that I've had major Flash support trouble
for years on the Debian platform (do I use Flash, do I use
flashplugin-nonfree, do I use flashplayer-mozilla, should I try to use
gnash, no that's too immature, ah it improved, no, still not quite
there, back to Flash via flashplugin-nonfree oh what a CPU hog,
...).
Since Bart indicates that update frequency is a delicate matter (which
is very understandable), this might leave us with adding
a proper explanation to each package upgrade. And (I'm repeating myself ;)
this is the minimum that __should__ be done.
Oh well, thanks, and thank you for providing a very important package!
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600681: Houston... (Debian Abandonware browser Iceweasel 3.5.x actively blocked by major sites now)
Package: iceweasel Version: 3.5.13-1 Severity: important Justification: major user-facing component of a system is unusably outdated (missing OFFICIAL support, of security updates etc.) Keywords: Firefox Iceweasel 3.5 outdated unsupported deprecated For about 3 weeks now already, bw-bank.de has been actively blocking online banking access for Firefox versions <= 3.5.x. The problem is that I'm online with a Debian system as updated as can be (Debian stable base, security, even plus backports). The version that it offers is 3.5.12-2~bpo50+1 . I know the history of why 3.5.x has been decided to remain in Debian (issues with updating of XUL dependencies, as explained in http://bugs.debian.org/591500 ). Mozilla is said to have ceased support for 3.5.x in August 2010 already (see http://de.wikipedia.org/wiki/Mozilla_Firefox ). (the IDIOTIC Mozilla source versioning development has been bitterly and thoroughly complained about in an online article a couple months ago which I cannot locate any more currently, which pinpointed EXACTLY the major issues that distro people would face once security update support was very prematurely closed down). Probably the decision-making at that bank is a sort of reptile-minded "is it a vendor-supported version?". This probably explains why even internet browser ZOMBIE IE6 is still supported (Secunia statistics of IE8 vs. FF 3.5 vs. IE6 are eye-opening). So, who is to take the blame? I'd say it's Mozilla by far. And then we have a very much overly eager deprecation by the bank (blocked a mere month after official support ended, for a browser version which got introduced on June 30th 2009 only). But a large share of the problem lies on Debian as well, since NOT EVEN UNSTABLE has a less-than-historic Firefox version (http://packages.debian.org/search?keywords=iceweasel ). And even Backports doesn't help either (one needs to go to experimental to even get a glimpse of 3.6.x!). Note that an analysis of distrowatch.com package versions shows that usually the second-last release version of distros (MEPIS, MINT, openSUSE, Mandriva, Fedora) already progressed towards 3.6.x, EXCEPT for Debian. Even the rabidly conservative RHEL5.5 (which I have to work with most of the time) is now at Firefox 3.6.x (.8, IIRC). Hence this IMHO critical bug report. We're talking of a major system component (some users are spending > 90% of their time with browser use) which is starting to be unusably outdated, and even the most conservative other distros have updated their packages. IMHO this should serve as a wakeup call. Now, which direction to go to? Probably Backports would be the best place to act on this. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570662: [PATCH] add missing include for ia64 and alpha
On Wed, Oct 13, 2010 at 11:06:51PM +0200, Serafeim Zanikolas wrote: > [please CC me on replies; I'm not subscribed] > > Hi, > > Here's a fix for Debian bug #570662 (FTBFS: error: '__NR_perf_event_open' > undeclared) #if defined(__ia64__) || defined(__alpha__) ;) And was that __NR_perf_event_open thing the one that I was having issues on MIPS? Hmm, need to verify... Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570662: powertop: FTBFS: error: '__NR_perf_event_open' undeclared
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570662 > # still fails on alpha and ia64: > # https://buildd.debian.org/status/package.php?p=powertop Confirmed, dito on Git MIPSEL (WL-500gPv2 OpenWrt 2.6.34.5 Debian stable extroot). Would have tried to fix it myself (patch --> upstream), but saw that Debian had some activity at #570662. Checked Debian source files, couldn't find all too much overly useful stuff (read: NONE). Bit wondering why buildd status page advertises mipsel as "installed", though, since Git did fail for me at __NR_perf_event_open. Config deviations?? Ping? Suitable CC's added. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593966: libc6: system-breaking (init OOPS) incompatibility with old prelink versions
Actually I'm not sure any more whether this is "a __severe__ problem for a branch-hopping minority(?) only": Boyd Stephen Smith Jr. realized that this might very well become a problem for "normal" branch upgrades from Lenny to Squeeze. If Squeeze libc6 upgrade processing happens before the upgrade of the prelink binary (and I think it does, since I believe libc6 upgrades happen rather early during an upgrade operation, before many other packages), we're ending up with the critical constellation during a normal upgrade as well. And since on a P3/500/512, a full Ubuntu upgrade I did once took >> 8 hours (possibly even longer with more modern installations), due to the slow performance there's a rather high chance to hit the cron.daily 24 hour processing's race window. Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593966: libc6: system-breaking (init OOPS) incompatibility with old prelink versions
Package: libc6
Version: 2.11.2-2
Severity: critical
Justification: breaks the whole system (repeatedly, in a timebomb manner)
Hi,
beginning of August my intention was to upgrade a system (AMD64 i386
stable; libc6-i686 installed additionally) to KDE 4.4.x.
I chose to do this by temporarily switching to testing repository.
All went more or less fine, except for suddenly ending up with all
shell binaries segfaulting. A reboot resulted in /sbin/init dying with
a nice kernel OOPS. Full stop.
Found #586241 (somewhat related issue), which recommended dpkg-deb:ing
over the libc6 / libc6-i686 libraries to restore the system. Worked.
Hurray.
Ultimately, I managed to figure out that the problem is caused by an old
prelink version which doesn't seem to get along at all with new(er?) libc6
version. See also the initial warning report,
"prelink-2007* and libc6-2.11* don't mix.":
http://lists.debian.org/debian-user/2010/06/msg02063.html
But, right after the upgrade, I hadn't realized the prelink issue
yet.
Note that, rather worse, prelink is cron-registered (cron.daily),
providing a nice time bomb by rendering a system fully unusable again the next
day.
IOW, you copy over pristine libc6 libs, everything boots fine again,
you think it's all fixed ("must have been some stupid libc6 update issue"),
and one day later it's all broken again right when one is unavailable
to get this fixed (yup, you're staring at the person that this happened to).
The issue occurred with the old prelink 0.0.20090311-1 package,
updating to 0.0.20090925-1 fixed everything, no more prelink breakage.
Contrary to the conclusion in the rather helpful warning given by Boyd Stephen
Smith Jr.
above (well, rather helpful if I actually had managed to find it in advance...),
I believe that something rather easy can and should actually be done about it,
to prevent other people from falling into the same very irritating trap:
provide a
Conflicts: prelink (<= 0.0.20090311-1)
package line or some such, which should hopefully be the proper means to
get this avoided.
I'm not sure of more precise version values to be provided here,
though, I only know of 0.0.20090311-1 behaviour.
libc6 specifics:
2010-07-31 19:11:57 upgrade libc6 2.9-25 2.11.2-2
Fallout of this issue really was not nice at all for me personally
(dead semi-production box for > 2 weeks, due to the cron timebomb complication),
thus myself I'd definitely want to see a protection applied,
despite being a __severe__ problem for a branch-hopping minority(?) only.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#585110: usbview: .desktop file has invalid content
Package: usbview Version: 1.1-1 Hi, starting some KDE app via shell managed to yield this: kbuildsycoca4(5818)/kdecore (services) KServicePrivate::init: The desktop entry file "/usr/share/applications/usbview.desktop" has Type= "Applications/System/Hardware" instead of "Application" or "Service" kbuildsycoca4(5818) KBuildServiceFactory::createEntry: Invalid Service : "/usr/share/applications/usbview.desktop" Judging from examination of other .desktop files in /usr/share/applications/ , the content of usbview.desktop seems pretty much very bogus (mixed up file Type entry content with - non-existent - Categories entry, etc.). Thank you, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574160: iceweasel: unspecific message prompt "removed by the system. It is strongly recommended to restart"
Package: iceweasel Version: 3.5.8-1 Just got the following: " Iceweasel, an extension or a plugin has been installed, upgraded or removed by the system. It is strongly recommended to restart. Do you want to restart now ? " This message is dearly missing "strongly recommended to restart... THE BROWSER" Especially since it's talking about "by the system" right before that. Pretty confusing for a newbie who doesn't know that an entire system or session restart (and accompanying loss of session data!) is something not usually enforced in most cases. Not sure whether this message is Iceweasel-only or upstream (internet search didn't turn up anything). Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462582: xserver-xorg-video-ati: regression, size configuration incredibly broken, on bog-standard display size
Hi, On Mon, Mar 08, 2010 at 11:32:44AM +0100, Michel Dänzer wrote: > On Sun, 2010-03-07 at 21:09 +0100, Andreas Mohr wrote: > > Any ideas? What should I test? > > If you're still running the server in depth 16, try 24. (Known but low > priority bug in / related to xserver 1.7) Yerps, that was it indeed, thanks for the hint! Somewhat annoying that such a mode is buggy now (not everybody likes to run a bloaty 24bit mode), but who am I to complain... ;) Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462582: xserver-xorg-video-ati: regression, size configuration incredibly broken, on bog-standard display size
On Sun, Mar 07, 2010 at 09:09:49PM +0100, Andreas Mohr wrote: > BUT, I have bad news now: > Just did an upgrade to 1:6.12.5-1 testing (causing a large bunch of > other xorg stuff to get updated), and directly after having started > 1:6.12.3-1, the screen is now quite a LOT darker than before > (in a weird twilight way, no contrast, no brightness, nothing). > Reverting to 6.12.4-2 (the only one readily available) did not help > either. And I DON'T think it's a (very) sudden monitor issue > (the OSD still shows with original colors) > > Obviously I'm not too happy about this state of affairs ;) > > Any ideas? What should I test? I got the old packages from http://boisson.homeip.net/debian/Xorg7.4/i386/ did a dpkg -i xserver-xorg-video-ati_1:6.12.3-1_i386.deb , same issue. Then I realized that Xorg log showed Radeon entries (obviously, since it's a Radeon). Tried to downgrade to xserver-xorg-video-radeon_1:6.12.3-1_i386.deb , failed. Had to downgrade xserver-xorg-core (was 2:1.7.5-1) to 2:1.6.5-1 , then downgrading to xserver-xorg-video-radeon_1:6.12.3-1_i386.deb was possible and the screen WORKED as it used to. Trying to re-upgrade to xserver-xorg-video-radeon_1:6.12.3-1_i386.deb (to check whether the problem lies with -core or -radeon) unfortunately failed since it requires xserver-xorg-core (>= 2:1.6.99.900). Any other questions? Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462582: xserver-xorg-video-ati: regression, size configuration incredibly broken, on bog-standard display size
Hi, On Sun, Mar 07, 2010 at 11:03:49AM +0100, Brice Goglin wrote: > On Fri, Jan 25, 2008 at 09:33:48PM +0100, Andreas Mohr wrote: > > Package: xserver-xorg-video-ati > > Version: 1:6.7.197-1 > > Severity: important > > > > Hi, > > > > my 14"(!) VGA-connected 1024x768 _desktop_ LCD was working just fine with my > > config file on 1:6.6.193, however both 1:6.7.197-1 and > > 6.7.198~git20080117.6bd510a2 manage to mess up size detection in a > > spectacularly awful way, it seems (either with or without xorg.conf). > > > > - there are 12 references to 1024x768 resolution in the log (DDC detection > > etc.), however it chooses to pick 1280x800 which has never been announced > > _anywhere_! > > - the DPI calculations are not "WAY off" as in another Debian bug report, > > they're "rather very extremely off" (147, 145 instead of 89, 92 > > previously) > > > > The display size detection of 290x210mm seems _correct_ since it matches > > physical dimensions. > > Do you still have these problems with latest packages in unstable? [same hardware still] No, on 1:6.12.3-1 (slightly older testing package) at least, it does not happen any more both with my usual xorg.conf and when renaming the file. It started to work relatively soon thereafter I believe (even though I didn't realize the exact event since I simply left it un-upgraded for a while). BUT, I have bad news now: Just did an upgrade to 1:6.12.5-1 testing (causing a large bunch of other xorg stuff to get updated), and directly after having started 1:6.12.3-1, the screen is now quite a LOT darker than before (in a weird twilight way, no contrast, no brightness, nothing). Reverting to 6.12.4-2 (the only one readily available) did not help either. And I DON'T think it's a (very) sudden monitor issue (the OSD still shows with original colors) Obviously I'm not too happy about this state of affairs ;) Any ideas? What should I test? Thank you very much for your re-inquiry! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568565: pm-suspend: rendered disabled by fatally broken locking implementation
On Mon, Feb 15, 2010 at 05:57:48PM +0100, Michael Biebl wrote: > Andreas Mohr wrote: > > Possible failure leading to pm-suspend breakage includes > > - simple loss of power (notebook battery, wall socket) while suspended > > - a crash during suspend \ both rather common > > - a crash during resume/ behaviour, sadly > > In all those cases, you need to (re)boot your machine. > If you are using tmpfs for /var/run, then /var/run/pm-utils/lock will > automatically be clean, otherwise > /etc/rcS.d/S??.d/mountall-bootclean.sh will clean up /var/run. > > So, I'm actually quite curious, how you managed to get such a stale lock file? # ls -l /lib/init/boot* -rw-r--r-- 1 root root 4865 Jun 26 2009 /lib/init/bootclean.sh.no Any further questions? :-P Well, yes indeed, /var/run/ likely is supposed to be a bit more "volatile" than the remaining bunch of directories on the system, thus it can be kind of expected to get purged rather frequently. Any suggestions as to which cave to choose to crawl back into now? :) Still I think that now using flock as a replacement wasn't such a bad idea anyway. Thanks for your very timely processing of this report, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568565: pm-suspend: rendered disabled by fatally broken locking implementation
On Mon, Feb 15, 2010 at 05:57:48PM +0100, Michael Biebl wrote: > Andreas Mohr wrote: > > Possible failure leading to pm-suspend breakage includes > > - simple loss of power (notebook battery, wall socket) while suspended > > - a crash during suspend \ both rather common > > - a crash during resume/ behaviour, sadly > > In all those cases, you need to (re)boot your machine. > If you are using tmpfs for /var/run, then /var/run/pm-utils/lock will > automatically be clean, otherwise > /etc/rcS.d/S??.d/mountall-bootclean.sh will clean up /var/run. > > So, I'm actually quite curious, how you managed to get such a stale lock file? I cannot think of many reasons currently, but possibly due to using /bin/dash? (perhaps using the Debian bashisms script on the startup scripts would reveal something) I'll keep some notes and check it. > Regarding your patch: I discussed that with my co-maintainer. His opinion is, > that your proposed patch is rather a hack then a proper solution, as you would > be unable to suspend for a whole day in case of stale lockfile. His suggestion > was, to use /usr/bin/flock. Yes, indeed, in the light of flock it's a hack, I should somehow have managed to remember that there's flock :( (was somewhat in a hurry, and wanted to get it improved in any way, shape or form) > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? I'm sure that partly must be due to people unable to think of flock :) Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100215181434.ga30...@rhlx01.hs-esslingen.de
Bug#568565: pm-suspend: rendered disabled by fatally broken locking implementation
Proposed patch (taking
http://www.freelists.org/post/dokuwiki/Changelog-rewrite,6 as a
reference):
--- /usr/lib/pm-utils/functions-1.2.6.1-3.orig 2010-02-14 17:28:15.0
+0100
+++ /usr/lib/pm-utils/functions 2010-02-14 17:32:06.0 +0100
@@ -26,7 +26,10 @@
# extra newline will be appended
# make sure the directory where the lockfile should be exists
mkdir -p "${LOCKDIR}"
- local lock="${LOCKDIR}/${1##*/}"
+ local lockfile="${1##*/}"
+ local lock="${LOCKDIR}/${lockfile}"
+ # remove any stale locks (>= 1 day)
+ find "${LOCKDIR}" -name "${lockfile}" -type f -mtime +1 -exec rm -f {}
\;
# we use noclobber to make sure there are no race conditions
(set -o noclobber; echo "${2}" > "${lock}") 2> /dev/null || return 1
return 0
This managed to remove stale locks and suspend successfully.
Not sure I agree about the severity though ;)
Would this crucial fix perhaps manage to get in before the freeze?
Otherwise we'll probably have several hundred PCs sitting idle consuming
power since their users are barred from using suspend as intended by God... ;)
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100214164731.ga25...@rhlx01.hs-esslingen.de
Bug#568565: pm-suspend: rendered disabled by fatally broken locking implementation
Package: pm-utils Version: 1.2.6.1-3 Severity: grave Justification: most basic robustness principles violated, by a core system package AFAICS even a single unfortunate failure during suspend usage can render pm-suspend support terminally broken, with subsequent attempts always exiting immediately, without any logging to occur (not even when trying to get help by running pm-suspend --help or so) [I realize that hitting an occupied lock probably shouldn't get logged, though]. Possible failure leading to pm-suspend breakage includes - simple loss of power (notebook battery, wall socket) while suspended - a crash during suspend \ both rather common - a crash during resume/ behaviour, sadly The only way to trace failure is to run sh -x or define PM_SUSPEND, which then outputs: +++ return 0 +++ check_hibernate +++ '[' -n uswsusp ']' +++ SUSPEND_HYBRID_MODULE=uswsusp +++ '[' suspend = suspend_hybrid ']' ++ '[' -z uswsusp ']' ++ '[' -z uswsusp ']' ++ id -u + '[' 0 '!=' 0 ']' + try_lock pm-suspend.lock + mkdir -p /var/run/pm-utils/locks + local lock=/var/run/pm-utils/locks/pm-suspend.lock + return 1 + exit 1 /var/run/pm-utils/locks/pm-suspend.lock turns out to be about as old as my grandmother: -rw-r--r-- 1 root root 1 11-09 07:52 /var/run/pm-utils/locks/pm-suspend.lock Filing the report now to get things rolling, may continue investigation on how to fix the problem (possibly by checking age of lock and removing if older than 1 day or so). Note that there isn't any init script available either which might have removed a stale lock as one of its tasks... Since most users are likely to invoke pm-suspend via implementation-hiding frontends, they'll never know what hit them. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557258: unattended-upgrades: add support for trickle?
Hi, On Sat, Nov 21, 2009 at 02:29:18PM +0100, Ola Lundqvist wrote: > Hi Andreas > > Thanks a lot for the information. I will add this to the cron-apt > configuration so that it is documented there. > > However I have a question. The "-o foo=1" what does it do? > > I suggest to document this as > OPTIONS="-o Acquire::http::Dl-Limit=25" > > or is this foo=1 needed as well? I can not find that in the documentation. Sorry, that was just intended as a placeholder for further useful options (just in case there are any that should be listed here). Right, simply add another OPTIONS line to document this item, per your suggestion above. Thanks a lot! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557258: unattended-upgrades: add support for trickle?
I've just been told that apt itself now has a builtin mechanism via a config option for this, Acquire::http::Dl-Limit . Since cron-apt seems to do a very similar thing, I think at the moment a good idea would be to simply add a sample APTCOMMAND line directly below the standard ones in /etc/cron-apt/config, e.g. something like: # APTCOMMAND=/usr/bin/apt-get # more elaborate sample (bandwidth limiting to 25kB/s, does foo and bar): APTCOMMAND="/usr/bin/apt-get -o Acquire::http::Dl-Limit=25 -o foo=1" APT config options don't seem to be too visible, thus a little bit more exposure of useful settings would be nice. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557258: unattended-upgrades: add support for trickle?
Package: unattended-upgrades Version: 0.25.1debian1-0.1 Severity: wishlist Now that the trickle bug affecting e.g. apt is finally fixed (see #302313), it perhaps makes sense to let unattended-upgrades recommend trickle, and have a bandwidth option (expressed in kB/s, default setting maybe 25, with -1 or 0 as "unlimited" setting) which then can do its thing in case trickle is installed as recommended. Doing package upgrades in such a limited way in the background would provide further protection for bandwidth-sensitive services such as VoIP sessions (even a nicely configured QoS usually cannot fully protect against VoIP disruptions). Also, does unattended-upgrades already provide configuration means to download the entire list of packages, not just security upgrades? (i.e. via apt-get --download-only dist-upgrade) In case of trickle support, providing such an option would be even more interesting than without support. Certain Other (tm) operating system vendors have been providing such functionality for some time already, or so I've been told. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533897: reassigning to libx86
Hi, On Tue, Aug 04, 2009 at 02:19:56PM +0200, Michael Biebl wrote: > This definitely is a bug in libx86 and not uswsusp, so reassigning. > > FWIW, I can't reproduce the problem anymore with 1.1+ds1-4, so maybe this > issue > has already been dealt with. strings on libx86 1.1+ds1-4 does find "LRMI_base_addr", and pm-suspend does work, thus it seems fixed, can be closed, thanks! Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533897: uswsusp: s2ram broken by incompatible ABI upgrade of libx86 (s2ram: undefined symbol: LRMI_base_addr)
Package: uswsusp Version: 0.8-1.1+b1 Hi, /var/log/dpkg.log showed a libx86-1 upgrade 2009-06-21 12:16:18 upgrade libx86-1 1.1+ds1-2 1.1+ds1-3 which caused pm-suspend to fail (do-nothing return): /var/log/pm-suspend.log showed s2ram: symbol lookup error: s2ram: undefined symbol: LRMI_base_addr Reverting to libx86-1 1.1+ds1-2 fixed the problem. Needs a uswsusp package rebuild I guess. OTOH this strongly sounds like an illegal ABI breakage of libx86 during minor upgrade. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532982: foomatic-db-engine: random black boxes printing bug - upstream fix available, Debian package upgrade MIA
Package: foomatic-db-engine Version: 4.0-20090509-1 Severity: important Hi, foomatic-db-engine pretty urgently needs another upgrade from upstream to get the black boxes printing of random characters on various HP printers fixed. Newer package not available in package pool nor incoming. See links with fully evaluated discussion: https://bugs.launchpad.net/ubuntu/+source/foomatic-db-engine/+bug/361772 (via http://forums.linux-foundation.org/read.php?30,9170 ) : openprinting.org's Till Kamppeter: "It is an upstream bug in foomatic-db-engine" http://bugs.ghostscript.com/show_bug.cgi?id=690025 Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#475435: konqueror: crash going to Settings -> Configure Konqueror -> Enhanced Browsing, reproducible
Hi, KDE 4.2.2 konqueror and related packages have hit testing; entering proxy setup in konqueror 4.2.2 (and doing some testing there) did not trigger the crash any more (either because the crash has been fixed for real, or because the configuration changes during upgrade circumvented the existing crash cause, who knows). The bug report can thus be closed, methinks. Thanks a lot, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#475435: konqueror: crash going to Settings -> Configure Konqueror -> Enhanced Browsing, reproducible
My testing box doesn't have the KDE4 packages offered yet, and the crash (e.g. in Proxy setup) - as expected - doesn't happen on my u9.04 KDE 4.2.2 setup. OTOH, the error message displayed during the crash was "The desktop file proxy.desktop does not specify a library." which I managed to also get on my u9.04 box (WITHOUT crash!) by removing the X-KDE-Library=kcm_kio line in /usr/share/kde4/services/proxy.desktop . However that doesn't mean at all that this crash possibility is now fixed since I'm not sure whether conditions are identical on the boxes. Took note to have another attempt in 2 months in case KDE4 upgrades are offered then. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#433779: Fixed on 1.4.17
Hi, not sure whether this bug still needs discussing, but on OpenWrt asterisk 1.2.1 I've got the same issue. One thing all people here forgot is checking "sip show peers" output. For me I've got show registry show all providers as "Registered", however the actual peer definitions at show peers are not listed at all (while _local_ SIP peers _are_ listed!) Clearly Yet Another (tm) asterisk SIP peer / registration state machine issue. (I've got two handfuls of those candies, want some?) Here's hope that 1.4.x and 1.6.x are _MUCH_ better in this respect (e.g. on a dynamic IP setup etc.) One last JFYI: on dual-dynamic setup, forget about asterisk peering management (on IAX), install openvpn, configure it, use it for peering, done! (<= 2 hours) VERY easy docs, reassuringly reliable over changes, that's how it should be. Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#488667: openoffice.org-core: should honor /etc/papersize and $PAPERSIZE for new files
Hi, +1 Another pretty annoying aspect of this is that you end up with a Letter document and no amount of fiddling with CUPS and or application print dialog will then prevent the printer from stalling due to "Print as A4?" display prompt after having printed the document... Especially nice if the printer sits on a different floor or a very different office and you end up having to wait there in person for the entire document to finish printing... (this behaviour happens to nicely merge with the never-ending stream of CUPS printing issues) This bug report should be more like "WTF, OOo does NOT obey libpapersize!?". That's at least what my reaction was. Using OOo 1:2.4.1-11ubuntu2.1 on u8.10 here. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504928: Does not honour /lib/firmware/KERNELRELEASE directory layout
Definitely seconded. snd-maestro3.ko nicely fails for me here, on custom-built 2.6.27+. As probably does lots of other hardware for many other users? Took ages working through the entire helper hierarchy (including adding printk logging to maestro3.c!!) until I found out that it is completely unable to locate the firmware file (via strace, no less!). Could this bug be turbo-charged? It's already a month old now, and a lot of time wasted locally until the cause was isolated... Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Hi, On Mon, Nov 17, 2008 at 11:44:04AM +0100, Martin Pitt wrote: > Martin Pitt [2008-11-16 16:59 +0100]: > > Upstream committed a different patch: > > > > http://www.cups.org/strfiles/3001/str3001.patch > > This patch is now included in 1.3.9-5, which just got uploaded to > experimental. Can you guys please test this version? If it works, I > need to push that to unstable and lenny, too, but the window for that > gets smaller every day. OK, I don't know what to make of this: I downgraded cups to 1.3.8-1lenny2 (the original, hanging version), tried printing two of the complex formerly problematic documents, didn't get any socket backend hangs this time (with printer "test" which remained configured exactly as last time when it did produce hangs). Verified timestamp of socket backend binary, was ok (October, matching distribution package, _NOT_ my custom-patched package version), and of course I had stopped and started cups, repeatedly even. Then I said "so what" and upgraded to incoming.debian.org 1.3.9-5 (plus _all_ cups helper packages), first submitted job got stuck at first page without producing any printer traffic, second job worked fine. (first job could possibly have been confused by an earlier Job Abort button action at the printer, though) Puzzled. Thanks a lot for your work, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Hi, On Tue, Nov 11, 2008 at 07:40:40PM +0100, Samuel Thibault wrote: > Andreas Mohr, le Tue 11 Nov 2008 19:33:02 +0100, a écrit : > > Or, simply stated, how to disable the test suite to get a successful > > .deb package build? > > Usually you just need to prepend DEB_BUILD_OPTIONS=nocheck That did it. And re-attempting a 40-page duplexed job on cups Debian unstable 1.3.9-2 did hang just like before, and then downgrading to the patched 1.3.8-1lenny2 _does_ print immediately upon cupsd restart, without any socket backend lockup any more. Very nice work, thanks! > > Samuel Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Hi, On Tue, Nov 11, 2008 at 02:46:55PM +0100, Samuel Thibault wrote: > Right but here the issue is on the input side: device_fd got to EOF, > thus select() returning it and read() on it returning 0. The attached > patch at least prevents select from returning, avoiding 100% CPU usage. Very nice, and fast reaction, too! I wanted to verify this patch to succeed versus the unpatched version to still fail with the very same test setup each, but I failed during package build (via fakeroot dpkg-buildpackage in the apt-get source'd cups-1.3.8/ directory): . . . lsb/usr/cups-included/Zebra/zebra.ppd Zebra ZPL Label Printer, 1.3 zebra.ppd Zebra ZPL Label Printer, 1.3 PASSED Test Summary PASS: Printer 'Test1' correctly produced 55 page(s). PASS: Printer 'Test2' correctly produced 23 page(s). PASS: 154 requests processed. PASS: 0 emergency messages. PASS: 0 alert messages. PASS: 0 critical messages. FAIL: 0 error messages, expected 9. PASS: 0 warning messages. PASS: 0 notice messages. PASS: 1 info messages. FAIL: 0 debug messages, expected more than 0. PASS: 0 debug2 messages. 2 tests failed. Log files can be found in /tmp/cups-root/log. A HTML report was created in /tmp/cups-root/cups-str-1.3-2008-11-11-root.html. Copies of the error_log and cups-str-1.3-2008-11-11-root.html files are in /usr/src/system/cups-1.3.8/test. make[1]: *** [check] Error 1 make[1]: Leaving directory `/usr/src/system/cups-1.3.8' make: *** [debian/stamp-makefile-check] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 birgit:/usr/src/system/cups-1.3.8# Or, simply stated, how to disable the test suite to get a successful .deb package build? (maybe I shouldn't ignore a failing test run though; then what?) Or could you tell me what the usual way is to do this cups .deb package build? Thanks a lot, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
OK, using HPLIP (hp backend, which appears to be recommended) submitting larger jobs seems to work without a backend lockup, however it's AWFULLY, almost unusably slow (1 page per 2 minutes or so, adding up to maybe 4 minutes per quadruple-duplexed PDF/PS page). (HPLIP is actually known to be very slow in certain configurations, too, and developers even already said that they're working on improving it) I don't know, but whichever thing I try to configure in CUPS, I'm _ALWAYS_ (yes, that's an always, since chances are about 60%) hitting a brick wall of some more or less severe sort (and I'm far from being the only one, judging from Internet discussions). IOW, I found a crude if acceptable workaround, thus severity should be left at grave, since the normal socket backend should at least be semi-usable, too. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
Environment clarification: HPLJ4000TN JetDirect J3111A Firmware G.08.49 (newest), on a BNC(!) connection. This being a 10Mbps BNC connection here could be another indication that this 100% CPU lockup issue possibly happens on slower connections only (this issue does not seem to be too wide-spread, thus maybe it affects slow-net users only) The CUPS backend mechanism had issues before already (STR #2664, http://www.cups.org/str.php?L2664+P0+S-2+C0+I0+E0+M20+Q ): r7204 | mike | 2008-01-09 19:59:55 +0100 (Mi, 09 Jan 2008) | 3 lines Don't select() on the output side of the device if we have a side-channel callback - this causes 100% CPU usage (STR #2664) Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
I'm going to revert severity to grave, since my situation can be considered fully printer-less: - this bug is killing all reasonable print activity locally - additionally, my fallback mechanism (printing over a large distributed SMB-based Canon copier network at a remote place) does __NOT__ work either due to a different very annoying bug (on an Ubuntu netbook installation): the GUI says "host check successful", yet printing (via smbspool backend) is not successful (with unreachable host), whereas awfully complicated printing via manual shell invocation of smbspool with all its parameters does work. Clearly CUPS is FULLY AND ENTIRELY UNUSABLE for me, thus this report absolutely deserves to be marked blocker'ish. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489045: cups: infinite loop, 100%CPU use, while trying to print with HPJetDirect
8, 4, 3085379232, 4, 3214689992, 3214687484, 3082137661,
3214689996, 3214687589, 4, 3214687113}}, sa_flags = 255,
sa_restorer = 0xa0cbc62e}
#3 0xb7e16455 in msort_with_tmp (p=0xbf9c5c88, b=0xb7fc6d90, n=3086774688)
at msort.c:142
b1 = 0x2cb86081
b2 = 0xb7fc8680 "U\211åWVSèüçÿÿ\201Ãi\031"
n1 = 3603444881
n2 = 0
tmp = 0xb7fc6d90 "1í^\211á\203äðPTRè\""
s = 0
cmp = (__compar_fn_t) 0
---Type to continue, or q to quit---
---Type to continue, or q to quit---
paperout = 0
offline = 0
print_buffer = "ŽH\234¿", '\0' ,
"\030\000\000\000\000\000\000È£ú· Rü·Àšš\002ôOü·0ïó·ð\212ú·\2048\234¿[xû·š\214ú·Pñ¶·\001\000\000\000\001\000\000\000\000\000\000\000;\020ô·
\000\000\000\000\000php0\205O\204ªû·È£ú·ô/õ·\000\000\000\000Ü/õ·P붷H붷`Èó·ô/õ·\000\000\000\000\000\000\000\000ô¿¿·\000\000\000\000\002\000\000\000ü<\234¿å)¿·\000\000\000\000\001\000\000\000\001\000\000\=\234¿\000\004\000\000TE\234¿\b\000\004\000¬æ¶·\004",
'\0' ...
print_ptr = 0xb7e0787c "ôE"
bc_buffer =
"0.101.0.1\000ü·WÛ\223\034š\214ú·\bY\234¿Ï5û·øX\234¿`ðó·ìX\234¿ÄWü·\000\000\000\000àð¶·\001\000\000\000\000\000\000\000\001\000\000\000Ð涷\031\000\000\000\001",
'\0' , "[EMAIL PROTECTED] Xü·", '\0' ,
"Ä\221ú·Ä\221ú·HYü·\200&ô·\004\000\000\020", '\0' ,
"Ìsà·\210\215ú·\000"...
action = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0},
sa_mask = {__val = {4294967295, 3086766068, 3082134176, 3086798488,
3214685904, 3086710875, 3086798928, 3086799328, 1, 1, 0, 3082134782, 14,
3082133504, 20528, 1, 3084941436, 3082153972, 4, 3214689992, 3214687484,
3086734048, 4, 3085379232, 4, 3214689992, 3214687484, 3082137661,
3214689996, 3214687589, 4, 3214687113}}, sa_flags = 255,
sa_restorer = 0xa0cbc62e}
#3 0xb7e16455 in msort_with_tmp (p=0xbf9c5c88, b=0xb7fc6d90, n=3086774688)
at msort.c:142
b1 = 0x2cb86081
b2 = 0xb7fc8680 "U\211åWVSèüçÿÿ\201Ãi\031"
n1 = 3603444881
n2 = 0
tmp = 0xb7fc6d90 "1í^\211á\203äðPTRè\""
s = 0
cmp = (__compar_fn_t) 0
---Type to continue, or q to quit---
#4 0xb7fc6dc1 in main (argc=-1212155688, argv=Cannot access memory at address
0xf32c
) at socket.c:342
method = Cannot access memory at address 0xfeed
(gdb)
Not that this output helps a lot, methinks.
frame #0 cannot be decoded since I was unable to load libpthread:
(gdb) add-symbol-file /usr/lib/debug/libpthread-2.7.so 0xb7f3e000
add symbol table from file "/usr/lib/debug/libpthread-2.7.so" at
.text_addr = 0xb7f3e000
(y or n) y
Reading symbols from /usr/lib/debug/libpthread-2.7.so...done.
warning: Cannot initialize thread debugging library: generic error
warning: Cannot initialize thread debugging library: generic error
All in all gdb symbol lookup handling leaves a LOT to be desired.
This issue seems to happen more easily in case of WLAN-based transfers
(on LAN, only larger jobs seem to be able to cause this lockup).
Please give more information as to how to usefully debug a CUPS backend
in-process, the CUPS website doesn't seem to explain much in this area.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502100: cups: socket backend hangs in tight select/read loop (larger printouts?)
merge 502100 489045 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502630: ifupdown: unhelpful and grammatically incorrect error message
Package: ifupdown
Version: 0.6.8
Hello,
this report is kinda related to #501554 ("ifupdown: gramatically incorrect
message").
"Don't seem to be have all the variables for %s/%s" is way too vague
IMHO (causing people such as
http://www.nabble.com/-etc-network-interfaces:-post-up-funktioniert-nicht-td14788505.html
to lose much more time than necessary during troubleshooting),
it should better be something like (my favourite)
Warning: %s/%s interface config seems incomplete - missing variable entry?
or
Warning: interface config of %s/%s doesn't seem to have all required entries.
Detected possibly incomplete configuration variable section of interface %s/%s.
Warning: config section of interface %s/%s seems to be incompletely specified!
Warning: missing required variables in configuration section of interface %s/%s?
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502100: cups: socket backend hangs in tight select/read loop (larger printouts?)
Package: cups Version: 1.3.9-1 Hi, (this did occur with 1.3.8-11 as well) I have the suspicion that it seems to be larger printouts which make the socket backend lock up entirely (up to about 10 pages worked fine multiple times, however trying something larger locked up multiple times). strace -f -p gives endless: read(5, ""..., 1024)= 0 select(6, [5], [5], NULL, NULL) = 1 (in [5]) read(5, ""..., 1024)= 0 select(6, [5], [5], NULL, NULL) = 1 (in [5]) read(5, Process 9753 detached # ltrace -f -p 9753 --- SIGSTOP (Stopped (signal)) --- --- SIGSTOP (Stopped (signal)) --- (gdb) attach 9753 Attaching to program: /usr/lib/cups/backend-available/socket, process 9753 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0xb7eee5ae in ?? () (gdb) bt #0 0xb7eee5ae in ?? () #1 0xb7f6dff4 in ?? () #2 0xb7f6c33f in ?? () #3 0x0005 in ?? () #4 0xbfe6b768 in ?? () #5 0x0400 in ?? () #6 0x in ?? () A "fin" on frame 0 does _never_ return. disas on any frame address fails (No function contains specified address.). Corrupt stack?? Remote printer is hplj4000tn:9100, client connected via two routers (one WLAN). Routers don't display any relevant firewall logs. _no_ WLAN driver error messages (acx100). Printout was a PDF file 2-paged via pdftops/psnup/ps2pdf (61 pages). Admittedly a pretty problematic bug report, if you have some ideas to try, then just yell. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500011: cups: "/usr/lib/cups/filter/pstopdf failed"
Hi, a simple cups upgrade seems to WORK already: experienced identical error on 1.3.8-11 when trying once(!), immediately upgraded to 1.3.9-1 after discovering this report, re-issued same (stopped) job once, success. Of course that's one single success report only, but success nonetheless. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500724: xfstt: Segfaulting upon broken .ttf symlink
Package: xfstt
Version: 1.7-5
Hello all,
this can be considered a continuation of stale report #54624
("xfstt: Segfault if there is symlink to nowhere").
Here, I get:
# xfstt
corrupt font database!
opening TTF database failed, while reading "/usr/share/fonts/truetype"
to build it.
Sync in directory "/usr/share/fonts/truetype/.".
Segmentation fault
strace yields:
getpid()= 3667
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb80d1000
write(3, "3667\n"..., 5)= 5
close(3)= 0
munmap(0xb80d1000, 4096)= 0
rt_sigaction(SIGINT, {0x8049ae0, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x8049ae0, [TERM], SA_RESTART}, {SIG_DFL}, 8) = 0
chdir("/usr/share/fonts/truetype") = 0
stat64("/var/cache/xfstt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/var/cache/xfstt/ttinfo.dir", O_RDONLY) = 3
stat64("/var/cache/xfstt/ttinfo.dir", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 0, PROT_READ, MAP_SHARED, 3, 0) = -1 EINVAL (Invalid argument)
close(3)= 0
write(2, "corrupt font database!\n"..., 23corrupt font database!
) = 23
write(2, "opening TTF database failed, whil"..., 84opening TTF database failed,
while reading "/usr/share/fonts/truetype" to build it.
) = 84
chdir("/usr/share/fonts/truetype") = 0
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
stat64("/var/cache/xfstt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/cache/xfstt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/var/cache/xfstt/ttinfo.dir", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
open("/var/cache/xfstt/ttname.dir", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb80d1000
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb80d
fstat64(1, {st_mode=S_IFREG|0644, st_size=5519, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb80cf000
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 6
fstat64(6, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0
getdents(6, /* 172 entries */, 4096)= 4092
stat64("Refsani.ttf", 0xbffee364) = -1 ENOENT (No such file or directory)
stat64("Refserbi.ttf", 0xbffee364) = -1 ENOENT (No such file or directory)
stat64("framd.ttf", 0xbffee364) = -1 ENOENT (No such file or directory)
stat64("ttf-japanese-mincho.ttf", {st_mode=S_IFREG|0644, st_size=8967464, ...})
= 0
open("ttf-japanese-mincho.ttf", O_RDONLY) = 7
fstat64(7, {st_mode=S_IFREG|0644, st_size=8967464, ...}) = 0
mmap2(NULL, 8967464, PROT_READ, MAP_SHARED, 7, 0) = 0xb75c4000
close(7)= 0
write(5, "TTFNNAME\2\1\376\277\0\0\0\0"..., 16) = 16
_llseek(5, 0, [16], SEEK_CUR) = 0
munmap(0xb75c4000, 8967464) = 0
stat64("coprgtb.ttf", 0xbffee364) = -1 ENOENT (No such file or directory)
open("coprgtb.ttf", O_RDONLY) = -1 ENOENT (No such file or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
note# ls -l /usr/share/fonts/truetype/coprgtb.ttf
lrwxr-xr-x 1 root root 31 May 15 2004
/usr/share/fonts/truetype/coprgtb.ttf ->/dosc/windows/fonts/coprgtb.ttf
Note: /dosc does exist, but no windows/ directory beyond it any more
(don't ask why - you know the reason, obviously! ;).
Removing all tons of symlinked fonts (those pointing to the /dosc/windows
directory) fixes the segfault.
Oh, now the possibly deciding factor:
/dev/sda1 on /dosc type vfat (rw,noexec,nosuid,nodev,noatime,umask=000,quiet)
IOW, providing a broken symlink into a VFAT partition (limited file attribute
set or so?) may yield a successful crash.
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495684: [965GM] no (Latin) characters and icons shown at login prompt and in the desktop
Hi, same here, no fonts visible on gdm login. Xorg.0.log showing EXA use, /proc/fb empty. 00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02) Subsystem: Hewlett-Packard Company Device 2802 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f040 (32-bit, non-prefetchable) [size=1M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at 1100 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 2.6.26.2 (custom, make-kpkg): CONFIG_FB=y CONFIG_FB_DDC=m CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m CONFIG_FB_SVGALIB=m # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_CIRRUS=m CONFIG_FB_PM2=m CONFIG_FB_PM2_FIFO_DISCONNECT=y CONFIG_FB_CYBER2000=m CONFIG_FB_ARC=m # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y # CONFIG_FB_EFI is not set # CONFIG_FB_N411 is not set CONFIG_FB_HGA=m # CONFIG_FB_HGA_ACCEL is not set CONFIG_FB_S1D13XXX=m CONFIG_FB_NVIDIA=m # CONFIG_FB_NVIDIA_I2C is not set # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y # CONFIG_FB_RIVA is not set CONFIG_FB_LE80578=m CONFIG_FB_CARILLO_RANCH=m CONFIG_FB_INTEL=m # CONFIG_FB_INTEL_DEBUG is not set CONFIG_FB_INTEL_I2C=y CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set CONFIG_FB_ATY128=m CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y # CONFIG_FB_ATY_GENERIC_LCD is not set CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_BACKLIGHT=y CONFIG_FB_S3=m CONFIG_FB_SAVAGE=m # CONFIG_FB_SAVAGE_I2C is not set # CONFIG_FB_SAVAGE_ACCEL is not set CONFIG_FB_SIS=m CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m # CONFIG_FB_3DFX_ACCEL is not set CONFIG_FB_VOODOO1=m CONFIG_FB_VT8623=m CONFIG_FB_TRIDENT=m # CONFIG_FB_TRIDENT_ACCEL is not set CONFIG_FB_ARK=m CONFIG_FB_PM3=m # CONFIG_FB_GEODE is not set CONFIG_FB_SM501=m CONFIG_FB_VIRTUAL=m No *fb*.ko modules loaded. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491613: konqueror: brown paper bag bug: stupid key-handling crash when closing tab
Package: konqueror Version: 4:3.5.9.dfsg.1-4 Severity: important Hello all, very annoyingly easily reproducible (aka brown paper bag) crash: Start fresh konqueror; open Tab (Ctrl-T), open any website, press Ctrl-Win95-W instead of Ctrl-W - KABM!! (note: you need to have at least two tabs and need to have _opened_ a website in the non-first tab, otherwise no crash) [KCrash handler] #5 0x08541b99 in ?? () #6 0xb7036709 in qt_inheritedBy () from /usr/lib/libqt-mt.so.3 #7 0xb6cbdaeb in KApplication::notify () from /usr/lib/libkdecore.so.4 #8 0xb6f768ad in QETWidget::translateKeyEvent () from /usr/lib/libqt-mt.so.3 #9 0xb6f778a6 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #10 0xb6f87fe6 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #11 0xb6fefb80 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #12 0xb6fefa16 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #13 0xb6fd8cff in QApplication::exec () from /usr/lib/libqt-mt.so.3 #14 0xb7f69c0c in kdemain () from /usr/lib/libkdeinit_konqueror.so #15 0x080484e2 in ?? () #16 0x0001 in ?? () #17 0xbf8d19f4 in ?? () #18 0xbf8d1968 in ?? () #19 0x08048519 in ?? () #20 0xb7fc7250 in ?? () from /lib/ld-linux.so.2 #21 0xbf8d1970 in ?? () #22 0xbf8d19c8 in ?? () #23 0xb7c65455 in __libc_start_main () from /lib/libc.so.6 Backtrace stopped: frame did not save the PC Awful, very awful, unbearable (simply because typing this combo by hitting Win95 key happens to me all the time accidentally). Escalating to severity important since this causes me to lose all tab sessions _at least_ every couple of weeks, IOW way too often, and since it's an especially stupid bug. x86_32 (Athlon), running under kwin (i.e., KDE). Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490868: select(2): timeout value description much less obvious than it should be
Package: manpages-dev Version: 3.02-1 Severity: wishlist Hello all, man 2 select states: " timeout is an upper bound on the amount of time elapsed before select() returns. It may be zero, causing select() to return immediately. (This is useful for polling.) If timeout is NULL (no timeout), select() can block indefinitely. " This... is... confusing. aka "what the heck is the difference between timeout zero and timeout NULL!?!?" "It may be zero" should thus definitely be changed into something like "the timeout value represented by the timeval struct may be zero" to make sure that people grok the difference between a NULL _pointer_ and a zero _representation_ of a struct. This all considering that this is indeed how select(2) works (haven't actually verified it myself recently). Thanks for your much needed docu work, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488771: vlc: podcast support?? the package description claims: "no way"
Package: vlc Version: 0.8.6.e-2.3+b1 Severity: normal As discussed at http://tech.slashdot.org/comments.pl?sid=595621&cid=23947081 , the VLC package description is said to not announce any podcast support, which is quite a usability annoyance. I haven't tried VLC podcast functionality myself (I'm merely intending to nail this usability bug), however at least https://trac.videolan.org/vlc/ticket/254 strongly indicates VLC podcast support. # apt-cache search podcast gpodder - A GTK+ Media aggregator and Podcast catcher kitty - a Qt/KDE based RSS podcast and video aggregator libxmlplaylist-ocaml-dev - Playlist parser for various xml formats newsbeuter - text mode rss feed reader with podcast support podget - Podcast aggregrator/downloader optimized for cron podracer - podcast aggregator/downloader rhythmbox - music player and organizer for GNOME rhythmbox-dbg - debugging symbols for rhythmbox xmms2-plugin-rss - XMMS2 - RSS podcast plugin democracyplayer - GTK+ based RSS video aggregator democracyplayer-data - GTK+ based RSS video aggregator data files hpodder - Tool to scan and download podcasts (podcatcher) idjc - graphical shoutcast/icecast client listen - music player and manager for GNOME miro - GTK+ based RSS video aggregator miro-data - GTK+ based RSS video aggregator data files mythstream - MythTv plugin that plays Internet audio and video streams Well... disappointing search result, which seems to confirm the Slashdot posting claim. Intentionally _not_ using severity "wishlist" since this is a problematic description omission of a core/distinct feature of this package IMHO and thus should best be fixed in a timely manner. OK, "podcast" probably is more of a marketing term than a protocol term, but this is exactly what mere mortals would search for, thus it should be added to the description. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486359: qemu(1) should have "GUI" keyword added to -nographic description somewhere
Package: qemu
Version: 0.9.1-5
Severity: wishlist
Hello,
currently, "man qemu" lists the following for -nographic:
-nographic
Normally, QEMU uses SDL to display the VGA output. With this option,
you
can totally disable graphical output so that QEMU is a simple command
line application. The emulated serial port is redirected on the
console.
Therefore, you can still use QEMU to debug a Linux kernel with a
serial
console.
Since I wanted to disable graphics, I searched the man page for "GUI", which
came up empty and thus I was forced to tediously skim through the whole content
manually.
I think the best solution is to replace "totally disable graphical output"
with "totally disable GUI output" ("graphic" is contained in the "nographic"
keyword already anyway).
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479786: adplug-utils: should definitely reference "OPL3" in package description
Package: adplug-utils Version: 2.0.1-7 Hello, I wanted to check whether my OPL3-supporting soundcard (~driver) actually works, however doing a apt-cache search opl3 came up empty. Most people are familiar with OPL3, _not_ OPL2, thus most people would definitely search for the opl3 term and be stumped. Thus it is very important to add this to the package description somewhere (also since the newest version 2.1, http://sourceforge.net/forum/forum.php?forum_id=684283 , now actually does support OPL3 hardware, thus the term should be added anyway) Now on to figuring out the challenge where to actually fetch those OPL2/OPL3 compatible sound track formats as mentioned on the adplug-utils page... Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475435: konqueror: crash going to Settings -> Configure Konqueror -> Enhanced Browsing, reproducible
:notify () from /usr/lib/libqt-mt.so.3 #32 0xb6e0cec2 in KApplication::notify () from /usr/lib/libkdecore.so.4 #33 0xb709ea52 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3 #34 0xb709dafd in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 #35 0xb70adfe6 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3 #36 0xb7115b80 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3 #37 0xb7115a16 in QEventLoop::exec () from /usr/lib/libqt-mt.so.3 #38 0xb70fecff in QApplication::exec () from /usr/lib/libqt-mt.so.3 #39 0xb801fd44 in kdemain () from /usr/lib/libkdeinit_konqueror.so #40 0x08048502 in ?? () #41 0x0001 in ?? () #42 0xbfc851a4 in ?? () #43 0xbfc85118 in ?? () #44 0x08048539 in ?? () #45 0xb8079dc0 in ?? () from /lib/ld-linux.so.2 #46 0xbfc85120 in ?? () #47 0xbfc85178 in ?? () #48 0xb7d32450 in __libc_start_main () from /lib/libc.so.6 Backtrace stopped: frame did not save the PC konsole output (after an "konqueror &") is: QInputContext: no input method context available QInputContext: no input method context available QObject::connect: Cannot connect (null)::changed( bool ) to KCModuleProxy::moduleChanged(bool) QObject::connect: Cannot connect (null)::destroyed() to KCModuleProxy::moduleDestroyed() QObject::connect: Cannot connect (null)::quickHelpChanged() to KCModuleProxy::quickHelpChanged() KCrash: Application 'konqueror' crashing... I can provide contents of both /usr/share/applications/kde/proxy.desktop and /usr/share/applnk/Settings/Browsing/Web/proxy.desktop on request (nothing too uncommon in there, it seems). This fully reproducible crash happens with an entirely new system account even, and with freshly started konqueror instances, with (at least) both German and English KDE locale setup. Gave it severity important since it's not funny if you have 30 tabs open and you simply want to adjust settings and... BOOM, that's it. It's certainly plausible that _something_ may be misconfigured somewhere, all I'd ask for is that it tries to prevent such an aggressive crash in such an error case, of course. Athlon K7, Debian testing. NOTE: system is "tainted" with an additional Chinese environment setup (e.g. KDE sometimes was configured for Chinese language etc.), that might explain me hitting this rather offensive crash, just make sure to take this into account during analysis. Oh, and this particular Debian is 12 years old on the 8th (or was it 9th?) harddisk generation, so that kind of age might play a role, too ;) Thanks a lot for an otherwise very enjoyable KDE environment, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470701: d-feet: inadequate package description line
Package: d-feet Version: 0.1.8-1 Hi all, a rather bog-standard request like apt-cache search dbus|grep -i viewer comes up with... yeah, that's right... plain NOTHING! Thanks for an otherwise useful package, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462582: xserver-xorg-video-ati: regression, size configuration incredibly broken, on bog-standard display size
Hi, On Sat, Jan 26, 2008 at 12:13:04AM +0100, Brice Goglin wrote: > > I need the xrandr output of 6.7.197 without --verbose too (the preferred > mode does not appear in verbose mode yet). This is 6.7.198 (the git one), is that ok already? Otherwise I'd have to restart sessions once again... Screen 0: minimum 320 x 200, current 1024 x 768, maximum 1680 x 1200 VGA-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 290mm x 210mm 1680x1050 60.0 1600x1024 60.0 1400x1050 60.0 1280x1024 60.0 1440x900 60.2 1280x960 60.0 1280x800 60.0 1152x864 75.0 1280x768 60.0 1152x768 54.8 1024x768 70.1*60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x51269.7 640x48075.0 72.8 72.8 75.0 66.7 60.0 59.9 720x40070.1 DVI-0 disconnected (normal left inverted right x axis y axis) S-video disconnected (normal left inverted right x axis y axis) NOTE that this is already with 1024x768 running activated manually. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462582: xserver-xorg-video-ati: regression, size configuration incredibly broken, on bog-standard display size
On Fri, Jan 25, 2008 at 10:44:48PM +0100, Brice Goglin wrote: > Andreas Mohr wrote: > > my 14"(!) VGA-connected 1024x768 _desktop_ LCD was working just fine with my > > config file on 1:6.6.193, however both 1:6.7.197-1 and > > 6.7.198~git20080117.6bd510a2 manage to mess up size detection in a > > spectacularly awful way, it seems (either with or without xorg.conf). > > > > - there are 12 references to 1024x768 resolution in the log (DDC detection > > etc.), however it chooses to pick 1280x800 which has never been announced > > _anywhere_! > > > > What does xrandr report? (without any xorg.conf) Wow, that was fast! Thanks, Andreas Mohr (xrandr --verbose each) xrandr_ok.log: Screen 0: minimum 400 x 300, current 1024 x 768, maximum 1024 x 768 default connected 1024x768+0+0 (0x55) normal (normal) 0mm x 0mm Identifier: 0x54 Timestamp: 7143859 Subpixel: no subpixels Clones: CRTC: 0 CRTCs: 0 1024x768 (0x55) 59.0MHz h: width 1024 start0 end0 total 1024 skew0 clock 57.6KHz v: height 768 start0 end0 total 768 clock 75.0Hz 1024x768 (0x56) 55.1MHz h: width 1024 start0 end0 total 1024 skew0 clock 53.8KHz v: height 768 start0 end0 total 768 clock 70.0Hz 1024x768 (0x57) 47.2MHz h: width 1024 start0 end0 total 1024 skew0 clock 46.1KHz v: height 768 start0 end0 total 768 clock 60.0Hz 800x600 (0x58) 36.0MHz h: width 800 start0 end0 total 800 skew0 clock 45.0KHz v: height 600 start0 end0 total 600 clock 75.0Hz 800x600 (0x59) 34.6MHz h: width 800 start0 end0 total 800 skew0 clock 43.2KHz v: height 600 start0 end0 total 600 clock 72.0Hz 800x600 (0x5a) 28.8MHz h: width 800 start0 end0 total 800 skew0 clock 36.0KHz v: height 600 start0 end0 total 600 clock 60.0Hz 800x600 (0x5b) 26.9MHz h: width 800 start0 end0 total 800 skew0 clock 33.6KHz v: height 600 start0 end0 total 600 clock 56.0Hz 640x480 (0x5c) 23.0MHz h: width 640 start0 end0 total 640 skew0 clock 36.0KHz v: height 480 start0 end0 total 480 clock 75.0Hz 640x480 (0x5d) 22.4MHz h: width 640 start0 end0 total 640 skew0 clock 35.0KHz v: height 480 start0 end0 total 480 clock 73.0Hz 640x480 (0x5e) 20.6MHz h: width 640 start0 end0 total 640 skew0 clock 32.2KHz v: height 480 start0 end0 total 480 clock 67.0Hz 640x480 (0x5f) 18.4MHz h: width 640 start0 end0 total 640 skew0 clock 28.8KHz v: height 480 start0 end0 total 480 clock 60.0Hz 832x624 (0x60) 38.9MHz h: width 832 start0 end0 total 832 skew0 clock 46.8KHz v: height 624 start0 end0 total 624 clock 75.0Hz 640x512 (0x61) 22.9MHz h: width 640 start0 end0 total 640 skew0 clock 35.8KHz v: height 512 start0 end0 total 512 clock 70.0Hz 720x400 (0x62) 20.2MHz h: width 720 start0 end0 total 720 skew0 clock 28.0KHz v: height 400 start0 end0 total 400 clock 70.0Hz 416x312 (0x63)9.7MHz h: width 416 start0 end0 total 416 skew0 clock 23.4KHz v: height 312 start0 end0 total 312 clock 75.0Hz 400x300 (0x64)9.0MHz h: width 400 start0 end0 total 400 skew0 clock 22.5KHz v: height 300 start0 end0 total 300 clock 75.0Hz 400x300 (0x65)8.6MHz h: width 400 start0 end0 total 400 skew0 clock 21.6KHz v: height 300 start0 end0 total 300 clock 72.0Hz 400x300 (0x66)7.2MHz h: width 400 start0 end0 total 400 skew0 clock 18.0KHz v: height 300 start0 end0 total 300 clock 60.0Hz xrandr_broken.log (the relatively current git-versioned package): Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1680 x 1200 VGA-0 connected 1280x800+0+0 (0x55) normal (normal left inverted right x axis y axis) 290mm x 210mm Identifier: 0x4c Timestamp: 59882 Subpixel: no subpixels Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00004df46202ab1a 110b0101681d1578e8965a8b534a9225 1f4b57bfee0031ca318a315945590101 0101010101010
Bug#457793: release-notes: etch upgrade release notes, chapter 4.5.3: mention localepurge, too?
Package: release-notes Severity: wishlist Hi all, I'd think it'd be useful to add a note about localepurge at the "4.5.3 Make sure you have sufficient space for the upgrade" chapter (purging unused locales freed a whopping 240MB on this machine here on Debian stable). Possibly with a note saying that one should only do this if very space-starved (purging locales might cause understandability issues), and thus maybe list this suggestion last. Thanks, Andreas Mohr -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (10, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-rc6-birgit Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#449294: xemacs21-mule: post-install failure (missing libncurses4 dependency?)
Package: xemacs21-mule Version: 21.4.20-3 Hi, when dist-upgrading my system today I got: # dpkg --configure -a Setting up xemacs21-mule (21.4.20-3) ... emacs-install xemacs21 install/a2ps: Handling install for emacsen flavor xemacs21 xemacs21: error while loading shared libraries: libncurses.so.4: cannot open shared object file: No such file or directory emacs-install: /usr/lib/emacsen-common/packages/install/a2ps xemacs21 failed at /usr/lib/emacsen-common/emacs-install line 28, line 3. dpkg: error processing xemacs21-mule (--configure): subprocess post-installation script returned error exit status 127 Errors were encountered while processing: xemacs21-mule # apt-file search libncurses.so.4 libncurses4: lib/libncurses.so.4 libncurses4: lib/libncurses.so.4.2 Thus I also installed libncurses4, and Suddenly Everything Worked Fine. Not sure whether the libncurses4 dependency is about xemacs21-mule or xemacs21 package proper, though (the install script invokes xemacs21, and that one fails!). OTOH xemacs21-mule does have a libncurses5 dependency registered already (why would xemacs21 then need libncurses4, too??): # dpkg -s xemacs21-mule Package: xemacs21-mule Status: install ok installed Priority: optional Section: editors Installed-Size: 5844 Maintainer: OHURA Makoto <[EMAIL PROTECTED]> Architecture: i386 Source: xemacs21 Version: 21.4.20-3 Provides: emacsen, info-browser, mail-reader, news-reader, www-browser, xemacs21 Depends: xemacs21-support (= 21.4.20-3), xemacs21-bin (= 21.4.20-3), libc6 (>= 2.6.1-1), libcompfaceg1, libdb4.6, libgpmg1 (>= 1.19.6-1), libice6 (>= 1:1.0.0), libjpeg62, libldap2 (>= 2.1.17-1), libncurses5 (>= 5.6+20071006-3), libpng12-0 (>= 1.2.13-4), libsm6, libtiff4, libx11-6, libxaw7, libxext6, libxmu6, libxpm4, libxt6, xemacs21-mulesupport (>= 2003.04.23-1), xemacs21-basesupport (>= 2003.04.23-1), emacsen-common , thus this might point to a local system inconsistency? Or probably more like a packaging issue (those packages should probably all depend on libncurses5, and on libncurses5 only!). xemacs21 package version is 21.4.20-3, too. Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439024: apt-get: annoying 1000Hz polling (--> powertop)
Hi,
just found that #409872 ("On slow arch apt just wastes cpu while waiting
for dpkg to run") is an earlier report about the same software bloat
(scheduler-disrupting 1ms polling loop).
IOW, I'm not the only one to have noticed this.
I'd actually work on this if it weren't for the fact that I'm not
informed about all the circumstances which came into play when
the current loop implementation was being done.
OTOH, are there any hints on how to implement this in an *efficient*
way (read: fully blocking operation) without (or with minimal) side effects?
Thanks,
Andreas Mohr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439024: apt-get: annoying 1000Hz polling (--> powertop)
OK, in apt-pkg/deb/dpkgpm.cc, I've now tried changing the usleep(1000) into a usleep(5) and copying the resulting libapt-pkg-libc6.6-6.so.4.4.0 into place. This removed the timer noise, however installation performance didn't improve much, AFAICS. I'd thus think that this value should be changed to something like 1 or so, or possibly the whole main loop be improved to not need such things any more. Also, it is known to be very advisable to do ++var instead of var++ in iterator-type loops, since this avoids an unnecessary check in asm code (--> smaller binary size). E.g. in the for (vector::iterator I = List.begin(); I != List.end(); I++) line and others. Oh, and somebody said that using endl is not necessarily a good idea since it always flushes the buffer, too (so maybe use something like a my_endl constant defined as "\n" or so). Thanks, Andreas Mohr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
