Bug#850180: mdadm: systemd units do not obey /etc/default/mdadm, esp DAEMON_OPTIONS=--syslog

[Matthew Gabeler-Lee]

Package: mdadm
Version: 3.4-4+b1
Followup-For: Bug #850180

The DAEMON_OPTIONS bit of this is trivially corrected with this patch:

--- mdmonitor.service.orig  2017-09-26 00:54:25.491632797 -0400
+++ /lib/systemd/system/mdmonitor.service   2017-09-26 00:54:29.047611746 
-0400
@@ -10,4 +10,5 @@
 DefaultDependencies=no
 
 [Service]
-ExecStart=/sbin/mdadm --monitor --scan
+EnvironmentFile=-/etc/default/mdadm
+ExecStart=/sbin/mdadm --monitor --scan $DAEMON_OPTIONS


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable'), (490, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  lsb-base   9.20161125
ii  udev   232-25+deb9u1

Versions of packages mdadm recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u1
ii  kmod   23-2

mdadm suggests no packages.

-- Configuration Files:
/etc/cron.daily/mdadm changed [not included]

-- debconf information excluded

Bug#874673: python-keyring: CLI tool is not properly installed

[Matthew Gabeler-Lee]

Package: python-keyring
Version: 10.1-1
Severity: normal

This package comes with a command line helper tool, but it is not installed
properly as such as part of the package.

/usr/lib/python2.7/dist-packages/keyring/cli.py is installed, but not as a
tool in /usr/bin/, and further it cannot even be run directly from the
location it is installed:

$ python /usr/lib/python2.7/dist-packages/keyring/cli.py
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/keyring/cli.py", line 10, in 
from . import get_keyring, set_keyring, get_password, set_password, 
delete_password
ValueError: Attempted relative import in non-package

The python3-keyring version of the package seems to have this same issue
based on the file list, though I haven't tried installing it to verify
directly.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 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: systemd (via /run/systemd/system)

Versions of packages python-keyring depends on:
ii  python2.7.13-2
ii  python-dbus   1.2.4-1+b1
ii  python-secretstorage  2.3.1-2

Versions of packages python-keyring recommends:
pn  python-keyrings.alt  

Versions of packages python-keyring suggests:
ii  gnome-keyring 3.20.0-3
pn  libkf5wallet-bin  

-- no debconf information

Bug#873040: getmail4: Parallel version of /usr/bin/getmails

[Matthew Gabeler-Lee]

On Sun, 27 Aug 2017, Osamu Aoki wrote:


Hi,

Thanks but ...

I thought about it but didn't do this.  I understand your needs but this
will cause screen output with -v a bit difficult to read.

If you make this feature addition patch as an optional feature enabled
by "-p" option, I will take it ;-)  Also if you can update manpage
accordingly, I appreciate.


Fair points.  I'll give that a go :)

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#872943: libpam-heimdal: Cannot configure credential cache file

[Matthew Gabeler-Lee]

On Wed, 23 Aug 2017, Russ Allbery wrote:


You'd also mentioned that you had read the man page about this, so I think
there's a bug here in the man page and how it discusses options that I'd
love to try to fix.  It looks like the way to do this wasn't obvious
enough.  The key bit, though, is here: [snip]


Aah, now I see.  Indeed I was a bit hasty when scanning the manpage for 
the thing I wanted to change (I think I just searched for "krb5cc_" 
since that's what I wanted to change).



This *should* work; please let me know if it doesn't.


Gave it a whirl, it works ... after I sort out my typos ;)


And let me know if
there's a way that I can make this information easier to find in the man
page.


A possible wording for the individual options that might help point 
folks back at the krb5.conf explanation without being too wordy (since 
it gets repeated a lot):


"This option can be set in the [appdefaults]/pam section or krb5.conf, 
..."



