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#1021846: [programmer11...@programist.ru: Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem]

[Robbie Harwood]

Steve McIntyre  writes:

> Hi all!
>
> программист некто (in CC) reported this bug a few weeks back in
> Debian. Since I applied the bundle of filesystem bounds-checking fixes
> a few months back, he can't run grub-install. He's done the work to
> determine that the patch that breaks things for him is
>
> 2d014248d540c7e087934a94b6e7a2aa7fc2c704 fs/f2fs: Do not read past the end of 
> nat journal entries
>
> The full thread of our discussion is at https://bugs.debian.org/1021846
>
> I don't have any knowledge of f2fs to go any further here. Help please! :-)

I don't know much about f2fs either, but has the value of `n` been
captured versus NAT_JOURNAL_ENTRIES in the failing case?  Might be
useful to know how much it's going over by.

Be well,
--Robbie


signature.asc
Description: PGP signature

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

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#966640: build-depends: debhelper-compat (= 13) cannot be satisfied

[Robbie Harwood]

Control: reassign -1 aptitude

Aha, makes sense.  Sorry to bother!

Thanks,
--Robbie

Bug#963949: aptitude: "search aborted by fatal exception" during upgrade

[Robbie Harwood]

Package: aptitude
Version: 0.8.13-1+b1
Severity: normal

Dear Maintainer,

```
frozencemetery@kirtar:~$ sudo aptitude full-upgrade
The following NEW packages will be installed:
  libmfx1{a} libpocketsphinx3{a} librabbitmq4{a} libsphinxbase3{a} 
libsrt1-gnutls{a} 
The following packages will be upgraded:
  ffmpeg libavcodec-extra58 libavdevice58 libavfilter7 libavformat58 
libavresample4 libavutil56 libpostproc55 libswresample3 libswscale5 
10 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/12.8 MB of archives. After unpacking 26.2 MB will be used.
The following packages have unmet dependencies:
 chromium : Conflicts: libavcodec58 (= 7:4.3-2) but it is not going to be 
installed
*** ERROR: search aborted by fatal exception.  You may continue
   searching, but some solutions will be unreachable.

I want to resolve dependencies, but no dependency resolver was created.The 
following NEW packages will be installed:
  libmfx1{a} libpocketsphinx3{a} librabbitmq4{a} libsphinxbase3{a} 
libsrt1-gnutls{a} 
The following packages will be upgraded:
  ffmpeg libavcodec-extra58 libavdevice58 libavfilter7 libavformat58 
libavresample4 libavutil56 libpostproc55 libswresample3 libswscale5 
10 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/12.8 MB of archives. After unpacking 26.2 MB will be used.
aptitude failed to find a solution to these dependencies.  You can solve them 
yourself by hand or type 'n' to quit.
The following packages have unmet dependencies:
 chromium : Conflicts: libavcodec58 (= 7:4.3-2) but it is not going to be 
installed
Resolve these dependencies by hand? [N/+/-/_/:/?] ^C
frozencemetery@kirtar:~$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  chromium
The following NEW packages will be installed:
  libmfx1 libpocketsphinx3 librabbitmq4 libsphinxbase3 libsrt1-gnutls
The following packages will be upgraded:
  ffmpeg libavcodec-extra58 libavdevice58 libavfilter7 libavformat58 
libavresample4 libavutil56 libpostproc55 libswresample3 libswscale5
10 upgraded, 5 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/12.8 MB of archives.
After this operation, 153 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
frozencemetery@kirtar:~$ 
```

Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963035 , right now
we're in a state where chromium has

Conflicts: libavcodec58 (= 7:4.3-1), libavcodec58 (= 7:4.3-2)

however, 7:4.3-2 is the only available version of libavcodec58.  I assume this
is why aptitude bails out here.  There isn't a fix, so it's understandable
that it can't come up with one, but "fatal exception" isn't usually the way I
expect that to be presented :)

Thanks,
--Robbie

-- Package-specific info:
Terminal: rxvt-unicode-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 9.3.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.2
  libsigc++ version: 2.10.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.2.20200212
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffd98be4000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f0aef302000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f0aef2c7000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f0aef298000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f0aef28f000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f0aef189000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f0aef05f000)
libboost_iostreams.so.1.71.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.71.0 (0x7f0aef036000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f0aeee1c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f0aeedfb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f0aeec2e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0aeeae9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f0aeeacf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0aee90a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f0aee8f2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f0aee8d5000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f0aee8c2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0aee899000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f0aee877000)
libzstd.so.1 => 

Bug#959186: gssproxy: kerberos credentials not looked into the classical file

[Robbie Harwood]

Hi Vincent,

I disagree about "usually", but I have a larger question, which is: why are you 
using gssproxy if you want the credentials in an easily accessible location?  
The entire point of the daemon is privilege separation.

Thanks,
--Robbie

On April 30, 2020 10:48:29 AM EDT, Vincent Danjean  wrote:
>Package: gssproxy
>Version: 0.8.0-1.1
>Severity: normal
>
>  Hi,
>
>  The default configuration file looks for kerberos credentials
>in ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U but they usually
>are in ccache:FILE:/tmp/krb5cc_%U
>  Is this configuration intended? Why? I had to change it, I found
>the solution on several internet forum where it said that this is
>an error in the default configuration. I'm not sure if this is the
>case (an error) or if the default configuration file targets another
>usage.
>
>  Regards
>Vincent
>
>-- System Information:
>Debian Release: 10.3
>  APT prefers stable
>APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>TAINT_UNSIGNED_MODULE
>Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
>LANGUAGE=C.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages gssproxy depends on:
>ii  libc6 2.28-10
>ii  libgssapi-krb5-2  1.17-3
>ii  libgssrpc41.17-3
>ii  libini-config50.6.1-2
>ii  libk5crypto3  1.17-3
>ii  libkrb5-3 1.17-3
>ii  libpopt0  1.16-12
>ii  libref-array1 0.6.1-2
>ii  libselinux1   2.8-1+b1
>ii  libverto1 0.3.0-2
>
>gssproxy recommends no packages.
>
>gssproxy suggests no packages.
>
>-- Configuration Files:
>/etc/gssproxy/99-nfs-client.conf changed:
>[service/nfs-client]
>  mechs = krb5
>  cred_store = keytab:/etc/krb5.keytab
>  cred_store = ccache:FILE:/tmp/krb5cc_%U
>  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>  cred_usage = initiate
>  allow_any_uid = yes
>  trusted = yes
>  euid = 0
>
>
>-- no debconf information

Bug#959190: gssproxy: Log flooded by gssproxy

[Robbie Harwood]

Hi Vincent,

Please see `man gssproxy.conf` for logging options.  You probably want to set 
debug_level to 0 to disable logging.

Thanks,
--Robbie

