Bug#882050: "service hostapd restart" *kills* hostapd

[Joey Hess]

Andrew Shadura wrote:
> Does your system run systemd or sysvinit? If systemd, what does
> systemctl status hostapd say when after hostapd is killed?

I ran service hostapd restart; systemctl status hostapd and
that one said:

● hostapd.service - LSB: Advanced IEEE 802.11 management daemon
   Loaded: loaded (/etc/init.d/hostapd; generated; vendor preset: enabled)
   Active: active (running) since Sun 2017-11-19 11:05:15 JEST; 67ms ago
 Docs: man:systemd-sysv-generator(8)
  Process: 3494 ExecStop=/etc/init.d/hostapd stop (code=exited, 
status=0/SUCCESS)
  Process: 3498 ExecStart=/etc/init.d/hostapd start (code=exited, 
status=0/SUCCESS)
Tasks: 1 (limit: 4915)
   CGroup: /system.slice/hostapd.service
   └─16142 /usr/sbin/hostapd -B -P /run/hostapd.pid 
/etc/hostapd/hostapd.conf

Nov 19 11:05:15 honeybee systemd[1]: Starting LSB: Advanced IEEE 802.11 
management daemon...
Nov 19 11:05:15 honeybee hostapd[3498]: Starting advanced IEEE 802.11 
management: hostapd.
Nov 19 11:05:15 honeybee systemd[1]: Started LSB: Advanced IEEE 802.11 
management daemon.

However, running systemctl status hostapd a second time after a minute had
changed:

● hostapd.service - LSB: Advanced IEEE 802.11 management daemon
   Loaded: loaded (/etc/init.d/hostapd; generated; vendor preset: enabled)
   Active: active (exited) since Sun 2017-11-19 11:05:15 JEST; 1min 36s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 3494 ExecStop=/etc/init.d/hostapd stop (code=exited, 
status=0/SUCCESS)
  Process: 3498 ExecStart=/etc/init.d/hostapd start (code=exited, 
status=0/SUCCESS)

Nov 19 11:05:15 honeybee systemd[1]: Starting LSB: Advanced IEEE 802.11 
management daemon...
Nov 19 11:05:15 honeybee hostapd[3498]: Starting advanced IEEE 802.11 
management: hostapd.
Nov 19 11:05:15 honeybee systemd[1]: Started LSB: Advanced IEEE 802.11 
management daemon.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#882050: "service hostapd restart" *kills* hostapd

[Joey Hess]

Package: hostapd
Version: 2:2.4-1.1
Severity: normal

Not sure why; /etc/init.d/hostapd restart restarts it successfully.

Saw this on an armhf system running testing.
/etc/default/hostapd contains DAEMON_CONF=/etc/hostapd/hostapd.conf

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#881969: making bootable SD cards

[Joey Hess]

Vagrant Cascadian wrote:
>  u-boot-install --board=Cubietruck --device=/dev/mmcblk0
> 
> u-boot is where the information such as
> supported boot media and device offsets generally comes from, as it
> sometimes changes changes between different versions of u-boot

Verison specificity is another big reason to need this in one place
and not scattered around.

> Doing this would also make me want to split the flash-kernel database
> out into a separate package from the boot script/kernel+initrd copying
> parts of flash-kernel

It would also be useful to be able to query the flash-kernel database
for particular fields to avoid other duplication of info. 
If there were a way to query for the kernel image variant to use for a board,
I could use that in propellor.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#881969: making bootable SD cards

[Joey Hess]

Karsten Merker wrote:
> to use d-i/flash-kernel on the target device, one obviously needs
> to already have put a u-boot onto the device in some form (such
> as preinstalled in the d-i SD card images), otherwise one
> couldn't have booted it

Not necessarily, see for example /target in d-i when the machine has
been booted from other media than the target disk.

As noted in my initial message, d-i does not handle this in all cases,
requiring clumsy warnings on wiki pages to warn the user about its
deficiencies. If flash-kernel provided a way to do it, d-i could easily
to it for at least cases where u-boot is installed on a safe media like
a SD card.

> As a result of these issues, it was deemed unsuitable for
> flash-kernel to attempt installing u-boot.

A separate program included in flash-kernel that looks at the machine
database to determine how to install u-boot and installs it to a
specified device would avoid all of those issues.
That is what I am suggesting.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#882024: allow bind mounting the qemu binaries into a chroot

[Joey Hess]

Package: qemu-user-static
Version: 1:2.10.0+dfsg-2
Severity: wishlist

qemu-debootstrap's approach of copying the host emulation binary into
the chroot is kind of messy. Nothing updates that binary when this
package is upgraded. If the chroot is turned into a bootable disk image
on the target hardware, the binary ought to be deleted, which is an
added complication to deal with.

So I had an idea of moving the qemu static binaries into a subdirectory
someplace. They could still be symlinked to /usr/bin/, but make the
binfmt-misc paths use the subdirectory. Then that subdirectory could be
bind mounted (readonly) into a chroot to make the binaries available
inside it without copying them.

Downside is that the bind mount would need to be set up on boot,
or when the chroot is used, so the current copying might need to remain
the default, and an option to do a cleaner bind mount added to
qemu-debootstrap.

(Of course, many user of chroots require mounting other stuff into them
eg /proc, so this would just be one more thing to mount.) 

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

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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.8-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.21p2-2

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#881969: making bootable SD cards

[Joey Hess]

Package: flash-kernel
Version: 3.87
Severity: normal

  Therefore you usually have to setup an SD card with the appropriate u-boot
  version for your particular device (see below) as a prerequisite for
  installing Debian. If you use the pre-made SD card images with the
  installer, this step is not necessary, as these images already contain
  u-boot.
  -- https://wiki.debian.org/InstallingDebianOn/Allwinner

This seems to fall squarely in flash-kernel's wheelhouse, since it
already handles the other parts of u-boot installation, and it knows
the name of the board being installed.

The d-i SD card images avoid the problem, but they are only one way to
install; there are even other ways to use d-i to install that need this
manual step first.

The main difficulty in putting it in flash-kernel is that it might be
installed in a chroot in a situation where it should not be altering
the boot sector of the host's disk. So, something like grub-installer
seems to be called for, so the user specifies the device to install to.

A utility in flash-kernel would be much nicer than needing to puzzle out dd
commands from README.Debian files and hope you got it right. I'm currently
having to embed those dd commands inside propellor; they're also embedded
inside debian-installer (build/boot/arm/u-boot-image-config).

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

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

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#881280: update for zsh and fish completions

[Joey Hess]

Package: libghc-optparse-applicative-dev
Version: 0.13.2.0-1+b1
Severity: normal

Version 0.14 added support for zsh and fish completion. git-annex
uses that feature.

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

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

Versions of packages libghc-optparse-applicative-dev depends on:
ii  ghc [libghc-transformers-dev-0.5.2.0-1d020]8.0.2-10
ii  libc6  2.24-17
ii  libghc-ansi-wl-pprint-dev [libghc-ansi-wl-pprint-dev-0.6.  0.6.7.3-3+b3
pn  libghc-base-dev-4.9.1.0-d28d6  
pn  libghc-process-dev-1.4.3.0-996f5   
ii  libghc-transformers-compat-dev [libghc-transformers-compa  0.5.1.4-2+b1
ii  libgmp10   2:6.1.2+dfsg-1.1

libghc-optparse-applicative-dev recommends no packages.

Versions of packages libghc-optparse-applicative-dev suggests:
ii  libghc-optparse-applicative-doc   0.13.2.0-1
ii  libghc-optparse-applicative-prof  0.13.2.0-1+b1

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#879723: can get stuck in state INSANE and stop responding

[Joey Hess]

Package: netplug
Version: 1.2.9.2-3
Severity: normal

If the netplug script fails to bring up the interface, netplug can
put it into state INSANE. Unfortunately, it never leaves that state,
preventing netplug from responding to further link changes.

This log shows the problem occurring. Probably the link was lost while
the dhclient was trying to up the interface. It remained in state INSANE
for hours, and the daemon had to be restarted to clear it up.

Oct 24 11:36:30 honeybee netplugd[650]: eth0: state INACTIVE flags 0x1003 
UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,1
Oct 24 11:36:30 honeybee netplugd[2115]: /etc/netplug/netplug eth0 in -> pid 
2115
Oct 24 11:36:30 honeybee dhclient[2132]: Internet Systems Consortium DHCP 
Client 4.3.5
Oct 24 11:36:30 honeybee dhclient[2132]: Copyright 2004-2016 Internet Systems 
Consortium.
Oct 24 11:36:30 honeybee dhclient[2132]: All rights reserved.
Oct 24 11:36:30 honeybee dhclient[2132]: For info, please visit 
https://www.isc.org/software/dhcp/
Oct 24 11:36:30 honeybee dhclient[2132]: 
Oct 24 11:36:30 honeybee dhclient[2132]: Listening on LPF/eth0/02:93:05:81:f2:aa
Oct 24 11:36:30 honeybee dhclient[2132]: Sending on   LPF/eth0/02:93:05:81:f2:aa
Oct 24 11:36:30 honeybee dhclient[2132]: Sending on   Socket/fallback
Oct 24 11:36:30 honeybee dhclient[2132]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 3
Oct 24 11:36:33 honeybee dhclient[2132]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 5
Oct 24 11:36:39 honeybee dhclient[2132]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 7
Oct 24 11:36:46 honeybee dhclient[2132]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 14
Oct 24 11:37:00 honeybee dhclient[2132]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 21
Oct 24 11:37:20 honeybee netplugd[650]: eth0: state INNING pid 2115 exited 
status 256
Oct 24 11:39:27 honeybee netplugd[650]: eth0: state INSANE flags 0x00011043 
UP,BROADCAST,RUNNING,MULTICAST,1 -> 0x1003 UP,BROADCAST,MULTICAST
Oct 24 11:39:28 honeybee netplugd[650]: eth0: state INSANE flags 0x1003 
UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,1
Oct 24 11:39:38 honeybee netplugd[650]: eth0: state INSANE flags 0x00011043 
UP,BROADCAST,RUNNING,MULTICAST,1 -> 0x1003 UP,BROADCAST,MULTICAST
Oct 24 11:39:40 honeybee netplugd[650]: eth0: state INSANE flags 0x1003 
UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,1
Oct 24 22:40:43 honeybee netplugd[650]: eth0: state INSANE flags 0x00011043 
UP,BROADCAST,RUNNING,MULTICAST,1 -> 0x1003 UP,BROADCAST,MULTICAST
Oct 24 23:37:30 honeybee netplugd[650]: eth0: state INSANE flags 0x1003 
UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,1
Oct 24 23:37:55 honeybee netplugd[650]: eth0: state INSANE flags 0x00011043 
UP,BROADCAST,RUNNING,MULTICAST,1 -> 0x1003 UP,BROADCAST,MULTICAST
Oct 24 23:37:56 honeybee netplugd[650]: eth0: state INSANE flags 0x1003 
UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,1
Oct 24 23:39:35 honeybee netplugd[650]: eth0: state INSANE flags 0x00011043 
UP,BROADCAST,RUNNING,MULTICAST,1 -> 0x1003 UP,BROADCAST,MULTICAST
Oct 24 23:39:37 honeybee netplugd[650]: eth0: state INSANE flags 0x1003 
UP,BROADCAST,MULTICAST -> 0x00011043 UP,BROADCAST,RUNNING,MULTICAST,1

In if_info.c, line 351, this code gets it into INSANE:

case ST_INNING:
if (exitok)
info->state = ST_ACTIVE;
else
info->state = ST_INSANE; /* ??? */
break;

There is no way out of INSANE once entered. ifsm_flagchange, there is this:

case ST_INSANE:
/* stay insane until there's been quiet for a while, then
   down interface and switch to ST_DOWN */
break;

That might be the right place to fix it, but as far as I can see, there's
no code following through on that comment.

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

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

Versions of packages netplug depends on:
ii  iproute   1:4.9.0-2
ii  iproute2  4.9.0-2
ii  libc6 2.24-17
ii  lsb-base  9.20170808

netplug recommends no packages.

netplug suggests no packages.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#874321: backtraces from generic extractor: "Compressed file ended before the end-of-stream marker was reached"

[Joey Hess]

Rogério Brito wrote:
> I believe that you meant to file this as a Python bug and I think that the
> severity is, quite frankly, lower than normal...

I don't think this is a python bug. It's reasonable for pythons's gzip
library to fail when presented with corrupted data. It does not know
it's being used to download an url. Perhaps it should have a mode where
it tries to extract as much data is it can, in case its caller wants to
try to be robust.

I think this is a bug in youtube-dl though, because of this code:

std_headers = {
...
'Accept-Encoding': 'gzip, deflate',
}

if resp.headers.get('Content-encoding', '') == 'gzip':
content = resp.read()
gz = gzip.GzipFile(fileobj=io.BytesIO(content), mode='rb')
try:
uncompressed = io.BytesIO(gz.read())
except IOError as original_ioerror:
# There may be junk add the end of the file
# See http://stackoverflow.com/q/4928560/35070 for details
for i in range(1, 1024):
try:
gz = gzip.GzipFile(fileobj=io.BytesIO(content[:-i]), 
mode='rb')
uncompressed = io.BytesIO(gz.read())
except IOError:
continue
break
else:
raise original_ioerror

It's encouraging gzip to be used (rather than deflate or no compression),
and it already contains workarounds for similar problems. This code
smells.

There is probably a python library that implements this robustly.
I tried python-urllib3:

joey@darkstar:~>python
Python 2.7.14 (default, Sep 17 2017, 18:50:44) 
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib3
>>> http = urllib3.PoolManager()
>>> headers = {'Accept-Encoding': 'gzip'}
>>> r = http.request('GET', 'http://www.debian.org/', headers=headers)
>>> r.headers.get("Content-Encoding")
'gzip'
>>> len(r.data)
14871

So that seems to work. I think because it uses zlib to decompress the data,
not gzip.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#877256: stack is too old to use current nightlies

[Joey Hess]

Package: haskell-stack
Version: 1.1.2-8
Severity: normal

joey@darkstar:~/src/git-annex> git diff
diff --git a/stack.yaml b/stack.yaml
index d40b53ee9..afde86b0d 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -23,4 +23,4 @@ extra-deps:
 - yesod-default-1.2.0
 explicit-setup-deps:
   git-annex: true
-resolver: lts-8.13
+resolver: nightly-2017-09-29
joey@darkstar:~/src/git-annex> stack setup
Unable to parse cabal file: FromString "This package requires at least Cabal 
version 2.0" Nothing

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

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

Versions of packages haskell-stack depends on:
ii  ca-certificates  20170717
ii  gcc  4:7.2.0-1d1
ii  libc62.24-17
ii  libffi6  3.2.1-6
ii  libgmp-dev   2:6.1.2+dfsg-1
ii  libgmp10 2:6.1.2+dfsg-1
ii  libsqlite3-0 3.20.1-1
ii  libyaml-0-2  0.1.7-2
ii  make 4.1-9.1
ii  xz-utils 5.2.2-1.3
ii  zlib1g   1:1.2.8.dfsg-5

haskell-stack recommends no packages.

haskell-stack suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#874321: backtraces from generic extractor: "Compressed file ended before the end-of-stream marker was reached"

[Joey Hess]

Package: youtube-dl
Version: 2017.05.18.1-1
Severity: normal

joey@darkstar:~>youtube-dl  http://debian.org/
[generic] debian: Requesting header
[redirect] Following redirect to http://www.debian.org/
[generic] www.debian: Requesting header
WARNING: Falling back on generic information extractor.
[generic] www.debian: Downloading webpage
Traceback (most recent call last):
  File "/usr/bin/youtube-dl", line 11, in 
load_entry_point('youtube-dl==2017.5.18.1', 'console_scripts', 
'youtube-dl')()
  File "/usr/lib/python3/dist-packages/youtube_dl/__init__.py", line 465, in 
main
_real_main(argv)
  File "/usr/lib/python3/dist-packages/youtube_dl/__init__.py", line 455, in 
_real_main
retcode = ydl.download(all_urls)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 1896, in 
download
url, force_generic_extractor=self.params.get('force_generic_extractor', 
False))
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 771, in 
extract_info
return self.process_ie_result(ie_result, download, extra_info)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 832, in 
process_ie_result
extra_info=extra_info)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 760, in 
extract_info
ie_result = ie.extract(url)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 
433, in extract
ie_result = self._real_extract(url)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/generic.py", line 
1942, in _real_extract
full_response = self._request_webpage(request, video_id)
  File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py", line 
502, in _request_webpage
return self._downloader.urlopen(url_or_request)
  File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line 2106, in 
