Bug#958331: libunbound-dev has undeclared dependency on nettle-dev

[Jason Rhinelander]

Package: libunbound-dev
Version: 1.10.0-1
Severity: normal

In 1.10.0 the unbound-dev pkgconfig file gained:

Requires: hogweed nettle libevent

but these dependencies are not declared in the debian package.  As a result the 
dev package isn't
usable via pkg-config because pkg-config complains that hogweed is not 
installed.

One solution would be to have libunbound-dev add a dependency on nettle-dev.

Another--and admittedly I'm less sure that this would work--is to change the 
libunbound.pc file to
move them from 'Requires:' to 'Requires.private:' (since the libraries 
themselves appear to only be
present in the `Libs.private:` but not `Libs:`).


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

Kernel: Linux 5.5.0-rc5-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libunbound-dev depends on:
ii  libunbound8  1.10.0-1

libunbound-dev recommends no packages.

libunbound-dev suggests no packages.

-- no debconf information

Bug#919704: fixed in distcc 3.3.2-6

[Jason Rhinelander]

On Sat, 19 Jan 2019 09:20:31 + Christian Marillat 
 wrote:

Source: distcc
Source-Version: 3.3.2-6

We believe that the bug you reported is fixed in the latest version of
distcc, which is due to be installed in the Debian FTP archive.


It looks like my previous message that reopened this bug got hidden by 
the PTS.  I reopened this because 3.3.2-8 reverted the fix: thus distcc 
doesn't work again with most of the compilers I have installed (e.g. 
clang, cross compilers).


If using the upstream Python version is not an option then please fix 
the existing script to include more compilers.



Jason Rhinelander

Bug#925240: graphite-web: on fresh install managr-graphite command return error (missing settings.py file)

[Jason Rhinelander]

On Thu, 21 Mar 2019 17:05:23 +0100 Jacek Jaros  wrote:

   Error: Can't find the file 'settings.py' in the directory containing
   '/usr/bin/graphite-manage'. It appears you've customized things.
   You'll have to run django-admin.py, passing it your settings module.
   (If the file settings.py does indeed exist, it's causing an
   ImportError somehow.)



This is happening because /usr/bin/graphite-manage starts off with 
`#!/usr/bin/python2` but the package has migrated to Python3.


Either changing the 2 -> 3 in the executable, or running as `python3 
/usr/bin/graphite-manage` are workarounds until the package gets fixed.



Jason Rhinelander

Bug#920454: linux-image-4.20.0-trunk-amd64: please reenable amdgpu HSA support

[Jason Rhinelander]

Package: src:linux
Version: 4.20-1~exp1
Severity: normal

The 4.20-1~exp1 configuration disabled CONFIG_HSA_AMD, necessary for using 
AMD's ROCm platform:

$ xzgrep CONFIG_HSA_AMD /usr/src/linux-config-4.20/config.amd64_none_amd64.xz
# CONFIG_HSA_AMD is not set

$ xzgrep CONFIG_HSA_AMD /usr/src/linux-config-4.19/config.amd64_none_amd64.xz
CONFIG_HSA_AMD=m


This was very likely unintentionally caused by 4.20 merging amdkfd into the 
amdgpu module
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04d5e2765802241b54ee93d1e655123c39fa7385)
which turned the HSA_AMD config option into a bool affecting the amdgpu module.

Bug#919704: distcc: update-distcc-symlinks misses many compilers; please switch to upstream .py version

[Jason Rhinelander]

Package: distcc
Version: 3.3.2-5
Severity: important

Debian's distcc includes a Perl-based `update-distcc-symlinks` script, but this 
misses rather a lot
of installed compilers when compared to the upstream package's 
update-distcc-symlinks.py (which
looks to be new as of 3.3).