On April 30, 2020 11:03:29 AM EDT, Vincent Danjean  wrote:
>Package: gssproxy
>Version: 0.8.0-1.1
>Severity: important
>
>  Hi,
>
>  On a system with kerberos (AD with sssd) and NFS mount,
>some applications (long bioinfo applications with data on
>the NFS partition) generate lots of logs that fill the
>root (or /var/log/) partition.
>  To have an idea, in less than 24h, more that 5GB of
>logs have been generated. There are all similar to:
>
>Apr 30 14:31:24 ge95142-vm1 gssproxy[6880]: gssproxy[6888]: (OID: { 1 2
>840 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide
>more information, No credentials cache found
>[and 300 similar lines for the same *second*]
>
>And I find them tree times: they are logged into
>/var/log/syslog, /var/log/daemon.log and /var/log/auth.log.
>
>
>  You should really provide a way to either limit the
>rate of the logs and/or provide an way to avoid logs
>(I do not find any).
>
>  Regards,
>Vincent
>
>
>-- System Information:
>Debian Release: 10.3
>  APT prefers stable
>APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
>'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/30 CPU cores)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>TAINT_UNSIGNED_MODULE
>Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
>LANGUAGE=C.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages gssproxy depends on:
>ii  libc6 2.28-10
>ii  libgssapi-krb5-2  1.17-3
>ii  libgssrpc41.17-3
>ii  libini-config50.6.1-2
>ii  libk5crypto3  1.17-3
>ii  libkrb5-3 1.17-3
>ii  libpopt0  1.16-12
>ii  libref-array1 0.6.1-2
>ii  libselinux1   2.8-1+b1
>ii  libverto1 0.3.0-2
>
>gssproxy recommends no packages.
>
>gssproxy suggests no packages.
>
>-- Configuration Files:
>/etc/gssproxy/99-nfs-client.conf changed:
>[service/nfs-client]
>  mechs = krb5
>  cred_store = keytab:/etc/krb5.keytab
>  cred_store = ccache:FILE:/tmp/krb5cc_%U
>  cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>  cred_usage = initiate
>  allow_any_uid = yes
>  trusted = yes
>  euid = 0
>
>
>-- no debconf information

Bug#955011: Fwd: Bug#955011: imap-dl: depends explicitly on python3-gssapi

[Robbie Harwood]

dkg wites:

> the typesafety checks in imap-dl turn out to make imap-dl fail when
> python3-gssapi is installed.  In particular:
>
> try:
> import gssapi # type: ignore
> except ModuleNotFoundError:
> gssapi = None
> […]
> class GSSAPI_handler():
> gss_vc:gssapi.SecurityContext
>
>
> this fails when the gssapi module isn't installed.  I should have caught
> it earlier, sorry!
>
> not sure the right way to handle this while retaining the type-safety
> though.

Ugh.  My suggestion is to just make the class definition contingent on
the library's presence.  Patch for that attached.

Thanks,
--Robbie


signature.asc
Description: PGP signature
>From 2a6d814dbe9976e55edd152982e60d1111a6ce61 Mon Sep 17 00:00:00 2001
From: Robbie Harwood 
Date: Fri, 27 Mar 2020 13:46:42 -0400
Subject: [PATCH] imap-dl: Fix failure when python3-gssapi isn't installed

The type annotation of the SecurityContext in GSSAPI_helper causes
python to actually use the gssapi object, which is None when
python3-gssapi isn't present.  Work around this by making the class
definition contingent on the presence of python3-gssapi.

Also adjust shebang to work properly with venvs.

Signed-off-by: Robbie Harwood 
---
 imap-dl | 60 +
 1 file changed, 31 insertions(+), 29 deletions(-)

diff --git a/imap-dl b/imap-dl
index 5a8494c..2052842 100755
--- a/imap-dl
+++ b/imap-dl
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
 # PYTHON_ARGCOMPLETE_OK
 # -*- coding: utf-8 -*-
 
@@ -95,39 +95,41 @@ def auth_builtin(username:str, imap:imaplib.IMAP4_SSL,
 if resp[0] != 'OK':
 raise Exception(f'login failed with {resp} as user {username} on {server}')
 
-# imaplib auth methods need to be in the form of callables, and they all
-# requre both additional parameters and storage beyond what the function
-# interface provides.
-class GSSAPI_handler():
-gss_vc:gssapi.SecurityContext
-username:str
+if gssapi:
+# imaplib auth methods need to be in the form of callables, and they all
+# requre both additional parameters and storage beyond what the function
+# interface provides.
+class GSSAPI_handler():
+gss_vc:gssapi.SecurityContext
+username:str
 
-def __init__(self, server:str, username:str) -> None:
-name = gssapi.Name(f'imap@{server}', gssapi.NameType.hostbased_service)
-self.gss_vc = gssapi.SecurityContext(usage="initiate", name=name)
-self.username = username
+def __init__(self, server:str, username:str) -> None:
+name = gssapi.Name(f'imap@{server}',
+   gssapi.NameType.hostbased_service)
+self.gss_vc = gssapi.SecurityContext(usage="initiate", name=name)
+self.username = username
 
-def __call__(self, token:Optional[bytes]) -> bytes:
-if token == b"":
-token = None
-if not self.gss_vc.complete:
-response = self.gss_vc.step(token)
-return response if response else b"" # type: ignore
-elif token is None:
-return b""
+def __call__(self, token:Optional[bytes]) -> bytes:
+if token == b"":
+token = None
+if not self.gss_vc.complete:
+response = self.gss_vc.step(token)
+return response if response else b"" # type: ignore
+elif token is None:
+return b""
 
-response = self.gss_vc.unwrap(token)
+response = self.gss_vc.unwrap(token)
 
-# Preserve the "length" of the message we received, and set the first
-# byte to one.  If username is provided, it's next.
-reply:List[int] = []
-reply[0:4] = response.message[0:4]
-reply[0] = 1
-if self.username:
-reply[5:] = self.username.encode("utf-8")
+# Preserve the "length" of the message we received, and set the
+# first byte to one.  If username is provided, it's next.
+reply:List[int] = []
+reply[0:4] = response.message[0:4]
+reply[0] = 1
+if self.username:
+reply[5:] = self.username.encode("utf-8")
 
-response = self.gss_vc.wrap(bytes(reply), response.encrypted)
-return response.message if response.message else b"" # type: ignore
+response = self.gss_vc.wrap(bytes(reply), response.encrypted)
+return response.message if response.message else b"" # type: ignore
 
 def auth_gssapi(username:str, imap:imaplib.IMAP4_SSL,
 conf:configparser.ConfigParser, server:str) -> None:
-- 
2.25.1

Bug#950514: gssproxy: Provided conf file ignored due to bad naming

[Robbie Harwood]

Control: reassign -1 libini-config5

Bug#950514: gssproxy: Provided conf file ignored due to bad naming

[Robbie Harwood]

Control: reassign -1 libini_config5

I believe this is https://pagure.io/SSSD/ding-libs/3182

Thanks,
--Robbie

Bug#928356: elpa-magit: diff buffer when committing is often useless/wrong

[Robbie Harwood]

Package: elpa-magit
Version: 2.90.1-2
Severity: normal

Dear Maintainer,

When committing changes without using staging (i.e., with `git commit -a` or
`git commit explicit/path/to/files`), the magit-diff buffer which is spawned
shows the diff for the most recent commit to master - not the proposed action
of the current commit.  To reproduce:

git init test
cd test
echo "test file" > foo
git add foo
git commit -am 'Initial commit'
echo "something else" > foo
git commit -a # this will incorrectly show an empty diff buffer
echo "a third thing" > foo
git commit -a # this will incorrectly show the previous commit

Thanks,
--Robbie

-- System Information:
Debian Release: buster/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 4.19.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-magit depends on:
ii  elpa-dash 2.14.1+dfsg-1
ii  elpa-ghub 3.2.0-1
ii  elpa-git-commit   2.90.1-2
ii  elpa-magit-popup  2.12.5-1
ii  elpa-with-editor  2.8.1-1
ii  emacsen-common3.0.4
ii  git   1:2.20.1-2

elpa-magit recommends no packages.

elpa-magit suggests no packages.

-- no debconf information

Bug#924418: libvirt-daemon-system: apparmor prevents libvirtd from spawning VMs

[Robbie Harwood]

Package: libvirt-daemon-system
Version: 5.0.0-1
Severity: important

Dear Maintainer,

When I attempt to spawn a QEMU/kvm VM (sudo virsh start vmname), it fails with:

error: Failed to start domain 7-1
error: internal error: Process exited prior to exec: libvirt:  error : 
unable to set AppArmor profile 'libvirt-16efecbc-66ca-4559-8558-7084588065d4' 
for '/usr/bin/kvm': No existe el fichero o el directorio

(That approximately translates to "The file or directory doesn't exist".  I
set LC_ALL=en_US.utf8, but it didn't seem to be respected.)

Here's the contents of /etc/apparmor.d/libvirt:

root@seton:~# ls -1 /etc/apparmor.d/libvirt
libvirt-0bb30752-0938-406e-a1db-897cc3dafff5
libvirt-0bb30752-0938-406e-a1db-897cc3dafff5.files
libvirt-168159f5-b57b-49f1-9326-306feeedcc44
libvirt-168159f5-b57b-49f1-9326-306feeedcc44.files
libvirt-16efecbc-66ca-4559-8558-7084588065d4
libvirt-16efecbc-66ca-4559-8558-7084588065d4.files
libvirt-2c26722b-4577-426a-af38-b81e7575c0ca
libvirt-2c26722b-4577-426a-af38-b81e7575c0ca.files
libvirt-4e7b35eb-3999-4879-afb6-e408445540ba
libvirt-4e7b35eb-3999-4879-afb6-e408445540ba.files
libvirt-53d197b4-935b-414e-8978-cd1c7fbbdf46
libvirt-53d197b4-935b-414e-8978-cd1c7fbbdf46.files
libvirt-59dc44de-10a8-41e8-bdc8-602bc03627a5
libvirt-59dc44de-10a8-41e8-bdc8-602bc03627a5.files
libvirt-92762faa-855e-43ab-8398-73f5cf54e7b9
libvirt-92762faa-855e-43ab-8398-73f5cf54e7b9.files
libvirt-ba5458f8-9ab6-4713-9bab-fdc620e4c64e
libvirt-ba5458f8-9ab6-4713-9bab-fdc620e4c64e.files
libvirt-c2bf8e0f-a7bc-4b01-ab12-bccae2ad43d0
libvirt-c2bf8e0f-a7bc-4b01-ab12-bccae2ad43d0.files
libvirt-d3397f74-1497-4f9a-9239-a941567f5201
libvirt-d3397f74-1497-4f9a-9239-a941567f5201.files
libvirt-e3a53b88-8c90-4126-b539-745e04d9169a
libvirt-e3a53b88-8c90-4126-b539-745e04d9169a.files
libvirt-e7d3374a-321b-4e50-9ca0-34ee843395c2
libvirt-e7d3374a-321b-4e50-9ca0-34ee843395c2.files
libvirt-ea10a337-7a16-469f-9bbf-49601a7390bc
libvirt-ea10a337-7a16-469f-9bbf-49601a7390bc.files
libvirt-f402a8d4-d6f3-4823-a20a-66c6e5a62924
libvirt-f402a8d4-d6f3-4823-a20a-66c6e5a62924.files
TEMPLATE.lxc
TEMPLATE.qemu
root@seton:~#

and indeed, it's not there.

I don't know how to debug this further, but please let me know if there's more
information I can provide.

Thanks,
--Robbie

-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  gettext-base   0.19.8.1-9
ii  iptables   1.8.2-4
ii  libacl12.2.53-4
ii  libapparmor1   2.13.2-9
ii  libaudit1  1:2.8.4-2
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-8
ii  libcap-ng0 0.7.9-2
ii  libdbus-1-31.12.12-1
ii  libdevmapper1.02.1 2:1.02.155-2
ii  libgnutls303.6.6-2
ii  libnl-3-2003.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libnuma1   2.0.12-1
ii  libselinux12.8-1+b1
ii  libvirt-clients5.0.0-1
ii  libvirt-daemon 5.0.0-1
ii  libvirt0   5.0.0-1
ii  libxml22.9.4+dfsg1-7+b3
ii  libyajl2   2.1.0-3
ii  logrotate  3.14.0-4
ii  lsb-base   10.2018112800
ii  policykit-10.105-25

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.2-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  ebtables 2.0.10.4+snapshot20181205-2
ii  iproute2 4.20.0-2
ii  parted   3.2-24

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.2-9
pn  auditd  
ii  nfs-common  1:1.3.4-2.4
pn  open-iscsi  
ii  pm-utils1.4.1-18
pn  radvd   
ii  systemd 241-1
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permiso denegado: 
'/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permiso denegado: 

Bug#870428: libverto1: Upstream has moved

[Robbie Harwood]

Sam Hartman  writes:

> I apologize for dropping the ball on this so long.
> It looks like there is a 0.3.0 release of verto, which was folded into
> krb5.
> However, It looks like there's not an upstream tarball on github for
> anything past 0.2.6.

I'm confused by this comment.  I've definitely been cutting relesese,
with tarballs, for 0.2.7, 0.3.0, and (today) 0.3.1 - you can see them
here: https://github.com/latchset/libverto/releases

I don't see anything different about those, but please let me know if
I've missed something.

> Because I dropped the ball so much I'm under tight time pressure to get
> an update into Debian buster.  I'm going to package 0.2.6, but if you
> either get me an official 0.3.0 tarball by Thursday or alternatively let
> me know that the changes between 0.2.6 and 0.3.0 are so critical I
> should go generate my own make dist even though I'm not upstream, I'll
> try to get 0.3.0 in.

Hopefully 0.3.1 addresses these concerns (and the bug you filed
upstream).

Thanks,
--Robbie


signature.asc
Description: PGP signature

Bug#922627: linux-image-4.19.0-2-rt-amd64: Crash on boot on Lenovo T530

[Robbie Harwood]

Package: src:linux
Version: 4.19.16-1
Severity: normal

Dear Maintainer,

While attempting to boot, the kernel failed to boot ending in stacktrace:

http://www.club.cc.cmu.edu/~rharwood/tmp/panic1.jpg

Apologies for not providing more logs, but shift-pageup doesn't appear to
scroll this console.

I was unable to reproduce the failure, but will update with more information
if it recurs.

Thanks,
--Robbie

-- Package-specific info:
** Version:
Linux version 4.19.0-2-rt-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-14)) #1 SMP PREEMPT RT Debian 4.19.16-1 (2019-01-17)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-2-rt-amd64 root=/dev/mapper/kirtar2-slash ro

** Not tainted

** Model information
sys_vendor: LENOVO
product_name: 23945WU
product_version: ThinkPad T530
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: G4ET65WW (2.07 )
board_vendor: LENOVO
board_name: 23945WU
board_version: Not Defined

** Loaded modules:
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
media
ctr
ccm
binfmt_misc
snd_hda_codec_realtek
snd_hda_codec_generic
intel_rapl
intel_powerclamp
coretemp
wmi_bmof
kvm_intel
kvm
irqbypass
intel_cstate
joydev
evdev
arc4
intel_uncore
intel_rapl_perf
iwldvm
serio_raw
mac80211
sg
nouveau
snd_hda_intel
thinkpad_acpi
tpm_tis
iwlwifi
tpm_tis_core
snd_hda_codec
battery
tpm
i915
mxm_wmi
snd_hda_core
nvram
rng_core
cfg80211
ac
snd_hwdep
ttm
iTCO_wdt
snd_pcm
iTCO_vendor_support
rfkill
video
drm_kms_helper
snd_timer
mei_me
pcc_cpufreq
snd
drm
pcspkr
wmi
button
soundcore
mei
i2c_algo_bit
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
xfs
btrfs
xor
zstd_decompress
zstd_compress
xxhash
raid6_pq
libcrc32c
crc32c_generic
algif_skcipher
af_alg
dm_crypt
dm_mod
sr_mod
cdrom
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
ahci
xhci_pci
libahci
sdhci_pci
ehci_pci
aesni_intel
cqhci
xhci_hcd
ehci_hcd
aes_x86_64
libata
crypto_simd
sdhci
cryptd
mmc_core
usbcore
psmouse
glue_helper
i2c_i801
scsi_mod
e1000e
lpc_ich
thermal
usb_common

** Network interface configuration:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp0s25:  mtu 1500 qdisc pfifo_fast state DOWN group 
default qlen 1000
link/ether 3c:97:0e:6b:ca:99 brd ff:ff:ff:ff:ff:ff
3: wlp3s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 84:3a:4b:2b:8b:e2 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.27/24 brd 192.168.0.255 scope global dynamic noprefixroute 
wlp3s0
   valid_lft 85845sec preferred_lft 85845sec
inet6 2601:184:4a80:2740:d7d5:bfb3:d692:2e44/64 scope global dynamic 
noprefixroute 
   valid_lft 345590sec preferred_lft 345590sec
inet6 fe80::f43e:b41:fbe0:330e/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo: 39131682615000 0  0 0  3913168
2615000 0   0  0
enp0s25:   0   0000 0  0 00 
  0000 0   0  0
wlp3s0: 28812637   26856000 0  0 0  8707985   
18604000 0   0  0

*** Protocol statistics:
Ip:
Forwarding: 2
15769 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
15736 incoming packets delivered
9586 requests sent out
98 dropped because of missing route
Icmp:
3 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
destination unreachable: 3
3 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 3
IcmpMsg:
InType3: 3
OutType3: 3
Tcp:
241 active connection openings
196 passive connection openings
0 failed connection attempts
149 connection resets received
3 connections established
26231 segments received
18846 segments sent out
69 segments retransmitted
0 bad segments received
174 resets sent
Udp:
2190 packets received
3 packets to unknown port received
31 packet receive errors
2171 packets sent
31 receive buffer errors
0 send buffer errors
IgnoredMulti: 49
UdpLite:
TcpExt:
63 TCP sockets finished time wait in fast timer
283 delayed acks sent
Quick ack mode was activated 3 times
19652 packet headers predicted

Bug#920770: ping: Lacking privilege for raw socket

[Robbie Harwood]

Control: close -1

You're right, it lost setuid bit.  Fixed by reinstall.

Thanks,
--Robbie

Bug#921124: elpa-git-commit: bad interaction with worktree/branch renaming

[Robbie Harwood]

Package: elpa-git-commit
Version: 2.90.1-1
Followup-For: Bug #921124

Thanks for your patience while I investigated a bit further.

It appears that this is related to worktrees and branch migration.  I can
reproduce like so:

# set up repo
git init testrepo
cd testrepo

# make HEAD valid so worktrees work
echo test > testf
git add testf
git commit -m test

# muck about with worktrees
git worktree add ugly-1
mv ugly-1 ugly-2
cd ugly-2
git branch -m ugly-2

# try to commit
echo test2 > testf
git commit -a

Assuming that's set up to spawn emacs with elpa-magit/elpa-git-commit, you
should see the failure at that point (warning that it renders my terminal
near-useless).  The content of *Messages* is:

Diffing changes to be committed (C-g to abort diffing)
Type C-c C-c to finish, or C-c C-k to cancel
error in process sentinel: user-error: Don’t kill this buffer.  Instead 
cancel using C-c C-k
error in process sentinel: Don’t kill this buffer.  Instead cancel using 
C-c C-k

Both (cli-only git) and (cli-git with emacs as editor but no magit) to have no
problem committing here.

Deleting and recreating the worktree using the new branchname seems to resolve
the problem.

Thanks,
--Robbie

-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-git-commit depends on:
ii  elpa-dash 2.14.1+dfsg-1
ii  elpa-with-editor  2.8.1-1
ii  emacsen-common3.0.4

elpa-git-commit recommends no packages.

elpa-git-commit suggests no packages.

-- no debconf information

Bug#921124: elpa-git-commit: magit components can't handle - character

[Robbie Harwood]

Package: elpa-git-commit
Version: 2.90.1-1
Severity: important

Dear Maintainer,

elpa-git-commit and magit's interactive rebase mode don't seem to be
able to handle the - character in pathnames/branches.  I wish I could
provide a more helpful error, but the result is that when I try to
type in the window, it hangs up the emacs process and barfs on the
terminal state machine, leaving garbage.

Thanks,
--Robbie

-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-git-commit depends on:
pn  elpa-dash 
pn  elpa-with-editor  
ii  emacsen-common3.0.4

elpa-git-commit recommends no packages.

elpa-git-commit suggests no packages.

Bug#920770: ping: Lacking privilege for raw socket

[Robbie Harwood]

Package: inetutils-ping
Version: 2:1.9.4-5
Severity: important

Dear Maintainer,

Non-root users seem unable to ping:

frozencemetery@kirtar:~$ ping 1.1.1.1
ping: Lacking privilege for raw socket.
frozencemetery@kirtar:~$

Nothing appears in the logs, so I'm unclear why this doesn't work anymore.

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

Kernel: Linux 4.19.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inetutils-ping depends on:
ii  libc62.28-5
ii  netbase  5.5

inetutils-ping recommends no packages.

inetutils-ping suggests no packages.

-- no debconf information

Bug#919323: msmtp: apparmor blocks reading configuration file ~/.msmtprc

[Robbie Harwood]

Package: msmtp
Version: 1.8.1-2
Severity: important

Dear Maintainer,

Trying to send mail with msmtp after upgrading, it fails with "no
configuration file available".  The audit line is:

audit: type=1400 audit(1547504604.078:263): apparmor="DENIED" 
operation="open" profile="/usr/bin/msmtp" name="/home/bos/rharwood/.msmtprc" 
pid=15946 comm="msmtp" requested_mask="r" denied_mask="r" fsuid=21259 ouid=21259

I wish I could tell you more, but I know nothing about apparmor.

Thanks,
--Robbie

-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  libc6  2.28-4
ii  libgnutls303.6.5-2
ii  libgsasl7  1.8.0-8+b2
ii  ucf3.0038+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20170717

Versions of packages msmtp suggests:
pn  msmtp-mta  

-- debconf information excluded

Bug#916564: python-pyte: new upstream version: 0.8.0

[Robbie Harwood]

Package: python3-pyte
Version: 0.4.8-1
Severity: normal

Dear Maintainer,

Currently pyte is on version 0.4.8 - which was released in January of 2014.
Please update to something newer, like the 0.8.0 that was released in April of
this year.

Thanks,
--Robbie

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

Kernel: Linux 4.18.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pyte depends on:
ii  python3  3.6.7-1

python3-pyte recommends no packages.

Versions of packages python3-pyte suggests:
pn  python-pyte-doc  

-- no debconf information

Bug#915780: krb5: New upstream version: 1.16.2

[Robbie Harwood]

Source: krb5
Version: 1.16.1-1
Severity: normal

Dear Maintainer,

A new upstream version is available.  There are 29 commits from 1.16.1 to
1.16.2 (not including release goo), which include several documentation fixes,
two memory leak fixes, and a fix for concurrent use of MEMORY ccaches.

Thanks,
--Robbie

-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#907568: dmesg: bad localization on --help

[Robbie Harwood]

Package: util-linux
Version: 2.32.1-0.1
Severity: normal

Dear Maintainer,

In non-english locales, the help appears to have been over-localized.  For
instance:

# LC_ALL=es_US.utf8 dmesg --help | grep -- --color
 -L, --color[=]  colorea los mensajes (auto, siempre o nunca)
#

but:

# LC_ALL=es_US.utf8 dmesg --color=siempre
dmesg: modo de color no implementado: 'siempre'
# LC_ALL=es_US.utf8 dmesg --color=nunca
dmesg: modo de color no implementado: 'nunca'
#

(which, in English, is "dmesg: unsupported color mode: 'nunca'").

Thanks!

-- System Information:
Debian Release: buster/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)
Foreign Architectures: i386

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii  fdisk  2.32.1-0.1
ii  libaudit1  1:2.8.3-1+b1
ii  libblkid1  2.32.1-0.1
ii  libc6  2.27-5
ii  libmount1  2.32.1-0.1
ii  libpam0g   1.1.8-3.8
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.32.1-0.1
ii  libsystemd0239-7
ii  libtinfo6  6.1+20180714-1
ii  libudev1   239-7
ii  libuuid1   2.32.1-0.1
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
ii  util-linux-locales  2.32.1-0.1

-- no debconf information

Bug#907486: libpam-systemd: Depends: systemd-shim (>= 10-4~) but it is not going to be installed

[Robbie Harwood]

Package: libpam-systemd
Version: 238-5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

(This bug has been reported also against systemd-shim:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903295 )

libpam-systemd requires systemd-shim version >=10-4~.  No such version exists.

This would make systemd-shim unusable.

root@hpsiddie:/home/manul# apt-get dist-upgrade -d sysvinit-core+ 
libpam-systemd+
Reading package lists... Done
Building dependency tree   
Reading state information... Done
sysvinit-core is already the newest version (2.88dsf-59.10).
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libpam-systemd : Depends: systemd-shim (>= 10-4~) but it is not going to 
be installed or
   systemd-sysv but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused 
by held packages.

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

Kernel: Linux 4.16.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libpam-systemd depends on:
ii  dbus1.12.10-1
ii  libc6   2.27-5
ii  libpam-runtime  1.1.8-3.8
ii  libpam0g1.1.8-3.8
ii  systemd 238-5
ii  systemd-shim10-3

libpam-systemd recommends no packages.

libpam-systemd suggests no packages.

-- no debconf information

Bug#899249: ncmpcpp: symbol lookup error on launch - boost related?

[Robbie Harwood]

Package: ncmpcpp
Version: 0.8.1-1+b1
Severity: important

Dear Maintainer,

This may be the same bug as #899163 so feel free to handle appropriately, but
I didn't perform any forcing.  This just happened during an upgrade.

Anyway, whenever I try to launch ncmpcpp, it fails like so:

rharwood@seton:~$ ncmpcpp
ncmpcpp: symbol lookup error: ncmpcpp: undefined symbol: 
_ZNK5boost16re_detail_10620031icu_regex_traits_implementation12do_transformEPKiS3_PKN6icu_608CollatorE

Thanks!

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

Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ncmpcpp depends on:
ii  libboost-date-time1.62.01.62.0+dfsg-5+b1
ii  libboost-filesystem1.62.0   1.62.0+dfsg-5+b1
ii  libboost-locale1.62.0   1.62.0+dfsg-5+b1
ii  libboost-program-options1.62.0  1.62.0+dfsg-5+b1
ii  libboost-regex1.62.01.62.0+dfsg-5+b1
ii  libboost-system1.62.0   1.62.0+dfsg-5+b1
ii  libboost-thread1.62.0   1.62.0+dfsg-5+b1
ii  libc6   2.27-3
ii  libcurl3-gnutls 7.58.0-2
ii  libfftw3-double33.3.7-1+b1
ii  libgcc1 1:8.1.0-3
ii  libicu6060.2-6
ii  libmpdclient2   2.11-1
ii  libncursesw66.1+20180210-3
ii  libreadline77.0-5
ii  libstdc++6  8.1.0-3
ii  libtag1v5   1.11.1+dfsg.1-0.2+b1
ii  libtinfo6   6.1+20180210-3

ncmpcpp recommends no packages.

Versions of packages ncmpcpp suggests:
pn  desktop-file-utils  
ii  mpd 0.20.19-1+b1

-- no debconf information

Bug#895836: flex: Upgrading from 2.6.1-1.3 to 2.6.4-6 breaks apache module loading

[Robbie Harwood]

Thanks Adrian!

Timo, this is fixed in upstream PR 179.

Thanks,
--Robbie

Bug#895836: flex: Upgrading from 2.6.1-1.3 to 2.6.4-6 breaks apache module loading

[Robbie Harwood]

Package: flex
Version: 2.6.4-6
Severity: important

Dear Maintainer,

After upgrading the version of flex, mod_auth_gssapi (in Debian,
libapache2-mod-auth-gssapi) can no longer be used.  In particular,
apache fails with:

apache2: Syntax error on line 78 of 
/root/mod_auth_gssapi/testsdir/httpd/httpd.conf: Cannot load 
./mod_auth_gssapi.so into server: /usr/lib/x86_64-linux-gnu/libfl.so.2: 
undefined symbol: yylex

Thanks!

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

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

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  libc6  2.27-3
ii  m4 1.4.18-1

Versions of packages flex recommends:
ii  gcc [c-compiler]4:7.3.0-3
ii  gcc-6 [c-compiler]  6.4.0-16
ii  gcc-7 [c-compiler]  7.3.0-16
ii  libfl-dev   2.6.4-6

Versions of packages flex suggests:
ii  bison2:3.0.4.dfsg-1+b1
ii  build-essential  12.4
pn  flex-doc 

-- no debconf information

Bug#892779: libu2f-udev: Please support non-systemd

[Robbie Harwood]

Package: libu2f-udev
Version: 1.1.4-1
Severity: normal

Dear Maintainer,

The provided udev rules don't work if the system isn't running systemd.
Instead, we have to do something like:

ATTRS{idVendor}=="1050", GROUP="plugdev", MODE="0660"
ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", GROUP="plugdev", 
MODE="0660"

I'm not sure this is the best solution, but feature parity should be possible
here.

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

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

-- no debconf information

Bug#880599: python-requests-kerberos: New upstream versions available - up to 0.11.0

[Robbie Harwood]

Package: python-requests-kerberos
Version: 0.7.0-3
Severity: normal

Dear Maintainer,

Version 0.7.0 was released in mid-2015.  Please update to a new version of
this module so that we can use the newer features added.

Thanks!

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

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

Versions of packages python-requests-kerberos depends on:
ii  python   2.7.14-1
ii  python-kerberos  1.1.5-2+b3
ii  python-requests  2.18.1-1

python-requests-kerberos recommends no packages.

python-requests-kerberos suggests no packages.

-- no debconf information

Bug#880446: GitPython: new upstream version 2.1.7

[Robbie Harwood]

Package: python-git
Version: 2.1.6-1
Severity: normal

Dear Maintainer,

A new upstream version of GitPython is available (2.1.7), released three days
after 2.1.6.  Among other things, this version contains fixes for working
worktrees.

I would appreciate if you could package this.

Thanks!

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

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

Versions of packages python-git depends on:
ii  git [git-core]  1:2.14.2-1
ii  python  2.7.14-1
ii  python-gitdb2.0.2-1

python-git recommends no packages.

Versions of packages python-git suggests:
pn  python-git-doc  
ii  python-smmap2.0.3-1

-- no debconf information

Bug#872365: python-cysignals-pari: Makes sagemath uninstallable, but sagemath depends on python-cysignals-pari

[Robbie Harwood]

Package: python-cysignals-pari
Version: 1.6.5+ds-1
Severity: important

Dear Maintainer,

sagemath depends on python-cysignals-pari.  However, python-cysignals-pari
has:

Breaks: sagemath (< 8.0~), sagemath:i386 (< 8.0~)

Since the only version of sagemath avaioable is 7.6, this makes sagemath
uninstallable.

I'm reporting this bug to your package because it has the problem; if you feel
that sagemath is at fault, please reassign.

Thanks,
--Robbie

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

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

Versions of packages python-cysignals-pari depends on:
ii  libc6 2.24-12
pn  libpari-gmp-tls5  
ii  python2.7.13-2

Versions of packages python-cysignals-pari recommends:
pn  cysignals-tools  

Versions of packages python-cysignals-pari suggests:
pn  python-cysignals-doc  

Bug#871601: ansible-2.3.1.0+dfsg-1 is uninstallable

[Robbie Harwood]

Package: ansible
Version: 2.3.1.0+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

ansible-2.3.1.0+dfsg-1 depends on python-jinja2 < 2.9.  However, this is not
available in testing/unstable/experimental.  As a result,
ansible-2.3.1.0+dfsg-1 is uninstallable, and its migration from unstable has
been blocked.

Thanks,
--Robbie

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

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

Versions of packages ansible depends on:
ii  python2.7.13-2
ii  python-crypto 2.6.1-7+b1
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.9.6-1
ii  python-netaddr0.7.18-2
ii  python-paramiko   2.0.0-1
ii  python-pkg-resources  36.0.1-1
ii  python-yaml   3.12-1+b1

Versions of packages ansible recommends:
ii  python-kerberos   1.1.5-2+b3
ii  python-selinux2.6-3+b2
pn  python-winrm  
ii  python-xmltodict  0.11.0-1

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

-- no debconf information

Bug#870428: libverto1: Upstream has moved

[Robbie Harwood]

Package: libverto1
Version: 0.2.4-2.1
Severity: normal

Dear Maintainer,

Since Fedorahosted isn't around anymore, we've moved the libverto upstream to
https://github.com/latchset/libverto .

I also notice that the Debian package is 0.2.4 while we have released 0.2.6
upstream.  I am happy to help with maintaining this package if it would be
helpful to you.

Thanks,
--Robbie

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

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

Versions of packages libverto1 depends on:
ii  libc62.24-12
ii  libverto-glib1   0.2.4-2.1
ii  libverto-libev1  0.2.4-2.1

libverto1 recommends no packages.

libverto1 suggests no packages.

-- no debconf information

Bug#870008: qemu-launcher: where is your upstream?

[Robbie Harwood]

Package: qemu-launcher
Severity: normal

Dear Maintainer,

In debian/control, there is no `Homepage`, `Vcs-Git`, or `Vcs-Browser` set.
Additionally, there are no results from search engines that seem to relate to
this project.

Please set these fields in control so that we can find this information.

Thanks!

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

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

Versions of packages qemu-launcher depends on:
pn  libgtk2-gladexml-perl   
ii  liblocale-gettext-perl  1.07-3+b3
ii  librsvg2-2  2.40.18-1
ii  perl5.26.0-4
pn  qemu

qemu-launcher recommends no packages.

Versions of packages qemu-launcher suggests:
ii  qemu-kvm [kvm]  1:2.8+dfsg-6
pn  qemuctl 

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Robbie Harwood]

