Bug#1029105: /usr/bin/getmails: 32: Bad substitution

[Robbie Harwood (frozencemetery)]

Package: getmail6
Version: 6.18.11-1
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

When running getmails, I get this:

$ getmails
/usr/bin/getmails: 32: Bad substitution
$

and it bails out without downloading any mail.

Of course it's still possible to run getmail itself without the wrapper
script.

Be well,
--Robbie

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (700, 'testing-debug'), (700, 'testing'), (500, 
'unstable-debug'), (500, 'unstable'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
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 getmail6 depends on:
ii  python3  3.10.6-3+b1

getmail6 recommends no packages.

getmail6 suggests no packages.

-- no debconf information

Bug#1007226: GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: assertion failed: (tz != NULL)

[Robbie Harwood (frozencemetery)]

Package: libglib2.0-0
Version: 2.70.4-1
Followup-For: Bug #1007226
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

The crash seems to be triggered by one particular message, which I've uploaded
in case it helps:
https://gist.github.com/frozencemetery/cc73375f628c6dbfdbb4834396db9a63

Be well,
--Robbie

Bug#1007226: GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: assertion failed: (tz != NULL)

[Robbie Harwood (frozencemetery)]

Package: libglib2.0-0
Version: 2.70.4-1
Followup-For: Bug #1007226
X-Debbugs-Cc: rharw...@club.cc.cmu.edu


> I think we will really need a backtrace with at least GLib debug symbols,
> and preferably GMime too, so that we can tell what identifier we're trying
> to parse here. (Or you could try loading each individual message into a
> GMime parser, but installing more debug symbols seems easier!)

Loading symbols "the old-fashioned way" against unstable:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x77b74546 in __GI_abort () at abort.c:79
#2  0x77d76ddc in g_assertion_message
(domain=, file=, line=, 
func=, message=) at 
../../../glib/gtestutils.c:3223
#3  0x77dd60bb in g_assertion_message_expr
(domain=domain@entry=0x77e0100e "GLib", file=file@entry=0x77e12e48 
"../../../glib/gtimezone.c", line=line@entry=1960, 
func=func@entry=0x77e13190 <__func__.9> "g_time_zone_new_offset", 
expr=expr@entry=0x77e052fb "tz != NULL") at ../../../glib/gtestutils.c:3249
#4  0x77ddc6a6 in g_time_zone_new_offset (seconds=158400) at 
../../../glib/gtimezone.c:1960
#5  0x77f2be1e in get_tzone (token=token@entry=0x7fffd930) at 
./gmime/gmime-utils.c:505
#6  0x77f2da1c in parse_rfc822_date (tokens=0x5567bf40) at 
./gmime/gmime-utils.c:557
#7  g_mime_utils_header_decode_date (str=str@entry=0x5567d650 "Sun, 13 Mar 
2022 21:00:43 +4400")
at ./gmime/gmime-utils.c:758
#8  0x77f1387e in process_header
(object=object@entry=0x55679440 [GMimeMessage], 
header=header@entry=0x55679c70 [GMimeHeader]) at ./gmime/gmime-message.c:343
#9  0x77f139d2 in message_header_added
(object=0x55679440 [GMimeMessage], header=0x55679c70 [GMimeHeader])
at ./gmime/gmime-message.c:360
#10 0x77f07a2e in g_mime_event_emit (event=0x5558b090, 
args=args@entry=0x7fffda30)
at ./gmime/gmime-events.c:221
#11 0x77f11f31 in _g_mime_header_list_append
(headers=0x5567a400 [GMimeHeaderList], name=0x55644ba0 "Date", 
raw_name=, raw_value=, offset=) at 
./gmime/gmime-header.c:1190
#12 0x77f19259 in _g_mime_object_append_header
(object=object@entry=0x55679440 [GMimeMessage], header=, 
raw_name=, raw_value=, offset=) at 
./gmime/gmime-object.c:852
#13 0x77f20164 in parser_construct_message (options=0x0, 
parser=0x5559f900 [GMimeParser])
at ./gmime/gmime-parser.c:2221
#14 g_mime_parser_construct_message
(parser=parser@entry=0x5559f900 [GMimeParser], 
options=options@entry=0x0)
at ./gmime/gmime-parser.c:2271
#15 0x77f78d78 in _notmuch_message_file_parse (message=0x55622320) 
at lib/message-file.c:161
#16 0x77f793ad in _notmuch_message_file_parse (message=0x55622320) 
at lib/message-file.c:373
#17 _notmuch_message_file_get_headers
(message_file=0x55622320, from_out=0x7fffdbf8, 
subject_out=0x7fffdc08, to_out=0x7fffdc00, date_out=0x7fffdbf0, 
message_id_out=0x7fffdc10) at lib/message-file.c:338
#18 0x77f86c24 in notmuch_database_index_file(notmuch_database_t*, char 
const*, notmuch_indexopts_t*, notmuch_message_t**)
(notmuch=notmuch@entry=0x555a8ba0, 
filename=filename@entry=0x555ac3d0 
"/home/bos/rharwood/Mail/local/new/1647358714.M224828P2714Q0.eesha", 
indexopts=0x555e4600, message_ret=message_ret@entry=0x7fffdd38) at 
lib/add-message.cc:497
#19 0x55564d12 in add_file
(state=0x7fffe100, filename=0x555ac3d0 
"/home/bos/rharwood/Mail/local/new/1647358714.M224828P2714Q0.eesha", 
notmuch=0x555a8ba0) at ./notmuch-new.c:380
#20 add_files
(notmuch=notmuch@entry=0x555a8ba0, path=path@entry=0x55621b50 
"/home/bos/rharwood/Mail/local/new", state=state@entry=0x7fffe100) at 
./notmuch-new.c:726
#21 0x55564a49 in add_files
(notmuch=notmuch@entry=0x555a8ba0, path=path@entry=0x5565f2f0 
"/home/bos/rharwood/Mail/local", state=state@entry=0x7fffe100) at 
./notmuch-new.c:613
#22 0x55564a49 in add_files
(notmuch=notmuch@entry=0x555a8ba0, path=path@entry=0x555c1830 
"/home/bos/rharwood/Mail", state=state@entry=0x7fffe100) at 
./notmuch-new.c:613
#23 0x5556596d in notmuch_new_command
(notmuch=0x555a8ba0, argc=, argv=) at 
./notmuch-new.c:1252
#24 0xe9b7 in main (argc=2, argv=0x7fffe8b8) at ./notmuch.c:604
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x77b74546 in __GI_abort () at abort.c:79
#2  0x77d76ddc in g_assertion_message (domain=, 
file=, line=, func=, 
message=) at ../../../glib/gtestutils.c:3223
#3  0x77dd60bb in g_assertion_message_expr 
(domain=domain@entry=0x77e0100e "GLib", file=file@entry=0x77e12e48 
"../../../glib/gtimezone.c", line=line@entry=1960, 
func=func@entry=0x77e13190 <__func__.9> "g_time_zone_new_offset", 
expr=expr@entry=0x77e052fb "tz != NU

Bug#1007226: GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: assertion failed: (tz != NULL)

[Robbie Harwood (frozencemetery)]

Package: libglib2.0-0
Version: 2.71.3-1
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

When running `notmuch new`, I get this error:

**
GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: assertion 
failed: (tz != NULL)
Bail out! GLib:ERROR:../../../glib/gtimezone.c:2051:g_time_zone_new_offset: 
assertion failed: (tz != NULL)

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
Download failed: Invalid argument.  Continuing without source file 
./signal/../sysdeps/unix/sysv/linux/raise.c.
49  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x77b70546 in __GI_abort () at abort.c:79
#2  0x77d72dcc in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77dd26cb in g_assertion_message_expr () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77dd8da6 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x77f32a1c in g_mime_utils_header_decode_date () at 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0
#6  0x77f1887e in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#7  0x77f189d2 in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#8  0x77f0ca2e in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#9  0x77f16f31 in  () at /lib/x86_64-linux-gnu/libgmime-3.0.so.0
#10 0x77f25164 in g_mime_parser_construct_message () at 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0
#11 0x77f7dd78 in _notmuch_message_file_parse (message=0x5561aef0) 
at lib/message-file.c:161
#12 0x77f7e3ad in _notmuch_message_file_parse (message=0x5561aef0) 
at lib/message-file.c:373
#13 _notmuch_message_file_get_headers (message_file=0x5561aef0, 
from_out=0x7fffdb88, subject_out=0x7fffdb98, to_out=0x7fffdb90, 
date_out=0x7fffdb80, message_id_out=0x7fffdba0) at 
lib/message-file.c:338
#14 0x77f8bc24 in notmuch_database_index_file(notmuch_database_t*, char 
const*, notmuch_indexopts_t*, notmuch_message_t**)
(notmuch=notmuch@entry=0x555a8ba0, 
filename=filename@entry=0x55619f30 
"/home/frozencemetery/Mail/local/new/1647044095.M257021P4675Q1.akroma", 
indexopts=0x555de400, message_ret=message_ret@entry=0x7fffdcc8)
at lib/add-message.cc:497
#15 0x55564d12 in add_file (state=0x7fffe090, 
filename=0x55619f30 
"/home/frozencemetery/Mail/local/new/1647044095.M257021P4675Q1.akroma", 
notmuch=0x555a8ba0) at ./notmuch-new.c:380
#16 add_files (notmuch=notmuch@entry=0x555a8ba0, 
path=path@entry=0x567c3d70 "/home/frozencemetery/Mail/local/new", 
state=state@entry=0x7fffe090) at ./notmuch-new.c:726
#17 0x55564a49 in add_files (notmuch=notmuch@entry=0x555a8ba0, 
path=path@entry=0x556123a0 "/home/frozencemetery/Mail/local", 
state=state@entry=0x7fffe090) at ./notmuch-new.c:613
#18 0x55564a49 in add_files (notmuch=notmuch@entry=0x555a8ba0, 
path=path@entry=0x555dceb0 "/home/frozencemetery/Mail", 
state=state@entry=0x7fffe090) at ./notmuch-new.c:613
#19 0x5556596d in notmuch_new_command (notmuch=0x555a8ba0, 
argc=, argv=) at ./notmuch-new.c:1252
#20 0xe9b7 in main (argc=2, argv=0x7fffe848) at ./notmuch.c:604
(gdb) 

