Bug#918154: python-docker: missing dependency on backports.ssl_match_hostname?
Package: python-docker Version: 3.4.1-3 Severity: normal (Sorry if this is a duplicate, I tried sending with reportbug but I think my MTA ate it...) Freshly installed stretch, dist-upgraded to buster, and then: root@violet:~# apt install python-docker root@violet:~# python Python 2.7.15+ (default, Nov 28 2018, 16:27:22) [GCC 8.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import docker Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/docker/__init__.py", line 2, in from .api import APIClient File "/usr/lib/python2.7/dist-packages/docker/api/__init__.py", line 2, in from .client import APIClient File "/usr/lib/python2.7/dist-packages/docker/api/client.py", line 10, in from .build import BuildApiMixin File "/usr/lib/python2.7/dist-packages/docker/api/build.py", line 6, in from .. import auth File "/usr/lib/python2.7/dist-packages/docker/auth.py", line 9, in from .utils import config File "/usr/lib/python2.7/dist-packages/docker/utils/__init__.py", line 3, in from .decorators import check_resource, minimum_version, update_headers File "/usr/lib/python2.7/dist-packages/docker/utils/decorators.py", line 4, in from . import utils File "/usr/lib/python2.7/dist-packages/docker/utils/utils.py", line 12, in from .. import tls File "/usr/lib/python2.7/dist-packages/docker/tls.py", line 5, in from .transport import SSLAdapter File "/usr/lib/python2.7/dist-packages/docker/transport/__init__.py", line 3, in from .ssladapter import SSLAdapter File "/usr/lib/python2.7/dist-packages/docker/transport/ssladapter.py", line 21, in from backports.ssl_match_hostname import match_hostname ImportError: No module named backports.ssl_match_hostname -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages python-docker depends on: ii python2.7.15-3 ii python-dockerpycreds 0.3.0-1 ii python-ipaddress 1.0.17-1 ii python-requests 2.20.0-2 ii python-six1.12.0-1 ii python-websocket 0.53.0-1 python-docker recommends no packages. python-docker suggests no packages. -- no debconf information
Bug#896921: Salt / tornado incompatibility - new upstream release is out with a fix
Looks like 2018.3.1 is out, and the version installed from upstream's personal repository no longer has the bug :) Specifically, I'm using http://repo.saltstack.com/apt/debian/9/amd64/latest/pool/main/s/salt/ on Buster -- Shish
Bug#893817: salt-common / tornado incompatibility
Discussed upstream at https://github.com/saltstack/salt/issues/45790 - the temporary fix from upstream is to mark salt incompatible with tornado 5, so that the packages won't install to start with https://github.com/saltstack/salt/pull/47106 is a pull request which works on updating the code to be tornado 5 compatible
Bug#839771: collectd-core: collectd graphite plugin is missing libyajl2 dependency
Package: collectd-core Version: 5.6.0-1 Severity: important Dear Maintainer, I ran "apt upgrade", collectd failed to restart, complaining that it didn't understand the graphite section of the config file, because the write_graphite plugin wasn't loaded. It recommended that I tried running lld on the .so file, which I did, and it said that libyajl.so.2 was not found. I ran apt install libyajl2, then it worked. I expect libyajl2 should be marked as recommends rather than suggests, since not having it will break currently working installations? -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages collectd-core depends on: ii debconf [debconf-2.0] 1.5.59 ii init-system-helpers1.45 ii libc6 2.24-3 ii libltdl7 2.4.6-2 Versions of packages collectd-core recommends: ii perl 5.24.1~rc3-3 ii rrdtool 1.6.0-1+b1 Versions of packages collectd-core suggests: pn apache2 pn apcupsd pn bind9 pn ceph pn collectd-dev ii default-jre-headless 2:1.8-57 ii hddtemp 0.3-beta15-52 pn httpd-cgi ii iptables 1.6.0-3 pn ipvsadm pn libatasmart4 pn libconfig-general-perl ii libcurl3-gnutls 7.50.1-1 ii libdbi1 0.9.0-4 pn libesmtp6 pn libganglia1 ii libgcrypt20 1.7.3-1 ii libgdk-pixbuf2.0-0 2.36.0-1 ii libglib2.0-0 2.50.0-1 pn libgps22 pn libhiredis0.13 ii libhtml-parser-perl 3.72-2+b1 ii libip4tc01.6.0-3 ii libip6tc01.6.0-3 ii libldap-2.4-22.4.42+dfsg-2+b3 pn liblua5.3-0 ii liblvm2app2.22.02.164-1 pn libmemcached11 ii libmnl0 1.0.4-1 pn libmodbus5 pn libmosquitto1 ii libmysqlclient18 5.6.30-1 ii libnotify4 0.7.6-2 ii libnspr4 2:4.12-2 ii libnss3 2:3.26-2 ii libopenipmi0 2.0.22-1 pn liboping0 pn libowcapi-3.1-1 ii libpcap0.8 1.7.4-3 ii libperl5.24 5.24.1~rc3-3 ii libpq5 9.6.0-1.pgdg70+1 pn libprotobuf-c1 ii libpython2.7 2.7.12-3 pn librabbitmq4 pn librdkafka1 ii libregexp-common-perl2016060801-1 pn libriemann-client0 ii librrd8 1.6.0-1+b1 pn librrds-perl ii libsensors4 1:3.4.0-3 pn libsigrok2 ii libsnmp305.7.3+dfsg-1.5+b1 ii libssl1.0.2 1.0.2j-1 pn libtokyotyrant3 ii libudev1 231-4 pn libupsclient4 ii liburi-perl 1.71-1 pn libvarnishapi1 pn libvirt0 pn libxen-4.6 ii libxml2 2.9.4+dfsg1-2 ii libyajl2 2.1.0-2 pn lm-sensors pn mbmon ii memcached1.4.28-1 pn mysql-server | virtual-mysql-server ii nginx1.10.1-3 ii nginx-full [nginx] 1.10.1-3+b1 ii notification-daemon 3.20.0-1 pn nut pn olsrd pn openvpn pn pdns-server pn postgresql ii redis-server 3:3.2.4-1 pn slapd pn time-daemon pn varnish ii zlib1g 1:1.2.8.dfsg-2+b1 pn zookeeper -- debconf information excluded
Bug#825394: also mosh
`mosh-server` should be added to the list of processes which should be exempt from this behaviour, as it is based on the principle of "ssh into remote host, start daemon, exit ssh, continue speaking to daemon". As a workaround, I'm running it in a new session explicitly: mosh --server "systemd-run --scope --user mosh-server" $hostname To make this more googlable, the error message which happens when systemd kills mosh-server is: mosh: Nothing received from server on UDP port 60001. [To quit: Ctrl-^ .]
Bug#815366: xdotool segfaults with Xvnc X server
Source: xdotool Severity: normal Dear Maintainer, Using xdotool with Xvnc instead of Xorg, it crashes doing some sort of keymap setup. Not sure if it's because of Xvnc or if the bug is more general, Xvnc is all I have to test with and I assume a 100%-reproducible segfault with Xorg would have been noticed already... Specifically, XkbGetMap on line ~1300 of xdo.c returns null, and the code doesn't handle it. To get it not-crashing, I've made it skip a whole bunch of code if desc is null - this works well enough for me, not sure if it has any negative side effects. (I'm only doing mouse automation, so if this has broken keyboard automation I won't notice) xdo->charcodes = calloc(keycodes_length, sizeof(charcodemap_t)); XkbDescPtr desc = XkbGetMap(xdo->xdpy, XkbAllClientInfoMask, XkbUseCoreKbd); + if(!desc) return; [... a bunch of code acting on desc ...] -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.10.23--std-ipv6-64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system)
Bug#468106: option to suppress 'missing from override file' warning
I've had the same annoyance; and it struck me as silly that the override file be a mandatory argument in the first place, if there are legitimate situations where it isn't needed (the tutorial I was following used /dev/null as a workaround) I've attached a patch which makes the override argument optional, and if it isn't supplied, the warnings about it won't be shown. There's a bit of ugly indent fiddling, but I couldn't see any way around that (Ideally I'd just stick an if around one function call, but there are no functions, the whole script is one monolithic block...) -- Shish scanpackages.diff Description: Binary data
Bug#415098: dbconfig can create tiny random passwords
Package: dbconfig-common Version: 1.8.29+etch1 Severity: minor While I am aware that the password 8 is just as totally random as Af3fS35xF, I feel that it's worryingly close to the beginning of the search space for a brute force attack -- I will confess that I'm no security expert, but might it be a good idea to pass the passwords through something like cracklib to filter out the totally weak ones? The package I noticed this in was nagios-mysql; the first install I did created a nice, long, random looking password. Then I scrapped the install and redid things from scratch, resulting in: #xsddb_host= #xsddb_port= xsddb_database=nagiosmysql xsddb_username=nagios-mysql xsddb_password=8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