Package: docker.io
Version: 1.13.1~ds1-2
Followup-For: Bug #864377

Well, perhaps.  The problem is that I can reproduce this on a fresh system
installation by just triggering a reinstall:

rharwood@seton:~$ sudo aptitude reinstall docker.io
The following packages will be REINSTALLED:
  docker.io 
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 
not upgraded.
Need to get 0 B/11.0 MB of archives. After unpacking 0 B will be used.
(Reading database ... 309020 files and directories currently installed.)
Preparing to unpack .../docker.io_1.13.1~ds1-2_amd64.deb ...
Unpacking docker.io (1.13.1~ds1-2) over (1.13.1~ds1-2) ...
Setting up docker.io (1.13.1~ds1-2) ...
[] Starting Docker: dockerinvoke-rc.d: initscript docker, action 
"start" failed.
dpkg: error processing package docker.io (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (233-9) ...
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
 docker.io
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up docker.io (1.13.1~ds1-2) ...
[] Starting Docker: dockerinvoke-rc.d: initscript docker, action 
"start" failed.
dpkg: error processing package docker.io (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 docker.io

Note that I haven't done any configuration or anything here, just installed
the package and then asked for a reinstall.

Thanks,
--Robbie

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

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

Versions of packages docker.io depends on:
ii  adduser  3.115
ii  containerd   0.2.3+git20170126.85.aa8187d~ds1-1
ii  golang-libnetwork0.8.0-dev.2+git20170202.599.45b4086-1
ii  init-system-helpers  1.48
ii  iptables 1.6.1-2
ii  libapparmor1 2.11.0-6
ii  libc62.24-12
ii  libdevmapper1.02.1   2:1.02.137-2+b1
ii  libsqlite3-0 3.16.2-5
ii  libsystemd0  233-9
ii  lsb-base 9.20161125
ii  runc 1.0.0~rc2+git20170201.133.9df8b30-2

Versions of packages docker.io recommends:
ii  ca-certificates  20161130+nmu1
ii  cgroupfs-mount   1.4
ii  git  1:2.13.2-3
ii  xz-utils 5.2.2-1.2+b1

Versions of packages docker.io suggests:
pn  aufs-tools   
pn  btrfs-progs  
pn  debootstrap  
pn  docker-doc   
pn  rinse
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#866530: pyrad: New upstream version - 2.1

[Robbie Harwood]

Source: pyrad
Severity: normal

Dear Maintainer,

A new version of pyrad is avilable upstream (2.1)[1].  Please package it.

Thanks,
--Robbie

1: https://github.com/wichert/pyrad/releases/tag/2.1

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

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

Bug#849240: auto-complete-el: ac-menu-delete setq of 1 arg

[Robbie Harwood]

Package: auto-complete-el
Version: 1.3.1-2
Followup-For: Bug #849240

Dear Maintainer,

This bug has been reported upstream as
https://github.com/auto-complete/auto-complete/issues/466 (more information on
failure) and https://github.com/auto-complete/auto-complete/pull/424 (contains
fix).