urlopen
return self._opener.open(req, timeout=self._socket_timeout)
  File "/usr/lib/python3.5/urllib/request.py", line 472, in open
response = meth(req, response)
  File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 981, in 
http_response
uncompressed = io.BytesIO(gz.read())
  File "/usr/lib/python3.5/gzip.py", line 274, in read
return self._buffer.read(size)
  File "/usr/lib/python3.5/gzip.py", line 480, in read
raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached

I'm able to reproduce this over an Excede satelite internet connection,
but not from a VPS. There's some transparent proxying involved,
which is apparently confusing the gzip Content-encoding support in
youtube-dl. (I have not seen the transparent proxying cause any
other problems with other programs.) Only http urls cause the problem,
since https bypasses the transparent proxy.

I edited the code to dump out the gzip compressed content it received
before it trys to decompress it.

joey@darkstar:~>file dump
dump: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
joey@darkstar:~>ls -l dump
-rw-r--r-- 1 joey joey 4744 Sep  4 21:00 dump
joey@darkstar:~>zcat < dump > data
gzip: stdin: unexpected end of file
joey@darkstar:~>curl --compressed -so raw http://www.debian.org/
joey@darkstar:~>cmp data raw
joey@darkstar:~>

So, it's apparently downloaded a gzip compressed chunk of data
which contains the whole url, but the gzip data is somehow shady,
although not in a way that prevents decompressing the whole page
content. I've attached the `dump` file to this bug report.

I've also attached a `wireshark.pcapng` which has the curl traffic
first followed by youtube-dl.

I suspect that the gzip compressed data has a missing gzip footer.
Normally, the last 8 bytes of `dump` would be the gzip footer. Those are:
93 C6 FF 00 00 00 FF FF
If that were a footer, the size would be  which is not the
actual size. And, changing any of these bytes except for the last one
exposes parts of the compression dictionary, so they must not be
part of the footer, and seem to instead be part of the DEFLATE data.

Similarly, looking at the http response to curl, 
the last 8 bytes of that are
9D 7B D7 66 E6 3B 00 00
Which again does not look like a gzip footer.

curl seems to follow Postel's law in handling this, so perhaps youtube-dl
should too?

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

Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages youtube-dl depends on:
ii  dpkg   1.18.24
ii  python33.5.3-3
ii  python3-pkg-resources  36.2.7-2

Versions of packages youtube-dl recommends:
ii  aria21.32.0-1
ii  ca-certificates  20170717
ii  curl 7.55.1-1
ii 

Bug#873115: Acknowledgement (concurrent apache2 -k graceful hang)

[Joey Hess]

Seems similar to #779077. mod_fcgid is not enabled on our server.
Regular cgi scripts are in use and one is quite likely running when
apache is reloaded. Using mpm_worker.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#873115: concurrent apache2 -k graceful hang

[Joey Hess]

Package: apache2
Version: 2.4.25-3+deb
Severity: normal

I woke up to a server with hundreds of apach2e -k graceful processes running.
This prevented any cgis from running since it was nearly out of process slots.

 2142 ?SNs0:01 /usr/sbin/apache2 -k graceful
 6007 ?SN 0:00  \_ /usr/sbin/apache2 -k graceful
 4680 ?SNl0:00  \_ /usr/sbin/apache2 -k graceful
 2217 ?SNs0:01 /usr/sbin/apache2 -k graceful
 7127 ?SN 0:00  \_ /usr/sbin/apache2 -k graceful
 2542 ?SNl0:00  \_ /usr/sbin/apache2 -k graceful
 2177 ?SNs0:01 /usr/sbin/apache2 -k graceful
 6748 ?SN 0:00  \_ /usr/sbin/apache2 -k graceful
 4189 ?SNl0:00  \_ /usr/sbin/apache2 -k graceful
 2214 ?SNs0:01 /usr/sbin/apache2 -k graceful
 6738 ?SN 0:00  \_ /usr/sbin/apache2 -k graceful
 3023 ?SNl0:00  \_ /usr/sbin/apache2 -k graceful

This was just after an upgrade from oldstable the day before.

I'm at this point not quite sure what reloaded apache multiple times,
but it was probably a cron job reloading it once per vhost or something
like that.

Running a single apache2ctl graceful did not result in any such stuck
processes. I was able to reproduce the basic problem thus:

apache2ctl graceful & apache2ctl graceful & apache2ctl graceful

With 3 running concurrently, they get in each other's way.

Output to the console looked like this:

pell:/# apache2ctl graceful & apache2ctl graceful  & apache2ctl graceful
[1] 15772
[2] 15773
httpd not running, trying to start
httpd not running, trying to start
httpd not running, trying to start
[1]-  Doneapache2ctl graceful
pell:/# 
[2]+  Doneapache2ctl graceful
pell:/# 
pell:/# ps -fax |grep graceful
16120 pts/0S+ 0:00   \_ grep graceful
15788 ?Ss 0:00 /usr/sbin/apache2 -k graceful
15790 ?S  0:00  \_ /usr/sbin/apache2 -k graceful
15795 ?Sl 0:00  \_ /usr/sbin/apache2 -k graceful
15796 ?Sl 0:00  \_ /usr/sbin/apache2 -k graceful
15789 ?Ss 0:00 /usr/sbin/apache2 -k graceful
15901 ?S  0:00  \_ /usr/sbin/apache2 -k graceful
15903 ?Sl 0:00  \_ /usr/sbin/apache2 -k graceful
15904 ?Sl 0:00  \_ /usr/sbin/apache2 -k graceful
15794 ?Ss 0:00 /usr/sbin/apache2 -k graceful
15902 ?S  0:00  \_ /usr/sbin/apache2 -k graceful
16010 ?Sl 0:00  \_ /usr/sbin/apache2 -k graceful

What are the stuck processes doing? Waiting on something..