(I don't know what's going on with the missing symbols - debuginfod fetched
the rest, but not those.)

This happens on both the version in unstable and experimental.  Possibly
related is that my timezone switched to daylight savings today.

Be well,
--Robbie

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-3-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libglib2.0-0 depends on:
ii  libc62.33-7
ii  libffi8  3.4.2-4
ii  libmount12.37.3-1+b1
ii  libpcre3 2:8.39-13
ii  libselinux1  3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.70.4-1
ii  shared-mime-info  2.1-2
ii  xdg-user-dirs 0.17-2

libglib2.0-0 suggests no packages.

-- no debconf information

Bug#988817: fwupd: Recommends on nonexistent package secureboot-db

[Robbie Harwood (frozencemetery)]

Package: fwupd
Version: 1.7.4-2
Followup-For: Bug #988817
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

It's been rather a while, so I no longer remember, but it may have just been
my own curiosity.  I did check again and none of the apt* that I use seem to
complain.

Be well,
--Robbie

Bug#995084: mnemosyne: missing dependency on python3-argon2

[Robbie Harwood (frozencemetery)]

Package: mnemosyne
Version: 2.8+ds1-1
Followup-For: Bug #995084
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: tag -1 patch

Dear Maintainer,

mnemosyne needs to depend on python3-argon2.  Without that, it will fail with
the traceback (duplicated in popup):

An unexpected error has occurred.
Please forward the following info to the developers:

Traceback (innermost last):
  File "/usr/bin/mnemosyne", line 278, in 
mnemosyne.initialise(data_dir=data_dir, filename=filename,
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 400, in initialise
self.register_components()
  File "/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/__init__.py", 
line 465, in register_components
importlib.import_module(module_name), class_name)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in 
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in 
_call_with_frames_removed
  File 
"/usr/lib/python3/dist-packages/mnemosyne/pyqt_ui/qt_sync_server.py", line 15, 
in 
from mnemosyne.libmnemosyne.sync_server import SyncServer
  File 
"/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/sync_server.py", line 9, 
in 
from argon2 import PasswordHasher
 ModuleNotFoundError: No module named 'argon2'

Once python3-argon2 is installed, everything is roses.

Please add the dependency.

Be well,
--Robbie

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
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 mnemosyne depends on:
ii  libjs-sphinxdoc 3.5.4-2
ii  libqt5sql5-sqlite   5.15.2+dfsg-12
ii  python3 3.9.2-3
ii  python3-cheroot 8.5.2+ds1-3
ii  python3-cherrypy3   8.9.1-8
ii  python3-gtts2.0.3-1
ii  python3-matplotlib  3.3.4-2
ii  python3-pil 8.1.2+dfsg-0.3
ii  python3-pyqt5   5.15.4+dfsg-4
ii  python3-pyqt5.qtsql 5.15.4+dfsg-4
ii  python3-pyqt5.qtwebchannel  5.15.4+dfsg-4
ii  python3-pyqt5.qtwebengine   5.15.4-2+b1
ii  python3-webob   1:1.8.6-1.1