Please note that, without this fix, auto-complete-el is unusable with emacs25.

Thanks,
--Robbie

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

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

Versions of packages auto-complete-el depends on:
ii  emacs  47.0~exp1

auto-complete-el recommends no packages.

auto-complete-el suggests no packages.

-- no debconf information

Bug#864377: docker.io: Failure to install (cannot start daemon)

[Robbie Harwood]

Package: docker.io
Version: 1.13.1~ds1-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

During a system upgrade, I got the following:

Setting up docker.io (1.13.1~ds1-2) ...
[] Starting Docker: dockerinvoke-rc.d: initscript docker, action "start"
failed.
dpkg: error processing package docker.io (--configure):

Followed by, at the end:

Errors were encountered while processing:
 docker.io
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up docker.io (1.13.1~ds1-2) ...
[] Starting Docker: dockerinvoke-rc.d: initscript docker, action "start" 
failed.
dpkg: error processing package docker.io (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 docker.io

I grepped logs for error, but don't see anything related, and they're so
incredibly verbose as to be useless.

Thanks,
--Robbie

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

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

Versions of packages docker.io depends on:
ii  adduser  3.115
ii  containerd   0.2.3+git20170126.85.aa8187d~ds1-1
ii  golang-libnetwork0.8.0-dev.2+git20170202.599.45b4086-1
ii  init-system-helpers  1.48
ii  iptables 1.6.0+snapshot20161117-6
ii  libapparmor1 2.11.0-3
ii  libc62.24-11
ii  libdevmapper1.02.1   2:1.02.137-2
ii  libsqlite3-0 3.16.2-4
ii  libsystemd0  232-25
ii  lsb-base 9.20161125
ii  runc 1.0.0~rc2+git20170201.133.9df8b30-1

Versions of packages docker.io recommends:
ii  ca-certificates  20161130+nmu1
ii  cgroupfs-mount   1.4
ii  git  1:2.13.1+next.20170605-1
ii  xz-utils 5.2.2-1.2+b1

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  4.9.1-1
ii  debootstrap  1.0.90
pn  docker-doc   
pn  rinse
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#862978: zsh: `kill -L` doesn't work

[Robbie Harwood]

Package: zsh
Version: 5.3.1-4+b1
Severity: minor

Dear Maintainer,

As per kill(1), -L should generate a pretty list of signals and values.  Like
this:

rharwood@thriss:~$ /bin/kill -L
 1 HUP  2 INT  3 QUIT 4 ILL  5 TRAP 6 ABRT 7 BUS
 8 FPE  9 KILL10 USR111 SEGV12 USR213 PIPE14 ALRM
15 TERM16 STKFLT  17 CHLD18 CONT19 STOP20 TSTP21 TTIN
22 TTOU23 URG 24 XCPU25 XFSZ26 VTALRM  27 PROF28 WINCH
29 POLL30 PWR 31 SYS

However, it does not.  Instead, it does this:

rharwood@thriss:~$ kill -L
kill: unknown signal: SIGL
kill: type kill -l for a list of signals

Moreover, this should be a synonym:

rharwood@thriss:~$ kill --table
kill: unknown signal: SIG-TABLE
kill: type kill -l for a list of signals

I don't really know whether zsh should implement these, but it should respond
correctly to the flag (even if it means calling out to /bin/kill).  For
reference, here's what bash does:

rharwood@thriss:~$ kill -L
 1) SIGHUP   2) SIGINT   3) SIGQUIT  4) SIGILL   5) SIGTRAP
 6) SIGABRT  7) SIGBUS   8) SIGFPE   9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG  24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF 28) SIGWINCH29) SIGIO   30) SIGPWR
31) SIGSYS  34) SIGRTMIN35) SIGRTMIN+1  36) SIGRTMIN+2  37) 
SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) 
SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) 
SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) 
SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) 
SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) 
SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX


Thanks!

-- Package-specific info:
Packages which depend, recommend, suggest or enhance a zsh package and hence 
may provide code meant to be sourced in .zshrc:

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  zsh-syntax-hig 0.5.0-1  all  Fish shell like syntax highlighti

Packages which provide vendor completions:

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  awscli 1.11.44-1all  Universal Command Line Environmen
ii  curl   7.52.1-5 amd64command line tool for transferrin
ii  git-buildpacka 0.8.12.2 all  Suite to help with Debian package
ii  systemd232-23   amd64system and service manager
ii  udev   232-23   amd64/dev/ and hotplug management daem
ii  vlc-bin2.2.5.1-1~de amd64binaries from VLC

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

Kernel: Linux 4.9.0-3-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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 zsh depends on:
ii  dpkg1.18.24
ii  libc6   2.24-10
ii  libcap2 1:2.25-1
ii  libtinfo5   6.0+20161126-1
ii  zsh-common  5.3.1-4

Versions of packages zsh recommends:
ii  libc6 2.24-10
ii  libncursesw5  6.0+20161126-1
ii  libpcre3  2:8.39-3

Versions of packages zsh suggests:
ii  zsh-doc  5.3.1-4

-- no debconf information

Bug#861266: cmocka: Please package new upstream version

[Robbie Harwood]

Source: cmocka
Version: 1.0.1-3
Severity: wishlist

Dear Maintainer,

Versions 1.1.1 has been released upstream early this month.

Thanks!


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

Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#860342: [Python-modules-team] Bug#860342: python3-taglib: Newer upstream releases available since Jan 21, 2014

[Robbie Harwood]

Brian May <b...@debian.org> writes:

> Robbie Harwood <rharw...@club.cc.cmu.edu> writes:
>
>> Please update to a newer version of the package.  This looks
>> unmaintained and I would have filed an RM request save that there are
>> packages that depend on this in the archive.
>
> What packages depend on python3-taglib? I can't see anything in testing.

Nothing in testing testing that I can see, but:

$ axi-cache rdepends python3-taglib | egrep -v 'dbgsym|i386'
python3-taglib
Reverse Depends:
  bluemindo
  libstdc++6

The former is a music player, which makes sense, and has a version in
experimental; the latter is perplexing to me.

Bug#860342: python3-taglib: Newer upstream releases available since Jan 21, 2014

[Robbie Harwood]

Package: python3-taglib
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Please update to a newer version of the package.  This looks unmaintained and
I would have filed an RM request save that there are packages that depend on
this in the archive.

Thanks.

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

Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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)

Bug#756400: pytaglib: Please include a python2 package

[Robbie Harwood]

Source: pytaglib
Followup-For: Bug #756400

Dear Maintainer,

Upstream is capable of both python2 and python3.  I would really like to not
have to make my code care, or install from pip.

Thanks.

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

Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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)

Bug#852395: unblock: gssproxy/0.5.1-2

[Robbie Harwood]

Niels Thykier  writes:

> Ok - as I understand it, what we are dealing with here is:
>
>  * systemd: You can get gssproxy + NFS and it "just works(tm)" if
>you install gssproxy.  Otherwise you get svcgssd + NFS.
>(This is how I understood Neil Brown)
>  * sysvinit: Business as usual either way.
>
>
> So granting gssproxy will:
>
>  * Provide systemd users with NFS + gssproxy if they opt-in to it
>(by installing it)
>  * Provide sysvinit users gssproxy and if they want to use it with
>NFS, they may have to tweak things themselves
>  * Not cause any issues for neither systemd users nor sysvinit users
>just by installing it.
>  * enable users to get gssproxy which is not deprecated (unlike the
>existing svcgssd)
>
> Is the above correct? And you are happy with gssproxy/0.5.1-2 as it is?

That sounds right.  And yes.


signature.asc
Description: PGP signature

Bug#859968: qt5-qmake: man page for qmake-qt5 has wrong HTML doc path

[Robbie Harwood]

Package: qt5-qmake
Version: 5.7.1+dfsg-3+b1
Severity: minor

Dear Maintainer,

qmake-qt5(1), which I assume was ported over from qmake-qt4(1), mentions the
path /usr/share/qt5/doc/html/qmake-manual.html in the "SEE ALSO" section.  The
correct path is /usr/share/qt5/doc/qmake/qmake-manual.html

Thanks!

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

Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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 qt5-qmake depends on:
ii  libc6   2.24-9
ii  libgcc1 1:6.3.0-12
ii  libstdc++6  6.3.0-12
ii  qtchooser   63-g13a3d08-1

qt5-qmake recommends no packages.

qt5-qmake suggests no packages.

-- no debconf information

Bug#852395: unblock: gssproxy/0.5.1-2

[Robbie Harwood]

Niels Thykier  writes:

> NeilBrown:
>> On Sun, Mar 05 2017, Daniel Pocock wrote:
>> 
>> The systemd unit files are designed so that svcgssd will only be
>> started if gssproxy didn't start - and gssproxy is tried first.
>> 
>> If you use something other than systemd, similar logic would be
>> needed.
>
> @Robbie: Can you clarify what happens for people who have chosen to
> use sysvinit as init system?  Will they end up with gssproxy or
> svcgssd or a broken NFS?

I don't totally understand these unit files, so this is probably a
better question for the NFS folk.  But:

The gssproxy package contains a sysvinit script, which works just fine
on my sysvinit system.  (And I assume on systemd systems due to lack of
bug reports :) )

Since nfs-common doesn't provide sysvinit scripts as far as I can tell,
I think you already can't run any of this on them, unless I'm missing
something.

So you'd get gssproxy, and no NFS, but that was already the case.


signature.asc
Description: PGP signature

Bug#856965: gssproxy: GSS-Proxy is not supported by this kernel

[Robbie Harwood]

Laurent Bonnaud  writes:

> I installed gssproxy on this system and saw the following error
> message in the logs:
>
> Mar 6 16:59:15 irancy gssproxy[23024]: GSS-Proxy is not supported by
> this kernel since file /proc/net/rpc/use-gss-proxy could not be found:
> 2 (No such file or directory)
>
> And indeed the /proc/net/rpc/ did not exist on my system.
>
> Loading the rpcsec_gss_krb5 kernel module fixed the problem.  So could
> you please add this to the init script?

You actually only need auth_rpcgss I think; rpcsec_gss_krb5 pulls in
auth_rpcgss.  Normal operation is for the nfsd module to pull
rpcsec_gss_krb5.

If you want a more lightweight workaround: delete the file
/etc/gssproxy/24-nfs-server.conf and everything should work okay.
Longer term the plan is to merge this into the NFS packaging, but we're
not there yet.

Thanks,
--Robbie


signature.asc
Description: PGP signature

Bug#857065: gmrun: Segfault after recent upgrades

[Robbie Harwood]

Package: gmrun
Version: 0.9.2-2.1+b2
Severity: grave
Followup-For: Bug #857065

Raising severity to "grave" since it is usable becuse it segfaults every time
we try to launch it.

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

Kernel: Linux 4.9.0-2-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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 gmrun depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3+b2
ii  libgcc1  1:6.3.0-8
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-1
ii  libgtk2.0-0  2.24.31-2
ii  libpango-1.0-0   1.40.4-1
ii  libpangocairo-1.0-0  1.40.4-1
ii  libpangoft2-1.0-01.40.4-1
ii  libpopt0 1.16-10
ii  libstdc++6   6.3.0-8

gmrun recommends no packages.

gmrun suggests no packages.

-- no debconf information

Bug#855079: Acknowledgement (weechat-curses: Screen redraw on terminal resize is slow after upgrade)

[Robbie Harwood]

After some digging, I believe this is caused by this issue:
https://github.com/weechat/weechat/issues/902
which was fixed upstream.


signature.asc
Description: PGP signature

Bug#855079: weechat-curses: Screen redraw on terminal resize is slow after upgrade

[Robbie Harwood]

Package: weechat-curses
Version: 1.7-1
Severity: minor

Dear Maintainer,

After upgraing to unstable, I'm noticing that weechat-curses takes 2-3 seconds
to repaint when I resize the terminal.  Normal repaints, such as switching
channel buffers, are as fast as before, and other curses applications (e.g.,
ncmpcpp) do not seem to be affected.

Setting severity to minor because weechat is otherwise usable, but I would
really appreciate this being fixed.  Thanks!

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

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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 weechat-curses depends on:
ii  libc62.24-9
ii  libcurl3-gnutls  7.52.1-2
ii  libgcrypt20  1.7.6-1
ii  libgnutls30  3.5.8-3
ii  libncursesw5 6.0+20161126-1
ii  libtinfo56.0+20161126-1
ii  weechat-core 1.7-1

Versions of packages weechat-curses recommends:
ii  weechat-plugins  1.7-1

Versions of packages weechat-curses suggests:
pn  weechat-doc  

-- no debconf information

Bug#852719: sssd-common: `service sssd restart` hangs

[Robbie Harwood]

Package: sssd-common
Version: 1.15.0-1
Severity: normal
Tags: patch

Dear Maintainer,

/etc/default/sssd has -i present in DAEMON_OPTS.  This causes sssd to not
disown its processes on service start, and as a result `service sssd restart`
will hang.

To fix, replace -i with -D.

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (600, 'unstable-debug'), (600, 'testing-debug'), (600, 
'unstable'), (600, 'testing'), (200, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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 sssd-common depends on:
ii  adduser  3.115
ii  init-system-helpers  1.47
ii  libbasicobjects0 0.6.0-1
ii  libc-ares2   1.12.0-1
ii  libc62.24-9
ii  libcollection4   0.6.0-1
ii  libcomerr2   1.43.3-1
ii  libdbus-1-3  1.10.14-1
ii  libdhash10.6.0-1
ii  libglib2.0-0 2.50.2-2
ii  libhttp-parser2.12.1-2
ii  libini-config5   0.6.0-1
ii  libjansson4  2.9-1
ii  libk5crypto3 1.15-1
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.15-1
ii  libldap-2.4-22.4.44+dfsg-3
ii  libldb1  2:1.1.27-1
ii  libnfsidmap2 0.25-5.1
ii  libnl-3-200  3.2.27-1
ii  libnl-route-3-2003.2.27-1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1
ii  libpam0g 1.1.8-3.5
ii  libpcre3 2:8.39-2
ii  libpopt0 1.16-10
ii  libref-array10.6.0-1
ii  libselinux1  2.6-3
ii  libsemanage1 2.6-2
ii  libsss-idmap01.15.0-1
ii  libsss-nss-idmap01.15.0-1
ii  libsystemd0  232-14
ii  libtalloc2   2.1.8-1
ii  libtdb1  1.3.11-2
ii  libtevent0   0.9.31-1
ii  python   2.7.13-2
ii  python-sss   1.15.0-1

Versions of packages sssd-common recommends:
ii  bind9-host   1:9.10.3.dfsg.P4-11
ii  libnss-sss   1.15.0-1
ii  libpam-sss   1.15.0-1
ii  libsss-sudo  1.15.0-1

Versions of packages sssd-common suggests:
pn  apparmor
ii  sssd-tools  1.15.0-1

-- Configuration Files:
/etc/default/sssd changed [not included]
/etc/init.d/sssd changed [not included]

-- no debconf information

Bug#852395: unblock: gssproxy/0.5.1-2

[Robbie Harwood]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gssproxy

gssproxy has been 10 days in unstable, and allowing it to migrate will fix
bug#848306 (severity: important) in nfs-common.  gssproxy is a new package in
unstable (so no debdiff is included), and would have made the freeze had I not
made a mistake documenting copyright.

Thanks.

unblock gssproxy/0.5.1-2

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

Kernel: Linux 4.8.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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)

Bug#833114: "RuntimeError: OrderedDict mutated during iteration" on some feeds

[Robbie Harwood]

Package: rss2email
Version: 1:3.9-2
Followup-For: Bug #833114

Here is the commit to fix it from upstream:

https://github.com/wking/rss2email/commit/60870d9ff7f23441919df79d710ad49ecbcedf73

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

Kernel: Linux 4.8.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
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 rss2email depends on:
ii  python-xdg  0.25-4
ii  python2.7   2.7.13-1
ii  python3-feedparser  5.1.3-3
ii  python3-html2text   2016.9.19-1
pn  python3:any 

Versions of packages rss2email recommends:
pn  python3-bs4  

Versions of packages rss2email suggests:
pn  esmtp  

-- no debconf information

Bug#807311: init-d-script: do_reload_sigusr1 sends sighup, not sigusr1

[Robbie Harwood]

Petter Reinholdtsen  writes:

> Renaming the function will break anyone doing the 'alias' trick, so any
> changes should be done in a backwards compatible way, I believe.
>
> Patches welcome. :)

The approach I was suggesting would look like this:

+ Enable this using
+ RELOAD_SIGNAL=1 # or other signal number
+ alias do_reload=do_reload_signal
+do_reload_signal() {
+log_daemon_msg "Reloading $DESC configuration files" "$NAME"
+start-stop-daemon --oknodo --stop --signal $RELOAD_SIGNAL \
+  --quiet --pidfile "$PIDFILE" --exec "$DAEMON"
+log_end_msg $?
+}

(There could even be a default value for RELOAD_SIGNAL, if desired.)

Once that has landed, I was suggesting sending patches to everyone using
do_reload_sigusr1() right now that look like this:

-alias do_reload=do_reload_sigusr1
+SIGNAL=1
+alias do_reload=do_reload_signal

At which point do_reload_sigusr1 can be safely removed since no one is
using it.


signature.asc
Description: PGP signature

Bug#807311: init-d-script: do_reload_sigusr1 sends sighup, not sigusr1

[Robbie Harwood]

Petter Reinholdtsen <p...@hungry.com> writes:

> [Robbie Harwood]
>> It's pretty common for SIGHUP to reload config as well as SIGUSR1.
>>
>> So, my suggestion would be define a new way of doing this, file bugs
>> with patches against anyone using do_reload_sigusr1, and then remove
>> do_reload_sigusr1.
>>
>> One way that might be nice is to make a function do_reload_signal, which
>> would send $SIGNAL (or $RELOAD_SIGNAL) as an argument to
>> start-stop-daemon.
>
> I did not quite understand the problem.  Can you explain in a bit more
> detail?
>
> Today scripts wanting to use SIGHUP to reload can implement do_reload()
> similar to the way do_reload_sigusr1() is implemented.  Those wanting
> SIGUSR1 can use do_reload_sigusr1() by providing it as an alias for
> do_reload().  What more is needed?

As per this bug's original filing: do_reload_sigusr1() calls SIGHUP, not
SIGUSR1.


signature.asc
Description: PGP signature

Bug#807311: init-d-script: do_reload_sigusr1 sends sighup, not sigusr1

[Robbie Harwood]

It's pretty common for SIGHUP to reload config as well as SIGUSR1.

So, my suggestion would be define a new way of doing this, file bugs
with patches against anyone using do_reload_sigusr1, and then remove
do_reload_sigusr1.

One way that might be nice is to make a function do_reload_signal, which
would send $SIGNAL (or $RELOAD_SIGNAL) as an argument to
start-stop-daemon.


signature.asc
Description: PGP signature

Bug#847681: packaging repository and sid diverging? Various fixes needed.

[Robbie Harwood]

Sven Geggus  writes:

> Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 11:01 Uhr:
>
>> Would you consider uploading it or proposing it in mentors.debian.net?
>> Please also send details on the gss-proxy ITP bug.
>
> Robbie is the one with the ITP bug, not me :)
>
> I just pushed my custom package data to github though:
> https://github.com/giggls/gssproxy

Hi, glad the github fork was useful.

I have the bulk of my package done for the ITP, but haven't gotten
init-related functionality working yet.

Upstream (that's Simo and me, though this is Simo's decision) prefer the
name "GSS-Proxy" for anything written in a sentence, and "gssproxy" for
everything else.  The package in Fedora and RHEL/CentOS is called
"gssproxy", for instance.

As for the NFS pieces: upstream, we package example configuration files
for an NFS server, apache (mod_auth_gssapi), and an NFS client.  We
don't provide any additional scripting for NFS; NFS takes care of that.

Hope that helps,
--Robbie


signature.asc
Description: PGP signature

Bug#847140: xdm: should install exececutable in /usr/sbin

[Robbie Harwood]

Package: xdm
Version: 1:1.1.11-3
Severity: normal

Dear Maintainer,

Binaries should be in the sbin, not the plain bin, directory when only root
wants to run them.

For instance:

$ xdm
Only root wants to run xdm
$ echo $?
1

Thanks!

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

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

Versions of packages xdm depends on:
ii  cpp4:6.2.1-1
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-7
ii  libpam0g   1.1.8-3.3
ii  libselinux12.6-3
ii  libx11-6   2:1.6.3-1
ii  libxau61:1.0.8-1
ii  libxaw72:1.0.13-1
ii  libxdmcp6  1:1.1.2-1.1
ii  libxext6   2:1.3.3-1
ii  libxft22.3.2-1
ii  libxinerama1   2:1.1.3-1+b1
ii  libxmu62:1.1.2-2
ii  libxpm41:3.5.11-1+b1
ii  libxrender11:0.9.9-2
ii  libxt6 1:1.1.5-1
ii  lsb-base   9.20161125
ii  procps 2:3.3.12-3
ii  x11-utils  7.7+3
ii  x11-xserver-utils  7.7+7

xdm recommends no packages.

xdm suggests no packages.

-- debconf information excluded

Bug#847009: amanda: please make the build reproducible (shell)

[Robbie Harwood]

Source: amanda
Version: 1:3.3.9-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that amanda could not be built reproducibly.

The attached patch stops the shell value at build-time from leaking into
processed shell scripts.  Once applied, amanda should be able to be
built reproducibly in our current framework.