I'm submitting this as important rather than merely normal as this breaks cross 
compiling and clang
compilation via distcc: the symlinks in /usr/lib/distcc have recently become a 
whitelist of allowed
compilers in distcc (see merged upstream PR #243), and thus the current 
approach of having only a
few compilers breaks using distcc for cross-compiling (or compiling with clang 
and likely various
other compilers that I don't happen to have installed).

Here's what I get in /usr/lib/distcc using the upstream version 
(update-distcc-symlinks.py) from the
source package (it *is* included in the source package, but not actually 
installed):

lrwxrwxrwx 1 root root 16 Jan 18 14:12 aarch64-linux-gnu-g++ -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 aarch64-linux-gnu-g++-8 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 aarch64-linux-gnu-gcc -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 aarch64-linux-gnu-gcc-8 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 c++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 c89 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 c89-gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 c99 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 c99-gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 cc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 clang -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 clang++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 clang++-6.0 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 clang-6.0 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 clang++-7 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 18 14:12 clang-7 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 g++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 10 15:57 g++-7 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 g++-8 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 gcc-7 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 gcc-8 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-g++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 10 15:57 x86_64-linux-gnu-g++-7 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-g++-8 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-gcc-7 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-gcc-8 -> 
../../bin/distcc*

But the Debian-installed update-distcc-symlinks (which comes from 
debian/update-distcc-symlinks.in,
and is an entirely different implementation written in Perl) misses many of 
these compilers:

lrwxrwxrwx 1 root root 16 Jan  6 13:37 c++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 c89-gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 c99-gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 cc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 g++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 10 15:57 g++-7 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 g++-8 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 gcc-7 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 gcc-8 -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-g++ -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan 10 15:57 x86_64-linux-gnu-g++-7 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-g++-8 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-gcc -> ../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-gcc-7 -> 
../../bin/distcc*
lrwxrwxrwx 1 root root 16 Jan  6 13:37 x86_64-linux-gnu-gcc-8 -> 
../../bin/distcc*

This in turn breaks distcc compilations that attempt to use installed 
cross-compilers or clang
(since, as I mentioned, these symlinks now do double-duty as distcc compiler 
whitelists).

An easy fix to this would thus appear to be replacing the package's 
update-distcc-symlinks with the
upstream version.




-- 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.19.0-1-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to 

Bug#882971: lvm2: Cannot uninstall lvm2: pre-removal script subprocess returned error exit status 1

[Jason Rhinelander]

Package: lvm2
Version: 2.02.176-4
Severity: normal

Dear Maintainer,

Attempting to `apt-get remove lvm2` fails in the pre-removal script:



jagerman@keynes:~$ sudo apt-get -y remove lvm2
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  lvm2
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 3,374 kB disk space will be freed.
(Reading database ... 343047 files and directories currently installed.)
Removing lvm2 (2.02.176-4) ...
Syntax: /usr/bin/deb-systemd-invoke   [ ...]
dpkg: error processing package lvm2 (--remove):
 installed lvm2 package pre-removal script subprocess returned error exit 
status 1
Failed to start lvm2-monitor.service: Unit dm-event.socket is masked.
Syntax: /usr/bin/deb-systemd-invoke   [ ...]
Errors were encountered while processing:
 lvm2
E: Sub-process /usr/bin/dpkg returned an error code (1)




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

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
pn  dmeventd  
ii  dmsetup   2:1.02.145-4
ii  libblkid1 2.30.2-0.1
ii  libc6 2.24-17
pn  libdevmapper-event1.02.1  
ii  libdevmapper1.02.12:1.02.145-4
pn  liblvm2app2.2 
ii  libreadline5  5.2+dfsg-3+b1
ii  libsystemd0   235-3
ii  libudev1  235-3
ii  lsb-base  9.20170808

Versions of packages lvm2 recommends:
pn  thin-provisioning-tools  

lvm2 suggests no packages.

-- no debconf information

Bug#859290: live-build documentation URL is cybersquatting site

[Jason Rhinelander]

Package: live-build
Version: 1:20170213
Severity: normal

Dear Maintainer,

I installed live-build, ran `man live-build` and read this under description:

   More documentation about how to use live-build  is  available
   in  the individual manpages for each helper and in the manual
   at .

That URL, rather than offering any documentation, instead redirects to a
cybersquatting site offering the domain for sale.


Despite the amazing offer of a mere $319 to obtain this premium domain from
such a generous internet patron who didn't want to see the domain become
unregistered, I declined the amazing offer and only hope someone with greater
means can compensate this valiant company for its efforts at "finding solutions
for ... important needs in the Domain aftermarket" [to quote from the seller's
"about us" page].


I got the HTML documentation locally with the live-manual-html package, but it
would be nice to update the URL.

The information `reportbug` presents when filing a bug against the package also
references the same URL.



-- Package-specific info:

-- 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.10.0-trunk-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages live-build depends on:
ii  debootstrap  1.0.89

Versions of packages live-build recommends:
ii  apt-utils   1.4~rc2
ii  cpio2.11+dfsg-6
pn  live-boot-doc   
pn  live-config-doc 
pn  live-manual-html | live-manual  
ii  wget1.19.1-3

live-build suggests no packages.

-- no debconf information

Bug#855222: clang-4.0 has wrong C++ include search path order

[Jason Rhinelander]

A quick follow-up and potential solution:

I rebuilt the package with debian/patches/fix-clang-path-and-build.diff 
changed to move the added `addSystemInclude(...)` call to just *after* 
adding the c++ library include paths, instead of before it, which 
results in a working include path order:


$ clang++-4.0 -v -E -x c++ -stdlib=libc++ -
clang version 4.0.0-+rc2-1.1 (tags/RELEASE_400/rc1)
...
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/v1
 /usr/include/clang/4.0.0/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.


I'm not sure if that causes other problems, but it looks like a fix.


Jason Rhinelander

Bug#855222: clang-4.0 has wrong C++ include search path order

[Jason Rhinelander]

Package: clang-4.0
Version: 1:4.0~+rc2-1
Severity: normal

Dear Maintainer,

clang-4.0 appears to have a search path order for includes that causes problems
with compilation with libc++ when trying to load stl headers; here's an example
that fails:

$ cat test.cpp
#include 
int main() { return 0; }
$ clang++-3.9 -stdlib=libc++ test.cpp
$ clang++-4.0 -stdlib=libc++ test.cpp
In file included from test.cpp:1:
In file included from /usr/include/c++/v1/limits:110:
In file included from /usr/include/c++/v1/type_traits:387:
/usr/include/c++/v1/cstddef:43:15: fatal error: 'stddef.h' file not found
#include_next 
  ^~
1 error generated.


The problem seems to be that, in clang-4.0, clang's include path is injected
before the standard library search path:

$ clang-4.0 -x c++ -stdlib=libc++ -v -E -
...
#include <...> search starts here:
 /usr/include/clang/4.0.0/include
 /usr/include/c++/v1
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include

This isn't specific to libc++: without the -stdlib=libc++ the second line is
replaced with three stdlibc++ include paths, but still show up after the clang
include path.  This doesn't seem to cause problems for stdlibc++, but still
seems incorrect.

In clang-3.9, clang's include path comes after the c++ library:

$ clang-3.9 -x c++ -stdlib=libc++ -v -E -
...
#include <...> search starts here:
 /usr/include/c++/v1
 /usr/local/include
 /usr/lib/llvm-3.9/bin/../lib/clang/3.9.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include


This breaks libc++ under clang-4.0 because it uses `#include_next `
to get at the compiler's stddef.h, which won't work with the paths in the wrong
order.


Other things I tried:

- I built and installed upstream libc++ 4.0 instead of the debian-packaged
libc++ 3.9.1: same error (unsurprisingly).
- I tried the clang-4.0 snapshot from http://apt.llvm.org/, which exhibits
exactly the same behaviour.
- I built clang and libc++ from the upstream llvm 4.0 branch: it works fine.
The search path for this clang is:
 /usr/local/bin/../include/c++/v1
 /usr/local/include
 /usr/local/bin/../lib/clang/4.0.0/include
 /usr/include/x86_64-linux-gnu
 /usr/include

i.e. the clang include is after the C++ library, where it belongs.



-- 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.10.0-rc6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages clang-4.0 depends on:
ii  binutils 2.27.90.20170205-1
ii  libc62.24-9
ii  libc6-dev2.24-9
ii  libclang-common-4.0-dev  1:4.0~+rc2-1
ii  libclang1-4.01:4.0~+rc2-1
ii  libgcc-6-dev 6.3.0-6
ii  libgcc1  1:6.3.0-6
ii  libjsoncpp1  1.7.4-3
ii  libllvm4.0   1:4.0~+rc2-1
ii  libobjc-6-dev6.3.0-6
ii  libstdc++-6-dev  6.3.0-6
ii  libstdc++6   6.3.0-6

Versions of packages clang-4.0 recommends:
ii  llvm-4.0-dev  1:4.0~+rc2-1
ii  python2.7.13-2

Versions of packages clang-4.0 suggests:
pn  clang-4.0-doc  
pn  gnustep
pn  gnustep-devel  

-- no debconf information

Bug#854692: pybind11: FTBFS due to an internal compiler error

[Jason Rhinelander]

Package: g++-6
Version: 6.3.0-6
Followup-For: Bug #854692

Dear Maintainer,

This looks a whole lot like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296
having now been backported into the gcc-6-branch, which would seem to warrant
an escalation of the upstream bug.  The "reduced testcase" attached there
triggers the ICE now with 6.3.0-6, while it doesn't with 6.3.0-5.

I can also confirm that pybind11 itself builds perfectly with testing's g++-6
6.3.0-5; this regression is new to 6.3.0-6.  Having this regression migrate to
testing would be a nuissance (upstream pybind11 itself uses debian testing for
some of its travis-ci builds).


Jason Rhinelander



-- 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.10.0-rc6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages g++-6 depends on:
ii  gcc-66.3.0-6
ii  gcc-6-base   6.3.0-6
ii  libc62.24-9
ii  libgmp10 2:6.1.2+dfsg-1
ii  libisl15 0.18-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.5-1
ii  libstdc++-6-dev  6.3.0-6
ii  zlib1g   1:1.2.8.dfsg-5

g++-6 recommends no packages.

Versions of packages g++-6 suggests:
pn  g++-6-multilib
pn  gcc-6-doc 
pn  libstdc++6-6-dbg  

-- no debconf information

Bug#854502: pybind11-dev: cmake configuration scripts are not installed

[Jason Rhinelander]

Package: pybind11-dev
Version: 2.0.1-1
Severity: important

Dear Maintainer,

pybind11 includes cmake scripts (as of 2.0) to enable CMake-using projects to
correctly set up compiler flags and include directories using a cmake standard:

find_package(pybind11)

This fails with the current pybind11 package as the cmake scripts aren't being
installed.

Tagging this 'important' as this is the upstream-recommended way to properly
use pybind11 in CMake projects.



-- 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_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

pybind11-dev depends on no packages.

pybind11-dev recommends no packages.

Versions of packages pybind11-dev suggests:
ii  libeigen3-dev  3.3.2-1
pn  pybind11-doc   

Bug#852104: g++-7 fails to include standard include path

[Jason Rhinelander]

Package: g++-7
Version: 7-20170118-1
Severity: important

The latest gcc-7 experimental snapshot appears to be missing 
'/usr/include/g++/7' from the standard include search paths, and as a 
result can't compile anything using any stl headers, e.g.:


#include 
int main() {}

fails to compile with:

test.cpp:1:10: fatal error: iostream: No such file or directory
 #include 
  ^~
compilation terminated.


Running cpp-7 -E -x c++ -v gives me:
Using built-in specs.
COLLECT_GCC=cpp-7
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
7-20170118-1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-7 --program-prefix=x86_64-linux-gnu- --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 
--enable-default-pie --with-system-zlib --with-target-system-zlib 
--enable-objc-gc=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --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 7.0.0 20170118 (experimental) [trunk revision 244601] 
(Debian 7-20170118-1)

COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch 
x86_64-linux-gnu -D_GNU_SOURCE - -mtune=generic -march=x86-64
ignoring nonexistent directory 
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../include/c++/7/x86_64-linux-gnu"
ignoring nonexistent directory 
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../include/x86_64-linux-gnu/x86_64-linux-gnu/c++/7"

ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory 
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"

#include "..." search starts here:
#include <...> search starts here:
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.



which seems to be missing '/usr/include/c++/7' as the first entry. 
Under cpp-6, for comparison, I get:

... (snip) ...
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/x86_64-linux-gnu/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include


Compilation worked fine with the previous snapshot version (though I 
don't seem to still have the .deb around to get the actual include list).

Bug#851714: gitlab: Cannot push to gitlab repositories with git >= 2.11.0

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg2-2
Severity: grave

Dear Maintainer,

Gitlab repositories will no longer accept remote pushes to protected branches
(which is the default!) with git 2.11.0 installed on the gitlab system, failing
with:

remote: GitLab: You are not allowed to force push code to a protected branch on 
this project.
To (sitename):(user)/(repo).git
 ! [remote rejected] master -> master (pre-receive hook declined)

even for ordinary, non-forced pushes.

This is upstream bug https://gitlab.com/gitlab-org/gitlab-ce/issues/25301

Since gitlab seems pretty useless without the ability to push to a repository
by default, I've marked this grave.


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

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  apache2 [httpd]   2.4.25-1
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b2
ii  bundler   1.13.6-2
ii  debconf [debconf-2.0] 1.5.59
ii  git   1:2.11.0-2
ii  gitlab-shell  3.6.6-1
ii  gitlab-workhorse  0.8.5+debian-3
ii  init-system-helpers   1.46
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161125
ii  nodejs4.7.2~dfsg-1
ii  openssh-client1:7.4p1-5
ii  postfix [mail-transport-agent]3.1.3-6
ii  postgresql-client 9.6+178
ii  postgresql-client-9.6 [postgresql-client  9.6.1-2
ii  postgresql-contrib9.6+178
ii  rake  10.5.0-2
pn  redis-server  
ii  ruby  1:2.3.3
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-2
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-3
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-4
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails 4.1.0-2
ii  ruby-coffee-script-source 1.10.0-1
ii  ruby-connection-pool  2.2.0-1
ii  ruby-creole   0.5.0-2
ii  ruby-d3-rails 3.5.6+dfsg-1
ii  ruby-default-value-for3.0.1-1
ii  ruby-devise   4.2.0-1
ii  ruby-devise-two-factor3.0.0-2
ii  ruby-diffy3.0.6-1
ii  ruby-doorkeeper   4.2.0-3
ii  ruby-dropzonejs-rails 0.7.1-1
ii  ruby-email-reply-parser   0.5.8-1
ii  ruby-fog-aws  0.12.0-1
ii  ruby-fog-azure0.0.2-1
ii  ruby-fog-core 1.42.0-1
ii  ruby-fog-google   0.3.2-1
ii  ruby-fog-local0.3.0-1
ii  ruby-fog-openstack0.1.6-4
ii  ruby-fog-rackspace0.1.1-4
ii  ruby-fogbugz  0.2.1-3
ii  ruby-font-awesome-rails   4.6.3.0-2
ii  ruby-gemnasium-gitlab-service 0.2.6-1
ii  ruby-gemojione3.1.0-2
ii  ruby-github-linguist  4.7.2-2
ii  ruby-github-markup1.5.0+dfsg-4
ii  ruby-gitlab-flowdock-git-hook 1.0.1-2
ii  ruby-gitlab-git  

Bug#846180: gitlab not restarted after redis-server upgrade

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg1-2
Severity: normal

Dear Maintainer,

I just installed an upgraded version of redis-server (but not of gitlab 
itself), and after the upgrade gitlab was no longer running.  The 
following reproduces this easily for me:



$ for i in "" -mailroom -sidekiq -unicorn -workhorse; do
  s=gitlab$i; echo $s; sudo service $s status | grep Active; done

gitlab
   Active: active (exited) since Mon 2016-11-28 21:06:38 EST; 3s ago
gitlab-mailroom
   Active: active (running) since Mon 2016-11-28 21:06:26 EST; 15s ago
gitlab-sidekiq
   Active: active (running) since Mon 2016-11-28 21:06:38 EST; 3s ago
gitlab-unicorn
   Active: active (running) since Mon 2016-11-28 21:06:26 EST; 15s ago
gitlab-workhorse
   Active: active (running) since Mon 2016-11-28 21:06:26 EST; 15s ago



$ sudo apt-get install redis-server --reinstall

Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.

Need to get 0 B/407 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 253802 files and directories currently installed.)
Preparing to unpack .../redis-server_3%3a3.2.5-2_amd64.deb ...
Unpacking redis-server (3:3.2.5-2) over (3:3.2.5-2) ...
Processing triggers for systemd (232-6) ...
Processing triggers for man-db (2.7.5-2) ...
Setting up redis-server (3:3.2.5-2) ...



$ for i in "" -mailroom -sidekiq -unicorn -workhorse; do
  s=gitlab$i; echo $s; sudo service $s status | grep Active; done

gitlab
   Active: inactive (dead) since Mon 2016-11-28 21:06:49 EST; 13s ago
gitlab-mailroom
   Active: inactive (dead) since Mon 2016-11-28 21:06:50 EST; 13s ago
gitlab-sidekiq
   Active: inactive (dead) since Mon 2016-11-28 21:06:52 EST; 10s ago
gitlab-unicorn
   Active: inactive (dead) since Mon 2016-11-28 21:06:50 EST; 12s ago
gitlab-workhorse
   Active: inactive (dead) since Mon 2016-11-28 21:06:49 EST; 13s ago



I have no idea whether this is something wrong in the gitlab service 
files, something wrong in redis-server, or something elsewhere (e.g. in 
debhelper's scripts for restarting on upgrade).



Jason Rhinelander

Bug#846179: gitlab: Use notify on ready under systemd instead of hack with sleep + check commandline

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg1-2
Severity: normal

Dear Maintainer,

The current systemd service file for gitlab-sidekiq contains a hack to 
delay the systemd service startup until sidekiq is actually ready by 
sleeping for up to 32 seconds (in increments of 4 seconds) until 
sidekiq's cmdline changes.


Besides being an unpleasant hack, and potentially ending too early (e.g. 
if sidekiq takes more than 32 seconds to start up on a slow/loaded 
machine), this also has the unfortunate consequence of showing this 
command forever in the service status output, and of making the service 
take up to 4 seconds longer than necessary to actually be registered as 
started.


We can do much better by performing a proper systemd notify, as follows 
(I've tested this locally, and it works properly):



1. Patch the installed /etc/gitlab/initializers/sidekiq.rb to add, near 
the top of the configure_server function:



  if ((socket_path = ENV["NOTIFY_SOCKET"]))
config.on(:startup) do
  notify_socket = Socket.new(Socket::AF_UNIX, Socket::SOCK_DGRAM, 0)
  notify_socket.connect(Socket.sockaddr_un(socket_path))
  notify_socket.sendmsg "READY=1", Socket::MSG_NOSIGNAL
end
  end


2. change the gitlab-sidekiq.service file to contain:

Type=notify

and delete the ExecStartPost= line.



Then we get proper notification support: notification happens 
immediately upon sidekiq being ready, the hack is gone, and the job 
starts faster.



Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#845719: gitlab produces 500 errors if it detects a license

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg1-2
Severity: normal

Dear Maintainer,

I migrated from a custom gitlab installation to the debian gitlab package 
today, and found that
attempting to view one of my git repositories was giving a 500 error.

When this occurred, the log gave:

ActionView::Template::Error ('gpl-3.0' is not a valid license key):
38: 
39:   - if @repository.license_blob
40: %li
41:   = link_to license_short_name(@project), license_path(@project)
42: 
43:   - if @repository.contribution_guide
44: %li
  app/helpers/projects_helper.rb:118:in `license_short_name'
  app/views/projects/show.html.haml:41:in 
`_app_views_projects_show_html_haml__3251184896114945331_47088563639140'
  lib/gitlab/request_profiler/middleware.rb:15:in `call'
  lib/gitlab/middleware/go.rb:16:in `call'



Some more tracking down of the issue (and comparing to my previous working
setup) suggests that the problem may be a problem with ruby-licensee package:
the debian package doesn't contain the
vendor/choosealicense.com/_licenses/*.txt files, but the ruby-licensee code
expects to find them in ../../vendor/choosealicence(etc.)

Thus gitlab and/or ruby-licensee seem to be (correctly) identifying the project
as GPLv3 licensed, and try to get some information about the license, but it
fails because the expected files don't exist.

I tried creating a /usr/lib/ruby/vendor symlink to
~/src/ruby-licensee-8.0.0/vendor (so that it can temporarily find the expected
files via the symlink into my `apt-get source' download directory) and this
cleared up the problem: the 500 error disappears and gitlab works again, with
the license showing "GNU GPLv3", which is presumably the license short name
that it gets from ruby-licensee.


(I realize, given the above, this bug probably belongs against ruby-licensee,
but since it seems to be packaged entirely for the benefit of gitlab, I thought
filing against gitlab might get the problem noticed faster).


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

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

Versions of packages gitlab depends on:
ii  adduser   3.115
ii  apache2 [httpd]   2.4.23-7
ii  asciidoctor   1.5.4-2
ii  bc1.06.95-9+b2
ii  bundler   1.12.5-3
ii  debconf [debconf-2.0] 1.5.59
ii  git   1:2.10.2-3
ii  gitlab-shell  3.6.6-1
ii  gitlab-workhorse  0.8.5+debian-3
ii  init-system-helpers   1.46
ii  libjs-chartjs 1.0.2-1
ii  libjs-clipboard   1.4.2-1
ii  libjs-fuzzaldrin-plus 0.3.1+git.20161008.da2cb58+dfsg-4
ii  libjs-graphael0.5+dfsg-1
ii  libjs-jquery-cookie   11-3
ii  libjs-jquery-history  11-3
ii  libjs-jquery-nicescroll   3.6.6-1
ii  lsb-base  9.20161101
ii  nodejs4.6.1~dfsg-1
ii  openssh-client1:7.3p1-3+b1
ii  postfix [mail-transport-agent]3.1.3-2
ii  postgresql-client 9.6+177
ii  postgresql-client-9.5 [postgresql-client  9.5.4-3
ii  postgresql-client-9.6 [postgresql-client  9.6.0-1
ii  postgresql-contrib9.6+177
ii  rake  10.5.0-2
ii  redis-server  3:3.2.5-2
ii  ruby  1:2.3.0+4
ii  ruby-ace-rails-ap 4.1.1-1
ii  ruby-activerecord-session-store   1.0.0-2
ii  ruby-acts-as-taggable-on  4.0.0-2
ii  ruby-addressable  2.4.0-1
ii  ruby-after-commit-queue   1.3.0-1
ii  ruby-akismet  2.0.0-1
ii  ruby-allocations  1.0.3-1+b2
ii  ruby-asana0.4.0-1
ii  ruby-attr-encrypted   3.0.1-2
ii  ruby-babosa   1.0.2-1
ii  ruby-base32   0.3.2-3
ii  ruby-bootstrap-sass   3.3.5.1-3
ii  ruby-browser  2.2.0-2
ii  ruby-cal-heatmap-rails3.6.0+dfsg-1
ii  ruby-carrierwave  0.10.0+gh-3
ii  ruby-charlock-holmes  0.7.3+dfsg-2+b3
ii  ruby-chronic  0.10.2-3
ii  ruby-chronic-duration 0.10.6-1
ii  ruby-coffee-rails

Bug#843330: Usage of OpenDMARC 1.3.2 beta0

[Jason Rhinelander]

On 05/11/16 06:53 PM, pkt...@users.sf.net wrote:

Hi,

I just saw your comment to ticket #185.
If you trying to use OpenDMARC 1.3.2 beta0 you will run into more
problems than just ticket 185. See my page at
http://batleth.sapienti-sat.org/projects/opendmarc/ for a collection of
patches this beta release.

If you are using MySQL 5.7 you will also experience problems with strict
mode - I have a patch pending.



Thanks for the comment and link.  I'm using the opendmarc package from 
Debian "testing", where this beta0 version landed in the last day or so. 
 The debian package has a few, but certainly not all of those patches 
applied.


I'm CC'ing this to the Debian bug report I submitted regarding including 
185 as some of these other patches would similarly be useful for the 
package in Debian.



Jason Rhinelander

Bug#843330: opendmarc segfaults when invoked for local/ignored hosts

[Jason Rhinelander]

Package: opendmarc
Version: 1.3.2~Beta0+dfsg-2
Severity: important
Tags: upstream patch

Dear Maintainer,

opendmarc segfaults when invoked (via milter) if the host is an ignored host
(e.g. localhost).

I manually fixed the .service generator script (#843327) to get opendmarc
started under systemd.  It started, but when postfix invokes it, I get
segfaults for some mail (and after seeing the below, the segfaults are
apparently for any mail from an ignored host/ip, such as mail originating from
the local system).

This was reported upstream in https://sourceforge.net/p/opendmarc/tickets/185/;
I applied the patch attached in that report, rebuilt the debian package, and
the package with that patch applied now works without segfaulting.

Please make a new release with that patch applied!

Jason Rhinelander


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

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

Versions of packages opendmarc depends on:
ii  adduser 3.115
ii  libbsd0 0.8.3-1
ii  libc6   2.24-5
ii  libmilter1.0.1  8.15.2-6
ii  libopendmarc2   1.3.2~Beta0+dfsg-2
ii  libspf2-2   1.2.10-7+b1
ii  lsb-base9.20161016
ii  publicsuffix20160826-1

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.037-5
ii  libdbi-perl   1.636-1+b1
ii  libhttp-message-perl  6.11-1
ii  libopendbx1   1.4.6-11
pn  libopendbx1-mysql 
ii  libswitch-perl2.17-2
ii  perl  5.24.1~rc3-3
pn  perl:any  

opendmarc suggests no packages.

-- Configuration Files:
/etc/default/opendmarc changed:
RUNDIR=/var/spool/postfix/opendmarc
SOCKET=local:$RUNDIR/opendmarc.sock
USER=opendmarc
GROUP=postfix
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

/etc/opendmarc.conf changed:
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
IgnoreAuthenticatedClients true
UMask 
Socket local:/var/spool/postfix/opendmarc/opendmarc.sock
HistoryFile /var/lib/opendmarc/history.dat
UserID opendmarc:postfix
PublicSuffixList /usr/share/publicsuffix/


-- no debconf information

-- debsums errors found:
debsums: can't check opendmarc file /usr/share/doc/opendmarc/README.gz (Wide 
character in subroutine entry)
debsums: can't check opendmarc file 
/usr/share/doc/opendmarc/README.opendmarc.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file 
/usr/share/doc/opendmarc/changelog.Debian.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file /usr/share/doc/opendmarc/changelog.gz (Wide 
character in subroutine entry)
debsums: can't check opendmarc file 
/usr/share/doc/opendmarc/opendmarc.conf.sample.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file /usr/share/man/man5/opendmarc.conf.5.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-check.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-expire.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-import.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file 
/usr/share/man/man8/opendmarc-importstats.8.gz (Wide character in subroutine 
entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-params.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc-reports.8.gz 
(Wide character in subroutine entry)
debsums: can't check opendmarc file /usr/share/man/man8/opendmarc.8.gz (Wide 
character in subroutine entry)

Bug#843327: opendmarc: generated systemd service file is completely non-functional

[Jason Rhinelander]

Package: opendmarc
Version: 1.3.2~Beta0+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The opendmarc.service file generated by opendmarc ends up trying to invoke
/usr/sbin/opendkim rather than /usr/sbin/opendmarc to start the daemon.  This
is clearly wrong (luckily it doesn't actually start opendkim, because opendkim
barfs at being given a conf file with opendmarc options).

This is coming from the opendmarc.service.generate script's ExecStart line:

echo "ExecStart=/usr/sbin/opendkim -p $SOCKET $DAEMON_OPTS -x 
/etc/$NAME.conf -u $USER -P $PIDFILE" >> $SERVICEFILE.new

That has at least three problems that I ran into trying to fix this:

- /usr/sbin/opendkim should be /usr/sbin/opendmarc

- the -x flag should be -c

- the -p $SOCKET bit is sometimes wrong; /etc/default/opendmarc says SOCKET
  overrides the Socket setting in the config file, and the
  /etc/init.d/opendmarc script indeed handles this.  If I fix the above two
  issues but comment out SOCKET in /etc/default/opendmarc (because I have the
  Socket specified in /etc/opendmarc.conf), I get a failure to start with bad
  argument output because SOCKET isn't set, so there is no argument following
  the "-p".


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

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

Versions of packages opendmarc depends on:
ii  adduser 3.115
ii  libbsd0 0.8.3-1
ii  libc6   2.24-5
ii  libmilter1.0.1  8.15.2-6
ii  libopendmarc2   1.3.2~Beta0+dfsg-2
ii  libspf2-2   1.2.10-7+b1
ii  lsb-base9.20161016
ii  publicsuffix20160826-1

Versions of packages opendmarc recommends:
ii  libdbd-mysql-perl 4.037-5
ii  libdbi-perl   1.636-1+b1
ii  libhttp-message-perl  6.11-1
ii  libopendbx1   1.4.6-11
pn  libopendbx1-mysql 
ii  libswitch-perl2.17-2
ii  perl  5.24.1~rc3-3
pn  perl:any  

opendmarc suggests no packages.

-- Configuration Files:
/etc/opendmarc.conf changed:
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
IgnoreAuthenticatedClients true
UMask 
Socket local:/var/spool/postfix/opendmarc/opendmarc.sock
HistoryFile /var/lib/opendmarc/history.dat
UserID opendmarc:opendmarc
PublicSuffixList /usr/share/publicsuffix/


-- no debconf information

Bug#840306: /usr/bin/nvim: SIGTSTP leaves terminal in a strange state

[Jason Rhinelander]

Upstream fix: 
https://github.com/neovim/neovim/commit/36c0ec6dd49c8c1a57eaa0b9f9d3c44792582f37


Please consider this a friendly request for a 0.1.6-2 package with this 
(simple) patch included: being able to Ctrl-Z nvim and use the shell 
normally for a few commands is something I rely on quite a bit.



Jason Rhinelander

Bug#822872: libinput package doesn't install udev hwdb/rules files

[Jason Rhinelander]

Source: libinput
Version: 1.2.4-1
Severity: normal

Dear Maintainer,

libinput has udev hwdb and rules entries (and a couple binary helpers called by
the rules) for handling various device quirks, but the debian packages aren't
including them, and so the libinput device quirks don't get applied.

Building the package properly with the udev entries requires an addition to
debian/rules of:

override_dh_auto_configure:
dh_auto_configure -- --with-udev-dir=/lib/udev

(Because otherwise the udev rules end up under /usr/lib/{arch-triplet}/udev,
which doesn't work).

I'm not completely sure how these should be packaged, though; I stuck them into
libinput10 to get it working for me, but that seems wrong (because it would, I
assume, break multi-arch), so perhaps a new libinput-common package?


-- 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-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#815687: r-cran-truncnorm: debian/copyright states License: GPL-2+, but package seems to be GPL-2-only

[Jason Rhinelander]

Package: r-cran-truncnorm
Version: 1.0-7-1
Severity: minor

Dear Maintainer,

The r-cran-truncnorm debian/copyright states the package's license as GPL-2 or
later, but the source itself appears to state that the package is GPL-2 only:

$ grep License r-cran-truncnorm-1.0-7/DESCRIPTION
License: GPL-2

It seems to me that this might also have implications on the allowable license
of the rdep r-cran-solnp and its rdep r-cran-fportfolio, both of which are
supposedly GPL-2+, but seem incompatible with GPL-3 because of the dependency
on the GPL-2-only r-cran-truncnorm.  Does requiring an R package from another
package count as "linking" from the license point of view?

If so, maybe it would be better to ask upstream if they are willing to
relicense under GPL-2+?



-- 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_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-cran-truncnorm depends on:
ii  libc62.21-9
ii  r-base-core  3.2.3-6

r-cran-truncnorm recommends no packages.

r-cran-truncnorm suggests no packages.

-- no debconf information

Bug#810860: usrmerge: System cannot be rebooted after partial usrmerge installation

[Jason Rhinelander]

On 16/01/16 09:16 PM, Ben Hutchings wrote:

On Thu, 2016-01-14 at 11:18 +0100, Marco d'Itri wrote:

initramfs-tools needs this patch to be able to resolve recursive
symlinks, or else the system will not boot while in the middle of
a merged /usr transition.
Then I will add a versioned conflict to the usrmerge package.

[...]

Taking a quick look at it, it looks like validate_init will only handle a
*single* absolute symlink, but in this particular case there are two
(absolute) symlinks:

/sbin/init -> /usr/sbin/init
/usr/sbin/init -> /lib/systemd/systemd

[...]

We can't resolve the second symlink until /usr is already mounted, so
recursively reading symlinks is not going to help.

But clearly if /sbin/init is a symlink to somewhere under /usr then we
need to mount it!

Ben.



That seems a separate (if related) issue: this non-bootable problem 
comes up up even when /usr is on the same partition as /sbin (and it 
isn't really specific to /usr).


To reformulate slightly (taking /usr out of the equation entirely), the 
following symlink setup currently fails to boot with initramfs-tools:


/sbin/init -> /sbin/blah
/sbin/blah -> /sbin/real.init

with error "Target filesystem doesn't have requested /sbin/init"


An in-progress usrmerge installation (without any of the added 
complexity of a separate /usr mount) is simply exposing this by creating 
such a symlink chain.


Jason



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#810860: usrmerge: System cannot be rebooted after partial usrmerge installation

[Jason Rhinelander]

On 12/01/16 06:05 PM, Marco d'Itri wrote:
> On Jan 12, Jason Rhinelander <jager...@jagerman.com> wrote:
>
> Thank you for testing the conversion program, for a start!
>
>> I installed usrmerge, and got the following during configuration:
> This is expected and not a bug.

Right (was just reporting it for context).

>> At this point, I examined the disk layout, and noticed that basically
>> everything* in /{bin,sbin,lib} had been moved to 
/usr/{bin,sbin,lib}, and

>> replaced with symlinks in /{bin,sbin,lib}, but /{bin,sbin,lib} still
>> existed as real directories (not symlinks).
> If you got at that point then everything in the directories was either
> a directory or a symlink.

Yes, it appears it had just the final move-away-and-symlink step left.

>> Since I couldn't figure out which daemon was causing the problem, I
>> rebooted the system as suggested in the usrmerge configure error
>> messages.  It didn't come back up: it failed to start with an error that
>> /sbin/init was not found on the disk.  Oddly, however, I could run ls
>> /sbin/init which *did* show an existing symlink and target.
> Did you get a "No init found. Try passing init= bootarg." message,
> exactly?
> This check in the initramfs it is supposed to cope with absolute
> symlinks, but I did not test this exact condition and it is the only
> possible failure I can think about right now.

The error was:

Target filesystem doesn't have requested /sbin/init

and so it indeed appears to be validate_init in initramfs-tools/init not 
coping with the intermediate usrmerge setup.


Taking a quick look at it, it looks like validate_init will only handle 
a *single* absolute symlink, but in this particular case there are two 
(absolute) symlinks:


/sbin/init -> /usr/sbin/init
/usr/sbin/init -> /lib/systemd/systemd

and so it resolves the first to ${rootmnt}/usr/sbin/init, but not the 
second, and so init is still a broken symlink.


I've attached a patch for initramfs-tools to cope with this by resolving 
symlinks in a loop (up to a maximum of 10 times, to avoid an infinite 
loop for potential symlink cycles) instead of just once, which should 
fix the problem. It seems to work with an artificial nest of various 
symlinks (both absolute and relative) that I created, though I didn't 
replicate the usrmerge intermediate step to actually test it there.



Jason Rhinelander
--- a/init	2016-01-13 10:50:25.928550244 -0500
+++ b/init	2016-01-13 11:08:19.900426244 -0500
@@ -234,15 +234,20 @@
 	checktarget="${1}"
 
 	# Work around absolute symlinks
-	if [ -d "${rootmnt}" ] && [ -h "${rootmnt}${checktarget}" ]; then
-		checktarget="$(readlink "${rootmnt}${checktarget}")"
-		case "$checktarget" in
-		/*)
-			;;
-		*)
-			checktarget="${1%/*}/$checktarget"
-			;;
-		esac
+	if [ -d "${rootmnt}" ]; then
+readlink_count=0
+while [ -h "${rootmnt}${checktarget}" ] && [ "$readlink_count" -lt 10 ]; do
+lasttarget="${checktarget}"
+checktarget="$(readlink "${rootmnt}${checktarget}")"
+readlink_count=$((readlink_count+1))
+case "$checktarget" in
+/*)
+;;
+*)
+checktarget="${lasttarget%/*}/$checktarget"
+;;
+esac
+done
 	fi
 
 	# Make sure the specified init can be executed


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#810860: usrmerge: System cannot be rebooted after partial usrmerge installation

[Jason Rhinelander]

On 12/01/16 06:05 PM, Marco d'Itri wrote:

On Jan 12, Jason Rhinelander <jager...@jagerman.com> wrote:

Thank you for testing the conversion program, for a start!


I installed usrmerge, and got the following during configuration:

This is expected and not a bug.


Right (was just reporting it for context).


At this point, I examined the disk layout, and noticed that basically
everything* in /{bin,sbin,lib} had been moved to /usr/{bin,sbin,lib}, and
replaced with symlinks in /{bin,sbin,lib}, but /{bin,sbin,lib} still
existed as real directories (not symlinks).

If you got at that point then everything in the directories was either
a directory or a symlink.


Yes, it appears it had just the final move-away-and-symlink step left.


Since I couldn't figure out which daemon was causing the problem, I
rebooted the system as suggested in the usrmerge configure error
messages.  It didn't come back up: it failed to start with an error that
/sbin/init was not found on the disk.  Oddly, however, I could run ls
/sbin/init which *did* show an existing symlink and target.

Did you get a "No init found. Try passing init= bootarg." message,
exactly?
This check in the initramfs it is supposed to cope with absolute
symlinks, but I did not test this exact condition and it is the only
possible failure I can think about right now.


The error was:

Target filesystem doesn't have requested /sbin/init

and so it indeed appears to be validate_init in initramfs-tools/init not 
coping with the intermediate usrmerge setup.


Taking a quick look at it, it looks like validate_init will only handle 
a *single* absolute symlink, but in this particular case there are two 
(absolute) symlinks:


/sbin/init -> /usr/sbin/init
/usr/sbin/init -> /lib/systemd/systemd

and so it resolves the first to ${rootmnt}/usr/sbin/init, but not the 
second, and so init is still a broken symlink.


I've attached a patch for initramfs-tools to cope with this by resolving 
symlinks in a loop (up to a maximum of 10 times, to avoid an infinite 
loop for potential symlink cycles) instead of just once, which should 
fix the problem.  It seems to work with an artificial nest of various 
symlinks (both absolute and relative) that I created, though I didn't 
replicate the usrmerge intermediate step to actually test it there.



Jason Rhinelander
--- a/init	2016-01-13 10:50:25.928550244 -0500
+++ b/init	2016-01-13 11:08:19.900426244 -0500
@@ -234,15 +234,20 @@
 	checktarget="${1}"
 
 	# Work around absolute symlinks
-	if [ -d "${rootmnt}" ] && [ -h "${rootmnt}${checktarget}" ]; then
-		checktarget="$(readlink "${rootmnt}${checktarget}")"
-		case "$checktarget" in
-		/*)
-			;;
-		*)
-			checktarget="${1%/*}/$checktarget"
-			;;
-		esac
+	if [ -d "${rootmnt}" ]; then
+readlink_count=0
+while [ -h "${rootmnt}${checktarget}" ] && [ "$readlink_count" -lt 10 ]; do
+lasttarget="${checktarget}"
+checktarget="$(readlink "${rootmnt}${checktarget}")"
+readlink_count=$((readlink_count+1))
+case "$checktarget" in
+/*)
+;;
+*)
+checktarget="${lasttarget%/*}/$checktarget"
+;;
+esac
+done
 	fi
 
 	# Make sure the specified init can be executed


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#810860: usrmerge: System cannot be rebooted after partial usrmerge installation

[Jason Rhinelander]

It seems to work with an artificial nest of various
symlinks (both absolute and relative) that I created, though I didn't
replicate the usrmerge intermediate step to actually test it there.


Just for reference, here's what I tested the patched validate_init with:


jagerman@loki:~$ ls -laR /mnttest
/mnttest:
total 20
drwxr-xr-x  5 jagerman jagerman 4096 Jan 13 11:01 ./
drwxr-xr-x 18 root root 4096 Jan 13 11:01 ../
drwxr-xr-x  2 jagerman jagerman 4096 Jan 13 11:00 test1/
drwxr-xr-x  2 jagerman jagerman 4096 Jan 13 11:07 test2/
drwxr-xr-x  2 jagerman jagerman 4096 Jan 13 11:02 test3/

/mnttest/test1:
total 12
drwxr-xr-x 2 jagerman jagerman 4096 Jan 13 11:00 ./
drwxr-xr-x 5 jagerman jagerman 4096 Jan 13 11:01 ../
-rwxr-xr-x 1 jagerman jagerman   31 Jan 13 10:59 init*
lrwxrwxrwx 1 jagerman jagerman4 Jan 13 11:00 link1 -> init*

/mnttest/test2:
total 8
drwxr-xr-x 2 jagerman jagerman 4096 Jan 13 11:07 ./
drwxr-xr-x 5 jagerman jagerman 4096 Jan 13 11:01 ../
lrwxrwxrwx 1 jagerman jagerman8 Jan 13 11:07 badlink1 -> badlink2
lrwxrwxrwx 1 jagerman jagerman8 Jan 13 11:07 badlink2 -> badlink1
lrwxrwxrwx 1 jagerman jagerman   12 Jan 13 11:00 link2 -> /test1/link1
lrwxrwxrwx 1 jagerman jagerman   14 Jan 13 11:00 link3 -> ../test1/link1*

/mnttest/test3:
total 8
drwxr-xr-x 2 jagerman jagerman 4096 Jan 13 11:02 ./
drwxr-xr-x 5 jagerman jagerman 4096 Jan 13 11:01 ../
lrwxrwxrwx 1 jagerman jagerman   14 Jan 13 11:01 link4 -> ../test2/link2
lrwxrwxrwx 1 jagerman jagerman   12 Jan 13 11:01 link5 -> /test2/link2
lrwxrwxrwx 1 jagerman jagerman   12 Jan 13 11:01 link6 -> /test2/link3
lrwxrwxrwx 1 jagerman jagerman   14 Jan 13 11:02 link7 -> ../test2/link3*
lrwxrwxrwx 1 jagerman jagerman5 Jan 13 11:02 link8 -> link7*
lrwxrwxrwx 1 jagerman jagerman5 Jan 13 11:02 link9 -> link5



With rootmnt=/mnttest, everything listed (/test1/init, /test1/link1, 
/test1/link2, ..., /test3/link9) all resolved correctly to 
/mnt/test1/init, except for the circular badlink1 and badlink2, which 
successfully aborted (and failed) after 10 iterations.


Without the patch, /test3/link4, /test3/link5, and /test2/link9 fail: 
and these are exactly the symlink-to-an-absolute-symlink cases that was 
present in my unbootable usrmerge setup.



Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#810860: usrmerge: System cannot be rebooted after partial usrmerge installation

[Jason Rhinelander]

Package: usrmerge
Version: 6
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I installed usrmerge on a system to try it out, and ended up with system
that could not be rebooted.  I'll try to outline the status as best I
recall in the hopes that you can recreate the issue.

   * What led up to the situation?

I installed usrmerge, and got the following during configuration:


Setting up usrmerge (6) ...

WARNING: renaming /bin/ (for the purpose of replacing it with a symlink
to /usr/bin/) has failed with the EBUSY error.
This is probably caused by a systemd service started with the
ProtectSystem option. Before running again this program you will need to
stop the relevant daemon(s) or reboot the system.
Do not install or update other Debian packages until the program
has been run successfully.

WARNING: renaming /sbin/ (for the purpose of replacing it with a symlink
to /usr/sbin/) has failed with the EBUSY error.
This is probably caused by a systemd service started with the
ProtectSystem option. Before running again this program you will need to
stop the relevant daemon(s) or reboot the system.
Do not install or update other Debian packages until the program
has been run successfully.

WARNING: renaming /lib/ (for the purpose of replacing it with a symlink
to /usr/lib/) has failed with the EBUSY error.
This is probably caused by a systemd service started with the
ProtectSystem option. Before running again this program you will need to
stop the relevant daemon(s) or reboot the system.
Do not install or update other Debian packages until the program
has been run successfully.

WARNING: renaming /lib64/ (for the purpose of replacing it with a
symlink
to /usr/lib64/) has failed with the EBUSY error.
This is probably caused by a systemd service started with the
ProtectSystem option. Before running again this program you will need to
stop the relevant daemon(s) or reboot the system.
Do not install or update other Debian packages until the program
has been run successfully.
dpkg: error processing package usrmerge (--configure):
 subprocess installed post-installation script returned error exit
 status 1
 Errors were encountered while processing:
  usrmerge


I could not figure out which processes/daemons in particular were
causing the errors.

At this point, I examined the disk layout, and noticed that basically
everything* in /{bin,sbin,lib} had been moved to /usr/{bin,sbin,lib}, and
replaced with symlinks in /{bin,sbin,lib}, but /{bin,sbin,lib} still
existed as real directories (not symlinks).

(* - I noticed two exceptions in /lib, both of which were directories,
but unfortunately I can't remember exactly what they were, and the
history is beyond the top of my terminal buffer.  My best guess is that
they were systemd and x86_64-linux-gnu, but again, I'm not certain of
that.)

Since I couldn't figure out which daemon was causing the problem, I
rebooted the system as suggested in the usrmerge configure error
messages.  It didn't come back up: it failed to start with an error that
/sbin/init was not found on the disk.  Oddly, however, I could run ls
/sbin/init which *did* show an existing symlink and target.

I tried rebooting with init=/usr/sbin/init, but that also did not work.
Eventually I got the system to boot using init=/usr/lib/systemd/systemd
after which a dpkg --configure usrmerge completed the merge (turning
/{bin,sbin/lib} into symlinks).  After this, rebooting without
specifying init= was successful.

Please let me know if there's any other information I can provide to
keep this from happening to others.


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

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

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-1

usrmerge recommends no packages.

usrmerge suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: can't check usrmerge file /usr/share/doc/usrmerge/changelog.gz (Wide 
character in subroutine entry)

Bug#810656: Your mail

[Jason Rhinelander]

0.8.7 didn't quite fix this: /lib/systemd/system/networking.service added:

TimeoutStartSec="5min"

But the quotes make systemd barf, and ignore the timeout:

Jan 12 16:00:18 locke.imaginary.ca systemd[1]:
[/usr/lib/systemd/system/networking.service:21] Failed to parse sec
value, ignoring: "5min"

I removed the quotes (keeping the 5min), and didn't get the error after
rebooting again.


Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#801645: gnome-shell-extension-suspend-button: Update needed for GNOME 3.18

[Jason Rhinelander]

Package: gnome-shell-extension-suspend-button
Version: 0~git20150615-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

gnome-shell 3.18 recently arrived in sid, and breaks gnome-shell-extension-
suspend-button.  It can be trivially patched to work under 3.18 (patches
attached), and works as expected under 3.18 when patched and rebuilt.  (The
patch is essentially the same patch that was applied upstream for 3.16, with
3.18 added to the appropriate places.)




-- 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.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -ur gnome-shell-extension-suspend-button-0~git20150615/metadata.json gnome-shell-extension-suspend-button-0~git20150615-new/metadata.json
--- gnome-shell-extension-suspend-button-0~git20150615/metadata.json	2015-04-11 14:25:44.0 -0400
+++ gnome-shell-extension-suspend-button-0~git20150615-new/metadata.json	2015-10-12 18:16:32.610325610 -0400
@@ -6,7 +6,8 @@
 "3.10", 
 "3.12",
 "3.14",
-"3.16"
+"3.16",
+"3.18"
   ], 
   "url": "https://github.com/laserb/gnome-shell-extension-suspend-button;, 
   "uuid": "suspend-button@laserb", 
diff -ur gnome-shell-extension-suspend-button-0~git20150615/README.md gnome-shell-extension-suspend-button-0~git20150615-new/README.md
--- gnome-shell-extension-suspend-button-0~git20150615/README.md	2015-04-11 14:25:44.0 -0400
+++ gnome-shell-extension-suspend-button-0~git20150615-new/README.md	2015-10-12 18:16:23.458280227 -0400
@@ -1,4 +1,4 @@
 gnome-shell-extension-suspend-button
 
 
-GNOME Shell Extension Suspend-Button for GNOME 3.10 / 3.12 / 3.14 / 3.16
+GNOME Shell Extension Suspend-Button for GNOME 3.10 / 3.12 / 3.14 / 3.16 / 3.18
diff -ur gnome-shell-extension-suspend-button-0~git20150615/debian/control gnome-shell-extension-suspend-button-0~git20150615-new/debian/control
--- gnome-shell-extension-suspend-button-0~git20150615/debian/control	2015-06-16 03:20:55.0 -0400
+++ gnome-shell-extension-suspend-button-0~git20150615-new/debian/control	2015-10-12 18:14:12.945633050 -0400
@@ -10,7 +10,7 @@
 
 Package: gnome-shell-extension-suspend-button
 Architecture: all
-Depends: gnome-shell (<< 3.17), gnome-shell (>= 3.10), ${misc:Depends}
+Depends: gnome-shell (<< 3.19), gnome-shell (>= 3.10), ${misc:Depends}
 Recommends: gnome-tweak-tool
 Description: Gnome-shell extension to modify the suspend/shutdown buttons
  This Gnome-shell extension allows you to control the suspend/shutdown buttons

Bug#786115: fixed in vim-latexsuite 20141116.812-1

[Jason Rhinelander]

On Thu, 20 Aug 2015 01:49:04 + Johann Felix Soden 
joh...@debian.org wrote:

Source: vim-latexsuite
Source-Version: 20141116.812-1

We believe that the bug you reported is fixed in the latest version of
vim-latexsuite, which is due to be installed in the Debian FTP archive.


This updated version in sid is not installable due to a new dependency 
on python2, which doesn't exist in the archive; I suspect that 
dependency should be python2.7 instead.


Thanks,

Jason Rhinelander

Bug#795148: mirrors: http://mirror.debian.org/status.html has not been updated since 1 July

[Jason Rhinelander]

Package: mirrors
Severity: normal

Dear Maintainer,

I recently tried to look at mirror status on
http://mirror.debian.org/status.html and noticed that it hasn't updated
in a while:

Data capturing time window:
Wed Jul 1 18:10:03 2015 UTC - Wed Jul 1 19:24:21 2015 UTC
HTML-file creation time: Wed Jul 1 19:24:21 2015 UTC


-- 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.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


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

Bug#792458: opendkim init script failed on start

[Jason Rhinelander]

On Wed, 15 Jul 2015 01:01:41 -0400 Scott Kitterman 
deb...@kitterman.com wrote:

On Wednesday, July 15, 2015 12:24:18 AM Cyrille Mescam wrote:
 Package: opendkim
...
 Trying to start the service: service opendkim start
...
 Init: systemd (via /run/systemd/system)
...

You started opendkim with the sysv init interface (which used the old sysv
init script) even though you are running systemd as your init system and a
systemd service file is provided.  What happens if you do:

systemctl start opendkim

You may have to clear the failed state first.  I think this will do that:

systemctl reset-failed opendkim



I get exactly the same problem, and the above did not fix it.  I found 
the problem, however: systemd environment files do *not* support in-line 
comments such as:


SOCKET=local:/var/run/opendkim/opendkim.sock # default

in the original report, or in my case:

SOCKET=inet:12345@localhost # listen on loopback on port 12345

which is how the examples in /etc/default/opendkim used to be (prefixed 
with another # at the beginning of the line).  It really isn't obvious 
that this change was significant across the upgrade (it looked more like 
just cosmetic reformatting), and so I just selected to keep my 
currently-installed version.


That broke because systemd doesn't see an inline # as starting a 
comment, and so ends up trying to start opendkim by running (in the 
original reporter's case):


/usr/sbin/opendkim -x /etc/opendkim.conf -u opendkim -P 
/var/run/opendkim/opendkim.pid -p local:/var/run/opendkim/opendkim.sock 
# default


which is obviously wrong, and hence opendkim fails to start.

So Cyrille can fix this by removing  # default from the end of the 
line in /etc/default/opendkim, and I've fixed my own similarly.


But since these inline comments were the default /etc/default/opendkim 
examples in the previous version, this seems like something that is 
going to come up for a lot of people when upgrading opendkim on a 
systemd-running system, since basically the old /etc/default/opendkim 
configuration file won't work with the new package.  Is there something 
else that can be done to catch and/or fix this on upgrade?



Jason Rhinelander


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

Bug#785049: printer-driver-cups-pdf: Syntax error in printer-driver-cups-pdf.postint

[Jason Rhinelander]

Package: printer-driver-cups-pdf
Version: 2.6.1-19
Severity: normal

Dear Maintainer,

When upgrading printer-driver-cups-pdf I noticed this error during
installation:

Setting up printer-driver-cups-pdf (2.6.1-19) ...
/var/lib/dpkg/info/printer-driver-cups-pdf.postinst: 50: [: missing ]
Skipped automated creation of the PDF queue.

The referenced line contains:

if [ -z $(LC_ALL=C lpstat -h localhost -v 2/dev/null | grep 
'cups-pdf:/')  -d /run/cups/certs ]

and the '' inside '[ ... ]' is what is throwing the error.  I suspect
(but did not test) that the conditional check on /run/cups/certs isn't
actually running.

Some possible fixes:

if [ -z $(LC_ALL=C lpstat -h localhost -v 2/dev/null | grep 
'cups-pdf:/') -a -d /run/cups/certs ]

if [ -z $(LC_ALL=C lpstat -h localhost -v 2/dev/null | grep 
'cups-pdf:/') ]  [ -d /run/cups/certs ]

if LC_ALL=C lpstat -h localhost -v 2/dev/null | grep -Lq 
'cups-pdf:/'  [ -d /run/cups/certs ]


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages printer-driver-cups-pdf depends on:
ii  cups1.7.5-11
ii  cups-client 1.7.5-11
ii  ghostscript 9.06~dfsg-2
ii  libc6   2.19-18
ii  libpaper-utils  1.1.24+nmu4

printer-driver-cups-pdf recommends no packages.

Versions of packages printer-driver-cups-pdf suggests:
ii  system-config-printer  1.4.6-1

-- no debconf information


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

Bug#781757: Please apply upstream workaround for nvidia-driver background garbage on resume

[Jason Rhinelander]

Package: gnome-shell
Version: 3.14.2-3+b1
Severity: normal
Tags: upstream

Dear Maintainer,

The proprietary NVIDIA driver has a bug where it doesn't preserve OpenGL 
frame buffer objects (FBOs) across power events (most noticeably across 
a suspend/resume cycle).  This is reported in Debian as bug 
https://bugs.debian.org/761360 (and a couple others that got merged into 
that), and upstream as https://bugzilla.gnome.org/739178.  GNOME started 
storing the backgrounds for the desktop and lock screen in FBOs in 3.14, 
which is why the issue didn't show up before 3.14.


This is NVIDIA's problem, of course, and NVIDIA has admitted as much, 
but the word from NVIDIA is just that this will be fixed at some 
indeterminate point in the future.


In the meantime, upstream has applied a patch included in the 3.14.4 
releases of gnome-shell and mutter, and will also include this fix in 
the 3.16.1 release.  The patch adds an ability to mutter to redraw all 
FBO background instances, and invokes this from gnome-shell during resume.


The upstream patches (reattached here) apply to the gnome-shell and 
mutter versions currently in sid/testing.  I've rebuilt the packages 
locally (on amd64/unstable) with the patches applied, and can confirm 
that this does work around the problem with the proprietary NVIDIA driver.


It would be nice for proprietary NVIDIA jessie users if we could get 
these patches applied to jessie as well, perhaps for the first jessie 
point update, either with a package update to 3.14.4, or by applying 
these patches to the current 3.14.2 version: this is going to be an 
issue that affects a lot of jessie users, and it doesn't sound as though 
NVIDIA is particularly concerned about fixing it in the immediate future.


The upstream patches are attached here for convenience: 
background-instance-refresh.patch is the mutter side of the fix, 
refresh-bg-after-suspend.patch is the gnome-shell side of the fix.


Thanks,

Jason Rhinelander
From c96f57449f1cdc60162f6bbcc82d504fde5c1f76 Mon Sep 17 00:00:00 2001
From: Rui Matos tiagoma...@gmail.com
Date: Thu, 19 Mar 2015 14:58:25 +0100
Subject: [PATCH] meta-background: Add a function to refresh all background
 instances

We need to reload the FBOs under some circumstances, this adds a way
to easily do so.

https://bugzilla.gnome.org/show_bug.cgi?id=739178
---
 src/compositor/meta-background.c | 14 ++
 src/meta/meta-background.h   |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/src/compositor/meta-background.c b/src/compositor/meta-background.c
index 6284a7a..3f2e23f 100644
--- a/src/compositor/meta-background.c
+++ b/src/compositor/meta-background.c
@@ -71,6 +71,8 @@ enum
 
 G_DEFINE_TYPE (MetaBackground, meta_background, G_TYPE_OBJECT)
 
+static GSList *all_backgrounds = NULL;
+
 static void
 free_fbos (MetaBackground *self)
 {
@@ -305,6 +307,8 @@ meta_background_dispose (GObject *object)
 static void
 meta_background_finalize (GObject *object)
 {
+  all_backgrounds = g_slist_remove (all_backgrounds, object);
+
   G_OBJECT_CLASS (meta_background_parent_class)-finalize (object);
 }
 
@@ -347,6 +351,7 @@ meta_background_init (MetaBackground *self)
   self-priv = G_TYPE_INSTANCE_GET_PRIVATE (self,
 META_TYPE_BACKGROUND,
 MetaBackgroundPrivate);
+  all_backgrounds = g_slist_prepend (all_backgrounds, self);
 }
 
 static void
@@ -913,3 +918,12 @@ meta_background_set_blend (MetaBackground  *self,
   free_wallpaper_texture (self);
   mark_changed (self);
 }
+
+void
+meta_background_refresh_all (void)
+{
+  GSList *l;
+
+  for (l = all_backgrounds; l; l = l-next)
+mark_changed (l-data);
+}
diff --git a/src/meta/meta-background.h b/src/meta/meta-background.h
index 822d27b..d48d966 100644
--- a/src/meta/meta-background.h
+++ b/src/meta/meta-background.h
@@ -57,6 +57,8 @@ struct _MetaBackground
   MetaBackgroundPrivate *priv;
 };
 
+void meta_background_refresh_all (void);
+
 GType meta_background_get_type (void);
 
 MetaBackground *meta_background_new  (MetaScreen *screen);
-- 
2.1.0
From d19e78af2459b1b5165848b643525df29ee20265 Mon Sep 17 00:00:00 2001
From: Rui Matos tiagoma...@gmail.com
Date: Thu, 19 Mar 2015 15:46:08 +0100
Subject: [PATCH] Refresh all background instances after suspend if needed

NVIDIA drivers don't preserve FBO contents across suspend / resume
cycles which results in broken backgrounds. We can work around that by
forcing a refresh when coming out of suspend.

https://bugzilla.gnome.org/show_bug.cgi?id=739178
---
 js/ui/layout.js  | 13 +
 src/shell-util.c | 33 +
 src/shell-util.h |  2 ++
 3 files changed, 48 insertions(+)

diff --git a/js/ui/layout.js b/js/ui/layout.js
index 9228bd1..e9aab13 100644
--- a/js/ui/layout.js
+++ b/js/ui/layout.js
@@ -11,6 +11,7 @@ const St = imports.gi.St;
 
 const Background = imports.ui.background;
 const BackgroundMenu = imports.ui.backgroundMenu

Bug#761360: GNOME fix

[Jason Rhinelander]

This is a NVIDIA driver bug, but it is only something that NVIDIA claims 
will be fixed at some indeterminate future date.  In the meantime, 
upstream gnome has applied a workaround (to 3.16.1, I think, but didn't 
make it into 3.16.0) for this, referenced in 
https://bugzilla.gnome.org/show_bug.cgi?id=739178 that basically forces 
a refresh of background instances during resume.


The two patches attached to that bug report apply to mutter (the 
meta-background patch) and gnome-shell (the Refresh all background 
patch), and apply cleanly to the 3.14 versions of those packages 
currently in testing.


I applied the patches, rebuilt mutter and gnome-shell, and the problem 
is gone: suspend and resume now work without any lock and desktop 
background garbling.


Jason Rhinelander


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

Bug#779717: FATAL:isolate_holder.cc(70)] Couldn't mmap v8 natives data file

[Jason Rhinelander]

As per upstream https://crbug.com/421063 chromimum now builds its v8 
code into natives_blob.bin and snapshot_blob.bin, loading them itself at 
runtime instead of linking them statically to the chromium binary (which 
is what happened = 40).


The current debian build, however, doesn't copy these files into 
/usr/lib/chromium, hence the error.


Adding this line to debian/chromium.install fixes the build:



out/Release/*.bin usr/lib/chromium



(It seems most logical to me to add it right after the out/Release/*.pak 
line, but it shouldn't matter where it gets added).


I added it, rebuilt the package, and can verify that the resulting 
chromium package now works.




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#761226: please try with LO 4.3.2 rc1

[Jason Rhinelander]

On 13/09/14 10:08 AM, Rene Engelhard wrote:

Hi,

[...]

I uploaded the debs to https://people.debian.org/~rene/libreoffice/4.3.2/. You 
can use
them to check/confirm yourself.



I upgraded to your 4.3.2~rc1-1 debs, and can confirm that the problem is 
no longer present.



Jason Rhinelander




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#759769: aptitude: Installed Size diff reported wrong for packages larger 2GiB if installed

[Jason Rhinelander]

On Sat, 30 Aug 2014 07:52:54 +0200 Benny Baumann be...@geshi.org wrote:

To reproduce have a look at the linux-image-*-dbg packages that require
more than 2GiB on amd64 after installation. When installing such a package
aptitude will report something like pi linux-image-*-dbg   -1,900M ...
while the correct display would report +2300M instead.

Likewise uninstalling such a package will report something along the lines
of id linux-image-*-dbg   +1,900M where -2,300M would be correct.


Just to clarify the above, it's only the disk usage on the individual 
package line that is incorrect: the overall total near the top of the 
interface (Will use xxx MB of disk space) is correct.


libreoffice-dbg is another such package (showing -870MB when selected 
for installation instead of the correct +3,425MB).




Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#761226: libreoffice-writer: Segmentation fault on special document content/input

[Jason Rhinelander]

Package: libreoffice-writer
Version: 1:4.3.1-1
Severity: important

Dear Maintainer,

libreoffice-writer will segfault when a file contains content such as:

(1)(2)(3)aa

This can be in an existing file being opened, or simply typed or pasted into a
blank document.

Variations I've tried that also trigger the segfault:

- Adding spaces around (before, between, and after) the parenthesized values.
- changing the 1,2,3 values to any other numbers.
- adding more numbers (parenthesized or not) between (3) and aa.

Variations that avoid the segfault:

- Changing any of the 1,2,3 values to non-numeric values.
- Making the trailing content consist of a single letter.  (The segfault occurs
in the original example only when something follows the first a.)
- Prior content on the line.  e.g. a line with a(1)(2)(3)aa seems okay.
- Making the trailing content consist only of numbers (whether or not
parenthesized).  Neither (1)(1)(1) 42 56 12345 nor (1)(1)(1)(42) trigger
the segfault, but (1)(1)(1) 42 56 12345 aa does.


A backtrace is attached.



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

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

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.0-2
ii  libc6  2.19-10
ii  libe-book-0.1-10.1.1-2
ii  libgcc11:4.9.1-13
ii  libicu52   52.1-5
ii  libmwaw-0.3-3  0.3.1-2
ii  libodfgen-0.1-10.1.1-2
ii  libreoffice-base-core  1:4.3.1-1
ii  libreoffice-core   1:4.3.1-1
ii  librevenge-0.0-0   0.0.1-3
ii  libstdc++6 4.9.1-13
ii  libwpd-0.10-10 0.10.0-2
ii  libwpg-0.3-3   0.3.0-3
ii  libwps-0.3-3   0.3.0-2
ii  libxml22.9.1+dfsg1-4
ii  uno-libs3  4.3.1-1
ii  ure4.3.1-1
ii  zlib1g 1:1.2.8.dfsg-2

Versions of packages libreoffice-writer recommends:
pn  libreoffice-math  none

Versions of packages libreoffice-writer suggests:
ii  default-jre [java5-runtime]2:1.7-52
ii  fonts-crosextra-caladea20130214-1
pn  fonts-crosextra-carlitonone
ii  libreoffice-base   1:4.3.1-1
pn  libreoffice-gcjnone
ii  libreoffice-java-common1:4.3.1-1
ii  openjdk-7-jre [java5-runtime]  7u65-2.5.2-3

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.1
ii  fonts-opensymbol  2:102.6+LibO4.3.1-1
ii  libatk1.0-0   2.12.0-1
ii  libboost-date-time1.55.0  1.55.0+dfsg-2
ii  libc6 2.19-10
ii  libcairo2 1.12.16-5
ii  libclucene-contribs1  2.3.3.4-4
ii  libclucene-core1  2.3.3.4-4
ii  libcmis-0.4-4 0.4.1-7
ii  libcups2  1.7.5-1
ii  libcurl3-gnutls   7.38.0-1
ii  libdbus-1-3   1.8.6-2
ii  libdbus-glib-1-2  0.102-1
ii  libeot0   0.01-3
ii  libexpat1 2.1.0-6
ii  libexttextcat-2.0-0   3.4.4-1
ii  libfontconfig12.11.0-6.1
ii  libfreetype6  2.5.2-1.1
ii  libgcc1   1:4.9.1-13
ii  libgdk-pixbuf2.0-02.30.8-1
ii  libgl1-mesa-glx [libgl1]  10.2.6-1
ii  libglew1.10   1.10.0-3
ii  libglib2.0-0  2.40.0-5
ii  libgltf-0.0-0 0.0.0-2
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgraphite2-31.2.4-3
ii  libgtk2.0-0   2.24.24-1
ii  libharfbuzz-icu0  0.9.35-1
ii  libharfbuzz0b 0.9.35-1
ii  libhunspell-1.3-0 1.3.3-2
ii  libhyphen02.8.7-3
ii  libice6   2:1.0.9-1
ii  libicu52  52.1-5
ii  libjpeg8  8d1-1
ii  liblangtag1   0.5.1-2
ii  liblcms2-22.6-3
ii  libldap-2.4-2 2.4.39-1.1+b1
ii  libmythes-1.2-0   2:1.2.4-1
ii  libneon27-gnutls  0.30.0-4
ii  libnspr4  2:4.10.7-1
ii  libnss3   2:3.17-1
ii  libnss3-1d2:3.17-1
ii  libodfgen-0.1-1   0.1.1-2
ii  libpango-1.0-01.36.7-1
ii  libpangocairo-1.0-0   1.36.7-1
ii  libpangoft2-1.0-0 1.36.7-1
ii  libpng12-01.2.50-2
ii  librdf0   1.0.17-1+b1
ii  libreoffice-common1:4.3.1-1
ii  librevenge-0.0-0  0.0.1-3
ii  libsm62:1.2.2-1
ii  libssl1.0.0   1.0.1i-2
ii  libstdc++64.9.1-13
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.2-1
ii  libxinerama1  2:1.1.3-1
ii  libxml2   2.9.1+dfsg1-4
ii  libxrandr22:1.4.2-1
ii  libxrender1   1:0.9.8-1
ii  libxslt1.11.1.28-2
ii  libxt61:1.1.4-1

Bug#744792: clang-3.4: unusable with libstdc++ from gcc 4.9

[Jason Rhinelander]

Hi,

Sylvestre Ledru wrote:

On 14/04/2014 21:40, Ben Longbons wrote:

Package: clang-3.4
Version: 1:3.4-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

clang 3.4 can't use libstdc++ 4.9's headers, due to changes in
bits/c++config.h

Thanks for the bug report.
For now, it is just normal severity:
* we are still using gcc 4.8 as default


Indeed, and clang itself is still buildable with gcc 4.8, but that isn't 
the main issue here.


Rather the issue is that compiling user programs with clang breaks: 
C++11 code (and possibly other C++ standard levels, but I didn't test) 
that includes the cstddef header will fail to compile if the 
libstdc++-4.9-dev package is installed, which will happen, for instance, 
if someone installs g++-4.9.  I think this qualifies the bug as at least 
'important', if not 'grave'.



* gcc 4.9 has not (yet) been released.


It has now been released, and is available in testing for most 
architectures.  I installed g++-4.9 to try it out; doing so broke 
compilation with clang++.


Upstream has discussed the problem and has fixes for it; it requires 
these two patches to llvm:


http://llvm.org/viewvc/llvm-project?view=revisionrevision=201729
http://llvm.org/viewvc/llvm-project?view=revisionrevision=201843

Upstream mailing list discussion regarding the two above changes is here:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/072711.html


I've applied the patches locally and can verify that they do solve the 
problem.  Here's a simple example of the error without the patches applied:


jagerman@loki:~$ cat test.cpp
#include iostream
#include cstddef
int main() { std::cout  hi!\n; }

jagerman@loki:~$ clang++ -std=c++11 test.cpp
In file included from test.cpp:2:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/cstddef:51:11: 
error:

  no member named 'max_align_t' in the global namespace
  using ::max_align_t;
~~^
1 error generated.



Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#742362: bash-completion: Bash completion no longer loads from /etc/profile.d/bash_completion.sh

[Jason Rhinelander]

Package: bash-completion
Version: 1:2.1-3
Severity: important

Dear Maintainer,

bash-completion 2.1-3 includes a fix for bug 741657, but the fix is
broken: it prevents /etc/profile.d/bash_completion.sh from loading
bash_completion at all.

The problem is that this line:

if [ -n $BASH_VERSION -a -n $PS1 -a $BASH_COMPLETION_COMPAT_DIR ]; 
then

is missing a -z before checking the $BASH_COMPLETION_COMPAT_DIR
variable.  Note that the upstream change referenced in 741657 (
http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=867282a
) correctly includes the -z, but
debian/patches/11-dont_return_from_sourced_script.patch is missing it.


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

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

Versions of packages bash-completion depends on:
ii  bash  4.3-4
ii  dpkg  1.17.6

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information


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

Bug#734865: libapache2-mpm-itk: fails to install: subprocess installed post-installation script returned error exit status 1

[Jason Rhinelander]

It's currently not possible to reinstall (or, when a new release comes 
along, upgrade to a newer version) because postinst is doing, as Eric 
pointed out, (essentially) an a2enmod mpm_itk--and this call fails if 
mpm_itk is already enabled.


The problem belongs to apache2, however: 
/etc/apache2/mods-available/mpm_prefork.load declares:


# Conflicts: mpm_event mpm_worker mpm_itk

but mpm_itk.load (as of the latest version) depends on mpm_prefork:

# Depends: mpm_prefork


a2enmod considers the dependency satisfied the very first time an 
'a2enmod mpm_itk' happens, because, at that time, mpm_itk isn't active 
yet, so the mpm_prefork dependency is satisfied.


If mpm_itk is already enabled, `a2enmod mpm_itk' fails because its 
mpm_prefork dependency now fails because the mpm_prefork dependency 
can't be enabled:


# a2enmod mpm_itk
WARNING: MPM_ITK is a third party module that is not part of the 
official Apache HTTPD. It has seen less testing than the official MPM 
modules.Considering dependency mpm_prefork for mpm_itk:

Considering conflict mpm_event for mpm_prefork:
Considering conflict mpm_worker for mpm_prefork:
Considering conflict mpm_itk for mpm_prefork:
ERROR: Module mpm_itk is enabled - cannot proceed due to conflicts. It 
needs to be disabled first!

ERROR: Could not enable dependency mpm_prefork for mpm_itk, aborting



Long story short: apache2 needs to remove the conflict with mpm_itk from 
mpm_prefork.load.



--
Jason Rhinelander


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

Bug#738131: libapache2-mpm-itk: seteuid() and various related functions are broken by seccomp syscall limits

[Jason Rhinelander]

Package: libapache2-mpm-itk
Version: 2.4.6-01-1
Severity: important

Dear Maintainer,

The current version of mpm-itk breaks code attempting to do legitimate 
setuid-type operations because of the seccomp BPF protections.


The reason stems from the fact that -1 is a permitted argument for 
syscalls that change multiple ID's at once, such as setresuid, to which 
(uid_t) -1 can be passed to indicate don't change this value.


Since (uid_t) -1 == 4294967295 for everything except the old 16-bit i386 
syscalls, these do-nothing values well exceed the max_uid = 65535, and 
so these calls are blocked.  Thus code which *should* be allowed (such 
as setresuid(-1, currentid, -1) return EPERM.


In practice, this breaks anything that relies on uid changes that 
*should* be permitted: in my case, a cgi script that invokes ssh fails 
because ssh calls something with a -1 argument.


The attached patch updates the filters to extend the syscall argument 
limits by allowing a specific value outside that min...max range, and -1 
is passed for this value where needed.  Thus in effect the uid/gid 
syscall limits now allow anything in [min, max], and also -1.


With the patch, -1 is allowed for all the arguments of the blocked 
syscalls except for __NR_setuid/__NR_setgid (and the ...32 version on 
i386): -1 isn't a special value there.  -1 isn't special for 
__NR_setfsuid (and ...gid), either, but since man setfsuid specifically 
suggests calling setfsuid a second time (with -1 as an argument) to 
detect failures, I allowed it for those syscalls, too.


(I also had to reorganize the various limit_syscall_range code because 
the -1 value ((__u16) -1 == 65535) for the i386, 16-bit __NR_set*uid 
calls doesn't coincide with the ((uid_t) -1 == 4294967295) value of 
non-i386's __NR_set*uid syscalls.)


I tested the code (on amd64) by extracting the capabilities and BPF 
filter code into a test program, to make sure it was working, and indeed 
it is: after the limits, all the restricted functions are indeed 
restricted, while the various seteuid and related failures are now fixed.



Jason Rhinelander
--- mpm-itk-2.4.6-01.orig/seccomp.c	2013-07-10 07:22:20.0 -0400
+++ mpm-itk-2.4.6-01/seccomp.c	2014-02-07 17:16:55.139802820 -0500
@@ -95,7 +95,7 @@
 ++*pos;
 }
 
-static int limit_syscall_range(int syscall_to_match, int nr_args, int min, int max)
+static int limit_syscall_range(int syscall_to_match, int nr_args, __u32 min, __u32 max, __u32 or_eq)
 {
 static struct sock_filter syscall_filter[BPF_MAXINSNS];
 
@@ -108,6 +108,8 @@
 
 for (int i = 0; i  nr_args; ++i) {
 add_bpf_stmt(syscall_filter, pos, BPF_LD + BPF_W + BPF_ABS, syscall_arg(i));
+if (or_eq  min || or_eq  max)
+add_bpf_jump(syscall_filter, pos, BPF_JMP + BPF_JEQ + BPF_K, or_eq, 4, 0);
 add_bpf_jump(syscall_filter, pos, BPF_JMP + BPF_JGE + BPF_K, min, 1, 0);
 add_bpf_stmt(syscall_filter, pos, BPF_RET + BPF_K, SECCOMP_RET_ERRNO | EPERM);
 add_bpf_jump(syscall_filter, pos, BPF_JMP + BPF_JGT + BPF_K, max, 0, 1);
@@ -128,6 +130,11 @@
 gid_t min_gid16 = (min_gid  65535) ? 65535 : min_gid;
 gid_t max_gid16 = (max_gid  65535) ? 65535 : max_gid;
 
+uid_t minus_one = (uid_t) -1;
+#ifdef __i386__
+__u16 minus_one16 = (__u16) -1;
+#endif // defined(__i386__)
+
 /* Apply a seccomp BPF to ourselves that disallows all setuid- and
  * setgid-like calls if the first argument is 0.  The list of calls comes from
  * the descriptions of CAP_SETUID and CAP_SETGID in capabilities(7), although
@@ -146,29 +153,43 @@
 if (apply_seccomp_filter(arch_filter, sizeof(arch_filter) / sizeof(arch_filter[0])) != 0) {
 return;
 }
-#ifdef __i386__
-limit_syscall_range(__NR_setfsuid32, 1, min_uid, max_uid);
-limit_syscall_range(__NR_setuid32, 1, min_uid, max_uid);
-limit_syscall_range(__NR_setreuid32, 2, min_uid, max_uid);
-limit_syscall_range(__NR_setresuid32, 3, min_uid, max_uid);
-#endif  // defined(__i386__)
-
-limit_syscall_range(__NR_setfsuid, 1, min_uid16, max_uid16);
-limit_syscall_range(__NR_setuid, 1, min_uid16, max_uid16);
-limit_syscall_range(__NR_setreuid, 2, min_uid16, max_uid16);
-limit_syscall_range(__NR_setresuid, 3, min_uid16, max_uid16);
 
 #ifdef __i386__
-limit_syscall_range(__NR_setfsgid32, 1, min_gid, max_gid);
-limit_syscall_range(__NR_setgid32, 1, min_gid, max_gid);
-limit_syscall_range(__NR_setregid32, 2, min_gid, max_gid);
-limit_syscall_range(__NR_setresgid32, 3, min_gid, max_gid);
-#endif  // defined(__i386__)
-
-limit_syscall_range(__NR_setfsgid, 1, min_gid16, max_gid16);
-limit_syscall_range(__NR_setgid, 1, min_gid16, max_gid16);
-limit_syscall_range(__NR_setregid, 2, min_gid16, max_gid16);
-limit_syscall_range(__NR_setresgid, 3, min_gid16, max_gid16);
+/* Newer, 32-bit uid_t/gid_t syscalls: */
+limit_syscall_range(__NR_setfsuid32, 1, min_uid, max_uid, minus_one);
+limit_syscall_range

Bug#734814: libapache2-mpm-itk: can no longer set group to one that the user does not belong to

[Jason Rhinelander]

On 04/02/14 04:47 PM, Steinar H. Gunderson wrote:

On Tue, Feb 04, 2014 at 04:28:18PM -0500, Jason Rhinelander wrote:

My guess here is that something in the new apache/mpm-itk
combination is removing the ability to seteuid/setegid sometime
after the seteuid is done for the VirtualHost, and this is breaking
anything later in the request that needs to do a seteuid, even for a
trivial seteuid to the already active euid.


There are really only two things that can cause this, namely capabilities and
the seccomp v2 sandbox. My guess would be on the latter.

However, I don't see how this can cause the original bug?


Indeed you're right.  I'll refile that as a new bug shortly.

As for the original bug report, I poked around with adding some 
debugging for bmc's test case with git (with s/bmc/jagerman/g), and 
there seems to be a problem in when itk_post_perdir_config is being 
called under the new version.


It's definitely *not* a problem with the previous request interfering 
with the later request: my initial and subsequent requests are handled 
by two entirely different processes.


What I'm seeing is the following, for a single request handled by 
/usr/lib/git-core/git-http-backend per bmc's config:


For 'POST /git/jagerman/foo.git/git-receive-pack', I see:

- itk_post_perdir_config gets called with r-uri = 
/git/jagerman/foo.git/git-receive-pack and r-filename = 
/usr/lib/git-core/git-http-backend.


setgid/initgroups/setuid runs and succeeds.

- in the same request, itk_post_perdir_config gets called again, this 
time with r-uri = /jagerman/foo.git/git-receive-pack and r-filename = 
/var/www/html/jagerman.


Notice the initial /git is gone now from r-uri.

It's this second call to itk_post_perdir_config that fails, because for 
that uri (/jagerman/foo.git/git-receive-pack), which doesn't exist, we 
aren't matching the LocationMatch with the AssignUserID anymore.  Thus 
the default (www-data:www-data) user applies.


That fails, of course, because we already setuid to 1000 during the 
first itk_post_perdir_config call: so the initgroups fails, and we trash 
the connection.



(I should also add that the POST above is actually the second request: 
there are also two initial GETs: the first, unauthenticated, for which 
itk_post_perdir_config is called once.  The second, with authentication, 
yields exactly the same double-call behaviour.  No error is occurring 
there, however, because both the (correct) initial call and second call 
(this time with r-uri = /jagerman/foo.git/info/refs) map to the same 
www-data user, and so the second set of setgid/setuid/initgroups calls 
succeeds because it's not actually trying to change anything).



Comparing the old code to the new, the apache hook setup is quite 
different: itk_post_perdir_config used to be set up via 
ap_hook_header_parser(...) (in apache2 2.4.6-3), while it's now 
ap_hook_post_perdir_config(...).



I don't know where to go from here, but hopefully this helps you figure 
out the issue.



--
Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#734814: libapache2-mpm-itk: can no longer set group to one that the user does not belong to

[Jason Rhinelander]

On 05/02/14 03:52 PM, Steinar H. Gunderson wrote:

Oh. It does sound like your mod_rewrite setup is somehow relevant for this,
then?


s/yours/bmc's/, but perhaps.  (This bug isn't actually affecting me, but 
I the digging looking into the other setuid problem I mentioned earlier.)


--
Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#734814: libapache2-mpm-itk: can no longer set group to one that the user does not belong to

[Jason Rhinelander]

I'm seeing something that seems related to this.  I boiled down my CGI 
script to this really simple test case:


#!/usr/bin/perl
my $id = `id`;
$ = 1000;
print qq{Content-Type: text/plain\n\n$id\$!=$!\n};


using AssignUserID jagerman jagerman for the VirtualHost, and where 
1000 is my user id.  The $ = 1000 line of that script is just doing a 
seteuid to the current euid, and that call is failing under the new mpm-itk.


Under the previous version (2.4.6-3 for both apache2 and 
apache2-mpm-itk) and running the script on the command line this seteuid 
call succeeds, indicating no error:


uid=1000(jagerman) gid=1000(jagerman) 
groups=1000(jagerman),27(sudo),50(staff)

$!=


but under the new libapache2-mpm-itk 2.4.6-01-1 and apache2 2.4.7-1, the 
seteuid is failing:



uid=1000(jagerman) gid=1000(jagerman) 
groups=1000(jagerman),27(sudo),50(staff)

$!=Operation not permitted


The same thing happens if I change the script to do a setegid (by 
changing '$' to '$)').



In my case, my CGI script that had an ssh call stopped working when I 
upgraded (apparently ssh fails if it is unable to seteuid).



My guess here is that something in the new apache/mpm-itk combination is 
removing the ability to seteuid/setegid sometime after the seteuid is 
done for the VirtualHost, and this is breaking anything later in the 
request that needs to do a seteuid, even for a trivial seteuid to the 
already active euid.



--
Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#706495: Bug fixed

[Jason Rhinelander]

Hi,

It's not exactly fixed if upgrading via one of the versions that was in 
experimental (in my case clang and clang-3.2 versions 3.2-1~exp8).  I 
upgraded just now to the latest in unstable (clang-3.2 3.2repack-3, 
clang 3.2-17), and got the same errors as the original reporter: clang 
was unable to find various standard headers such as stdarg.h.


I suspect this is because the newer packages (in unstable) have 
/usr/lib/clang/3.2/lib and /usr/include/clang/3.2/include as symlinks to 
/usr/lib/llvm-3.2/lib/clang/3.2/lib and 
/usr/lib/llvm-3.2/lib/clang/3.2/include.


After upgrading from the experimental packages, however, my 
/usr/lib/clang/3.2/lib and /usr/include/clang/3.2/include were *NOT* 
symlinks, and instead just empty directories.


Uninstalling clang/llvm-related packages entirely and reinstalling them 
got the appropriate symlinks, and my clang can find standard headers again.


(I realize that cleaning up breakages from installing experimental 
packages is implicitly my own responsibility--but I thought I'd leave a 
comment in case anyone else runs into the same issue).





smime.p7s
Description: S/MIME Cryptographic Signature

Bug#668837: gstreamer0.10-plugins-good: GStreamer stops decoding in the middle of a flac

[Jason Rhinelander]

I'm seeing the same issue (though I can't distribute the FLAC in 
question), using the latest sid version (0.10.31-3).


I did a little more debugging on this; using gstreamer0.10-tools, this 
command reproduces the error, with the gstreamer debugging suggesting a 
problem:


gst-launch-0.10 --gst-debug-level=2 filesrc 
location=10-machinae_supremacy-cryosleep.flac ! flacparse ! flacdec ! 
pulsesink


Just before the track finishes prematurely, there's this:

0:00:58.040476180  4864  0x148dad0 WARN   flacparse 
gstflacparse.c:576:gst_flac_parse_frame_header_is_valid:flacparse0 
Block size is not constant
0:00:58.040721771  4864  0x148dad0 WARN flacdec 
gstflacdec.c:419:gst_flac_dec_scan_got_frame:flacdec0 Variable block 
size FLAC unsupported
0:00:58.040971058  4864  0x148dad0 WARN   flacparse 
gstflacparse.c:576:gst_flac_parse_frame_header_is_valid:flacparse0 
Block size is not constant


The last one gets repeated a few thousand times, then playback stops. 
For my file I get the same errors and result.  For both Anton's file and 
my file, the FLAC has no errors or warnings when run with flac -t, and 
plays perfectly with non-gstreamer players.


(Note that replacing the final pulsesink in the above command with 
fakesink lets you see the errors without having to wait 58 seconds).


I tried analyzing both FLAC files using ``flac -a filename.flac'', for 
both my file and Anton's file.  The resulting .ana analysis file shows 
that every frame except the very last one has blocksize=4096, so the 
error appears at least misleading, perhaps indicating some flac decoding 
or parsing error in gstreamer.


I also tried installing the gstreamer1.0 packages, and trying the above 
with gst-launch-1.0; exactly the same errors occurred.


After reading Anton's suggestion that he thinks it was working a couple 
months ago, I tried installing 0.10.30-2.1, but that still has the 
problem (though the Block size is not constant error doesn't get 
reported--that check was added upstream since then).


Jason Rhinelander



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

Bug#650459: telepathy-gabble description should mention Facebook Chat

[Jason Rhinelander]

Package: telepathy-gabble
Version: 0.13.7-1
Severity: minor

Dear Maintainer,

It would be very helpful to add  and Facebook Chat to the end of the
telepathy-gabble description (i.e. ..., including Google Talk and
Facebook Chat..  When telepathy-gabble is installed, a Facebook Chat
protocol appears in Empathy, but it isn't obvious that this is a
Jabber/XMPP connection, and the package description as currently written
doesn't suggest that installing telepathy-gabble will give me Facebook
Chat support.

I recently removed telepathy-gabble package (among a bunch of other
upgrades), and the Facebook Chat account type in Empathy disappeared; I
didn't realize it at first, and by the time I did, I'd forgotten about
removing telepathy-gabble.  My mistake, I realize, but when trying to
figure out what I needed to install again to get it working, it took me
some time; in particular, `apt-cache search facebook' doesn't list
telepathy-gabble, and it isn't obvious that telepathy-gabble is the
needed package.

As I understand it, many moons ago, to get Facebook Chat working
required adding Jabber/XMPP support, then configuring the facebook
Jabber server info yourself; since Empathy now treats Facebook Chat as
a protocol distinct from Jabber (from the user's perspective), it would
be very useful to have this added to the description of telepathy-gabble,
as is currently the case for Google Talk (which also appears as a
distinct Protocol option in Empathy).

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

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

Versions of packages telepathy-gabble depends on:
ii  libc6   2.13-21 
ii  libdbus-1-3 1.5.8-1 
ii  libdbus-glib-1-20.98-1  
ii  libglib2.0-02.30.2-4
ii  libgnutls26 2.12.14-3   
ii  libnice10   0.1.1-1 
ii  libsoup2.4-12.36.1-1
ii  libsqlite3-03.7.9-2 
ii  libtelepathy-glib0  0.16.2-1
ii  libxml2 2.7.8.dfsg-5

telepathy-gabble recommends no packages.

telepathy-gabble suggests no packages.

-- no debconf information



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

Bug#488088: perl: Unknown error

[Jason Rhinelander]

This is upstream bug #49472
(http://rt.perl.org/rt3/Public/Bug/Display.html?id=49472), fixed by
upstream change 33265
(http://public.activestate.com/cgi-bin/perlbrowse/p/33265).

This is indeed a very annoying bug (particularly for users of Catalyst,
which makes significant use of attributes), with a very small fix that
doesn't depend on other upstream changes.

The fix will, of course, be included in perl 5.10.1, but it would be
nice, particularly for Catalyst users, to see an update to Debian's
5.10.0 with the fix before then.

-- 
-- Jason Rhinelander



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#374371: update-grub fix

[Jason Rhinelander]

I tracked this down and created a patch to fix it.  update-grub converts
filenames with x.y.z versions in them to x.y.z.0, but the sed regex was
only matching when something follows the z--so /boot/vmlinuz-x.y.z-foo
and /boot/vmlinuz-x.y.z.a would work, but /boot/vmlinuz-x.y.z would end
up coming before the -rc versions (or -pre or any of the other special
suffixes update-grub knows about).

The attached patch to lets the x.y.z - x.y.z.0 conversion also happen
when z is at the end of the filename.


-- 
-- Jason Rhinelander
--- old/update-grub	2007-02-05 13:17:25.0 -0400
+++ new/update-grub	2007-02-05 13:17:30.0 -0400
@@ -471,8 +471,8 @@
 v1=$(echo $1 | sed -e 's!^\(.*-\([0-9]\+\.\)\{2,3\}[0-9]\+\)\(.*\)!\1 \3!g')
 	v2=$(echo $2 | sed -e 's!^\(.*-\([0-9]\+\.\)\{2,3\}[0-9]\+\)\(.*\)!\1 \3!g')
 	#If the version number only has 3 digits then put in another .0
-v1=$(echo $v1 | sed -e 's!^\(.*-\([0-9]\+\.\)\{2\}[0-9]\+\)\( .*\)!\1.0 \3!g')
-v2=$(echo $v2 | sed -e 's!^\(.*-\([0-9]\+\.\)\{2\}[0-9]\+\)\( .*\)!\1.0 \3!g')
+v1=$(echo $v1 | sed -e 's!^\(.*-\([0-9]\+\.\)\{2\}[0-9]\+\)\( .*\|$\)!\1.0 \3!g')
+v2=$(echo $v2 | sed -e 's!^\(.*-\([0-9]\+\.\)\{2\}[0-9]\+\)\( .*\|$\)!\1.0 \3!g')
   
 	# Then split the version number and remove any '.' 's or dashes
 	v1=$(echo $v1 | sed -e 's![-\.]\+! !g' -e 's!\([0-9]\)\([[:alpha:]]\)!\1 \2!')

Bug#374371: update-grub fix

[Jason Rhinelander]

Otavio Salvador wrote:
 Can you please provide a test case were it was failing and now it's
 working?


Sure,

Starting from an unpatched /usr/sbin/update-grub:

[EMAIL PROTECTED]:~$ ls -l /boot/vmlinuz-2.6.*
-rw-r--r-- 1 root root 1366789 2006-12-02 12:43 /boot/vmlinuz-2.6.19
-rw-r--r-- 1 root root 1370776 2007-02-05 12:58 /boot/vmlinuz-2.6.20
-rw-r--r-- 1 root root 1415992 2006-12-23 16:03 /boot/vmlinuz-2.6.20-rc1
-rw-r--r-- 1 root root 1371384 2007-01-31 14:09 /boot/vmlinuz-2.6.20-rc6

[EMAIL PROTECTED]:~$ sudo update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
grep: /boot/config*: No such file or directory
Found kernel: /boot/vmlinuz-2.6.20-rc6
Found kernel: /boot/vmlinuz-2.6.20-rc1
Found kernel: /boot/vmlinuz-2.6.20
Found kernel: /boot/vmlinuz-2.6.19
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

[EMAIL PROTECTED]:~$ grep ^kernel /boot/grub/menu.lst
kernel  /boot/vmlinuz-2.6.20-rc6 root=/dev/sda1 ro
kernel  /boot/vmlinuz-2.6.20-rc1 root=/dev/sda1 ro
kernel  /boot/vmlinuz-2.6.20 root=/dev/sda1 ro
kernel  /boot/vmlinuz-2.6.19 root=/dev/sda1 ro
kernel  /boot/memtest86+.bin



The position of 2.6.20 in the above is wrong: 2.6.20 should be treated
as newer than 2.6.20-rc*.  With the patch applied:


[EMAIL PROTECTED]:~$ sudo patch -i update-grub.patch /usr/sbin/update-grub
patching file /usr/sbin/update-grub

[EMAIL PROTECTED]:~$ sudo update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
grep: /boot/config*: No such file or directory
Found kernel: /boot/vmlinuz-2.6.20
Found kernel: /boot/vmlinuz-2.6.20-rc6
Found kernel: /boot/vmlinuz-2.6.20-rc1
Found kernel: /boot/vmlinuz-2.6.19
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done

[EMAIL PROTECTED]:~$ grep ^kernel /boot/grub/menu.lst
kernel  /boot/vmlinuz-2.6.20 root=/dev/sda1 ro
kernel  /boot/vmlinuz-2.6.20-rc6 root=/dev/sda1 ro
kernel  /boot/vmlinuz-2.6.20-rc1 root=/dev/sda1 ro
kernel  /boot/vmlinuz-2.6.19 root=/dev/sda1 ro
kernel  /boot/memtest86+.bin



-- 
-- Jason Rhinelander


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#344162: wbritish-huge: package description seems to be misleading

[Jason Rhinelander]

I tracked this down to two separate issues in the debian/rules file, for
which I've attached a patch.

The first issue is that the 'eval' in 6-2 wasn't quite correct:

for EXT in $$(eval echo \\$$SIZE_EXTENSIONS$$SIZE); do\
^^
There should only be one \ here (otherwise 'echo' is outputting '\10 20
35 40 50-large' instead of '$SIZE_EXTENSIONS-large').

The second problem is that the variables being exported and evaled
(SIZE_EXTENSIONS-large, etc.) contain -'s, which sh won't accept, so it
ends up with the eval being told to eval, e.g., '$SIZE_EXTENSIONS-large'
which it happily evals to 10 20 35 40 50-large instead of the intended
10 20 35 40 50 55 60 70.

The attached debian/rules patch fixes both issues (by defining the
variables with _'s instead of -'s) and makes everything build properly
-- i.e. with the proper sized dict files.

-- 
-- Jason Rhinelander
--- scowl-6.orig/debian/rules	2006-04-18 21:15:19.0 -0700
+++ scowl-6/debian/rules	2006-04-18 21:40:53.0 -0700
@@ -15,11 +15,11 @@
 # corresponding packages for wbritish and wcanadian.
 # The medium size packages have no -size part in their names
 # These are the scowl extensions (complexity numbers?) that contribute to each word list (i.e. each size);
-# the -size parts -small, , -large, and -huge correspond to the end of the binary package name:
-export SIZE_EXTENSIONS-small:=10 20 35
-export SIZE_EXTENSIONS:=$(SIZE_EXTENSIONS-small) 40 50
-export SIZE_EXTENSIONS-large:=$(SIZE_EXTENSIONS) 55 60 70
-export SIZE_EXTENSIONS-huge:=$(SIZE_EXTENSIONS-large) 80
+# the size parts small, , large, and huge correspond to the end of the binary package name:
+export SIZE_EXTENSIONS_small:=10 20 35
+export SIZE_EXTENSIONS:=$(SIZE_EXTENSIONS_small) 40 50
+export SIZE_EXTENSIONS_large:=$(SIZE_EXTENSIONS) 55 60 70
+export SIZE_EXTENSIONS_huge:=$(SIZE_EXTENSIONS_large) 80

 # These are the scowl word list classes we use:
 CLASSES:=words proper-names upper contractions
@@ -31,11 +31,12 @@
 
 	set -e;\
 	for SPELLING in american british canadian; do\
-	  for SIZE in -small  -large -huge; do\
+	  for SIZENAME in small  large huge; do\
+	if [ -n $$SIZENAME ]; then SIZE=-$$SIZENAME; SIZEVAR=_$$SIZENAME; else SIZE=; SIZEVAR=; fi;\
 	echo The following SCOWL word lists were concatenated and sorted (with duplicates  w$$SPELLING$$SIZE.scowl-word-lists-used;\
 	echo removed) to create this word list (see README.Debian for more details):  w$$SPELLING$$SIZE.scowl-word-lists-used;\
 	for CLASS in $(CLASSES); do\
-	  for EXT in $$(eval echo \\$$SIZE_EXTENSIONS$$SIZE); do\
+	  for EXT in $$(eval echo \$$SIZE_EXTENSIONS$$SIZEVAR); do\
 		if [ -f final/english-$$CLASS.$$EXT ]; then\
 		  echo cat final/english-$$CLASS.$$EXT  $$SPELLING-english$$SIZE.unsorted;\
 		  cat final/english-$$CLASS.$$EXT  $$SPELLING-english$$SIZE.unsorted;\

Bug#334582: lftp doesn't list paths on first `ls' for HTTP targets

[Jason Rhinelander]

This problem is fixed in 3.3.3-1.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#334582: lftp doesn't list paths on first `ls' for HTTP targets

[Jason Rhinelander]

Package: lftp
Version: 3.3.2-1
Severity: normal

I installed the latest lftp to avoid the double-free problem (bug
#334059 and several duplicates) but ran into a new bug that didn't
happen with 3.3.1-1 and earlier - when accessing an HTTP host the first
`ls' issued lists nothing, but repeating the `ls' a second time gives
the proper listing.

An example:

[EMAIL PROTECTED]:~$ lftp http://www.google.ca/
cd ok, cwd=/
lftp www.google.ca:/ ls
lftp www.google.ca:/ ls
-rw-r--r--  --  intl/en_ca/images/logo.gif
drwxr-xr-x  --  intl/en/options
-rw-r--r--  --  fr
drwxr-xr-x  --  ads
drwxr-xr-x  --  services
-rw-r--r--  --  intl/en/about.html
lftp www.google.ca:/ exit


`ls' for FTP targets appears to work properly.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-ck1
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)

Versions of packages lftp depends on:
ii  libc6 2.3.5-7GNU C Library: Shared libraries an
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li
ii  libgcc1   1:4.0.2-2  GCC support library
ii  libgcrypt11   1.2.1-4LGPL Crypto library - runtime libr
ii  libgnutls12   1.2.6-1the GNU TLS library - runtime libr
ii  libgpg-error0 1.1-4  library for common error values an
ii  libncurses5   5.5-1  Shared libraries for terminal hand
ii  libreadline5  5.0-11 GNU readline and history libraries
ii  libtasn1-20.2.13-1   Manage ASN.1 structures (runtime)
ii  netbase   4.22   Basic TCP/IP networking system
ii  zlib1g1:1.2.3-6  compression library - runtime

lftp recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#333424: libnet-dns-perl 0.53-1 missing dependency on libnet-ip-perl

[Jason Rhinelander]

Package: libnet-dns-perl
Version: 0.53-1
Severity: important


Net::DNS now requires Net::IP 1.20, which libnet-dns-perl 0.53-1 does
not depend upon, rendering the module unusable until libnet-ip-perl is
installed.  It appears this dependency was introduced in 0.50, but isn't
mentioned in the Net::DNS package's Changes file.

[EMAIL PROTECTED]:~$ perl -MNet::DNS -e0
Can't locate Net/IP.pm in @INC (@INC contains: /etc/perl 
/usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl 
.) at /usr/lib/perl5/Net/DNS/Resolver/Base.pm line 24.
BEGIN failed--compilation aborted at /usr/lib/perl5/Net/DNS/Resolver/Base.pm 
line 24.
Compilation failed in require at /usr/lib/perl5/Net/DNS/Resolver/UNIX.pm line 9.
BEGIN failed--compilation aborted at /usr/lib/perl5/Net/DNS/Resolver/UNIX.pm 
line 9.
Compilation failed in require at /usr/lib/perl5/Net/DNS/Resolver.pm line 19.
BEGIN failed--compilation aborted at /usr/lib/perl5/Net/DNS/Resolver.pm line 22.
Compilation failed in require at /usr/lib/perl5/Net/DNS.pm line 66.
BEGIN failed--compilation aborted at /usr/lib/perl5/Net/DNS.pm line 66.
Compilation failed in require.
BEGIN failed--compilation aborted.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)

Versions of packages libnet-dns-perl depends on:
ii  libc6 2.3.5-6GNU C Library: Shared libraries an
ii  libdigest-hmac-perl   1.01-3 create standard message integrity 
ii  perl [libmime-base64-perl]5.8.7-5Larry Wall's Practical Extraction 
ii  perl-base [perlapi-5.8.7] 5.8.7-5The Pathologically Eclectic Rubbis

libnet-dns-perl recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#316303: apache2-common: apache2ctl -k stop not being used - faulty init.d/apache2 logic

[Jason Rhinelander]

Package: apache2-common
Version: 2.0.54-4
Severity: normal
Tags: patch


The /etc/init.d/apache2 init script that comes with apache2-common has a
logic error that causes the script to always fall back to killing apache
instead of using apache2ctl -k stop.

Basically it's because this:

if `apache2 -t  /dev/null 21`; then

will always be false, due to being in backticks.  After fixing this, I
also noticed and added a fix for bug 290060, which is that `apache2 -k
stop' is being called inside this if statement instead of `apache2ctl -k
stop'.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc4
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)

Versions of packages apache2-common depends on:
ii  apache2-utils 2.0.54-4   utility programs for webservers
ii  debconf   1.4.51 Debian configuration management sy
ii  debianutils   2.14.1 Miscellaneous utilities specific t
ii  libc6 2.3.5-1GNU C Library: Shared libraries an
ii  libdb4.2  4.2.52-19  Berkeley v4.2 Database Libraries [
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li
ii  libgcc1   1:4.0.0-11 GCC support library
ii  libmagic1 4.12-1 File type determination library us
ii  mime-support  3.34-1 MIME files 'mime.types'  'mailcap
ii  net-tools 1.60-13The NET-3 networking toolkit
ii  openssl   0.9.7g-1   Secure Socket Layer (SSL) binary a
ii  ssl-cert  1.0-11 Simple debconf wrapper for openssl

apache2-common recommends no packages.

-- no debconf information
--- /etc/init.d/apache2 2005-06-29 14:19:11.0 -0700
+++ /etc/init.d/apache2.fixed   2005-06-29 14:19:08.0 -0700
@@ -42,14 +42,12 @@
fi
done
 
-   if `apache2 -t  /dev/null 21`; then
+   if $APACHE2 -t  /dev/null 21; then
# if the config is ok than we just stop normaly
 
-   if [ -e $PIDFILE ]
+   if [ -n $PID ]
then
-   PID=`cat $PIDFILE`
-
-   $APACHE2 -k stop
+   $APACHE2CTL -k stop
 
CNT=0
while [ 1 ]