mnemosyne recommends no packages.

mnemosyne suggests no packages.

-- no debconf information

Bug#994507: O: gssproxy -- Privilege separation daemon for GSSAPI

[Robbie Harwood (frozencemetery)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: affects -1 src:gssproxy

I intend to orphan the gssproxy package.

The package description is:
 Applications can choose to use GSS-Proxy for GSSAPI credential management,
 which means that they will not have direct access to the credentials
 themselves.  GSSAPI operations are also offloaded to the gssproxy daemon,
 making it suitable for upcalls from the Kernel as well.
 .
 This package includes both the gssproxy daemon itself and the GSSAPI
 interposer layer for existing applications.

There's nothing particularly wrong with gssproxy, but I am no longer paid to
work on it.

It would help prospective maintainers to have good knowledge of GSSAPI and
NFS.

Be well,
--Robbie

Bug#994508: O: python-gssapi -- Python 3 interface to GSSAPI

[Robbie Harwood (frozencemetery)]

Package: wnpp
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: affects -1 src:python-gssapi

I intend to orphan the python-gssapi package.

The package description is:
 Python3 Bindings for GSSAPI.  These bindings are for both RFC 2743/2744 and
 many extensions.  They are native bindings produced using Cython.
 .
 Available extensions will vary based on what your GSSAPI implementation
 supports; see package documentation for a detailed list of what is available.

There's nothing particularly wrong with python-gssapi, but I am no longer paid
to work on it.

Large codebase churn is unexpected, though new features may be added by
upstream.

Be well,
--Robbie

Bug#989021: rxvt-unicode: new usptream version available: 9.26

[Robbie Harwood (frozencemetery)]

Source: rxvt-unicode
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

Version 9.26 is available upstream: http://dist.schmorp.de/rxvt-unicode/
(This isn't particularly high priority for me since you've already patched the
recent CVE.)

Thanks,
--Robbie

Bug#988817: fwupd: Recommends on nonexistent package secureboot-db

[Robbie Harwood (frozencemetery)]

Package: fwupd
Version: 1.5.7-3
Severity: minor
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

fwupd currently has:

Recommends: python3, bolt, dbus, secureboot-db, udisks2, fwupd-signed

but there is no package called secureboot-db.

May you be well,
--Robbie

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (700, 'unstable-debug'), (700, 'testing-debug'), (700, 
'unstable'), (700, 'testing'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 fwupd depends on:
ii  libc6  2.31-12
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-3
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-4
ii  libfwupdplugin11.5.7-4
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-4
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-30
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-5
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+3
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#988816: fwupd: cannot install with fwupd-amd64-signed

[Robbie Harwood (frozencemetery)]

Package: fwupd
Version: 1.5.7-3
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

It's not currently possible to update to fwupd-1.5.7-3:

fwupd-amd64-signed : Depends: fwupd (= 1.5.7-3) but 1.5.7-4 is to be 
installed

>From the outside it looks like these two need to be updated in lockstep.
There already is a corresponding bug on fwupd-amd64-signed (#973715), but it
has been several days without any activity there.

May you be well,
--Robbie

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (700, 'unstable-debug'), (700, 'testing-debug'), (700, 
'unstable'), (700, 'testing'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 fwupd depends on:
ii  libc6  2.31-12
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-3
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-4
ii  libfwupdplugin11.5.7-4
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-4
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-30
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-5
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+3
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#985744: libapache2-mod-auth-gssapi: Upstream repo has moved

[Robbie Harwood (frozencemetery)]

Package: libapache2-mod-auth-gssapi
Severity: normal
X-Debbugs-Cc: rharw...@club.cc.cmu.edu

Dear Maintainer,

We've moved the repo for mod_auth_gssapi to
https://github.com/gssapi/mod_auth_gssapi .  GitHub should redirect
everything, but just in case.

Thanks,
--Robbie

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (700, 'unstable-debug'), (700, 'testing-debug'), (700, 
'unstable'), (700, 'testing'), (300, 'experimental-debug'), (300, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-4-rt-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libapache2-mod-auth-gssapi depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.46-4
ii  libc6   2.31-10
ii  libgssapi-krb5-21.18.3-4
ii  libssl1.1   1.1.1j-1

libapache2-mod-auth-gssapi recommends no packages.

libapache2-mod-auth-gssapi suggests no packages.

Bug#978931: gssproxy: CVE-2020-12658

[Robbie Harwood (frozencemetery)]

Package: gssproxy
Followup-For: Bug #978931
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: severity -1 minor
Control: close -1

Hi,

I (upstream and downstream maintainer) do not believe this is CVE-worthy and
have filed dispute claim with Mitre.

The code change in question only happens in a shutdown path.  So even a DoS
here makes no sense as a concept - gssproxy is shutting down already.

If we receive more information that updates that understanding, I'm happy to
adjust accordingly, but upstream was not contacted or involved in any way in
this.

Thanks,
--Robbie

Bug#798899: vlc: Segmentation fault when playing video

[Robbie Harwood (frozencemetery)]

Package: vlc
Version: 2.2.1-3
Severity: important

Dear Maintainer,

When trying to open certain video files, vlc segfaults.  Traceback follows:

GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/vlc...Reading symbols from 
/usr/lib/debug/.build-id/90/c97846f85649757361feb9eae4bb8d39c6c01e.debug...done.
done.
(gdb) r
Starting program: /usr/bin/vlc OldSouls\ Speedruns\ with\ some\ 
Beats-v14088611.mp4
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
VLC media player 2.2.0-rc2 Weatherwax (revision 2.2.0-rc1-118-g22fda39)

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x708d8864 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#2  0x708cb6af in lua_pushstring ()
   from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#3  0x70b0c90a in vlclua_input_metas_internal (
p_item=, L=0x70b7c0) at lua/libs/input.c:159
#4  vlclua_input_item_metas (L=0x70b7c0) at lua/libs/input.c:297
#5  0x708cfc3d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#6  0x708db59d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#7  0x708cffa8 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#8  0x708cf5bf in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#9  0x708d0201 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#10 0x708cc186 in lua_pcallk ()
   from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#11 0x70b030d3 in run (p_context=0x0, 
luafunction=0x70b1763c "read_meta", L=0x70b7c0, 
psz_filename=0x70b060 "/usr/lib/vlc/lua/meta/reader/filename.luac", 
p_this=0x702b98) at lua/meta.c:128
#12 read_meta (p_this=0x702b98, 
psz_filename=0x70b060 "/usr/lib/vlc/lua/meta/reader/filename.luac", 
p_context=) at lua/meta.c:213
#13 0x70b05880 in vlclua_scripts_batch_execute (p_this=0x702b98, 
luadirname=, func=0x70b03010 , 
user_data=0x0) at lua/vlc.c:299
#14 0x7717bee5 in ?? () from /usr/lib/libvlccore.so.8
#15 0x7717c4ae in vlc_module_load () from /usr/lib/libvlccore.so.8
#16 0x7713fca3 in ?? () from /usr/lib/libvlccore.so.8
#17 0x77142604 in ?? () from /usr/lib/libvlccore.so.8
#18 0x7714673d in input_Read () from /usr/lib/libvlccore.so.8
#19 0x7711c775 in ?? () from /usr/lib/libvlccore.so.8
#20 0x77117af8 in ?? () from /usr/lib/libvlccore.so.8
#21 0x77113708 in ?? () from /usr/lib/libvlccore.so.8
#22 0x7710496c in libvlc_InternalInit () from /usr/lib/libvlccore.so.8
#23 0x77bc2a8b in libvlc_new () from /usr/lib/libvlc.so.5
#24 0x00401266 in main (i_argc=, 
ppsz_argv=0x7fffe830) at vlc.c:228
(gdb) 