Thanks!

 [1]: https://wiki.debian.org/ReproducibleBuilds
Author: Robbie Harwood <rharw...@club.cc.cmu.edu>
Description: Avoid using build-time shell in built scripts for reproducibility
--- a/amplot/amplot.sh
+++ b/amplot/amplot.sh
@@ -1,4 +1,4 @@
-#!@SHELL@
+#/bin/sh
 # Amanda, The Advanced Maryland Automatic Network Disk Archiver
 # Copyright (c) 1992-1998 University of Maryland at College Park
 # Copyright (c) 2007-2013 Zmanda, Inc.  All Rights Reserved.
--- a/changer-src/chg-disk.sh
+++ b/changer-src/chg-disk.sh
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 # Amanda, The Advanced Maryland Automatic Network Disk Archiver
 # Copyright (c) 1991-1999 University of Maryland at College Park
--- a/changer-src/chg-manual.sh
+++ b/changer-src/chg-manual.sh
@@ -1,4 +1,4 @@
-#!@SHELL@ 
+#!/bin/sh
 #
 # Exit Status:
 # 0 Alles Ok
--- a/changer-src/chg-multi.sh
+++ b/changer-src/chg-multi.sh
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 # Amanda, The Advanced Maryland Automatic Network Disk Archiver
 # Copyright (c) 1991-1999 University of Maryland at College Park
--- a/changer-src/chg-zd-mtx.sh
+++ b/changer-src/chg-zd-mtx.sh
@@ -1,4 +1,4 @@
-#!@SHELL@ 
+#!/bin/sh
 #
 # Exit Status:
 # 0 Alles Ok
--- a/client-src/patch-system.sh
+++ b/client-src/patch-system.sh
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 # patch inetd.conf and services
 # originally by Axel Zinser (f...@hiss.han.de)
--- a/common-src/amaespipe.sh
+++ b/common-src/amaespipe.sh
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 # Copyright (c) 2007-2013 Zmanda Inc.  All Rights Reserved.
 # 
--- a/common-src/amcrypt-ossl-asym.sh
+++ b/common-src/amcrypt-ossl-asym.sh
@@ -1,4 +1,4 @@
-#!@SHELL@
+#!/bin/sh
 #
 # This program is free software; you can redistribute it and/or
 # modify it under the terms of the GNU General Public License
--- a/common-src/amcrypt-ossl.sh
+++ b/common-src/amcrypt-ossl.sh
@@ -1,4 +1,4 @@
-#!@SHELL@
+#!/bin/sh
 #
 # This program is free software; you can redistribute it and/or
 # modify it under the terms of the GNU General Public License
--- a/common-src/amcrypt.sh
+++ b/common-src/amcrypt.sh
@@ -1,4 +1,4 @@
-#!@SHELL@
+#!/bin/sh
 #
 # Original wrapper by Paul Bijnens
 #
--- a/server-src/amcheckdb.sh
+++ b/server-src/amcheckdb.sh
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 # check tapelist against database and vice versa
 #


signature.asc
Description: PGP signature

Bug#846971: maildrop: Fix reproducible build issue in package

[Robbie Harwood]

Package: maildrop
Severity: normal
Tags: patch

Dear Maintainer,

maildrop.makedat captures the build-time shell and uses it an interpreter
after the package is built.  This patch uses /bin/sh instead.

Thanks!

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

Kernel: Linux 4.8.0-1-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
Init: sysvinit (via /sbin/init)
Author: Robbie Harwood <rharw...@club.cc.cmu.edu>
Description: For reproducibility, do not use build-time shell in scripts
--- a/libs/maildir/sharedindexinstall.in
+++ b/libs/maildir/sharedindexinstall.in
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 # Copyright 2004 Double Precision, Inc.
 # See COPYING for distribution information.
--- a/libs/makedat/makedat.in
+++ b/libs/makedat/makedat.in
@@ -1,4 +1,4 @@
-#! @SHELL@
+#!/bin/sh
 #
 #
 # Copyright 1998 - 2004 Double Precision, Inc.  See COPYING for

Bug#846894: bgoffice-computer-terms: VCS links are dead

[Robbie Harwood]

Package: bgoffice-computer-terms
Severity: normal

Dear Maintainer,

The VCS links for this package have stopped working.  Please update them to
your actual VCS.

Thanks!

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

Kernel: Linux 4.8.0-1-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
Init: sysvinit (via /sbin/init)

Bug#846885: paxrat: Vcs-Git is incorrect

[Robbie Harwood]

Package: paxrat
Severity: minor
Tags: patch

Dear Maintainer,

The `Vcs-git:` field should point to a URL that can be checked out.  For this
package, the correct remote would be
https://anonscm.debian.org/git/collab-maint/paxrat.git

Thanks!

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

Kernel: Linux 4.8.0-1-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
Init: sysvinit (via /sbin/init)

Bug#832962: reprotest fails to build properly on jessie

[Robbie Harwood]

Package: reprotest
Followup-For: Bug #832962

So it will need to build against backports because it requires diffoscope.
Most of the build can occur with minor changes to dependencies (vim-common for
xxd, python-tox for tox, fixing version in setup.py).  However, the test suite
does not seem to run happily against python34, which would be needed.

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

Kernel: Linux 4.8.0-1-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
Init: sysvinit (via /sbin/init)

Bug#846857: git-pbuilder: does not call pbuilder and no flag to change this

[Robbie Harwood]

Package: git-buildpackage
Version: 0.8.7
Severity: normal

Dear Maintainer,

Based on the name, I would have expected pbuilder to call out to pbuilder, not
cowbuilder.  It is also difficult to change this behavior from a `gbp
buildpackage` invocation since there are no flags for it.

Thanks!

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

Kernel: Linux 4.8.0-1-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
Init: sysvinit (via /sbin/init)

Versions of packages git-buildpackage depends on:
ii  devscripts2.16.10
ii  git   1:2.10.2-3
ii  man-db2.7.5-2
ii  python-dateutil   2.5.3-2
ii  python-pkg-resources  28.7.1-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.81
ii  pbuilder 0.226.1
ii  pristine-tar 1.37
ii  python-requests  2.11.1-1

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  sudo   1.8.17p1-2
ii  unzip  6.0-20

-- no debconf information

Bug#846535: openssl: 1.1.0c cannot decrypt files created by older versions of openssl

[Robbie Harwood]

Package: openssl
Version: 1.1.0c-2
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

After upgrading to a newer version of OpenSSL, I cannot decrypt a file that
was encrypted using the OpenSSL in Stable (and had been decryptable until very
recently).

To reproduce:

root@stable:~# echo "test" > file
root@stable:~# echo "secretes" | openssl enc -aes-256-cbc -in file -out 
file.enc -pass stdin

Then copy the file to a (testing) system and:

rharwood@thriss:/tmp$  echo "secretes" | openssl enc -d -aes-256-cbc -in 
file.enc -out file -pass stdin
bad decrypt
140704872014976:error:06065064:digital envelope 
routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:529:

Thanks!

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

Kernel: Linux 4.8.0-1-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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 openssl depends on:
ii  libc6  2.24-7
ii  libssl1.1  1.1.0c-2

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20161102

-- no debconf information

Bug#838282: ITP: gssproxy -- A privilege separation daemon for GSSAPI

[Robbie Harwood]

Package: wnpp
Followup-For: Bug #838282
Owner: Robbie Harwood <rharw...@club.cc.cmu.edu>
Control: retitle -1 ITP: gssproxy -- A privilege separation daemon for GSSAPI

* Package name: gssproxy
  Version : 0.5.1
  Upstream Author : The GSS-PROXY contributors
* URL : https://fedorahosted.org/gss-proxy/
* License : MIT
  Programming Lang: C
  Description : A privilege separation daemon for GSSAPI

gssproxy (https://fedorahosted.org/gss-proxy/) is an abstraction layer
(typically an application) between a GSS client and the credentials being
used.

In addition to the NFS use case Sven mentions, gssproxy will be useful to
freeIPA.

I am an upstream maintainer for this project.

Bug#842393: thefuck: Missing dependency on python-pkg-resources

[Robbie Harwood]

Package: thefuck
Version: 3.11-2
Severity: important

Dear Maintainer,

When run on a system without python-pkg-resources, running
`eval "$(thefuck --alias)` produces the following traceback:

> Traceback (most recent call last):
>   File "/usr/bin/thefuck", line 6, in 
> from pkg_resources import load_entry_point
> ImportError: No module named pkg_resources

which goes away (and the package works as expected) once python-pkg-resources
is installed.

Thanks!


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

Kernel: Linux 4.7.0-1-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 thefuck depends on:
ii  python-colorama   0.3.7-1
ii  python-decorator  4.0.6-1
ii  python-pathlib2   2.1.0-1
ii  python-psutil 4.3.1-1
ii  python-six1.10.0-3
ii  python2.7 2.7.12-3+b1
pn  python:any

thefuck recommends no packages.

thefuck suggests no packages.

-- no debconf information

Bug#842291: notmuch processes frequently stuck in select()

[Robbie Harwood]

David Bremner  writes:

> 1) Can you duplicate the problem with non-encrypted messages?

Not sure.  Most of the time it's inconsistent what messages it happens
for (and it's hard to see whether the message is encrypted when notmuch
won't show it to me).  I'll update with a traceback for a non-encrypted
if I can find one.

> 2) Can you duplicate the problem with the same command run outside of
>emacs?

Yes, the same command hangs outside of emacs.


signature.asc
Description: PGP signature

Bug#842291: notmuch processes frequently stuck in select()

[Robbie Harwood]

Package: notmuch
Version: 0.23.1-1
Severity: important

Dear Maintainer,

Frequently the processes notmuch-emacs spawns to view messages never finish
returning the message data.  Sometimes this is deterministic and the message
is never viewable; other times, spawning more of the same process causes the
first process to complete.

Here's a traceback from one of the processes (invoked as
/usr/bin/notmuch show --format=sexp --format-version=1 --decrypt 
--exclude=false ' thread:[redacted] and ( [redacted] )'
):

(gdb) bt
#0  0x7f1d74cff293 in __select_nocancel () at 
../sysdeps/unix/syscall-template.S:84
#1  0x7f1d736b2429 in _gpgme_ath_select (nfd=nfd@entry=10, 
rset=rset@entry=0x7ffe2d9c99e0, 
wset=wset@entry=0x7ffe2d9c9a60, eset=eset@entry=0x0, 
timeout=timeout@entry=0x7ffe2d9c99d0)
at ath-pthread.c:153
#2  0x7f1d736ad857 in _gpgme_io_select (fds=0x556a3ddb1e30, nfds=10, 
nonblock=nonblock@entry=0)
at posix-io.c:643
#3  0x7f1d7368d2de in _gpgme_wait_on_condition 
(ctx=ctx@entry=0x556a3ddb1260, cond=cond@entry=0x0, 
op_err_p=op_err_p@entry=0x0) at wait-private.c:87
#4  0x7f1d7368d4d9 in _gpgme_wait_one (ctx=ctx@entry=0x556a3ddb1260) at 
wait-private.c:170
#5  0x7f1d73691898 in gpgme_op_verify (ctx=0x556a3ddb1260, sig=, 
signed_text=0x556a3ce9eb10, plaintext=plaintext@entry=0x0) at verify.c:1147
#6  0x7f1d75985b95 in pkcs7_verify (context=, 
digest=, 
istream=, sigstream=0x556a3ce38850, err=0x7ffe2d9c9c70) at 
gmime-pkcs7-context.c:646
#7  0x7f1d7597c832 in g_mime_multipart_signed_verify (mps=, 
ctx=ctx@entry=0x556a3ce5f630, err=err@entry=0x7ffe2d9c9c70) at 
gmime-multipart-signed.c:466
#8  0x556a3c5f1c80 in node_verify (cryptoctx=0x556a3ce5f630, 
part=0x556a3ce3cf00, 
node=0x556a3ce7e100) at mime-node.c:159
#9  _mime_node_create (part=0x556a3ce3cf00, parent=0x556a3ddc92d0) at 
mime-node.c:267
#10 mime_node_child (parent=parent@entry=0x556a3ddc92d0, child=child@entry=0) 
at mime-node.c:296
#11 0x556a3c5eed6d in format_part_sprinter (ctx=0x556a3ddb7cc0, 
sp=0x556a3ce5e540, 
node=0x556a3ddc92d0, first=1, output_body=1, include_html=0) at 
notmuch-show.c:563
#12 0x556a3c5ef486 in format_part_sprinter_entry (ctx=, 
sp=, 
node=, indent=, params=) at 
notmuch-show.c:670
#13 0x556a3c5edfc0 in show_message (ctx=ctx@entry=0x556a3ce38200, 
sp=sp@entry=0x556a3ce5e540, 
message=message@entry=0x556a3ddb87a0, indent=indent@entry=3, 
params=params@entry=0x7ffe2d9c9fa0, 
format=) at notmuch-show.c:827
#14 0x556a3c5ee0b9 in show_messages (ctx=ctx@entry=0x556a3ce38200, 
format=format@entry=0x556a3c7fd280 , 
sp=sp@entry=0x556a3ce5e540, 
messages=0x556a3ddb5aa0, indent=indent@entry=3, 
params=params@entry=0x7ffe2d9c9fa0)
at notmuch-show.c:863
#15 0x556a3c5ee0fc in show_messages (ctx=ctx@entry=0x556a3ce38200, 
format=format@entry=0x556a3c7fd280 , 
sp=sp@entry=0x556a3ce5e540, 
messages=0x556a3ce81700, indent=indent@entry=2, 
params=params@entry=0x7ffe2d9c9fa0)
at notmuch-show.c:871
#16 0x556a3c5ee0fc in show_messages (ctx=ctx@entry=0x556a3ce38200, 
format=format@entry=0x556a3c7fd280 , 
sp=sp@entry=0x556a3ce5e540, 
messages=0x556a3ce846c0, indent=indent@entry=1, 
params=params@entry=0x7ffe2d9c9fa0)
at notmuch-show.c:871
#17 0x556a3c5ee0fc in show_messages (ctx=ctx@entry=0x556a3ce38200, 
format=format@entry=0x556a3c7fd280 , 
sp=sp@entry=0x556a3ce5e540, 
messages=0x556a3ce6dec0, indent=indent@entry=0, 
params=params@entry=0x7ffe2d9c9fa0)
at notmuch-show.c:871
#18 0x556a3c5efd9f in do_show (params=0x7ffe2d9c9fa0, sp=0x556a3ce5e540, 
format=0x556a3c7fd280 , query=0x556a3ce3dfd0, 
ctx=0x556a3ce38200) at notmuch-show.c:959
#19 notmuch_show_command (config=0x556a3ce38200, argc=, 
argv=)
at notmuch-show.c:1171
#20 0x556a3c5e1b8f in main (argc=, argv=0x7ffe2d9ca458) at 
notmuch.c:421
(gdb) 