I should probably also call out that the PAM module doesn't use the
library default ccache location.  (I should also remember why I did that;
I know I had a specific reason, but I don't remember what it was.)


Agreed -- looking through the man page more carefully, I notice there is 
some discussion about a similar issue relating to how realms are 
handled, it would make sense to add a note about not using the normal 
defaults to this parameter too.


Thinking it through, I have a hunch why using the default "just specific 
to the UID" cache might be a bad idea if you don't have a daemon like 
winbindd to help manage sessionss:


If you log in once, and then a second time, and then log out one of 
those two sessions, that would empty/destroy the cache, leaving the 
other session with no ticket(s).  I just tested that, and indeed it is 
the case.


(pam)_winbind(d) doesn't have this problem, I think because it uses the 
daemon to be aware of the multiple sessions, so it can advise them if 
they are the "last" one and thus whether the cache should be destroyed 
or not when each sesssion exits.


But without that kind of support, it's a good reason to have pam_krb5 
default to a per-session ticket cache.  It complicates upcalls and 
anything else that wants to leverage a session's ticket cache from 
outside the session, but I'm not sure there's any easy way around that.



For my edification, can you explain why /usr/share/pam-configs/krb5
can't be made a conffile?


Files in /usr are not permitted to be configuration files.

Now, the other question is why these files aren't in /etc somewhere, which
would allow them to be conffiles and configuration files.  That's a good
question -- I don't really know off the top of my head why it was defined
that way.  I'm pretty sure it was discussed in the original PAM
configuration proposal for pam-auth-update.  The intent was that this
system should only be used if you want a fully-default PAM configuration
given the modules you have installed, but I'm not sure why that was the
intent.


Thanks for explaining.  I can run with that and see what I can find, and 
maybe propose a change to the PAM maintainer(s).


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#873040: getmail4: Parallel version of /usr/bin/getmails

[Matthew Gabeler-Lee]

Package: getmail4
Version: 4.53.0-1
Severity: wishlist
Tags: patch

Attached is an improved (IMO) version of /usr/bin/getmails that launches a
separate getmail process for each config file, in parallel, and then waits
for them to all complete, exiting with the "worst" (greatest) exit code of
any of the individual instances.

I wrote this for myself because I'm using it to keep a backup of a couple
gmail accounts that are now, for some reason, taking nearly 30 minutes each
just to enumerate the list of messages (I have a feeling I may have hit some
overuse throttle at Google since the message list data is coming down at
dialup speeds).

Loosely relates to #863856, but does not implement that suggestion.  Also
not handled (at least not in any pretty way) is what happens if you run it
with no getmail configs in the specified directory.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 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: systemd (via /run/systemd/system)

Versions of packages getmail4 depends on:
ii  python  2.7.13-2

getmail4 recommends no packages.

getmail4 suggests no packages.

-- no debconf information
#!/bin/sh
# vim:se tw=78 sts=4:
# Copyright (C) Osamu Aoki , GPL2+
set -e
UID_BY_ID=$(id -u)
PID_GETMAILS=$(pgrep -U $UID_BY_ID '^getmails$')
if [ "x$PID_GETMAILS" != "x$$" ]; then
echo "The getmails script is already running as PID=\"$PID_GETMAILS\" 
." >&2
exit 1
fi
if [ -f $HOME/.getmail/stop ]; then
echo "Do not run getmail ... (if not, remove $HOME/.getmail/stop)" >&2
exit 1
fi
pids=""
rcfiles="/usr/bin/getmail"
for file in $HOME/.getmail/config/* ; do
/usr/bin/getmail --rcfile "$file" &
pids="$pids $!"
done
rc=0
if [ -n "$pids" ]; then
for pid in $pids ; do
wait $pid
prc=$?
if [ $prc -gt $rc ]; then
rc=$prc
fi
done
fi
exit $rc

Bug#872943: libpam-heimdal: Cannot configure credential cache file

[Matthew Gabeler-Lee]

On Tue, 22 Aug 2017, Russ Allbery wrote:


Matthew Gabeler-Lee <chee...@fastcat.org> writes:


1) The documentation claims you can set the credential cache filename in
krb5.conf, but this appears to be a lie.  If you don't give the pam ccache=
option, then it uses a hard coded string to form the cache filename,
disregarding any settings in krb5.conf.


Could you show me your krb5.conf file where you tried to set this?



[libdefaults]
default_realm = our.active.directory.realm
dns_lookup_realm = false
dns_lookup_kdc = true
# added this line:
default_cc_name = /tmp/krb5cc_%{uid}

I also tried without the path and with %u instead of %{uid}.  None of it 
worked.  I resorted to UTSL, and was not surprised it hadn't worked:


setcred.c, function build_ccache_name:
if (args->config->ccache == NULL) {
retval = asprintf(_name, "%s/krb5cc_%d_XX",
  args->config->ccache_dir, (int) uid);
// ...

From what I can see, there is simply no case in this package's code 
where it visibly reads the krb5.conf file, nor where it allows the krb5 
implementation library to use whatever defaults are in krb5.conf.  It 
always seems to give an explicit filename to the krb5 library that will 
override whatever is in krb5.conf.



Yeah, this is how the PAM update system works.  I can't change this as a
PAM package maintainer (and there are a bunch of reasons why it works this
way).


For my edification, can you explain why /usr/share/pam-configs/krb5 
can't be made a conffile?  It would solve this frustration, and some 
related frustrations I've had with other libpam-foo packages.  I assume 
there is a good reason for it, it's just not obvious to me what that is.


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#872958: bridge-utils: Should support hairpin configuration

[Matthew Gabeler-Lee]

Package: bridge-utils
Version: 1.5-13
Severity: normal

bridge-utils can do almost any brctl command with some nice directives in
/etc/network/interfaces ...  except configure hairpin mode on ports.

>From the looks of /lib/bridge-utils/ifupdown.sh, this seems like it
shouldn't be too hard to implement, something like this has the feel of
being close?

if [ "$IF_BRIDGE_HAIRPIN_PORTS" ]; then
  bridge_parse_ports $IF_BRIDGE_HAIRPIN_PORTS | while read i ; do
for port in $i ; do
  brctl hairpin $IFACE $port on
done
  done
fi

I also notice that the hairpin command to brctl is missing from the man pages.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 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: systemd (via /run/systemd/system)

Versions of packages bridge-utils depends on:
ii  libc6  2.24-11+deb9u1

bridge-utils recommends no packages.

Versions of packages bridge-utils suggests:
ii  ifupdown  0.8.19

-- no debconf information

Bug#872943: libpam-heimdal: Cannot configure credential cache file

[Matthew Gabeler-Lee]

Package: libpam-heimdal
Version: 4.7-4
Severity: normal

The libpam-krb5 package has a couple issues when trying to configure
credential cache files:

1) The documentation claims you can set the credential cache filename in
krb5.conf, but this appears to be a lie.  If you don't give the pam ccache=
option, then it uses a hard coded string to form the cache filename,
disregarding any settings in krb5.conf.

2) Because /usr/share/pam-configs/krb5 is not a conffile, there's no way to
edit the pam settings without risking them getting clobbered on a package
update, other than by disabling the module in the system level config and
then adding it back in by hand, which is a bit of a pain in the tuchus.

Background: I want to change this so that cifs.upcall can find the user's
credential cache, which seems to require that to be in a predictable
location like pam_winbind creates (/tmp/krb5cc_UID).

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 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: systemd (via /run/systemd/system)

Versions of packages libpam-heimdal depends on:
ii  krb5-config 2.6
ii  libc6   2.24-11+deb9u1
ii  libkrb5-26-heimdal  7.1.0+dfsg-13+deb9u1
ii  libpam-runtime  1.1.8-3.6
ii  libpam0g1.1.8-3.6

libpam-heimdal recommends no packages.

libpam-heimdal suggests no packages.

-- no debconf information

Bug#803924: for stretch?

[Matthew Gabeler-Lee]

Is this fix queued to end up in stretch?  A prior mail suggests maybe it
is, but not clear?  Will that not be released until the stretch 9.1
update goes out?

Bug#827593: new upstream (2.9.8.3)

[Matthew Gabeler-Lee]

On 03/17/2017 12:59 PM, Matthew Gabeler-Lee wrote:
> Further, I would note that upstream has now officially End of Life'd 2.9.7.x

And now they have discontinued providing rules for 2.9.7.x, making the
Debian provided package ever closer to useless.

Bug#858923: libpam-winbind: Cannot change password via passwd (pam) in default config

[Matthew Gabeler-Lee]

Package: libpam-winbind
Version: 2:4.5.8+dfsg-1
Followup-For: Bug #858923

The common recommendation for how to fix this issue, as long as you don't
have too much else in the way of "interesting" module stacking is to remove
use_authtok from the pam_winbind entry.

But that will get clobbered the next time pam-auth-update gets run AFAICT.

So I thought the next best solution would be to edit
/usr/share/pam-configs/winbind to change the template entry for winbind. 
But that's not a conf file, so it too will get clobbered, this time on
package upgrade.

Making /usr/share/pam-configs/winbind a conffile would at least allow
reasonable sysadmin workarounds.

While others disagree, I'd go so far as to say that removing use_authtok
should be the default, as the simple PAM configs are going to be vastly more
common than the complex stacking ones that might be adversely affected by
that.

Another way around this I guess might be to have a special PAM module that's
not part of the normal stack whose sole purpose is to force the prompt for
the new password to happen, and then make all the "real" modules use
use_authtok, including pam_unix.  That's a more complex and invasive change,
though.

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

Kernel: Linux 4.9.0-2-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: systemd (via /run/systemd/system)

Versions of packages libpam-winbind depends on:
ii  dpkg1.18.23
ii  libbsd0 0.8.3-1
ii  libc6   2.24-10
ii  libpam-runtime  1.1.8-3.5
ii  libpam0g1.1.8-3.5
ii  libtalloc2  2.1.8-1
ii  libwbclient02:4.5.8+dfsg-1
ii  samba-common2:4.5.8+dfsg-1
ii  samba-libs  2:4.5.8+dfsg-1
ii  winbind 2:4.5.8+dfsg-1

libpam-winbind recommends no packages.

Versions of packages libpam-winbind suggests:
ii  libnss-winbind  2:4.5.8+dfsg-1

-- no debconf information

Bug#862100: snort: Email alerts don't work in default config

[Matthew Gabeler-Lee]

Package: snort
Version: 2.9.7.0-5
Severity: important

The default configuration of snort offers to setup an e-mail alert ... 
which will NEVER work in the default configuration, because the alerting
script only seems to work with textual log files, while the default config
only generates the binary unified2 format log file.

Nothing in the debconf prompting for the alert setup even hints that this
might be a problem, leading to a false sense of security by the
administrator installing the package.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.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: systemd (via /run/systemd/system)

Versions of packages snort depends on:
ii  adduser  3.115
ii  debconf [debconf-2.0]1.5.60
ii  libc62.24-10
ii  libdaq2  2.0.4-3+b1
ii  libdumbnet1  1.12-7+b1
ii  liblzma5 5.2.2-1.2+b1
ii  libpcap0.8   1.8.1-3
ii  libpcre3 2:8.39-3
ii  logrotate3.11.0-0.1
ii  net-tools1.60+git20161116.90da8a0-1
ii  rsyslog [system-log-daemon]  8.24.0-1
ii  snort-common 2.9.7.0-5
ii  snort-common-libraries   2.9.7.0-5
ii  snort-rules-default  2.9.7.0-5
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages snort recommends:
ii  iproute2  4.9.0-1

Versions of packages snort suggests:
pn  snort-doc  

-- Configuration Files:
/etc/default/snort changed [not included]

-- debconf information:
* snort/stats_treshold: 1
* snort/send_stats: true
* snort/interface: enp1s0
* snort/please_restart_manually:
* snort/address_range: 172.22.0.0/23
* snort/stats_rcpt: beech...@beechwoods.com
* snort/invalid_interface:
  snort/config_parameters:
* snort/options:
* snort/startup: boot
* snort/disable_promiscuous: false

Bug#861156: tt-rss: Needs new Dojo to render UI properly

[Matthew Gabeler-Lee]

On 04/26/2017 05:23 PM, Matthew Gabeler-Lee wrote:
> On 04/26/2017 02:56 PM, Sebastian Reichel wrote:
>> I can't reproduce this. I tested the release before uploading and everything
>> (incl. feed icons) worked and still works as expected in my installation.
> Hmm, interesting.  Do you have different dojo packages installed vs. my
> report somehow?
>
> Can you check with the DOM inspector tools in your browser to see if you
> have the same img-as-a-child-of-an-img odditiy that I got?
Argh, I figured it out.  Somehow my
/usr/share/tt-rss/www/lib/{dojo,dijit} were not symlinks but a static
copy from $deity knows where.  Probably leftovers from me trying to work
around the last time an upgrade to those libraries was needed.

Replacing those snapshots with proper symlinks fixed things.

Feel free to close this as "user shot self in foot" :)

Bug#861156: tt-rss: Needs new Dojo to render UI properly

[Matthew Gabeler-Lee]

On 04/26/2017 02:56 PM, Sebastian Reichel wrote:
> I can't reproduce this. I tested the release before uploading and everything
> (incl. feed icons) worked and still works as expected in my installation.

Hmm, interesting.  Do you have different dojo packages installed vs. my
report somehow?

Can you check with the DOM inspector tools in your browser to see if you
have the same img-as-a-child-of-an-img odditiy that I got?

I'm seeing my problem in multiple browsers on multiple machines, in
normal and incognito/private modes, chrome guest profiles (so no
addins/extensions), including after flushing caches and cookies.

The feed icon elements are /there/ in the DOM, it's just the browsers
are refusing to render the nested image.

If I use the DOM tree editor in Firefox to hack on the element type of
the outer image, I can get the icon to display.

Bug#861262: sphinxsearch: service restart on upgrades or otherwise always fails

[Matthew Gabeler-Lee]

Package: sphinxsearch
Version: 2.2.11-1.1
Severity: important

Every time something tries to restart sphinxsearch, it fails, leaving the
sphinxsearch service in a failed state and the daemon not running.  This
happens on package upgrades, or restarts for library upgrades, or restarts
for config changes, or anything that tries to restart sphinxsearch.

It looks like the stop request returns before it is actually stopped, which
causes the following start request to fail because the old copy is still
running.

One thing I notice once it's up and running is that the PID in
/var/run/sphinxsearch/searchd.pid is NOT the pid of the top level searchd
process, but rather the PID of its immediate child.  I'm not sure if there's
a "supervisor" process being used here or what.

Example flow:

$ sudo service sphinxsearch restart
Job for sphinxsearch.service failed because the control process exited with 
error code.
See "systemctl status sphinxsearch.service" and "journalctl -xe" for details.

$ sudo service sphinxsearch status
● sphinxsearch.service - LSB: Fast standalone full-text SQL search engine
   Loaded: loaded (/etc/init.d/sphinxsearch; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2017-04-26 11:57:41 EDT; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 25416 ExecStop=/etc/init.d/sphinxsearch stop (code=exited, 
status=0/SUCCESS)
  Process: 25421 ExecStart=/etc/init.d/sphinxsearch start (code=exited, 
status=1/FAILURE)
Tasks: 0 (limit: 4915)
   Memory: 4.7M
  CPU: 9ms
   CGroup: /system.slice/sphinxsearch.service

Apr 26 11:57:41 hostname systemd[1]: Stopping LSB: Fast standalone full-text 
SQL search engine...
Apr 26 11:57:41 hostname sphinxsearch[25416]: Stopping sphinxsearch: 
sphinxsearch.
Apr 26 11:57:41 hostname systemd[1]: Stopped LSB: Fast standalone full-text SQL 
search engine.
Apr 26 11:57:41 hostname systemd[1]: Starting LSB: Fast standalone full-text 
SQL search engine...
Apr 26 11:57:41 hostname sphinxsearch[25421]: Starting sphinxsearch: 
/usr/bin/searchd already running.
Apr 26 11:57:41 hostname systemd[1]: sphinxsearch.service: Control process 
exited, code=exited status=1
Apr 26 11:57:41 hostname systemd[1]: Failed to start LSB: Fast standalone 
full-text SQL search engine.
Apr 26 11:57:41 hostname systemd[1]: sphinxsearch.service: Unit entered failed 
state.
Apr 26 11:57:41 hostname systemd[1]: sphinxsearch.service: Failed with result 
'exit-code'.

$ sudo service sphinxsearch restart

$ sudo service sphinxsearch status
● sphinxsearch.service - LSB: Fast standalone full-text SQL search engine
   Loaded: loaded (/etc/init.d/sphinxsearch; generated; vendor preset: enabled)
   Active: active (running) since Wed 2017-04-26 11:57:55 EDT; 3min 14s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 25416 ExecStop=/etc/init.d/sphinxsearch stop (code=exited, 
status=0/SUCCESS)
  Process: 25443 ExecStart=/etc/init.d/sphinxsearch start (code=exited, 
status=0/SUCCESS)
Tasks: 8 (limit: 4915)
   Memory: 11.4M
  CPU: 225ms
   CGroup: /system.slice/sphinxsearch.service
   ├─25447 /usr/bin/searchd
   └─25448 /usr/bin/searchd

Apr 26 11:57:55 hostname sphinxsearch[25443]: Sphinx 2.2.11-id64-release 
(95ae9a6)
Apr 26 11:57:55 hostname sphinxsearch[25443]: Copyright (c) 2001-2016, Andrew 
Aksyonoff
Apr 26 11:57:55 hostname sphinxsearch[25443]: Copyright (c) 2008-2016, Sphinx 
Technologies Inc (http://sphinxsearch.com)
Apr 26 11:57:55 hostname sphinxsearch[25443]: precaching index 'wiki_main'
Apr 26 11:57:55 hostname sphinxsearch[25443]: [249B blob data]
Apr 26 11:57:55 hostname sphinxsearch[25443]: [250B blob data]
Apr 26 11:57:55 hostname sphinxsearch[25443]: Copyright (c) 2001-2016, Andrew 
Aksyonoff
Apr 26 11:57:55 hostname sphinxsearch[25443]: Copyright (c) 2008-2016, Sphinx 
Technologies Inc (http://sphinxsearch.com)
Apr 26 11:57:55 hostname sphinxsearch[25443]: sphinxsearch.
Apr 26 11:57:55 hostname systemd[1]: Started LSB: Fast standalone full-text SQL 
search engine.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages sphinxsearch depends on:
ii  adduser 3.115
ii  libc6   2.24-9
ii  libexpat1   2.2.0-2
ii  libgcc1 1:6.3.0-14
ii  libmariadbclient18  10.1.22-3
ii  libpq5  9.6.2-2
ii  libstdc++6  6.3.0-14
ii  libstemmer0d0+svn585-1+b2
ii  zlib1g  1:1.2.8.dfsg-5

sphinxsearch recommends no packages.

sphinxsearch suggests no packages.

-- Configuration Files:
/etc/cron.d/sphinxsearch changed [not included]
/etc/default/sphinxsearch changed [not included]

-- no debconf information

Bug#861156: tt-rss: Needs new Dojo to render UI properly

[Matthew Gabeler-Lee]

Package: tt-rss
Version: 17.1+git20170410+dfsg-2
Severity: important

Since updating to the new 17.1 package of tt-rss, some parts of the UI no
longer render correctly.  Immediately noticeable is the feed icons are all
gone, despite the usual "clear cookies, shift-reload" after updates.

Scanning around, I find this thread that indicates upstream expects to have
Dojo 1.12, but Debian / this tt-rss package only has 1.11, so I suspect this
is the crux of the issue.

https://tt-rss.org/oldforum/viewtopic.php?f=10=4024

For reference, with the older Dojo, the immediate problem of feed icons
seems to be placing an  as a child of another , which no browser
will render AFAICT.  I suspect in the newer Dojo, the node it's placing the
image into is no longer another image.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages tt-rss depends on:
ii  dbconfig-common 2.0.8
ii  dbconfig-mysql  2.0.8
ii  debconf [debconf-2.0]   1.5.60
ii  init-system-helpers 1.47
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.16-3
ii  libjs-dojo-core 1.11.0+dfsg-1
ii  libjs-dojo-dijit1.11.0+dfsg-1
ii  libjs-scriptaculous 1.9.0-2
ii  libphp-phpmailer5.2.14+dfsg-2.3
ii  lsb-base9.20161125
ii  php 1:7.0+49
ii  php-mbstring1:7.0+49
ii  php-mysql   1:7.0+49
ii  php-php-gettext 1.0.12-0.1
ii  php-xml 1:7.0+49
ii  php7.0 [php]7.0.16-3
ii  php7.0-cgi [php-cgi]7.0.16-3
ii  php7.0-cli [php-cli]7.0.16-3
ii  php7.0-json [php-json]  7.0.16-3
ii  php7.0-mbstring [php-mbstring]  7.0.16-3
ii  php7.0-pgsql [php-pgsql]7.0.16-3
ii  php7.0-xml [php-xml]7.0.16-3
ii  phpqrcode   1.1.4-2

Versions of packages tt-rss recommends:
ii  apache2 [httpd] 2.4.25-3
ii  ca-certificates 20161130
ii  lighttpd [httpd]1.4.45-1
ii  php-curl1:7.0+49
ii  php-gd  1:7.0+49
ii  php7.0-curl [php-curl]  7.0.16-3
ii  php7.0-gd [php-gd]  7.0.16-3
ii  php7.0-mcrypt [php-mcrypt]  7.0.16-3

Versions of packages tt-rss suggests:
ii  php-apc  4.0.10-1
ii  php5-apcu [php-apc]  4.0.10-1
ii  sphinxsearch 2.2.11-1.1

-- Configuration Files:
/etc/default/tt-rss changed [not included]
/etc/tt-rss/apache.conf changed [not included]
/etc/tt-rss/config.php changed [not included]

-- debconf information excluded

Bug#860827: gnome-disk-image-mounter: Provide GUI option to mount image files read-write

[Matthew Gabeler-Lee]

Package: gnome-disk-utility
Version: 3.22.1-1
Severity: wishlist

gnome-disk-image-mounter provides a command line option to mount image files
read-write, but there's no way to do this in the GUI.

This would be particularly handy for e.g.  a disk image file containing an
encrypted (e.g.  LUKS) filesystem.

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

Kernel: Linux 4.9.0-2-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: systemd (via /run/systemd/system)

Versions of packages gnome-disk-utility depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdvdread4  5.0.3-2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  liblzma5 5.2.2-1.2+b1
ii  libnotify4   0.7.7-1+b1
ii  libpango-1.0-0   1.40.4-1
ii  libpangocairo-1.0-0  1.40.4-1
ii  libpwquality11.3.0-1+b1
ii  libsecret-1-00.18.5-3.1
ii  libsystemd0  232-22
ii  libudisks2-0 2.1.8-1
ii  libx11-6 2:1.6.4-3
ii  udisks2  2.1.8-1

gnome-disk-utility recommends no packages.

gnome-disk-utility suggests no packages.

-- no debconf information

Bug#860569: linux-image-4.9.0-2-amd64: Please enable CONFIG_LEDS_GPIO on amd64 too

[Matthew Gabeler-Lee]

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

This is basically a reahsh of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734204

That one enabled the relevant modules only on 32 bit kernels, but missed
amd64 kernes.  The current PCEngines hardware is all 64 bit processors, and
I'm sure they're not alone, so it makes sense to at least have the base
infrastructure (LEDS_GPIOS for one) enabled as modules so that per-platform
drivers can be built -- e.g.  lede-project.org has what looks like a nice
driver for the APU2 that could be built out-of-tree reasonably easily ... 
if the common modules were available in the baseline Debian kernel config.

-- Package-specific info:
** Version:
Linux version 4.9.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170321 (Debian 6.3.0-11) ) #1 SMP Debian 4.9.18-1 (2017-03-30)

Bug#860066: ltrace: Doesn't work on some binaries

[Matthew Gabeler-Lee]

Package: ltrace
Version: 0.7.3-6+b1
Severity: normal

ltrace -f ls: crapton of output
ltrace -f irw: nothing

(irw from current testing version of lirc)

I've not found the correlation between apps that work and apps that don't. 
I see an old bug about PIE executables, but that was listed as fixed?  None
of the apps from the lirc package work.

Most apps work.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages ltrace depends on:
ii  libc62.24-9
ii  libelf1  0.168-0.2
ii  libselinux1  2.6-3+b1

ltrace recommends no packages.

ltrace suggests no packages.

-- no debconf information

Bug#860065: lirc: Ignores remote configs included with absolute paths

[Matthew Gabeler-Lee]

Package: lirc
Version: 0.9.4c-9
Severity: normal

If you put a line like this in lircd.conf or one of the files it includes:

include "/absolute/path/to/remote.conf"

It will be ignored.  The problem seems to be bad interaction between these
two snippets of code in lib/config_file.c:

~ line 906 (read_all_included):
lirc_parse_relative(buff, sizeof(buff), val, name);
glob(buff, 0, NULL, );
~ line 791 (lirc_parse_relative)
if (*child == '/')
return child;

The caller doesn't actually use the return value of lirc_parse_relative, it
assumes buff will be filled ...  but it's not.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages lirc depends on:
ii  init-system-helpers  1.47
ii  libasound2   1.1.3-5
ii  libc62.24-9
ii  libftdi1-2   1.3-2+b2
ii  libgcc1  1:6.3.0-11
ii  liblirc-client0  0.9.4c-9
ii  liblirc0 0.9.4c-9
ii  libportaudio219.6.0-1
ii  libstdc++6   6.3.0-11
ii  libsystemd0  232-22
ii  libudev1 232-22
ii  libusb-0.1-4 2:0.1.12-30
ii  libusb-1.0-0 2:1.0.21-1
ii  lsb-base 9.20161125
ii  python3  3.5.3-1

Versions of packages lirc recommends:
pn  gir1.2-vte
ii  python3-gi3.22.0-2
pn  python3-yaml  

Versions of packages lirc suggests:
pn  ir-keytable  
ii  lirc-compat-remotes  0.9.0-1
pn  lirc-doc 
pn  lirc-drv-irman   
ii  lirc-x   0.9.4c-9
ii  setserial2.17-50

-- Configuration Files:
/etc/lirc/hardware.conf changed [not included]
/etc/lirc/lircd.conf changed [not included]
/etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] No such file or directory: 
'/etc/lirc/lircd.conf.d/devinput.lircd.conf'

-- debconf information excluded

Bug#860039: liblirc-dev pkg-config does not provide proper include paths

[Matthew Gabeler-Lee]

Package: liblirc-dev
Version: 0.9.4c-9
Severity: normal

Trying to build an LIRC plugin using liblirc-dev doesn't work, because the 
installed pkg-config file does not provide proper include flags for the cflags 
output:

$ make
cc -I../usb_ir -fpic -DPLUGINDOCS=\"/usr/share/doc/lirc/plugindocs\"   -c -o 
iguanair.o iguanair.c
In file included from /usr/include/lirc/ir_remote_types.h:52:0,
 from /usr/include/lirc_driver.h:21,
 from iguanair.c:31:
/usr/include/lirc/include/media/lirc.h:9:20: fatal error: config.h: No such 
file or directory
 #include 
^
compilation terminated.
: recipe for target 'iguanair.o' failed
make: *** [iguanair.o] Error 1
$ pkg-config --cflags lirc-driver
-fpic -DPLUGINDOCS=\"/usr/share/doc/lirc/plugindocs\"
$ ls /usr/include/lirc/config.h
/usr/include/lirc/config.h

It looks like it needs to export "-I/usr/include/lirc"

Which is strange because ... it also looks like it already does?

Cflags: -I${includedir} -fpic -DPLUGINDOCS='"${docdir}/plugindocs"'

Aaah, it seems that includedir is just set to /usr/include, but it needs to 
also give /usr/include/lirc

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

Kernel: Linux 4.9.0-2-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: systemd (via /run/systemd/system)

Versions of packages liblirc-dev depends on:
ii  liblirc-client0  0.9.4c-9
ii  liblirc0 0.9.4c-9
ii  lsb-base 9.20161125

liblirc-dev recommends no packages.

liblirc-dev suggests no packages.

-- no debconf information

Bug#859733: snort: Please provide snort-dev package for compiling so_rules

[Matthew Gabeler-Lee]

Source: snort
Version: 2.9.7.0-5
Severity: wishlist

Currently, if you install snort from debian, you can't compile so rules from
sources, because the header files needed to do so (e.g. 
sf_snort_plugin_api.h) are not distributed as part of any of the Debian
packages.

Having a snort-dev package that contains all the headers/etc.  needed for
compiling so_rules would be useful.

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

Kernel: Linux 4.9.0-2-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: systemd (via /run/systemd/system)

Bug#859141: tigervnc-standalone-server: Wrapper script is unreasonably intolerant of slightly slow or busy systems

[Matthew Gabeler-Lee]

Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-6
Severity: normal

The /usr/bin/tigervncserver wrapper script gives up and kills the server it
just started if it doesn't have its VNC-TCP and X11-unix sockets up and
running within one second.

If a machine is a bit bogged down, this can prevent starting the server at
all, for no good reason.

It seems like 10-60 seconds would be a much more reasonable timeout here.

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

Kernel: Linux 4.9.0-2-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: systemd (via /run/systemd/system)

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1 1:2.6.7-1
ii  libc6 2.24-9
ii  libgcc1   1:6.3.0-10
ii  libgcrypt20   1.7.6-1
ii  libgl1-mesa-glx [libgl1]  13.0.5-1
ii  libgnutls30   3.5.8-3
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpam0g  1.1.8-3.5
ii  libpixman-1-0 0.34.0-1
ii  libselinux1   2.6-3+b1
ii  libstdc++66.3.0-10
ii  libsystemd0   232-19
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.2-3
ii  libxfont2 1:2.0.1-3
ii  libxshmfence1 1.2-1+b2
pn  perl:any  
ii  x11-xkb-utils 7.7+3+b1
ii  xauth 1:1.0.9-1+b2
ii  xkb-data  2.19-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri13.0.5-1
pn  tigervnc-common
ii  x11-xserver-utils  7.7+7+b1
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1
ii  xfonts-75dpi 1:1.0.4+nmu1
ii  xfonts-scalable  1:1.0.3-1.1

-- no debconf information

Bug#858923: libpam-winbind: Cannot change password via passwd (pam) in default config

[Matthew Gabeler-Lee]

Package: libpam-winbind
Version: 2:4.5.6+dfsg-1
Severity: normal

Domain-only users cannot change their password in the default configuration.

Ubuntu has a bug for this with a workaround, though the workaround has its
own issues:

https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944

It appears there is a problem with having use_authtok in the winbind line
for the password pam service.  However, there are other issues in some
configurations with removing that option.

I've tried the workaround suggested there: removing use_authtok from the
winbind entry in /etc/pam.d/common-password, and it worked for me -- my
environment doesn't have the concerns with removing that item that may apply
to others.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages libpam-winbind depends on:
ii  dpkg1.18.23
ii  libbsd0 0.8.3-1
ii  libc6   2.24-9
ii  libpam-runtime  1.1.8-3.5
ii  libpam0g1.1.8-3.5
ii  libtalloc2  2.1.8-1
ii  libwbclient02:4.5.6+dfsg-1
ii  samba-common2:4.5.6+dfsg-1
ii  samba-libs  2:4.5.6+dfsg-1
ii  winbind 2:4.5.6+dfsg-1

libpam-winbind recommends no packages.

Versions of packages libpam-winbind suggests:
ii  libnss-winbind  2:4.5.6+dfsg-1

-- no debconf information

Bug#858759: pepperflashplugin-nonfree: Option --quiet is broken

[Matthew Gabeler-Lee]

Package: pepperflashplugin-nonfree
Version: 1.8.3+nmu1
Severity: normal

Can't pass --quiet arg any more:

$ sudo /usr/sbin/update-pepperflashplugin-nonfree --install --quiet
Can't be verbose and quiet at the same time.
Usage: wget [OPTION]... [URL]...

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now


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

Kernel: Linux 4.9.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.27.90.20170124-2
ii  ca-certificates20161130
ii  debconf [debconf-2.0]  1.5.60
ii  gnupg  2.1.18-6
ii  libatk1.0-02.22.0-1
ii  libcairo2  1.14.8-1
ii  libcurl3-gnutls7.52.1-3
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3+b2
ii  libgcc11:6.3.0-6
ii  libglib2.0-0   2.50.3-1
ii  libgtk2.0-02.24.31-2
ii  libnspr4   2:4.12-6
ii  libnss32:3.26.2-1
ii  libpango-1.0-0 1.40.4-1
ii  libpango1.0-0  1.40.4-1
ii  libstdc++6 6.3.0-6
ii  libx11-6   2:1.6.4-3
ii  libxext6   2:1.3.3-1+b2
ii  libxt6 1:1.1.5-1
ii  wget   1.18-5

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
pn  chromium   
pn  hal
pn  ttf-dejavu 
ii  ttf-mscorefonts-installer  3.6
ii  ttf-xfree86-nonfree4.2.1-5

-- no debconf information

Bug#827593: new upstream (2.9.8.3)

[Matthew Gabeler-Lee]

Source: snort
Version: 2.9.7.0-5
Followup-For: Bug #827593

Further, I would note that upstream has now officially End of Life'd 2.9.7.x

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

Kernel: Linux 4.9.0-2-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: systemd (via /run/systemd/system)

Bug#837788: munin: systemd control scripts are missing

[Matthew Gabeler-Lee]

On Fri, 10 Mar 2017, Simon McVittie wrote:


However, Matthew Gabeler-Lee's reply:


I argue this merits worse than "important" -- in a default install of
Stretch currently, munin doesn't work at all.


suggests that there may be something else going on.

Matthew, please could you describe what you did (before applying any
workarounds), what you expected to happen, and what actually happened,
including any syslog, Journal or web server log messages that look
potentially relevant?


On closer inspection, I think I need to retract my prior statement.

I had a problem with munin "not working at all" -- i.e. not collecting 
data / updating charts, which correlated with an upgrade of the munin 
package.


But on closer inspection, I realize two things happened that day, and it 
was actually the other thing that "broke" munin, and it was a mistake 
interpreting the munin status pages that made me thing the sysvinit 
workaround "fixed" it.  The sysvinit hack "fixing" things was a false 
positive, and it was really fixing the other problem (a network issue 
preventing data collection from most nodes) that made munin start 
working for me.


I think the suggestion that this in fact is not a bug and is just a 
confusion with how munin works is correct.


It is in fact /etc/cron.d/munin that does the "service" work of munin.

Apologies for the confusion!

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#837788: munin: systemd control scripts are missing

[Matthew Gabeler-Lee]

Package: munin
Version: 2.0.33-1
Followup-For: Bug #837788

I argue this merits worse than "important" -- in a default install of
Stretch currently, munin doesn't work at all.

Also worthy of note is this workaround:
sudo rm /lib/systemd/system/munin.service
sudo systemctl enable munin
sudo systemctl start munin

This takes it back to using the sysvinit script with systemd.  I don't know
if this might cause difficulties with future upgrades, but it at least gets
munin running again for me.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages munin depends on:
ii  cron [cron-daemon]3.0pl1-128+b1
ii  fonts-dejavu-core 2.37-1
ii  libdate-manip-perl6.57-1
pn  libdigest-md5-perl
ii  libfile-copy-recursive-perl   0.38-1
ii  libhtml-template-perl 2.95-2
ii  libio-socket-inet6-perl   2.72-2
ii  liblog-log4perl-perl  1.48-1
ii  libperl5.24 [libtime-hires-perl]  5.24.1-1
ii  librrds-perl  1.6.0-1+b2
pn  libstorable-perl  
ii  liburi-perl   1.71-1
ii  lsb-base  9.20161125
ii  munin-common  2.0.33-1
ii  perl  5.24.1-1
ii  rrdtool   1.6.0-1+b2

Versions of packages munin recommends:
ii  libcgi-fast-perl  1:2.12-1
pn  munin-doc 
ii  munin-node2.0.33-1

Versions of packages munin suggests:
ii  apache2 [httpd]   2.4.25-3
ii  libapache2-mod-fcgid  1:2.3.9-1+b1
ii  libnet-ssleay-perl1.80-1
ii  lynx [www-browser]2.8.9dev11-1
ii  w3m [www-browser] 0.5.3-34

-- Configuration Files:
/etc/cron.d/munin changed [not included]
/etc/munin/apache.conf changed [not included]
/etc/munin/apache24.conf changed [not included]
/etc/munin/munin.conf changed [not included]

-- no debconf information

Bug#856311: avahi-daemon: Won't start due to rlimit nproc, confused by lxc containers

[Matthew Gabeler-Lee]

Package: avahi-daemon
Version: 0.6.32-2
Severity: normal

On one of my systems, avahi-daemon can't start due to its default rlimit-nproc 
value of 3.

In my case this seems to be because an lxc container running on this host is
using the same uid for avahi as the host system, but for a different
function.  Even if it was using it for the same function, the rlimit-nproc
is enforcing in the wrong scope it seems.

Feb 27 10:28:34 hostname avahi-daemon[23274]: Found user 'avahi' (UID 104) and 
group 'avahi' (GID 110).
Feb 27 10:28:34 hostname avahi-daemon[23274]: Successfully dropped root 
privileges.
Feb 27 10:28:34 hostname avahi-daemon[23274]: chroot.c: fork() failed: Resource 
temporarily unavailable
Feb 27 10:28:34 hostname avahi-daemon[23274]: failed to start chroot() helper 
daemon.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages avahi-daemon depends on:
ii  adduser  3.115
ii  bind9-host [host]1:9.10.3.dfsg.P4-12
ii  dbus 1.10.16-1
ii  host 1:9.10.3.dfsg.P4-12
ii  init-system-helpers  1.47
ii  libavahi-common3 0.6.32-2
ii  libavahi-core7   0.6.32-2
ii  libc62.24-9
ii  libcap2  1:2.25-1
ii  libdaemon0   0.14-6
ii  libdbus-1-3  1.10.16-1
ii  libexpat12.2.0-2
ii  lsb-base 9.20161125

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-8

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#855969: gitolite3: Please package ukm tool from contrib

[Matthew Gabeler-Lee]

Package: gitolite3
Version: 3.6.1-2+deb8u1
Severity: wishlist

The upstream gitolite source includes a very useful "contrib" tool 'ukm' to
help with key management.  It would be nice if the Debian package included
this tool in some fashion.

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

Kernel: Linux 4.9.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: systemd (via /run/systemd/system)

Bug#854021: fwbuilder: Consider following fork / new upstream https://github.com/fwbuilder/

[Matthew Gabeler-Lee]

Package: fwbuilder
Version: 5.1.0-4+b2
Severity: wishlist

There seems to be a new upstream, or at least an actively maintained fork:
https://github.com/fwbuilder/fwbuilder, while the existing upstream has not
shown any signs of life for several years.

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

Kernel: Linux 4.9.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: systemd (via /run/systemd/system)

Versions of packages fwbuilder depends on:
ii  fwbuilder-common  5.1.0-4
ii  libc6 2.24-8
ii  libgcc1   1:6.3.0-5
ii  libqt4-network4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libsnmp30 5.7.3+dfsg-1.7
ii  libssl1.0.2   1.0.2j-5
ii  libstdc++66.3.0-5
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxslt1.11.1.29-2
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages fwbuilder recommends:
ii  fwbuilder-doc  5.1.0-4
pn  rcs

fwbuilder suggests no packages.

-- no debconf information

Bug#851813: lighttpd-mod-webdav: WebDAV crashes constantly when accessed from Windows client (unusable)

[Matthew Gabeler-Lee]

Package: lighttpd-mod-webdav
Version: 1.4.44-1
Severity: important

I'm trying to setup a webdav share for windows (10) clients to access.

One of the basic commands they send causes lighttpd to segfault with a
"double free or corruption" error in syslog.  Constantly.  It's barely
possible to get Windows to "mount" the webdav location, and totally
impossible to copy a file into it.

The only commands the Windows client gets to issue before it crashes are
PROPFIND and LOCK, so it's one of those two triggering the error.  Given the
propensity of the file copy to trigger the crash, I suspect it is the LOCK
call.

The stack trace logged along with the segfault is:

=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7fb1d6d57bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7fb1d6d5dfa6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7fb1d6d5e79e]
/usr/lib/lighttpd/mod_webdav.so(+0x257c)[0x7fb1d4bd957c]
/usr/sbin/lighttpd(plugins_call_connection_reset+0x56)[0x560858e464f6]
/usr/sbin/lighttpd(connection_reset+0x11)[0x560858e31e71]
/usr/sbin/lighttpd(connection_state_machine+0x6e6)[0x560858e32d46]
/usr/sbin/lighttpd(main+0x172d)[0x560858e2e1ed]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb1d6d072b1]
/usr/sbin/lighttpd(_start+0x2a)[0x560858e2f13a]

This is 100% reproducible across multiple systems for me :(

Note: I had the testing release installed when reporting this bug, but I did
test it with the sid release and it fails in the same way.

Note 2: I also tried the same basic configuration using the stable (jessie)
version of lighttpd, and it does not crash, but it also doesn't work with
the Windows clients due to missing support for some arguments Windows sends
in the LOCK command.

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

Kernel: Linux 4.8.0-2-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: systemd (via /run/systemd/system)

Versions of packages lighttpd-mod-webdav depends on:
ii  libc6 2.24-8
ii  libsqlite3-0  3.15.2-2
ii  libuuid1  2.29-1
ii  libxml2   2.9.4+dfsg1-2.1
ii  lighttpd  1.4.43+git20161216-1

lighttpd-mod-webdav recommends no packages.

lighttpd-mod-webdav suggests no packages.

-- no debconf information

Bug#850180: mdadm: systemd units do not obey /etc/default/mdadm, esp DAEMON_OPTIONS=--syslog

[Matthew Gabeler-Lee]

Package: mdadm
Version: 3.4-4
Severity: normal

I had some recent array events, notified by email (worked), and was trying
to look up when the recovery finished in syslog, only to discover that the
mdadm array monitor is not logging to syslog.  This seems to be because the
systemd unit and/or initramfs support (not sure which) that started the
monitor daemon does not obey (or even look at?) /etc/default/mdadm, where I
have:

DAEMON_OPTIONS="--syslog"

I think this is even the default.

Whereas mdmonitor.service has only:


[Unit]
Description=MD array monitor
DefaultDependencies=no

[Service]
ExecStart=/sbin/mdadm --monitor --scan



-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST cheetah.fastcat.org
MAILADDR root
ARRAY 

--- /etc/default/mdadm
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

Auto-generated on Wed, 04 Jan 2017 13:31:06 -0500 by mdadm bugscript

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  lsb-base   9.20161125
ii  udev   232-8

Versions of packages mdadm recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-2
ii  kmod   23-1

mdadm suggests no packages.

-- Configuration Files:
/etc/cron.daily/mdadm changed [not included]

-- debconf information:
  mdadm/initrdstart_notinconf: false
* mdadm/start_daemon: true
* mdadm/mail_to: root
  mdadm/initrdstart_msg_errexist:
* mdadm/autocheck: true
* mdadm/autostart: true
  mdadm/initrdstart_msg_errconf:
  mdadm/initrdstart_msg_errmd:
* mdadm/warning:
* mdadm/initrdstart: all
  mdadm/initrdstart_msg_intro:
  mdadm/initrdstart_msg_errblock:

Bug#849806: mdadm: Administrator should be warned about the dangers of HOMEHOST

[Matthew Gabeler-Lee]

On Tue, 3 Jan 2017, Dimitri John Ledkov wrote:


On 31 December 2016 at 09:48, Matthew Gabeler-Lee <chee...@fastcat.org> wrote:

Snazzy would be to bake the system hostname into the initramfs (Ubuntu seems
to do this as part of the baseline initramfs-tools, but Debian not so much)
so that this problem largely went away.



Ouch. Imho hostname should be copied into initramfs. But I do not know
the history of where this change was done in Ubuntu and/or why not
done in Debian.
I am not sure if it is appropriate for mdadm package initramfs hooks
to copy /etc/hostname into initramfs. Maybe it should be done
somewhere more universal, e.g. initramfs-tools itself.


Agreed that it shouldn't be mdadm's responsibility to bake the hostname 
into the initramfs.


And that doesn't cover systems with dynamic hostnames -- Those really 
shouldn't be trying to use a DNS name for the homehost at all.  There's 
an argument for an enhancement to use the systemd/dbus machine guid 
instead of hostnames here, though that comes with its own 
complexities...


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#849564: python3-reportbug: reportbug fails with AttributeError: 'str' object has no attribute 'utils'

[Matthew Gabeler-Lee]

Package: reportbug
Version: 7.1.1
Followup-For: Bug #849564

This bug seems like it maybe should be higher severity than 'normal'.  On
systems that have 7.1.1 installed, I can't seem to run reportbug no matter
what I do.  It seems from scanning the problem python code that I would need
to not have a realname associated with the sending account at all.

Since I'm assuming the package didn't go out the door not working at all for
everyone ... is there a trick to getting past this problem other than
downgrading reportbug?  I tried moving aside my .reportbugrc and clearing
any environment variables that provide a realname, but it seems I would have
to also empty the GECOS field for my account in /etc/passwd to get around
this?

NB: I've only tried the text UI, not sure if this maybe doesn't affect the
GTK UI in the same way?

-- Package-specific info:
** /home/cheetah/.reportbugrc:
reportbug_version "6.3.1"
mode advanced

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

Kernel: Linux 4.8.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: systemd (via /run/systemd/system)

Versions of packages python-reportbug depends on:
ii  apt   1.4~beta2
ii  file  1:5.29-1
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

Bug#849806: mdadm: Administrator should be warned about the dangers of HOMEHOST

[Matthew Gabeler-Lee]

Package: mdadm
Version: 3.4-4
Severity: normal

I've found, the hard way, that having "HOMEHOST " in mdadm.conf is
... not really safe, unless you list ALL arrays in mdadm.conf.  That of
course means that the arrays are all always present.

In my case, I have arrays that are present in external (read:
semi-removable) storage, so listing them explicitly in mdadm.conf would
cause frequent spurious boot failures -- these arrays are in no way needed
to boot the system.  I rely on udev incremental assembly to bring up these
arrays when they come online, and this works fine for me.

In this scenario, though, HOMEHOST  is a bad setting, because if
these arrays ARE present at boot, then they are assembled as foreign arrays
... beacuse the system hostname isn't set yet!  Which means they have the
"wrong" name in /dev/md/ and things go badly.

It seems to me that the administrator should be warned about this in some
way.  Fancy would be to warn if this config setting is in use and there are
arrays present which are not defined in mdadm.conf (NB: the existing logic
for detecting this is ... weak, it is trivially confused by comments for
example).  Less fancy but still useful would be to document this limitation
in mdadm.conf(5).

Snazzy would be to bake the system hostname into the initramfs (Ubuntu seems
to do this as part of the baseline initramfs-tools, but Debian not so much)
so that this problem largely went away.

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

Kernel: Linux 4.8.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: systemd (via /run/systemd/system)

Versions of packages mdadm depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  lsb-base   9.20161125
ii  udev   232-7

Versions of packages mdadm recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-1
ii  kmod   23-1

mdadm suggests no packages.

-- debconf information excluded

Bug#841401: chromium: doesn't update extensions

[Matthew Gabeler-Lee]

Package: chromium
Version: 55.0.2883.75-2
Followup-For: Bug #841401

Disabling extension updates seems like a pretty horrible decision,
especially without informing the user.

If you're going to do this, then you should remove the ability to INSTALL
extensions in the first place.

Now I can't update extensions without uninstalling them, which erases their
settings generally.  If an extension is broken due to server side changes,
I'm screwed.  If an extension has a security issue that has been fixed, I'm
screwed.  If I want bug fixes or new features, I'm screwed.

None of the other browsers package for Debian have such a patch applied, why
is chromium "special"?


If someone is this hyper-paranoid, why are they running a browser like
Chrom(e/ium) in the first place?  It is /full/ of phone home features and
the like.  Turning off extension auto updating seems like shooting yourself
in the foot because the horse has already left the barn and crossed several
state lines.


But seriously, this is a huge PITA, and a potential security problem IMO.

Bug#846536: python-certbot: Not installable in jessie backports

[Matthew Gabeler-Lee]

On Fri, 2 Dec 2016, Ondřej Surý wrote:


have you tried using apt-get install -t jessie-backports python-certbot ?


Dur, that worked ... I was thinking that enabling backports that would 
sort of be the default behavior, but of course it's not.


Thanks / sorry for wasting time

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#846536: python-certbot: Not installable in jessie backports

[Matthew Gabeler-Lee]

Package: python-certbot
Version: 0.9.3-1~bpo8+1
Severity: normal

Trying to install python-certbot (really letsencrypt), running into two
dependency issues, one with python-certbot itself and the other with an
indirect dependency python-acme has.

p-c depends on a newer version of python-cryptography than is available, and
depends on python-acme which depends on a newer version of python-openssl
than is available.

$ sudo apt install python-certbot python-acme
Reading package lists... Done
Building dependency tree
Reading state information... Done
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:
 python-acme : Depends: python-openssl (>= 0.15) but 0.14-1 is to be installed
   Depends: python-cryptography (>= 0.8) but 0.6.1-1 is to be 
installed
   Depends: python-setuptools (>= 11.3~) but 5.5.1-1 is to be 
installed
   Recommends: python-dnspython but it is not going to be installed
 python-certbot : Depends: python-cryptography (>= 0.7) but 0.6.1-1 is to be 
installed
  Recommends: letsencrypt
  Recommends: python-psutil (>= 2.2.1) but it is not going to 
be installed
E: Unable to correct problems, you have held broken packages.

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

Kernel: Linux 4.8.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: systemd (via /run/systemd/system)

Bug#844783: wmaker: wmmenugen crashes rampantly

[Matthew Gabeler-Lee]

Package: wmaker
Version: 0.95.7-6+b1
Severity: normal

Trying to use wmmenugen to import the xdg desktop files doesn't work because
wmmenugen segfaults like there's no tomorrow ;)

This months old mailing list post looks like a likely fix:

https://www.mail-archive.com/wmaker-dev@lists.windowmaker.org/msg06734.html

Doesn't seem to be fixed upstream, however (current head):

http://repo.or.cz/wmaker-crm.git/blob/0a009143c32064d47dc857ec50e95116b7c5b6be:/util/wmmenugen.c#l109


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages wmaker depends on:
ii  libc62.24-5
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgif7  5.1.4-0.4
ii  libjpeg62-turbo  1:1.5.1-2
ii  libpng16-16  1.6.26-1
ii  libtiff5 4.0.6-3
ii  libwings30.95.7-6+b1
ii  libwraster5  0.95.7-6+b1
ii  libwutil50.95.7-6+b1
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxinerama1 2:1.1.3-1+b1
ii  libxpm4  1:3.5.11-1+b1
ii  wmaker-common0.95.7-6

wmaker recommends no packages.

Versions of packages wmaker suggests:
ii  desktop-base8.0.2
ii  lxterminal [x-terminal-emulator]0.2.0-1
ii  menu2.1.47
ii  rxvt-unicode [x-terminal-emulator]  9.22-1+b1
ii  wmaker-data 0.9~3-4
pn  wmaker-utils
ii  x11-apps7.7+6
ii  xterm [x-terminal-emulator] 327-1

-- no debconf information

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[Matthew Gabeler-Lee]

fixed 842952 50.0-1
thanks

On 11/03/2016 10:24 AM, Sylvestre Ledru wrote:
> In the future, please report a bug per issue and create a meta bug to
> keep track of them.
>
> It makes the life of the maintainer harder. 

Sorry for that.

Having just installed 50.0-1, both the annoyances I mentioned seem to be
fixed.  The addressbar issue may have been fixed by another package
upgrade in between, I'm not sure.  The black bars issue was definitely
fixed just by installing the new version of firefox.

The widget size issue that ano...@users.sourceforge.net reported is
still present, but as you note that shouldn't be lumped into this, and
it doesn't bother me too much, so I'm marking this fixed ... assuming my
noob interaction with the control address doesn't go wrong ;)

Bug#836324: tightvncserver: Typing gives wrong keys in some apps

[Matthew Gabeler-Lee]

On Sat, 3 Sep 2016, Ola Lundqvist wrote:


Also interesting that the problem goes away with vnc4server.


I just came across tigervnc which has the tight protocol support and 
does not suffer from this bug.


The tigervnc website says it's based on the newer vnc4 branch of 
tightvnc that never got released, so this may be a bugfix in vnc4 that 
was not in the older tightvnc 1.3 code.



What client software do you use?


I tried many, including vinagre, remmina, and the uber-basic vncviewer, 
all had exactly the same problem.




FWIW, since tigervnc does everything (for me) that tightvnc did, and 
doesn't have this bug, switching to that package functions as a "fix" 
for this for me, and I'm no longer concerned about tightvnc, esp. since 
it seems to be effectively unmaintained upstream, at least for open 
source linux packaging.


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#843198: gcc-6: Cross-compiles older GCC badly

[Matthew Gabeler-Lee]

Correction: I hadn't smacked the cross-compiler build process hard
enough to get -fno-pie -no-pie into all its compile steps.  Once I hit
it with a bigger stick, that did function as a workaround for this issue
for me, albeit an ugly one.

Bug#843198: gcc-6: Cross-compiles older GCC badly

[Matthew Gabeler-Lee]

Package: gcc-6
Version: 6.2.0-11
Severity: normal

I'm working on a project that uses a Linaro gcc 4.8.3 cross compiler for
ARM, which I'm building on my Debian desktop.

As of gcc-6 6.2.0-6, this worked fine.

As of gcc-6 6.2.0-10, a subtly bad cross-compiler seems to be generated.  My
build is failing in an area related to precompiled headers:

cc1: warning: /path/to/foo.h.gch: had text segment at different address 
[enabled by default]
cc1: error: one or more PCH files were found, but they were invalid
cc1: fatal error: /path/to/foo.h: No such file or directory

I confirmed that if I downgrade all the binary packages I have installed
from the gcc-6 source to 6.2.0-6 and rebuild, things work again.

Scanning the changelogs, I came upon the idea that the default enabling of
-fPIE/-pie in 6.2.0-7 might have something to do with this, so I switched to
that version and tried again, and it failed, so at the very least the
problem is something that came in between the -6 and -7 releases.

Rebuilding the cross-toolchain with -fno-PIE -no-pie produced linker errors
complaining that it needed -fPIC, and rebuilding with -fno-PIE -no-pie -fPIC
produced the same errors, so I don't know what to do now :(

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, '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: systemd (via /run/systemd/system)

Versions of packages gcc-6 depends on:
ii  binutils  2.27.51.20161102-1
ii  cpp-6 6.2.0-6
ii  gcc-6-base6.2.0-6
ii  libc6 2.24-5
ii  libcc1-0  6.2.0-6
ii  libgcc-6-dev  6.2.0-6
ii  libgcc1   1:6.2.0-6
ii  libgmp10  2:6.1.1+dfsg-1
ii  libisl15  0.17.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.5-1
ii  libstdc++66.2.0-6
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-5

Versions of packages gcc-6 suggests:
ii  gcc-6-doc 6.1.0-1
pn  gcc-6-locales 
pn  gcc-6-multilib
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[Matthew Gabeler-Lee]

On Wed, 2 Nov 2016, Jeff King wrote:


On Wed, Nov 02, 2016 at 11:00:34AM -0400, Matthew Gabeler-Lee wrote:


Some things I've noticed going from 49.0-4 to 49.0-5 that I'm inferring are
related to turning on GTK+3:


One thing I've noticed that you didn't mention: on my hi-dpi display the
widget fonts are tiny after the move to GTK+3 (e.g., address bar, tab
titles, anything not rendered HTML).


I do run GNOME, and it works fine on my HiDPI screen there.

Do you have some value set for layout.css.devPixelsPerPx, or is it the 
default -1?



I don't run GNOME, but I do have "dconf" installed. Tweaking
"/org/gnome/desktop/interface/scaling-factor" (and text-scaling-factor)
has no effect.


In my GNOME environment, the first is 0 and the second is 1, and yet I 
get proper sized stuff in HiDPI nonetheless.


However, the gnome-tweak-tool shows the "Window scaling" as 2.

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#833741: pepperflashplugin-nonfree: Feature request?: Download from Adobe instead of Google.

[Matthew Gabeler-Lee]

Package: pepperflashplugin-nonfree
Followup-For: Bug #833741

This is a grave issue for existing installations as well, as it is thus
impossible to upgrade them away from the releases that have critical
security vulnerabilities actively being exploited in the wild.

Bug#842952: firefox: Things that are still bad with GTK+3 enabled

[Matthew Gabeler-Lee]

Package: firefox
Version: 49.0-5
Severity: normal

Some things I've noticed going from 49.0-4 to 49.0-5 that I'm inferring are
related to turning on GTK+3:

1) Parts of the UI have gained ugly heavy black borders.  This seems to be
fixed upstream for a future release:
https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1266914

2) The address bar is intermittently non-functional: I can type in it, but
hitting enter or the "go" button does nothing.  I did some searching to see
if this was a known issue, but mostly only found old / windows-specific
issues.  Workaround: press ESC to clear the address bar and start over.

Also, not related to the GTK+3, but the symbolic icon is terrible IMO:
Instead of a recognizable colorful icon, I instead get an unrecognizable
circle half the size of any of the other app icons that show in the top bar
in Gnome.  I guess if the symbolic icon was properly sized it would be
better, but having it render so much smaller makes it just a generic round
blob with nothing discernably "firefox" about it.  For example, the symbolic
icon for gnome-terminal is square-ish, and taller/wider than the height of
the capital "T".  The firefox symbolic icon however is smaller than the
capital "F", and only marginally larger than the lower-case "o".

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: All-in-One Gestures
Location: ${PROFILE_EXTENSIONS}/{8b86149f-01fb-4842-9dd8-4d7eb02fd055}
Status: enabled

Name: bug489729(Disable detach and tear off tab)
Location: ${PROFILE_EXTENSIONS}/bug489729@alice0775
Status: enabled

Name: Cookie Monster
Location: ${PROFILE_EXTENSIONS}/{45d8ff86-d909-11db-9705-005056c8}
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: dtv jira tweaks userstyle
Status: enabled

Name: Element Hiding Helper for Adblock Plus
Location: ${PROFILE_EXTENSIONS}/elemhidehel...@adblockplus.org.xpi
Status: enabled

Name: Google Privacy
Location: ${PROFILE_EXTENSIONS}/{ea61041c-1e22-4400-99a0-aea461e69d04}.xpi
Status: enabled

Name: Hide right hand pane in Gmail userstyle
Status: enabled

Name: Hide Tab Bar With One Tab
Location: ${PROFILE_EXTENSIONS}/{e5bbc237-c99b-4ced-a061-0be27703295f}.xpi
Status: enabled

Name: HTTP/2 and SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: Linkification
Location: ${PROFILE_EXTENSIONS}/{35106bca-6c78-48c7-ac28-56df30b51d2a}.xpi
Status: enabled

Name: Mailvelope
Location: ${PROFILE_EXTENSIONS}/jid1-aqqsmbyb0a8...@jetpack.xpi
Status: enabled

Name: Master Password+
Location: ${PROFILE_EXTENSIONS}/masterpasswordtimeoutplus@vano
Status: enabled

Name: meta-q-override
Location: ${PROFILE_EXTENSIONS}/jid1-7osji9sxtay...@jetpack.xpi
Status: enabled

Name: msdn tweaks userstyle
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: No Native Notifications
Location: ${PROFILE_EXTENSIONS}/nnnotif...@robwu.nl.xpi
Status: enabled

Name: PasswordMaker
Location: ${PROFILE_EXTENSIONS}/{5872365e-67d1-4afd-9480-fd293bebd20d}.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Referrer Control
Location: ${PROFILE_EXTENSIONS}/referrercont...@qixinglu.com.xpi
Status: enabled

Name: ReloadEvery
Location: ${PROFILE_EXTENSIONS}/{888d99e7-e8b5-46a3-851e-1ec45da1e644}.xpi
Status: enabled

Name: RightBar
Location: ${PROFILE_EXTENSIONS}/right...@realmtech.net.xpi
Status: enabled

Name: Saved Password Editor
Location: ${PROFILE_EXTENSIONS}/savedpasswordedi...@daniel.dawson.xpi
Status: enabled

Name: Send Tab to Device
Location: ${PROFILE_EXTENSIONS}/jid1-mdjma7if6lo...@jetpack.xpi
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Stylish Sync
Location: ${PROFILE_EXTENSIONS}/{0e3fc079-afbb-4a00-87e5-9486062d0f9c}.xpi
Status: enabled

Name: SuperStop
Location: ${PROFILE_EXTENSIONS}/supers...@gavinsharp.com.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: Web Compat
Location: ${PROFILE_EXTENSIONS}/webcom...@mozilla.org.xpi
Status: enabled

Name: xda-developers forum - suppress minimum page width userstyle
Status: enabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: Google Talk Plugin
Location: 

Bug#820255: Fixed Upstream

[Matthew Gabeler-Lee]

This seems to be fixed upstream in their mercurial repo, according to:

https://sourceforge.net/p/joe-editor/bugs/354/
https://sourceforge.net/p/joe-editor/mercurial/ci/e050c4a911bb4f84b51e3c931e424477c217c972/

And therefore I think should be fixed by updating the package to the
upstream 4.3 release.

Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps

[Matthew Gabeler-Lee]

On Thu, 13 Oct 2016, Rogier Wolff wrote:


No! Not a "more reasonable" value! An outrageous value!

You have a network where 5 hops-in-a-row don't conform to IP standards. And
then you expect mtr to work?


traceroute works fine, ping works fine, tcp connections work fine ... 
but mtr is special and should fail just because the network doesn't meet 
your ideals?  And yeah, MTR would work fine in this case if it didn't 
decide to give up "just because".  The "give up after 5" is the /only/ 
thing preventing it from working properly.


To put a concrete example to it, consider the case of tunnels, esp. 
VPNs.  It is common for the TTL of the tunneled packet to be copied to 
the outer packet for various good reasons.  But this means that 
traceroute through that tunnel will not return the errors for any TTL 
value that causes the packet to be dropped at points between the 
endpoints of the tunnel, because the error will be returned back to the 
tunnel endpoint, not the original sender.


Happens with OpenVPN (it's even in their FAQ I think), happens with the 
Cisco IPSEC site-to-site tunnel used at my employer.


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#840563: mtr: New 0.87 release fixes issue with paths with long gaps

[Matthew Gabeler-Lee]

Package: mtr
Version: 0.86-1+b1
Severity: wishlist

A new upstream release 0.87 has a fix (of sorts) for the problem where MTR
will not trace a successful path that has more than five non-responding
hops.  I say fix "of sorts" because the default limit for this has not been
changed, but it is now possible to override that default on the command
line.  FWIW the MTR git shows that an upcoming not-yet-released version also
increases the default to a more reasonable value.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, '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: systemd (via /run/systemd/system)

Versions of packages mtr depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-2
ii  libgtk2.0-0  2.24.31-1
ii  libncurses5  6.0+20160917-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpangoft2-1.0-01.40.3-2
ii  libtinfo56.0+20160917-1

mtr recommends no packages.

mtr suggests no packages.

-- no debconf information

Bug#839843: /usr/bin/lxc-create: Ran rm -rf on an entire filesystem after failing to create a container

[Matthew Gabeler-Lee]

Package: lxc
Version: 1:2.0.4-1
Severity: normal
File: /usr/bin/lxc-create

I ran lxc-create to setup an image, and realized I had given it the wrong
arguments (wrong distro version, nothing dramatic), so I stopped it with
Ctrl-C and cleaned up the partial directory it left behind.

Some time later, while in the process of setting up the container created
from using the correct arguments, I noticed many many things going wrong. 
As I started to go WTF, this pops out on the console used for the original
incorrect lxc-create:

lxc-destroy: utils.c: _recursive_rmdir: 170 _recursive_rmdir: failed to delete 
/scratch
lxc-destroy: lxccontainer.c: container_destroy: 2384 Error destroying rootfs 
for centos7-32bit-lxc
Container is not defined
exiting...

It ran rm -rf on the ENTIRE FILESYSTEM CONTAINING ALL OF MY LXC IMAGES.

Instead of doing an rm -rf on the container, it tried to do an rm -rf of the
directory in which the container was created, and since it had to be run as
root to create the container, it was pretty $#!%$ successful.

reportbug wants me to quote chapter and verse from the policy manual to mark
this as a serious bug, but "don't rm -rf the entire OS" is so blatantly
obvious that there is no specific policy entry to reference.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, '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: systemd (via /run/systemd/system)

Versions of packages lxc depends on:
ii  init-system-helpers  1.45
ii  libapparmor1 2.10.95-4+b1
ii  libc62.24-3
ii  libcap2  1:2.25-1
ii  liblxc1  1:2.0.4-1
ii  libseccomp2  2.3.1-2
ii  libselinux1  2.5-3
ii  python3  3.5.1-4
pn  python3:any  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-9
pn  cgmanager 
pn  debootstrap   
ii  dirmngr   2.1.15-3
ii  dnsmasq-base  2.76-4
ii  gnupg 2.1.15-3
ii  iptables  1.6.0-3
pn  libpam-cgfs   
pn  lxcfs 
ii  openssl   1.0.2j-1
ii  rsync 3.1.1-3
pn  uidmap

Versions of packages lxc suggests:
pn  apparmor 
ii  btrfs-tools  4.7.3-1
pn  lua5.2   
ii  lvm2 2.02.164-1

-- no debconf information

Bug#839671: linux-image-4.7.0-1-amd64: NEWS should document conntrack policy changes

[Matthew Gabeler-Lee]

On Mon, 3 Oct 2016, Ben Hutchings wrote:


The kernel has warned about reliance on auto-loading conntrack helpers
since 3.5, so this should not be surprising.


How many people do you think really peruse dmesg for low level warnings? 
Esp. considering that the kernel boot messages aren't even printed on 
the console any more.


A warning that isn't displayed anywhere is not much of a warning IMO.

In my case it wasn't even printed during the boot / firewall startup, 
but some four hours later (when I guess the first time a conntrack rule 
failed to operate in the legacy way hit), so even if I checked the logs 
during the firewall startup, when the iptables rules that don't work any 
more were added, it wouldn't have helped me.


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#839671: linux-image-4.7.0-1-amd64: NEWS should document conntrack policy changes

[Matthew Gabeler-Lee]

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

The 4.7 kernel seems to have MASSIVELY changed how firewalls are allowed to
use conntrack modules by default, rendering many common firewall
configurations invalid in significant ways.

This should be called out in the NEWS (possibly conditional on having some
common firewall tools installed or something?) so that administrators are
not caught by surprise.

More info:

http://www.spinics.net/lists/netfilter/msg56874.html

https://home.regit.org/netfilter-en/secure-use-of-helpers/


-- Package-specific info:
** Version:
Linux version 4.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.1 
20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.7.5-1 (2016-09-26)

** Command line:
BOOT_IMAGE=/vmlinuz-4.7.0-1-amd64 root=/dev/mapper/harkonnen-root ro reboot=pci 
cgroup_enable=memory swapaccount=1 quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   25.836274] nf_tables: (c) 2007-2009 Patrick McHardy 
[   26.185996] eth1br: port 1(eth1) entered forwarding state
[   26.186005] eth1br: topology change detected, propagating
[   27.365910] systemd[1]: apt-daily.timer: Adding 4h 25min 38.321890s random 
time.
[   28.263668] systemd[1]: apt-daily.timer: Adding 8h 50min 1.016862s random 
time.
[   39.086611] FS-Cache: Loaded
[   39.094549] FS-Cache: Netfs 'nfs' registered for caching
[   39.185329] Key type dns_resolver registered
[   39.202051] NFS: Registering the id_resolver key type
[   39.202063] Key type id_resolver registered
[   39.202064] Key type id_legacy registered
[   97.928816] NET: Unregistered protocol family 40
[  103.103052] vmmon: module verification failed: signature and/or required key 
missing - tainting kernel
[  103.104294] /dev/vmmon[10438]: Module vmmon: registered with major=10 
minor=165
[  103.104297] /dev/vmmon[10438]: Using tsc_khz as TSC frequency: 3591682
[  103.104298] /dev/vmmon[10438]: Module vmmon: initialized
[  103.112243] Guest personality initialized and is inactive
[  103.112286] VMCI host device registered (name=vmci, major=10, minor=57)
[  103.112287] Initialized host personality
[  103.126305] NET: Registered protocol family 40
[  103.327626] /dev/vmnet: open called by PID 10585 (vmnet-bridge)
[  103.327633] /dev/vmnet: hub 0 does not exist, allocating memory.
[  103.327646] /dev/vmnet: port on hub 0 successfully opened
[  103.327652] bridge-eth0: up
[  103.327655] bridge-eth0: attached
[  103.328527] /dev/vmnet: open called by PID 10587 (vmnet-bridge)
[  103.328530] /dev/vmnet: hub 1 does not exist, allocating memory.
[  103.328538] /dev/vmnet: port on hub 1 successfully opened
[  103.328541] bridge-eth1br: up
[  103.328542] bridge-eth1br: attached
[  152.941930] /dev/vmmon[13596]: PTSC: initialized at 40 Hz using TSC, 
TSCs are synchronized.
[  153.014435] /dev/vmmon[13596]: Monitor IPI vector: ff
[  153.014437] /dev/vmmon[13596]: HV  IPI vector: f2
[  153.529637] /dev/vmnet: open called by PID 13648 (vmx-vcpu-0)
[  153.529645] device eth1br entered promiscuous mode
[  153.529699] bridge-eth1br: enabled promiscuous mode
[  153.529701] /dev/vmnet: port on hub 1 successfully opened
[  600.892487] usb 3-4.1.1: USB disconnect, device number 9
[ 1074.401746] usb 3-4.1.1: new high-speed USB device number 17 using xhci_hcd
[ 1074.506571] usb 3-4.1.1: New USB device found, idVendor=18d1, idProduct=4ee1
[ 1074.506573] usb 3-4.1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1074.506575] usb 3-4.1.1: Product: Nexus 6P
[ 1074.506575] usb 3-4.1.1: Manufacturer: Huawei
[ 1074.506576] usb 3-4.1.1: SerialNumber: 5VT7N15A24002460
[ 9528.592627] EXT4-fs (dm-17): write access unavailable, skipping orphan 
cleanup
[ 9528.592629] EXT4-fs (dm-17): recovery complete
[ 9528.592631] EXT4-fs (dm-17): mounted filesystem with ordered data mode. 
Opts: (null)
[ 9528.617423] EXT4-fs (dm-11): mounted filesystem with ordered data mode. 
Opts: (null)
[ 9528.634692] EXT4-fs (dm-14): write access unavailable, skipping orphan 
cleanup
[ 9528.634694] EXT4-fs (dm-14): recovery complete
[ 9528.634696] EXT4-fs (dm-14): mounted filesystem with ordered data mode. 
Opts: (null)
[ 9528.646217] EXT4-fs (dm-20): mounted filesystem with ordered data mode. 
Opts: (null)
[ 9998.097187] usb 3-4.1.1: USB disconnect, device number 17
[ 9998.309217] usb 3-4.1.1: new high-speed USB device number 18 using xhci_hcd
[ 9998.410986] usb 3-4.1.1: New USB device found, idVendor=18d1, idProduct=4ee2
[ 9998.410989] usb 3-4.1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 9998.410990] usb 3-4.1.1: Product: Nexus 6P
[ 9998.410991] usb 3-4.1.1: Manufacturer: Huawei
[ 9998.410993] usb 3-4.1.1: SerialNumber: 5VT7N15A24002460
[10023.951019] usb 3-4.1.1: USB disconnect, device number 18
[10024.163247] usb 3-4.1.1: new high-speed USB device number 19 using xhci_hcd
[10024.264508] usb 3-4.1.1: New USB device found, idVendor=18d1, idProduct=4ee1

Bug#838929: virt-manager: Does not render remote display unless window is larger than needed

[Matthew Gabeler-Lee]

Package: virt-manager
Version: 1:1.4.0-3
Severity: normal

If the remote VM display window is exactly the size it needs to be, then the
remote display does not render for me.  If I resize the window to be just
one pixel bigger (in either or both dimensions), everything works fine.  Of
course, this totally breaks fullscreen mode if my screen and the remote
screen are the same resolution.

This is happening with both a Windows 10 guest, and a text-mode-only Linux
guest.  In both cases, remote qemu/kvm VMs.

The "doesn't render" extends to not even clearing the window background.  If
the viewer window was partly obscured by another window, and I switch focus
to the viewer and raise it, it leaves whatever pixels were on screen from
the occluding window still there until I resize the window.

Note: this also seems to affect virt-viewer 4.0, but details of that app's
behavior make it harder to see what's going on with this bug.

The requested run with --debug --no-fork doesn't produce any output when
resizing the windows either into or out of the problem state.  It prints
debug messages for connecting to the remote VM and connecting the spice
channels, but once connected, no output on any of the window resizes.

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

Kernel: Linux 4.6.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: systemd (via /run/systemd/system)

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.21.5-3
ii  gir1.2-gtk-vnc-2.0   0.6.0-1
ii  gir1.2-libosinfo-1.0 0.3.1-5
ii  gir1.2-libvirt-glib-1.0  0.2.3-2
ii  gir1.2-vte-2.91  0.45.90-2
ii  librsvg2-common  2.40.16-1
ii  python-dbus  1.2.4-1
ii  python-gi3.22.0-1
ii  python-gi-cairo  3.22.0-1
ii  python-libvirt   2.2.0-1
ii  python-requests  2.11.1-1
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.4.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.32-1
ii  gnome-icon-theme 3.12.0-2
ii  libvirt-daemon-system2.2.0-1

Versions of packages virt-manager suggests:
ii  gnome-keyring 3.20.0-3
ii  python-gnomekeyring   2.32.0+dfsg-3
pn  python-guestfs
ii  ssh-askpass-fullscreen [ssh-askpass]  0.3-3.1
ii  virt-viewer   4.0-1

-- no debconf information

Bug#838615: autoconf-archive: ax_cxx_compile_stdcxx_*.m4 are broken, cause failures building other software

[Matthew Gabeler-Lee]

Package: autoconf-archive
Version: 20160320-1
Severity: important

After updating this package, builds of other software are failing:

srcdir$ aclocal-1.9
/usr/share/aclocal/ax_cxx_compile_stdcxx_14.m4:32: file 
`ax_cxx_compile_stdcxx.m4' does not exist

Google suggests that this has been fixed upstream:

https://lists.gnu.org/archive/html/autoconf-archive-commits/2016-05/msg1.html
https://github.com/peti/autoconf-archive/pull/78
https://github.com/peti/autoconf-archive/commit/fd864cb41ad922b66b144a280143f53844b39a95
https://github.com/peti/autoconf-archive/commit/d343892fbd0605a9375ff1ae0467aa320a404b12

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

Kernel: Linux 4.6.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: systemd (via /run/systemd/system)

Versions of packages autoconf-archive depends on:
ii  dpkg  1.18.10

Versions of packages autoconf-archive recommends:
ii  autoconf  2.69-10

autoconf-archive suggests no packages.

-- no debconf information

Bug#834148: systemd-inhibit no longer respected

[Matthew Gabeler-Lee]

On Tue, 6 Sep 2016, Matthew Gabeler-Lee wrote:


I upgraded to 231-5, but I'm still having this problem, exactly as described
by the prior reporters :(


Sorry, please disregard this.  The problem is that upgrading systemd 
doesn't restart running daemons sufficiently for at least this fix to 
take effect.  After a reboot the issue _is_ fixed.


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#836324: tightvncserver: Typing gives wrong keys in some apps

[Matthew Gabeler-Lee]

Package: tightvncserver
Version: 1.3.9-8
Severity: important

tightvncserver was working fine for me for a long time until I restarted my
VNC server session recently.  Now I find that in most apps I can type fine,
but certain apps get the keys all wrong.  Nearly the entire un-shifted US
keyboard (letters and numbers) are coming out wrong.

I discovered this in bitcoin-qt, but xkeycaps also shows the problem
behavior.

Unaffected include firefox, lxterm, and even xev.

Interestingly, in xkeycaps, the keycode shows correct (e.g.  the 1 key shows
1) but the keysym shows wrong (e.g.  the 1 key shows 9).

Switching to vnc4server instead of tightvncserver makes this problem go
away.

Note: this is not the same behavior has these other old bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545939
I have the workaround for this one in place.  Turning it on or off does not
affect the problem I'm describing here.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514476
Using a US keyboard, and in my case pretty much ALL keys are broken, not
just some, and nothing is accidentally shifted or such.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698859
Again, different set of keys broken for me, not just a couple but nearly
all.

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages tightvncserver depends on:
ii  libc62.23-5
ii  libjpeg62-turbo  1:1.5.0-1
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  perl 5.22.2-3
ii  x11-common   1:7.7+16
ii  x11-utils7.7+3
ii  xauth1:1.0.9-1
ii  xserver-common   2:1.18.4-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages tightvncserver recommends:
ii  x11-xserver-utils  7.7+7
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tightvncserver suggests:
ii  tightvnc-java  1.2.7-9

-- no debconf information

Bug#833767: firefox: skia canvas backend does not render Google Sheets properly on non-HiDPI systems

[Matthew Gabeler-Lee]

Package: firefox
Version: 48.0-1
Severity: normal

After upgrading to Firefox 48, I noticed that Google Sheets on my "normal"
DPI system does not render fonts legibly any more.

Changing gfx.canvas.azure.backends from skia to cairo and restarting firefox 
fixes this.

I think this may be related to
https://bugzilla.mozilla.org/show_bug.cgi?id=981391, though that is quite
old and somewhat windows-centric.

Screenshot showing the illegibility attached.

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: All-in-One Gestures
Location: ${PROFILE_EXTENSIONS}/{8b86149f-01fb-4842-9dd8-4d7eb02fd055}
Status: enabled

Name: bug489729(Disable detach and tear off tab)
Location: ${PROFILE_EXTENSIONS}/bug489729@alice0775
Status: enabled

Name: Cookie Monster
Location: ${PROFILE_EXTENSIONS}/{45d8ff86-d909-11db-9705-005056c8}
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: dtv jira tweaks userstyle
Status: enabled

Name: Element Hiding Helper for Adblock Plus
Location: ${PROFILE_EXTENSIONS}/elemhidehel...@adblockplus.org.xpi
Status: enabled

Name: Firefox Hello
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: Google Privacy
Location: ${PROFILE_EXTENSIONS}/{ea61041c-1e22-4400-99a0-aea461e69d04}.xpi
Status: enabled

Name: Hide right hand pane in Gmail userstyle
Status: enabled

Name: Hide Tab Bar With One Tab
Location: ${PROFILE_EXTENSIONS}/{e5bbc237-c99b-4ced-a061-0be27703295f}.xpi
Status: enabled

Name: HTTP/2 and SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: Linkification
Location: ${PROFILE_EXTENSIONS}/{35106bca-6c78-48c7-ac28-56df30b51d2a}.xpi
Status: enabled

Name: Mailvelope
Location: ${PROFILE_EXTENSIONS}/jid1-aqqsmbyb0a8...@jetpack.xpi
Status: enabled

Name: Master Password+
Location: ${PROFILE_EXTENSIONS}/masterpasswordtimeoutplus@vano
Status: enabled

Name: meta-q-override
Location: ${PROFILE_EXTENSIONS}/jid1-7osji9sxtay...@jetpack.xpi
Status: enabled

Name: msdn tweaks userstyle
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: No Native Notifications
Location: ${PROFILE_EXTENSIONS}/nnnotif...@robwu.nl.xpi
Status: enabled

Name: PasswordMaker
Location: ${PROFILE_EXTENSIONS}/{5872365e-67d1-4afd-9480-fd293bebd20d}.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Referrer Control
Location: ${PROFILE_EXTENSIONS}/referrercont...@qixinglu.com.xpi
Status: enabled

Name: ReloadEvery
Location: ${PROFILE_EXTENSIONS}/{888d99e7-e8b5-46a3-851e-1ec45da1e644}.xpi
Status: enabled

Name: Saved Password Editor
Location: ${PROFILE_EXTENSIONS}/savedpasswordedi...@daniel.dawson.xpi
Status: enabled

Name: Send Tab to Device
Location: ${PROFILE_EXTENSIONS}/jid1-mdjma7if6lo...@jetpack.xpi
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Stylish Sync
Location: ${PROFILE_EXTENSIONS}/{0e3fc079-afbb-4a00-87e5-9486062d0f9c}.xpi
Status: enabled

Name: SuperStop
Location: ${PROFILE_EXTENSIONS}/supers...@gavinsharp.com.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: xda-developers forum - suppress minimum page width userstyle
Status: enabled

-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: Shockwave Flash (21.0.0.242)
Location: 
/usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so
Package: browser-plugin-freshplayer-pepperflash
Status: enabled


-- Addons package information
ii  browser-plugin 0.3.5-1  amd64PPAPI-host NPAPI-plugin adapter f
ii  firefox48.0-1   amd64Mozilla Firefox web browser
ii  gnome-shell3.20.3-1 amd64graphical shell for the GNOME des
ii  google-talkplu 5.41.3.0-1   amd64Google Talk Plugin

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

Kernel: 

Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP sink on session start

[Matthew Gabeler-Lee]

Package: gdm3
Version: 3.20.1-1
Followup-For: Bug #805414

It seems like gdm3 should not be claiming the A2DP audio interface, or
really _any_ audio interface when it is not 'active' / visible.

It needs the keyboard to accept passwords, but it doesn't prevent me from
using my keyboard after I log in ;)

I realize the PA bits are going to be (much) more complicated than the
keyboard example, but the principle applies I think.

Being ignorant of PA, I'm also a bit confused as to why A2DP is special
here.  Other sound devices aren't broken by gdm3 wanting to have sound
services available for accessibility, why is A2DP different here?

Bug#823286: xserver-xorg-input-libinput: Significant functional regressions for touchapds vs. xserver-xorg-input-synaptics

[Matthew Gabeler-Lee]

On 05/26/2016 04:02 PM, Emilio Pozuelo Monfort wrote:

> Thanks for your report, and sorry for the trouble this caused.

I would like to note that, with the latest updates to GNOME:

1) xserver-xorg-input-synaptics is mostly non-functional, insofar as
adjusting settings and having things work the way they used to

2) The worst of my complaints about xserver-xorg-input-libinput have
been resolved.  Things are not as fully functional as they were with the
synaptics driver, but they are usable, subject to some fiddling with
hidden settings in dconf.  The clickpad behaviors on my hardware still
default to the "wrong" setting, but I can now change that via the hidden
dconf settings.

What is most noticeably missing for me in the libinput driver now is the
"momentum" scrolling.

For anyone else that comes across this, the hidden settings in dconf to
change the clickpad behaviors can be found in
/org/gnome/desktop/peripherals/touchpad

Bug#828026: linux-image-4.6.0-1-amd64: Spanning Tree (STP) not working in 4.6, was in 4.5, seems to ignore incoming BPDU packets

[Matthew Gabeler-Lee]

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

Upgrading to the 4.6 kernel from 4.5 seems to have broken STP.

If I create a bridge interface and add one or more physical interfaces, the
system running the Debian 4.6 kernel package ALWAYS thinks it is the bridge
root (regardless of what other STP devices are on the network and their
bridge priorities), and further will not put ANY port into the blocking
state, even when there is a loop (as confirmed by broadcast storm and lots
of "received packet on $interface with own address as source address" errors
in the logs).

Monitoring the physical interfaces with tshark shows that the BPDUs are
being both sent and received at that level, but the system running the 4.6
kernel simply seems to ignore the ones coming in, even if they have much
lower bridge priorities.

The 4.5 kernel package seems to operate STP correctly and will negotiate
which device should be the bridge root correctly.

I'm able to reproduce this on multiple systems.  One of them has a second
strange problem with not sending BPDUs at all even on the 4.5 kernel, but I
expect that is a different issue.

-- Package-specific info:
** Version:
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-4) ) #1 SMP Debian 4.6.2-1 (2016-06-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.6.0-1-amd64 root=/dev/mapper/bengal-root ro 
cgroup_enable=memory quiet

** Tainted: E (8192)
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[2.446308] Bluetooth: hci0: read Intel version: 370710018002030d53
[2.446310] Bluetooth: hci0: Intel device is already patched. patch num: 53
[2.447390] sd 0:0:0:0: Attached scsi generic sg0 type 0
[2.453311] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless N 
7260, REV=0x144
[2.453579] iwlwifi :02:00.0: L1 Enabled - LTR Enabled
[2.453968] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input7
[2.454030] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input8
[2.454117] iwlwifi :02:00.0: L1 Enabled - LTR Enabled
[2.470971] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[2.471306] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input9
[2.490499] EFI Variables Facility v0.08 2004-May-17
[2.495673] ACPI: Battery Slot [BAT1] (battery present)
[2.509940] pstore: Registered efi as persistent store backend
[2.602595] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[2.602601] [drm] Initialized i915 1.6.0 20160229 for :00:02.0 on minor 0
[2.602977] ACPI Warning: SystemIO range 
0xF040-0xF05F conflicts with OpRegion 
0xF040-0xF04F (\_SB.PCI0.SBUS.SMBI) 
(20160108/utaddress-255)
[2.602984] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[2.614899] fbcon: inteldrmfb (fb0) is primary device
[2.651464] input: PC Speaker as /devices/platform/pcspkr/input/input10
[2.675989] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[2.679989] clocksource: Switched to clocksource tsc
[2.765677] input: ELAN Touchscreen as 
/devices/pci:00/:00:14.0/usb2/2-7/2-7:1.0/0003:04F3:0089.0001/input/input11
[2.765874] hid-multitouch 0003:04F3:0089.0001: input,hiddev0,hidraw0: USB 
HID v1.10 Device [ELAN Touchscreen] on usb-:00:14.0-7/input0
[2.793080] iTCO_vendor_support: vendor-support=0
[2.794412] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[2.794464] iTCO_wdt: Found a Lynx Point_LP TCO device (Version=2, 
TCOBASE=0x1860)
[2.794910] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[2.841962] intel_rapl: Found RAPL domain package
[2.841964] intel_rapl: Found RAPL domain core
[2.841965] intel_rapl: Found RAPL domain uncore
[2.841967] intel_rapl: Found RAPL domain dram
[2.841971] intel_rapl: RAPL package 0 domain package locked by BIOS
[2.841975] intel_rapl: RAPL package 0 domain dram locked by BIOS
[2.850481] Adding 8388604k swap on /dev/mapper/bengal-swap_1.  Priority:-1 
extents:1 across:8388604k SSFS
[2.859965] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: 
(null)
[2.958855] FAT-fs (sda2): utf8 is not a recommended IO charset for FAT 
filesystems, filesystem will be case sensitive!
[3.751824] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[3.751825] Bluetooth: BNEP filters: protocol multicast
[3.751828] Bluetooth: BNEP socket layer initialized
[3.762132] r8169 :03:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168g-2.fw
[3.801596] r8169 :03:00.0 eth0: link down
[3.802677] Console: switching to colour frame buffer device 400x112
[3.803105] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[3.817349] i915 :00:02.0: fb0: inteldrmfb frame 

Bug#827758: apt: Misleadingly reports Hash Sum mismatch if package is missing stronger hashes (e.g. sha256, sha512)

[Matthew Gabeler-Lee]

Package: apt
Version: 1.2.13
Severity: normal

When trying to install a package from an upstream source that is missing the
stronger hashes (Google, sigh), apt is misleadingly reporting that the hash
doesn't match on the download, which is not the problem at all:

sudo apt-get -oDebug::Hashes=true -oDebug::pkgAcquire=true 
-oDebug::pkgAcquire::Auth=true install google-talkplugin

ReceivedHash:
- 
SHA512:8802c1726c9b362db5302a8b2243c8d84c2b35b9ab55adacc08ed05a5fb98d2778c2ff516a5df13bcaa499ab9d902481957b119624467be69a2833e0b76ba218
- 
SHA256:af7e23d2b6215afc547f96615b99f04e0561557cc58c0c9302364b5a3840d97d
- SHA1:0bbc3d6997ba22ce712d93e5bc336c894b54fc81
- MD5Sum:03ea81590baa680d286d28533c4d40e1
- Checksum-FileSize:7800474
ExpectedHash:
- SHA1:0bbc3d6997ba22ce712d93e5bc336c894b54fc81
- MD5Sum:03ea81590baa680d286d28533c4d40e1

Dequeuing /var/cache/apt/archives/partial/google-talkplugin_5.41.3.0-1_amd64.deb
Err:1 http://dl.google.com/linux/talkplugin/deb stable/main amd64 
google-talkplugin amd64 5.41.3.0-1
  Hash Sum mismatch
Fetched 7,800 kB in 0s (8,140 kB/s)
Dequeuing /var/cache/apt/archives/partial/google-talkplugin_5.41.3.0-1_amd64.deb
E: Failed to fetch 
http://dl.google.com/linux/talkplugin/deb/pool/main/g/google-talkplugin/google-talkplugin_5.41.3.0-1_amd64.deb
  Hash Sum mismatch

Note that the hashes that are published match.  The only problem seems to be
the lack of the stronger hashes (apt-get update of course warns about this
for the package list retrieval too)


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.5\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.6\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "1";
APT::Periodic::MaxSize "1000";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 

Bug#826717: firefox: Native notifications no longer working after upgrade

[Matthew Gabeler-Lee]

I retract my prior mail ... without that firefox add-on installed, HTML5
notifications don't work at all for me.  I don't get native OR XUL
notifications ... I get nothing.  With that add-on installed, I at least
get XUL notifications.

Bug#826717: firefox: Native notifications no longer working after upgrade

[Matthew Gabeler-Lee]

Package: firefox
Version: 46.0.1-1+b1
Followup-For: Bug #826717

This is A OK with me, because the GNOME notifications didn't work most of
the time.  With some websites (Google Calendar for one), it was 100%
failure.  I believe I found a page somewhere where someone had tracked it
down to a problem with notifications that gave a custom image URL that
required traversing an HTTP 302 redirect to retrieve the actual image.

This was a common enough bug that there's this add-on:
https://addons.mozilla.org/en-US/firefox/addon/no-native-notifications/

Bug#667611: n-m-openvpn shuts down VPN when openvpn soft-restarts

[Matthew Gabeler-Lee]

Package: network-manager-openvpn
Version: 1.2.0-1
Followup-For: Bug #667611

I think the root cause of this issue may have changed over time, given the
activity on the upstream openvpn bug report, but the fact that it still
fails.

I see this locally with this error in the logs:

May  9 09:18:49 bengal nm-openvpn[20895]: Preserving previous TUN/TAP instance: 
tap0
May  9 09:18:49 bengal nm-openvpn[20895]: 
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --bus-name 
org.freedesktop.NetworkManager.openvpn.Connection_53 --tap -- tap0 1500 1574 
10.0.0.175 255.255.255.0 restart
May  9 09:18:49 bengal nm-openvpn[20895]: WARNING: Failed running command 
(--up/--down): could not execute external program
May  9 09:18:49 bengal nm-openvpn[20895]: Exiting due to fatal error

I think the problem now is that you can't use --up-restart with --chroot,
unless the --up script is also present at the same path in the chroot.

PS: #567153 is probably a duplicate of this issue.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.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: systemd (via /run/systemd/system)

Versions of packages network-manager-openvpn depends on:
ii  adduser   3.114
ii  libc6 2.22-7
ii  libglib2.0-0  2.48.0-1
ii  libnm01.2.0-1
ii  openvpn   2.3.10-1

network-manager-openvpn recommends no packages.

network-manager-openvpn suggests no packages.

-- no debconf information

Bug#823286: xserver-xorg-input-libinput: Significant functional regressions for touchapds vs. xserver-xorg-input-synaptics

[Matthew Gabeler-Lee]

Source: xserver-xorg-input-libinput
Version: 0.18.0-1
Severity: normal

I'm filing this as "normal" severity, since I'm not sure how common my
installation setup is (how many people have mice vs.  slick multitouch
touchpads), but personally this is "important" or higher -- I have
uninstalled this package because it removes basic capabilities from my
hardware.

The libinput driver seems to be replacing the synaptics driver, but it does
not match it in functionality:

* The pointer acceleration tracking is far worse than the synaptics driver. 
  I was able to trivially adjust the pointer speed settings for the
  synaptics driver so that I can have fine grained pointer control and also
  be able to quickly move the pointer from one side of the screen to the
  other.  After the libinput driver installed, I have no more control over
  acceleration, and have had to turn down the pointer speed lest it fly all
  over the screen, and so now it's hard to get the pointer across the screen
  in a single swipe across my LARGE touchpad.

* Multi-finger click for secondary buttons is gone.  Apparently the libinput
  folks decided that this feature should be disabled unless your touchpad
  says it comes from Apple.  Because NOBODY ELSE ever wants this feature or
  had it turned on before ... oh ... wait ... *sigh*.  Granted, there is a
  way to bring this back via mucking in dconf, but it disabled a common
  feature for no apparent reason with no notice and provides no UI to get it
  back.

* Inertial scrolling is gone, and there's no hidden setting for this. 
  Apparently the synaptics driver had a corner case issue where the
  scrolling wouldn't stop when you started typing ...  so they just deleted
  the entire inertial scrolling feature and decided it was someone else's
  job to implement it ...  and nobody has.  Who knows if they ever will?

To sum it up, this "upgrade" damages pointer motion, clicking, and
scrolling.  Since we don't have the fancier multitouch gesture support out
of the box in Linux yet, that means 100% of the things I can do with my
touchpad got noticeably worse.

Until this input driver covers the core features of what it's replacing, it
doesn't seem right to have it be the default driver for these types of
devices.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.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: systemd (via /run/systemd/system)

Bug#822581: libvirt-daemon: Missing dependency on systemd-container

[Matthew Gabeler-Lee]

Package: libvirt-daemon
Version: 1.3.3-2
Severity: important

The libvirt-daemon package is missing a dependency on systemd-container. 
Without this, lxc instances are completely unusable, don't know if qemu
instances or others are affected too.

Without systemd-container, lxc containers fail to start with an error "no
valid cgroup for machine" ...  except that many of the processes are running
and have to be killed manually.  But the network for the container does not
come up.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.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: systemd (via /run/systemd/system)

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.10-4
ii  libaudit1   1:2.4.5-1+b1
ii  libavahi-client30.6.32~rc+dfsg-1
ii  libavahi-common30.6.32~rc+dfsg-1
ii  libblkid1   2.28-1
ii  libc6   2.22-7
ii  libcap-ng0  0.7.7-1+b1
ii  libdbus-1-3 1.10.8-1
ii  libdevmapper1.02.1  2:1.02.120-1
ii  libfuse22.9.5-1
ii  libgnutls30 3.4.10-4
ii  libnetcf1   1:0.2.8-1
ii  libnl-3-200 3.2.27-1
ii  libnl-route-3-200   3.2.27-1
ii  libnuma12.0.11-1
ii  libparted2  3.2-15
ii  libpcap0.8  1.7.4-2
ii  libpciaccess0   0.13.4-1
ii  librados2   0.80.11-1
ii  librbd1 0.80.11-1
ii  libsasl2-2  2.1.26.dfsg1-15
ii  libselinux1 2.4-3+b1
ii  libssh2-1   1.5.0-2.1
ii  libsystemd0 229-4
ii  libudev1229-4
ii  libvirt01.3.3-2
ii  libxen-4.6  4.6.0-1+nmu2
ii  libxenstore3.0  4.6.0-1+nmu2
ii  libxml2 2.9.3+dfsg1-1
ii  libyajl22.1.0-2

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.3+dfsg1-1
ii  netcat-openbsd  1.105-7
ii  qemu-kvm1:2.5+dfsg-5+b1

Versions of packages libvirt-daemon suggests:
ii  libvirt-daemon-system  1.3.3-2

-- no debconf information

Bug#821808: [pkg-gnupg-maint] Bug#821808: Acknowledgement (libgpgme11: Fails to locate new key in agent (wrong keygrip?))

[Matthew Gabeler-Lee]

On Tue, 19 Apr 2016, Daniel Kahn Gillmor wrote:


Thanks for the followup.  I'm closing this report since there's a clear
workaround.  However, gpg2 (from the 2.1 branch) should have migrated
your secret keyring automatically the first time it ever encountered
them.


It did do that properly.  My problem was having created a new key with 
gpg long after gpg2 ran that migration.



fwiw, i'm hoping that gpg and gpg2 will be the same thing (from the
2.1.x sources) in debian in the not-too-distant future.


:happydance:

--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#821808: Acknowledgement (libgpgme11: Fails to locate new key in agent (wrong keygrip?))

[Matthew Gabeler-Lee]

I tracked down the problem.  It is because all the instructions on the
web for creating new keys are about using "gpg", but gpgme is built on
"gpg2", and the two no longer share the private key ring.

Quick fix for anyone that comes across this via google or such:

gpg --export-secret-keys | gpg2 --import -

Bug#821808: libgpgme11: Fails to locate new key in agent (wrong keygrip?)

[Matthew Gabeler-Lee]

Package: libgpgme11
Version: 1.6.0-1
Severity: normal

libgpgme seems to have problems handling my new RSA 4096 bit key.  In my
case, this is breaking reprepro (CC'ing maintainer of that).

Having the same problem as this person on Server Fault:
http://serverfault.com/questions/770130/reprepro-export-could-not-find-signing-key

Using gpg-connect-agent's KEYINFO command, and the logging suggestion from
that serverfault post, it seems like gpgme is computing the wrong keygrip(s)
for the key.  It sends a HAVEKEY with two keygrips, neither of which match
the keygrips listed by KEYINFO --list.

In the context of reprepro, I'm providing it the SignWith option and giving
the 8 digit hex ID of my new key.  This works fine when passed to e.g.  gpg
--list-secret-keys.  But reprepro complains:

Could not find any key matching '4A3CC4E9'!

Based on the gpgme failure.  If I give the hex ID for my old DSA key, it
works fine.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages libgpgme11 depends on:
ii  gnupg2 2.1.11-6
ii  libassuan0 2.4.2-3
ii  libc6  2.22-6
ii  libgpg-error0  1.21-2

libgpgme11 recommends no packages.

Versions of packages libgpgme11 suggests:
pn  gpgsm  

-- no debconf information

Bug#820747: eclipse: Latest Gnome/GTK theme updates render portions of eclipse unreadable white-on-white

[Matthew Gabeler-Lee]

Package: eclipse
Version: 3.8.1-8
Severity: normal

After updating to the current gnome packages from testing this morning,
portions of eclipse are no longer readable.  Most problematic is the quick
outline, which now displays most text as "white on white".

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

Kernel: Linux 4.4.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: systemd (via /run/systemd/system)

Versions of packages eclipse depends on:
ii  eclipse-jdt  3.8.1-8
ii  eclipse-pde  3.8.1-8

eclipse recommends no packages.

eclipse suggests no packages.

Versions of packages eclipse-platform depends on:
ii  ant1.9.6-2
ii  ant-optional   1.9.6-2
ii  eclipse-platform-data  3.8.1-8
ii  eclipse-rcp3.8.1-8
ii  gconf-service  3.2.6-3
ii  java-common0.57
ii  libc6  2.22-5
ii  libcommons-codec-java  1.10-1
ii  libcommons-httpclient-java 3.1-12
ii  libcommons-logging-java1.2-1
ii  libgconf-2-4   3.2.6-3
ii  libglib2.0-0   2.48.0-1
ii  libjetty8-java 8.1.19-1
ii  libjsch-java   0.1.53-1
ii  liblucene2-java2.9.4+ds1-4
ii  libservlet3.0-java 7.0.68-1
ii  multiarch-support  2.22-5
ii  openjdk-7-jre [java6-runtime]  7u91-2.6.3-1
ii  sat4j  2.3.3-1

Versions of packages eclipse-platform recommends:
ii  eclipse-pde  3.8.1-8

Versions of packages eclipse-platform suggests:
ii  eclipse-jdt  3.8.1-8

Versions of packages eclipse-pde depends on:
ii  eclipse-jdt3.8.1-8
ii  eclipse-platform   3.8.1-8
ii  libasm3-java   3.3.2-3
ii  openjdk-7-jre [java6-runtime]  7u91-2.6.3-1

eclipse-pde suggests no packages.

Versions of packages eclipse-jdt depends on:
ii  eclipse-platform   3.8.1-8
ii  junit  3.8.2-8
ii  junit4 4.12-4
ii  libhamcrest-java   1.3-5
ii  openjdk-7-jre [java6-runtime]  7u91-2.6.3-1

Versions of packages eclipse-jdt recommends:
pn  default-jdk | sun-java6-jdk  

eclipse-jdt suggests no packages.

-- no debconf information

Bug#814578: laptop-mode-tools throttles pstate-managed CPUs to half speed on battery power

[Matthew Gabeler-Lee]

On 04/07/2016 04:42 AM, Ritesh Raj Sarraf wrote:
> What hardware are you on? There's a recent kernel fix in the thermal 
> subsystem,
> which affected many users.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=114551
> https://bugzilla.redhat.com/show_bug.cgi?id=1317190
This sounds exactly like my issue.  I'm on a Samsung Ativ Book 9 Plus.

Bug#814578: laptop-mode-tools throttles pstate-managed CPUs to half speed on battery power

[Matthew Gabeler-Lee]

Package: laptop-mode-tools
Version: 1.69.2-1
Followup-For: Bug #814578

I have this problem too, but it's even worse for me.

The throttling to "50%" ends up mapping to "always stuck at the bog minimum
slowest speed possible".

cpufreq-info -c 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.00 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.00 GHz.
  The governor "powersave" may decide which speed to use
  within this range.

Even running burnP6 * nCPUs from cpuburn won't bump it off the bare minimum
800MHz when on battery.

My cpu is a:
model name  : Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz

Which I guess explains why "50%" is "800MHz" -- 3GHz is the max turbo freq,
800MHz is presumably the only step close to 1800/2=900 MHz.

>From what I've read, preventing the CPU from bumping up to higher
frequencies can actually *increase* power consumption because it forces the
CPU to stay awake longer before returning to an idle low power / sleep
state.

Needless to say I'm fixing this locally in my config files, but I would
suggest that the current defaults should be revisited as producing poor
behavior, and possibly being misguided.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.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: systemd (via /run/systemd/system)

Versions of packages laptop-mode-tools depends on:
ii  init-system-helpers  1.29
ii  lsb-base 9.20160110
ii  psmisc   22.21-2.1+b1
ii  util-linux   2.27.1-6

Versions of packages laptop-mode-tools recommends:
ii  ethtool 1:4.5-1
ii  hdparm  9.48+ds-1
ii  net-tools   1.60+git20150829.73cef8a-2
ii  python-qt4  4.11.4+dfsg-1+b3
pn  sdparm  
ii  udev229-3
ii  wireless-tools  30~pre9-9

Versions of packages laptop-mode-tools suggests:
ii  acpid  1:2.0.26-1

-- no debconf information

Bug#820255: joe: Character range searching doesn't work in UTF8 locale

[Matthew Gabeler-Lee]

Package: joe
Version: 4.1-2
Severity: normal

Create a file with some text ...  e.g.  this bug report ...  with lots of
upper and lower case letters.

Start editing with LANG=en_US.UTF-8

Search for "\[a-z]" or "\[A-Z]" or "\[0-9]" -- no matches found.

Search for "\[0123456789]" -- matches found!

Change LANG to C, try again -- both work properly.

Change LANG to en_US.ISO-8859-15 -- both work properly.

Seems to be a problem with UTF8 I infer.

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

Kernel: Linux 4.4.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: systemd (via /run/systemd/system)

Versions of packages joe depends on:
ii  libc62.22-5
ii  libncurses5  6.0+20160319-1
ii  libtinfo56.0+20160319-1

joe recommends no packages.

joe suggests no packages.

-- Configuration Files:
/etc/joe/ftyperc changed [not included]
/etc/joe/joerc changed [not included]

-- no debconf information

Bug#819598: (no subject)

[Matthew Gabeler-Lee]

Addenda:

I meant #816865, not 816815

Upgrading bluez locally gets rid of the prior errors, but produces other
errors, and the mouse still doesn't work (at first, but keep reading)

I cleared the previous pairing and tried to re-pair, just to be "safe"

Mar 30 21:20:56 hostname bluetoothd[1421]: GATT service objects disabled
Mar 30 21:20:56 hostname kernel: [   36.700194] Bluetooth: SMP security
requested but not available

The last line repeats every ~15 *milliseconds* until it times out and
gives up.  That sounds like
https://bugzilla.kernel.org/show_bug.cgi?id=104011

Following the suggestion there (bluetoothctl power off / power on) I was
able to pair and use the mouse!

The kernel.org ticket suggests it will be temporarily broken again when
I reboot, and that the root cause of that is a udev rule causing the
bluetooth host to be brought up in "legacy mode".

Bug#819598: bluetooth: Can't use bluetooth 4 / LE HID devices

[Matthew Gabeler-Lee]

Package: bluetooth
Version: 5.36-1
Severity: normal
Tags: upstream

I'm having the same problem as described in this Ubuntu ticket:

https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1546603

My log entries, for completeness:

Mar 30 20:43:56 hostname bluetoothd[1525]: Error reading PNP_ID value: 
Attribute requires authentication before read/write
Mar 30 20:43:56 hostname bluetoothd[1525]: Unable to register GATT service with 
handle 0x0009 for device C6:E5:C2:98:9B:58
Mar 30 20:43:56 hostname bluetoothd[1525]: Unable to register GATT service with 
handle 0x000e for device C6:E5:C2:98:9B:58
Mar 30 20:43:57 hostname bluetoothd[1525]: Report Map read failed: Attribute 
requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Protocol Mode characteristic read 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: HID Information read failed: 
Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write
Mar 30 20:43:57 hostname bluetoothd[1525]: Read Report Reference descriptor 
failed: Attribute requires authentication before read/write

I'm using a Microsoft Bluetooth Mouse 3600 for reference.  It is a BT4/LE
device.  It pairs and connects just fine, but no HID events make it through
(at least not through to X) -- no pointer movement, clicks, or scrolls.

Some deep time with Google suggests that this issue affects quite a few
folks (not just Debian, includes keyboards as well as other mice) and _may_
be fixed by this upstream patch:

http://www.spinics.net/lists/linux-bluetooth/msg66469.html
AKA
http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=064f48ad6dd0eb4becb94f5492b6c78218065f19

Which I think is included in the latest upstream release (5.38).  I haven't
had the chance yet to test/verify this.

I see #816815 is also requesting an update to newer upstream to support
newer hardware, though not related to this specific issue.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.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: systemd (via /run/systemd/system)

Versions of packages bluetooth depends on:
ii  bluez  5.36-1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
ii  bluez-cups   5.36-1
ii  bluez-obexd  5.36-1

-- no debconf information

Bug#819466: alien: DEB->RPM does not setup Provides for shared libraries properly

[Matthew Gabeler-Lee]

Package: alien
Version: 8.95
Severity: normal

Example: Converting the debian liblockfile1 and lockfile-progs to RPM
packages, because CentOS packages totally broken and useless versions of
these.

The converted lockfile-progs has these Requires:

libc.so.6
libc.so.6(GLIBC_2.0)
liblockfile.so.1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

But the converted liblockfile1 only has these Provides:

liblockfile1 = 1.09-7
liblockfile1(x86-32) = 1.09-7

Note that the provides and requires for the shared library are totally
disjoint, resulting in the application RPM not being installable!

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

Kernel: Linux 4.4.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: systemd (via /run/systemd/system)

Versions of packages alien depends on:
ii  cpio   2.11+dfsg-5
ii  debhelper  9.20160313
ii  dpkg-dev   1.18.4
ii  make   4.1-9
ii  perl   5.22.1-9
ii  rpm4.12.0.1+dfsg1-3+b2
ii  rpm2cpio   4.12.0.1+dfsg1-3+b2

alien recommends no packages.

Versions of packages alien suggests:
ii  bzip21.0.6-8
pn  lintian  
ii  patch2.7.5-1
ii  xz-utils [lzma]  5.1.1alpha+20120614-2.1

-- no debconf information

Bug#817929: mosh fails to connect, giving a UDP error

[Matthew Gabeler-Lee]

On 03/24/2016 12:31 AM, john hood wrote:
> I haven't been able to chase these glibc details down.  Do you have
> pointers to specifics for this?
My assessment was based just on reading the referenced glibc-help
thread, and the commit it referenced --
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=beff1d132c16aedd87a3f1bc7b572c8e69819015

The commit contains this comment ahead of the "trampoline" generation:

/* libpthread once had its own fork, though there was no apparent reason
   for it.  There is no use in having a separate symbol in libpthread, but
   the historical ABI requires it.  For static linking, there is no need to
   provide anything here--the libc version will be linked in.  For shared
   library ABI compatibility, there must be __fork and fork symbols in
   libpthread.so; so we define them using IFUNC to redirect to the libc
   function.  */

There is also some further discussion on the glibc thread since it was
first referenced here.  To summarize some key items from that:

"this is a bug.  Could you report it in Bugzilla here, please?"

"The commit you identified, beff1d132c16aedd87a3f1bc7b572c8e69819015,
assumes that __libc_fork has been relocated before the IFUNC resolver
for the libpthread fork definition runs, which is not always true."

https://sourceware.org/bugzilla/show_bug.cgi?id=19861

So it looks like, contrary to my assessment (I said I wasn't an expert
:), this *is* a glibc bug.  But the mosh workaround is probably still
necessary in the short term.

Bug#817929: mosh fails to connect, giving a UDP error

[Matthew Gabeler-Lee]

On Tue, 22 Mar 2016 23:21:31 +0100 Goffredo Baroncelli
 wrote:
> Please give a look to
>
> https://sourceware.org/ml/libc-help/2016-03/msg00010.html
>
> to me it seems that the real problem is in glibc.

>From reading that thread and looking at the referenced git commit, I'm
not convinced it's a glibc bug.  While I'm definitely not an expert in
this area, it looks to me like glibc removed some legacy cruft that
should no longer have been needed by any app that used the correct
compile/link flags for pthreads.  They also added a workaround for a
common case of incorrect flags.

But what we have here is an uncommon case driven by mosh's linker
options, which means that the glibc workaround for protobuf's incorrect
linker options doesn't (can't?) work.