Thanks!

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'stable'), (600, 'testing'), (400, 
'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages vlc depends on:
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-43
ii  libavcodec-ffmpeg56 7:2.7.2-2+b1
ii  libavutil-ffmpeg54  7:2.7.2-2+b1
ii  libc6   2.19-18+deb8u1
ii  libcaca00.99.beta19-2
ii  libcairo2   1.14.0-2.1
ii  libegl1-mesa [libegl1-x11]  10.3.2-1+deb8u1
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-4
ii  libfreetype62.5.2-3
ii  libfribidi0 0.19.6-3
ii  libgcc1 1:4.9.2-10
ii  libgl1-mesa-glx [libgl1]10.3.2-1+deb8u1
ii  libgles1-mesa [libgles1]10.3.2-1+deb8u1
ii  libgles2-mesa [libgles2]10.3.2-1+deb8u1
ii  libglib2.0-02.42.1-1
ii  libpulse0   5.0-13
ii  libqt5core5

Bug#767188: libvirt-clients: Cannot access storage file error: success

[frozencemetery]

Package: libvirt-clients
Version: 1.2.9-3
Severity: normal

Dear Maintainer,

When trying to create a pre-exsting machine defined by an earlier version of
virt-manager, I get:

# virsh create /etc/libvirt/qemu/eudev.xml 
error: Failed to create domain from /etc/libvirt/qemu/eudev.xml
error: Cannot access storage file '/var/lib/libvirt/images/eudev.qcow2' (as 
uid:114, gid:127): Success

Thanks!

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (400, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libvirt-clients depends on:
ii  libapparmor12.8.0-8
ii  libaudit1   1:2.4-1
ii  libavahi-client30.6.31-4
ii  libavahi-common30.6.31-4
ii  libc6   2.19-11
ii  libcap-ng0  0.7.4-2
ii  libdbus-1-3 1.8.8-2
ii  libdevmapper1.02.1  2:1.02.90-2
ii  libgnutls-deb0-28   3.3.8-3
ii  libnl-3-200 3.2.24-2
ii  libnl-route-3-200   3.2.24-2
ii  libnuma12.0.10~rc2-3
ii  libreadline66.3-8
ii  libsasl2-2  2.1.26.dfsg1-12
ii  libselinux1 2.3-2
ii  libssh2-1   1.4.3-4
ii  libsystemd0 215-5+b1
ii  libvirt01.2.9-3
ii  libxml2 2.9.1+dfsg1-4
ii  libyajl22.1.0-2

libvirt-clients recommends no packages.

libvirt-clients 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#764564: openrc: fail to boot when encryption + lvm are present

[frozencemetery]

Source: openrc
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When upgrading a sysv system (jessie) to openrc, if the partition table
includes a lvm partition with physical volume an encrypted partition,
installing openrc will render the system unbootable.

That is, the system will hang like so:
https://www.club.cc.cmu.edu/~rharwood/tmp/openrc.png
with the "perf interrupt" occuring after a few minutes of waiting and no
further activity.

This is a major problem because this partition layout is one of those
*recommended by the installer* for automatic partitioning.  As far as I can
tell, openrc is capable of booting both encrypted and LVM partitions
individually, but not both.

The minimized partition layout I use which fails is:

- disk 1: MSDOS table
  - partition 1: 200MB ext4, /boot
  - partition 2: *, physical volume for encryption
- subpartition 1: *, physical volume for LVM
  - subsubpartition 1: * ext4, /

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (400, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761347: mpd: Crash when enquing

[frozencemetery]

Package: mpd
Version: 0.18.13-1
Severity: important

Dear Maintainer,

When enqueueing a file to mpd, occasionally the following crash (captured in
gdb) will occur:

[Switching to Thread 0x7fffe2c3b700 (LWP 26272)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x735364cf in av_match_name () from
/usr/lib/x86_64-linux-gnu/libavutil.so.54
#2  0x746ed5f4 in av_probe_input_format2 () from
/usr/lib/x86_64-linux-gnu/libavformat.so.56
#3  0x746ed7c6 in av_probe_input_format () from
/usr/lib/x86_64-linux-gnu/libavformat.so.56
#4  0x004486bb in ffmpeg_probe (decoder=decoder@entry=0x7fffe2c3aaa0,
is=...)
at src/decoder/FfmpegDecoderPlugin.cxx:390
#5  0x00448abf in ffmpeg_decode (decoder=..., input=...)
at src/decoder/FfmpegDecoderPlugin.cxx:396
#6  0x0041e942 in StreamDecode (this=0x474e40 ,
is=..., decoder=...)
at src/DecoderPlugin.hxx:131
#7  decoder_stream_decode (plugin=..., decoder=..., input_stream=...) at
src/DecoderThread.cxx:131
#8  0x0041eda5 in decoder_run_file (
path_fs=0x7fffcc001b08 "/home/frozencemetery/Music/Meshuggah/I/1-01
I.m4a", decoder=...)
at src/DecoderThread.cxx:320
#9  decoder_run_song (dc=..., song=song@entry=0x7fffdc001090, 
uri=0x7fffcc001b08 "/home/frozencemetery/Music/Meshuggah/I/1-01 I.m4a") at
src/DecoderThread.cxx:351
#10 0x0041f07b in decoder_run (dc=...) at src/DecoderThread.cxx:400
#11 decoder_task (arg=0x7fffe343bc10) at src/DecoderThread.cxx:424
#12 0x0046a49e in Thread::ThreadProc (ctx=) at
src/thread/Thread.cxx:104
#13 0x7fffef1100a4 in start_thread (arg=0x7fffe2c3b700) at
pthread_create.c:309
#14 0x7fffeee45c2d in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) 

My guess based on where the traceback goes is that this is the fault of libav,
though I have not troubleshot farther.

Thanks!


-- System Information:
Debian Release: jessie/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mpd depends on:
ii  adduser   3.113+nmu3
ii  init-system-helpers   1.21
ii  libadplug-2.2.1-0 2.2.1+dfsg3-0.1
ii  libao41.1.0-3
ii  libasound21.0.28-1
ii  libaudiofile1 0.3.6-2
ii  libavahi-client3  0.6.31-4
ii  libavahi-common3  0.6.31-4
ii  libavcodec56  6:11~beta1-2
ii  libavformat56 6:11~beta1-2
ii  libavutil54   6:11~beta1-2
ii  libbz2-1.01.0.6-7
ii  libc6 2.19-10
ii  libcdio-cdda1 0.83-4.2
ii  libcdio-paranoia1 0.83-4.2
ii  libcdio13 0.83-4.2
ii  libcurl3-gnutls   7.37.1-1
ii  libfaad2  2.7-8
ii  libflac8  1.3.0-2
ii  libfluidsynth11.1.6-2
ii  libglib2.0-0  2.40.0-5
ii  libgme0   0.5.5-2
ii  libid3tag00.15.1b-11
ii  libiso9660-8  0.83-4.2
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20140719git3eb0ae6a~dfsg-1
ii  libmad0   0.15.1b-8
ii  libmikmod33.3.6-4
ii  libmms0   0.6.2-4
ii  libmodplug1   1:0.8.8.4-4.1
ii  libmp3lame0   3.99.5+repack1-5
ii  libmpcdec62:0.1~r459-4.1
ii  libmpdclient2 2.9-1
ii  libmpg123-0   1.20.1-2
ii  libogg0   1.3.2-1
ii  libopenal11:1.15.1-5
ii  libopus0  1.1-2
ii  libpulse0 5.0-6
ii  libresid-builder0c2a  2.1.1-14
ii  libroar2  1.0~beta11-1
ii  libsamplerate00.1.8-8
ii  libshout3 2.3.1-3
ii  libsidplay2   2.1.1-14
ii  libsidutils0  2.1.1-14
ii  libsndfile1   1.0.25-9
ii  libsqlite3-0  3.8.6-1
ii  libstdc++64.9.1-12
ii  libsystemd-daemon0208-8
ii  libvorbis0a   1.3.2-1.4
ii  libvorbisenc2 1.3.2-1.4
ii  libvorbisfile31.3.2-1.4
ii  libwavpack1   4.70.0-1
ii  libwildmidi1  0.3.7-1
ii  libwrap0  7.6.q-25
ii  libyajl2  2.1.0-2
ii  libzzip-0-13  0.13.62-3
ii  lsb-base  4.1+Debian13

mpd re

Bug#761139: emacs-goodies-el: rfcview.el does not obey fill-column

[frozencemetery]

Package: emacs-goodies-el
Version: 35.12
Severity: minor
Tags: upstream patch

Dear Maintainer,

When viewing RFCs, the page numbers are placed such that they end at the 79th
character.  However, in cases where fill-column is lower than 79 and the
buffer width is equal to the fill-column, this will produce another line
having as its contents a piece of the page number information.

The fix is a simple one-line change on this line:
https://gist.github.com/frozencemetery/97ae92e42a1f37ad5272#file-rfcview-el-L379

Thanks!


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (400, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages emacs-goodies-el depends on:
ii  bash   4.3-9
ii  dpkg   1.17.13
ii  emacs24-nox [emacsen]  24.3+1-4+b1
ii  install-info   5.2.0.dfsg.1-4

Versions of packages emacs-goodies-el recommends:
ii  dict  1.12.1+dfsg-2
ii  perl-doc  5.20.0-6
ii  wget  1.15-1+b1

emacs-goodies-el 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#751270: bitlbee: Twitter broken in Stable's Bitlbee (Please Backport?)

[frozencemetery]

Package: bitlbee
Version: 3.0.5-1.2
Severity: wishlist

Dear Maintainer,

It is currently impossible to use a Twitter account through the Bitlbee in
Stable.  According to the Bitlbee Version Reference [0], the version currently
in Testing should be able to perform this task.

However, it is not possible to install the Testing version of Bitlbee onto
Stable currently (requires newer libc).  Could we have the Testing version of
Bitlbee available through wheezy-backports?

Thanks!

[0]: http://wiki.bitlbee.org/VersionReference

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (800, 'stable-updates'), (800, 'stable'), (600, 'testing'), (400, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bitlbee depends on:
ii  bitlbee-common  3.0.5-1.2
ii  debianutils 4.3.2
ii  libc6   2.13-38+deb7u1
ii  libevent-2.0-5  2.0.19-stable-3
ii  libgcrypt11 1.5.0-5+deb7u1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgnutls26 2.12.20-8+deb7u2

bitlbee recommends no packages.

bitlbee 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#702380: zathura doesn't respond to exit commands while rendering

[frozencemetery]

Sebastian Ramacher  writes:

> On 2013-03-05 16:12:29, frozencemetery wrote:
>> >> However, I also can't get zathura to exit when viewing the pdf in the
>> >> experimental version; it ceased responding to non-scroll input and loaded 
>> >> up
>> >> the CPU.  Subjectively, up until I lost response, the rendering took 
>> >> longer
>> >> but the rest of the interface (especially scrolling) was more responsive.
>> 
>> I guess that can only be fixed killing the render thread. At the moment we
>> wait until the current page rendering job is done. However, I think this can
>> be improved in a way that the user doesn't notice anything.  We should be 
>> able
>> to destroy the GUI and then wait for the render thread. Mind filling a new 
>> bug
>> about that?
>
> So we reworked most of the render code and hope that the situation is a bit
> better. Would you mind checking if it got better for you with 0.2.6-1?

That is a lot better, thanks!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#722996: wireshark: Builds for gtk2 and qt

[frozencemetery]

Package: wireshark
Severity: wishlist

Since wireshark supports building for gtk2, gtk3, and qt, it would be nice if
we could get three versions, one for each.  The difference in the build
process is just which flag is passed to configure (and of course the relevant
graphics library).

Thanks!


-- System Information:
Debian Release: 7.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wireshark depends on:
ii  libc6   2.13-38
ii  libcairo2   1.12.2-3
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk-3-0  3.4.2-6
ii  libpango1.0-0   1.30.0-1
ii  libpcap0.8  1.3.0-1
ii  libportaudio2   19+svn2021-1
pn  libwireshark3   
pn  libwiretap3 
pn  libwsutil3  
pn  wireshark-common
ii  xdg-utils   1.1.0~rc1+git20111210-6
ii  zlib1g  1:1.2.7.dfsg-13

wireshark recommends no packages.

wireshark suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#683892: msmtp attempts to connect to gnome-keyring

[frozencemetery]

Emmanuel Bouthenot  writes:

> To reproduce the bug it's needed to send mail through a smtp server
> where tls is required.
>
> msmtp is linked to libp11-kit.so which once loaded tries to read the
> pkcs11 modules configuration files located in /etc/pkcs11/modules/*
>
> When installed, gnome-keyring ship a config file for pkcs11:
> /etc/pkcs11/modules/gnome-keyring-module
>
> /etc/pkcs11/modules/gnome-keyring-module is a conffile so removing
> gnome-keyring package is not enough to remove its conffiles.
>
> It is required to purge gnome-keyring to remove this file.
>
> So could you try to purge gnome-keyring and tell me if it fix this
> issue?
>
> $ apt-get purge gnome-keyring

Unfortunately I have since re-installed wheezy and no longer have
gnome-keyring installed.  msmtp is working in this environment, and
there is no /etc/pkcs11 directory at all.

Sorry I can't be more helpful.


pgp1IyMeYEoUO.pgp
Description: PGP signature

Bug#702380: zathura doesn't respond to exit commands while rendering

[frozencemetery]

Package: zathura
Version: 0.2.2-1
Severity: normal

As requested, here is the bug.  Original formulation below.

Sebastian Ramacher  writes:

>> However, I also can't get zathura to exit when viewing the pdf in the
>> experimental version; it ceased responding to non-scroll input and loaded up
>> the CPU.  Subjectively, up until I lost response, the rendering took longer
>> but the rest of the interface (especially scrolling) was more responsive.

I guess that can only be fixed killing the render thread. At the moment we
wait until the current page rendering job is done. However, I think this can
be improved in a way that the user doesn't notice anything.  We should be able
to destroy the GUI and then wait for the render thread. Mind filling a new bug
about that?

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages zathura depends on:
ii  libc6 2.13-38
ii  libcairo2 1.12.2-3
ii  libgirara-gtk2-1  0.1.5-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libpoppler-glib8  0.18.4-5
ii  libsqlite3-0  3.7.13-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  iceweasel [www-browser]  17.0.3esr-1
ii  lynx-cur [www-browser]   2.8.8dev.12-2
ii  poppler-data 0.4.5-10
ii  w3m [www-browser]0.5.3-8
pn  zathura-djvu 
ii  zathura-ps   0.2.1-2

-- 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#702214: zathura: Slow resizing followed by segfault

[frozencemetery]

Sebastian Ramacher  writes:

> I'm unable to reproduce the segfault with 0.1.2-4 and 0.2.2-1 from
> experimental. However, I remember that we have fixed some segfaults in
> the poppler plugin in 0.2.x that were caused by race conditions and
> really unfortunate unfortunate timing of events. Could you please check
> if the segfault is gone in 0.2.2-1?
>
> Both pages in that PDF are quite large, so the high CPU usage is
> somewhat expected.

I can't seem to reproduce the segfault in 0.2.2-1, so in that respect I
suppose the problem is fixed.  However, I also can't get zathura to exit
when viewing the pdf in the experimental version; it ceased responding
to non-scroll input and loaded up the CPU.  Subjectively, up until I
lost response, the rendering took longer but the rest of the interface
(especially scrolling) was more responsive.

Since it appears the segfault is gone, what remains of my complaint is
performance, which is at best wishlist, following the garbage in garbage
out principle.  If you think there's nothing more to be done, feel free
to close this bug.

Thanks.


pgpQpRjkXOE68.pgp
Description: PGP signature

Bug#702214: zathura: Slow resizing followed by segfault

[frozencemetery]

Package: zathura
Version: 0.1.2-4
Severity: normal

Hello,

While using zathura to browse this pdf

> http://web.mit.edu/campus-map/pdf/campusmap.pdf

zathura was quite slow to render, especially when zooming, and also consumed
an entire core of my machine (and I believe loading the graphics card as well)
when no rendering had been requested (i.e., in what appeared to be an "idle"
state).  It eventually segfaulted, as reported in dmesg:

> [34555.296106] zathura[1659]: segfault at 0 ip 7f81c833e62c sp 
> 7fff36156a70 error 4 in libpoppler.so.19.0.0[7f81c81f9000+1da000]

Thank you.


-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages zathura depends on:
ii  libc6 2.13-38
ii  libcairo2 1.12.2-3
ii  libgirara-gtk2-0  0.1.2-3
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libpoppler-glib8  0.18.4-5
ii  libsqlite3-0  3.7.13-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  iceweasel [www-browser]  17.0.3esr-1
ii  lynx-cur [www-browser]   2.8.8dev.12-2
ii  poppler-data 0.4.5-10
ii  w3m [www-browser]0.5.3-8
pn  zathura-djvu 
ii  zathura-ps   0.1-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#683892: msmtp attempts to connect to gnome-keyring

[frozencemetery]

Package: msmtp
Version: 1.4.28-1
Followup-For: Bug #683892

Emmanuel Bouthenot  writes:

> what's the result of the following commands:

> $ ldd /usr/bin/msmtp
  linux-vdso.so.1 =>  (0x7fff163ff000)
  libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 
(0x7f7289391000)
  libgsasl.so.7 => /usr/lib/libgsasl.so.7 (0x7f7289172000)
  libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x7f7288f3d000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7288bb3000)
  libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x7f72889a2000)
  libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7f7288723000)
  libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f728850c000)
  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f72882f)
  libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 
(0x7f72880dd000)
  libntlm.so.0 => /usr/lib/libntlm.so.0 (0x7f7287ed6000)
  libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f7287c97000)
  libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f72879c2000)
  libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
(0x7f7287799000)
  libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f7287595000)
  /lib64/ld-linux-x86-64.so.2 (0x7f728966b000)
  libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f7287391000)
  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f728718d000)
  libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f7286f84000)
  libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 
(0x7f7286d7f000)
  libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f7286b69000)


> $ dpkg -S /usr/bin/msmtp
msmtp: /usr/bin/msmtp

Hope that helps.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#683892: msmtp attempts to connect to gnome-keyring

[frozencemetery]

Package: msmtp
Version: 1.4.28-1
Followup-For: Bug #683892

More information:

$ echo test | msmtp -a user@host.domain user@host.domain
p11-kit: couldn't load module: 
/usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: 
/usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared 
object file: No such file or directory
$ 

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.9
ii  install-info   4.13a.dfsg.1-10
ii  libc6  2.13-37
ii  libgnutls262.12.20-2
ii  libgsasl7  1.8.0-2
ii  libidn11   1.25-2
ii  ucf3.0025+nmu3

Versions of packages msmtp recommends:
ii  ca-certificates  20120623

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#683892: msmtp attempts to connect to gnome-keyring

[frozencemetery]

Package: msmtp
Version: 1.4.28-1
Followup-For: Bug #683892

Dear Maintainer,

This bug is still present.  This system does not have network-manager
installed, nor are either of GNOME_KEYRING_CONTROL or GNOME_KEYRING_PID
defined.  msmtp-gnome was never installed on this system.

I do mail through emacs so setting mail-interactive is a workaround, but it
would be very nice if the underlying problem could be solved.

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.9
ii  install-info   4.13a.dfsg.1-10
ii  libc6  2.13-37
ii  libgnutls262.12.20-2
ii  libgsasl7  1.8.0-2
ii  libidn11   1.25-2
ii  ucf3.0025+nmu3

Versions of packages msmtp recommends:
ii  ca-certificates  20120623

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#699009: pidgin-latex: Assumes render background is white

[frozencemetery]

Package: pidgin-latex
Version: 1.4.4-2
Severity: important

Hello,

pidgin-latex assumes that pidgin will have a white background for conversation
windows without bothering to check that the background is in fact white.  This
results in largely unreadable rendering; on my black background, the
characters mostly disappear with only white partial outlines visible around
them in a ghostly fashion.

Thanks.

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pidgin-latex depends on:
ii  dvipng  1.14-1+b1
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-37
ii  libcairo2   1.12.2-2
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-3
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libpurple0  2.10.6-2
ii  pidgin  2.10.6-2
ii  texlive-latex-base  2012.20120611-5

pidgin-latex recommends no packages.

pidgin-latex 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#697086: youtube-dl: Fails on SoundCloud

[frozencemetery]

Package: youtube-dl
Version: 2012.02.27-1
Severity: important

Hello,

youtube-dl is broken on soundcloud.  It is also broken in the unstable version
of the package, though it is fixed in upstream head.  A traceback looks as
follows:

Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/usr/local/bin/youtube-dl/__main__.py", line 7, in 
  File "/usr/local/bin/youtube-dl/__init__.py", line 558, in main

  File "/usr/local/bin/youtube-dl/__init__.py", line 542, in _real_main

  File "/usr/local/bin/youtube-dl/FileDownloader.py", line 478, in download
  File "/usr/local/bin/youtube-dl/InfoExtractors.py", line 82, in extract
  File "/usr/local/bin/youtube-dl/InfoExtractors.py", line 2654, in
  _real_extract
UnboundLocalError: local variable 'video_id' referenced before assignment

Many thanks.

-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages youtube-dl depends on:
ii  python  2.7.3~rc2-1

Versions of packages youtube-dl recommends:
ii  ffmpeg6:0.8.4-1
ii  rtmpdump  2.4+20111222.git4e06e21-1

youtube-dl 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#693025: xmobar: unable to read CoreTemp and BatteryP is blank on ThinkPad

[frozencemetery]

Package: xmobar
Version: 0.14-4
Followup-For: Bug #693025

Hello,

When using BatteryP, xmobar is unable to detect my battery, and reports 0 for
left constantly.

As the original responder for this bug report did, I upgraded the version of
xmobar to version 0.15 from cabal, and the battery appears to be detected with
no problems.

In message 20, Apollon Oikonomopoulos  wrote:
> Most likely you need to use the -c parameter for BatteryP to point it to the
> correct file under /sys/class/power//, see the manpage for details and
> give it a try if you can. 0.15 does some autodiscovery and doesn't need the
> -c flag anymore.

I'd very much like to do this.  However, that directory does not exist on my
system.  The closest thing appears to be /sys/class/power_supply, where within
the relevant battery subdirectory there are files energy_full,
energy_full_design, and energy_now, which I believe -c is searching for.  With
0.15, however, I don't even need to pass this flag.

Many thanks.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xmobar depends on:
ii  libc6 2.13-37
ii  libffi5   3.0.10-3
ii  libgmp10  2:5.0.5+dfsg-2
ii  libiw30   30~pre9-8
ii  libx11-6  2:1.5.0-1
ii  libxext6  2:1.3.1-2
ii  libxft2   2.3.1-1
ii  libxinerama1  2:1.1.2-1
ii  libxrandr22:1.3.2-2

Versions of packages xmobar recommends:
ii  curl  7.26.0-1

Versions of packages xmobar suggests:
ii  xmonad  0.10-4+b2

-- 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#696037: mercurial-git: Does not handle empty repositories

[frozencemetery]

Package: mercurial-git
Version: 0.3.2-2
Severity: normal

Hey,

As indicated by the title, checkout of empty repositories does not seem to
work.  I created an empty repository using github, and when I went to check it
out, I got the traceback as follows:

** unknown exception encountered, please report by visiting
**  http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17) [GCC 4.6.3]
** Mercurial Distributed SCM (version 2.2.2)
** Extensions loaded: git, color, pager, rebase, convert
Traceback (most recent call last):
  File "/usr/bin/hg", line 38, in 
mercurial.dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 27, in
**  run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 64, in
**  dispatch
return _runcatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 87, in
**  _runcatch
return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 696, in
**  _dispatch
cmdpats, cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 472, in
**  runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 184,
**  in wrap
return wrapper(origfn, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/pager.py", line 91, in pagecmd
return orig(ui, options, cmd, cmdfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 184,
**  in wrap
return wrapper(origfn, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 362, in
**  colorcmd
return orig(ui_, opts, cmd, cmdfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 786, in
**  _runcommand
return checkargs()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 757, in
**  checkargs
return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 693, in
**  
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 463, in
**  check
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 1171, in
**  clone
branch=opts.get('branch'))
  File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 350, in clone
destrepo.clone(srcrepo, heads=revs, stream=stream)
  File "/usr/lib/python2.7/dist-packages/mercurial/localrepo.py", line 2305,
**  in clone
return self.pull(remote, heads)
  File "/usr/lib/python2.7/dist-packages/hgext/git/hgrepo.py", line 14, in
**  pull
return git.fetch(remote.path, heads)
  File "/usr/lib/python2.7/dist-packages/hgext/git/git_handler.py", line 156,
**  in fetch
refs = self.fetch_pack(remote, heads)
  File "/usr/lib/python2.7/dist-packages/hgext/git/git_handler.py", line 820,
**  in fetch_pack
f.write, progress.progress)
  File "/usr/lib/python2.7/dist-packages/dulwich/client.py", line 471, in
**  fetch_pack
refs, server_capabilities = self._read_refs(proto)
  File "/usr/lib/python2.7/dist-packages/dulwich/client.py", line 172, in
**  _read_refs
return refs, set(server_capabilities)
TypeError: 'NoneType' object is not iterable
user@host:~$ fatal: The remote end hung up unexpectedly

As I can tell github to not make empty repositories, this is not fatal, but it
is inconvenient.

Many thanks!

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mercurial-git depends on:
ii  mercurial   2.2.2-1
ii  python  2.7.3~rc2-1
ii  python-dulwich  0.8.5-2
ii  python2.6   2.6.8-0.2
ii  python2.7   2.7.3~rc2-2.1

mercurial-git recommends no packages.

mercurial-git 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#686855: mercurial-git: hg-git outgoing support broken

[frozencemetery]

Package: mercurial-git
Version: 0.3.1-1~bpo60+1
Severity: normal

In a hg-git repository, I attempt the following:

$ hg out
comparing with git+ssh://g...@github.com/<>/<>.git
abort: hg-git outgoing support is broken on hg 1.9.x

I am not using the specified version of mercurial, so I'm confused as to why
this would fail.

Thanks for your attention.

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mercurial-git depends on:
ii  mercurial   2.2.2-1~bpo60+1  easy-to-use, scalable distributed 
ii  python  2.6.6-3+squeeze7 interactive high-level object-orie
ii  python-dulwich  0.8.1-1~bpo60+1  Python Git library
ii  python2.6   2.6.6-8+b1   An interactive high-level object-o

mercurial-git recommends no packages.

mercurial-git 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#649466: pidgin: Pidgin emacs keys C-f unexpected behavior

[frozencemetery]

Package: pidgin
Version: 2.7.3-1+squeeze1
Severity: normal

To reproduce:

In gtk settings, set:
gtk-key-theme-name = "Emacs"
gtk-can-change-accels = 1

Then, in any query, within pidgin, clear (hover and press delete) the
Conversation->Find... command.  Bind it to something else (C-s, for example).

Type some text into the send field.  Go to the beginning, then try to navigate
forward with C-f.  The insertion point will advance as expected except that it
will not advance past the last character of the line (i.e., to the place where
pressing C-e would put it).  The expected behavior here is that C-f has the
same behavior as the right arrow key.

-- System Information:
Debian Release: 6.0.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pidgin depends on:
ii  gconf2 2.28.1-6  GNOME configuration database syste
ii  libatk1.0-01.30.0-1  The ATK accessibility toolkit
ii  libc6  2.11.2-10 Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libdbus-1-31.2.24-4+squeeze1 simple interprocess messaging syst
ii  libdbus-glib-1-2   0.88-2.1  simple interprocess messaging syst
ii  libfontconfig1 2.8.0-2.1 generic font configuration library
ii  libfreetype6   2.4.2-2.1+squeeze3FreeType 2 font engine, shared lib
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libgstreamer0.10-0 0.10.30-1 Core GStreamer libraries and eleme
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface 
ii  libgtkspell0   2.0.16-1  a spell-checking addon for GTK's T
ii  libice62:1.0.6-2 X11 Inter-Client Exchange library
ii  libpango1.0-0  1.28.3-1+squeeze2 Layout and rendering of internatio
ii  libpurple0 2.7.3-1+squeeze1  multi-protocol instant messaging l
ii  libsm6 2:1.1.1-1 X11 Session Management library
ii  libstartup-notific 0.10-1library for program launch feedbac
ii  libx11-6   2:1.3.3-4 X11 client-side library
ii  libxml22.7.8.dfsg-2+squeeze1 GNOME XML library
ii  libxss11:1.2.0-2 X11 Screen Saver extension library
ii  perl   5.10.1-17squeeze2 Larry Wall's Practical Extraction 
ii  perl-base [perlapi 5.10.1-17squeeze2 minimal Perl system
ii  pidgin-data2.7.3-1+squeeze1  multi-protocol instant messaging c

Versions of packages pidgin recommends:
ii  gstreamer0.10-plugins-base0.10.30-1  GStreamer plugins from the "base" 
ii  gstreamer0.10-plugins-good0.10.24-1  GStreamer plugins from the "good" 

Versions of packages pidgin suggests:
pn  evolution-data-server  (no description available)
pn  gnome-panel | kdebase-workspa  (no description available)
ii  libsqlite3-0  3.7.3-1SQLite 3 shared library

-- 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#640951: sbcl: ASDF::SPLIT is undefined

[frozencemetery]

Package: sbcl
Version: 1:1.0.40.0-2
Severity: important


This has been reported upstream 
with patch included.  The basic problem is that installer.lisp references a
split function, but this function has been renamed in asdf.lisp to
split-string.  Upstream includes a patch on the link; could we merge this in?

-- System Information:
Debian Release: 6.0.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sbcl depends on:
ii  common-lisp-controller7.6Common Lisp source and compiler ma
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib

Versions of packages sbcl recommends:
ii  binfmt-support1.2.18 Support for extra binary formats

Versions of packages sbcl suggests:
pn  sbcl-doc   (no description available)
pn  sbcl-source(no description available)
ii  slime   1:20100722-1 Superior LISP Interaction Mode for

-- 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#639842: ncmpcpp: Albums of the same name are not correctly handled

[frozencemetery]

Package: ncmpcpp
Version: 0.5.4-1
Severity: normal

This was discovered with the random album feature.  I have two albums of the
same name ("Judgement") by two different bands.  This is two separate albums,
not one album by two different bands, and the track/disc numbers within the
tagging indicate that.  However, when asked for a random album, ncmpcpp
appended both albums to the playlist, with the expected behavior that it would
only add one.

-- System Information:
Debian Release: 6.0.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ncmpcpp depends on:
ii  libc6 2.11.2-10  Embedded GNU C Library: Shared lib
ii  libcurl3-gnutls   7.21.0-2   Multi-protocol file transfer libra
ii  libfftw3-33.2.2-1library for computing Fast Fourier
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libmpdclient2 2.3-1  client library for the Music Playe
ii  libncursesw5  5.7+20100313-5 shared libraries for terminal hand
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3
ii  libtag1c2a1.6.3-1TagLib Audio Meta-Data Library

ncmpcpp recommends no packages.

Versions of packages ncmpcpp suggests:
pn  desktop-file-utils (no description available)
ii  mpd  0.15.12-1.1 Music Player Daemon

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