pell:/# strace -p 15794
strace: Process 15794 attached
_newselect(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=762363}) = 0 (Timeout)
waitpid(-1, 0xbfce1210, WNOHANG|WSTOPPED) = 0
_newselect(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout)
waitpid(-1, 0xbfce1210, WNOHANG|WSTOPPED) = 0
pell:/# strace -p 15902
strace: Process 15902 attached
accept(4,  ^C
pell:/# ls -l /proc/15902/fd/4
lrwx-- 1 root root 64 Aug 24 16:18 /proc/15902/fd/4 -> socket:[2396130]
pell:/# strace -p 16010
strace: Process 16010 attached
read(7,^C
pell:/# ls -l /proc/16010/fd/7
lr-x-- 1 root root 64 Aug 24 16:18 /proc/16010/fd/7 -> pipe:[2401595]

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#872278: setResponseTimeout Nothing has silently changed behavior with http-client 0.5.0

[Joey Hess]

Package: libghc-dav-dev
Version: 1.3.1-2+b5
Severity: normal

Proir to http-client 0.5.0, setResponseTimeout Nothing disabled the
timeout entirely. However with http-client 0.5.0, setResponseTimeout Nothing
sets responseTimeout = responseTimeoutDefault, which is 30 seconds.

I want to entirely disable the timeout. I could use setResponseTimeout
(Just maxBound), and that would work ok on 64 bit; Int is large enough
that this would make the timeout years long. But on 32 bit, it would be
only a couple of minutes.

Please consider this patch to make the behavior consistent and allow
entirely disabling the timout again.

- setResponseTimeout rt = baseRequest %= \x -> x { responseTimeout = maybe 
responseTimeoutDefault responseTimeoutMicro rt }
+ setResponseTimeout rt = baseRequest %= \x -> x { responseTimeout = maybe 
responseTimeoutNone responseTimeoutMicro rt }

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

Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libghc-dav-dev depends on:
ii  ghc [libghc-transformers-dev-0.5.2.0-1d020]  8.0.2-5
ii  libc62.24-14
pn  libghc-base-dev-4.9.1.0-d28d6
pn  libghc-bytestring-dev-0.10.8.1-45b2c 
ii  libghc-case-insensitive-dev [libghc-case-insensitive-dev-1.  1.2.0.10-1+b1
pn  libghc-containers-dev-0.5.7.1-cd211  
ii  libghc-data-default-dev [libghc-data-default-dev-0.7.1.1-bf  0.7.1.1-2+b2
ii  libghc-exceptions-dev [libghc-exceptions-dev-0.8.3-5fa88]0.8.3-4
ii  libghc-http-client-dev [libghc-http-client-dev-0.5.7.0-8bd7  0.5.7.0-1+b3
ii  libghc-http-client-tls-dev [libghc-http-client-tls-dev-0.3.  0.3.5.1-1+b3
ii  libghc-http-types-dev [libghc-http-types-dev-0.9.1-0f9fc]0.9.1-3+b5
ii  libghc-lens-dev [libghc-lens-dev-4.15.1-54553]   4.15.1-1
ii  libghc-mtl-dev [libghc-mtl-dev-2.2.1-1a6c5]  2.2.1-5+b1
ii  libghc-transformers-base-dev [libghc-transformers-base-dev-  0.4.4-6+b1
ii  libghc-transformers-compat-dev [libghc-transformers-compat-  0.5.1.4-2+b1
ii  libghc-utf8-string-dev [libghc-utf8-string-dev-1.0.1.1-9093  1.0.1.1-4+b2
ii  libghc-xml-conduit-dev [libghc-xml-conduit-dev-1.3.5-4eb5c]  1.3.5-3+b7
ii  libghc-xml-hamlet-dev [libghc-xml-hamlet-dev-0.4.1-b7697]0.4.1-1+b3
ii  libgmp10 2:6.1.2+dfsg-1
ii  zlib1g   1:1.2.8.dfsg-5

libghc-dav-dev recommends no packages.

Versions of packages libghc-dav-dev suggests:
ii  libghc-dav-doc   1.3.1-2
pn  libghc-dav-prof  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#872187: package description unclear about API breaking version numbers

[Joey Hess]

Source: borgbackup
Version: 1.0.11-3
Severity: normal

 Please note that the server and the client should be on the same
 version of borgbackup. Using different versions of borgbackup on
 client and server might result in 'incompatible API version' error
 messages and a non-working backup.

Could this happen between any two versions even if only the minor
version changed? It's not clear. I found this in the documentation:

EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE
NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).

Which seems to suggest that the API version change would only affect
major version number changes, but I'm not clear if it's talking about
the same kind of API mismatch.

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

Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#869843: Jul 26 19:37:49 honeybee dnsmasq[31624]: sed: -e expression #1, char 103: Invalid range end

[Joey Hess]

Source: dnsmasq
Severity: normal
Version: 2.77-2

Noticed the subject message in the journal. It does not seem to break 
basic functionality. Probably caused by the sed in the init script.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#844056: hard coded mac address

[Joey Hess]

My cubietruck needs this file for wifi to work. However, the MAC address
hardcoded in the file is not used.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#867408: upgrade logged me out, stopped network-manager; kernel: dbus-daemon[650]: segfault at 0 ip 0000562c3192e620 sp 00007ffd9c679798 error 6 in dbus-daemon

[Joey Hess]

Simon McVittie wrote:
> On Thu, 06 Jul 2017 at 09:58:35 -0400, Joey Hess wrote:
> > I ran apt-get dist-upgrade to unstable today
> 
> What state were you upgrading from?
> 
> What version of `dbus-daemon --system` was running on your system? Your
> apt logs might help to work this out - it will be whatever version was
> present during the most recent boot before the problematic upgrade.
> 
> I would also like to know the sequence of upgrades of the dbus package
> since that boot (again, please look in your apt logs).

Last boot was 2017-06-06 16:45:08.

2017-05-30 15:20:42 trigproc dbus:amd64 1.10.18-1 
2017-05-30 15:20:42 status half-configured dbus:amd64 1.10.18-1
2017-05-30 15:20:42 status installed dbus:amd64 1.10.18-1
2017-06-11 10:45:07 status triggers-pending dbus:amd64 1.10.18-1
2017-06-11 10:45:07 status triggers-pending dbus:amd64 1.10.18-1
2017-06-11 10:47:44 trigproc dbus:amd64 1.10.18-1 
2017-06-11 10:47:44 status half-configured dbus:amd64 1.10.18-1
2017-06-11 10:47:44 status installed dbus:amd64 1.10.18-1
2017-06-22 16:55:10 status triggers-pending dbus:amd64 1.10.18-1
2017-06-30 14:50:01 upgrade dbus:amd64 1.10.18-1 1.10.20-1
2017-06-30 14:59:53 configure dbus:amd64 1.10.20-1 
 
-- 
see shy jo


signature.asc
Description: PGP signature

Bug#867408: upgrade logged me out, stopped network-manager; kernel: dbus-daemon[650]: segfault at 0 ip 0000562c3192e620 sp 00007ffd9c679798 error 6 in dbus-daemon

[Joey Hess]

Simon McVittie wrote:
> On Thu, 06 Jul 2017 at 09:58:35 -0400, Joey Hess wrote:
> > Jul 06 09:16:38 darkstar dbus[650]: [system] Unable to reload 
> > configuration: (null)
> > Jul 06 09:16:38 darkstar dbus-daemon[650]: Unable to reload configuration: 
> > (null)
> > Jul 06 09:16:39 darkstar systemd[1]: dbus.service: Main process exited, 
> > code=killed, status=11/SEGV
> 
> Huh, weird. Do you have any unusual/local/non-standard configuration in
> /etc/dbus-1/system.conf, /etc/dbus-1/system.d/*.conf,
> /etc/dbus-1/system-local.conf or /usr/share/dbus-1/system.d/*.conf?

I've listed all modified conffiles on my system, and none of them are
in those directories. I have no files in those directories not provided
by debian packages. Attached a tarball of /etc/dbus-1/

> > Jul 06 09:16:39 darkstar kernel: dbus-daemon[650]: segfault at 0 ip 
> > 562c3192e620 sp 7ffd9c679798 error 6 in dbus-daemon 
> > (deleted)[562c31912000+
> 
> I don't suppose you have a core or backtrace for this, from corekeeper
> or systemd-coredump or similar?

Sadly not. Seems likely this is the same null pointer shown in the
"Unable to reload configuration: (null)" though..

-- 
see shy jo


etc-dbus-1.tar.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#867408: upgrade logged me out, stopped network-manager; kernel: dbus-daemon[650]: segfault at 0 ip 0000562c3192e620 sp 00007ffd9c679798 error 6 in dbus-daemon

[Joey Hess]

Package: dbus
Version: 1.10.20-1
Severity: normal

I ran apt-get dist-upgrade to unstable today from a xfce4-terminal
and at some point in the upgrade the entire X session uncerimoniously
ended, losing anything I was working on at the time and dumping me back
into the lightdm login screen.

When I logged back in, I noticed that network-manager was not running
any longer, and that the apt-get dist-upgrade was still running,
apparently not connected to any terminal. After a while it appeared to
stall out at a conffile prompt.

I killed the dpkg process and ran apt-get -f install, and completed the
upgrade. network-manager remained not running until I manually started
it.

Here's the journal from when network-manager died:

Jul 06 09:16:39 darkstar NetworkManager[21505]:   [1499346999.1047] 
bus-manager: disconnected by the system bus
Jul 06 09:16:39 darkstar NetworkManager[21505]:   [1499346999.5461] 
caught SIGTERM, shutting down normally.

Here's lightdm restarting:

Jul 06 09:16:39 darkstar lightdm[832]: Failed to get D-Bus connection
Jul 06 09:16:39 darkstar systemd[1]: lightdm.service: Main process exited, 
code=exited, status=1/FAILURE
Jul 06 09:16:43 darkstar systemd[1]: lightdm.service: Unit entered failed state.
Jul 06 09:16:43 darkstar systemd[1]: lightdm.service: Triggering OnFailure= 
dependencies.
Jul 06 09:16:43 darkstar systemd[1]: lightdm.service: Failed with result 
'exit-code'.
Jul 06 09:16:43 darkstar systemd[1]: lightdm.service: Service hold-off time 
over, scheduling restart.
Jul 06 09:16:43 darkstar systemd[1]: Stopped Light Display Manager.
Jul 06 09:16:43 darkstar systemd[1]: Starting Light Display Manager...
Jul 06 09:16:43 darkstar systemd[1]: Started Light Display Manager.

Here's closer to the root cause, where dbus died:

Jul 06 09:16:38 darkstar dbus[650]: [system] Unable to reload configuration: 
(null)
Jul 06 09:16:38 darkstar dbus-daemon[650]: Unable to reload configuration: 
(null)
Jul 06 09:16:39 darkstar systemd[1]: dbus.service: Main process exited, 
code=killed, status=11/SEGV
Jul 06 09:16:39 darkstar systemd[1]: dbus.service: Unit entered failed state.
Jul 06 09:16:39 darkstar systemd[1]: dbus.service: Failed with result 
'exit-code'.
Jul 06 09:16:39 darkstar systemd[1]: Started D-Bus System Message Bus.

Here's the dpkg.log around the same time:

2017-07-06 09:16:37 startup packages configure
2017-07-06 09:16:37 configure libudev1:amd64 233-10 
2017-07-06 09:16:37 status unpacked libudev1:amd64 233-10
2017-07-06 09:16:37 status half-configured libudev1:amd64 233-10
2017-07-06 09:16:37 status installed libudev1:amd64 233-10
2017-07-06 09:16:37 configure libudev1:i386 233-10 
2017-07-06 09:16:37 status unpacked libudev1:i386 233-10
2017-07-06 09:16:38 status half-configured libudev1:i386 233-10
2017-07-06 09:16:38 status installed libudev1:i386 233-10
2017-07-06 09:16:38 startup archives unpack
2017-07-06 09:16:38 upgrade bluez:amd64 5.43-2 5.45-1
2017-07-06 09:16:38 status half-configured bluez:amd64 5.43-2
2017-07-06 09:16:38 status unpacked bluez:amd64 5.43-2
2017-07-06 09:16:38 status half-installed bluez:amd64 5.43-2
2017-07-06 09:16:38 status triggers-pending dbus:amd64 1.10.20-1
2017-07-06 09:16:38 status triggers-pending systemd:amd64 233-9
2017-07-06 09:16:39 status triggers-pending dbus:amd64 1.10.20-1
2017-07-06 09:16:39 status half-installed bluez:amd64 5.43-2
2017-07-06 09:16:39 status unpacked bluez:amd64 5.45-1
2017-07-06 09:16:39 status unpacked bluez:amd64 5.45-1

Here's the whole system journal in the minute in question:

Jul 06 09:16:24 darkstar systemd[1]: Reloading.
Jul 06 09:16:24 darkstar systemd[1]: Configuration file 
/etc/systemd/system/postfix.service.d/override.conf is marked 
world-inaccessible. This has no e
Jul 06 09:16:24 darkstar systemd[1]: Configuration file 
/etc/systemd/system/opendkim.service.d/override.conf is marked 
world-inaccessible. This has no 
Jul 06 09:16:25 darkstar systemd[1]: Reloading.
Jul 06 09:16:26 darkstar systemd[1]: Configuration file 
/etc/systemd/system/postfix.service.d/override.conf is marked 
world-inaccessible. This has no e
Jul 06 09:16:26 darkstar systemd[1]: Configuration file 
/etc/systemd/system/opendkim.service.d/override.conf is marked 
world-inaccessible. This has no 
Jul 06 09:16:26 darkstar systemd[1]: Starting Daily apt download activities...
Jul 06 09:16:26 darkstar systemd[1]: Stopped Daily apt upgrade and clean 
activities.
Jul 06 09:16:26 darkstar systemd[1]: Stopping Daily apt upgrade and clean 
activities.
Jul 06 09:16:26 darkstar systemd[1]: Started Daily apt upgrade and clean 
activities.
Jul 06 09:16:26 darkstar systemd[1]: Stopped Daily apt download activities.
Jul 06 09:16:26 darkstar systemd[1]: Stopping Daily apt download activities.
Jul 06 09:16:26 darkstar systemd[1]: Started Daily apt download activities.
Jul 06 09:16:26 darkstar systemd[1]: Started Daily apt download activities.
Jul 06 09:16:38 darkstar dbus[650]: [system] Unable to reload configuration: 
(null)
Jul 06 09:16:38 

Bug#865705: assword gui does not appear when key is expired

[Joey Hess]

Package: assword
Version: 0.10-2
Severity: normal

When the gpg key used to sign the assword database has expired,
assword gui does not display any indication of the problem,
except to stderr. When it's bound to a key, the user has no way to know
what's wrong unless they think to look in the logs.

Suggestion: If there's a gpg error, display the error in a dialog box.

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

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

Versions of packages assword depends on:
ii  python3  3.5.3-1
ii  python3-gi   3.22.0-2
ii  python3-gpg  1.8.0-3+b2

Versions of packages assword recommends:
ii  gir1.2-gtk-3.0  3.22.12-1
ii  python3-xdo 0.4-1
ii  xclip   0.12+svn84-4+b1

assword suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#864530: uuid parsing accepts invalid UUIDs, with potential security consequences

[Joey Hess]

Package: uuid
Version: 1.6.2-1.5+b4
Severity: normal

joey@darkstar:~>uuid -d 4eb841ca-ce98-4590-8ea2-c4643bfa537bad
encode: STR: 4eb841ca-ce98-4590-8ea2-c4643bfa537b
SIV: 104636500717844908867795278139605275515
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 4 (random data based)
content: 4E:B8:41:CA:CE:98:05:90:0E:A2:C4:64:3B:FA:53:7B
 (no semantics: random data only)

So that's a valid UUID, isn't it? Except no, it's not, it's two bytes too long.

It could be that the parser is lenient to allow delimiters or something:

joey@darkstar:~>uuid -d 4eb841ca-ce98-4590-8ea2-c4643bfa537b,
encode: STR: 4eb841ca-ce98-4590-8ea2-c4643bfa537b
SIV: 104636500717844908867795278139605275515
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 4 (random data based)
content: 4E:B8:41:CA:CE:98:05:90:0E:A2:C4:64:3B:FA:53:7B
 (no semantics: random data only)

The libossp-uuid-perl library behaves the same, so the ossp-uuid library
is the root cause.

joey@darkstar:~>perl -le 'use OSSP::uuid; my $uuid = OSSP::uuid->new; 
$uuid->import("str", "4eb841ca-ce98-4590-8ea2-c4643bfa537bad"); print 
$uuid->export("str")'
4eb841ca-ce98-4590-8ea2-c4643bfa537b

This could potentially expose users of the ossp-uuid library to
security holes. Two potential ways this could have security ramifications:

* If a fixed size buffer is allocated to hold a UUID, and ossp-uuid is used
  to verify user input is a valid UUID before it's copied into the buffer.
* If a frontend system uses ossp-uuid to parse user input UUIDs, and a backend
  system uses a more strict UUID library (such as the haskell UUID library),
  the backend could be fed data that it will reject, causing the frontend
  to run unusual code paths.

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

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

Versions of packages uuid depends on:
ii  libc6   2.24-11
ii  libossp-uuid16  1.6.2-1.5+b4

uuid recommends no packages.

uuid suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#864507: patch: support bash completion for add-on git commands

[Joey Hess]

7SKgPUi+h5okRafG+i0Y65RlM49f4k9jFoJ43oU0F3p4k3npGYsM3Tef
	 OwtYrGNA0M4+15XcBl0yKMcBSpRIFfj9hI2uoLgg=
Date:	Thu, 16 Jul 2015 13:22:34 -0400
From:	Joey Hess <j...@joeyh.name>
To:	g...@vger.kernel.org
Subject: [PATCH] support bash completion for add-on commands
Message-ID: <20150716172234.ga3...@kitenet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Status: No, score=-3.1 required=10.0 tests=BAYES_00,DKIM_SIGNED,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,
	RP_MATCHES_RCVD,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no
	version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on kite.kitenet.net
Sender:	git-ow...@vger.kernel.org
Precedence: bulk
List-ID: 
X-Mailing-List:	g...@vger.kernel.org
Status: RO
Content-Length: 2689
Lines: 62

This makes it possible to implement bash completion for add-on commands,
that will work even when the bash completion scripts are being loaded
on-demand, as is done by the bash-completion package.

git's bash completion handles subcommands by running a _git_$command
function. As well as the many such functions included in
git-completion.bash, there can be other functions defined elsewhere
to support third-party add-on git commands, and they'll happily be used.

But, bash completion scripts are often loaded on demand, as shown in the
completion_loader example in bash's man page, and the bash-completion
implementation that is commonly used on many Linux systems. The demand
loading will load this very script from some place like
/usr/share/bash-completion/completions/git, when the user complete a git
command. But, completion scripts for git add-on commands don't get loaded.

For example, when I wrote a git-annex bash completion script,
bash was unable to tab complete "git annex foo", until I tab completed a
"git-annex" command. Which loaded the git-annex completion, and then
that same completion worked to make "git annex foo" tab complete. An
inconsistent UI..

So, if the git completion script is unable to find the wanted
_git_$command function, have it fall-back to looking for a git-$command
completion script, and loading it. The add-on script is looked for in the
same directory as the git completion script, which we can find by looking
at BASH_SOURCE.

Signed-off-by: Joey Hess <jo...@joeyh.name>
---
 contrib/completion/git-completion.bash | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c97c648..ba91b2a 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2614,7 +2614,16 @@ __git_main ()
 	if [ -n "$expansion" ]; then
 		words[1]=$expansion
 		completion_func="_git_${expansion//-/_}"
-		declare -f $completion_func >/dev/null && $completion_func
+		declare -f $completion_func >/dev/null && $completion_func && return
+	fi
+
+	# As a fallback, if no completion function is defined for the
+	# command, look for add-on command completion script in same
+	# directory as this completion script, and if found, source it,
+	# and restart completion using it.
+	local compdir="${BASH_SOURCE%/*}"
+	if [ -e "$compdir/git-$command" ]; then
+		source "$compdir/git-$command" && __git_main "$@"
 	fi
 }
 

-- 
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



signature.asc
Description: PGP signature

Bug#864505: bash completion does not work

[Joey Hess]

Package: git-hub
Version: 0.11.0-1
Severity: normal

In bash, typing "git-hub " does not offer any completions.
There must be a problem with the included bash completion file.

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

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

Versions of packages git-hub depends on:
ii  git 1:2.11.0-4
ii  python  2.7.13-2

git-hub recommends no packages.

git-hub suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#863910: haskell highlighting colors lines starting with # operator in red

[Joey Hess]

Package: vim
Version: 2:8.0.0197-4
Severity: normal

This in foo.hs will show the problem when loaded in vim with
no local ~/.vimrc or ~/.vim:

main = print (munge "world hello,")

munge = words
# reverse
# unwords

(#) = flip (.)

Both of the lines starting with "#" are displayed with a red background,
as if vim thinks this is some kind of syntax error. However, 
# is a perfectly legal haskell function name, and this file is a
legal haskell hello world.

The haskell package threepenny-gui uses the definition of # given above,
and so idionmatic code written with that library is full of ugly red lines
in vim.

I'll bet that the intention was something like, perl refugees 
might try to write "# comment" and so highlight the mistake. But with #
in actual use as a function, that does not seem wise. Also, note that
vim does not use the red background on "foo # comment"

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.basic
/usr/bin/vim is /usr/bin/vim.basic

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

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

Versions of packages vim depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.24-11
ii  libgpm2  1.20.4-6.2+b1
ii  libselinux1  2.6-3+b1
ii  libtinfo56.0+20161126-1
ii  vim-common   2:8.0.0197-4
ii  vim-runtime  2:8.0.0197-4

vim recommends no packages.

Versions of packages vim suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-11
pn  vim-doc  
pn  vim-scripts  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#862350: importfeed debug print

[Joey Hess]

Package: git-annex
Version: 6.20170101-1+b1
Severity: normal

git-annex importfeed prints out ("link", url) debugging lines.

This debug print was accidentially shipped in this version of git-annex,
a62802af087e5c06f23a654a9d7023e3ae8df956 is a patch to remove it.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-annex depends on:
ii  curl7.52.1-5
ii  git 1:2.11.0-3
ii  libc6   2.24-10
ii  libffi6 3.2.1-6
ii  libgmp102:6.1.2+dfsg-1
ii  libmagic1   1:5.30-1
ii  libsqlite3-03.16.2-3
ii  libxml2 2.9.4+dfsg1-2.2
ii  openssh-client  1:7.4p1-10
ii  rsync   3.1.2-2
ii  wget1.19.1-3
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages git-annex recommends:
ii  aria2  1.31.0-1
ii  bind9-host 1:9.10.3.dfsg.P4-12.2
ii  git-remote-gcrypt  1.0.1-1
ii  gnupg  2.1.18-7
ii  lsof   4.89+dfsg-0.1
ii  nocache1.0-1
ii  quvi   0.9.4-1.1+b1

Versions of packages git-annex suggests:
ii  bup 0.29-3
ii  libnss-mdns 0.10-8
ii  magic-wormhole  0.9.1-1
pn  tahoe-lafs  
ii  tor 0.2.9.10-1
ii  xdot0.7-2

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#861780: README does not mention pause key combo

[Joey Hess]

Package: kazam
Version: 1.4.5-2
Severity: normal

The README documents some keyboard shortcuts, but no the one for pausing
which is SUPER-CTRL-P

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kazam depends on:
ii  gir1.2-gst-plugins-base-1.0  1.10.4-1
ii  gir1.2-gstreamer-1.0 1.10.4-1
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-wnck-3.0  3.20.1-3
ii  gnome-session-canberra   0.30-3
ii  gstreamer1.0-plugins-base1.10.4-1
ii  gstreamer1.0-plugins-good1.10.4-1
ii  gstreamer1.0-plugins-ugly1.10.4-1
ii  gstreamer1.0-pulseaudio  1.10.4-1
ii  python3  3.5.3-1
ii  python3-cairo1.10.0+dfsg-5+b1
ii  python3-dbus 1.2.4-1+b1
ii  python3-gi   3.22.0-2
ii  python3-gi-cairo 3.22.0-2
ii  python3-xdg  0.25-4
pn  python3:any  

Versions of packages kazam recommends:
ii  gstreamer1.0-libav  1.10.4-1

kazam suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#800134: new version

[Joey Hess]

Turns out wotsap 0.3 file format supports 16 length ids. 
http://pgp.cs.uu.nl/archive/wot-0.3/latest.wot
The version of wotsap in debian does not support that format.

I feel that this is a security problem; the current wotsap provides a
false sense of security to any users given that the whole strong set has
been cloned at length 8.

It seems that the python implementation of wotsap does not support that
format, but there's a perl version that does, here:
http://pgp.cs.uu.nl/wotsap/

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#800134: +1

[Joey Hess]

This makes wotsap not secure enough for use by the program I had wanted
to use it. Short key ids are too easily spoofed to be useful.

IMHO, wotsap should support full length key fingerprints, I don't want
to use any form of truncated ids when finding trust paths.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#776424: [kgb-maintainers] Bug#776424: can be crashed by some network traffic

[Joey Hess]

Antoine Beaupre wrote:
> Joey, did you manage to reproduce this issue without an external
> attacker? Can you still reproduce in 1.34?

Just saw the issue again with 1..34-2

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#858288: -n option does not behave as documented (or as it does in other shells)

[Joey Hess]

Package: dash
Version: 0.5.8-2.4
Severity: normal

joey@darkstar:~>dash -n -c 'echo hi'
hi
joey@darkstar:~>bash -n -c 'echo hi'
joey@darkstar:~>posh -n -c 'echo hi'
joey@darkstar:~>

According the man page:

   -n noexecIf not interactive, read commands but do
not execute them.  This is useful for
checking the syntax of shell scripts.

As well as not matching the man page, this nonstandard behavior can
be a source of bugs.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii  debianutils  4.8.1
ii  dpkg 1.18.23
ii  libc62.24-9

dash recommends no packages.

dash suggests no packages.

-- debconf information excluded

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#858286: man page -n option documentation

[Joey Hess]

Package: bash
Version: 4.4-4+b1
Severity: normal

The -n option is not very well documented on the bash man page.
This is the only mention of it:

   -DA  list of all double-quoted strings preceded by $ is printed
 on the standard output.  These are the strings that are  sub‐
 ject to language translation when the current locale is not C
 or POSIX.  This implies the -n option; no  commands  will  be
 executed.

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   9.8
ii  dash 0.5.8-2.4
ii  debianutils  4.8.1
ii  libc62.24-9
ii  libtinfo56.0+20161126-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#855994: password rotation needed field

[Joey Hess]

Package: assword
Version: 0.10-2
Severity: normal

It would be very useful to have a field for each password indicating
when it needs to be rotated. assword could then warn when the user uses
that password, and have a button to generate a new password, replacing
the old one in the db.

Given Cloudbleed, it would also be nice to have an option that can set
the field to "immediately" for all passwords..

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages assword depends on:
ii  python3-gi   3.22.0-2
ii  python3-gpg  1.8.0-3
pn  python3:any  

Versions of packages assword recommends:
ii  gir1.2-gtk-3.0  3.22.7-1
ii  python3-xdo 0.3-2
ii  xclip   0.12+svn84-4

assword suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#852199: /snap is a FHS violation

[Joey Hess]

Package: snapd
Version: 2.21-1
Severity: normal

I am very surprised to see a Debian package violating the FHS so
egrariously.

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages snapd depends on:
ii  adduser   3.115
ii  apparmor  2.11.0-1
ii  ca-certificates   20161130
ii  gnupg 2.1.17-5
ii  gnupg11.4.21-2
ii  init-system-helpers   1.47
ii  libc6 2.24-9
ii  snap-confine  2.21-1
ii  squashfs-tools1:4.3-3
ii  systemd   232-8
ii  ubuntu-core-launcher  2.21-1

snapd recommends no packages.

snapd suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: Info received (Bug#846275: provide a directory for hidden service socket files)

[Joey Hess]

I think I've figured out underlying problem that caused me to get
confused about whether tor was able to access the sockets.

Dec 21 13:50:16.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 
rendezvous descriptor for service [scrubbed]
Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible 
hidden service directories, because we requested them all recently without 
success.
Dec 21 13:50:16.000 [info] pick_hsdir(): Could not pick one of the responsible 
hidden service directories, because we requested them all recently without 
success.
Dec 21 13:50:16.000 [info] fetch_v2_desc_by_addr(): Could not pick one of the 
responsible hidden service directories to fetch descriptors, because we already 
tried them all unsuccessfully.

https://trac.torproject.org/projects/tor/ticket/16501
https://trac.torproject.org/projects/tor/ticket/15937

While testing my peer-to-peer use of tor hidden services, I was running
multiple hidden services on one development machine. Each peer would try
to contact the other's hidden service.

As seen in the bug reports above, multiple SOCKS connections to a hidden
service could cause some of the requests to fail.

Those bugs reports seem to have been dealt with, but I am still
experiencing what seems to be a similar problem. I've filed a new bug
report on tor about that:

https://trac.torproject.org/projects/tor/ticket/21056

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Peter Palfrader wrote:
> Yes, see README.Debian in the most recent upload -
>  https://gitweb.torproject.org/debian/tor.git/tree/debian/README.Debian
> 
> Please let me know if this is what you had in mind.  I'd appreciate any
> suggestions (or patches) for improvement :)

Looks very good.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Peter Palfrader wrote:
> On Sun, 18 Dec 2016, Joey Hess wrote:
> 
> > But, I was able to get it to work using /var/lib/bla/sock
> > when I tried once more.
> 
> Ok.  I guess that means we don't need any particular package config fu
> here.  Maybe just some documentation.

It would be good to document where the sockets can be placed. Picking
and documenting a specific directory would ensure that, if tor later
gets locked down more, it would still be able to read sockets from that
location.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Peter Palfrader wrote:
> Can you retry with an info level log (see Tor#21019[1]), and maybe
> strace -p  -e connect the process while you're at it?
> 
> Also, which kernel and which systemd?
> 
> I had tried it on sid, using systemd 232-8, tor 0.2.9.7-rc-dev-..,
> and 4.8.0-2-amd64 with apparmor enabled to boot.

Here are the versions on the two systems I've tried:

linux 4.8.0-2-amd64linux 4.6.0-1-amd64
systemd 232-7  systemd 232-3
tor 0.2.8.11   tor 0.2.8.9

Neither system has apparmor* packages installed.

But, I was able to get it to work using /var/lib/bla/sock
when I tried once more.

Beginning to think that it's not related to filesystem perms, and is
some intermittent or timing related problem getting the onion
address published or querying it.

I can consistently reproduce the problem by adding a new hidden service,
starting up tor, and trying to connect to its onion address from the same
system within about 1 minute. The telnet hangs, and this shows in the log:

Dec 18 18:23:29.000 [info] connection_ap_handshake_rewrite_and_attach(): Got a 
hidden service request for ID '[scrubbed]'
Dec 18 18:23:29.000 [info] connection_ap_handshake_rewrite_and_attach(): 
Unknown descriptor [scrubbed]. Fetching.
Dec 18 18:23:29.000 [debug] rend_client_refetch_v2_renddesc(): Fetching v2 
rendezvous descriptor for service [scrubbed]
Dec 18 18:23:29.000 [info] pick_hsdir(): Could not pick one of the responsible 
hidden service directories, because we requested them all recently without 
success.

(Still don't see how the apparmor config would let it read
/var/lib/bla/sock tho.)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#848508: fails to work with LANG=C

[Joey Hess]

Antoine Beaupré wrote:
> That's a good point! However, wouldn't that be a bug with wormhole on OS
> X (as opposed to here, on Debian, which supports UTF-8 natively).

I think wormhole can be used with either python2 or python3, and the
error message says this is a python3 problem, and Debian has it using
python3. That's why I reported the bug here.

From http://click.pocoo.org/5/python3/

At the moment, it is strongly recommended is to use Python 2 for Click
utilities unless Python 3 is a hard requirement.

Advice Debian is disregarding it seems..

Concerned that if I build something using wormhole, I'll get to learn
about every Debian user who has LANG=C or does not have any locale set.

(Maybe I *can* just force LANG=C.UTF-8; on operating systems where
wormhole is using python2, it probably won't matter if that locale is
not available.)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Peter Palfrader wrote:
> So, maybe I'm doing something wrong, but I have configured a hidden
> service socket in /var/lib/bla/sock, and I can access it just fine
> without listing that directory in either the apparmor nor the systemd
> service file.

root@elephant:~> tail -n 2 /etc/tor/torrc
HiddenServiceDir /var/lib/tor/tesths
HiddenServicePort  unix:/var/lib/bla/sock
root@elephant:~> service tor restart # waited for it to finish bootstrap
root@elephant:~> cd /var/lib
root@elephant:/var/lib> mkdir bla
root@elephant:/var/lib> cd bla
root@elephant:/var/lib/bla> socat UNIX-LISTEN:sock STDIO &
root@elephant:/var/lib/bla> chmod 777 sock
root@elephant:/var/lib/bla> ls -l sock
srwxrwxrwx 1 root root 0 Dec 17 18:38 sock=
root@elephant:/var/lib/bla> ls -ld `pwd`
drwxr-xr-x 2 root root 4096 Dec 17 18:42 /var/lib/bla/
root@elephant:/var/lib/bla> cat /var/lib/tor/tesths/hostname 
r7ymlfhfbpp5cfny.onion
root@elephant:/var/lib/bla> torsocks telnet r7ymlfhfbpp5cfny.onion 
Trying 127.42.42.0...

The telnet never connects. Tor is silently refusing to use /var/lib/bla/sock.

Following the exact same procedure, but with /etc/tor/sock as the socket,
the telnet connects successfully.

Note that this only seems to happen when tor is started by systemd.
When I run the daemon manually, it is able to use sockets elsewhere.
My assumption, which may be wrong, is that systemd is loading the
apparmor config. There may be other situations where that does not happen;
dunno.

Complete tor log after the transcript above:

Dec 17 22:49:31.000 [notice] Tor 0.2.8.9 (git-cabd4ef300c6b3d6) opening log 
file.
Dec 17 22:49:31.330 [notice] Tor v0.2.8.9 (git-cabd4ef300c6b3d6) running on 
Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 17 22:49:31.331 [notice] Tor can't help you if you use it wrong! Learn how 
to be safe at https://www.torproject.org/download/download#warning
Dec 17 22:49:31.332 [notice] Read configuration file 
"/usr/share/tor/tor-service-defaults-torrc".
Dec 17 22:49:31.332 [notice] Read configuration file "/etc/tor/torrc".
Dec 17 22:49:31.340 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 17 22:49:31.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Dec 17 22:49:31.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Dec 17 22:49:31.000 [notice] Bootstrapped 0%: Starting
Dec 17 22:49:32.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Dec 17 22:49:32.000 [notice] Signaled readiness to systemd
Dec 17 22:49:32.000 [notice] Opening Socks listener on /var/run/tor/socks
Dec 17 22:49:32.000 [notice] Opening Control listener on /var/run/tor/control
Dec 17 22:49:33.000 [notice] Bootstrapped 85%: Finishing handshake with first 
hop
Dec 17 22:49:33.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Dec 17 22:49:33.000 [notice] Tor has successfully opened a circuit. Looks like 
client functionality is working.
Dec 17 22:49:33.000 [notice] Bootstrapped 100%: Done

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#848508: fails to work with LANG=C

[Joey Hess]

Package: magic-wormhole
Version: 0.8.1-2
Severity: normal

  joey@darkstar:~>LANG=C wormhole receive
  Traceback (most recent call last):
File "/usr/bin/wormhole", line 11, in 
  load_entry_point('magic-wormhole==0.8.1', 'console_scripts', 'wormhole')()
File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
  return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 675, in main
  _verify_python3_env()
File "/usr/lib/python3/dist-packages/click/_unicodefun.py", line 119, in 
_verify_python3_env
  'mitigation steps.' + extra)
  RuntimeError: Click will abort further execution because Python 3 was 
configured to use ASCII as encoding for the environment.  Either run this under 
Python 2 or consult http://click.pocoo.org/python3/ for mitigation steps.
  
  This system supports the C.UTF-8 locale which is recommended.
  You might be able to resolve your issue by exporting the
  following environment variables:
  
  export LC_ALL=C.UTF-8
  export LANG=C.UTF-8

Shouldn't LANG=C be supported by everything?

This is kind of a problem for scripting use of wormhole, when any
translations of the output need to be avoided. While C.UTF-8 is
available in recent versions of Debian, I doubt it's available widely
elsewhere. For example, it's not available on OSX.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages magic-wormhole depends on:
ii  python3-autobahn  0.14.1+dfsg1-2
ii  python3-click 6.6-1
ii  python3-hkdf  0.0.3-1
ii  python3-nacl  1.0.1-2
ii  python3-six   1.10.0-3
ii  python3-spake20.7-2
ii  python3-tqdm  4.8.4-1
ii  python3-twisted   16.6.0-2
pn  python3:any   

magic-wormhole recommends no packages.

magic-wormhole suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#847677: "unable to decommit memory" data loss

[Joey Hess]

Package: ghc
Version: 8.0.1-14
Severity: serious

git-annex: unable to decommit memory: Invalid argument

This happened with a git-annex built with this ghc, and bundled with
Debian's glibc (essentially a chroot), on a Fedora system with a 4.4.14
Linux kernel.

It apparently then led to memory corruption, since git-annex created
some very bogus symlinks:

lrwxrwxrwx 1 user user 338 Jun 17 22:36 
bup.git/objects/pack/pack-47b493a3bbbd22200d2b390c277e49ce713243cc.pack -> 
*??:?;J?

So, we seem to have data loss, presumably any git-annex binary built
with this ghc and used with a too old kernel. Could also affect other
haskell programs.

The ghc bug leading to this problem has been fixed:

https://ghc.haskell.org/trac/ghc/ticket/12865

Could you please fast-track this fix into Debian?

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

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

Versions of packages ghc depends on:
ii  dpkg 1.18.14
ii  gcc  4:6.1.1-1
ii  libbsd-dev   0.8.3-1
ii  libc62.24-5
ii  libc6-dev2.24-5
ii  libffi-dev   3.2.1-6
ii  libffi6  3.2.1-6
ii  libgmp-dev   2:6.1.1+dfsg-1
ii  libgmp10 2:6.1.1+dfsg-1
ii  libncurses5-dev  6.0+20160917-1
ii  libtinfo56.0+20160917-1

ghc recommends no packages.

Versions of packages ghc suggests:
ii  ghc-doc  8.0.1-14
ii  ghc-prof 8.0.1-14
pn  haskell-doc  
pn  llvm-3.7 
ii  perl 5.24.1~rc3-3

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Peter Palfrader wrote:
> If we call it tor_hidden_service_sockets, then the onionshare usecase is
> not really covered by that name.  However, I'm also not sure that it's a
> valid use-case - it probably ought to put the hidden service directory
> into /var/lib/tor and use the control interface to learn the hostname.
> Or use ephemeral hidden services via the control interface.

I can't speak for the onionshare developers, but the control interface
is not enabled by default, and can't be easily automatically enabled,
which makes it unappealing to depend on it if you can get things working
another way. There may be a permissions problem with them using
/var/lib/tor for the hidden service directory too.

Whether it makes sense to also cater to the onionshare needs with this
directory, or limit it to the hidden service socket use case, 
I leave up to you.

> With the top directory not having any user specific modes, different tor
> instances can share that tree.  I wonder if we still want
> /var/lib/tor-onion-sockets/{default,foo,bar} so that we get
> systemd protection and prevent a tor instance from accessing another
> instances's tree.

The permissions probably prevent such problems, at least if they are set
up as in my example with the socket file for a hidden service in a
directory that only the tor instance that serves it (and the user that
runs the service) can read.

But, it couldn't hurt to separate the directories and lock it down more.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Peter Palfrader wrote:
> I do like the idea.  Do you have any suggestions on naming it?  

Well, the directory should only contain unix socket files for tor hidden
services, so something like /var/lib/tor_hidden_service_sockets?

(Path should not be too long due to the severe length limitations on
paths to unix sockets..)

> Do we want directory shared across all tor instances, or do we want a
> different one for every instance?

The only tor instance I am familar with, aside from the system tor, is
torbrowser's instance. AFAIK the latter runs entirely as the user who
started the browser, and uses a separate tor directory tree in their
HOME, so system-wide directories are probably not useful to it.

The hidden service socket directory needs to be readable by debian-tor,
and by whatever set of users hidden services run as. That probably means
world readable. Each hidden service can have a subdirectory in it,
which need only to be readable by debian-tor and writable by the
particular user who runs the hidden service.

drwxr-xr-x root   root   /var/lib/tor_hidden_service_sockets
drwxr-x--- joey   debian-tor /var/lib/tor_hidden_service_sockets/joeyservice
-rw-r- joey   debian-tor 
/var/lib/tor_hidden_service_sockets/joeyservice/socket

If another instance of the system tor was run for some reason, as a
different user than debian-tor, it would thus not be able to access
the sockets for hidden services served by debian-tor. It could use the
/var/lib/tor_hidden_service_sockets directory in the same way with
subdirs for the hidden services it serves.

(Is it a problem that in this example user joey can now store data under
/var? Well, I can already write to /var/mail/joey, and to some nethack bones
files and of course to /var/tmp/. This would be the first time I was able to
write to files in /var/lib/ except indirectly via crontab -e. It could be a
concern if the admin enforces user disk quotas for /home, but they
should probably also have quotas on /var due to the other ways for users
to write there.)

> Should we actually ship the directory, or would it be sufficient to just
> make the apparmor and systemd restrictions allow that directory and have
> the admin create it when they need it?

Shipping the directory would be a good indication that this version of
tor supports it. Otherwise a hidden service installer would need to look
at version numbers or the apparmor config to guess.

Also, shipping the directory would let you pick the best permissions for it.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: FWD: Re: Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Resent as apparently public libraries have smtp-eating proxies now.

- Forwarded message from Joey Hess <i...@joeyh.name> -

Date: Thu, 8 Dec 2016 12:43:59 -0400
From: Joey Hess <i...@joeyh.name>
To: Peter Palfrader <wea...@debian.org>
Cc: 846...@bugs.debian.org
Subject: Re: Bug#846275: provide a directory for hidden service socket files
User-Agent: NeoMutt/20161104 (1.7.1)

Peter Palfrader wrote:
> I do like the idea.  Do you have any suggestions on naming it?  

Well, the directory should only contain unix socket files for tor hidden
services, so something like /var/lib/tor_hidden_service_sockets?

(Path should not be too long due to the severe length limitations on
paths to unix sockets..)

> Do we want directory shared across all tor instances, or do we want a
> different one for every instance?

The only tor instance I am familar with, aside from the system tor, is
torbrowser's instance. AFAIK the latter runs entirely as the user who
started the browser, and uses a separate tor directory tree in their
HOME, so system-wide directories are probably not useful to it.

The hidden service socket directory needs to be readable by debian-tor,
and by whatever set of users hidden services run as. That probably means
world readable. Each hidden service can have a subdirectory in it,
which need only to be readable by debian-tor and writable by the
particular user who runs the hidden service.

drwxr-xr-x root   root   /var/lib/tor_hidden_service_sockets
drwxr-x--- joey   debian-tor /var/lib/tor_hidden_service_sockets/joeyservice
-rw-r- joey   debian-tor 
/var/lib/tor_hidden_service_sockets/joeyservice/socket

If another instance of the system tor was run for some reason, as a
different user than debian-tor, it would thus not be able to access
the sockets for hidden services served by debian-tor. It could use the
/var/lib/tor_hidden_service_sockets directory in the same way with
subdirs for the hidden services it serves.

(Is it a problem that in this example user joey can now store data under
/var? Well, I can already write to /var/mail/joey, and to some nethack bones
files and of course to /var/tmp/. This would be the first time I was able to
write to files in /var/lib/ except indirectly via crontab -e. It could be a
concern if the admin enforces user disk quotas for /home, but they
should probably also have quotas on /var due to the other ways for users
to write there.)

> Should we actually ship the directory, or would it be sufficient to just
> make the apparmor and systemd restrictions allow that directory and have
> the admin create it when they need it?

Shipping the directory would be a good indication that this version of
tor supports it. Otherwise a hidden service installer would need to look
at version numbers or the apparmor config to guess.

Also, shipping the directory would let you pick the best permissions for it.

-- 
see shy jo



- End forwarded message -
-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Joey Hess wrote:
> drwxr-xr-x root   root   /var/lib/tor_hidden_service_sockets
> drwxr-x--- joey   debian-tor /var/lib/tor_hidden_service_sockets/joeyservice
> -rw-r- joey   debian-tor 
> /var/lib/tor_hidden_service_sockets/joeyservice/socket

Actually, I can't create a socket file owned by debian-tor, and I need
to be the one to create the socket (when my hidden service binds it).
So, it would really look like this:

drwxr-xr-x root   root   /var/lib/tor_hidden_service_sockets
drwxr-x--- joey   debian-tor /var/lib/tor_hidden_service_sockets/joeyservice
-rw-r--r-- joey   joey   
/var/lib/tor_hidden_service_sockets/joeyservice/socket

This still only lets debian-tor read from the socket due to the
permissions of the directory, which is good.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#847418: depends on gstreamer-plugins-bad, which is an ongoing source of security holes

[Joey Hess]

Package: libfarstream-0.2-5
Version: 0.2.8-1
Severity: normal

gstreamer-plugins-bad has been in the news at least twice recently for
security holes.

http://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html
https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html

It seems likely that it will continue to be a source of such security
holes.

I wanted to remove gstreamer-plugins-bad from my system, but this would
remove libfarstream-0.2-5, which would remove pidgin.

I doubt that pidgin needs a ton of insecurely implemented codecs for
playing Nintendo games etc in order to do video/audio chat. Could this
dependency please be lessened to a Suggests? Or even better, don't
depend on codecs from a library package; let the packages for programs
that actually need to codecs depend on the codec packages.

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

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

Versions of packages libfarstream-0.2-5 depends on:
ii  gstreamer1.0-nice   0.1.13-2
ii  gstreamer1.0-plugins-bad1.10.0-1
ii  gstreamer1.0-plugins-base   1.10.0-1
ii  gstreamer1.0-plugins-good   1.10.0-1
ii  libc6   2.24-5
ii  libglib2.0-02.50.2-1
ii  libgstreamer-plugins-base1.0-0  1.10.0-1
ii  libgstreamer1.0-0   1.10.0-2
ii  libgupnp-1.0-4  1.0.1-1
ii  libgupnp-igd-1.0-4  0.2.4-1
ii  libnice10   0.1.13-2

libfarstream-0.2-5 recommends no packages.

libfarstream-0.2-5 suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#847417: depends on gstreamer-plugins-bad, which is an ongoing source of security holes

[Joey Hess]

Package: gnome-video-effects
Version: 0.4.1-3
Severity: normal

gstreamer-plugins-bad has been in the news at least twice recently for
security holes. 

http://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html
https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html

It seems likely that it will continue to be a source of such security
holes.

I wanted to remove gstreamer-plugins-bad from my system, but this would
remove gnome-video-effects, which would remove cheese. I don't know why
cheese needs a ton of insecurely implemented codecs for playing Nintendo
games etc in order to take snapshots and record videos. Probably it doesn't?

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

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

Versions of packages gnome-video-effects depends on:
ii  gstreamer1.0-plugins-bad   1.10.0-1
ii  gstreamer1.0-plugins-good  1.10.0-1

gnome-video-effects recommends no packages.

Versions of packages gnome-video-effects suggests:
pn  gnome-video-effects-frei0r  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#846275: provide a directory for hidden service socket files

[Joey Hess]

Package: tor
Version: 0.2.8.9-1
Severity: normal

When running a tor hidden service, it's desirable to run it as a
different user than debian-tor, and it's safer to use a unix socket than
it is to run the hidden service on a localhost port. However, when a unix
socket file is used for communication between tor and the hidden
service, there is no good location to put it in. I suggest providing
such a location.

It seems that /etc/apparmor.d/system_tor is used by default on systemd
systems -- it appears to be limiting here what tor can read, although I
don't have apparmor packages installed. In that file, tor is locked down
to only be able to access /var/lib/tor/, /var/run/tor/, and /etc/tor/

/var/lib/tor is only readable by debian-tor, so for the hidden service
  socket to be located somewhere in there, the hidden service would have
  to be run as debian-tor (user or group).

/var/run/tor is world readable, so it would be possible to make a
  subdirectory, say /var/run/tor/hidden_service/, allow the hidden service
  user to write to the subdirectory so it can bind the socket, and tor would
  be able to use it. But, /var/run does not persist across reboots, so this
  subdirectory would need to be set up on each boot by root before the
  hidden service starts up.

/etc/tor is the only other option. Indeed, /etc/tor/hidden_service/ can
  be set up to be writable by the hidden service user, it can put its
  socket there, and tor can read it. But putting a socket in /etc/ is
  a FHS violation.

I am using tor hidden services for P2P communication between git-annex
repositories. The user runs a command as root once to set up the hidden
service for their repository. So my current choices to integrate this
with Debian's tor package are:

* Violate the FHS by putting a non-config file in /etc/tor/
* Modify the apparmor config shipped with tor to let it read the socket
  in some other location. Seems this would require restarting the tor
  daemon amoung other complications.
* Add an init script that sets up subdirectories under /var/run/tor
  with appropriate owners on boot. Complicated.

So, the configuration of this package is encouraging me to violate the
FHS. It seems like the most robust and simplest way.

I suggest that the Debian tor package include a world-readable
directory, which tor is allowed to access by its apparmor config and any
other things used to lock it down. Subdirectories can then be
added as needed to contain hidden service unix sockets, etc.

(Another use case for such a world-readable directory could be
onionshare. It currently uses a HiddenServiceDir in /tmp/onionshare/, so
that it can read the onion address from it, which it could not if it
used /var/lib/tor. /etc/apparmor.d/torbrowser.Tor.tor has a special case
for that onionshare directory. This is why the onionshare package depends
on torbrowser-launcher; see #762890.)

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

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

Versions of packages tor depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  libc62.24-5
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libseccomp2  2.3.1-2
ii  libssl1.0.2  1.0.2j-4
ii  libsystemd0  232-3
ii  lsb-base 9.20161101
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages tor recommends:
ii  logrotate3.8.7-2
ii  tor-geoipdb  0.2.8.9-1
ii  torsocks 2.2.0-1

Versions of packages tor suggests:
pn  apparmor-utils   
pn  mixmaster
pn  obfs4proxy   
pn  obfsproxy
ii  socat1.7.3.1-1
pn  tor-arm  
ii  torbrowser-launcher  0.2.6-2

-- Configuration Files:
/etc/tor/torrc changed [not included]

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#844598: not fixed

[Joey Hess]

Still experiencing build failures using stack until I make the
workarounds to ghc's settings file described in this bug.

ii  ghc8.0.1-14 amd64The Glasgow Haskell Compilation sy
ii  haskell-stack  1.1.2-7  amd64The Haskell Tool Stack

Packages using lts-6.12 fail to build. For example,
git://git.joeyh.name/keysafe.git

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#840516: doesn't work with django 1.10

[Joey Hess]

I suppose this is the problem that this bug report is about:

root@ia-bak:/usr/local/propellor# graphite-manage 
Traceback (most recent call last):
  File "/usr/bin/graphite-manage", line 15, in 
execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 367, in execute_from_command_line
utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 341, in execute
django.setup()
  File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in 
populate
app_config.import_models(all_models)
  File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 199, in 
import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/python2.7/dist-packages/graphite/events/models.py", line 6, in 

from tagging.managers import ModelTaggedItemManager
  File "/usr/lib/python2.7/dist-packages/tagging/managers.py", line 8, in 

from tagging.models import Tag, TaggedItem
  File "/usr/lib/python2.7/dist-packages/tagging/models.py", line 10, in 

from django.contrib.contenttypes import generic
ImportError: cannot import name generic

Downgrading python-django to 1.9.8 and python-django-tagging to 0.4 did clear
this up.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#843522: Hardcoding Tor SOCKS proxy

[Joey Hess]

Sean Whitton wrote:
> Keysafe hardcodes the Tor SOCKS proxy as 127.0.0.1:9050.  Do you intend
> to make this configurable, or are there security reasons for forcing
> localhost?
> 
> This will determine whether the Debian package depends on tor or merely
> recommends it.

I feel that it should depend on tor.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#839759: locale-gen (and localedef) read from files in current directory

[Joey Hess]

Package: locales
Version: 2.24-3
Severity: normal
File: /usr/sbin/locale-gen
Tags: security

While stracing localedef, I noticed this behavior:

open("i18n", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("/usr/share/i18n/locales/i18n", O_RDONLY) = 4

There's no chdir; this reads from files in the cwd where locale-gen is run.

The original intended use case for localedef was probably to run it in your
home directory to generate locales there, so this behavior didn't matter. With
locale-gen running it as root, that innocious behavior becomes a potential
security hole.

So, if root runs locale-gen in eg, /tmp or a user's home directory,
it will read files controlled by another user.

This could be used to try to exploit localedef and get a shell, or it could be
used to feed in valid format but incorrect locale data and mess up the system
locales.

It may also be possible to exploit this when apt is upgrading locales.

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

Kernel: Linux 4.8.0-rc5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc-bin   2.24-3
ii  libc-l10n  2.24-3

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: de_DE.UTF-8 UTF-8, en_CA.UTF-8 UTF-8, en_US 
ISO-8859-1, en_US.UTF-8 UTF-8, es_ES.UTF-8 UTF-8, et_EE.UTF-8 UTF-8, 
fr_FR.UTF-8 UTF-8, ru_RU.UTF-8 UTF-8
* locales/default_environment_locale: None

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#837968: key generation blocks gpg signing with another already existing key

[Joey Hess]

Package: gnupg
Version: 2.1.15-2
Severity: normal

I was running gpg --full-gen-key in one terminal, and it was taking a
while to find enough entropy.

In another terminal, I tried to make a git commit, and this hung. git
was running gpg -bsau, signing using a differeny key that already exists, 
and it seems it's blocking while the key generation is running.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.15-2
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-2
ii  libgcrypt201.7.3-1
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.5-2
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.14.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  dirmngr 2.1.15-2
pn  gnupg-l10n  

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#836351: new mac address randomization breaks r8723au

[Joey Hess]

Package: network-manager
Version: 1.4.0-3
Severity: normal

My Lenovo Yoga laptop uses the r8723au kernel driver. This driver is low
quality, and one of its bugs is that when asked to change the mac
address, the system call succeeds, but the address is not actually
changed (see #774898):

root@darkstar:~>macchanger -r wlan0 
Current MAC:(Liteon Technology Corporation)
Permanent MAC:  (Liteon Technology Corporation)
New MAC:   2e:ba:07:b6:bd:3e (unknown)
Network driver didn't actually change to the new MAC!!

Apparently this behavior causes a bad interaction with network-manager's new
mac address randomization.

When wifi.scan-rand-mac-address=yes, network-manager fails to scan for wifi
networks. The UI has no indication of a problem, other than no networks are
listed. The log shows:

Sep 01 22:16:03 darkstar kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not 
ready
Sep 01 22:16:03 darkstar wpa_supplicant[5360]: wlan0: CTRL-EVENT-REGDOM-CHANGE 
init=CORE type=WORLD
Sep 01 22:16:03 darkstar NetworkManager[9700]:   [1472782563.1695] device 
(wlan0): supplicant interface state: disabled -> disconnected
Sep 01 22:16:04 darkstar NetworkManager[9700]:   [1472782564.4725] device 
(wlan0): supplicant interface state: disconnected -> inactive
Sep 01 22:16:04 darkstar NetworkManager[9700]:   [1472782564.4767] device 
(wlan0): set-hw-addr: new MAC address 56:61:92:36:E5:54 not successfully set to 
set (scanning)
Sep 01 22:16:04 darkstar kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not 
ready
Sep 01 22:16:04 darkstar wpa_supplicant[5360]: wlan0: CTRL-EVENT-REGDOM-CHANGE 
init=CORE type=WORLD

When wifi.scan-rand-mac-address=no, and wifi.cloned-mac-address=random, it
finds networks, but fails to connect, displaying a dialog box with a error
message that threatens to summon the dark elder gods of bad error messages:

   Failed to add/activate connection
(2) Active connection removed before it was initialized

Log:

Sep 01 22:17:50 darkstar NetworkManager[10288]:   [1472782670.0328] 
manager: NetworkManager state is now CONNECTING
Sep 01 22:17:50 darkstar NetworkManager[10288]:   [1472782670.0338] 
device (wlan0): set-hw-addr: new MAC address E2:14:61:DC:AA:08 not successfully 
set to set-cloned (random)
Sep 01 22:17:50 darkstar NetworkManager[10288]:   [1472782670.0340] 
device (wlan0): state change: prepare -> failed (reason 'none') [40 120 0]
Sep 01 22:17:50 darkstar NetworkManager[10288]:   [1472782670.0343] 
manager: NetworkManager state is now DISCONNECTED

Hopefully the r8723au staging driver is going away soon and the new
driver will be better. But, it seems network-manager could better deal with
a failure to randomize the MAC, in its behavior and/or UI.

Note that, since known network connections made before upgrading have
randomization disabled, this bug will mostly affect connecting to new
networks some time after upgrading. I think that my earlier bug #818428
was due to experiencing that while traveling, after the scanning MAC
randomization was first added to network-manager.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.10-1
ii  init-system-helpers1.42
ii  libaudit1  1:2.6.6-1
ii  libbluetooth3  5.36-1+b2
ii  libc6  2.23-5
ii  libglib2.0-0   2.49.6-1
ii  libgnutls303.5.3-3
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.0-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.4.0-3
ii  libpam-systemd 231-5
ii  libpolkit-agent-1-00.105-16
ii  libpolkit-gobject-1-0  0.105-16
ii  libreadline6   6.3-8+b4
ii  libselinux12.5-3
ii  libsoup2.4-1   2.54.1-1
ii  libsystemd0231-5
ii  libteamdctl0   1.26-1
ii  libuuid1   2.28.1-1
ii  lsb-base   9.20160629
ii  policykit-10.105-16
ii  udev   231-5
ii  wpasupplicant  2.5-2+v2.4-2

Versions of packages network-manager recommends:
ii  crda 3.13-1+b1
pn  dnsmasq-base 
ii  iptables 1.6.0-3
pn  iputils-arping   
ii  isc-dhcp-client  4.3.4-1
pn  modemmanager 
ii  ppp  2.4.7-1+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#836136: new note crash related to tidy

[Joey Hess]

Package: pumpa
Version: 0.9.2-1+b1
Severity: normal

pumpa is crashing when I click on New Note

pumpa: /build/tidy-html5-kAYBhq/tidy-html5-5.2.0/src/config.c:409: 
prvTidySetOptionBool: Assertion `option_defs[ optId ].type == TidyBoolean' 
failed.
Aborted

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pumpa depends on:
ii  libaspell15   0.60.7~20110707-3+b1
ii  libc6 2.23-5
ii  libgcc1   1:6.2.0-1
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5dbus5   5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5network55.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libstdc++66.2.0-1
ii  libtidy5  1:5.2.0-2

pumpa recommends no packages.

pumpa suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#834869: ITP: keysafe -- back up secret keys to cloud servers

[Joey Hess]

It would be fine to package keysafe now, but please be sure to note that
it has not been fully security reviewed yet. It would probably make
sense to keep it in experimental until version 1.x.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#828779: Info received (Illegal instruction: me too)

[Joey Hess]

Unsurprisingly, building the package from source got a working program.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#828779: Illegal instruction: me too

[Joey Hess]

Package: libargon2-0
Version: 0~20160406-2
Severity: normal

Both the command line program argon2 and the library fail with SIGILL on
my laptop.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 69
model name  : Intel(R) Core(TM) i5-4210Y CPU @ 1.50GHz
stepping: 1
microcode   : 0x14
cpu MHz : 1507.148
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi 
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid 
xsaveopt dtherm ida arat pln pts
bugs:
bogomips: 2992.96
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libargon2-0 depends on:
ii  libc6  2.23-4

libargon2-0 recommends no packages.

libargon2-0 suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#799745: still not fixed...

[Joey Hess]

Over 1 year and not fixed?

FWIW, the changes in 0.4.4-1 cause dh_systemd_enable to run, but there's
no debian/udevil.service file, so that's a no-op. You may find
dh_systemd_enable(1) useful reading.

The ADD_SYSTEMD=0 business does not prevent the Makefile from
installing the service file (in the wrong location). As far as I can
see, ADD_SYSTEMD is an internal variable only used by the configure
script and setting it in debian/rules has no effect.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#825772: seems to ignore SIGHUP sometimes/somehow

[Joey Hess]

Package: alpine
Version: 2.20+dfsg1-2
Severity: normal

I have a server with some users who ssh in to run alpine, and often find
alpine processes left behind after the users have presumably closed
their terminal window or perhaps shut off their computer.
I'm quite sure these nontchnical users are not using nohup to run alpine
or somehing like that. It could be that alpine is crashing somehow and
they're closing the window; they have not said.

(I realize systemd is in the process of fixing this problem erm,
comprehensively, but it still seems worth reporting. My server has run
out of memory partly because of this at least once.)

Glancing at the code, it seems alpine does in
fact catch SIGHUP for some reason. It looks like it can call
signal(SIGHUP, SIG_IGN) in some circumstances.

Attaching gdb to such a process, I got this backtrace:

#0  __lll_lock_wait_private ()
at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x7efec3fa6d82 in __tz_convert (timer=0x7efec429cb20 , 
timer@entry=0x7fff278a4f58, use_localtime=use_localtime@entry=1, 
tp=tp@entry=0x7efec429f560 <_tmbuf>) at tzset.c:623
#2  0x7efec3fa5411 in __GI_localtime (t=t@entry=0x7fff278a4f58)
at localtime.c:42
#3  0x005db4d2 in debug_time (include_date=include_date@entry=1, 
include_subseconds=0) at debugtime.c:52
#4  0x005bcb51 in pine_mail_actually_close (stream=0x129f620)
at stream.c:1351
#5  0x004cd014 in fast_clean_up () at signal.c:370
#6  0x004cd10e in hup_signal () at signal.c:244
#7  
#8  0x7efec3fd76d5 in __GI___xstat (vers=, 
name=0x7efec406295c "/etc/localtime", buf=0x7fff278a5630)
at ../sysdeps/unix/sysv/linux/wordsize-64/xstat.c:35
#9  0x7efec3fa6fdc in __tzfile_read (
file=file@entry=0x7efec406295c "/etc/localtime", extra=extra@entry=0, 
extrap=extrap@entry=0x0) at tzfile.c:161
#10 0x7efec3fa6a39 in tzset_internal (always=, 
explicit=explicit@entry=1) at tzset.c:443
#11 0x7efec3fa6dab in __tz_convert (timer=timer@entry=0x7fff278a5768, 
use_localtime=use_localtime@entry=1, tp=tp@entry=0x7efec429f560 <_tmbuf>)
at tzset.c:628
#12 0x7efec3fa5411 in __GI_localtime (t=t@entry=0x7fff278a5768)
at localtime.c:42
#13 0x7efec3fa5369 in ctime (t=t@entry=0x7fff278a5768) at ctime.c:27
#14 0x005db46b in debug_time (include_date=include_date@entry=0, 
include_subseconds=include_subseconds@entry=1) at debugtime.c:63
#15 0x00559c3c in add_review_message (
message=message@entry=0xaf1380  "- completely_done_with_adrbks -\n", 
level=level@entry=1) at help.c:342
#16 0x005e1ac3 in output_debug_msg (dlevel=dlevel@entry=1, 
fmt=fmt@entry=0x7add41 "read_bail: cleaning up\n") at debuging.c:324
#17 0x005e6cd5 in read_bail () at termin.unx.c:579
#18 0x0050a9f4 in simple_ttgetc (
recorder=recorder@entry=0x5e6730 , 
bail_handler=bail_handler@entry=0x5e6cc0 ) at tty.c:157
#19 0x005e68e8 in pine_simple_ttgetc (
fi=0x5e6730 , fv=0x5e6cc0 )
at termin.unx.c:660
#20 0x00507509 in kbseq (
getcfunc=getcfunc@entry=0x5e6870 , 
recorder=recorder@entry=0x5e6730 , 
bail_handler=bail_handler@entry=0x5e6cc0 , 
data=0x7b3de8 , ch=ch@entry=0x7fff278a59dc)
at getkey.c:359
#21 0x005e7055 in read_char (time_out=time_out@entry=8)
at termin.unx.c:342
#22 0x005e476c in read_command (
utf8str=utf8str@entry=0x7fff278a5aa8) at termin.gen.c:116
#23 0x00497147 in scrolltool (
sparms=sparms@entry=0x7fff278a5bc0) at mailview.c:2606
#24 0x0049939d in mail_view_screen (ps=0x12845c0)
at mailview.c:445
#25 0x0040a0d5 in main (argc=, 
ut>) at alpine.c:1336

-- 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/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages alpine depends on:
ii  libc6 2.22-9
ii  libgssapi-krb5-2  1.13.2+dfsg-5
ii  libkrb5-3 1.13.2+dfsg-5
ii  libldap-2.4-2 2.4.42+dfsg-2+b2
ii  libpam0g  1.1.8-3.2
ii  libssl1.0.2   1.0.2h-1
ii  libtinfo5 6.0+20160319-1
ii  mlock 8:2007f~dfsg-4+b1

Versions of packages alpine recommends:
ii  alpine-doc  2.20+dfsg1-2

Versions of packages alpine suggests:
ii  aspell  0.60.7~20110707-3+b1
ii  postfix [mail-transport-agent]  3.1.0-3

-- no debconf information

-- 
see shy jo

Bug#825394: shim screen etc?

[Joey Hess]

Since the number of commands that start such a process is limited to
screen/tmux/nohup, these could just be shimmed to do whatever's
needed to let them keep running past logout.

Course it would make more sense to have a proper API that such programs
can use themselves.

I have tried to develop such a shim:

#!/bin/sh
cmd="$(basename "$0")"
# hardcoded path so this shim can be in eg ~/bin/screen and run the real program
systemd-run -q --scope --user /usr/bin/$cmd "$@"

Difficulties with this as it stands:

* loginctl enable-linger needs to be run before the login session
  in which that shim is used, I think?
* I could not get loginctl enable-linger as user to work when logging into the
  server as over ssh:
Could not enable linger: The name org.freedesktop.PolicyKit1 was not 
provided by any .service files
  Running it as root to enable lingering for a user worked.

-- 
see shy jo, adding ! Systemd.killUserProcesses to his propellor config


signature.asc
Description: PGP signature

Bug#824042: gets into kill/restart loop

[Joey Hess]

Package: clamav-daemon
Version: 0.99.1+dfsg-1+b2
Severity: normal

clamav-daemon got into a loop on my server where it was being killed and
restarting multiple times per second. This spiked load to 100.
Basically a weak fork bomb.

I tried systemctl stop clamav but it just started right up again.
In the end, I rebooted, which "fixed" the problem.

Looks like it was being killed each time by the OOM killer. Which makes
sense; clamav uses 18% of the system's 2 gb of ram and so will be the
top target.

I think there should be something to prevent this runaway scenario.
Maybe a delay, or maybe avoid restarting repeatedly.

May  8 13:58:14 kite kernel: [12577316.169029] Out of memory: Kill
process 14646 (clamd) score 115 or sacrifice child
May  8 13:58:14 kite kernel: [12577316.169043] Killed process 14646
(clamd) total-vm:425680kB, anon-rss:264680kB, file-rss:0kB
May  8 13:58:29 kite kernel: [12577330.925647] Out of memory: Kill
process 14662 (clamd) score 115 or sacrifice child
May  8 13:58:29 kite kernel: [12577330.925663] Killed process 14662
(clamd) total-vm:425936kB, anon-rss:264684kB, file-rss:12kB

Sun May  8 07:32:30 2016 -> +++ Started at Sun May  8 07:32:30 2016
Sun May  8 07:32:30 2016 -> Received 1 file descriptor(s) from systemd.
Sun May  8 07:32:30 2016 -> clamd daemon 0.99.1 (OS: linux-gnu, ARCH: x86_64, 
CPU: x86_64)
Sun May  8 07:32:30 2016 -> Running as user clamav (UID 112, GID 119)
Sun May  8 07:32:30 2016 -> Log file size limited to 4294967295bytes.
Sun May  8 07:32:30 2016 -> Reading databases from /var/lib/clamav
Sun May  8 07:32:30 2016 -> Not loading PUA signatures.
Sun May  8 07:32:30 2016 -> Bytecode: Security mode set to "TrustSigned".
Sun May  8 13:32:30 2016 -> +++ Started at Sun May  8 13:32:30 2016
Sun May  8 13:32:30 2016 -> Received 1 file descriptor(s) from systemd.
Sun May  8 13:32:30 2016 -> clamd daemon 0.99.1 (OS: linux-gnu, ARCH: x86_64, 
CPU: x86_64)
Sun May  8 13:32:30 2016 -> Running as user clamav (UID 112, GID 119)
Sun May  8 13:32:30 2016 -> Log file size limited to 4294967295bytes.
Sun May  8 13:32:30 2016 -> Reading databases from /var/lib/clamav
Sun May  8 13:32:30 2016 -> Not loading PUA signatures.
Sun May  8 13:32:30 2016 -> Bytecode: Security mode set to "TrustSigned".
Sun May  8 13:32:39 2016 -> +++ Started at Sun May  8 13:32:39 2016
Sun May  8 13:32:39 2016 -> Received 1 file descriptor(s) from systemd.
Sun May  8 13:32:39 2016 -> clamd daemon 0.99.1 (OS: linux-gnu, ARCH: x86_64, 
CPU: x86_64)
Sun May  8 13:32:39 2016 -> Running as user clamav (UID 112, GID 119)
Sun May  8 13:32:39 2016 -> Log file size limited to 4294967295bytes.
Sun May  8 13:32:39 2016 -> Reading databases from /var/lib/clamav
Sun May  8 13:32:39 2016 -> Not loading PUA signatures.
Sun May  8 13:32:39 2016 -> Bytecode: Security mode set to "TrustSigned".
Sun May  8 13:32:50 2016 -> +++ Started at Sun May  8 13:32:50 2016
Sun May  8 13:32:50 2016 -> Received 1 file descriptor(s) from systemd.
Sun May  8 13:32:50 2016 -> clamd daemon 0.99.1 (OS: linux-gnu, ARCH: x86_64, 
CPU: x86_64)
Sun May  8 13:32:50 2016 -> Running as user clamav (UID 112, GID 119)
Sun May  8 13:32:50 2016 -> Log file size limited to 4294967295bytes.
Sun May  8 13:32:50 2016 -> Reading databases from /var/lib/clamav
Sun May  8 13:32:50 2016 -> Not loading PUA signatures.
Sun May  8 13:32:50 2016 -> Bytecode: Security mode set to "TrustSigned".

May 11 09:09:53 kite systemd[1]: clamav-daemon.service: Main process exited, 
code=killed, status=9/KILL
May 11 09:09:53 kite systemd[1]: clamav-daemon.service: Unit entered failed 
state.
May 11 09:09:53 kite systemd[1]: clamav-daemon.service: Failed with result 
'signal'.
May 11 09:09:53 kite systemd[1]: Started Clam AntiVirus userspace daemon.
May 11 09:10:07 kite systemd[1]: clamav-daemon.service: Main process exited, 
code=killed, status=9/KILL
May 11 09:10:07 kite systemd[1]: clamav-daemon.service: Unit entered failed 
state.
May 11 09:10:07 kite systemd[1]: clamav-daemon.service: Failed with result 
'signal'.
May 11 09:10:07 kite systemd[1]: Started Clam AntiVirus userspace daemon.
May 11 09:10:30 kite systemd[1]: clamav-daemon.service: Main process exited, 
code=killed, status=9/KILL
May 11 09:10:30 kite systemd[1]: clamav-daemon.service: Unit entered failed 
state.
May 11 09:10:30 kite systemd[1]: clamav-daemon.service: Failed with result 
'signal'.
May 11 09:10:30 kite systemd[1]: Started Clam AntiVirus userspace daemon.
May 11 09:11:02 kite systemd[1]: clamav-daemon.service: Main process exited, 
code=killed, status=9/KILL
May 11 09:11:02 kite systemd[1]: clamav-daemon.service: Unit entered failed 
state.
May 11 09:11:02 kite systemd[1]: clamav-daemon.service: Failed with result 
'signal'.
May 11 09:11:02 kite systemd[1]: Started Clam AntiVirus userspace daemon.
May 11 09:11:18 kite systemd[1]: clamav-daemon.service: Main process exited, 
code=killed, status=9/KILL
May 11 09:11:18 kite systemd[1]: clamav-daemon.service: Unit entered failed 
state.
May 11 09:11:18 

Bug#823558: synaptics stopped being used on Lenovo Yoga laptop

[Joey Hess]

Package: xserver-xorg-input-synaptics
Version: 1.8.3-1+b1
Severity: normal

I rebooted today with the touchpad working fine and it came back up with
it messed up (bad accelleration, no tap click). For some reason, X
stopped using the synaptics driver for it and fell back to libinput
instead. Rebooting didn't help, still libinput.

My laptop is a Lenovo Yoga 11gs, and has a clickpad and a touch screen.
I last upgraded this package in February and have certianly rebooted
since then, but may have upgraded some stuff in the past week that broke
it.

The xorg log file did not show it loading the synaptics module at all.
I tried adding an xorg.conf.d to force it to load:

Section "Module"
Load "synaptics"
EndSection

While the module loaded, it was still not used for the touchpad.
The resulting log file is attached as Xorg.0.log.old.

I was finally able to workaround the problem by forcing 
use of the synaptics driver:

Section "Module"
Load "synaptics"
EndSection

Section "InputClass"
Identifier "touchpad tweaked catchall"
MatchIsTouchpad "on"
Driver "synaptics"
EndSection

The logs below are from starting X in that configuration.

One thing I noticed in the logs when X didn't use synaptics is


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jul  2  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Apr  5 03:05 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0a1e] 
(rev 0b)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 173 May  5 18:25 synaptics.conf

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.5.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160424 (Debian 5.3.1-16) ) #1 SMP Debian 4.5.2-1 (2016-04-28)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  6592 Sep  8  2014 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 29042 Apr 25  2015 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 24584 May  5 18:26 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   910.095] 
X.Org X Server 1.18.3
Release Date: 2016-04-04
[   910.095] X Protocol Version 11, Revision 0
[   910.095] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[   910.095] Current Operating System: Linux darkstar 4.5.0-2-amd64 #1 SMP 
Debian 4.5.2-1 (2016-04-28) x86_64
[   910.095] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-2-amd64 
root=UUID=1619e79b-7dc8-46a1-af37-824e461ea961 ro quiet
[   910.095] Build Date: 05 April 2016  07:00:43AM
[   910.095] xorg-server 2:1.18.3-1 (http://www.debian.org/support) 
[   910.095] Current version of pixman: 0.33.6
[   910.095]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   910.095] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   910.095] (==) Log file: "/var/log/Xorg.0.log", Time: Thu May  5 18:26:06 
2016
[   910.095] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   910.095] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   910.095] (==) No Layout section.  Using the first Screen section.
[   910.095] (==) No screen section available. Using defaults.
[   910.095] (**) |-->Screen "Default Screen Section" (0)
[   910.095] (**) |   |-->Monitor ""
[   910.095] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   910.095] (==) Automatically adding devices
[   910.095] (==) Automatically enabling devices
[   910.095] (==) Automatically adding GPU devices
[   910.095] (==) Max clients allowed: 256, resource mask: 0x1f
[   910.095] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   910.095]Entry deleted from font path.
[   910.095] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   910.095] (==) ModulePath set to "/usr/lib/xorg/modules"
[   910.095] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   910.095] (II) Loader magic: 0x558ae86bfdc0
[   910.095] (II) Module ABI versions:
[   910.096]X.Org ANSI C Emulation: 0.4
[   910.096]X.Org Video 

Bug#820823: too many mboxes

[Joey Hess]

Package: mairix
Version: 0.23+git20131125-0.4
Severity: normal

Too many mboxes (max 65536, you have 71571)

Well yes, I have a lot of mboxes. I'm not quite sure where mairix is
getting the 71571 figure from, since my ~/mail contains only 19734
files and some of those are git repository stuff and not mboxes.
I tried deleting .mairix_database and mairix stopped complaining, so
perhaps it had some old cached info and its count was off.

I have stuff like daily mboxes for spam and for viruses, daily mboxes
for all mail before any filtering, etc. So it's not inconceivable I'll
really reach 65k mailboxes some day. Can this limit be increased to
something less likely to be reachable?

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mairix depends on:
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.22-5
ii  zlib1g  1:1.2.8.dfsg-2+b1

mairix recommends no packages.

mairix suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#819365: assword gui fails to start when stderr is closed

[Joey Hess]

The reason my WM did not have stderr/stdout available is, I had started
it from a terminal, disowned it, and then closed the terminal. So,
stderr was pointing at /dev/pts/2, which had been deallocated.

That's probably not an entirely original way to shoot oneself in the
foot; I'm sure I've done that plenty of times before and just didn't try
to run anything from the WM that expected to be able to write to stderr.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#819365: assword gui fails to start when stderr is closed

[Joey Hess]

Package: assword
Version: 0.8-2.1
Severity: normal

Had a weird thing where my window manager's hotkey to start assword gui
stopped doing anything. Apparently assword is trying to print out a warning
(WARNING: could not validate OpenPGP signature on db file) and for some reason
stderr is closed, so it crashes

write(2, "print >>sys.stderr, \"WARNING: co"..., 80) = -1 EIO (Input/output 
error)
close(4)= 0
munmap(0x7fea62219000, 4096)= 0
write(2, "IOError", 7)  = -1 EIO (Input/output error)
write(2, ": ", 2)   = -1 EIO (Input/output error)
write(2, "[Errno 5] Input/output error", 28) = -1 EIO (Input/output error)
write(2, "\n", 1)   = -1 EIO (Input/output error)

I have no idea why my window manager is suddenly running the program with a
closed or unwritable stderr, but probably crashing in this situation is not
useful, so how about you catch this exception so that the gui can still
display. Especially since the gui helpfully displays the same warning..

To reproduce:

joey@darkstar:~>assword gui 2>/dev/full
- exit 1

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages assword depends on:
ii  python2.7.11-1
ii  python-gpgme  0.3-1.1+b1
ii  python-gtk2   2.24.0-4
ii  python-pkg-resources  20.1.1-1

Versions of packages assword recommends:
ii  python-xdo  0.2-2
ii  xclip   0.12+svn84-4

assword suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#818428: lost wlan0 (r8723au) on upgrade

[Joey Hess]

Package: network-manager
Version: 1.1.91-3
Severity: normal

nmcli list no longer lists my wlan0 device. It's still there in
iwconfig. Other (external) wifi devices are still listed and work.

This was caused by the upgrade to this version of network-manager.
Downgrading to 1.1.90-6 got it managing wlan0 again.

Before that solution, I tried restarting network-manager, rebooting,
etc. Nothing worked.

Oddly, after the downgrade fixed the problem, I re-upgraded and now 
this version is managing wlan0. Hmm, something fishy going on.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.114
ii  dbus   1.10.8-1
ii  init-system-helpers1.29
ii  isc-dhcp-client4.3.3-9
ii  libbluetooth3  5.36-1
ii  libc6  2.22-3
ii  libglib2.0-0   2.46.2-3
ii  libgnutls303.4.9-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.4.12-1
ii  libndp01.4-2
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.1.91-3
ii  libpam-systemd 229-2
ii  libpolkit-agent-1-00.105-14.1
ii  libpolkit-gobject-1-0  0.105-14.1
ii  libreadline6   6.3-8+b4
ii  libsoup2.4-1   2.52.2-1
ii  libsystemd0229-2
ii  libteamdctl0   1.23-1
ii  libuuid1   2.27.1-6
ii  lsb-base   9.20160110
ii  policykit-10.105-14.1
ii  udev   229-2
ii  wpasupplicant  2.3-2.3

Versions of packages network-manager recommends:
ii  crda3.13-1+b1
pn  dnsmasq-base
ii  iptables1.6.0-2
pn  iputils-arping  
pn  modemmanager
ii  ppp 2.4.7-1+2

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#818428: Acknowledgement (lost wlan0 (r8723au) on upgrade)

[Joey Hess]

Seem to be able to reproduce the problem by upgrading and rebooting.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#817067: clamscan large archive DOS protection could be used to hide virus

[Joey Hess]

Package: clamav
Version: 0.99+dfsg-2
Severity: important
Tags: security

Any script relying on clamscan's exit status can probably be tricked
with a file that contains a virus, but that uses clamscan's DOS
protection to trick clamscan into not scanning it in full.

Unfortunately, when a file is too large or otherwise triggers the DOS
protections, clamscan exits 0 without checking all of it.

clamscan git-annex.dmg 
git-annex.dmg: OK

--- SCAN SUMMARY ---
Known viruses: 4291311
Engine version: 0.99
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.00 MB
Data read: 25.35 MB (ratio 0.00:1)
Time: 8.958 sec (0 m 8 s)

The dmg in the example above could contain a virus. It's too large for
clamscan to process it, but there's no indication of that, except
perhaps a hint in the 0 MB scanned line.

Suggested fix: If clamscan doesn't process the whole file content for
any reason, exit with 2, which is documented to mean "some error
occurred".

-- 
see shy jo

Bug#816860: stable backport, please

[Joey Hess]

Package: haskell-stack
Version: 0.1.10.0-1
Severity: normal

There's currently no way to get stack installed on stable w/o
downloading a binary from a third party, without any means of
verification. 

The source depends on a newer base than stable's ghc currently has.
So, it might be somewhat tricky to backport it.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#816837: dropped .ed.date.gz files in cwd

[Joey Hess]

Package: apt
Version: 1.2.3
Severity: normal
Tags: security

I ran sudo apt-get update in a directory (~/src/git-annex), interrupted it,
and noticed all these temp files, which contain ed diffs to Packages.

-rw-r--r-- 1 root root   29 Feb 23 23:06 .ed.2016-02-24-0258.17.gz
-rw-r--r-- 1 root root  949 Feb 24 04:57 .ed.2016-02-24-0852.43.gz
-rw-r--r-- 1 root root  12K Feb 24 11:09 .ed.2016-02-24-1501.06.gz
-rw-r--r-- 1 root root  36K Feb 24 16:54 .ed.2016-02-24-2052.14.gz
-rw-r--r-- 1 root root   44 Feb 24 22:52 .ed.2016-02-25-0249.22.gz
-rw-r--r-- 1 root root  22K Feb 25 04:57 .ed.2016-02-25-0855.02.gz

As well as being the wrong place to put temp files, this could be exploitable,
since a regular user can replace these files with malicious ones.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
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\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.3\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.2\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.3\.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::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";

Bug#815674: no indication when not connected

[Joey Hess]

Package: hexchat
Version: 2.10.2-1+b3
Severity: normal

I often find myself typing into a channel when hexchat is not connected
to the server. In this situation, there is no indication that ones's
words are vanishing into the void.

For example, this morning I opened my laptop at the coffee shop, and an
hour later went to a channel and wrote something. Hexchat seemed to
think it was connected like it was when I suspended the laptop last
night; there was no error and the channel did not appear disconnected.
But nothing was sent.

I seem to have to manually /reconnect before trying to use IRC. And
that's for sending; I have no way to know if it's really connected and
the channel is idle or if it's disconnected.

Hexchat seems possibly worse at this than xchat, although I have not
figured out quite why.

I'm connecting to a znc bouncer, if it matters.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hexchat depends on:
ii  hexchat-common   2.10.2-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-8
ii  libcairo21.14.6-1
ii  libcanberra0 0.30-2.1
ii  libdbus-1-3  1.10.6-1
ii  libdbus-glib-1-2 0.106-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libglib2.0-0 2.46.2-3
ii  libgtk2.0-0  2.24.29-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libproxy1v5  0.4.11-4.2
ii  libssl1.0.2  1.0.2f-2

Versions of packages hexchat recommends:
ii  gvfs-bin 1.26.2-1+b1
ii  hexchat-perl 2.10.2-1+b3
ii  hexchat-plugins  2.10.2-1+b3
ii  hexchat-python   2.10.2-1+b3

Versions of packages hexchat suggests:
pn  unifont  

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#815103: memory use increases with more files; OOM

[Joey Hess]

> 366 added objects in 5 minutes, and the memory increased by 55 mb.

The meliae dumps for that time period grew from 807 mb to 813 mb.
I don't know if that 6 mb of serialized data could use 55 mb in memory
or not.

Of the 3556035 lines in the last meliae dump, 3394078 were of type: str.
The breakdown of which by len is:

1542175 18
 380340 8
 340319 48
 222324 168

The length 18 strings looked like binary data, so if part of obnam
generates 18 character wide strings (perhaps as a packed data structure),
that might point at what is using most of the space.

{"address": 139975408226352, "type": "str", "size": 55, "len": 18, "value": 
"\u0001?:\u00d0\\\u00d0\u0082\u00f8C\urm\u00b8\u00c9\u00fbo\u0010_", 
"refs": []}
{"address": 139975408226408, "type": "str", "size": 55, "len": 18, "value": 
"\up}\u00d4.\u00ac\u00cak\u0001\u0003\u\u\u\u\u\u\u\u",
 "refs": []}
{"address": 139975408226464, "type": "str", "size": 55, "len": 18, "value": 
"\u 0{c\u0092\u00da\u00b7*\u 0{c\u0092\u00da\u00b7*", "refs": []}
{"address": 139975408226520, "type": "str", "size": 55, "len": 18, "value": 
"\u\u0012\u0004K]\u009d\u00a3]\u0095\urm\u00b8\u00c9\u00fbo\u0010_", 
"refs": []}

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#815103: memory use increases with more files; OOM

[Joey Hess]

Lars Wirzenius wrote:
> Hmm. The number of Python objects seems to be pretty steady, but the
> memory use keeps going up. That seems to indicate a memory leak
> somewhere.

Well, the number of objects seems to be going up over time.
366 added objects in 5 minutes, and the memory increased by 55 mb.
If 154 kb per object is a feasible amount, the objects could explain all
of the memory growth.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#815103: correction

[Joey Hess]

System has 2gb of memory, but 1gb is in use, so obnam "only" grows to 1gb.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#815103: memory use increases with more files; OOM

[Joey Hess]

Package: obnam
Version: 1.19.1-1
Severity: normal

obnam grows in size to fill all 2 gb of memory on the system and OOMs.
Memory use seems to increase the more files are backed up. I did try
setting lru-size to half of the default, but this did not change much
memory use.

I have a meliae profile of a backup of 100k files, most of which are
unchanged from the previous backup, which shows memory growing pretty
steadily over time. Since the log and profile files contain filenames, I
don't want to publish them here, but can send them on request. (500 mb
of compressed log files).

Summarizing it:

2016-02-18 14:31:23 DEBUG VmRSS: 113736 KiB
2016-02-18 14:31:23 DEBUG # objects: 17780
2016-02-18 14:31:23 DEBUG # garbage: 0
2016-02-18 14:31:23 DEBUG memory profile: see obnam-0.meliae

2016-02-18 15:30:09 DEBUG VmRSS: 460780 KiB
2016-02-18 15:30:09 DEBUG # objects: 20649
2016-02-18 15:30:09 DEBUG # garbage: 0
2016-02-18 15:30:09 DEBUG memory profile: see obnam-1.meliae


2016-02-18 15:35:09 DEBUG VmRSS: 517528 KiB
2016-02-18 15:35:09 DEBUG # objects: 21015
2016-02-18 15:35:09 DEBUG # garbage: 0
2016-02-18 15:35:09 DEBUG memory profile: see obnam-2.meliae

2016-02-18 15:40:11 DEBUG VmRSS: 552868 KiB
2016-02-18 15:40:11 DEBUG # objects: 21752
2016-02-18 15:40:11 DEBUG # garbage: 0
2016-02-18 15:40:11 DEBUG memory profile: see obnam-3.meliae

2016-02-18 15:45:11 DEBUG VmRSS: 562648 KiB
2016-02-18 15:45:11 DEBUG # objects: 22262
2016-02-18 15:45:11 DEBUG # garbage: 0
2016-02-18 15:45:11 DEBUG memory profile: see obnam-4.meliae

2016-02-18 15:51:21 DEBUG VmRSS: 565000 KiB
2016-02-18 15:51:21 DEBUG # objects: 22545
2016-02-18 15:51:21 DEBUG # garbage: 0
2016-02-18 15:51:21 DEBUG memory profile: see obnam-5.meliae

Presumably this continues growing, and reaches 2 gb before obnam has
finished with all 42 files on this system.


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

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages obnam depends on:
ii  libc6 2.21-8
ii  python2.7.11-1
ii  python-cliapp 1.20160109-1
ii  python-fuse   2:0.2.1-11
ii  python-larch  1.20151025-1
ii  python-paramiko   1.15.3-1
ii  python-tracing0.9-1
ii  python-ttystatus  0.32-1
ii  python-yaml   3.11-3

obnam recommends no packages.

obnam suggests no packages.

-- no debconf information

-- 
see shy jo

Bug#814257: debug logging support

[Joey Hess]

Source: haskell-dav
Severity: wishlist

It would be helpful if there were a way to cause http requests made
by this library to be fed into logging machinery. http protocol dumps
can be super useful in debugging the kind of protocol issues that seem
to plague DAV.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#814052: should delete .well-known/acme-challenge when it's done with it

[Joey Hess]

Package: letsencrypt
Version: 0.2.0-1
Severity: normal

Running letsencrypt creates  .well-known/acme-challenge/ in the web
root. After it's done, this directory is left, empty. It would be better
for both directories to be deleted, unless something else happens to be
in them.

It violates least surprise for a directory that is essentially
an implementation detail to be left hanging around when it's no longer
needed.

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages letsencrypt depends on:
ii  dialog  1.2-20150920-1
ii  python-letsencrypt  0.2.0-1
pn  python:any  

letsencrypt recommends no packages.

Versions of packages letsencrypt suggests:
pn  python-letsencrypt-apache  
pn  python-letsencrypt-doc 

-- no debconf information

-- 
see shy jo

Bug#814055: has broken binding to libgnutls-deb0.so.28

[Joey Hess]

Yaroslav Halchenko wrote:
> # ldd 
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.10.3/network-protocol-xmpp-0.4.8-AArRa3ialU19Kz62aVPiMC/libHSnetwork-protocol-xmpp-0.4.8-AArRa3ialU19Kz62aVPiMC-ghc7.10.3.so
>  | grep gnutls-deb
> libgnutls-deb0.so.28 => not found

joey@darkstar:~>dpkg -S libgnutls-deb0.so.28
libgnutls-deb0-28:amd64: /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
libgnutls-deb0-28:amd64: /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28.41.12

But, libghc-gnutls-dev now depends on libgnutls30. Seems that 
libghc-network-protocol-xmpp-dev was not updated after that change..

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#813844: depend on xz-utils, gcc

[Joey Hess]

Package: haskell-stack
Version: 0.1.10.0-1
Severity: normal

stack setup fails in a clean chroot, until xz-utils and gcc are
installed. I suggest making these be dependencies.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages haskell-stack depends on:
ii  libc6 2.21-7
ii  libffi6   3.2.1-4
ii  libgmp-dev2:6.1.0+dfsg-2
ii  libgmp10  2:6.1.0+dfsg-2
ii  libsqlite3-0  3.10.2-1
ii  libyaml-0-2   0.1.6-3
ii  make  4.1-5
ii  zlib1g1:1.2.8.dfsg-2+b1

haskell-stack recommends no packages.

haskell-stack suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#812380: apt warns about /apt/apt.conf.d/50unattended-upgrades.ucf-dist

[Joey Hess]

Package: unattended-upgrades
Version: 0.86.5+build1
Severity: normal

Since I have the config file modified, every upgrade of
unattended-upgrades drops a .ucf-dist copy, which causes every run of
apt to warn about the file being ignored.

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unattended-upgrades depends on:
ii  apt1.2
ii  apt-utils  1.2
ii  debconf [debconf-2.0]  1.5.58
ii  init-system-helpers1.24
ii  lsb-base   9.20160110
ii  lsb-release9.20160110
ii  python33.5.1-1
ii  python3-apt1.1.0~beta1
ii  ucf3.0031
ii  xz-utils   5.1.1alpha+20120614-2.1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-128

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx   8.1.2-0.20150408cvs-1
ii  postfix [mail-transport-agent]  2.11.3-1+b1

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed [not included]

-- debconf information excluded

-- 
see shy jo

Bug#807968: RFP: haskell-gitlib-libgit2 -- Libgit2 backend for gitlib (haskell)

[Joey Hess]

Package: wnpp
Severity: wishlist

* Package name: haskell-gitlib-libgit2
* URL : http://hackage.haskell.org/package/gitlib-libgit2
* License : BSD
  Programming Lang: haskell
  Description : Libgit2 backend for gitlib (haskell)

Debian includes haskell-gitlib, but that only provides some types and
can't be used for anything without a backend like this one. Neither this
backend nor gitlib-cmdline are in Debian. I am considering using this in
git-annex.

Note that gitlib-libgit2 depends on hlibgit2, which happens to contain
an embedded code copy of gitlib2. I guess debianization would include
patching it to build against an appropriate system version of gitlib2,
although that added dependency may complicate matters.

A few issues that probably bear on packaging hlibgit2:

* https://github.com/jwiegley/gitlib/issues/43
  The version of libgit2 bundled with hlibgit2 is currently 0.18,
  which is older than the versions in Debian. This may make it hard
  to build the package against the system libgit2. (Haven't tried.)

* https://github.com/jwiegley/gitlib/issues/58
  The embedded copy of gitlib2 doesn't include its license text due to
  an oversight.
  
-- 
see shy jo


signature.asc
Description: PGP signature

Bug#807592: lease update to 0.13.0

[Joey Hess]

Source: haskell-aws
Version: 0.11.4
Severity: normal

0.13.0 adds support for the STANDARD_IA storage class, as well as google
nearline. git-annex users would like to save money by using these
features.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#806644: Fwd: Bug#806644: git-annex: can't add files with names >= 127 characters

[Joey Hess]

When people complain of 127 characters and filesystems, my first thought
is "encfs" and my second thought is an expletive.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#806677: prompts unncessarily for password for fish:// login

[Joey Hess]

Package: lftp
Version: 4.6.3a-1
Severity: normal

When the ssh server is configured to allow login via authorized_keys,
using lftp to connect to it with fish:// results in it prompting for a
password despite no password being needed. The password entered is never
used.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (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.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lftp depends on:
ii  libc6  2.19-22
ii  libgcc11:5.2.1-23
ii  libgnutls-deb0-28  3.3.18-1
ii  libidn11   1.32-3
ii  libreadline6   6.3-8+b3
ii  libstdc++6 5.2.1-23
ii  libtinfo5  6.0+20151024-1
ii  netbase5.3
ii  zlib1g 1:1.2.8.dfsg-2+b1

lftp recommends no packages.

lftp suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#806163: d-i's hardcoded list of groups should be moved to this package

[Joey Hess]

Package: base-passwd
Version: 3.5.38
Severity: normal

Suggest that user-setup's list of groups in its
passwd/user-default-groups debconf template be moved (or copied) to
base-passwd.

This list does not currently seem to be available anywhere on an
installed Debian system. This makes it unncessarily hard to set up a
second (or perhaps first) desktop user in the right groups for
everything to work.

FWIW, I need it in a machine-readable form. So I've currently had to
make a copy of it, which will appear in the next update to propellor to
reach Debian.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#803405: worakaround

[Joey Hess]

Since this was getting very annoying, I wrote this script:

#!/bin/sh
/usr/bin/mutt "$@"
ret="$?"
/bin/echo -e '\e[0m'
exit "$ret"

Which also shows that a SGR reset is all that's missing.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#803405: does not properly restore console colors on exit anymore

[Joey Hess]

Package: mutt
Version: 1.5.24-1
Severity: normal

Before upgrading to mutt 1.5.24, I could run mutt, press 'q' and 
the shell prompt was the same color as it was before mutt ran.
Now, after quitting mutt, the color setting is apparently left at
light grey on black. I have to run `reset` to fix it.

See attached screenshot.

-- Package-specific info:
Mutt 1.5.24 (2015-08-30)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.2.0-1-amd64 (x86_64)
ncurses: ncurses 6.0.20151024 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-17' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20150911 (Debian 5.2.1-17) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch
debian-specific/document_debian_defaults.patch
debian-specific/assumed_charset-compat.patch
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.patch
misc/gpg.rc-paths.patch
misc/smime.rc.patch
misc/fix-configure-test-operator.patch
upstream/531430-imapuser.patch
upstream/543467-thread-segfault.patch
upstream/548577-gpgme-1.2.patch
upstream/553321-ansi-escape-segfault.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/603288-split-fetches.patch
upstream/611410-no-implicit_autoview-for-text-html.patch

Bug#803406: does not properly restore console colors on exit anymore

[Joey Hess]

Package: mutt
Version: 1.5.24-1
Severity: normal

Before upgrading mutt to this version, running mutt and then exiting
returned the terminal to how it was before. As of this version, the
screen colors are not restored. Workaround: reset

See attached screenshot.

-- Package-specific info:
Mutt 1.5.24 (2015-08-30)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.2.0-1-amd64 (x86_64)
ncurses: ncurses 6.0.20151024 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-17' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20150911 (Debian 5.2.1-17) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch
debian-specific/document_debian_defaults.patch
debian-specific/assumed_charset-compat.patch
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.patch
misc/gpg.rc-paths.patch
misc/smime.rc.patch
misc/fix-configure-test-operator.patch
upstream/531430-imapuser.patch
upstream/543467-thread-segfault.patch
upstream/548577-gpgme-1.2.patch
upstream/553321-ansi-escape-segfault.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/603288-split-fetches.patch
upstream/611410-no-implicit_autoview-for-text-html.patch
upstream/771125-CVE-2014-9116-jessie.patch

Bug#786549: much simpler approach: rsyncd package

[Joey Hess]

I'm at this bug because my rsync server, which was working, failed to
start rsyncd on reboot. Apparently the systemd service is disabled,
the instuctions I had followed to enable the daemon are out of date,
etc.

This is a silly amount of complexity and growing. Just split out a
rsyncd package for those of us who want the daemon, and have it enable
the daemon by default. Pick a directory, empty by default, and have the
default /etc/rsyncd.conf export it, read-only. 

Make apt-get install rsyncd result in a fully working rsyncd starting
point for the admin to tweak, rather than apt-get install rsync yielding
a bunch of daemon bits and peices that can be cobbled together.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#802717: nexpected os-prober when setting up grub in a disk image

[Joey Hess]

Package: grub-pc
Version: 2.02~beta2-28
Severity: normal

I'm creating a disk image, which I want to be bootable using grub.
Unexpectedly, update-grub runs os-prober which probes the host system
and adds unwanted entries for it.

In the transcript below, /mnt is a loop mounted filesystem from my disk image.
I used kpartx to set up the loop device for the partition inside the disk image.

I bind mount /dev from the host system because this seems to be
necessary to let update-grub figure out that it's being run in a disk
image (by giving it access to /dev/mapper etc).
(Also because vmdebootstrap does it..)

root@darkstar:/mnt>mount --bind /dev dev
root@darkstar:/mnt>chroot . 
root@darkstar:/# mount -t sysfs sys /sys
root@darkstar:/# mount -t proc proc /proc
root@darkstar:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.2.0-1-amd64
Found initrd image: /boot/initrd.img-4.2.0-1-amd64
Found Windows 8 (loader) on /dev/sda2
Found Debian GNU/Linux (stretch/sid) on /dev/sda3
done
root@darkstar:/mnt>grub-install /dev/loop2 
Installing for i386-pc platform.
Installation finished. No error reported.

The result is, grub boots fine using this disk image, but the menu has
unexpected entries, from os-prober, for the system where it was built.

I think the only reason that vmdebootstrap images don't experience this
problem is because it doesn't install os-prober by default. However, I'd
like to include os-prober on my image, if possible.

Could the os-prober hook perhaps notice when the root is a loopback
image, and avoid probing the host system?

Temporary workaround: chmod -x /etc/grub.d/30_os-prober 

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda3 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sdb1 /media/flash ext4 
rw,sync,nosuid,nodev,noexec,relatime,errors=remount-ro,data=ordered 0 0
/dev/mapper/loop2p1 /mnt ext4 rw,relatime,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-SAMSUNG_MZMPC128HBFU-000L1_S0Y4NEAD923930
(hd1)   /dev/disk/by-id/usb-Generic_Mass_storage_gsgsmt07211218000816-0:0
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 
--hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 --hint='hd0,gpt3'  
1619e79b-7dc8-46a1-af37-824e461ea961
else
  search --no-floppy --fs-uuid --set=root 1619e79b-7dc8-46a1-af37-824e461ea961
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 
--hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 --hint='hd0,gpt3'  
1619e79b-7dc8-46a1-af37-824e461ea961
else
  search --no-floppy --fs-uuid --set=root 1619e79b-7dc8-46a1-af37-824e461ea961
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub-1920x1080.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN 

Bug#800067: should depend on xz-utils

[Joey Hess]

Package: haskell-stack
Version: 0.1.2.0-1
Severity: normal

stack setup fails in a fresh sid chroot:

Downloaded ghc-7.10.2.
The following executables are missing and must be installed: xz

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

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

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#800068: should depend on gcc or clang

[Joey Hess]

Package: haskell-stack
Version: 0.1.2.0-1
Severity: normal

stack setup fails in a fresh sid choot:

checking for gcc... no
checking for clang... no
configure: error: cannot find gcc nor clang in your PATH

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

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

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#800066: depends on ca-certificates

[Joey Hess]

Package: haskell-stack
Version: 0.1.2.0-1
Severity: normal

Using stack setup in a fresh sid chroot fails:

TlsException (HandshakeFailed (Error_Protocol ("certificate has unknown 
CA",True,UnknownCa)))

It needs to depend on ca-certificates.

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

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

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#800065: new upstream release

[Joey Hess]

Package: haskell-stack
Version: 0.1.2.0-1
Severity: normal

This version is probably considerably behind the current upstream
0.1.5.0 release. In particular, I am looking for the --local-bin-path
option; it's annoying to not be able to direct debian users of stack to
use this option.

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

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

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#776424: debug output

[Joey Hess]

My kgb bot didn't crash again until now, when I've had 2 crashes over 4 days,
with debug enabled:

2015.09.18 07:26:35: irc_raw_out 'PONG :irc.teksavvy.ca' 
2015.09.18 07:27:24: irc_raw 'PING :kornbluth.freenode.net' 
2015.09.18 07:27:24: irc_ping 'kornbluth.freenode.net' 
2015.09.18 07:27:24: irc_raw_out 'PONG :kornbluth.freenode.net' 
Did not get DONE/CLOSE event for Wheel ID 742 from IP 222.186.34.194 at 
/usr/share/perl5/POE/Component/Server/SimpleHTTP.pm line 221.
2015.09.18 07:28:15: _child 'lose' 'POE::Session=ARRAY(0x394c360)' undef 
2015.09.18 07:28:15: _child 'lose' 'POE::Session=ARRAY(0x395e0b0)' undef 
2015.09.18 07:28:15: _child 'lose' 'POE::Session=ARRAY(0x3964520)' undef 
2015.09.18 07:28:15: _stop @session 3
I had a problem posting to event Got_Request of session SOAPServer for DIR 
handler '.*'. As reported by Kernel: 'No such file or directory', perhaps the 
session name is spelled incorrectly for this handler? at 
/usr/share/perl5/POE/Session.pm line 483.


2015.09.22 02:18:58: irc_ping 'wolfe.freenode.net' 
2015.09.22 02:18:58: irc_raw_out 'PONG :wolfe.freenode.net' 
2015.09.22 02:20:08: irc_raw 'PING :graviton.oftc.net' 
2015.09.22 02:20:08: irc_ping 'graviton.oftc.net' 
2015.09.22 02:20:08: irc_raw_out 'PONG :graviton.oftc.net' 
Did not get DONE/CLOSE event for Wheel ID 29 from IP 222.186.34.194 at 
/usr/share/perl5/POE/Component/Server/SimpleHTTP.pm line 221.
2015.09.22 02:21:22: _child 'lose' 'POE::Session=ARRAY(0x4d7fda0)' undef 
2015.09.22 02:21:22: _child 'lose' 'POE::Session=ARRAY(0x4d6e070)' undef 
2015.09.22 02:21:22: _child 'lose' 'POE::Session=ARRAY(0x4d86210)' undef 
2015.09.22 02:21:22: _stop @session 3
I had a problem posting to event Got_Request of session SOAPServer for DIR 
handler '.*'. As reported by Kernel: 'No such file or directory', perhaps the 
session name is spelled incorrectly for this handler? at 
/usr/share/perl5/POE/Session.pm line 483.


Note that's the same class C that crashed kgb back in January.
http://www.abuseipdb.com/report-history/222.186.34.194 says this IP
engages in port scanning and perhaps hacking/DDOS.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#799286: setup puts auth token in ~/.git/config

[Joey Hess]

Package: git-hub
Version: 0.9.0-1
Severity: normal

I have my home in git, and running git hub setup put the auth in
~/.git/config. This prevented git hub clone from working, since I ran it
elsewhere and it didn't look at that config. Moving the auth token to
~/.gitconfig worked. Suggest passing --global when setting this.

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

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

Versions of packages git-hub depends on:
ii  git 1:2.5.0-1
ii  python  2.7.9-1

git-hub recommends no packages.

git-hub suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#799111: classic tiles page forgets file:/// urls

[Joey Hess]

Package: iceweasel
Version: 38.1.0esr-3
Severity: normal

I have a file:/// url I access every day. That showed up in the new tab
tiles as expected. It's even pinned there.

Recently, that tile has gone missing from the page, a blank space is
where it should be. If I manually open the file:/// url, and then open a
new tab, the tile comes back, and remains in the new tab page until I
close firefox. Each time I close it, it forgets about this one tile again.

(In case it matters, the full url is
file:///usr/share/doc/ghc-doc/html/libraries/index.html )

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: user-disabled

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

Name: Element Hiding Helper for Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/elemhidehel...@adblockplus.org
Package: xul-ext-adblock-plus-element-hiding-helper
Status: user-disabled

Name: Firebug
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/fire...@software.joehewitt.com
Package: xul-ext-firebug
Status: enabled

Name: Monkeysphere
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/tls-xul-...@monkeysphere.info
Package: xul-ext-monkeysphere
Status: user-disabled

Name: Perspectives
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/perspecti...@cmu.edu
Package: xul-ext-perspectives
Status: user-disabled

Name: Privacy Badger Firefox
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpn...@jetpack.xpi
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: µBlock
Location: ${PROFILE_EXTENSIONS}/{2b10c1c8-a11f-4bad-fe9c-1c11e82cac42}.xpi
Status: user-disabled

-- Plugins information

-- Addons package information
ii  iceweasel  38.1.0esr-3  amd64Web browser based on Firefox
ii  xul-ext-adbloc 2.6.9.1+dfsg all  advertisement blocking extension 
ii  xul-ext-adbloc 1.3.2-2  all  companion for Adblock Plus to cre
ii  xul-ext-firebu 2.0.11-1 all  web development plugin for Icewea
ii  xul-ext-monkey 0.8-1all  Iceweasel/Firefox extension for u
ii  xul-ext-perspe 4.6.2-1  all  verify HTTPS sites through notary

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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.16.0-2
ii  libc6 2.19-19
ii  libcairo2 1.14.2-2
ii  libdbus-1-3   1.8.20-1
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.5.2-4
ii  libgcc1   1:5.1.1-14
ii  libgdk-pixbuf2.0-02.31.5-1
ii  libglib2.0-0  2.44.1-1.1
ii  libgtk2.0-0   2.24.28-1
ii  libhunspell-1.3-0 1.3.3-3
ii  libnspr4  2:4.10.9-1
ii  libnss3   2:3.20-1
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.11-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.1.1-14
ii  libvpx2   1.4.0-4
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.10-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.4.5-3
ii  gstreamer1.0-plugins-good  1.4.5-2+b1

Versions of packages iceweasel suggests:
pn  fonts-mathjax  
pn  fonts-oflb-asana-math  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-2
pn  mozplugger 

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#569150: Amavis never cleans its virusmail jail

[Joey Hess]

I installed amavis to delete viruses. After a year, I noticed
/var/lib/amavis/virusmails was where all my system's disk space had
gone.

After grepping through all the documentation, I have yet to find
anything that documents this package behaves this way. Is the admin
supposed to learn about this when their server breaks?

Not sure why I'm even bothering to follow up since this bug
has been open for 5 years(!), but I wanted to point out that
this is also a documentation issue, and that this package, as it
currently exists, is a landmine for the unwary admin.

-- 
see shy jo


signature.asc
Description: Digital signature