If protobuf didn't recommend incorrect linker options, we wouldn't have
this problem.  Seems thus this bug should be moved to the protobuf
package and the upstream patch applied?

Having mosh conflict with the broken protobuf versions would be handy
too, but may not be necessary?

Bug#817929: mosh fails to connect, giving a UDP error

[Matthew Gabeler-Lee]

Package: mosh
Version: 1.2.5-1.1
Followup-For: Bug #817929

Looks like upstream has a patch for this:

https://github.com/mobile-shell/mosh/pull/732/commits/a47917b97606a03f6bbf0cafd1fcd495b0229790

Though it looks like that's a hack and they really want this fixed in
protobuf:

https://github.com/google/protobuf/pull/1333

Which also has a patch.

This bug maybe should be moved to be against the protobuf package since that
seems the cleaner place to fix this?

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.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: systemd (via /run/systemd/system)

Versions of packages mosh depends on:
ii  dpkg1.18.4
ii  libc6   2.22-3
ii  libgcc1 1:5.3.1-11
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.2 1.0.2g-1
ii  libstdc++6  5.3.1-11
ii  libtinfo5   6.0+20160213-1
ii  libutempter01.1.6-3
ii  openssh-client  1:7.2p2-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  libio-socket-ip-perl  0.37-1
ii  perl-base [libio-socket-ip-perl]  5.22.1-9

