Bug#1031509: clamav: 2 RCE bugs in ClamAV 0.103 (+ 1.0.0), CVE-2023-20032/CVE-2023-20052
Package: clamav Version: 0.103.7+dfsg-0+deb11u1 Severity: important Dear Maintainer, ClamAV/Cisco have released a security advisory concerning 2 potential-RCE bugs in ClamAV: https://blog.clamav.net/2023/02/clamav-01038-01052-and-101-patch.html According to the the security tracker, all versions currently in Debian are vulnerable: https://security-tracker.debian.org/tracker/CVE-2023-20032 https://security-tracker.debian.org/tracker/CVE-2023-20052 Please consider an update. Currently, ClamAV is not suitable for use in a (quite common) email-scanning setup like with Amavis, but can still be used (with appropriate care) directly. Thus I think Severity: important fits. Kind regards, Robert -- Package-specific info: --- configuration --- # Automatically created by the clamav-freshclam postinst # Comments will get lost when you reconfigure the clamav-freshclam package DatabaseOwner clamav UpdateLogFile /var/log/clamav/freshclam.log LogVerbose false LogSyslog false LogFacility LOG_LOCAL6 LogFileMaxSize 0 LogRotate true LogTime true Foreground false Debug false MaxAttempts 5 DatabaseDirectory /var/lib/clamav DNSDatabaseInfo current.cvd.clamav.net ConnectTimeout 30 ReceiveTimeout 0 TestDatabases yes ScriptedUpdates yes CompressLocalDatabase no Bytecode true NotifyClamd /etc/clamav/clamd.conf # Check for new database 24 times a day Checks 24 DatabaseMirror db.local.clamav.net DatabaseMirror database.clamav.net --- data dir --- total 226104 -rw-r--r-- 1 clamav clamav293670 Feb 17 14:46 bytecode.cvd -rw-r--r-- 1 clamav clamav 60744631 Feb 17 14:44 daily.cvd -rw-r--r-- 1 clamav clamav69 Feb 17 14:43 freshclam.dat -rw-r--r-- 1 clamav clamav 170479789 Feb 17 14:46 main.cvd -- System Information: Debian Release: 11.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-0.deb11.4-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clamav depends on: ii clamav-freshclam [clamav-data] 0.103.7+dfsg-0+deb11u1 ii libc6 2.31-13+deb11u5 ii libclamav9 0.103.7+dfsg-0+deb11u1 ii libcurl47.74.0-1.3+deb11u3 ii libjson-c5 0.15-2 ii libssl1.1 1.1.1n-0+deb11u3 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages clamav recommends: ii clamav-base 0.103.7+dfsg-0+deb11u1 Versions of packages clamav suggests: pn clamav-docs pn libclamunrar -- no debconf information
Bug#1003195: enlightenment: E crashes after coming back from a different VTY
On Thu, 06 Jan 2022 22:26:53 -0800, Ross Vandegrift writes:
>On Thu, Jan 06, 2022 at 12:32:44AM +0100, Robert Waldner wrote:
>> F'rex, switching to VTY1 (text console) works as expected, but after
>> switching back to Enlightenment on VTY7 E crashes.
>> Same after switching back to VTY7 from VTY8 (where a different user runs
>> XFCE4).
>Switching to a different vty and back works fine for me, but I don't have
>another desktop session running anywhere. Does the issue still happen if you
>only have one session running?
Good point: yes, it does.
>> Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red
>> writing situation:
>It looks like you're missing the debug symbols. Please follow the instructions
>at https://wiki.debian.org/HowToGetABacktrace and try again.
I've installed enlightenment-dbgsym, but can't get Enlightenment
started via gdb:
--
$ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' -ex 'threa
d apply all bt full' --args /usr/bin/startx /usr/bin/enlightenment_start
"0x7ffc0cb4c140s": not in executable format: file format not recognized
No executable file specified.
Use the "file" or "exec-file" command.
No stack.
No stack.
--
~/.e-crashdump.txt (attached) looks filled with a bit more info, though.
I've then started E normally via lightdm, and attached to the (or
rather "a", there's a couple) running
/usr/bin/enlightenment process with gdb as per
https://wiki.debian.org/XStrikeForce/XserverDebugging and did a
backtrace there, gdb.txt is also attached.
Hope that helps.
Thanks for taking an interest!
Kind regards,
Robert
Continuing.
Thread 1 "enlightenment" received signal SIGINT, Interrupt.
0x7ffaf92af872 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
29 in ../sysdeps/unix/sysv/linux/pause.c
#0 0x7ffaf92af872 in __libc_pause () at
../sysdeps/unix/sysv/linux/pause.c:29
resultvar = 18446744073709551102
sc_cancel_oldtype = 0
#1 0x7ffaf92b0140 in () at
/lib/x86_64-linux-gnu/libpthread.so.0
#2 0x55a77f727280 in ()
#3 0x7ffaeddff3b6 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#4 0x7ffaeddf1d1d in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#5 0x7ffaeddf2399 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#6 0x7ffaeddc9098 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#7 0x7ffaeddcb4a0 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#8 0x7ffaedd30bc5 in () at
/lib/x86_64-linux-gnu/libnvidia-eglcore.so.495.44
#9 0x7ffaef55b688 in () at /lib/x86_64-linux-gnu/libEGL_nvidia.so.0
#10 0x7ffaef4ff59f in () at /lib/x86_64-linux-gnu/libEGL_nvidia.so.0
#11 0x7ffaf4324bbb in eglReleaseThread () at
/lib/x86_64-linux-gnu/libEGL.so.1
#12 0x7ffaf4375cb3 in () at
/usr/lib/x86_64-linux-gnu/evas/modules/engines/gl_x11/v-1.25/module.so
#13 0x7ffaf437320f in () at
/usr/lib/x86_64-linux-gnu/evas/modules/engines/gl_x11/v-1.25/module.so
#14 0x7ffaf9c928c8 in efl_canvas_output_del () at
/lib/x86_64-linux-gnu/libevas.so.1
#15 0x7ffaf9bfb305 in () at /lib/x86_64-linux-gnu/libevas.so.1
#16 0x7ffaf9f75d6a in efl_destructor () at /lib/x86_64-linux-gnu/libeo.so.1
#17 0x7ffaf9f7f054 in efl_del () at /lib/x86_64-linux-gnu/libeo.so.1
#18 0x7ffaf95231f2 in _ecore_evas_free () at
/lib/x86_64-linux-gnu/libecore_evas.so.1
#19 0x55a77d250146 in _e_comp_free (c=0x55a77f254d70) at
../src/bin/e_comp.c:847
#20 0x55a77d2f3e58 in e_object_unref (obj=0x55a77f254d70) at
../src/bin/e_object.c:153
ref = 0
__func__ = "e_object_unref"
#21 0x55a77d2f3f4d in e_object_del (obj=) at
../src/bin/e_object.c:60
__func__ = "e_object_del"
#22 0x55a77d2538f4 in e_comp_shutdown () at ../src/bin/e_comp.c:1434
l =
ll =
ec =
#23 0x55a77d2e66c8 in _e_main_screens_shutdown () at
../src/bin/e_main.c:1585
#24 0x55a77d2e6ccb in _e_main_shutdown (errcode=errcode@entry=0) at
../src/bin/e_main.c:1157
i =
#25 0x55a77d226921 in main (argc=, argv=) at
../src/bin/e_main.c:1119
waslocked = 0 '\000'
strshare =
s =
action =
{__sigaction_handler = {sa_handler = 0x55a77d30cda0 ,
sa_sigaction = 0x55a77d30cda0 }, sa_mask = {__val = {0 }}, sa_flags = -1073741820, sa_restorer = 0x0}
__func__ = "main"
Thread 4 (Thread 0x7f2f49165700 (LWP 2598539) "Eanimator-timer"):
#0 0x7f2f4df9e116 in epoll_wait (epfd=48, events=0x7f2f49164760,
maxevents=2, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x7f2f4eca071b in () at /lib/x86_64-linux-gnu/libecore.so.1
#2 0x7f2f4ece4cc1 in () at /lib/x86_64-linux-gnu/libecore.so.1
#3 0x7f2f4ede1e0a in () at /lib/x86_
Bug#1003195: enlightenment: E crashes after coming back from a different VTY
Package: enlightenment Version: 0.24.2-8 Severity: normal Dear Maintainer, after upgrading from Debian 10 to 11.2, I can no longer seamlessly switch to different VTYs/Window Managers and then back to Enlightenment. F'rex, switching to VTY1 (text console) works as expected, but after switching back to Enlightenment on VTY7 E crashes. Same after switching back to VTY7 from VTY8 (where a different user runs XFCE4). _Most_ of the time I get a black screen with red writing, citing "Guru meditation #02248813.0011", and can recover my Enlightenment session (and open programs) via pressing F1. At other times I get a non-responsive screen where I can see the title bars of all windows but clicking anywhere with the mouse is non-responsive - this I can usually recover via restarting Enlightenment (which I've bound to ctrl-alt-x for this purpose), but sometines all I can do is kill all Enlightenment processes from, say, VTY1 and logging in again from lightdm. Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red writing situation: --- Thread 1 (Thread 0x7f287f74e740 (LWP 5319)): #0 0x7f287d1c6b8d in pause () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 No locals. #2 0x7f286afbed2b in ?? () from /usr/lib/enlightenment/modules/comp/linux-gnu-x86_64-0.17.3/module.so No symbol table info available. #3 0x7f286afbef4b in ?? () from /usr/lib/enlightenment/modules/comp/linux-gnu-x86_64-0.17.3/module.so No symbol table info available. #4 0x7f287f031657 in ?? () from /usr/lib/x86_64-linux-gnu/libecore.so.1 No symbol table info available. #5 0x7f287f0359d9 in ?? () from /usr/lib/x86_64-linux-gnu/libecore.so.1 No symbol table info available. #6 0x7f287f035f17 in ecore_main_loop_begin () from /usr/lib/x86_64-linux-gnu/libecore.so.1 No symbol table info available. #7 0x00434ac0 in main () No symbol table info available. Detaching from program: /usr/bin/enlightenment, process 5319 --- VTY-switching in this manner has worked well for me for over a decade now, and I'm a bit stumped on as to how to debug this. Thanks for any pointers. Kind regards, Robert -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages enlightenment depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-2 ii dbus-x11 [dbus-session-bus] 1.12.20-2 ii enlightenment-data0.24.2-8 ii libasound21.2.4-1.1 ii libbluetooth3 5.55-3.1 ii libc6 2.31-13+deb11u2 ii libecore-con1 1.25.1-1 ii libecore-drm2-1 1.25.1-1 ii libecore-evas11.25.1-1 ii libecore-file11.25.1-1 ii libecore-input1 1.25.1-1 ii libecore-ipc1 1.25.1-1 ii libecore-wl2-11.25.1-1 ii libecore-x1 1.25.1-1 ii libecore1 1.25.1-1 ii libedje-bin 1.25.1-1 ii libedje1 1.25.1-1 ii libeet1 1.25.1-1 ii libeeze1 1.25.1-1 ii libefreet-bin 1.25.1-1 ii libefreet1a 1.25.1-1 ii libeina1a 1.25.1-1 ii libeio1 1.25.1-1 ii libelementary11.25.1-1 ii libelput1 1.25.1-1 ii libemile1 1.25.1-1 ii libemotion1 1.25.1-1 ii libevas1 1.25.1-1 ii libevas1-engines-drm 1.25.1-1 ii libevas1-engines-wayland 1.25.1-1 ii libevas1-engines-x1.25.1-1 ii libpam0g 1.4.0-9+deb11u1 ii libpulse0 14.2-2 ii libuuid1 2.36.1-8 ii libwayland-client01.18.0-2~exp1.1 ii libwayland-server01.18.0-2~exp1.1 ii libxkbcommon0
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
On Sun, 26 Dec 2021 10:47:42 -0500, Simon Deziel writes: >What's in /etc/default/named? Chroot'ing could cause some issues. This is stock, AFAICT: --- # # run resolvconf? RESOLVCONF=no # startup options for the server OPTIONS="-u bind" --- >Since you are hitting permission issues, I'd also check dmesg for >AppArmor denial messages (`dmesg | grep apparmor`). At least there's nothing (to me) obvious: root@fsckv2:~# dmesg | grep apparmor [6.889374] audit: type=1400 audit(1640488235.484:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-senddoc" pid=900 comm="apparmor_parser" [6.889470] audit: type=1400 audit(1640488235.484:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=901 comm="apparmor_parser" [6.889533] audit: type=1400 audit(1640488235.484:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=889 comm="apparmor_parser" [6.889746] audit: type=1400 audit(1640488235.484:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=896 comm="apparmor_parser" [6.889794] audit: type=1400 audit(1640488235.484:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=894 comm="apparmor_parser" [6.889797] audit: type=1400 audit(1640488235.484:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=894 comm="apparmor_parser" [6.890474] audit: type=1400 audit(1640488235.484:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=891 comm="apparmor_parser" [6.890477] audit: type=1400 audit(1640488235.484:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=891 comm="apparmor_parser" [6.890479] audit: type=1400 audit(1640488235.484:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=891 comm="apparmor_parser" [6.891157] audit: type=1400 audit(1640488235.484:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="named" pid=899 comm="apparmor_parser" Kind regards, Robert -- -- Acronyms explained: TCPA -- (T)otal (C)ontrol of (P)rivate (A)ssets -- - captainiglo
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
On Sun, 26 Dec 2021 14:20:21 +0100, =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= writes: >Well, what is your working directory and is it writeable by user:group > under which named runs at your system? root@fsckv2:~# grep direct /etc/bind/named.conf.options directory "/etc/bind"; root@fsckv2:~# ls -la /etc/bind/ total 104 drwxrwsr-x 3 root bind 4096 Dec 26 11:35 . root@fsckv2:~# grep OPTIONS /etc/default/named OPTIONS="-u bind" Running named from buster, 1:9.11.5.P4+dfsg-5.1, started normally from systemd: root@fsckv2:~# ps auxwww| grep [n]amed bind 133379 0.0 0.9 1728372 323376 ? Ssl 12:09 0:04 /usr/sbin/named -f -u bind Kind regards, Robert
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
Package: bind9 Version: 1:9.16.22-1~deb11u1 Severity: important Dear Maintainers, I upgraded my nameserver from buster to bullseye, afterwards named wouldn't start anymore. Looking at syslog, the relevant part seems to be: ... Dec 26 11:36:01 fsck named[128029]: configuring command channel from '/etc/bind/rndc.key' Dec 26 11:36:01 fsck named[128029]: command channel listening on 127.0.0.1#953 Dec 26 11:36:01 fsck named[128029]: configuring command channel from '/etc/bind/rndc.key' Dec 26 11:36:01 fsck named[128029]: command channel listening on ::1#953 Dec 26 11:36:01 fsck named[128029]: the working directory is not writable ^ Dec 26 11:36:01 fsck named[128029]: loading configuration: permission denied Dec 26 11:36:01 fsck named[128029]: exiting (due to fatal error) Dec 26 11:36:01 fsck systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE Dec 26 11:36:01 fsck systemd[1]: named.service: Failed with result 'exit-code'. Note that this is straight from systemd trying to start it. Running named as `named -g -u bind` got the same result (CWD: /home/myuser). But! starting it manually with a CWD that's writable by group bind (eg. `cd /etc/bind; named -g -u bind`) works: ... 26-Dec-2021 11:44:10.434 configuring command channel from '/etc/bind/rndc.key' 26-Dec-2021 11:44:10.434 command channel listening on 127.0.0.1#953 26-Dec-2021 11:44:10.434 configuring command channel from '/etc/bind/rndc.key' 26-Dec-2021 11:44:10.434 command channel listening on ::1#953 26-Dec-2021 11:44:10.434 not using config file logging statement for logging due to -g option 26-Dec-2021 11:44:10.434 zone 10.in-addr.arpa/IN: loaded serial 2002041301 ... Now this wouldn't be a problem is systemd could start named, but it can't: root@fsckv2:/etc/bind# systemctl start named root@fsckv2:/etc/bind# systemctl status named ● named.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2021-12-26 11:46:23 CET; 1s ago Docs: man:named(8) Process: 130605 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE) Main PID: 130605 (code=exited, status=1/FAILURE) CPU: 51ms Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Scheduled restart job, restart counter is at 5. Dec 26 11:46:23 fsckv2 systemd[1]: Stopped BIND Domain Name Server. Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Start request repeated too quickly. Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Failed with result 'exit-code'. Dec 26 11:46:23 fsckv2 systemd[1]: Failed to start BIND Domain Name Server. For testing, I also `apt-get -b source`d bind9 from testing/unstable (9.17.21-1) but it exhibits the same non-working bevaviour. (If needed I can provide all config in private mail, but am loathe to disclose them publicly as it's quite extensive (this is a nameserver for quite some domains, plus the resolver for all my internal networks).) Kind regards and grateful for any hints, Robert -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9 depends on: ii adduser3.118 ii bind9-libs 1:9.16.22-1~deb11u1 ii bind9-utils1:9.16.22-1~deb11u1 ii debconf [debconf-2.0] 1.5.77 ii dns-root-data 2021011101 ii init-system-helpers1.60 ii iproute2 5.10.0-4 ii libc6 2.31-13+deb11u2 ii libcap21:2.44-1 ii libfstrm0 0.6.0-1+b1 ii libjson-c5 0.15-2 ii liblmdb0 0.9.24-1 ii libmaxminddb0 1.5.2-1 ii libprotobuf-c1 1.3.3-1+b2 ii libssl1.1 1.1.1k-1+deb11u1 ii libuv1 1.40.0-2 ii libxml22.9.10+dfsg-6.7 ii lsb-base 11.1.0 ii netbase6.3 ii zlib1g 1:1.2.11.dfsg-2 bind9 recommends no packages. Versions of packages bind9 suggests: pn bind-doc pn dnsutils pn resolvconf pn ufw -- Configuration Files: /etc/bind/named.conf changed [not included] /etc/bind/named.conf.local changed [not included] /etc/bind/named.conf.options changed [not included] -- debconf information: bind9/run-resolvconf: false bind9/start-as-user: bind bind9/different-configuration-file:
Bug#939165: nmh: spost execs /usr/lib/mh/nmh/post, could do with s:nmh/::
Package: nmh
Version: 1.7.1-4
Severity: normal
Tags: patch
Dear Maintainer (hi az!),
Upgraded jessie->strecch->buster, spost no longer coooperated. When used
via exmh I got
"/usr/lib/mh/spost: 13: exec: /usr/lib/mh/nmh/post: not found"
Fixed the path in spost to no longer contain the nmh part, everything works
again as expected. Looked at the source from testing, too - doesn't seem to
be fixed there, either.
Patch is as simple as:
===
$ diff -u ./nmh-1.7.1/debian/nmh/usr/lib/mh/spost /usr/lib/mh/spost
--- ./nmh-1.7.1/debian/nmh/usr/lib/mh/spost 2019-02-12 05:58:31.0
+0100
+++ /usr/lib/mh/spost 2019-09-01 21:26:16.338481935 +0200
@@ -10,4 +10,4 @@
prefix=''
exec_prefix="${prefix}"
-exec "${prefix}/usr/lib/mh/nmh/post" -mts sendmail/pipe "$@"
+exec "${prefix}/usr/lib/mh/post" -mts sendmail/pipe "$@"
===
Thanks for continuing to maintain nmh!
cheers,
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15
(charmap=ISO-8859-15), LANGUAGE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nmh depends on:
ii libc6 2.28-10
ii libcurl47.64.0-4
ii libdb5.35.3.28+dfsg1-0.5
ii liblockfile11.14-1.1
ii libsasl2-2 2.1.27+dfsg-1
ii libssl1.1 1.1.1c-1
ii libtinfo6 6.1+20181013-2
ii mime-support3.62
ii netbase 5.6
ii sensible-utils 0.0.12
Versions of packages nmh recommends:
ii postfix [mail-transport-agent] 3.4.5-1
Versions of packages nmh suggests:
ii exmh1:2.9.0-1
ii libmailtools-perl 2.18-1
ii libmime-tools-perl 5.509-1
pn mh-book
pn mh-e
pn par
-- no debconf information
Bug#703112: #703112 enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi Alexander, On Thu, 08 Sep 2016 23:40:11 +0200, Alexander Sack writes: >sorry for ping on this old bug and for not getting earlier to you. Is >this issue still something that should be looked into? for me the problem was solved after creating some symlinks, see #110 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703112#110). A similar problem hasn't resurfaced since. Thanks for looking at old bugs! cheers, -- -- "If the primates had imagined that someday politicians would -- come out of the genepool they'd have stayed right up in the -- trees and told evolution to stuff it." - Babylon 5 signature.asc Description: Digital Signature
Bug#786373: [Pkg-xfce-devel] Bug#786373: lightdm switches back to tty1 after auth, manual switch back to VT7 required
I just noticed something else: when I switch to VT1 directly from the initial lightdm login screen, and stop/start lightdm, X w/ Enlightenment comes up. The whole sequence then would be: * boot, watch boot messages scroll by * lightdm login screen appears * I switch to VT1 manually, log in as root * /etc/init.d/lightdm stop * /etc/init.d/lightdm start * screen switches to non-text-mode for a short (sub-second) period * and I'm back at VT1 * manually switch to VT7, see lightdm login screen * enter credentials, press enter * blam, back at VT1 * manually switch to VT7, and now I'm in the Enlightenment session Kind regards, robert -- -- Unterschaetze nicht die psychedelische Wirkung von 4 Tagen -- Schlafentzug. - Andreas Bogk, dasr signature.asc Description: Digital Signature
Bug#786373: [Pkg-xfce-devel] Bug#786373: lightdm switches back to tty1 after auth, manual switch back to VT7 required
On Thu, 21 May 2015 12:21:22 +0200, Yves-Alexis Perez writes: On jeu., 2015-05-21 at 06:01 +0200, Robert Waldner wrote: Since this didn't happen with GDM3, I don't think (ICBW, of course) this is a problem with Enlightenment. I also get the same behaviour on my box at work, same setup, so I can reproduce this. Any hints very much appreciated - this is somewhat annoying. Can you check the .xsession-errors in both cases? Because it seems that the session is correctly started by the greeter, so something else might be happening later. I don't see anything obvious, so I've attached .xsession-errors.old from the first session (directly after reboot) and .xsession-errors from after restarting lightdm. Xorg.0.log(.old) also look fine to me. Kind regards, robert .xsession-errors Description: .xsession-errors .xsession-errors.old Description: .xsession-errors.old -- Brain: Pinky, are you pondering what I'm pondering? -- Pinky: I think so, Brain, but if they called --them Sad Meals, kids wouldn't buy them. signature.asc Description: Digital Signature
Bug#786373: [Pkg-xfce-devel] Bug#786373: lightdm switches back to tty1 after auth, manual switch back to VT7 required
On Thu, 21 May 2015 18:04:22 +0200, Yves-Alexis Perez writes: Any hints very much appreciated - this is somewhat annoying. Can you check the .xsession-errors in both cases? Because it seems that the session is correctly started by the greeter, so something else might be happening later. I don't see anything obvious, so I've attached .xsession-errors.old from the first session (directly after reboot) and .xsession-errors from after restarting lightdm. Well, there are definitely RANDR stuff in the .old log which look weird, but I don't know if they're a cause or a consequence. Hmm, you mean the E_RANDR lines, which I guess are from Enlightenment? Would E even know if it's the first try for a session after reboot or a subsequent one? For comparison, I've attached .xsession-errors/.old from my box at work - same general setup (lightdm, Enlightenment, upgraded from wheezy to jessie (so no full systemd env.), same problem, but w/o proprietary NVIDIA stuff). Kind regards, robert .xsession-errors Description: .xsession-errors .xsession-errors.old Description: .xsession-errors.old -- Booze: because one doesn't solve the world's problems over white wine. signature.asc Description: Digital Signature
Bug#786373: lightdm switches back to tty1 after auth, manual switch back to VT7 required
Package: lightdm Version: 1.10.3-3 Severity: normal Dear Maintainer, I have the following situation: after cold-booting lightdm comes up as expected, I authenticate and then get a blank screen (no signal to the monitor). I then have to manually switch to VT1, stop/start lightdm, authenticate again and am auto-switched to VT1 again. If I then switch to VT7, I finally get to my normal X session with Enlightenment. * What led up to the situation? Switching from GDM3 to lightdm (after upgrade to Jessie). lightdm.log after getting the no-signal blank screen: ... [+38.46s] DEBUG: Session pid=3291: User waldner authorized [+38.46s] DEBUG: Session pid=3291: Greeter sets language de_AT.utf8 [+38.55s] DEBUG: Session pid=3291: Greeter requests session enlightenment [+38.55s] DEBUG: Seat: Stopping greeter; display server will be re-used for user session [+38.55s] DEBUG: Session pid=3291: Sending SIGTERM [+38.56s] DEBUG: Session pid=3291: Greeter closed communication channel [+38.56s] DEBUG: Session pid=3291: Exited with return value 0 [+38.56s] DEBUG: Seat: Session stopped [+38.56s] DEBUG: Seat: Greeter stopped, running session [+38.56s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0 [+38.56s] DEBUG: Session pid=3318: Running command /etc/X11/Xsession /usr/bin/enlightenment_start [+38.56s] DEBUG: Creating shared data directory /var/lib/lightdm/data/waldner [+38.56s] DEBUG: Session pid=3318: Logging to .xsession-errors [+38.59s] DEBUG: Activating VT 7 [+38.59s] DEBUG: Activating login1 session 1 lightdm.log after re-starting lightdm and authenticating: ... [+8.67s] DEBUG: Session pid=3794: User waldner authorized [+8.67s] DEBUG: Session pid=3794: Greeter sets language de_AT.utf8 [+8.80s] DEBUG: Session pid=3794: Greeter requests session enlightenment [+8.80s] DEBUG: Seat: Stopping greeter; display server will be re-used for user session [+8.80s] DEBUG: Session pid=3794: Sending SIGTERM [+8.81s] DEBUG: Session pid=3794: Greeter closed communication channel [+8.81s] DEBUG: Session pid=3794: Exited with return value 0 [+8.81s] DEBUG: Seat: Session stopped [+8.81s] DEBUG: Seat: Greeter stopped, running session [+8.81s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0 [+8.81s] DEBUG: Session pid=3917: Running command /etc/X11/Xsession /usr/bin/enlightenment_start [+8.81s] DEBUG: Creating shared data directory /var/lib/lightdm/data/waldner [+8.81s] DEBUG: Session pid=3917: Logging to .xsession-errors [+8.82s] DEBUG: Activating VT 7 [+8.82s] DEBUG: Activating login1 session 5 Since this didn't happen with GDM3, I don't think (ICBW, of course) this is a problem with Enlightenment. I also get the same behaviour on my box at work, same setup, so I can reproduce this. Any hints very much appreciated - this is somewhat annoying. Kind regards, robert -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lightdm depends on: ii adduser3.113+nmu3 ii dbus 1.8.16-1 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18 ii libgcrypt201.6.3-2 ii libglib2.0-0 2.42.1-1 iu libpam-systemd 215-17 ii libpam0g 1.1.8-3.1 ii libxcb11.10-3+b1 ii libxdmcp6 1:1.1.1-1+b1 ii lightdm-gtk-greeter [lightdm-greeter] 1.8.5-2 Versions of packages lightdm recommends: ii xserver-xorg 1:7.7+7 Versions of packages lightdm suggests: pn accountsservice none ii upower 0.99.1-3.1 -- Configuration Files: /etc/lightdm/keys.conf [Errno 2] No such file or directory: u'/etc/lightdm/keys.conf' /etc/lightdm/lightdm.conf [Errno 2] No such file or directory: u'/etc/lightdm/lightdm.conf' /etc/lightdm/users.conf [Errno 2] No such file or directory: u'/etc/lightdm/users.conf' -- debconf information: lightdm/daemon_name: /usr/sbin/lightdm * shared/default-x-display-manager: lightdm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741031: I can confirm this bug, too
On Mon, 05 May 2014 10:13:51 +0200, Robert Waldner writes: Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got libc6-amd64:i386 into a state where it seems impossible to continue. Removing libc6-amd64:i386 fails because the package is in a bad state, reinstalling doesn't work, either, nor das apt-get -f install: At first failure, I tried with the steps outlined in #736097, and (like Francesco) hosed my system - luckily I had sash installed and could revocer via that. Now it seems I'm stuck in a loop: FWIW, after some experimentation in a chrooted copy of the system I was able to revover, here's a snippet of my shell history: 588 LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ apt-get -f install Didn't help. every new process would just segfault, until (ldconfig had been symlinked to /bin/true before): 589 /sbin/ldconfig.real Seems the apt-get -f install with LD_LIBRARY_PATH set got me far enough so that now it was possible to continue w/o errors: 590 apt-get -f install 591 apt-get -s remove libc6-amd64 592 apt-get -s --purge remove libc6-amd64 593 apt-get --purge remove libc6-amd64 Now I'm in a state without broken/half-installed libc6* packages, finally could get rid of libc6-amd64, and can continue with upgrading: :) waldner@fsck-~ $ COLUMNS=72 dpkg -l | grep libc6 | egrep ^i ii libc6:amd642.18-5 amd64Embedded GNU C Library: Shared li ii libc6:i386 2.18-5 i386 Embedded GNU C Library: Shared li ii libc6-dbg:amd6 2.18-5 amd64Embedded GNU C Library: detached ii libc6-dev:amd6 2.18-5 amd64Embedded GNU C Library: Developme ii libc6-dev:i386 2.18-5 i386 Embedded GNU C Library: Developme ii libc6-dev-i386 2.18-5 amd64Embedded GNU C Library: 32-bit de ii libc6-dev-x32 2.18-5 amd64Embedded GNU C Library: X32 ABI D ii libc6-i386 2.18-5 amd64Embedded GNU C Library: 32-bit sh ii libc6-x32 2.18-5 amd64Embedded GNU C Library: X32 ABI S Kind regards, robert -- -- Too much is just enough. -- Mark Twain (on whiskey) signature.asc Description: Digital Signature
Bug#741031: I can confirm this bug, too
On Tue, 06 May 2014 08:44:02 +0200, Aurelien Jarno writes: On Mon, May 05, 2014 at 10:13:51AM +0200, Robert Waldner wrote: Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got libc6-amd64:i386 into a state where it seems impossible to continue. Removing libc6-amd64:i386 fails because the package is in a bad state, reinstalling doesn't work, either, nor das apt-get -f install: At first failure, I tried with the steps outlined in #736097, and (like Francesco) hosed my system - luckily I had sash installed and could revocer via that. Now it seems I'm stuck in a loop: Before trying to provide any hint, but also to be able to understand and fix the problem, we need to have a clear status of your system. Could you please run the following commands and send us the output: - dpkg -l libc* - ls -l /lib /lib32 /lib64 /lib/i386-linux-gnu/ /lib/x86_64-linux-gnu/ Hi Aurelien, sorry, your mail overlapped with me managing to get back to a working system. I've got most of the state of the libc6* (not libc*) packages still in the scroll buffer, but not all of it (this is literally the top of the scroll buffer): iU libc6-amd64 2.18-5 i386 Embedded GNU C Library: 64bit Shared libraries for AMD64 iU libc6-dbg:amd64 2.18-5 amd64Embedded GNU C Library: detached debugging symbols iU libc6-dev:amd64 2.18-5 amd64Embedded GNU C Library: Development Libraries and Header Files iU libc6-dev:i3862.18-5 i386 Embedded GNU C Library: Development Libraries and Header Files iU libc6-dev-i3862.18-5 amd64Embedded GNU C Library: 32-bit development libraries for AMD64 iU libc6-dev-x32 2.18-5 amd64Embedded GNU C Library: X32 ABI Development Libraries for AMD64 iU libc6-i3862.18-5 amd64Embedded GNU C Library: 32-bit shared libraries for AMD64 rc libc6-i686:i386 2.13-38 i386 Embedded GNU C Library: Shared libraries [i686 optimized] iU libc6-x32 2.18-5 amd64Embedded GNU C Library: X32 ABI Shared libraries for AMD64 :) root@fsck-/usr/local/src/games # ls -la /lib/x86_64-linux-gnu/libdl-2.1* -rw-r--r-- 1 root root 14664 Nov 29 18:00 /lib/x86_64-linux-gnu/libdl-2.17.so I could get the rest of the output, but it'd be from the working system, so I guess there wouldn't much of a point. Thanks for taking the time and trying to help me out. Kind regards, robert -- -- You're lost in the maze of /usr/ucb and /usr/xpg/bin. An evil -- tset attacks you. - az about Solaris signature.asc Description: Digital Signature
Bug#741031: I can confirm this bug, too
Trying to upgrade to current Jessie, eg. from 2.17-97 to 2.18-5, got libc6-amd64:i386 into a state where it seems impossible to continue. Removing libc6-amd64:i386 fails because the package is in a bad state, reinstalling doesn't work, either, nor das apt-get -f install: At first failure, I tried with the steps outlined in #736097, and (like Francesco) hosed my system - luckily I had sash installed and could revocer via that. Now it seems I'm stuck in a loop: # apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: libc-bin libc6 libc6-amd64:i386 Suggested packages: glibc-doc The following packages will be upgraded: libc-bin libc6 libc6-amd64:i386 3 upgraded, 0 newly installed, 0 to remove and 1235 not upgraded. 12 not fully installed or removed. Need to get 0 B/8,518 kB of archives. After this operation, 115 kB disk space will be freed. Do you want to continue? [Y/n] Preconfiguring packages ... (Reading database ... 294301 files and directories currently installed.) Preparing to unpack .../libc6-amd64_2.18-5_i386.deb ... Unpacking libc6-amd64 (2.18-5) over (2.17-97) ... Replaced by files in installed package libc6:amd64 (2.17-97) ... dpkg: warning: subprocess old post-removal script was killed by signal (Segmentation fault) dpkg: trying script from the new package instead ... dpkg: error processing archive /var/cache/apt/archives/libc6-amd64_2.18-5_i386.deb (--unpack): subprocess new post-removal script was killed by signal (Segmentation fault) dpkg: error while cleaning up: subprocess installed pre-installation script was killed by signal (Segmentation fault) Preparing to unpack .../libc6_2.18-5_amd64.deb ... Checking for services that may need to be restarted... Checking init scripts... Warning: found a potentially broken dynamic loader symlink, disabling ldconfig to avoid a possible system breakage. It will be reenabled when a new version of libc-bin is unpacked. Unpacking libc6:amd64 (2.18-5) over (2.17-97) ... dpkg: warning: subprocess old post-removal script was killed by signal (Segmentation fault) dpkg: trying script from the new package instead ... dpkg: error processing archive /var/cache/apt/archives/libc6_2.18-5_amd64.deb (--unpack): subprocess new post-removal script was killed by signal (Segmentation fault) dpkg: error while cleaning up: subprocess installed pre-installation script was killed by signal (Segmentation fault) Errors were encountered while processing: /var/cache/apt/archives/libc6-amd64_2.18-5_i386.deb /var/cache/apt/archives/libc6_2.18-5_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) :( root@fsck-/usr/local/src/games # apt-get remove libc6-amd64:i386 Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libc-bin : Depends: libc6 ( 2.18) but 2.18-5 is to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). :( root@fsck-/usr/local/src/games # apt-get --reinstall install libc6-amd64- libc6 libc-bin Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: glibc-doc The following packages will be REMOVED: libc6-amd64:i386 The following packages will be upgraded: libc-bin libc6 2 upgraded, 0 newly installed, 1 to remove and 1235 not upgraded. 12 not fully installed or removed. Need to get 0 B/5,927 kB of archives. After this operation, 11.0 MB disk space will be freed. Do you want to continue? [Y/n] Preconfiguring packages ... dpkg: error processing package libc6-amd64 (--remove): package is in a very bad inconsistent state; you should reinstall it before attempting a removal E: Sub-process /usr/bin/dpkg returned an error code (1) :( root@fsck-/usr/local/src/games # dpkg -r libc6-amd64 dpkg: error processing package libc6-amd64 (--remove): package is in a very bad inconsistent state; you should reinstall it before attempting a removal Errors were encountered while processing: libc6-amd64 :( root@fsck-/usr/local/src/games # apt-get --reinstall install libc6-amd64:i386 Reading package lists... Done Building dependency tree Reading state information... Done You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libc-bin : Depends: libc6 ( 2.18) but 2.18-5 is to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). :( root@fsck-/usr/local/src/games # apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following extra packages will be installed: libc-bin libc6 libc6-amd64:i386 Suggested packages: glibc-doc
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
Werner Koch, w...@gnupg.org, wrote: On Tue, 18 Feb 2014 18:26, r...@debian.org said: 10240-bit RSA key, ID 4A11C97A, created 2009-09-23 ^^ !!! gpg: (this may be caused by too many secret keys used simultaneously or due to excessive large key sizes) There are reasons why upstream gpg does not allow the creation of such stupidly long keys. The fix for being able to deal with such key-sizes seems rather trivial, though. gnupg-1.4.16/g10/gpg.c:1998 got_secmem=secmem_init( 32768 ); Changing that to, say, 262144 (*8) lets GnuPG deal with keys ~5kBit. A quick test shows that it can deal with 16kBit keys with that value, but 32kBit are still too much. I do think that in Good Old Internet Tradition (be liberal in what you accept) it'd be fine to change that value. It still won't let you *create* keys 4kBit anyway, just deal with situations where the user (or a correspondent, in case of the user wanting to sign such a thing) has created such large keys with something else. Kind regards, -robert -- -- A militant agnostic is someone who's credo is -- No, I don't know, and NEITHER DO YOU, DAMMIT! -- (partly) Kevin Martin, asr signature.asc Description: Digital Signature
Bug#736978: kuvert: Can't read logfile parameter in the config file any more
Package: kuvert
Version: 2.0.10
Severity: normal
Hi az,
another bug (well, I guess).
Preface:
~ $ ls -l /var/log/kuvert
-rw-r--r-- 1 user user 0 Jan 28 22:11 /var/log/kuvert
~ $ echo foo /var/log/kuvert
~ $ cat /var/log/kuvert
foo
So far, so good.
~ $ grep ^logfile .kuvert
logfile /var/log/kuvert
~ $ kuvert -d
reading config file
got config mail-on-error=user
got config identify=1
got config interval=20
got config can-detach=1
got config defaultaction=signonly
got config use-agent=1
Can't use an undefined value as a symbol reference at /usr/bin/kuvert line 914.
Ok, logfile is the first option after use-agent, if I put it further up,
say, after identify:
~ $ kuvert -d
reading config file
got config mail-on-error=user
got config identify=1
Can't use an undefined value as a symbol reference at /usr/bin/kuvert line 914.
If I just comment out the logfile option, kuvert works as expected.
strace-ing yields:
~ $ strace kuvert -d 21 | grep /var/log/kuvert
stat(/var/log/kuvert, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
stat(/var/log/kuvert, {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
Config (~/.kuvert, sans private bits) is:
mail-on-error user
identify 1
interval 20
can-detach 1
defaultaction signonly
use-agent 1
logfile /var/log/kuvert
defaultkey 0x...
Config-file was unchanged from 2.0.9, re-installing 2.0.9 doesn't make any
difference, though, so I'm filing against 2.0.10.
Kind regards (+cheers!),
-robert
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12.6rw1 (SMP w/8 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages kuvert depends on:
ii gnupg 1.4.16-1
ii libauthen-sasl-perl 2.1500-1
ii libc6 2.17-97
ii libfile-slurp-perl .19-4
ii libmailtools-perl 2.12-1
ii libmime-tools-perl 5.505-1
ii libnet-server-mail-perl 0.21-1
ii libnet-smtps-perl 0.03-1
ii perl5.18.2-2
ii postfix [mail-transport-agent] 2.10.2-1
kuvert recommends no packages.
Versions of packages kuvert suggests:
pn keyutils none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736774: kuvert: Unable to start on Jessie - Can't locate Net/SMTPS.pm
Package: kuvert Version: 2.0.9 Severity: normal Hi az, after upgrading to Jessie, kuvert doesn't start anymore: ~ $ kuvert Can't locate Net/SMTPS.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /usr/bin/kuvert line 31. BEGIN failed--compilation aborted at /usr/bin/kuvert line 31. Perusing packages.d.o, I guesstimate kuvert should now depend on libnet-smtps-perl And, indeed, after installing libnet-smtps-perl, kuvert starts again and works as expected. Kind regards, robert -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12.6rw1 (SMP w/8 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages kuvert depends on: ii gnupg 1.4.16-1 ii libauthen-sasl-perl 2.1500-1 ii libc6 2.17-97 ii libfile-slurp-perl .19-4 ii libmailtools-perl 2.12-1 ii libmime-tools-perl 5.505-1 ii libnet-server-mail-perl 0.21-1 ii perl5.14.2-21+deb7u1 ii postfix [mail-transport-agent] 2.10.2-1 kuvert recommends no packages. Versions of packages kuvert suggests: pn keyutils none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736097: libc6:amd64: libc6 2.17-97 rm'ing ld.so.cache at inopportune moment, can not upgrade
On Mon, 20 Jan 2014 23:36:17 -0700, Adam Conrad writes: On Sun, Jan 19, 2014 at 06:55:49PM +0100, Robert Waldner wrote: The problem is that as soon as ld.so.cache is gone, dpkg-deb stops working because it can't find libz.so.1 anymore. At the moment I don't have any idea on how to upgrade from stable (2.13-38) to testing (2.17-97). Any hints *greatly* appreciated. Your analysis doesn't make much sense to me. If libz.so.1 is on the default search path (and it is, unless you've moved it), you don't need ld.so.cache to exist to resolve it. For things on the search path, the cache only speeds up the lookup, it doesn't facilitate it. Ok. My knowledge about libc and library-loading isn't great. If this weren't true, literally *nothing* would run, because most of the world depends on finding libc.so.6 on path. So, I'd recommend sorting out where your libz.so.1 has gone to, and that should get you going again. I've prepared a copy of the system for testing via chroot. chroot'ed to there, `apt-get upgrade`: Preparing to replace libc6-dev-i386 2.13-38 (using .../libc6-dev-i386_2.17-97_amd64.deb) ... Unpacking replacement libc6-dev-i386 ... Preparing to replace libc6-i386 2.13-38 (using .../libc6-i386_2.17-97_amd64.deb) ... Unpacking replacement libc6-i386 ... Replaced by files in installed package libc6:i386 ... Preparing to replace linux-libc-dev:amd64 3.2.51-1 (using .../linux-libc-dev_3.12.6-2_amd64.deb) ... De-configuring linux-libc-dev:i386 ... Unpacking replacement linux-libc-dev:amd64 ... Preparing to replace linux-libc-dev:i386 3.2.51-1 (using .../linux-libc-dev_3.12.6-2_i386.deb) ... Unpacking replacement linux-libc-dev:i386 ... Can not write log, openpty() failed (/dev/pts not mounted?) Setting up linux-libc-dev:amd64 (3.12.6-2) ... Setting up linux-libc-dev:i386 (3.12.6-2) ... Can not write log, openpty() failed (/dev/pts not mounted?) (Reading database ... 288896 files and directories currently installed.) Preparing to replace libc6-dev:i386 2.13-38 (using .../libc6-dev_2.17-97_i386.deb) ... De-configuring libc6-dev:amd64 ... Unpacking replacement libc6-dev:i386 ... Preparing to replace libc6-dev:amd64 2.13-38 (using .../libc6-dev_2.17-97_amd64.deb) ... Unpacking replacement libc6-dev:amd64 ... Preparing to replace locales 2.13-38 (using .../locales_2.17-97_all.deb) ... Unpacking replacement locales ... Preparing to replace libc6:amd64 2.13-38 (using .../libc6_2.17-97_amd64.deb) ... De-configuring libc6:i386 ... Checking for services that may need to be restarted... Checking init scripts... Unpacking replacement libc6:amd64 ... dpkg-deb: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory dpkg: error processing /var/cache/apt/archives/libc6_2.17-97_amd64.deb (--unpack): subprocess dpkg-deb --fsys-tarfile returned error exit status 127 dpkg-deb: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory dpkg: error processing /var/cache/apt/archives/libc6_2.17-97_i386.deb (--unpack): subprocess dpkg-deb --control returned error exit status 127 Processing triggers for man-db ... /usr/bin/mandb: error while loading shared libraries: libgdbm.so.3: cannot open shared object file: No such file or directory Errors were encountered while processing: /var/cache/apt/archives/libc6_2.17-97_amd64.deb /var/cache/apt/archives/libc6_2.17-97_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Now, at this point practically nothing works any more: :( root@fsck-/ # ls -al ./usr/lib32/libz.so.1 ls: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory :) root@fsck-/ # find . -name libz.so.1 | xargs file file: error while loading shared libraries: libmagic.so.1: cannot open shared object file: No such file or directory Looking from _outside_ the chroot it seems everything's still there: # find /mnt/container/ -name libz.so.1 | xargs file -L /mnt/container/usr/lib32/libz.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x3539dd7120554f14be8c3668d2bad45650192c5f, stripped /mnt/container/lib/x86_64-linux-gnu/libz.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x1fb7fe1e239c99d4670d5707a44e723a6752d8e1, stripped /mnt/container/lib/i386-linux-gnu/libz.so.1:ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x6619298726f5e0d5b293bbd09fc3de8c1e6881f8, stripped Yet, once I run ldconfig: :( root@fsck-/ # ldconfig :) root@fsck-/ # ls -al ./usr/lib32/libz.so.1 lrwxrwxrwx 1 root root 13 Jan 21 01:33 ./usr/lib32/libz.so.1 - libz.so.1.2.7 Running dpkg through strace yields: 23397 open(/lib64/libz.so.1, O_RDONLY) = -1 ENOENT (No such file or directory) 23397 open(/usr/lib64/libz.so.1, O_RDONLY) = -1 ENOENT (No such file or directory
Bug#708609: kernel-package: Produces uninstallable linux-headers package in multiarch situation
Package: kernel-package
Version: 12.036+nmu3
Severity: normal
Dear Maintainer,
trying to build a Linux 3.9 kernel here.
Grab source, unpack, config, `fakeroot make-kpkg --us --uc -j 8 --revision \
10.02.rw binary-inarch`. Builds without errors, good.
The newly-generated linux-headers package is not installable, though:
# dpkg -i /usr/local/src/kernel/linux-headers-3.9.2_10.02.rw_amd64.deb
...
dpkg: dependency problems prevent configuration of linux-headers-3.9.2:
linux-headers-3.9.2 depends on libc6-amd64 (= 2.7).
...
# dpkg -l libc6-amd64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---=
ii libc6-amd642.13-38 i386 Embedded GNU C Library: 64bit Sha
And there is no libc6-amd64 for amd64:
# apt-get -s install libc6-amd64:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libc6-amd64 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
libc6
E: Package 'libc6-amd64' has no installation candidate
# apt-get -s install libc6:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6 is already the newest version.
I guess it should depend on libc6:amd64 instead of libc6-amd64:amd64, which
looks like kernel-package not being properly multiarch-aware.
Editing /usr/share/kernel-package/Control (hence the debsums error below) like
Package: =ST-headers-=V
Architecture: any
#Depends: ${shlibs:Depends}
Depends: libc6 (= 2.13-38)
produces the desired result (installable/usable linux-headers package), but
is clearly an ugly hack and not a proper solution.
Other packages installed that I think might be relevant:
ii dpkg-dev 1.16.10 all Debian package development tools
ii gcc4:4.7.2-1amd64GNU C compiler
ii kernel-package 12.036+nmu3 all A utility for building Linux kern
ii libc6:amd642.13-38 amd64Embedded GNU C Library: Shared li
ii libc6:i386 2.13-38 i386 Embedded GNU C Library: Shared li
ii libc6-amd642.13-38 i386 Embedded GNU C Library: 64bit Sha
Kind regards,
Robert Waldner
-- System Information:
Debian Release: 7.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'proposed-updates'), (500, 'unstable'),
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages kernel-package depends on:
ii binutils 2.22-8
ii build-essential11.6
ii debianutils4.3.4
ii file 5.11-2
ii gettext0.18.1.1-10
ii make 3.81-8.2
ii module-init-tools 9-3
ii po-debconf 1.0.16+nmu2
ii util-linux 2.20.1-5.3
Versions of packages kernel-package recommends:
ii cpio 2.11+dfsg-0.1
Versions of packages kernel-package suggests:
pn btrfs-tools none
ii bzip2 1.0.6-4
pn docbook-utils none
ii e2fsprogs 1.42.5-1.1
ii grub0.97-66
ii initramfs-tools [linux-initramfs-tool] 0.112
pn jfsutilsnone
ii libncurses5-dev [libncurses-dev]5.9-10
ii linux-source-3.8 [linux-source] 3.8.12-1
pn mcelog none
pn oprofilenone
pn pcmciautils none
pn ppp none
ii procps 1:3.3.4-2
pn quota none
pn reiserfsprogs none
pn squashfs-tools none
ii udev175-7.2
pn xfsprogsnone
ii xmlto 0.0.25-2
-- Configuration Files:
/etc/kernel-pkg.conf changed:
maintainer := Robert Waldner
email := waldner+ker...@waldner.priv.at
priority := Low
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/kernel-package/Control (from kernel-package
package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi Willi, On Sun, 12 May 2013 09:20:07 +0200, Willi Mann writes: in http://bugs.debian.org/707877 someone reported to have solved similar problems like yours via placing further symlinks in /usr/lib for the symlinks shipped in /usr/lib/x86_64-linux-gnu/ by libnspr4-0d. Could you please check whether such symlinks already exist on your system and then check whether the solution mentioned also works for you? no, the symlinks didn't exist - creating them _did_ solve the problem, though. Enigmail now works as expected, for checking signatures, de- and encrypting, again. Thanks for pointing this out! Kind regards, Robert Waldner signature.asc Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
On Sun, 21 Apr 2013 21:05:34 +0200, Willi Mann writes:
On Thu, 11 Apr 2013 18:59:11 +0200, Willi Mann writes:
thanks for the update. It would be interesting to know what
happens if you remove the i386 versions of libnspr4{,-0d}.
This would also remove ia32-libs (and ia32-libs-i386), which, the
last time I tried, made the system disfunctional (froze and
wouldn't boot into userland anymore), and I had to rescue-boot and
reinstall those packages. I'm somewhat wary of trying that again.
I can understand that.
I'll try and get a second disk to RAID-1 the box, then such tests are
gonna be rather easier to roll back instead of rescue-boot or
restore-from-backup. ETA at least 2 weeks, though.
The alternative is that I try to reproduce the
problem by installing the same set of package in a virtual
environment. Can you please send me the output of
dpkg --get-selections
and
dpkg -l
? In case you feel uncomfortable sending this to the public bug
report, you can send it to me only (encrypted if you like, my key is
in the debian-keyring). I fear I will not have time immediately for
that, though.
Incoming in direct mail.
If that does not help, I would be interested in the contents of
/etc/ld.so.conf and all the files in /etc/ld.so.conf.d/. I would
then forward this bug to upstream again.
Attached.
Thanks. I think I should only try this on a test system, but one of
the first things I would try there is renaming i486-linux-gnu.conf to
yy_i486-linux-gnu.conf, under the assumption that only the first
matching library is tried to be loaded by mozilla applications,
without ignoring libraries of the wrong architecture.
No difference (after renaming+ldconfig, from the Icedove error console):
Failed to load native module at path
'/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libenigmime-x86_64-gcc3.so':
(80004005) libplds4.so.0d: cannot open shared object file: No such file or
directory
Failed to load native module at path
'/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so':
(80004005) libplds4.so.0d: cannot open shared object file: No such file or
directory
Kind regards,
Robert Waldner
--
-- in the beginning was the word.
-- and the word was Content-Type: text/plain.
-- - unknown
signature.asc
Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
On Thu, 11 Apr 2013 18:59:11 +0200, Willi Mann writes:
thanks for the update. It would be interesting to know what happens if
you remove the i386 versions of libnspr4{,-0d}.
This would also remove ia32-libs (and ia32-libs-i386), which, the last
time I tried, made the system disfunctional (froze and wouldn't boot
into userland anymore), and I had to rescue-boot and reinstall those
packages.
I'm somewhat wary of trying that again.
If that does not help,
I would be interested in the contents of /etc/ld.so.conf and all the
files in /etc/ld.so.conf.d/. I would then forward this bug to upstream
again.
Attached.
Kind regards,
Robert Waldner
ld.so.tar
Description: ld.so.tar
signature.asc
Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi,
On Wed, 10 Apr 2013 22:17:52 +0200, Willi Mann writes:
do you have any update on this? Is there anything that you could be
related to your enigmail problems in the Error Console?
WM
Am 2013-03-27 08:38, schrieb Willi Mann:
Hi!
Upstream recommended to check the error console (Tools Error
Console). Are there any entries that could be related to enigmail?
sorry, I was away and this mail somehow got overlooked.
Yes, there are errors in the error console that might be related, right
after startup:
Failed to load native module at path
'/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libenigmime-x86_64-gcc3.so':
(80004005) libplds4.so.0d: cannot open shared object file: No such file or
directory
Failed to load native module at path
'/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so':
(80004005) libplds4.so.0d: cannot open shared object file: No such file or
directory
libplds4.so.0d is installed:
$ dpkg -S libplds4.so
libnspr4-0d:i386: /usr/lib/i386-linux-gnu/libplds4.so.0d
libnspr4:i386: /usr/lib/i386-linux-gnu/libplds4.so
libnspr4:amd64: /usr/lib/x86_64-linux-gnu/libplds4.so
libnspr4-0d:amd64: /usr/lib/x86_64-linux-gnu/libplds4.so.0d
And from `ldconfig -v` it seems fine, too:
/usr/lib/i386-linux-gnu:
...
libplds4.so - libplds4.so.0d
/usr/lib/x86_64-linux-gnu:
...
libplds4.so - libplds4.so.0d
`ldd`, OTOH:
$ ldd !$
ldd
/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so
linux-vdso.so.1 = (0x7fff9060)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f08f8ef8000)
libxpcom.so = not found
libmozalloc.so = not found
libxul.so = not found
libplds4.so.0d = not found
libplc4.so.0d = not found
libnspr4.so.0d = not found
libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f08f8cf)
libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f08f89e8000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f08f876)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f08f8548000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f08f81b8000)
/lib64/ld-linux-x86-64.so.2 (0x7f08f935)
Kind regards,
Robert Waldner
signature.asc
Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi!
On Sun, 24 Mar 2013 08:38:53 +0100, Willi Mann writes:
Could you please send me the output of
% dpkg -l $(for i in $(lsof -c icedove | grep \.so | awk '{print
$9}' | sort | uniq); do dpkg -S $i; done | cut -d: -f1 | sort | uniq)
Attached.
I'd like to know whether we have the same versions of all packages
that icedove loads shared libraries from installed. Of course, this
should not be the problem, but let us take a look at it anyway.
I'd not be surprised if the problem is somewhere in there - as I said,
I moved from i386 to amd64 when the problem started.
Kind regards,
Robert Waldner
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-=-==--==
ii gvfs:amd641.12.3-4
amd64userspace virtual filesystem - GIO module
ii gvfs-libs:amd64 1.12.3-4
amd64userspace virtual filesystem - private libraries
ii icedove 10.0.12-1
amd64mail/news client with RSS and integrated spam filter support
ii libart-2.0-2:amd642.3.21-2
amd64Library of functions for 2D graphics - runtime files
ii libasound2:amd64 1.0.25-4
amd64shared library for ALSA applications
ii libasound2:i386 1.0.25-4
i386 shared library for ALSA applications
ii libatk1.0-0:amd64 2.4.0-2
amd64ATK accessibility toolkit
ii libavahi-client3:amd640.6.31-2
amd64Avahi client library
ii libavahi-client3:i386 0.6.31-2
i386 Avahi client library
ii libavahi-common3:amd640.6.31-2
amd64Avahi common library
ii libavahi-common3:i386 0.6.31-2
i386 Avahi common library
ii libavahi-glib1:amd64 0.6.31-1
amd64Avahi GLib integration library
rc libavahi-glib1:i386 0.6.31-1
i386 Avahi GLib integration library
ii libbluray1:amd64 1:0.2.2-1
amd64Blu-ray disc playback support library (shared library)
ii libbonobo2-0 2.24.3-1
amd64Bonobo CORBA interfaces library
ii libbonoboui2-02.24.3-1
amd64The Bonobo UI library
ii libc6:amd64 2.13-38
amd64Embedded GNU C Library: Shared libraries
ii libc6:i3862.13-38
i386 Embedded GNU C Library: Shared libraries
ii libc6-amd64 2.13-38
i386 Embedded GNU C Library: 64bit Shared libraries for AMD64
ii libcairo2:amd64 1.12.2-3
amd64The Cairo 2D vector graphics library
rc libcairo2:i3861.12.2-3
i386 The Cairo 2D vector graphics library
ii libcanberra0:amd640.28-6
amd64simple abstract interface for playing event sounds
ii libdbus-1-3:amd64 1.6.8-1
amd64simple interprocess messaging system (library)
ii libdbus-1-3:i386 1.6.8-1
i386 simple interprocess messaging system (library)
ii libdbus-glib-1-2:amd640.100.2-1
amd64simple interprocess messaging system (GLib-based shared library)
rc libdbus-glib-1-2:i386 0.100.1-1
i386 simple interprocess messaging system (GLib-based shared library)
ii libevent-2.0-5:amd64 2.0.19-stable-3
amd64Asynchronous event notification library
ii libexpat1:amd64 2.1.0-1
amd64XML parsing C library - runtime library
ii libexpat1:i3862.1.0-1
i386 XML parsing C library - runtime library
ii libffi5:amd64 3.0.10-3
amd64Foreign Function Interface library runtime
ii
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi!
On Sat, 23 Mar 2013 22:29:17 +0100, Willi Mann writes:
In the meantime you could use strace to check whether icedove even
tries to load the binary components:
strace -o strace.icedove -f icedove
(Just start it and close it, you don't need to try to open or write
any mail.)
grep -E (ipc|enig).*so strace.icedove
This grep returns 6 lines on my system, 4 stat64 and 2 open. Please
send me the output (unless it is empty..).
stat(), not stat64() here, it seems:
stat(/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libenigmime-x86_64-gcc3.so,
{st_mode=S_IFREG|0644, st_size=93096, ...}) = 0
stat(/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libenigmime-x86_64-gcc3.so,
{st_mode=S_IFREG|0644, st_size=93096, ...}) = 0
stat(/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so,
{st_mode=S_IFREG|0644, st_size=67008, ...}) = 0
stat(/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so,
{st_mode=S_IFREG|0644, st_size=67008, ...}) = 0
open(/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libenigmime-x86_64-gcc3.so,
O_RDONLY) = 27
open(/usr/lib/mozilla/extensions/{3550f703-e582-4d05-9a08-453d09bdfdc6}/{847b3a00-7ab1-11d4-8f02-006008948af5}/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so,
O_RDONLY) = 27
You could also create a new account to rule out that some environment
variable disturbs the loading of those binary components (e.g.
LD_LIBRARY_PATH is set to a custom value in your account, as far as I
remember from checking your enigmail debug output).
Doesn't make much difference - at least none that I can see (debug
output attached). For the sake of completeness, I also did this under
a more standard window manager (XFCE4 instead of my usual E17). I
_did_ copy ~/,gnupg to have the keys needed for decryption, though - if
I should also try with new keys, this'll take a bit longer.
Kind regards,
Robert Waldner
2013-03-23 22:45:40.235 [DEBUG] enigmail.js: Logging debug output to
/tmp/en/enigdbug.txt
2013-03-23 22:45:40.236 [DEBUG] enigmail.js: Enigmail version 1.4.1
2013-03-23 22:45:40.236 [DEBUG] enigmail.js: OS/CPU=Linux x86_64
2013-03-23 22:45:40.236 [DEBUG] enigmail.js: Platform=X11
2013-03-23 22:45:40.236 [DEBUG] enigmail.js: composeSecure=true
2013-03-23 22:45:40.237 [DEBUG] enigmail.js: Enigmail.initialize: Ec.envList =
DISPLAY=:1.0,HOME=/home/enigtest,LANG=de_AT.UTF-8,LOGNAME=enigtest,LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove,MOZILLA_FIVE_HOME=/usr/lib/icedove,PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games,PWD=/home/enigtest,SHELL=/bin/bash,USER=enigtest
2013-03-23 22:45:40.237 [DEBUG] enigmail.js: ResolvePath: filePath=gpg
2013-03-23 22:45:40.237 [CONSOLE] EnigmailAgentPath=/usr/bin/gpg
2013-03-23 22:45:40.238 [DEBUG] enigmail.js: Enigmail.setAgentPath: calling
subprocess with '/usr/bin/gpg'
2013-03-23 22:45:40.281 [CONSOLE] enigmail /usr/bin/gpg --version --version
--batch --no-tty --charset utf-8 --display-charset utf-8
2013-03-23 22:45:40.282 [CONSOLE] gpg (GnuPG) 1.4.12
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Unterstützte Verfahren:
Ãff. Schlüssel: RSA, RSA-E, RSA-S, ELG-E, DSA
Verschlü.: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
2013-03-23 22:45:40.282 [DEBUG] enigmail.js: detected GnuPG version '1.4.12'
2013-03-23 22:45:40.282 [DEBUG] enigmail.js: detectGpgAgent
2013-03-23 22:45:40.282 [DEBUG] enigmail.js: detectGpgAgent: no GPG_AGENT_INFO
variable set
2013-03-23 22:45:40.282 [DEBUG] enigmail.js: detectGpgAgent - gpg 1.x found
2013-03-23 22:45:40.282 [DEBUG] enigmail.js: detectGpgAgent: GPG_AGENT_INFO=''
2013-03-23 22:45:40.283 [DEBUG] enigmailCommon.jsm: stillActive:
2013-03-23 22:45:40.283 [DEBUG] enigmail.js: Enigmail.initialize: END
2013-03-23 22:45:40.283 [DEBUG] enigmailCommon.js: getService: 1.4.1
2013-03-23 22:45:40.283 [DEBUG] enigmailCommon.jsm: getVersion
2013-03-23 22:45:40.283 [DEBUG] enigmailCommon.jsm: installed version: 1.4.1
2013-03-23 22:45:40.283 [DEBUG] enigmailMessengerOverlay.js: messageDecryptCb:
2013-03-23 22:45:40.283 [DEBUG] enigmailMessengerOverlay.js: header
content-type: multipart/encrypted; boundary
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi! On Fri, 22 Mar 2013 16:45:57 +0100, Willi Mann writes: Please enable debugging (OpenPGP - Settings (Expert Options) - Debugging - Enter location) and send me the logfiles. I'll probably forward this to upstream. Please also execute lsof | grep icedove | grep -i enig and debsums enigmail and send me the output. Attached. (And thanks for taking the time to help me!) Kind regards, Robert Waldner /usr/lib/xul-ext/enigmail/chrome.manifest OK /usr/lib/xul-ext/enigmail/chrome/enigmail.jar OK /usr/lib/xul-ext/enigmail/components/enigMsgCompFields.js OK /usr/lib/xul-ext/enigmail/components/enigmail.js OK /usr/lib/xul-ext/enigmail/components/enigmail.xpt OK /usr/lib/xul-ext/enigmail/components/enigmime.xpt OK /usr/lib/xul-ext/enigmail/components/enigprefs-service.js OK /usr/lib/xul-ext/enigmail/components/ipc-pipe.xpt OK /usr/lib/xul-ext/enigmail/defaults/preferences/enigmail.jsOK /usr/lib/xul-ext/enigmail/install.rdf OK /usr/lib/xul-ext/enigmail/modules/commonFuncs.jsm OK /usr/lib/xul-ext/enigmail/modules/enigmailCommon.jsm OK /usr/lib/xul-ext/enigmail/modules/keyManagement.jsm OK /usr/lib/xul-ext/enigmail/modules/pipeConsole.jsm OK /usr/lib/xul-ext/enigmail/modules/subprocess.jsm OK /usr/lib/xul-ext/enigmail/modules/subprocess_worker_unix.js OK /usr/lib/xul-ext/enigmail/modules/subprocess_worker_win.jsOK /usr/lib/xul-ext/enigmail/platform/Linux_x86_64-gcc3/components/libenigmime-x86_64-gcc3.so OK /usr/lib/xul-ext/enigmail/platform/Linux_x86_64-gcc3/components/libipc-x86_64-gcc3.so OK /usr/share/doc/enigmail/changelog.Debian.gz OK /usr/share/doc/enigmail/copyright OK icedove-b 23357 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23391 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23391 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23392 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23392 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23393 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23393 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23394 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23394 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23395 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23395 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23396 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23396 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23398 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23398 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23404 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23404 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23406 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23406 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23413 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23413 waldner 50w REG8,2 9079 3670053 /tmp/enigdbug.txt icedove-b 23357 23414 waldner mem REG8,2 1329252 5641200 /usr/lib/xul-ext/enigmail/chrome/enigmail.jar icedove-b 23357 23414 waldner 50w
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
On Thu, 21 Mar 2013 08:05:08 +0100, Willi Mann writes: This looks like an incompatibility on ABI level, which normally occurs if your version of enigmail is not compiled against the current version of icedove. Could you please post the output of $ dpkg -l enigmail icedove ? I'm particularly interested in the Architecture field. Sure: ~ $ dpkg -l enigmail icedove Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii enigmail 2:1.4.1-2amd64GPG support for Thunderbird and D ii icedove10.0.12-1amd64mail/news client with RSS and int Kind regards, Robert waldner -- -- So Solaris is like the nerdy kid who has carefully-thought-out -- unusual behavior that he sticks to because he has a rationale, -- while Ubuntu is -- So ... Solaris is Richard Stallman? signature.asc Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi! On Thu, 21 Mar 2013 18:56:23 +0100, Willi Mann writes: ii enigmail 2:1.4.1-2amd64GPG support for Thunderbird ii icedove10.0.12-1amd64mail/news client with Thanks, this looks the same on my system where enigmail works fine. Have you tested if the problem is reproducible in a fresh profile? Fresh profile, from the error console: Error: enigmailMsgComposeOverlay.js: Enigmail.msg.encryptMsg: caught exception: TypeError Message: 'Cc[NS_IPCBUFFER_CONTRACTID] is undefined' File: file:///usr/lib/mozilla/extensions/%7B3550f703-e582-4d05-9a08-453d09bdfdc6%7D/%7B847b3a00-7ab1-11d4-8f02-006008948af5%7D/components/enigmail.js Line:1633 Stack: ([object Proxy],16,null,Test Message,0xC33A2BC0,wald...@waldner.priv.at,,354,[object Object],[object Object],[object Object])@file:///usr/lib/mozilla/extensions/%7B3550f703-e582-4d05-9a08-453d09bdfdc6%7D/%7B847b3a00-7ab1-11d4-8f02-006008948af5%7D/components/enigmail.js:1633 ([object Object],227,96,3,0xC33A2BC0,[object Array],[object Array])@chrome://enigmail/content/enigmailMsgComposeOverlay.js:1163 (0)@chrome://enigmail/content/enigmailMsgComposeOverlay.js:1497 ([object UIEvent])@chrome://enigmail/content/enigmailMsgComposeOverlay.js:2076 _enigmial_sendMessageListener([object UIEvent])@chrome://enigmail/content/enigmailMsgComposeOverlay.js:2775 GenericSendMessage(0)@chrome://messenger/content/messengercompose/MsgComposeCommands.js:2187 SendMessage()@chrome://messenger/content/messengercompose/MsgComposeCommands.js:2260 (cmd_sendButton)@chrome://messenger/content/messengercompose/MsgComposeCommands.js:554 goDoCommand(cmd_sendButton)@chrome://global/content/globalOverlay.js:96 oncommand([object XULCommandEvent])@chrome://messenger/content/messengercompose/messengercompose.xul:1 Did you ever install enigmail from upstream's homepage? I don't think so, though I'm using Icedove for something like 5 years now, and am not sure if Enigmail was available in Debian for all that time. Kind regards, Robert waldner -- -- Too much is just enough. -- Mark Twain (on whiskey) signature.asc Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Hi! On Thu, 21 Mar 2013 23:17:35 +0100, Robert Waldner writes: On Thu, 21 Mar 2013 18:56:23 +0100, Willi Mann writes: ii enigmail 2:1.4.1-2amd64GPG support for Thunderbird ii icedove10.0.12-1amd64mail/news client with Thanks, this looks the same on my system where enigmail works fine. Have you tested if the problem is reproducible in a fresh profile? Fresh profile, from the error console: Ah, sorry, that was with trying to *en*crypt mail, which with the new profile is also not working. *De*crypting gets the following in the error console: Error: enigmailMessengerOverlay.js: messageDecryptCb: caught exception: TypeError Message: 'Cc[NS_ENIGMIMESERVICE_CONTRACTID] is undefined' File: file:///usr/lib/mozilla/extensions/%7B3550f703-e582-4d05-9a08-453d09bdfdc6%7D/%7B847b3a00-7ab1-11d4-8f02-006008948af5%7D/components/enigmail.js Line:759 Stack: ()@file:///usr/lib/mozilla/extensions/%7B3550f703-e582-4d05-9a08-453d09bdfdc6%7D/%7B847b3a00-7ab1-11d4-8f02-006008948af5%7D/components/enigmail.js:759 ([object Event],true,[object Object])@chrome://enigmail/content/enigmailMessengerOverlay.js:669 ([object Array])@chrome://enigmail/content/enigmailMessengerOverlay.js:504 ()@resource://enigmail/enigmailCommon.jsm:1207 And also the following on the console from where I started Icedove (no idea if it might be relevant): (icedove-bin:7621): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion `targets != NULL' failed (icedove-bin:7621): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion `targets != NULL' failed Kind regards, Robert waldner -- -- AssemblerProgrammieren ist wie Onanie: Man hat absolute -- Kontrolle darueber, wo was hinkommt, aber der richtige -- Spass findet woanders statt ... - Herwig Huener signature.asc Description: Digital Signature
Bug#703112: enigmail 1.4.1-2 not decrypting mails/verifying sigs with Icedove 10.0.12-1
Package: enigmail Version: 2:1.4.1-2 Severity: important Hi, I recently moved from i386 to amd64, and since then I can't decrypt/verify mails with enigmail/icedove. Debug output is: 2013-03-15 08:18:20.094 [DEBUG] enigmailMessengerOverlay.js: messageFrameUnload 2013-03-15 08:18:20.094 [DEBUG] enigmailMessengerOverlay.js: messageCleanup 2013-03-15 08:18:20.094 [DEBUG] enigmailMessengerOverlay.js: setAttachmentReveal 2013-03-15 08:18:20.094 [DEBUG] enigmailMsgHdrViewOverlay.js: this.messageUnload 2013-03-15 08:18:20.096 [DEBUG] enigmailMsgHdrViewOverlay.js: _listener_onStartHeaders 2013-03-15 08:18:20.096 [DEBUG] enigmailCommon.jsm: getFrame: name=messagepane 2013-03-15 08:18:20.096 [DEBUG] enigmailMsgHdrViewOverlay.js: msgFrame=[object Window] 2013-03-15 08:18:20.096 [DEBUG] enigmailMsgHdrViewOverlay.js: enigmailPrepSecurityInfo 2013-03-15 08:18:20.107 [DEBUG] enigmailMsgHdrViewOverlay.js: _listener_onEndHeaders 2013-03-15 08:18:20.112 [DEBUG] enigmailMessengerOverlay.js: messageDecrypt: [object Event] 2013-03-15 08:18:20.114 [DEBUG] enigmailCommon.jsm: dispatchEvent f= 2013-03-15 08:18:20.115 [DEBUG] enigmailCommon.jsm: dispatchEvent running mainEvent 2013-03-15 08:18:20.115 [DEBUG] enigmailMessengerOverlay.js: messageDecryptCb: 2013-03-15 08:18:20.115 [DEBUG] enigmailMessengerOverlay.js: header content-type: multipart/encrypted; boundary=--=_1363330633-19056-2; protocol=application/pgp-encrypted 2013-03-15 08:18:20.115 [DEBUG] enigmailMessengerOverlay.js: header content-transfer-encoding: 2013-03-15 08:18:20.115 [DEBUG] enigmailMessengerOverlay.js: header x-enigmail-version: 2013-03-15 08:18:20.115 [DEBUG] enigmailMessengerOverlay.js: header x-pgp-encoding-format: 2013-03-15 08:18:20.115 [DEBUG] enumerateMimeParts: - multipart/encrypted; boundary=--=_1363330633-19056-2; protocol=application/pgp-encrypted 2013-03-15 08:18:20.115 [DEBUG] enumerateMimeParts: 1 - multipart/encrypted; boundary=--=_1363330633-19056-2; protocol=application/pgp-encrypted 2013-03-15 08:18:20.115 [DEBUG] enumerateMimeParts: 1.1 - application/pgp-encrypted 2013-03-15 08:18:20.115 [DEBUG] enumerateMimeParts: 1.2 - application/octet-stream 2013-03-15 08:18:20.115 [DEBUG] enigmailMessengerOverlay.js: embedded objects: 1.1 / 2013-03-15 08:18:20.115 [ERROR] enigmailMessengerOverlay.js: messageDecryptCb: caught exception: TypeError Message: 'Cc[NS_ENIGMIMESERVICE_CONTRACTID] is undefined' File: file:///usr/lib/mozilla/extensions/%7B3550f703-e582-4d05-9a08-453d09bdfdc6%7D/%7B847b3a00-7ab1-11d4-8f02-006008948af5%7D/components/enigmail.js Line:759 Stack: ()@file:///usr/lib/mozilla/extensions/%7B3550f703-e582-4d05-9a08-453d09bdfdc6%7D/%7B847b3a00-7ab1-11d4-8f02-006008948af5%7D/components/enigmail.js:759 ([object Event],true,[object Object])@chrome://enigmail/content/enigmailMessengerOverlay.js:654 ([object Array])@chrome://enigmail/content/enigmailMessengerOverlay.js:504 ()@resource://enigmail/enigmailCommon.jsm:1207 This looks like bug# 671928, yet the enigmail/icedove versions should be compatible (enigmail 1.4.1-2, Icedove 10). Reinstalling both packages doesn't change anything. Marked important because having to save each message and decrypting it on the command line is rather making enigmail useless ;) Please advise. Kind regards, Robert Waldner -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages enigmail depends on: ii gnupg1.4.12-7 ii iceape 2.7.12-1 ii icedove 10.0.12-1 ii libc62.13-38 ii libgcc1 1:4.7.2-5 ii libnspr4-0d 2:4.9.5-1 ii libstdc++6 4.7.2-5 enigmail recommends no packages. enigmail suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699479: snmpd: In the SNMP run name table process names are truncated to 15 chars
Package: snmpd Version: 5.4.3~dfsg-2.7 Severity: normal Dear Maintainer, when querying the system for running processes, like, f'rex, apache2, with OID iso.3.6.1.2.1.25.4.2.1.2.$PID, the resulting string is truncated to 15 characters (16-byte fixed-size buffer, thinking of 0-terminated strings in C?). This is quite annoying since some processes have started to include their full path in this, like apache2: $ snmpwalk -v 2c -c comm localhost iso.3.6.1.2.1.25.4.2.1.2 | grep apach iso.3.6.1.2.1.25.4.2.1.2.1483 = STRING: /usr/sbin/apach ... There are also at least those processes whose names are truncated even though they don't have their path in there: BackupPC_trashC (BackupPC_trashClean) console-kit-dae (console-kit-daemon) enlightenment_f (enlightenment_fm) hald-addon-stor (hald-addon-storage) hald-addon-inpu (hald-addon-input) Maybe this stems from the MIB and not snmpd, but as I don't know anything about MIBs... please reassign if appropriate. cheers, rw -- System Information: Debian Release: 7.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.7.4 (SMP w/6 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages snmpd depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-37 ii libsnmp15 5.4.3~dfsg-2.7 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8 snmpd recommends no packages. snmpd suggests no packages. -- Configuration Files: /etc/default/snmpd changed: export MIBS= SNMPDRUN=yes SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1:161' TRAPDRUN=no TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid' SNMPDCOMPAT=yes -- debconf information: snmpd/upgradefrom521: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647782: dvb-apps: /usr/bin/scan - program name conflicts with nmh's /usr/bin/mh/scan
Package: dvb-apps Version: 1.1.1+rev1355-1 Severity: normal Hi, there's a slight problem for nmh-users (and thus also for users of exmh, which builds on the nmh tools) with the binary name, as nmh brings /usr/bin/mh/scan, and users are expected to put /usr/bin/mh in their $PATH to use nmh. Obviously, only /usr/bin _or_ /usr/bin/mh can be first in $PATH, and one package gets a usability problem in the process. As nmh has been around for a lng time, and this has the potential for problems with another package, exmh, I'm filing this against dvb-apps. (Found when exmh suddenly stopped working properly after installing dvb-apps.) Kind regards, Robert Waldner -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.39-bpo.2-686-pae (SMP w/6 CPU cores) Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages dvb-apps depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii makedev 2.3.1-89 creates device files in /dev ii udev 164-3 /dev/ and hotplug management daemo dvb-apps recommends no packages. dvb-apps suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637159: cpuburn: Just segfaults on ARMel
Package: cpuburn Version: 1.4a-1 Severity: normal Aloha, I have here a QNAP TS-410, which boasts an ARM CPU: ~# cat /proc/cpuinfo Processor : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 799.53 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: QNAP TS-41x ~# /usr/bin/burnCortexA8 Segmentation fault Through strace: root@haviland:~# strace -v -F -f -s 2 /usr/bin/burnCortexA9 execve(/usr/bin/burnCortexA9, [/usr/bin/burnCortexA9], [SHELL=/bin/bash, TERM=Eterm, USER=root, MAIL=/var/mail/root, PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, PWD=/root, LANG=en_US.UTF-8, SHLVL=1, HOME=/root, LANGUAGE=en_US:en, LOGNAME=root, _=/usr/bin/strace]) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault IMHO it should not be installable, or throw a dire warning through debconf, on systems it can't run on. cheers, Robert -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-kirkwood 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 cpuburn depends on: ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy cpuburn recommends no packages. Versions of packages cpuburn suggests: pn hwtools none (no description available) pn kernel-patch-badram none (no description available) pn memtest86 none (no description available) pn memtester none (no description available) -- debconf information: * cpuburn/dangerous: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635599: clamav: Please integrate upstream patch for off-by-one bug in matcher-hash.c
Package: clamav Version: 0.97.1+dfsg-1~lenny1 Severity: important Tags: patch Upstream has a bugreport incl. patch about (what I guess is) an off-by-one error in matcher-hash.c, which makes clamscan crash when encountering specific messages with specially-crafted hashes. See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2818 Patch: http://git.clamav.net/gitweb?p=clamav-devel.git;a=commit;h=4842733eb3f09be61caeed83778bb6679141dbc5 Kind regards, Robert Waldner -- Package-specific info: --- configuration --- Checking configuration files in /etc/clamav Software settings - Version: 0.97.1 Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 JIT Platform information uname: Linux 2.6.18-6-xen-686 #1 SMP Tue May 5 04:56:39 UTC 2009 i686 OS: linux-gnu, ARCH: i386, CPU: i486 Full OS version: Debian GNU/Linux 5.0.8 (lenny) zlib version: 1.2.3.3 (1.2.3.3), compile flags: 55 Triple: i386-pc-linux-gnu CPU: core2, Little-endian platform id: 0x0a113d3d0404030201040302 Build information - GNU C: 4.3.2 (4.3.2) GNU C++: 4.3.2 (4.3.2) CPPFLAGS: CFLAGS: -Wall -g -O2 CXXFLAGS: -Wall -g -O2 LDFLAGS: Configure: '--build=i486-linux-gnu' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-clamav' '--with-dbdir=/var/lib/clamav/' '--sysconfdir=/etc/clamav' '--enable-milter' '--disable-clamuko' '--with-gnu-ld' '--enable-dns-fix' '--disable-unrar' '--libdir=/usr/lib' '--with-system-tommath' '--with-ltdl-include=/usr/include' '--with-ltdl-lib=/usr/lib' 'build_alias=i486-linux-gnu' 'CFLAGS=-Wall -g -O2' 'LDFLAGS=' 'CPPFLAGS=' sizeof(void*) = 4 Engine flevel: 61, dconf: 61 --- data dir --- total 74448 -rw-r--r-- 1 clamav clamav 478208 Jul 14 22:02 bytecode.cld drwxr-xr-x 2 clamav clamav 4096 Apr 3 2008 clamav-b967ef3ba9e3136d55d395c63489fa93 -rw-r--r-- 1 clamav clamav 10220544 Jul 27 04:28 daily.cld drwxr-xr-x 2 clamav clamav 4096 Jul 17 2008 daily.inc -rw-r--r-- 1 clamav clamav 65422336 Nov 14 2010 main.cld drwxr-xr-x 2 clamav clamav 4096 Jul 7 2008 main.inc -rw--- 1 clamav clamav 104 Apr 3 2008 mirrors.dat -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-xen-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages clamav depends on: ii clamav-freshclam [c 0.97.1+dfsg-1~lenny1 anti-virus utility for Unix - viru ii libc6 2.7-18lenny7 GNU C Library: Shared libraries ii libclamav6 0.97.1+dfsg-1~lenny1 anti-virus utility for Unix - libr ii zlib1g 1:1.2.3.3.dfsg-12compression library - runtime Versions of packages clamav recommends: ii clamav-base 0.97.1+dfsg-1~lenny1 anti-virus utility for Unix - base Versions of packages clamav suggests: pn clamav-docs none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506880: udev: /dev/null gets (re-)created with mode 0660 sometimes
Package: udev Version: 0.105-4 Severity: normal Hi, as the subject says, sometimes the permissions of /dev/null, /dev/(u)random and some others gets set to 0660, which obviously is not very useful. It's not related to rebooting, but happens at odd times when the system is otherwise uprunning fine. Searching around on the 'net didn't prove very useful (only some reports without a real solution, for Ubuntu and Slackware variants of udev). grep-ing the /etc/udev* brought no enlightenment either, but running (as suggested in /usr/share/doc/udev/README.Debian.gz) /usr/share/doc/udev/examples/udevtest-all indicates (for a mere sysadmin like me) that somehow udev's to be blamed here: ... main: looking at device '/class/mem/null' from subsystem 'mem' udev_rules_get_name: no node name set, will use kernel name 'null' udev_db_get_device: found a symlink as db file udev_device_event: device '/class/mem/null' already in database, validate curren tly present symlinks udev_node_add: creating device node '/dev/null', major = '1', minor = '3', mode = '0660', uid = '0', gid = '0' ... Any hints? FWIW, this machine's acting as Xen dom0, but this also hit us on some domUs. cheers, Robert Waldner -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 56 -rw-r--r-- 1 root root 3586 2008-08-28 03:39 50-udev.rules -rw-r--r-- 1 root root 1543 2008-08-28 03:39 60-persistent-input.rules -rw-r--r-- 1 root root 4554 2008-08-28 03:39 60-persistent-storage.rules -rw-r--r-- 1 root root 1582 2008-08-28 03:39 60-persistent-storage-tape.rules -rw-r--r-- 1 root root 523 2008-08-28 03:39 60-persistent-v4l.rules -rw-r--r-- 1 root root 1083 2008-07-17 11:53 65_dmsetup.rules -rw-r--r-- 1 root root 496 2007-04-06 02:23 70-persistent-net.rules -rw-r--r-- 1 root root 452 2008-08-28 03:39 75-cd-aliases-generator.rules -rw-r--r-- 1 root root 3081 2008-08-28 03:39 75-persistent-net-generator.rules -rw-r--r-- 1 root root 2282 2008-08-28 03:39 80-drivers.rules -rw-r--r-- 1 root root 4247 2008-08-28 03:39 91-permissions.rules -rw-r--r-- 1 root root 593 2008-08-28 03:39 95-late.rules lrwxrwxrwx 1 root root 20 2007-04-09 00:41 z60_xen-backend.rules - ../xen-backend.rules -- /sys/: /sys/block/cciss!c0d0/cciss!c0d0p1/dev /sys/block/cciss!c0d0/cciss!c0d0p2/dev /sys/block/cciss!c0d0/dev /sys/block/dm-0/dev /sys/block/dm-10/dev /sys/block/dm-11/dev /sys/block/dm-12/dev /sys/block/dm-13/dev /sys/block/dm-14/dev /sys/block/dm-15/dev /sys/block/dm-16/dev /sys/block/dm-17/dev /sys/block/dm-18/dev /sys/block/dm-19/dev /sys/block/dm-1/dev /sys/block/dm-20/dev /sys/block/dm-21/dev /sys/block/dm-22/dev /sys/block/dm-23/dev /sys/block/dm-24/dev /sys/block/dm-25/dev /sys/block/dm-26/dev /sys/block/dm-2/dev /sys/block/dm-3/dev /sys/block/dm-4/dev /sys/block/dm-5/dev /sys/block/dm-6/dev /sys/block/dm-7/dev /sys/block/dm-8/dev /sys/block/dm-9/dev /sys/block/loop0/dev /sys/block/loop1/dev /sys/block/loop2/dev /sys/block/loop3/dev /sys/block/loop4/dev /sys/block/loop5/dev /sys/block/loop6/dev /sys/block/loop7/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/class/input/input0/event0/dev /sys/class/input/input1/event1/dev /sys/class/input/input2/event2/dev /sys/class/input/input2/mouse0/dev /sys/class/input/input2/ts0/dev /sys/class/input/input3/event3/dev /sys/class/input/input4/event4/dev /sys/class/input/input4/mouse1/dev /sys/class/input/input4/ts1/dev /sys/class/input/mice/dev /sys/class/misc/device-mapper/dev /sys/class/misc/evtchn/dev /sys/class/misc/hpet/dev /sys/class/misc/psaux/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev /sys/class/usb_device/usbdev5.1/dev /sys/class/usb_device/usbdev5.2/dev /sys/class/usb_device/usbdev5.3/dev /sys/class/usb_device/usbdev6.1/dev /sys/devices/pci:00/:00:1d.0/usb1/1-0:1.0/usbdev1.1_ep81/dev /sys/devices/pci:00/:00:1d.0/usb1/usbdev1.1_ep00/dev /sys/devices/pci:00/:00:1d.1/usb2/2-0:1.0/usbdev2.1_ep81/dev /sys/devices/pci:00/:00:1d.1/usb2/usbdev2.1_ep00/dev /sys/devices/pci:00/:00:1d.2/usb3/3-0:1.0/usbdev3.1_ep81/dev /sys/devices/pci:00/:00:1d.2/usb3/usbdev3.1_ep00/dev /sys/devices/pci:00/:00:1d.3/usb4/4-0:1.0/usbdev4.1_ep81/dev /sys/devices/pci:00/:00:1d.3/usb4/usbdev4.1_ep00/dev /sys/devices/pci:00/:00:1d.7/usb6/6-0:1.0/usbdev6.1_ep81/dev /sys/devices/pci:00/:00:1d.7/usb6/usbdev6.1_ep00/dev /sys/devices/pci:00/:00:1e.0/:01:04.4/usb5/5-0:1.0/usbdev5.1_ep81/dev /sys/devices/pci:00/:00:1e.0/:01:04.4/usb5/5-1/5-1:1.0/usbdev5.2_ep81/dev /sys/devices/pci:00/:00:1e.0/:01:04.4/usb5/5-1/5-1:1.1/usbdev5.2_ep82
Bug#506880: udev: /dev/null gets (re-)created with mode 0660 sometimes
On Tuesday 25 November 2008 16:21:51 Marco d'Itri wrote: On Nov 25, Robert Waldner [EMAIL PROTECTED] wrote: -rw-r--r-- 1 root root 1083 2008-07-17 11:53 65_dmsetup.rules lrwxrwxrwx 1 root root 20 2007-04-09 00:41 z60_xen-backend.rules - ../xen-backend.rules Please report the content of these files. Nothing relevant there. Any hints on where/what else I could look at? cheers -- / Robert Waldner | [EMAIL PROTECTED] \ \ T: +43 1 5056416 | http://www.cert.at/ / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506880: udev: /dev/null gets (re-)created with mode 0660 sometimes
On Tuesday 25 November 2008 17:04:11 you wrote: Any hints on where/what else I could look at? First, find out how to reliably reproduce the problem. Then raise the log level and echo add /sys/class/mem/null/uevent 'echo add /sys/class/mem/null/uevent' consistently reproduces the problem. gcv:/etc/udev/rules.d# udevcontrol log_priority=debug gcv:/etc/udev/rules.d# ls -la /dev/null /dev/.static/dev/null crw-rw-rw- 1 root root 1, 3 2008-11-04 12:15 /dev/null crw-rw-rw- 1 root root 1, 3 2008-11-25 15:21 /dev/.static/dev/null gcv:/etc/udev/rules.d# echo add /sys/class/mem/null/uevent gcv:/etc/udev/rules.d# ls -la /dev/null /dev/.static/dev/null crw-rw 1 root root 1, 3 2008-11-04 12:15 /dev/null crw-rw-rw- 1 root root 1, 3 2008-11-25 15:21 /dev/.static/dev/null gcv:/etc/udev/rules.d# Nov 25 17:33:23 gcv udevd-event[20819]: udev_rules_get_name: no node name set, will use kernel name 'null' Nov 25 17:33:23 gcv udevd-event[20819]: udev_db_get_device: found a symlink as db file Nov 25 17:33:23 gcv udevd-event[20819]: udev_device_event: device '/class/mem/null' already in database, validate currently present symlinks Nov 25 17:33:23 gcv udevd-event[20819]: udev_node_add: creating device node '/dev/null', major = '1', minor = '3', mode = '0660', uid = '0', gid = '0' Nov 25 17:33:23 gcv udevd-event[20819]: udev_node_mknod: preserve file '/dev/null', because it has correct dev_t Nov 25 17:33:23 gcv udevd-event[20819]: pass_env_to_socket: passed -1 bytes to socket '@/org/kernel/udev/monitor', Nov 25 17:33:23 gcv udevd-event[20819]: udev_event_run: seq 1226 finished Nov 25 17:33:23 gcv udevd[20173]: udev_done: seq 1226, pid [20819] exit with 0, 0 seconds old cheers -- / Robert Waldner | [EMAIL PROTECTED] \ \ T: +43 1 5056416 | http://www.cert.at/ / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505840: kuvert unable to create its temp-directory
Package: kuvert Version: 2.0.0 Severity: normal Hi az, the manpage states for tempdir: The directory is created if necessary, :) [EMAIL PROTECTED]~ $ kuvert -o -d reading config file got config mail-on-error=waldner got config identify=1 got config interval=20 got config can-detach=0 got config defaultaction=signonly overrides Fatal: cant opendir /tmp/kuvert.waldner.3679: No such file or directory :( [EMAIL PROTECTED]~ $ mkdir /tmp/kuvert.waldner.3679 :) [EMAIL PROTECTED]~ $ As an aside, it very definitely sucks that the config-format of kuvert has changed *without any notice whatsoever*. And no, kuvert bomnbing out when used after an upgrade doesn't count. At the very least please notify on upgrade that work on the config's necessary. As another aside, you mis-spelled can't in cant opendir ;) cheers, rw -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-6-686-bigmem (SMP w/2 CPU cores) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages kuvert depends on: ii gnupg 1.4.9-3GNU privacy guard - a free PGP rep ii libc6 2.7-15 GNU C Library: Shared libraries ii libfile-slurp-perl.12-2 single call read write file rout ii libmailtools-perl 2.03-1 Manipulate email in perl programs ii libmime-perl 5.427-1transitional dummy package ii libmime-tools-perl [libmime-p 5.427-1Perl5 modules for MIME-compliant m ii libnet-server-mail-perl 0.17-1 Class to easily create a mail serv ii perl 5.10.0-17 Larry Wall's Practical Extraction ii postfix [mail-transport-agent 2.5.5-1.1 High-performance mail transport ag kuvert recommends no packages. Versions of packages kuvert suggests: pn keyutils none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409461: bash: /usr/bin/bashbug doesn't have a man-page
Package: bash Version: 3.1dfsg-8 Severity: minor The Debian policy states in 12.1 Each program, utility, and function should have an associated manual page included in the same package. Which, in my reading, suggests that even a small utility like bashbug should have its own man-page, even if it's just for cosmetics. cheers, rw -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages bash depends on: ii base-files 4 Debian base system miscellaneous f ii debianutils 2.17Miscellaneous utilities specific t ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libncurses5 5.5-5 Shared libraries for terminal hand bash recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409461: bash: /usr/bin/bashbug doesn't have a man-page
On Sat, 03 Feb 2007 14:43:16 +0100, Matthias Klose writes: Which, in my reading, suggests that even a small utility like bashbug should have its own man-page, even if it's just for cosmetics. ... unless you would like to send a patch. cheers, rw .\ Process this file with .\ groff -man -Tascii foo.1 .\ .TH BASHBUG 1 JANUARY 2007 Linux User Manuals .SH NAME bashbug \- report bugs in GNU bash (Bourne Again SHell) .SH SYNOPSIS .B bashbug [--help] [--version] [bug-report-email-address] .SH DESCRIPTION .B bashbug is used to send mail to the Bash maintainers for when Bash doesn't behave like you'd like, or expect. Bashbug will start up your editor (as defined by the shell's EDITOR environment variable) with a preformatted bug report template for you to fill in. The report will be mailed to the bash maintainers by default. If you invoke bashbug by accident, just quit your editor without saving any changes to the template, and no bug report will be sent. From bash(1): If you find a bug in bash, you should report it. But first, you should make sure that it really is a bug, and that it appears in the latest version of bash. The latest version is always available from ftp://ftp.gnu.org/pub/bash/. .SH OPTIONS .IP --help Display help .IP --version Display version information .IP bug-report-email-address Optionally, define the email-address the bug-report should be sent to. .SH BUGS The author of this man page doesn't know what he's talking about. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409461 .SH AUTHOR Robert Waldner waldner at waldner dot priv dot at .SH SEE ALSO .BR bash (1) -- Hardware: built to fail. -- Software: fails to build. pgpW3UQ3ESAbU.pgp Description: PGP signature
Bug#394556: installation-report: [d-i] [etch rc1] [sparc32] success
Package: installation-reports Version: 2.20 Severity: normal Installation worked as expected. cheers, rw -- Package-specific info: Boot method: netboot Image version: http://people.debian.org/~stappers/d-i/images/daily/sparc32/netboot/2.6/boot.img, 20061019 Date: 20061019 - 20061021 Machine: Sun SparcStation 10 (SS10])= Partitions: df -Tl will do; the raw partition table is preferred FilesystemType 1K-blocks Used Available Use% Mounted on /dev/sda1 ext3 342227265298 59258 82% / udev tmpfs 1024036 10204 1% /dev devshm tmpfs 42964 0 42964 0% /dev/shm Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[O] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Once you have filled out this report, mail it to [EMAIL PROTECTED] == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=3.1 (installer build 20061019) X_INSTALLATION_MEDIUM=netboot-2.6 == Installer hardware-summary: == umame -a: Linux di-test 2.6.17-2-sparc32 #1 Wed Sep 13 09:03:37 PDT 2006 sparc unknown lspci -v -t: -[:00]- lsmod: Module Size Used by lsmod: xfs 491716 0 lsmod: reiserfs 321272 0 lsmod: ext3 144584 1 lsmod: jbd54612 1 ext3 lsmod: vfat 12896 0 lsmod: fat53148 1 vfat lsmod: isofs 29380 0 lsmod: sd_mod 17808 3 lsmod: esp33256 2 lsmod: scsi_mod 99960 2 sd_mod,esp lsmod: sunlance 13936 0 df: Filesystem 1k-blocks Used Available Use% Mounted on df: tmpfs43404 392 43012 1% /dev df: tmpfs43404 392 43012 1% /dev df: tmpfs43404 392 43012 1% /.dev df: /dev/scsi/host0/bus0/target3/lun0/part1342227220528104028 68% /target free: total used free shared buffers free: Mem:8680880684 61240 2960 free: Swap:642521311651136 free: Total: 1510609380057260 cardctl status: /usr/bin/report-hw: /usr/bin/report-hw: 32: pccardctl: not found cardctl ident: /usr/bin/report-hw: /usr/bin/report-hw: 33: pccardctl: not found cardctl status: /usr/bin/report-hw: /usr/bin/report-hw: 34: cardctl: not found cardctl ident: /usr/bin/report-hw: /usr/bin/report-hw: 35: cardctl: not found /proc/cpuinfo: cpu : Texas Instruments, Inc. - MicroSparc /proc/cpuinfo: fpu : SuperSparc on-chip FPU /proc/cpuinfo: promlib : Version 3 Revision 2 /proc/cpuinfo: prom : 2.14 /proc/cpuinfo: type : sun4m /proc/cpuinfo: ncpus probed : 1 /proc/cpuinfo: ncpus active : 1 /proc/cpuinfo: CPU0Bogo : 35.84 /proc/cpuinfo: CPU0ClkTck : 0 /proc/cpuinfo: MMU type : TI Viking /proc/cpuinfo: contexts : 65536 /proc/cpuinfo: nocache total: 2252800 /proc/cpuinfo: nocache used : 570880 /proc/interrupts: 4: 443884ESP SCSI /proc/interrupts: 6: 81656LANCE /proc/interrupts: 10:9364298 + timer /proc/interrupts: 11: 8 + floppy /proc/interrupts: 12: 313679SunZilog /proc/meminfo: MemTotal:86808 kB /proc/meminfo: MemFree: 6004 kB /proc/meminfo: Buffers: 2960 kB /proc/meminfo: Cached: 57424 kB /proc/meminfo: SwapCached: 9840 kB /proc/meminfo: Active: 45744 kB /proc/meminfo: Inactive:25208 kB /proc/meminfo: HighTotal: 48448 kB /proc/meminfo: HighFree: 408 kB /proc/meminfo: LowTotal:38360 kB /proc/meminfo: LowFree: 5596 kB /proc/meminfo: SwapTotal: 64252 kB /proc/meminfo: SwapFree:51136 kB /proc/meminfo: Dirty: 320 kB /proc/meminfo: Writeback: 0 kB /proc/meminfo: Mapped: 11904 kB /proc/meminfo: Slab: 5604 kB /proc/meminfo: CommitLimit:107656 kB /proc/meminfo: Committed_AS:17572 kB /proc/meminfo: PageTables:
Bug#385752: jpilot crashes at startup - glibc error: invalid pointer
Package: jpilot Version: 0.99.7-0.99.8-pre8-1 Severity: important Hi! When starting jpilot, it immediately crashes with a glibc error: :) [EMAIL PROTECTED]~ $ jpilot *** glibc detected *** free(): invalid pointer: 0x080fd8e8 *** Aborted As a workaround it's possible to run jpilot with less efficient malloc implementation (as stated in malloc(3), as in :( [EMAIL PROTECTED]~ $ MALLOC_CHECK_=1 jpilot malloc: using debugging hooks *** glibc detected *** free(): invalid pointer: 0x081004e8 *** *** glibc detected *** free(): invalid pointer: 0x08100520 *** *** glibc detected *** free(): invalid pointer: 0x08100558 *** jpilot then runs as expected. Bug marked serious because a normal user probably wouldn't find out about the MALLOC_CHECK_ option, and thus jpilot would be unusable. cheers, rw -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.13 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages jpilot depends on: ii debconf 1.4.30.13 Debian configuration management sy ii libatk1.0-0 1.12.1-1The ATK accessibility toolkit ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libglib2.0-0 2.10.3-3The GLib library of C routines ii libgtk2.0-0 2.8.10-1The GTK+ graphical user interface ii libpango1.0-01.12.3-1Layout and rendering of internatio ii libpisock8 0.11.8-10 Library for communicating with a P -- debconf information: * shared/pilot/port: ttyUSB1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379788: [Pkg-nagios-devel] Bug#379788: nagios-plugins-standard: check_radius segfaults on AMD64
On Wed, 26 Jul 2006 02:14:14 EDT, sean finney writes: very interesting. i won't have a amd64 machine handy for another 2 weeks, so if you could provide a little more help, it'd be appreciated. could you try rebuilding the package with debug symbols (make sure there's a -g somewhere in debian/rules and that dh_strip is commented out) and print out a backtrace? Sure. nagios2:~# gdb /usr/lib/nagios/plugins/check_radius GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run -P 1812 -u user -p pass -F /etc/radiusclient/radiusclient.conf -H host Starting program: /usr/lib/nagios/plugins/check_radius -P 1812 -u user -p pass -F /etc/radiusclient/radiusclient.conf -H host Program received signal SIGSEGV, Segmentation fault. 0x2b43fb5c28b3 in rc_avpair_insert () from /usr/lib/libradiusclient.so.0 (gdb) bt #0 0x2b43fb5c28b3 in rc_avpair_insert () from /usr/lib/libradiusclient.so.0 #1 0x2b43fb5c2b82 in rc_avpair_add () from /usr/lib/libradiusclient.so.0 #2 0x00401ad3 in main (argc=value optimized out, argv=value optimized out) at check_radius.c:126 cheers, rw -- -- Perilous to all of us are the devices of -- an art deeper than we ourselves possess. -- Gandalf pgpsBqLmIsey3.pgp Description: PGP signature
Bug#378329: backuppc: Problem backing uo files with newline in the filename
Package: backuppc Version: 2.1.1-2sarge2 Severity: normal Hi! One of my users every now and then manages to create files with CR and/or LF in the name, and BackupPC is stopped dead in its tracks wrt. to this file, as it relies on proper line-by-line output from the rsyncp module. For now I just hunt down the file in question, rename it and restart the backup, but in the long run this ain't gonna do. One can easily reproduce the problem by creating a file like this: :) [EMAIL PROTECTED]~/tmp $ touch Hello there :) [EMAIL PROTECTED]~/tmp $ ls -b Hello* Hello\nthere :) [EMAIL PROTECTED]~/tmp $ find . -name Hello\* ./Hello there and then start a backup. In the Xferlog the relevant lines are create 644 1000/1000 0 waldner/tmp/Hello Don't understand 'there' from child Any hints? libfile-rsyncp-perl is at 0.52-1. cheers, rw -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages backuppc depends on: ii adduser 3.63Add and remove users and groups ii apache 1.3.33-6sarge1 versatile, high-performance HTTP s ii apache-ssl 1.3.33-6sarge1 versatile, high-performance HTTP s ii debconf 1.4.30.13 Debian configuration management sy ii dpkg 1.10.28 Package maintenance system for Deb ii libarchive-zip-perl 1.14-1 Module for manipulation of ZIP arc ii libcompress-zlib-perl1.34-1 Perl module for creation and manip ii perl [libdigest-md5-perl 5.8.4-8sarge4 Larry Wall's Practical Extraction ii perl-suid5.8.4-8sarge4 Runs setuid Perl scripts ii samba-common 3.0.14a-3sarge1 Samba common files used by both th ii smbclient3.0.14a-3sarge1 a LanManager-like simple client fo ii tar 1.14-2.2GNU tar ii wwwconfig-common 0.0.43 Debian web auto configuration -- debconf information: * backuppc/add-lines: true * backuppc/configuration-note: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358956: Amazon changed URLs, returns 302, libamazon-ruby not able to follow that
Package: libamazon-ruby Version: 0.9.0-1 Severity: important Hi! While hunting for a bug that prevents alexandria from looking up books, I discovered that it's actually libamazon-ruby that's at fault. The reason for all that is that libamazon-ruby tries to look up information via xml.amazon.com, but Amazon returns a HTTP 302 Object moved, which libamazon-ruby apparently can't handle. The HTTP conversation, as captured by ethereal, looks like this: .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. GET /onca/xml3?t=calibanorg-20AsinSearch=0006479901f=xmltype=heavydev-t=1XQCB3VJ5VW8P8FKFDG2locale=de HTTP/1.1 Accept: */* User-Agent: Ruby/Amazon 0.9.0 Host: xml.amazon.com HTTP/1.1 302 MovedTemporarily Date: Sat, 25 Mar 2006 13:08:55 GMT Server: Server x-amz-id-1: 1ZMQSK6Z491267JFMSYB x-amz-id-2: /Llt7MEQEP660Dxv5M+2RMUnA0U5fhsl Location: http://webservices.amazon.de/onca/xml3?t=calibanorg-20AsinSearch=0006479901f=xmltype=heavydev-t=1XQCB3VJ5VW8P8FKFDG2locale=de nnCoection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 0 .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-. Now, if I change xml.amazon.com to webservices.amazon.com (and accordingly for other LOCALEs) in /usr/lib/ruby/1.8/amazon/search.rb, everything works fine again. Bug marked as important because libamazon-ruby doesn't work without that change. 'course, it'd be nice if it were just able to follow 302s... cheers, rw -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.13 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages libamazon-ruby depends on: ii libruby1.8 [librexml-ruby1.8] 1.8.4-1Libraries necessary to run Ruby 1. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340567: digikam: fails to start with albumtreestate.bin not found
Package: digikam
Version: 0.7.2-2
Severity: normal
As the subject says:
:) [EMAIL PROTECTED]~ $ digikam
digikam: WARNING: [void AlbumFolderView::loadAlbumState()] Failed to
open albumtreestate.bin
(according to strace it tries to open
29036 open(/home/waldner/.kde/share/apps/digikam/albumtreestate.bin,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) )
and then I'm stuck with a splashscreen, and can do nothing. The last
think digicam does is connect to localhost:921 (famd) and then trying to
read from there, but I've no idea what famd's supposed to spew out (if
that has anything to do with the problem).
...
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 10
connect(10, {sa_family=AF_INET, sin_port=htons(921),
sin_addr=inet_addr(127.0.0.1)}, 16) = 0
getegid32() = 1000
geteuid32() = 1000
write(10, \0\0\0\34N0 1000 1000 sockmeister\\n\0, 32) = 32
read(10,
I can't find albumtreesate.bin via the search interface at packages.d.o (even in
unstable) so I'm somewhat at a loss here. There is mention of this problem on
http://sourceforge.net/mailarchive/forum.php?forum_id=35249style=flatviewday=15viewmonth=200408
but it also says that it's fixed - and that mail's from 2004.
(Note: I'm not using KDE per se, but Enlightenment, and pulled in
digikam via simple apt-get install from stable)
cheers,
rw
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.13
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to
[EMAIL PROTECTED])
Versions of packages digikam depends on:
ii kdelibs4 4:3.3.2-6.2 KDE core libraries
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libaudio2 1.7-2 The Network Audio System (NAS). (s
ii libc6 2.3.5-7 GNU C Library: Shared libraries an
ii libexif10 0.6.9-6 library to parse EXIF files
ii libfam0c1022.7.0-6 client library to control the FAM
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib
ii libgcc11:4.0.2-3 GCC support library
ii libgdbm3 1.8.3-2 GNU dbm database routines (runtime
ii libgphoto2-2 2.1.5-6 gphoto2 digital camera library
ii libgphoto2-port0 2.1.5-6 gphoto2 digital camera port librar
ii libice64.3.0.dfsg.1-14sarge1 Inter-Client Exchange library
ii libidn11 0.5.13-1.0GNU libidn library, implementation
ii libimlib2 1.2.0-2.2 powerful image loading and renderi
ii libimlib2-dev 1.2.0-2.2 Imlib2 development files
ii libjpeg62 6b-10 The Independent JPEG Group's JPEG
ii libkexif1 0.2.1-2 library for KDE to read/display/ed
ii libkipi0 0.1.1-2 library for apps that want to use
ii libpng12-0 1.2.8rel-1PNG library - runtime
ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime v
ii libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management
ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3
ii libtiff4 3.7.2-3 Tag Image File Format (TIFF) libra
ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li
ii libxcursor11.1.3-1 X cursor management library
ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte
ii libxft22.1.7-1 FreeType-based font drawing librar
ii libxrandr2 4.3.0.dfsg.1-14sarge1 X Window System Resize, Rotate and
ii libxrender11:0.9.0-2 X Rendering Extension client libra
ii libxt6 4.3.0.dfsg.1-14sarge1 X Toolkit Intrinsics
ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340567: digikam: fails to start with albumtreestate.bin not found
On Thu, 24 Nov 2005 12:29:46 +0100, Achim Bohnet writes: digikam: WARNING: [void AlbumFolderView::loadAlbumState()] Failed to open albumtreestate.bin the album widget saves the state of the tree in this file. When you never run digikam it can't exist. No problem. No package installs files in user home directories! KDE uses ~/.kde to store user specific (config) data. So no chance to find it on p.d.o ;) I thought maybe it'd be copied from somewhere, but if it's generated, of course no chance to find it on p.d.o ;) It was the last message digikam printed, so I thought it likely to be (part of) the problem. I famd running? Yes, of course it's running, otherwise digikam couldn't connect to it: 4985 ?Ss 0:01 /usr/sbin/famd -T 0 Which version ii fam2.7.0-6File Alteration Monitor (Note: I'm not using KDE per se, but Enlightenment, and pulled in digikam via simple apt-get install from stable) Well, I guess here's the culprit. The mixture pkgs from unstable with some stable. In this case the bug would be an improper dependency - but which one? cheers, rw -- -- OS/X: Because making Unix user-friendly -- was easier than debugging Windows. pgpQDXlsWLUbc.pgp Description: PGP signature
Bug#340434: vlc adds broken mailcap entries
Package: vlc Version: 0.8.1.svn20050314-1 Severity: normal Hi! In helping me tracking down problems with exmh and mailcap, Alex Zangerl found out that vlc adds broken entries to /etc/mailcap[0]. From mailcap(5): Each individual mailcap entry consists of a content-type specification, a command to execute, and (possibly) a set of optional flag values. vlc, OTOH, adds entries where a flag field precedes the command, f'rex: application/ogg; nametemplate=%s.ogg; vlc -I rc -V caca '%s'; needsterminal; description=Ogg stream which in turn confuses other programs using the mailcap file (like exmh). The problem actually stems from .../debian/vlc.mime, where those broken entries are spelled out. 0: See Bug#339570 cheers, rw -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages vlc depends on: ii aalib1 1.4p5-22 ascii art library ii dbus-1 0.23.4-1 simple interprocess messaging syst ii liba52-0.7.4 0.7.4-1 Library for decoding ATSC A/52 str ii libc6 2.3.5-8 GNU C Library: Shared libraries an ii libdvbpsi3 0.1.4-2 library for MPEG TS and DVB PSI ta ii libdvdnav4 0.1.9-3 The DVD navigation library ii libdvdread30.9.4-5 Simple foundation for reading DVDs ii libflac6 1.1.1-5 Free Lossless Audio Codec - runtim ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libfribidi00.10.4-6 Free Implementation of the Unicode ii libgcc11:4.0.2-4 GCC support library ii libgcrypt111.2.0-11.1LGPL Crypto library - runtime libr ii libgnutls111.0.16-13.1 GNU TLS library - runtime library ii libgpg-error0 1.0-1 library for common error values an ii libhal00.4.7-3sarge1 Hardware Abstraction Layer - share ii libid3tag0 0.15.1b-4.1 ID3 tag reading library from the M ii liblircclient0 0.7.1pre2-2 LIRC client library ii libmad00.15.1b-1.1 MPEG audio decoder library ii libmodplug01:0.7-4 shared libraries for mod music bas ii libmpeg2-4 0.4.0b-2 MPEG1 and MPEG2 video decoder libr ii libncurses55.5-1 Shared libraries for terminal hand ii libogg01.1.2-1 Ogg Bitstream Library ii libpng12-0 1.2.8rel-1PNG library - runtime ii libstdc++5 1:3.3.5-13The GNU Standard C++ Library v3 ii libtar 1.2.11-2 C library for manipulating tar arc ii libtheora0 0.0.0.alpha4-1.1 The Theora Video Compression Codec ii libvorbis0a1.1.0-1 The Vorbis General Audio Compressi ii libvorbisenc2 1.1.0-1 The Vorbis General Audio Compressi ii libx11-6 6.8.2.dfsg.1-10 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-10 X Window System miscellaneous exte ii libxml22.6.22-2 GNOME XML library ii libxosd2 2.2.14-1.1X On-Screen Display library - runt ii libxv1 4.3.0.dfsg.1-14sarge1 X Window System video extension li ii slang1 1.4.9dbs-8The S-Lang programming library - r ii ttf-freefont 20031008-1.1 Freefont Serif, Sans and Mono True ii wxvlc 0.8.1.svn20050314-1 wxWindows frontend for VLC ii xlibmesa-gl [libgl 4.3.0.dfsg.1-14sarge1 Mesa 3D graphics library [XFree86] ii xlibmesa-glu [libg 4.3.0.dfsg.1-14sarge1 Mesa OpenGL utility library [XFree ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.3-8 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339570: exmh doesn't understand /etc/mailcap
Hi az!
On Tue, 22 Nov 2005 20:32:50 +1000, Alexander Zangerl writes:
This is MPEG Audio
It can be displayed with
nametemplate=/tmp/waldner/1.0=1=2.20424.exmh.mp3.
*sigh* not here :-(
I seem to be good at finding unreproducible bugs in exmh, eh?
i tried your mailcap fragment verbatim in both
places (/etc/mailcap or .mailcap) and it didn't cause any problems
I'm attaching the whole /etc/mailcap, in case that helps - maybe the
order of entries is also relevant? FWIW, it happens _reproducible_
with audio/mpeg - I'm attaching a msg/rfc822 that triggers this (don't
actually listen to the file - it's straight out of /dev/urandom ;) ).
The relevant exmh-log is
12:35:52 (5.028) Msg_Pick line=290
12:35:52 (0.001) Msg_Change id=799
12:35:52 (0.014) {cur: 798 = 799}
12:35:52 (0.001) Writing /home/waldner/Mail/inbox/.mh_sequences
12:35:52 (0.012) Ftoc_ShowSequence cur msgids {798 799}
12:35:52 (0.014) {file delete /tmp/waldner/0.0=1.2962.exmh
/tmp/waldner/0.0=1=1.2962.exmh /tmp/waldner/0.0=1=2.2962.exmh
/tmp/waldner/1.0=1=2.2962.exmh}
12:35:52 (0.023) {Mime_ShowMultipart 0=1 multipart/mixed}
12:35:52 (0.066) exec {sh -c test $(echo 'us-ascii' | tr [A-Z] [a-z]) =
iso-8859-1 -a $DISPLAY != }
12:35:52 (0.016) Msg_TextHighlight 18.0 22.0
12:35:52 (0.010)
12:35:52 (0.224) MimeDecode /tmp/waldner/0.0=1=2.2962.exmh
/tmp/waldner/1.0=1=2.2962.exmh base64 0
12:35:52 (0.000) exec {mimencode -u -b /tmp/waldner/0.0=1=2.2962.exmh @ file8}
12:35:52 (0.012) test.mp3
12:35:53 (0.230)
12:35:53 (0.078) Widget_TextPad h=54 last=55.0 top=11.0
12:35:53 (0.001) test mp3
12:35:53 (0.102) Seq_Del inbox unseen 799 ...
12:35:53 (0.087) {URI_ScanMsg 67.0}
12:35:53 (0.013) Seq_Del inbox unseen 799 ...
12:35:53 (0.001) test mp3
12:35:53 (0.113) Msg_Change {1016295 microseconds per iteration}
What's irritating is that exmh names the file as .mpg, when both the
filename and nametemplate end in .mp3.
are we talking about the same file?
1dead87da16d0569bf04f463e05c0f27 /usr/lib/exmh/mailcap.tcl
Yep, 1dead87da16d0569bf04f463e05c0f27 /usr/lib/exmh/mailcap.tcl
no .exmh/lib lurking behind?
It's there, but only contains two private functions that have nothing
to do with mailcap.
which tcl/tk does your /etc/alternatives/wish
point to? i've got tk8.3 and things work fine...
/etc/alternatives/wish - /usr/bin/wish8.3, which is from tk8.3.
cheers+tia,
rw
###
#
# MIME types and programs that process those types
#
# Much of this file is generated automatically by the program update-mime.
# Please see the update-mime man page for more information.
#
###
###
#
# User section follows: Any entries included in this section will take
# precedence over those created by update-mime. DO NOT CHANGE the
# User Section Begins and User Section Ends lines, or anything outside
# of this section!
#
# - User Section Begins - #
# - User Section Ends - #
###
application/pdf; /usr/bin/acroread '%s'; test=test -n $DISPLAY;
description=Portable Document Format; nametemplate=%s.pdf
application/pdf; false; x-mozilla-flags=plugin:nppdf.so
text/plain; less '%s'; needsterminal
application/vnd.sun.xml.calc; openoffice '%s'; edit=openoffice '%s'; test=test
$DISPLAY != ; description=OpenOffice.org Spreadsheet; nametemplate=%.sxc
application/vnd.sun.xml.calc.template; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ; description=OpenOffice.org Spreadsheet Template;
nametemplate=%.stc
application/vnd.sun.xml.draw; openoffice '%s'; edit=openoffice '%s'; test=test
$DISPLAY != ; description=OpenOffice.org Drawing; nametemplate=%.sxd
application/vnd.sun.xml.draw.template; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ; description=OpenOffice.org Drawing Template;
nametemplate=%.std
application/vnd.sun.xml.impress; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ; description=OpenOffice.org Presentation;
nametemplate=%.sxi
application/vnd.sun.xml.impress.template; openoffice '%s'; edit=openoffice
'%s'; test=test $DISPLAY != ; description=OpenOffice.org Presentation
Template; nametemplate=%.sti
application/vnd.sun.xml.writer; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ; description=OpenOffice.org Text Document;
nametemplate=%.sxw
application/vnd.sun.xml.writer.global; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ; description=OpenOffice.org Master Document;
nametemplate=%.sxg
application/vnd.sun.xml.writer.math; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ; description=OpenOffice.org Maths Document
application/vnd.sun.xml.writer.template; openoffice '%s'; edit=openoffice '%s';
test=test $DISPLAY != ;
Bug#339570: exmh doesn't understand /etc/mailcap
Package: exmh Version: 1:2.7.2-7 Severity: normal Hi! It seems that exmh doesn't understand the Debian format of /etc/mailcap, which is best explained via example: /etc/mailcap: audio/mpeg; beep-media-player '%s'; nametemplate=%s.mp3; test=test $DISPLAY != Would lead exmh to try to start This is MPEG Audio It can be displayed with nametemplate=/tmp/waldner/1.0=1=2.20424.exmh.mp3. If I, however, mangle /etc/mailcap to _not_ contain any nametemplate entries and place it in ~, exmh works as expected - which is what I recommend as a workaround until this is fixed. Funny thing is that the nametemplate issue should be already fixed since 1998 according to http://mercea.net/~exmh/html/exmh-workers/1998-11/msg00011.html - It also adds a sanity check so that entries that read nametemplate=%s will be ignored. - seems like this got lost along the way ;) cheers, rw -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.13 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages exmh depends on: ii metamail 2.7-47implementation of MIME ii mime-support 3.28-1MIME files 'mime.types' 'mailcap ii nmh [mh] 1.1-release-3 A set of electronic mail handling ii tcl8.0 [tclsh] 8.0.5-8 Tcl (the Tool Command Language) v8 ii tcl8.3 [tclsh] 8.3.5-4 Tcl (the Tool Command Language) v8 ii tcl8.4 [tclsh] 8.4.9-1 Tcl (the Tool Command Language) v8 ii tk8.0 [wish] 8.0.5-11 Tk toolkit for Tcl and X11, v8.0 - ii tk8.3 [wish] 8.3.5-4 Tk toolkit for Tcl and X11, v8.3 - ii xterm 4.3.0.dfsg.1-14sarge1 X terminal emulator -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329182: checking of values unknown to siege programmers
Package: siege
Version: 2.61-1
Severity: normal
Tags: patch
Multiple bugs. First about not having understood how HTTP headers are
contructed (= instead of : as separator). Checking the validity of
values is, of course, beyond the thought anyway.
--- siege_orig/siege-2.61/src/http.c2004-11-19 15:47:21.0
+0100
+++ siege/siege-2.61/src/http.c 2005-09-19 17:47:18.119287505 +0200
@@ -374,7 +374,11 @@
else{
h-auth.type.proxy = BASIC;
}
- tmp = strchr( line, '=' );
+ tmp = strchr( line, ':' );
+ if (tmp == NULL) {
+printf(I shat myself so hard..\n);
+return NULL;
+ }
tmp++;
if( tmp[0] == '' ){ tmp++; tmp[strlen(tmp)-1] = '\0'; }
strncpy( h-auth.realm.proxy, tmp, strlen( tmp ));
And in hash.c we're also back to not checking bloody values.
--- siege_orig/siege-2.61/src/hash.c2003-07-09 22:22:38.0
+0200
+++ siege/siege-2.61/src/hash.c 2005-09-19 18:04:19.990104391 +0200
@@ -182,6 +182,7 @@
int x;
NODE *node;
+ if (key == NULL) { return 1; }
x = hash_genkey( this-size, key );
for( node = this-table[x]; node != NULL; node = node-next ){
if( !strcmp( node-key, key )){
cheers,
rw
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages siege depends on:
ii libc6 2.3.5-4GNU C Library: Shared libraries an
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327467: ecartis: New upstream version
Package: ecartis Version: ecartis-1.0.0+cvs.20030911 Severity: wishlist Since ecartis-1.0.0+cvs.20030911 quite some patches have made it into upstream, some security relevant. A new snapshot should be out today. Please either update to a new upstream or drop the package from Debian. cheers, rw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298832: A method for passing arguments with spaces to postgrey
Package: postgrey Version: 1.17-2 Severity: wishlist Hi! At the moment it doesn't seem possible to pass an argument with spaces via /etc/default/postgrey to postgrey, because the shell doesn't expand an argument multiple times. To be more specifix, I'm unable to find a way to pass --greylist-text=Text with blanks to postgrey in a workable manner. I think a good way around all this would be a bit of shuffling around, and to use an array for the options. For example, moving the options in /etc/init.d/postgrey further up: POSTGREY_OPTS=--pidfile=$PIDFILE --daemonize # Read config file if it is present. if [ -r /etc/default/$NAME ] then . /etc/default/$NAME fi change the call from start-stop-daemon: start-stop-daemon --start --quiet --pidfile $PIDFILE \ --exec $DAEMON -- [EMAIL PROTECTED] and, finally, have /etc/default/postgrey contain: POSTGREY_OPTS=($POSTGREY_OPTS --inet=127.0.0.1:6 --delay=10 --greylist-text=Text with blanks.) This way, one can make use of all of postgrey's options in a clean manner. cheers, rw -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.4.27-1-sparc64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages postgrey depends on: ii debconf 1.4.30.11 Debian configuration management sy ii libberkeleydb-perl0.26-3 use Berkeley DB 4 databases from P ii libnet-dns-perl 0.48-1 Perform DNS queries from a Perl sc ii libnet-server-perl0.87-2 An extensible, general perl server ii perl 5.8.4-5Larry Wall's Practical Extraction -- debconf information: postgrey/1.13-5_move-db: postgrey/1.14-1_lookup-by-subnet: postgrey/1.13-5_old-config: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294029: exmh: Problem starting up when current message is encrypted
On Tue, 08 Feb 2005 21:57:57 +1000, Alexander Zangerl writes: Another example is that when starting exmh and the current message is encrypted, the passphrase-dialog grabs the input exclusively (don't know the correct term, sorry), but immediately afterwards the sequences window comes up. This combination somehow puts the focus back exmh's main window and thus effectively renders keyboard input impossible, the only way out I could find up to now is to switch to another tty and `killall exmh`. See screenshot http://www.waldner.priv.at/temp/exmh-startup-prob.jpg [~200 kB] tclsh8.3 (same problem with 8.4), wish8.3, gpg 1.2.3-1 i can not reproduce this at all :-(( i've set up the same tcl/tk versions as you (my gnupg is a little older but that doesn't come into play here), and i'm using your exmh-defaults. the main window, the sequences thing and the passphrase dialog pop up and that's it. gah, how i love heisenbugs. i suspect a window manager issue (i use fvwm2): what are you using? I'm using Enlightenment, 0.16.6-1. With fvwm2, 2.3, the situation is better, though still not bug-free: the passphrase dialog doesn't accept any keyboard input, but at least it's possible to click ok, and the next incarnation of it then works as expected. forwarded to the upstream discussion list with a request for comments; can you please leave your screenshots alive for a couple more days? They're not going to vanish any time soon. cheers, rw -- / Ing. Robert Waldner | Security Engineer | CoreTec IT-Security \ \ [EMAIL PROTECTED] | T +43 1 503 72 73 | F +43 1 503 72 73 x99 / pgpHkPGRBdNgt.pgp Description: PGP signature
Bug#294212: exmh vs. mailcap
Package: exmh Version: 1:2.7.2-2 Severity: minor Hi (az)! (This is a follow-up to bug# 293560, where I reported multiple bugs) -- - 2.7.2 completely ignores the mailcap file -- My previous observation was not entirely correct, though, exmh doesn't /ignore/ the mailcap, it rather seems to somehow mangle Content-Types which contain a dot (like application/vnd.ms-powerpoint). For example, from a raw message: Content-Type: application/vnd.ms-powerpoint; name=file.pps I see in exmh -- 2. file.pps(application/vndms-powerpoint) This is a application/vndms-powerpoint It might be displayable with metamail. (Invoke menu with right button.) name = file.pps disposition = attachment filename = file.pps -- Note the now missing dot in the Content-Type. And thus it's unable to find the correct entry in the mailcap file. Attachments with a COntent-Type without a dot (like image/jpg, or even application/msword) are working as expected. (tclsh8.3, wish8.3) cheers, rw -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux beren 2.4.26-1-686 #1 Sat May 1 18:04:05 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C) Versions of packages exmh depends on: ii metamail 2.7-45.1 An implementation of MIME ii mime-support 3.23-1MIME files 'mime.types' 'mailcap ii nmh [mh] 1.1-release-3 A set of electronic mail handling ii tcl8.0 [tclsh] 8.0.5-7 The Tool Command Language (TCL) v8 ii tcl8.0-ja [tclsh] 8.0.4jp1.3-14 Japanese localized version of tcl ii tcl8.2 [tclsh] 8.2.3-10 The Tool Command Language (TCL) v8 ii tcl8.3 [tclsh] 8.3.5-4 Tcl (the Tool Command Language) v8 ii tcl8.4 [tclsh] 8.4.9-1 Tcl (the Tool Command Language) v8 ii tk8.3 [wish] 8.3.5-4 Tk toolkit for Tcl and X11, v8.3 - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294019: exmh: Opened messages marked like selected ones
Package: exmh Version: 1:2.7.2-2 Severity: minor Hi (az)! (This is a follow-up to bug# 293560, where I reported multiple bugs) --- - a openened message is marked like a selected one what do you mean? i don't see any difference to 2.5 wrt. message marking. --- See http://www.waldner.priv.at/temp/exmh272.jpg vs. http://www.waldner.priv.at/temp/exmh25.jpg (about 50 kB each). -- also, what wish/tclsh versions are active? you have three revisions of tcl/tk installed, what does /etc/alternatives say about them? -- tclsh8.4, wish8.3 cheers, rw -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux beren 2.4.26-1-686 #1 Sat May 1 18:04:05 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C) Versions of packages exmh depends on: ii metamail 2.7-45.1 An implementation of MIME ii mime-support 3.23-1MIME files 'mime.types' 'mailcap ii nmh [mh] 1.1-release-3 A set of electronic mail handling ii tcl8.0 [tclsh] 8.0.5-7 The Tool Command Language (TCL) v8 ii tcl8.0-ja [tclsh] 8.0.4jp1.3-14 Japanese localized version of tcl ii tcl8.2 [tclsh] 8.2.3-10 The Tool Command Language (TCL) v8 ii tcl8.3 [tclsh] 8.3.5-4 Tcl (the Tool Command Language) v8 ii tcl8.4 [tclsh] 8.4.9-1 Tcl (the Tool Command Language) v8 ii tk8.3 [wish] 8.3.5-4 Tk toolkit for Tcl and X11, v8.3 - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293560: multiple bugs in exmh 2.7.2
On Sat, 05 Feb 2005 00:15:44 +1000, Alexander Zangerl writes: Package: exmh Version: 1:2.7.2-2 Severity: normal Thanks for packaging 2.7.2. There a couple bugs, though: sorry, but please submit separate bug reports. there's no way of keeping track of things otherwise. Oh, ok. i will treat this report as including only the syntax error issue; feel free to submit more detail for the others in separate reports. also, what wish/tclsh versions are active? you have three revisions of tcl/tk installed, what does /etc/alternatives say about them? tclsh8.4, wish8.3 for me 8.3 seems to work best, and upstream has indicated that they're not yet fully ready for requiring tk8.4... I'm not sure what pulled tcl8.4 in, but I've now modified the alternatives to use 8.3, no difference. - numerous other errors when opening GnuPG-signes messages, for example -- syntax error in expression int(1+1+(11-)*(101-1-2)/(101-)) while executing expr int($minlineno+1+($msgid-$minmsgid)*($maxlineno-$minlineno-2)/($maxmsgi d-$minmsgid)) (procedure Ftoc_FindMsg line 51) invoked from within Ftoc_FindMsg $msg weird. haven't seen any syntax errors in ages, and i can not confirm this here with signed or signed+encrypted mails. what version of gpg do you have installed? 1.2.3-1, I noticed today that this only affects the first signed message I open after starting exmh, though, subsequent ones are handled just fine. cheers, rw -- / Ing. Robert Waldner | Security Engineer | CoreTec IT-Security \ \ [EMAIL PROTECTED] | T +43 1 503 72 73 | F +43 1 503 72 73 x99 / pgpmGXOv8cmqb.pgp Description: PGP signature
Bug#294029: exmh: Problem starting up when current message is encrypted
Package: exmh Version: 1:2.7.2-2 Severity: important Hi (az)! (This is a follow-up to bug# 293560, where I reported multiple bugs) -- - numerous other errors when opening GnuPG-signes messages, for example -- Another example is that when starting exmh and the current message is encrypted, the passphrase-dialog grabs the input exclusively (don't know the correct term, sorry), but immediately afterwards the sequences window comes up. This combination somehow puts the focus back exmh's main window and thus effectively renders keyboard input impossible, the only way out I could find up to now is to switch to another tty and `killall exmh`. See screenshot http://www.waldner.priv.at/temp/exmh-startup-prob.jpg [~200 kB] tclsh8.3 (same problem with 8.4), wish8.3, gpg 1.2.3-1 Severity important because if one doesn't know of the underlying mh there doesn't seem a way to work around the problem. cheers, rw -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux beren 2.4.26-1-686 #1 Sat May 1 18:04:05 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C) Versions of packages exmh depends on: ii metamail 2.7-45.1 An implementation of MIME ii mime-support 3.23-1MIME files 'mime.types' 'mailcap ii nmh [mh] 1.1-release-3 A set of electronic mail handling ii tcl8.0 [tclsh] 8.0.5-7 The Tool Command Language (TCL) v8 ii tcl8.0-ja [tclsh] 8.0.4jp1.3-14 Japanese localized version of tcl ii tcl8.2 [tclsh] 8.2.3-10 The Tool Command Language (TCL) v8 ii tcl8.3 [tclsh] 8.3.5-4 Tcl (the Tool Command Language) v8 ii tcl8.4 [tclsh] 8.4.9-1 Tcl (the Tool Command Language) v8 ii tk8.3 [wish] 8.3.5-4 Tk toolkit for Tcl and X11, v8.3 - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293560: multiple bugs in exmh 2.7.2
Package: exmh
Version: 1:2.7.2-2
Severity: normal
(Hi az!)
Thanks for packaging 2.7.2. There a couple bugs, though:
- a openened message is marked like a selected one
- passphrase prompting for GnuPG-encrypted messages pretty much locks the
keyboard, but leaves the focus on the (in this case) unresponsive exmh main
window, killing exmh from another tty is the only escape I could find
- 2.7.2 completely ignores the mailcap file
- numerous other errors when opening GnuPG-signes messages, for example
--
syntax error in expression int(1+1+(11-)*(101-1-2)/(101-))
while executing
expr
int($minlineno+1+($msgid-$minmsgid)*($maxlineno-$minlineno-2)/($maxmsgid-$minmsgid))
(procedure Ftoc_FindMsg line 51)
invoked from within
Ftoc_FindMsg $msg
(procedure Ftoc_FindMsgs line 5)
invoked from within
Ftoc_FindMsgs $seqids
(procedure Ftoc_ShowSequence line 21)
invoked from within
Ftoc_ShowSequence $seq $msgids
(procedure Ftoc_ShowSequences line 16)
invoked from within
Ftoc_ShowSequences
(procedure FolderChange line 54)
invoked from within
FolderChange privat/az {Msg_Show cur}
invoked from within
time [list FolderChange $folder $msgShowProc
(procedure Folder_Change line 3)
invoked from within
Folder_Change privat/az
(command bound to event)
--
cheers,
rback to 2.5 for the momentw
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux beren 2.4.26-1-686 #1 Sat May 1 18:04:05 EST 2004 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C)
Versions of packages exmh depends on:
ii metamail 2.7-45.1 An implementation of MIME
ii mime-support 3.23-1MIME files 'mime.types' 'mailcap
ii nmh [mh] 1.1-release-3 A set of electronic mail handling
ii tcl8.0 [tclsh] 8.0.5-7 The Tool Command Language (TCL) v8
ii tcl8.0-ja [tclsh] 8.0.4jp1.3-14 Japanese localized version of tcl
ii tcl8.2 [tclsh] 8.2.3-10 The Tool Command Language (TCL) v8
ii tcl8.3 [tclsh] 8.3.5-4 Tcl (the Tool Command Language) v8
ii tcl8.4 [tclsh] 8.4.9-1 Tcl (the Tool Command Language) v8
ii tk8.3 [wish] 8.3.5-4 Tk toolkit for Tcl and X11, v8.3 -
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292569: kdelibs-data: conflicts with openoffic.org
Package: kdelibs-data Version: 4:3.1.5-1 Severity: serious Justification: unkown Whilst installing amarok, I encountered the following error: Unpacking kdelibs-data (from .../kdelibs-data_4%3a3.3.2-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/kdelibs-data_4%3a3.3.2-1_all.deb (--unpack): trying to overwrite `/usr/share/mimelnk/application/vnd.sun.xml.calc.desktop', which is also in package openoffice.org Installed is openoffice.org 1.0.3-2, on a mixed stable/testing/unstable system. cheers, rw -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26-1-k7 Locale: LANG=C, [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