(Versions of programs are the latest I could install, but it also occurs with
about the same frequency when everything is from testing.)

Thanks!

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

Kernel: Linux 4.7.0-1-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 notmuch depends on:
ii  libc6   2.24-5
ii  libglib2.0-02.50.1-1
ii  libgmime-2.6-0  2.6.20-8
ii  libnotmuch4 0.23.1-1
ii  libtalloc2  2.1.8-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages notmuch recommends:
ii  gnupg-agent2.1.15-4
ii  gpgsm  2.1.15-4
ii  notmuch-emacs  0.23.1-1

notmuch suggests no packages.

-- no debconf information

Bug#839844: freeipa-client: Uninstallable due to unsatisfiable Depends:

[Robbie Harwood]

Package: freeipa-client
Version: 4.3.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

freeipa-client currently cannot be installed due to the following nonexistent
dependencies:

Depends: freeipa-common (= 4.3.2-2) which is a virtual package and is not
provided by any available package
Depends: python-ipaclient (= 4.3.2-2) which is a virtual package and is not
  provided by any available package

Thanks.

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

Kernel: Linux 4.7.0-1-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)

Bug#829749: krb5-kdc-ldap: kerberos.schema.gz is a config file

[Robbie Harwood]

Package: krb5-kdc-ldap
Severity: normal

Dear Maintainer,

When deploying an LDAP KDC, the LDAP configuration needs the kerberos schema
file.  However, this file is treated as documentation and therefore is
compressed.  This means that when deploying, it must be extracted somewhere
(probably /etc/ldap/schema ) before being included.  In addition to being an
extra step that other distributions do not require, this means that updates to
kerberos.schema in the krb5-kdc-ldap package will not propogate to users.

Packaging in this manner was requested as part of 1.6 in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479239 but I don't see a
justification there for these being documentation rather than configuration.
Is there a reason they're treated as such?

Thanks!

Bug#825749: xul-ext-foxyproxy-standard: foxyproxy cannot be installed if icedove 45 is present

[Robbie Harwood]

Package: xul-ext-foxyproxy-standard
Version: 4.5.6-debian-1
Severity: important

Dear Maintainer,

It is currently not possible to have both xul-ext-foxyproxy-standard and
icedove 45.1.0-1 (i.e., the icedove from sid) present on the same system:

```
$ aptitude -s install -t unstable icedove
The following packages will be REMOVED:
  libhunspell-1.3-0{u}
The following packages will be upgraded:
  icedove{b} iceowl-extension
2 packages upgraded, 0 newly installed, 1 to remove and 224 not upgraded.
Need to get 0 B/32.6 MB of archives. After unpacking 5,036 kB will be freed.
The following packages have unmet dependencies:
 icedove : Breaks: xul-ext-foxyproxy-standard (> 3.4-1) but 4.5.6-debian-1 is 
installed.
The following actions will resolve these dependencies:

Remove the following packages:
1) xul-ext-foxyproxy-standard



Accept this solution? [Y/n/q/?] 
```

I understand that as per [0] there are some issues with actually using
foxyproxy in icedove, but this will prevent usage in firefox as well, and it
still works there.

Thanks!

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815000

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

Kernel: Linux 4.5.0-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
Init: sysvinit (via /sbin/init)

Versions of packages xul-ext-foxyproxy-standard depends on:
ii  firefox-esr  45.1.1esr-1+b1
ii  icedove  38.6.0-1

xul-ext-foxyproxy-standard recommends no packages.

xul-ext-foxyproxy-standard suggests no packages.

-- no debconf information

Bug#821844: elpa-magit: [RFE] Please include magit subcomponents

[Robbie Harwood]

Package: elpa-magit
Version: 2.6.1-1
Severity: wishlist

Dear Maintainer,

I'm primarily interested in magit-stgit here, though there are other git
component integrations that upstream has available[0].  Since we have stgit
and magit both available, it would be great if the integration glue were also
packaged[1].  I think it makes sense to include these in the magit packaging,
so I'm filing this rather than a RFP.

Thanks!

[0]: https://github.com/magit
[1]: https://github.com/magit/magit-stgit

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

Kernel: Linux 4.4.0-1-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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 elpa-magit depends on:
ii  dash-el   2.12.1-1
ii  elpa-git-commit   2.6.0-1
ii  elpa-magit-popup  2.6.1-1
ii  elpa-with-editor  2.5.0-1
ii  emacsen-common2.0.8
ii  git   1:2.8.0~rc3-1

elpa-magit recommends no packages.

elpa-magit suggests no packages.

-- no debconf information

Bug#722017: xfonts-terminus: iso10646 font is unusable with xterm

[Robbie Harwood]

Package: xfonts-terminus
Version: 4.39-1
Followup-For: Bug #722017

Dear Maintainer,

This issue also manifests in other programs, such as xmobar and dzen2 (and GUI
emacs, if you believe stack overflow).  I noticed this issue on upgrade from
stable, where it was previously working.

Please fix this.  It makes Terminus very difficult to use in UTF-8
environments when every chareacter gets replaced with 'n'.

Thanks!

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

Kernel: Linux 4.3.0-1-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 xfonts-terminus depends on:
ii  xfonts-utils  1:7.7+3

xfonts-terminus recommends no packages.

Versions of packages xfonts-terminus suggests:
ii  tightvncserver [xserver]  1.3.9-7
ii  xfonts-terminus-oblique   4.39-1
ii  xserver-xorg [xserver]1:7.7+13

-- no debconf information

Bug#812131: krb5: Please package 1.14 (willing to provide assistance)

[Robbie Harwood]

Sam Hartman  writes:

> Hi.
> I hope to get to this in the next week or so; sorry about the delay.

Sounds good.  Thanks for doing it!


signature.asc
Description: PGP signature

Bug#812131: krb5: Please package 1.14 (willing to provide assistance)

[Robbie Harwood]

Source: krb5
Severity: important

Dear Maintainer,

As per http://web.mit.edu/kerberos/ krb5-1.14 has been available since
2015-11-20.  Please consider packaging this new version, even if only in
experimental.

If it would be helpful, I am willing to provide labor.  I maintain an
rdependency (python{3,}-gssapi) in Debian that has an interest in having a
newer krb5, and additionally I am the Fedora maintainer for krb5 (where we
have had 1.14 since its release).

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

Kernel: Linux 4.3.0-1-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)

Bug#810923: virtinst: virt-install fails to create working ppc64 (& other non-native) VMs

[Robbie Harwood]

Package: virtinst
Version: 1:1.2.1-4
Severity: important

Dear Maintainer,

When following the normal process for creating a ppc64 VM (e.g.,
https://rwmj.wordpress.com/2015/04/15/virt-builder-fedora-21-ppc64-and-ppc64le-images/
), it will fail complaining about vmport.  I believe this is this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1259998

Assuming one can get beyond that (e.g., with VNC set), the resulting machine
will fail with no output.  Logs reveal that

2016-01-13 18:49:40.822+: starting up libvirt version: 1.3.0, package: 2 
(Guido Günther  Wed, 06 Jan 2016 00:04:12 +0100), qemu 
version: 2.5.0 (Debian 1:2.5+dfsg-3), hostname: thriss
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none 
/usr/bin/qemu-system-ppc64 -name rhel6-ppc64 -S -machine 
pseries-2.5,accel=tcg,usb=off -cpu POWER8 -m 2048 -realtime mlock=off -smp 
1,sockets=1,cores=1,threads=1 -uuid 98d818e6-b5c5-43b1-8381-da6ca420aec8 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-rhel6-ppc64/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-no-shutdown -boot strict=on -device 
ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 
-device spapr-vscsi,id=scsi0,reg=0x2000 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive 
file=/var/lib/libvirt/images
 /rhel6-ppc64.img,if=none,id=drive-scsi0-0-0-0,format=raw -device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2
 -drive 
file=/home/bos/rharwood/iso/RHEL-6.7-20150702.0-Server-ppc64-dvd1.iso,if=none,id=drive-scsi0-0-0-1,readonly=on,format=raw
 -device 
scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1
 -netdev tap,fd=29,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3a:c7:37,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device 
spapr-vty,chardev=charserial0,reg=0x3000 -device usb-tablet,id=input0 
-device usb-kbd,id=input1 -device usb-mouse,id=input2 -vnc 127.0.0.1:0 -device 
VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x1 -chardev 
spicevmc,id=charredir0,name=usbredir -device 
usb-redir,chardev=charredir0,id=redir0 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -obj
 ect rng-random,id=objrng0,filename=/dev/random -device 
virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x8 -msg timestamp=on
char device redirected to /dev/pts/3 (label charserial0)
qemu: fatal: Trying to execute code outside RAM or ROM at 0xf92169f8

NIP f92169f8   LR 631c CTR f92169f8 XER 
 CPU#0
MSR 8000 HID0   HF 8000 idx 1
TB  07931969 DECR 4287035593
GPR00 631c bba0 00014398 bd60
GPR04 0140 7268 bc10 bd61
GPR08 006c f9210180 f92169f8 7fbbd590
GPR12 0001  726b 002d
GPR16  0001 0030 0078
GPR20 73b8 bf58 0020 0020
GPR24 0004 0140  bd60
GPR28 bd20 bc31 7260 
CR 4208  [ G  -  -  -  -  E  -  L  ] RES 
FPR00    
FPR04    
FPR08    
FPR12    
FPR16    
FPR20    
FPR24    
FPR28    
FPSCR 
 SRR0   SRR1 PVR 004d0100 VRSAVE 

SPRG0  SPRG1   SPRG2   SPRG3 

SPRG4  SPRG5   SPRG6   SPRG7 

 CFAR 67e0
 SDR1 7fbd3f06   DAR   DSISR 
2016-01-13 18:49:41.358+: shutting down

These happen to be the RHEL logs, but the failure mode is the same for Fedora
as well.

Thanks!

-- System Information:

Bug#808576: [Pkg-rust-maintainers] Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"

[Robbie Harwood]

Sylvestre Ledru  writes:

> Le 21/12/2015 14:02, Luca Bruno a écrit :
>> On Monday 21 December 2015 12:27:47 Luca Bruno wrote:
>> 
>>> For reference, current working sid toolchain is ld 2.25.90.20151209 and gcc
>>> 5.3.1-4.
>> 
>> Similarly, I tried in a fresh stretch environment and it works fine.
>> The toolchain there is ld 2.25.90.20151209 and gcc 5.3.1-3.
> As mentioned on #debian-rust this morning, it seems the same as:
> https://github.com/rust-lang/rust/issues/30305
>
> Rust 1.5 cherry-picked from unstable on a testing system?

All correct.  Updating binutils to the testing/unstable version fixes
it.  Thanks for your help!


signature.asc
Description: PGP signature

Bug#808576: rustc cannot compile programs: "unrecognized relocation in section"

[Robbie Harwood]

Package: rustc
Version: 1.5.0+dfsg1-1
Severity: important

Dear Maintainer,

When I try to build any rust program, the following occurs:

$ cat > main.rs
fn main() {
  print!("Hello, world!\n");
  }