mosh suggests no packages.

-- no debconf information

Bug#816372: mosh-server doesn't work without libpam-systemd

[Matthew Gabeler-Lee]

Package: mosh
Version: 1.2.5-1.1
Severity: normal

I was trying to get mosh-server working in a minimal chroot (LXC container)
running debian stable, and had problems where mosh-server was getting killed
off almost as soon as it started, but not clear from where.

After much google-fu and cursing and hair pulling, I finally came across this:

https://lists.freedesktop.org/archives/systemd-devel/2014-May/019531.html

Which gave me the hint that I needed to install libpam-systemd in the
minimal chroot.  After that, mosh functioned properly.

I'm not sure if this should be fixed by a Recommends or a Suggests or maybe
just a note in the README.Debian?  Perhaps that even belongs in the sshd
package, since it is the session setup by sshd that isn't getting done
correctly without libpam-sshd.  The logind session setup & teardown here are
a bit beyond my understanding.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.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: systemd (via /run/systemd/system)

Versions of packages mosh depends on:
ii  dpkg1.18.4
ii  libc6   2.21-9
ii  libgcc1 1:5.3.1-8
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.2 1.0.2f-2
ii  libstdc++6  5.3.1-8
ii  libtinfo5   6.0+20160213-1
ii  libutempter01.1.6-3
ii  openssh-client  1:7.1p2-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  libio-socket-ip-perl  0.37-1
ii  perl-base [libio-socket-ip-perl]  5.22.1-7

mosh suggests no packages.

-- no debconf information

Bug#815046: owfs-fuse: Crash if fuse options provided

[Matthew Gabeler-Lee]

Package: owfs-fuse
Version: 3.1p1-2
Severity: important
Tags: patch upstream

If you pass --fuse-opt or --fuse-open-opt to the ofws fuse program, it will 
crash.

Submitted upstream as https://sourceforge.net/p/owfs/bugs/69/

Patch to fix this attached

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.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: systemd (via /run/systemd/system)
Contrary to quilt, dpkg-source does not handle correctly various EOL :-(
So, we store the whole diff here
--- a/module/owfs/src/c/fuse_line.c
+++ b/module/owfs/src/c/fuse_line.c
@@ -97,7 +97,7 @@
 	
 	orm.number = 1 ;
 	
-	ow_regcomp( _farg, "^\".+\"$", 0 ) ;
+	ow_regcomp( _farg, "^\"(.+)\"$", 0 ) ;
 	
 	if ( ow_regexec( _farg, opt_arg,  ) != 0 ) {
 		fprintf(stderr, "Put the %s value in quotes. \"%s\"", entryname, opt_arg);

Bug#812843: iceweasel: Many notifications are not shown with libnotify enabled

[Matthew Gabeler-Lee]

Package: iceweasel
Version: 44.0-1
Severity: normal

I find that many HTML5 style notifications aren't shown in iceweasel (not
new in this version, just finally got motivated to dig a little due to the
notification enhancements advertised in this version).

Most notification demo sites work, but notably gmail only sometimes works,
and most annoyingly, google calendar _never_ works.

Searching in bugzilla, I find these reports that look similar, but I'm not
sure how to dig in further to find out if one of them matches my case:

https://bugzilla.mozilla.org/show_bug.cgi?id=1236150
https://bugzilla.mozilla.org/show_bug.cgi?id=726594
https://bugzilla.mozilla.org/show_bug.cgi?id=1162788

Installing this extension to disable libnotify usage makes notifications
from my "problem" sites work properly, though naturaully now with XUL
instead of libnotify appearance.

https://addons.mozilla.org/en-US/firefox/addon/disable-system-alerts/

It's also worth noting that there are new notification control options as of
44.0 in the XUL version that don't seem to be accessible from the libnotify
version.

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: All-in-One Gestures
Location: ${PROFILE_EXTENSIONS}/{8b86149f-01fb-4842-9dd8-4d7eb02fd055}
Status: enabled

Name: bug489729(Disable detach and tear off tab)
Location: ${PROFILE_EXTENSIONS}/bug489729@alice0775
Status: enabled

Name: Cookie Monster
Location: ${PROFILE_EXTENSIONS}/{45d8ff86-d909-11db-9705-005056c8}.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Disable System Alerts
Location: 
${PROFILE_EXTENSIONS}/disable-system-ale...@matthew.noorenberghe.com.xpi
Status: enabled

Name: dtv jira tweaks userstyle
Status: enabled

Name: Element Hiding Helper for Adblock Plus
Location: ${PROFILE_EXTENSIONS}/elemhidehel...@adblockplus.org.xpi
Status: enabled

Name: Google Privacy
Location: ${PROFILE_EXTENSIONS}/{ea61041c-1e22-4400-99a0-aea461e69d04}.xpi
Status: enabled

Name: Hide right hand pane in Gmail userstyle
Status: enabled

Name: Hide Tab Bar With One Tab
Location: ${PROFILE_EXTENSIONS}/{e5bbc237-c99b-4ced-a061-0be27703295f}.xpi
Status: enabled

Name: Linkification
Location: ${PROFILE_EXTENSIONS}/{35106bca-6c78-48c7-ac28-56df30b51d2a}.xpi
Status: enabled

Name: Master Password+
Location: ${PROFILE_EXTENSIONS}/masterpasswordtimeoutplus@vano
Status: enabled

Name: meta-q-override
Location: ${PROFILE_EXTENSIONS}/jid1-7osji9sxtay...@jetpack.xpi
Status: enabled

Name: msdn tweaks userstyle
Status: enabled

Name: PasswordMaker
Location: ${PROFILE_EXTENSIONS}/{5872365e-67d1-4afd-9480-fd293bebd20d}.xpi
Status: enabled

Name: Referrer Control
Location: ${PROFILE_EXTENSIONS}/referrercont...@qixinglu.com.xpi
Status: enabled

Name: ReloadEvery
Location: ${PROFILE_EXTENSIONS}/{888d99e7-e8b5-46a3-851e-1ec45da1e644}.xpi
Status: enabled

Name: Saved Password Editor
Location: ${PROFILE_EXTENSIONS}/savedpasswordedi...@daniel.dawson.xpi
Status: enabled

Name: Send Tab to Device
Location: ${PROFILE_EXTENSIONS}/jid1-mdjma7if6lo...@jetpack.xpi
Status: enabled

Name: SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Stylish Sync
Location: ${PROFILE_EXTENSIONS}/{0e3fc079-afbb-4a00-87e5-9486062d0f9c}.xpi
Status: enabled

Name: SuperStop
Location: ${PROFILE_EXTENSIONS}/supers...@gavinsharp.com.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: xda-developers forum - suppress minimum page width userstyle
Status: enabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled


-- Addons package information
ii  gnome-shell3.18.1-1 amd64graphical shell for the GNOME des
ii  google-talkplu 5.41.0.0-1   amd64Google Talk Plugin
ii  iceweasel  44.0-1   amd64Web browser based on Firefox

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Bug#761215: base-passwd: Changes made to passwd file without administrator permission

[Matthew Gabeler-Lee]

Package: base-passwd
Version: 3.5.39
Followup-For: Bug #761215

Actually, it does _not_ prompt ... unless debconf is _not_ installed and
prompting is not possible -- i.e., I think this is a bug.  From
base-passwd.postinst:


tmp=`tempfile`
if ! update-passwd --dry-run > $tmp ; then
if [ -f /usr/share/debconf/confmodule ] ; then
db_version 2.0
update-passwd --verbose
changes=1
else
# debconf prompting


I believe that probably should be "if [ ! -f .../deconf/..."

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, '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: systemd (via /run/systemd/system)

Versions of packages base-passwd depends on:
ii  libc6  2.21-6
ii  libdebconfclient0  0.201

Versions of packages base-passwd recommends:
ii  debconf [debconf-2.0]  1.5.58

base-passwd suggests no packages.

-- debconf information excluded

Bug#761215: base-passwd: Changes made to passwd file without administrator permission

[Matthew Gabeler-Lee]

On 01/13/2016 12:37 PM, Colin Watson wrote:
> As Russ says, that depends on the nature of the change and on the active
> debconf priority.
Aah, OK ... My problem was that I had thought I had my debconf question
priority set differently than I actually did.  Fixing that fixes my
problem, sorry for the noise.

Bug#761215: base-passwd: Changes made to passwd file without administrator permission

[Matthew Gabeler-Lee]

On 01/13/2016 11:29 AM, Colin Watson wrote:
> That's a rather strange summary of the code.  The bit in the "else"
> branch is in fact *non*-debconf prompting.
Oops, re-read the code and you're right.  A better summary of the code I
guess would be:

if (debconf is available) then
  update non-interactively without prompting administrator
else
  update interactively without debconf if a terminal is available
fi

The end result is still that, in normal situations, it will never
confirm the changes with the admin, which means that changes made by the
local admin will be silently reverted.

Bug#808466: update error at configure

[Matthew Gabeler-Lee]

Package: redmine
Version: 3.0~20140825-8
Followup-For: Bug #808466

I believe this may be related to rails updating to 4.2.x in testing, whereas
redmine seems to still be searching for 4.1.x given the error message?

Hacking on /usr/share/redmine/Gemfile to change it to look for 4.2.x (making
the unreasonable assumption that this is OK) then leads to:

Could not find gem 'jquery-rails (~> 3.1.1) ruby' in any of the gem sources
listed in your Gemfile or available on this machine.

And indeed ruby-jquery-rails is now 4.0.x.  Making another unreasonable
assumption that hacking on that version in the Gemfile is OK allows the
postint script to finish.

I haven't done significant checking to see if all of redmine, esp. jquery
related functionality, actually still works with this hacking done.

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages redmine depends on:
ii  bundler 1.10.6-2
ii  dbconfig-common 1.8.58
ii  debconf [debconf-2.0]   1.5.58
ii  libjs-scriptaculous 1.9.0-2
ii  redmine-mysql   3.0~20140825-8
ii  ruby1:2.2.4
ii  ruby-actionpack-action-caching  1.1.1-4
ii  ruby-awesome-nested-set 3.0.0-1
ii  ruby-coderay1.1.0-4
ii  ruby-i18n   0.7.0-2
ii  ruby-jquery-rails   4.0.5-1
ii  ruby-mime-types 2.6.1-1
ii  ruby-net-ldap   0.8.0-1
ii  ruby-openid 2.7.0debian-1
ii  ruby-protected-attributes   1.1.3-1
ii  ruby-rack   1.6.4-2
ii  ruby-rack-openid1.4.2-1
ii  ruby-rails  2:4.2.5-1
ii  ruby-rails-observers0.1.2-1
ii  ruby-redcarpet  3.3.2-1+b1
ii  ruby-request-store  1.1.0-1
ii  ruby-rmagick2.15.4-2+b1
ii  ruby1.9.1 [ruby-interpreter]1.9.3.484-2
ii  ruby2.0 [ruby-interpreter]  2.0.0.484+really457-3
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.3-2

Versions of packages redmine recommends:
ii  libfcgi-ruby1.9.1  0.9.2.1-1
ii  ruby-fcgi [libfcgi-ruby1.9.1]  0.9.2.1-1+b6
ii  ruby-passenger 5.0.22-1

Versions of packages redmine suggests:
pn  bzr 
ii  cvs 2:1.12.13+real-15
pn  darcs   
ii  git 1:2.6.4-1
ii  mercurial   3.5.2-2
pn  subversion  

-- debconf information excluded

Bug#806691: mpd: systemd service file issue: LimitRTTIME has invalid value

[Matthew Gabeler-Lee]

Package: mpd
Version: 0.19.11-1
Severity: normal

Systemd regularly complains about mpd's service file:

systemd[1]: [/lib/systemd/system/mpd.service:11] Failed to parse resource 
value, ignoring: -1

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages mpd depends on:
ii  adduser   3.113+nmu3
ii  init-system-helpers   1.24
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-0.3
ii  libao41.1.0-3
ii  libasound21.0.29-1
ii  libaudiofile1 0.3.6-2+b1
ii  libavahi-client3  0.6.32~rc+dfsg-1
ii  libavahi-common3  0.6.32~rc+dfsg-1
ii  libavcodec-ffmpeg56   7:2.8.2-1
ii  libavformat-ffmpeg56  7:2.8.2-1
ii  libavutil-ffmpeg547:2.8.2-1
ii  libbz2-1.01.0.6-8
ii  libc6 2.19-22
ii  libcdio-cdda1 0.83-4.2
ii  libcdio-paranoia1 0.83-4.2
ii  libcdio13 0.83-4.2
ii  libcurl3-gnutls   7.45.0-1+b1
ii  libdbus-1-3   1.10.4-1
ii  libexpat1 2.1.0-7
ii  libfaad2  2.8.0~cvs20150510-1
ii  libflac8  1.3.1-4
ii  libfluidsynth11.1.6-3
ii  libglib2.0-0  2.46.2-1
ii  libgme0   0.6.0-3
ii  libicu55  55.1-6
ii  libid3tag00.15.1b-11
ii  libiso9660-8  0.83-4.2
ii  libjack0 [libjack-0.116]  1:0.124.1+20140122git5013bed0-3
ii  libmad0   0.15.1b-8
ii  libmikmod33.3.8-1
ii  libmms0   0.6.4-1
ii  libmodplug1   1:0.8.8.5-2
ii  libmp3lame0   1:3.99.5-dmo5
ii  libmpcdec62:0.1~r475-1
ii  libmpdclient2 2.9-1
ii  libmpg123-0   1.22.4-1
ii  libnfs8   1.9.8-dmo1
ii  libogg0   1.3.2-1
ii  libopenal11:1.16.0-3
ii  libopus0  1.1-2
ii  libpulse0 7.1-2
ii  libresid-builder0c2a  2.1.1-14
ii  libroar2  1.0~beta11-5
ii  libsamplerate00.1.8-8
ii  libshout3 2.3.1-3
ii  libsidplay2   2.1.1-14
ii  libsidutils0  2.1.1-14
ii  libsmbclient  2:4.1.17+dfsg-4
ii  libsndfile1   1.0.25-10
ii  libsoxr0  0.1.2-1
ii  libsqlite3-0  3.9.2-1
ii  libstdc++65.2.1-23
ii  libsystemd0   228-2
ii  libupnp6  1:1.6.19+git20141001-1
ii  libvorbis0a   1.3.4-3
ii  libvorbisenc2 1.3.4-3
ii  libvorbisfile31.3.4-3
ii  libwavpack1   4.75.0-1
ii  libwildmidi1  0.3.8-2
ii  libwrap0  7.6.q-25
ii  libyajl2  2.1.0-2
ii  libzzip-0-13  0.13.62-3
ii  lsb-base  9.20150917
ii  zlib1g1:1.2.8.dfsg-2+b1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon  0.6.32~rc+dfsg-1
ii  glurp [mpd-client]0.12.3-1
ii  gmpc [mpd-client] 11.8.16-9
pn  icecast2  
ii  mpc [mpd-client]  0.27-2
ii  ncmpcpp [mpd-client]  0.6.6-1
pn  pulseaudio

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

-- no debconf information

Bug#805179: dmeventd libdevmapper-event-lvm2raid.so dlopen failed

[Matthew Gabeler-Lee]

Package: dmeventd
Version: 2:1.02.110-1
Followup-For: Bug #805179

This also affects libdevmapper-event-lvm2snapshot.so, which appears to make
snapshot "full" monitoring fail:

$ sudo lvcreate -L 2G -s -p r -n lv-snap vg/lv
  Monitoring vg/snapshot0 failed.
  Logical volume "lv-snap" created.

$ sudo strace -f -p $(pidof dmeventd) -e open |& fgrep .so
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 7
open("/lib/x86_64-linux-gnu/libdevmapper-event-lvm2snapshot.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/libdevmapper-event-lvm2snapshot.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libdevmapper-event-lvm2snapshot.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libdevmapper-event-lvm2snapshot.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
open("/usr/lib/libdevmapper-event-lvm2snapshot.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)

syslog:
Nov 16 19:29:28 cheetah dmeventd[17538]: dmeventd 
libdevmapper-event-lvm2snapshot.so dlopen failed: 
libdevmapper-event-lvm2snapshot.so: cannot open shared object file: No such 
file or directory.

As a temporary workaround:
$ cd /lib/x86_64-linux-gnu/
$ sudo ln -s device-mapper/*.so* .


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

Kernel: Linux 4.2.0-1-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages dmeventd depends on:
ii  init-system-helpers   1.24
ii  libc6 2.19-22
ii  libdevmapper-event1.02.1  2:1.02.110-1
ii  libdevmapper1.02.12:1.02.110-1
ii  liblvm2cmd2.022.02.133-1

dmeventd recommends no packages.

dmeventd suggests no packages.

-- no debconf information

Bug#804195: libapache2-mod-passenger: Incompatible with apache 2.4.17

[Matthew Gabeler-Lee]

Package: libapache2-mod-passenger
Version: 5.0.7-3
Severity: important
Tags: upstream

I found that the front page of my Redmine installation using passenger would
not work -- I would instead get an apache error about directory indexes not
being allowed.

After many hours of searching, I finally found that I was not the only one,
and it turns out to be an incompatibility with passenger and a specific
version of apache.

Upstream discussions of this issue:
https://groups.google.com/forum/#!topic/phusion-passenger/jiOpv9Isua4
https://bz.apache.org/bugzilla/show_bug.cgi?id=58498
https://github.com/phusion/passenger/pull/1642
https://github.com/phusion/passenger/issues/1648

And the patch submitted to upstream (scheduled for inclusion in a future
release) that fixes this:

https://github.com/covener/passenger/commit/b70b0e8e9ee14a2dbda94ca92545fb3b07c30f24

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-passenger depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.17-1
ii  libapr1 1.5.2-3
ii  libaprutil1 1.5.4-1
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-22
ii  libstdc++6  5.2.1-22
ii  passenger   5.0.7-3

libapache2-mod-passenger recommends no packages.

libapache2-mod-passenger suggests no packages.

-- Configuration Files:
/etc/apache2/mods-available/passenger.conf changed [not included]

-- no debconf information

Bug#804195: libapache2-mod-passenger: Incompatible with apache 2.4.17-1

[Matthew Gabeler-Lee]

Addendum -- it is only 2.4.17-1 that has this problem.  The Debian
apache maintainers reverted the apache change that broke this (for now)
in 2.4.17-2 -- see #803353.  It looks like even apache is going to
revert the change for the next 2.4 release --
https://bz.apache.org/bugzilla/show_bug.cgi?id=57785#c10

Bug#801992: iceweasel: App icons below 128x128 are cropped from instead of scaled from the larger image

[Matthew Gabeler-Lee]

Package: iceweasel
Version: 41.0.2-1
Severity: minor

Upgrading from 41.0.1-1 to 41.0.2-1, the app icons became damaged.  The
icons at sizes below 128x128 are now crops from the top left corner of the
128x128 icon instead of scaled down versions.  At the smaller sizes, this
produces an icon that is almost entirely transparency, with just a small
white triangle in the bottom right corner.

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: ${PROFILE_EXTENSIONS}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
Status: enabled

Name: Add-on Compatibility Reporter
Location: ${PROFILE_EXTENSIONS}/compatibil...@addons.mozilla.org.xpi
Status: enabled

Name: All-in-One Gestures
Location: ${PROFILE_EXTENSIONS}/{8b86149f-01fb-4842-9dd8-4d7eb02fd055}
Status: enabled

Name: bug489729(Disable detach and tear off tab)
Location: ${PROFILE_EXTENSIONS}/bug489729@alice0775
Status: enabled

Name: Cookie Monster
Location: ${PROFILE_EXTENSIONS}/{45d8ff86-d909-11db-9705-005056c8}.xpi
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: dtv jira tweaks userstyle
Status: enabled

Name: Element Hiding Helper for Adblock Plus
Location: ${PROFILE_EXTENSIONS}/elemhidehel...@adblockplus.org.xpi
Status: enabled

Name: Fox To Phone
Location: ${PROFILE_EXTENSIONS}/sendtoph...@martinezdelizarrondo.com.xpi
Status: enabled

Name: Google Privacy
Location: ${PROFILE_EXTENSIONS}/{ea61041c-1e22-4400-99a0-aea461e69d04}.xpi
Status: enabled

Name: Hide right hand pane in Gmail userstyle
Status: enabled

Name: Hide Tab Bar With One Tab
Location: ${PROFILE_EXTENSIONS}/{e5bbc237-c99b-4ced-a061-0be27703295f}.xpi
Status: enabled

Name: Linkification
Location: ${PROFILE_EXTENSIONS}/{35106bca-6c78-48c7-ac28-56df30b51d2a}.xpi
Status: enabled

Name: Master Password+
Location: ${PROFILE_EXTENSIONS}/masterpasswordtimeoutplus@vano
Status: enabled

Name: meta-q-override
Location: ${PROFILE_EXTENSIONS}/jid1-7osji9sxtay...@jetpack.xpi
Status: enabled

Name: msdn tweaks userstyle
Status: enabled

Name: PasswordMaker
Location: ${PROFILE_EXTENSIONS}/{5872365e-67d1-4afd-9480-fd293bebd20d}.xpi
Status: enabled

Name: Referrer Control
Location: ${PROFILE_EXTENSIONS}/referrercont...@qixinglu.com.xpi
Status: enabled

Name: ReloadEvery
Location: ${PROFILE_EXTENSIONS}/{888d99e7-e8b5-46a3-851e-1ec45da1e644}.xpi
Status: enabled

Name: Saved Password Editor
Location: ${PROFILE_EXTENSIONS}/savedpasswordedi...@daniel.dawson.xpi
Status: enabled

Name: SPDY indicator
Location: ${PROFILE_EXTENSIONS}/spdyindica...@chengsun.github.com.xpi
Status: enabled

Name: Stylish
Location: ${PROFILE_EXTENSIONS}/{46551EC9-40F0-4e47-8E18-8E5CF550CFB8}.xpi
Status: enabled

Name: Stylish Sync
Location: ${PROFILE_EXTENSIONS}/{0e3fc079-afbb-4a00-87e5-9486062d0f9c}.xpi
Status: enabled

Name: SuperStop
Location: ${PROFILE_EXTENSIONS}/supers...@gavinsharp.com.xpi
Status: enabled

Name: User Agent Switcher
Location: ${PROFILE_EXTENSIONS}/{e968fc70-8f95-4ab9-9e79-304de2a71ee1}.xpi
Status: enabled

Name: xda-developers forum - suppress minimum page width userstyle
Status: enabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: Google Talk Plugin
Location: /opt/google/talkplugin/libnpgoogletalk.so
Package: google-talkplugin
Status: enabled

Name: Google Talk Plugin Video Renderer
Location: /opt/google/talkplugin/libnpo1d.so
Package: google-talkplugin
Status: enabled

Name: Shockwave Flash (11.2.202.521)
Location: /usr/lib/flashplugin-nonfree/libflashplayer.so
Status: enabled


-- Addons package information
ii  gnome-shell3.16.3-2+b1  amd64graphical shell for the GNOME des
ii  google-talkplu 5.41.0.0-1   amd64Google Talk Plugin
ii  iceweasel  41.0.2-1 amd64Web browser based on Firefox

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, '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: systemd (via /run/systemd/system)

Versions of packages iceweasel depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.19-22
ii  libcairo2 1.14.2-2
ii  libdbus-1-3   1.10.0-3
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.2.1-3
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6-2
ii  libgcc1   1:5.2.1-21
ii  libgdk-pixbuf2.0-02.32.1-1
ii  libglib2.0-0  2.46.0-2
ii  libgtk2.0-0  

Bug#771784: remmina: Missing controls tab from top/center of window in fullscreen

[Matthew Gabeler-Lee]

Package: remmina
Version: 1.1.2-3
Followup-For: Bug #771784

This is supposedly fixed upstream in "1.2.0-rcgit.3", see their FAQ:
https://github.com/FreeRDP/Remmina/wiki/Remmina-Usage-FAQ

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

Kernel: Linux 4.2.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: systemd (via /run/systemd/system)

Versions of packages remmina depends on:
ii  dbus-x111.10.0-3
ii  libavahi-client30.6.31-5
ii  libavahi-common30.6.31-5
ii  libavahi-ui-gtk3-0  0.6.31-5
ii  libc6   2.19-22
ii  libgcrypt20 1.6.3-2
ii  libgdk-pixbuf2.0-0  2.32.1-1
ii  libglib2.0-02.46.0-2
ii  libgtk-3-0  3.16.6-1
ii  libpango-1.0-0  1.38.0-3
ii  libssh-40.6.3-4.1
ii  libvte-2.91-0   0.42.0-1
ii  libx11-62:1.6.3-1
ii  remmina-common  1.1.2-3

Versions of packages remmina recommends:
ii  remmina-plugin-rdp  1.1.2-3
ii  remmina-plugin-vnc  1.1.2-3

remmina suggests no packages.

-- no debconf information

Bug#801079: mercurial-common: bash completion broken

[Matthew Gabeler-Lee]

Package: mercurial-common
Version: 3.5.1-2
Severity: normal

Despite installing bash completion helpers, it doesn't work, for the
exceedingly simple reason that the filename is wrong.  Dynamic completion
loading looks for the completion file to be named for the command, and the
command is "hg", not "mercurial", so it doesn't find it and no smart
completion is enabled.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, '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: systemd (via /run/systemd/system)

Versions of packages mercurial-common depends on:
ii  libjs-excanvas  0.r3-4
ii  python  2.7.9-1
pn  python:any  

Versions of packages mercurial-common recommends:
ii  ca-certificates  20150426
ii  mercurial3.5.1-2

Versions of packages mercurial-common suggests:
pn  python-mysqldb   
ii  python-openssl   0.15.1-2
ii  python-pygments  2.0.1+dfsg-1.1
ii  tk [wish]8.6.0+8

-- no debconf information

Bug#799784: network-manager: VPN connect timer kills reconnect after password fail

[Matthew Gabeler-Lee]

Package: network-manager
Version: 1.0.6-1
Severity: normal

I'm experiencing this with network-manager-openvpn, but a quick grep through
the source suggests it is a bug in the core network-manager vpn support and
not in the openvpn plugin itself.

Scenario:
* Start a VPN connection that requires entering secrets (e.g. openvpn with
  the PAM plugin on the server)
* Accidentally fat-finger the password
* Reconnect immediately and type the password correctly this time
* Wait a minute and watch NM kill the successfully started VPN

Syslog:

Starting the connection and fat fingering the password:

Sep 22 09:50:23 xyzzy NetworkManager[848]: (nm-openvpn-service:20864): 
nm-openvpn-WARNING **: 
(nm-openvpn-service.c:1269):nm_openvpn_start_openvpn_binary: runtime check 
failed: (priv->mgt_path == NULL)
Sep 22 09:50:23 xyzzy NetworkManager[848]:   VPN plugin state changed: 
starting (3)
Sep 22 09:50:23 xyzzy NetworkManager[848]: nm-openvpn-Message: openvpn started 
with pid 22961
Sep 22 09:50:23 xyzzy NetworkManager[848]:   VPN connection 'xyzzy' 
(Connect) reply received.
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: OpenVPN 2.3.7 x86_64-pc-linux-gnu [SSL 
(OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Sep  8 2015
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: library versions: OpenSSL 1.0.2d 9 Jul 
2015, LZO 2.08
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: NOTE: the current --script-security 
setting may allow this configuration to call user-defined scripts
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: NOTE: chroot will be delayed because 
of --client, --pull, or --up-delay
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: NOTE: UID/GID downgrade will be 
delayed because of --client, --pull, or --up-delay
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: UDPv4 link local: [undef]
Sep 22 09:50:23 xyzzy nm-openvpn[22961]: UDPv4 link remote: 
[AF_INET]xyzzyip:xyzzyport
Sep 22 09:50:25 xyzzy nm-openvpn[22961]: [server] Peer Connection Initiated 
with [AF_INET]xyzzyip:xyzzyport
Sep 22 09:50:27 xyzzy nm-openvpn[22961]: AUTH: Received control message: 
AUTH_FAILED
Sep 22 09:50:27 xyzzy nm-openvpn[22961]: SIGUSR1[soft,auth-failure] received, 
process restarting
Sep 22 09:50:27 xyzzy NetworkManager[848]:   VPN plugin failed: 
login-failed (0)
Sep 22 09:50:27 xyzzy NetworkManager[848]:   VPN plugin state changed: 
stopped (6)
Sep 22 09:50:27 xyzzy NetworkManager[848]:   VPN plugin state change 
reason: login-failed (10)
Sep 22 09:50:27 xyzzy NetworkManager[848]: (nm-openvpn-service:20864): 
nm-openvpn-WARNING **: Password verification failed
Sep 22 09:50:27 xyzzy NetworkManager[848]:   error disconnecting VPN: 
Could not process the request because no VPN connection was active.

Oops, reconnect!

Sep 22 09:50:31 xyzzy NetworkManager[848]: (nm-openvpn-service:20864): 
nm-openvpn-WARNING **: 
(nm-openvpn-service.c:1269):nm_openvpn_start_openvpn_binary: runtime check 
failed: (priv->mgt_path == NULL)
Sep 22 09:50:31 xyzzy NetworkManager[848]: nm-openvpn-Message: openvpn started 
with pid 23033
Sep 22 09:50:31 xyzzy NetworkManager[848]:   VPN plugin state changed: 
starting (3)
Sep 22 09:50:31 xyzzy NetworkManager[848]:   VPN connection 'xyzzy' 
(Connect) reply received.
Sep 22 09:50:31 xyzzy nm-openvpn[23033]: OpenVPN 2.3.7 x86_64-pc-linux-gnu [SSL 
(OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Sep  8 2015
Sep 22 09:50:31 xyzzy nm-openvpn[23033]: library versions: OpenSSL 1.0.2d 9 Jul 
2015, LZO 2.08
Sep 22 09:50:32 xyzzy nm-openvpn[23033]: NOTE: the current --script-security 
setting may allow this configuration to call user-defined scripts
Sep 22 09:50:32 xyzzy nm-openvpn[23033]: NOTE: chroot will be delayed because 
of --client, --pull, or --up-delay
Sep 22 09:50:32 xyzzy nm-openvpn[23033]: NOTE: UID/GID downgrade will be 
delayed because of --client, --pull, or --up-delay
Sep 22 09:50:32 xyzzy nm-openvpn[23033]: UDPv4 link local: [undef]
Sep 22 09:50:32 xyzzy nm-openvpn[23033]: UDPv4 link remote: 
[AF_INET]xyzzyip:xyzzyport
Sep 22 09:50:33 xyzzy nm-openvpn[23033]: [server] Peer Connection Initiated 
with [AF_INET]xyzzyip:xyzzyport
Sep 22 09:50:35 xyzzy nm-openvpn[23033]: TUN/TAP device tap0 opened
Sep 22 09:50:35 xyzzy nm-openvpn[23033]: 
/usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --tap -- tap0 1500 
1574 xyzzy 255.255.255.0 init
Sep 22 09:50:35 xyzzy NetworkManager[848]:   (tap0): new Tun device 
(carrier: OFF, driver: 'tun', ifindex: 6)
Sep 22 09:50:35 xyzzy NetworkManager[848]:   devices added (path: 
/sys/devices/virtual/net/tap0, iface: tap0)
Sep 22 09:50:35 xyzzy NetworkManager[848]:   device added (path: 
/sys/devices/virtual/net/tap0, iface: tap0): no ifupdown configuration found.
Sep 22 09:50:35 xyzzy NetworkManager[848]:   VPN connection 'xyzzy' (IP 
Config Get) reply received.
Sep 22 09:50:35 xyzzy NetworkManager[848]:   VPN connection 'xyzzy' (IP4 
Config Get) reply received.
Sep 22 09:50:35 xyzzy NetworkManager[848]:   VPN plugin state changed: 
started (4)
Sep 22 09:50:35 xyzzy NetworkManager[848]:   VPN 

Bug#622265: TERM=screen.mlterm breaks dircolors

[Matthew Gabeler-Lee]

On 2015-08-26 12:05, Axel Beckert wrote:
 Matthew Gabeler-Lee wrote:
 This isn't just mlterm.  This breaks xterm, xterm-256color, etc. too

 I'm sorry, but while I can reproduce the issue with env TERM=mlterm
 screen, I can't reproduce it with env TERM=xterm-256color screen
 (on Jessie). In the latter case, dircolors just look fine to me.

I'm on stretch (testing) personally.  Launching screen inside
gnome-terminal is b0rked because of this for me, or at least it was
until I added logic to my ~/.bashrc to undo these broken TERM values and
push everything back to just being screen.

 Some systems don't even think the munged TERM values are real and
 cause problems like less complaining WARNING: terminal is not fully
 functional.

 That's IMHO a different issue. You should be able to work around it by
 either uninstalling ncurses-term locally or installing it remotely.
 IIRC if screen can't find the according terminfo entries, it won't use
 them and hence won't change $TERM to something more fancy than just
 screen.

I'm hitting this when using ssh from within a local screen.  I can't
demand that the sysadmins of every old non-Debian system I might want to
SSH to install a potentially unavailable package on their servers.

And if I uninstall ncurses-term on my local system, then trying to
connect to my from inside a screen on another system that does have that
package will be broken.

There needs to somehow be a trade-off here between supporting the newer
terminal features inside the screen session and not breaking access to
older systems.  I doubt the openssh folks would be impressed by an
enhancement request to support conditional expression-based changes to
the TERM variable, not to mention the degenerate case of plain old telnet.

The best compromise I can come up with at the moment is an option to
screen to disable this munging and just use plain old TERM=screen within
a given session.  That (plus the fix to dircolors, which from the other
recent email seems like an independent issue) would be a usable
workaround / compromise for me.  That would be an upstream feature
request I guess...

Bug#622265: TERM=screen.mlterm breaks dircolors

[Matthew Gabeler-Lee]

Package: screen
Version: 4.3.1-1
Followup-For: Bug #622265

This isn't just mlterm.  This breaks xterm, xterm-256color, etc. too -- i.e.
screen is now slightly incompatible with X environments in general.  Yuck.

This munging of the TERM variable also breaks access to other systems, e.g. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609656.  Some systems
don't even think the munged TERM values are real and cause problems like
less complaining WARNING: terminal is not fully functional.

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

Kernel: Linux 4.1.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: systemd (via /run/systemd/system)

Versions of packages screen depends on:
ii  libc6  2.19-19
ii  libpam0g   1.1.8-3.1
ii  libtinfo5  6.0+20150810-1

screen recommends no packages.

Versions of packages screen suggests:
pn  iselect | screenie | byobu  none

-- debconf information excluded

Bug#795313: openvpn: CapabilityBoundingSet breaks auth pam plugin

[Matthew Gabeler-Lee]

Package: openvpn
Version: 2.3.7-1
Severity: important

With the update from 2.3.4-5 to 2.3.7-1 (testing), my vpn configurations
using the auth pam plugin broke.

After much digging, I finally isolated this to the addition of the
CapabilityBoundingSet entry in the systemd service definition.  If I comment
that out, everything works again.

I've marked this as important because I suspect the auth pam plugin sees
wide usage, and because the nature of the way that module writes its debug
data and how systemd runs openvpn means that no matter how high you turn the
verbosity in openvpn, you won't actually receive any of the diagnostic data
from the plugin to help figure out what the problem is, and if you run
openvpn on the console, the capabilities limitation isn't applied and the
problem won't appear to debug.

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

Kernel: Linux 4.0.0-2-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: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.57
ii  init-system-helpers1.23
ii  initscripts2.88dsf-59.2
ii  iproute2   4.0.0-1
ii  libc6  2.19-19
ii  liblzo2-2  2.08-1.2
ii  libpam0g   1.1.8-3.1
ii  libpkcs11-helper1  1.11-4
ii  libssl1.0.01.0.2d-1
ii  libsystemd0224-1

Versions of packages openvpn recommends:
pn  easy-rsa  none

Versions of packages openvpn suggests:
ii  openssl 1.0.2d-1
pn  resolvconf  none

-- debconf information excluded

Bug#794477: ruby-mysql2: Unversioned dependency on libmysqlclient18 leads to unusable package in testing

[Matthew Gabeler-Lee]

Package: ruby-mysql2
Version: 0.3.18-1
Severity: important

The contents of the ruby-mysql2 package effectively have a versioned
dependency on libmysqlclient18, but the package itself does not specify a
version dependency.

This leads to the current version of ruby-mysql2 in testing being unusable
until the new version of mysql migrates to testing.  Witness:

Setting up redmine (3.0~20140825-8) ...
Populating database for redmine instance default.
This may take a while.
rake aborted!
Incorrect MySQL client library version! This gem was compiled for 5.6.25 but
the client library is 5.5.43.

If the ruby library is going to complain about the mysql library version,
seems the package dependencies should reflect that.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages ruby-mysql2 depends on:
ii  libc6  2.19-19
ii  libgmp10   2:6.0.0+dfsg-7
ii  libmysqlclient18   5.5.43-0+deb8u1
ii  libruby2.1 2.1.5-3
ii  ruby   1:2.1.5.1
ii  ruby-eventmachine  1.0.7-3
ii  zlib1g 1:1.2.8.dfsg-2+b1

ruby-mysql2 recommends no packages.

ruby-mysql2 suggests no packages.

-- no debconf information


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

Bug#794018: pdns-backend-sqlite3: Default database name offered by dbconfig isn't the proper default

[Matthew Gabeler-Lee]

Package: pdns-backend-sqlite3
Version: 3.4.5-1
Severity: important

Installing pdns-backend-sqlite3 on a server that has never had powerdns
installed before resulted in being presented with bad defaults.

From the source package (and the info extracted from debconf below), it
looks like the default dbname for this backend should be pdns.sqlite3.  But
during the install, the default value provided to the administrator is
instead pdnsbackendsqlite3, which does not match the config file.

This will naturally create some bad results for the naive administrator.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/12 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: systemd (via /run/systemd/system)

Versions of packages pdns-backend-sqlite3 depends on:
ii  dbconfig-common1.8.52
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18
ii  libgcc11:5.1.1-12
ii  libstdc++6 5.1.1-12
ii  pdns-server3.4.5-1
ii  sqlite33.8.10.2-1
ii  ucf3.0030

pdns-backend-sqlite3 recommends no packages.

pdns-backend-sqlite3 suggests no packages.

-- debconf information:
  pdns-backend-sqlite3/internal/reconfiguring: false
  pdns-backend-sqlite3/dbconfig-reinstall: false
* pdns-backend-sqlite3/dbconfig-install: true
  pdns-backend-sqlite3/database-type: sqlite3
* pdns-backend-sqlite3/db/basepath: /var/lib/powerdns
  pdns-backend-sqlite3/passwords-do-not-match:
  pdns-backend-sqlite3/dbconfig-remove: true
* pdns-backend-sqlite3/db/dbname: pdnsbackendsqlite3
  pdns-backend-sqlite3/install-error: abort
  pdns-backend-sqlite3/purge: false
  pdns-backend-sqlite3/missing-db-package-error: abort
  pdns-backend-sqlite3/dbconfig-upgrade: true
  pdns-backend-sqlite3/upgrade-backup: true
  pdns-backend-sqlite3/upgrade-error: abort
  pdns-backend-sqlite3/internal/skip-preseed: false
  pdns-backend-sqlite3/remove-error: abort


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