$ rustc main.rs
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-m64" "-L" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "main.0.o" "-o" "main" 
"-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-L" 
"/home/frozencemetery/.rust/lib/x86_64-unknown-linux-gnu" "-L" 
"/home/frozencemetery/lib/x86_64-unknown-linux-gnu" "-Wl,-Bstatic" 
"-Wl,-Bdynamic" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-35c36e89.rlib" 
"/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-35c36e89.rlib" "-l" "dl" 
"-l" "pthread" "-l" "gcc_s" "-l" "rt" "-l"
  "pthread" "-l" "c" "-l" "m" "-l" "compiler-rt"
note: /usr/bin/ld: 
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-35c36e89.rlib(jemalloc.pic.o):
 unrecognized relocation (0x2a) in section `.text.malloc_conf_init'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

error: aborting due to previous error
$

Please let me know if I can provide more information.  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/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
Init: sysvinit (via /sbin/init)

Versions of packages rustc depends on:
ii  libc62.19-18+deb8u1
ii  libstd-rust-dev  1.5.0+dfsg1-1

Versions of packages rustc recommends:
ii  rust-gdb  1.5.0+dfsg1-1

Versions of packages rustc suggests:
pn  rust-doc  

-- no debconf information

Bug#807963: virt-viewer: Segmentation fault on connection to spice vm

[Robbie Harwood]

Package: virt-viewer
Version: 1.0-1
Severity: important

Dear Maintainer,

When attempting to connect to VMs over SPICE, virt-viewer will consistently
segfault as so:

$ gdb -q virt-viewer
Reading symbols from virt-viewer...(no debugging symbols found)...done.
(gdb) set args --connect qemu:///system 1
(gdb) r
Starting program: /usr/bin/virt-viewer --connect qemu:///system 1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe21e3700 (LWP 27850)]
[New Thread 0x7fffe19e2700 (LWP 27851)]
[New Thread 0x7fffe0a3b700 (LWP 27852)]

(virt-viewer:27846): GSpice-WARNING **: PulseAudio context failed Connection
refused

(virt-viewer:27846): GSpice-WARNING **: pa_context_connect() failed:
Connection refused

Program received signal SIGSEGV, Segmentation fault.
0x742087a0 in ?? () from
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
(gdb) bt
#0  0x742087a0 in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#1  0x74221bc9 in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#2  0x7422253b in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#3  0x7421273e in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#4  0x74212964 in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#5  0x74214630 in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#6  0x7423d81b in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#7  0x7423d643 in ?? () from 
/usr/lib/x86_64-linux-gnu/libspice-client-glib-2.0.so.8
#8  0x73c73f60 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x0096c5a8 in ?? ()
#10 0x in ?? ()
(gdb)

Looking around, it is possible that this may be
https://bugzilla.redhat.com/show_bug.cgi?id=1257210

Thanks!

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

Kernel: Linux 4.2.0-1-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 virt-viewer depends on:
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.19-22
ii  libcairo-gobject2   1.14.4-1
ii  libcairo2   1.14.4-1
ii  libgdk-pixbuf2.0-0  2.32.2-1
ii  libglib2.0-02.46.2-1
ii  libgtk-3-0  3.18.5-1
ii  libgtk-vnc-2.0-00.5.3-1.3
ii  libgvnc-1.0-0   0.5.3-1.3
ii  libpango-1.0-0  1.38.1-1
ii  libpangocairo-1.0-0 1.38.1-1
ii  libspice-client-glib-2.0-8  0.29-1+b1
ii  libspice-client-gtk-3.0-4   0.29-1+b1
ii  libvirt01.2.21-2
ii  libxml2 2.9.2+zdfsg1-4

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.105-7
ii  netcat-traditional [netcat]  1.10-41

-- no debconf information

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  

Bug#783224: boinctui segmentation fault on start

[Robbie Harwood]

Sergey Suslov  writes:

> Thanks for bug report. Unfortunately, I can't reproduce this bug on my
> configuration (i386 instead x86_64, all other like as your). Can you
> try to start boinctui without ~/.boinctui.cfg file (remove or rename)?

Turns out my .boinctui.cfg file being empty causes this.  If it's
nonexistent, boinctui will write one; if it exists and is empty, it
becomes upset.


signature.asc
Description: PGP signature

Bug#796287: openrc: Please package new version

[Robbie Harwood]

Package: openrc
Version: 0.13.1-4
Severity: normal

Dear Maintainers,

A new version of this package is available upstream.  Please, please package
it in testing/unstable.  Thanks!

-- System Information:
Debian Release: 8.1
  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/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
Init: sysvinit (via /sbin/init)

Versions of packages openrc depends on:
ii  insserv1.14.0-5
ii  libc6  2.19-18
ii  libeinfo1  0.13.1-4
ii  librc1 0.13.1-4

openrc recommends no packages.

openrc suggests no packages.

-- Configuration Files:
/etc/rc.conf changed [not included]

-- no debconf information

Bug#794980: ITP: python-gssapi, python3-gssapi -- Python Python3 interfaces to GSSAPI

[Robbie Harwood]

Package: wnpp
Version: N/A; reported 2015-08-08
Severity: wishlist

* Package name  : python-gssapi, python3-gssapi
  Version   : 1.1.2
  Upstream Author   : The Python GSSAPI Team
* URL   : https://github.com/pythongssapi/python-gssapi/
* License   : ISC
  Programming Lang  : Python
  Description   : Python interface to GSSAPI

Python Bindings for GSSAPI.  These bindings are for both RFC 2743/2744
and many extensions.  They are native bindings produced using Cython.

This package will be needed by at least the next release of freeipa, and
can also be consumed python3-ldap3, among others.

I am an upstream author with commit access.  Dafydd Harries
d...@debian.org has agreed to sponsor this package.


signature.asc
Description: PGP signature

Bug#794042: hydrogen: Hydrogen segfault on adding from sound library

[Robbie Harwood]

Package: hydrogen
Version: 0.9.6.1-1
Severity: important

Dear Maintainer,

Sporadically, hydrogen will crash.  This seems to be co-incident with adding
instruments to the current loop.  Here is a traceback:

Program received signal SIGABRT, Aborted.
0x73b2d107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or 
directory.
(gdb) bt
#0  0x73b2d107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x73b2e4e8 in __GI_abort () at abort.c:89
#2  0x73b26226 in __assert_fail_base (fmt=0x73c5cce8 %s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n, assertion=assertion@entry=0x61e858 idx_b = 0 
 idx_b  __instruments.size(), file=file@entry=0x61e7e0 
/tmp/buildd/hydrogen-0.9.6.1/src/core/src/basics/instrument_list.cpp, 
line=line@entry=202,function=function@entry=0x61e940 void 
H2Core::InstrumentList::move(int, int)) at assert.c:92
#3  0x73b262d2 in __GI___assert_fail (assertion=0x61e858 idx_b = 0  
idx_b  __instruments.size(), file=0x61e7e0 
/tmp/buildd/hydrogen-0.9.6.1/src/core/src/basics/instrument_list.cpp, 
line=202, function=0x61e940 void H2Core::InstrumentList::move(int, int)) at 
assert.c:101
#4  0x00584ba5 in H2Core::InstrumentList::move(int, int) ()
#5  0x0048c341 in DrumPatternEditor::functionMoveInstrumentAction(int, 
int) ()
#6  0x0048c527 in 
DrumPatternEditor::functionDropInstrumentRedoAction(QString, QString, int) ()
#7  0x004987cf in SE_dragInstrumentAction::redo() ()
#8  0x7792db53 in QUndoStack::push(QUndoCommand*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9  0x004970b0 in PatternEditorInstrumentList::dropEvent(QDropEvent*) ()
#10 0x77306748 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#11 0x772b348c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x772bbb0f in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x76a3271d in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#14 0x7733e500 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#15 0x7733e895 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#16 0x7733fb20 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x76a327f2 in 
QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#18 0x772b3418 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#19 0x772ba10f in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#20 0x76a3271d in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#21 0x772b976f in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointerQWidget, bool) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x77330432 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#23 0x7732ee2c in QApplication::x11ProcessEvent(_XEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#24 0x77357ed2 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#25 0x733dbc5d in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x733dbf48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x733dbffc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x76a61d1d in 
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () 
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#29 0x77357f96 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#30 0x76a31271 in 
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#31 0x76a315d5 in 
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#32 0x7733fe4d in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#33 0x772c5084 in QDrag::start(QFlagsQt::DropAction) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#34 0x00477613 in 
SoundLibraryPanel::on_DrumkitList_mouseMove(QMouseEvent*) ()
#35 0x76a4771c in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#36 0x00531c30 in SoundLibraryTree::onMouseMove(QMouseEvent*) ()
#37 0x77306748 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#38 0x776c883e in QFrame::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#39 0x777e5703 in 

Bug#790055: msmtp: Please compile with GSSAPI support

[Robbie Harwood]

Robbie Harwood rharw...@club.cc.cmu.edu writes:

 Package: msmtp
 Version: 1.4.32-2+b1
 Severity: normal

 Dear Maintainer,

 When attempting to use GSSAPI for authentication with msmtp, the following
 message is returned:

 msmtp: support for authentication method GSSAPI is not compiled in

 Please compile with GSSAPI support.  Thanks!

Okay, I went and looked at the rules file, and it looks like the
--with-gsasl argument *is* being passed to configure properly, and the
resulting msmtp binary is linked to libgsasl (and the package depends on
it).  I don't know what's gone wrong here.


signature.asc
Description: PGP signature

Bug#790055: msmtp: Please compile with GSSAPI support

[Robbie Harwood]

Package: msmtp
Version: 1.4.32-2+b1
Severity: normal

Dear Maintainer,

When attempting to use GSSAPI for authentication with msmtp, the following
message is returned:

 msmtp: support for authentication method GSSAPI is not compiled in

Please compile with GSSAPI support.  Thanks!

-- System Information:
Debian Release: 8.1
  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/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
Init: sysvinit (via /sbin/init)

Versions of packages msmtp depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18
ii  libgnutls-deb0-28  3.3.8-6+deb8u1
ii  libgsasl7  1.8.0-6
ii  libidn11   1.29-1+b2
ii  ucf3.0030

Versions of packages msmtp recommends:
ii  ca-certificates  20141019

Versions of packages msmtp suggests:
pn  msmtp-mta  none

-- 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#783224: boinctui segmentation fault on start

[Robbie Harwood]

Package: boinctui
Version: 2.3.5-1
Severity: important

Dear Maintainer,

Boinctui was previously operational.  However, when I try to start it now, it
clears the screen and then prints Segmentation fault.  Reproducing the crash
in gdb produces

(gdb) bt
#0  0x0041a1a3 in ?? ()
#1  0x004113a4 in ?? ()
#2  0x00404d8a in ?? ()
#3  0x76164b45 in __libc_start_main (main=0x404d60, argc=1, 
argv=0x7fffe878, init=optimized out, fini=optimized out, 
rtld_fini=optimized out, stack_end=0x7fffe868) at libc-start.c:287
#4  0x00404e18 in ?? ()
(gdb) 

Thanks!

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

Kernel: Linux 3.16.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
Init: sysvinit (via /sbin/init)

Versions of packages boinctui depends on:
ii  libc62.19-18
ii  libexpat12.1.0-6+b3
ii  libgcc1  1:4.9.2-10
ii  libgnutls-openssl27  3.3.8-6
ii  libncursesw5 5.9+20140913-1+b1
ii  libstdc++6   4.9.2-10
ii  libtinfo55.9+20140913-1+b1

boinctui recommends no packages.

Versions of packages boinctui suggests:
ii  boinc-client  7.4.23+dfsg-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#771770: haskell-mode copiously displays its documentation

[Robbie Harwood]

David Bremner da...@tethera.net writes:

 Robbie Harwood rharw...@club.cc.cmu.edu writes:

 Makes sense.  The problem I'm having is that it's not clear how to turn
 it off, especially since I don't want any indentation.

 I think what you want then is to turn off electric-indent-mode, perhaps
 in a hook of haskell-mode. I have a vague memory that the default for
 this mode changed in 24.4.

 UNTESTED:

 (add-hook 'haskell-mode-hook
   (lambda ()
   (electric-indent-local-mode -1)))

That is exactly what I want, thanks!


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

Bug#771770: haskell-mode copiously displays its documentation

[Robbie Harwood]

David Bremner da...@tethera.net writes:

 Robbie Harwood rharw...@club.cc.cmu.edu writes:

 Package: haskell-mode
 Version: 13.10-3
 Severity: important

 Dear Maintainer,

 When a newline is entered into a buffer in Haskell mode, the view is
 split and a *Help* buffer appears displaying documentation for
 haskell-mode-hook.  That is, it displays:

 haskell-mode-hook is a variable defined in `haskell-mode.el'.
 Its value is nil

   This variable may be risky if used as a file-local variable.

 In fact it's not quite being copious enough. In emacs23 (I didn't have
 24.3 on hand) it actually tells you that you want to
 turn-on-haskell-indent or equivalent to set up some haskell indentation
 mode.  You will notice a similar strange effect if you hit tab. I think
 the best workaround is to add a more complete configuration for
 haskell-mode to your .emacs.d/init.el.

Makes sense.  The problem I'm having is that it's not clear how to turn
it off, especially since I don't want any indentation.


signature.asc
Description: PGP signature