Bug#1013827: varnish-modules: Tests fail in Ubuntu only on armhf

[Stig Sandbeck Mathisen]

Package: varnish-modules
Version: 0.20.2-1
Followup-For: Bug #1013827

Post-build tests fail on armel and armhf on Debian.  See
https://buildd.debian.org/status/package.php?p=varnish-modules

-- 
Stig

Bug#1012076: varnish: Remove me as uploader

[Stig Sandbeck Mathisen]

On Sun, May 29, 2022 at 08:33:30PM +0200, Tollef Fog Heen wrote:
> I haven't been active in maintaining Varnish for quite a few years, could you
> please remove me from uploaders?

Hello Tollef,

I've removed you from the uploaders list, this will make the next package
release.

-- 
Stig

Bug#996425: hitch: diff for NMU version 1.7.1-2.1

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> Dear maintainer,
>
> I've prepared an NMU for hitch (versioned as 1.7.1-2.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
>
> cu
> Adrian
>
>

Hello Adrian,

Thank you for the bugfix, I'll pull it into the packaging repo as well.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#892058: Your Debian key is expiring

[Stig Sandbeck Mathisen]

On Sun, Dec 05, 2021 at 05:36:20AM -0800, felix.lech...@lease-up.com wrote:

> This is a courtesy reminder that your Debian key is expiring on 2022-01-24.
[...]
> If you like this service, please leave a favorable comment here [2].
> Thank you!

Thanks, that was really helpful. :)

-- 
Stig

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> On Wed, Sep 22, 2021 at 08:22:04PM +0200, Stig Sandbeck Mathisen wrote:
>> Adrian Bunk  writes:
>> 
>> > On Sat, Aug 28, 2021 at 09:43:36PM +0200, Stig Sandbeck Mathisen wrote:
>> >> 
>> >> Hello,
>> >> 
>> >> Thank you for the bug report and patch. I did a slight adjustment,
>> >> adding the parameters in debian/rules, and targeting the "gnu"
>> >> libc, see
>> >> https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda
>> >
>> > Could you make an upload with this bug fixed?
>> 
>> That fixed the bug, but the package unfortunately still won't build,
>> and why or why not this happens is not clear to me. Any hints would
>> be welcome. (build log for that commit at
>> https://salsa.debian.org/debian/grok/-/jobs/1870864)
>
> That was fixed in one of the missing NMUs.

Thanks, I'll import those and get the package in shape again.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#775827: RFA: grok -- powerful pattern-matching and reacting tool

[Stig Sandbeck Mathisen]

This package is still up for adoption.  To take over, just do an upload with a
new Maintainer: field in debian/control and close this bug.

The packaging repository is at https://salsa.debian.org/debian/grok/

>>> Stig

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> On Sat, Aug 28, 2021 at 09:43:36PM +0200, Stig Sandbeck Mathisen wrote:
>> 
>> Hello,
>> 
>> Thank you for the bug report and patch. I did a slight adjustment,
>> adding the parameters in debian/rules, and targeting the "gnu" libc,
>> see
>> https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda
>
> Could you make an upload with this bug fixed?

That fixed the bug, but the package unfortunately still won't build, and
why or why not this happens is not clear to me. Any hints would be
welcome. (build log for that commit at
https://salsa.debian.org/debian/grok/-/jobs/1870864)

Also, the "grok" package is up for adoption if anyone would like to take
care of it. (https://bugs.debian.org/775827)

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#994626: lintian-brush 0.112 depends on python3-breezy (>= 3.2.1-1)

[Stig Sandbeck Mathisen]

Package: lintian-brush
Version: 0.112
Severity: normal
Tags: patch

Dear Maintainer,

The "lintian-brush" package uses Repository.get_revision_deltas from
python3-breezy.  This is not available in 3.1.0-8, but us available in 3.2.1-1.

The bug is only visible on a "stable" system using lintian-brush from
"unstable".


With lintian-brush 0.112 and python3-breezy 3.1.0-8 installed I get an error
after changes have been made, but before any git operation:

$ lintian-brush 
   
Traceback (most recent call last):
  File "/usr/bin/lintian-brush", line 33, in 
sys.exit(load_entry_point('lintian-brush==0.112', 'console_scripts', 
'lintian-brush')())
  File "/usr/lib/python3/dist-packages/lintian_brush/__main__.py", line 
328, in main
overall_result = run_lintian_fixers(
  File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 
1187, in run_lintian_fixers
result, summary = run_lintian_fixer(
  File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 
1041, in run_lintian_fixer
dch_guess = guess_update_changelog(
  File "/usr/lib/python3/dist-packages/lintian_brush/detect_gbp_dch.py", 
line 95, in guess_update_changelog
ret = _guess_update_changelog_from_branch(tree.branch, debian_path)
  File "/usr/lib/python3/dist-packages/lintian_brush/detect_gbp_dch.py", 
line 200, in _guess_update_changelog_from_branch
(changelog_only, other_only, mixed, dch_references) = _changelog_stats(
  File "/usr/lib/python3/dist-packages/lintian_brush/detect_gbp_dch.py", 
line 157, in _changelog_stats
get_deltas = branch.repository.get_revision_deltas
AttributeError: 'LocalGitRepository' object has no attribute 
'get_revision_deltas'


With lintian-brush 0.112 and python3-breezy 3.2.1-1 installed, lintian-brush
runs as expected, and makes the world a little bit better again.


$ lintian-brush   
[...]
Lintian tags fixed: {'out-of-date-standards-version', 
'package-uses-deprecated-debhelper-compat-version'}
[...]



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (499, 'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian-brush depends on:
ii  devscripts   2.21.3
ii  python3  3.9.2-3
ii  python3-breezy   3.2.1-1
ii  python3-debian   0.1.39
ii  python3-debmutate0.38
ii  python3-distro-info  1.0
ii  python3-dulwich  0.20.23-1
ii  python3-iniparse 0.4-3
ii  python3-iso8601  0.1.13-1
ii  python3-ruamel.yaml  0.16.12-2
ii  python3-tqdm 4.57.0-2
ii  python3-upstream-ontologist  0.1.22-1

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.27-2
ii  libdebhelper-perl13.3.4
ii  lintian  2.104.0
pn  ognibuild
ii  python3-asyncpg  0.21.0-1+b2
ii  python3-bs4  4.9.3-1
ii  python3-docutils 0.16+dfsg-4
ii  python3-levenshtein  0.12.2-1
ii  python3-lxml 4.6.3+dfsg-0.1
ii  python3-markdown 3.3.4-1
ii  python3-pyinotify0.9.6-1.3
ii  python3-tomlkit  0.6.0-2

Versions of packages lintian-brush suggests:
pn  breezy-debian  
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
pn  postgresql-common  

-- no debconf information
>From cb8cd33862370f263f12c02bb6badfaecb23d802 Mon Sep 17 00:00:00 2001
From: Stig Sandbeck Mathisen 
Date: Sat, 18 Sep 2021 23:06:33 +0200
Subject: [PATCH] Bump dependency on python3-breezy

Class "Repository" does not have get_revision_deltas in 3.1.0
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 64318d3..60ba1e2 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: bash-completion,
dos2unix,
python3-all,
python3-bs4,
-   python3-breezy (>= 3.1.0-8),
+   python3-breezy (>= 3.2.1-1),
python3-breezy.tests,
python3-dulwich (>= 0.19.7),
python3-distro-info,
-- 
2.30.2

Bug#992917: grok: FTBFS due to RPC removal from glibc

[Stig Sandbeck Mathisen]

On Wed, Aug 25, 2021 at 12:46:40AM +0200, Aurelien Jarno wrote:
> Source: grok
> Version: 1.20110708.1-4.5
> Severity: serious
> Tags: patch ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> 
> The glibc SunRPC implementation has been marked obsolete for some time.
> It has been removed upstream from glibc 2.32, and it got disabled in the
> recent glibc uploads. The TI RPC implementation should be used instead,
> which also brings new features (IPv6, Kerberos support, ...).
> 
> For this reason grok now fails to build from source. You will find
> attached a patch to switch to the TI RPC implementation, fixing the
> FTBFS.
> 
> Regards,
> Aurelien

Hello,

Thank you for the bug report and patch.  I did a slight adjustment, adding the
parameters in debian/rules, and targeting the "gnu" libc, see
https://salsa.debian.org/debian/grok/-/commit/fe4c4b549ae2595007271df7502feb54115f4dda

-- 
Stig Sandbeck Mathisen

Bug#991366: nmu: varnish-modules_0.16.0-2.1

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> I am not a member of the release team, but shouldn't #991348 be a
> release critical bug in any case?
>
> An security update of varnish after bullseye became stable could cause
> to same problem, breaking production systems of our users.

[...]

> Doing first an NMU and then the proper fix of varnish-modules for 
> bullseye is not faster than doing the proper fix for varnish-modules
> right away.

Good points, I'll adjust the severity of #991348, do a proper update and
request an unblock. Thanks for the feedback.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#991366: nmu: varnish-modules_0.16.0-2.1

[Stig Sandbeck Mathisen]

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

Hello,

Please do a BinNMU of "varnish-modules" to ensure that the "varnish" security
fix can migrate to testing.

Background: After upgrading "varnish" from 6.5.1 to 6.5.2, the module
"bodyaccess" in this package fails to load, which was discovered with
autopkgtest. The "bodyaccess" module has a stricter dependency on the Varnish
version than the dependency declared in the "varnish-modules" package.

Getting the correct dependency into "varnish-modules" is tracked in
https://bugs.debian.org/991348, but a rebuild of "varnish-modules" against the
new varnish package may be a faster fix due to the freeze.

nmu varnish-modules_0.16.0-2.1 . ANY . unstable . -m "rebuild against new 
varnish"

Bug#991348: varnish-modules should depend on varnish strict abi

[Stig Sandbeck Mathisen]

Package: varnish-modules
Version: 0.16.0-2.1
Severity: normal

When upgrading "varnish", the vmod "bodyaccess" in this package fails to load,
since it has stricter requirements than the package itself.

The package depends on the "ABI vrt" version, while the bodyaccess vmod depends
on the "ABI strict" version to load, which is the specific version of Varnish.

The different ABI versions are documented at
https://varnish-cache.org/docs/5.2/whats-new/changes-5.2.html#abi-strict-vrt

Consequence: This blocks "varnish" upgrades without rebuilding
"varnish-modules" at the same time.

Solution: Ensure "varnish-modules" package depends on the "strict" ABI version
of the varnish package, and ensure "varnish-modules" is rebuilt whenever
"varnish" is uploaded.

Bug#991122: unblock: varnish/6.5.2-1

[Stig Sandbeck Mathisen]

On Mon, Jul 19, 2021 at 10:06:37PM +0200, Graham Inggs wrote:
> On Mon, 19 Jul 2021 at 13:00, Stig Sandbeck Mathisen  wrote:
> > Attached is the diff. Changes are the upstream bugfix, as well as two
> > commits in the packaging repository:
> 
> Thanks.  Please go ahead and upload to unstable, then remove the moreinfo tag
> once it has built.

Hello Graham,

Thanks, will do.

-- 
Stig Sandbeck Mathisen

Bug#991122: unblock: varnish/6.5.2-1

[Stig Sandbeck Mathisen]

ess imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures Varnish 6.5.1 to adapt to many kinds of systems.
+\`configure' configures Varnish 6.5.2 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1505,7 +1505,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of Varnish 6.5.1:";;
+ short | recursive ) echo "Configuration of Varnish 6.5.2:";;
esac
   cat <<\_ACEOF
 
@@ -1672,7 +1672,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-Varnish configure 6.5.1
+Varnish configure 6.5.2
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2147,7 +2147,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by Varnish $as_me 6.5.1, which was
+It was created by Varnish $as_me 6.5.2, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4532,7 +4532,7 @@
 
 # Define the identity of the package.
  PACKAGE='varnish'
- VERSION='6.5.1'
+ VERSION='6.5.2'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -24939,7 +24939,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by Varnish $as_me 6.5.1, which was
+This file was extended by Varnish $as_me 6.5.2, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -25005,7 +25005,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-Varnish config.status 6.5.1
+Varnish config.status 6.5.2
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru varnish-6.5.1/configure.ac varnish-6.5.2/configure.ac
--- varnish-6.5.1/configure.ac  2020-09-25 11:14:30.0 +0200
+++ varnish-6.5.2/configure.ac  2021-07-02 13:57:09.0 +0200
@@ -2,7 +2,7 @@
 AC_COPYRIGHT([Copyright (c) 2006 Verdens Gang AS
 Copyright (c) 2006-2020 Varnish Software])
 AC_REVISION([$Id$])
-AC_INIT([Varnish], [6.5.1], [varnish-...@varnish-cache.org])
+AC_INIT([Varnish], [6.5.2], [varnish-...@varnish-cache.org])
 AC_CONFIG_SRCDIR(include/miniobj.h)
 AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_MACRO_DIR([m4])
diff -Nru varnish-6.5.1/debian/changelog varnish-6.5.2/debian/changelog
--- varnish-6.5.1/debian/changelog  2020-09-29 23:21:31.0 +0200
+++ varnish-6.5.2/debian/changelog  2021-07-14 21:46:38.0 +0200
@@ -1,3 +1,10 @@
+varnish (6.5.2-1) unstable; urgency=medium
+
+  * New upstream release.
+(Closes: #991040, VSV7, CVE-2021-36740)
+
+ -- Stig Sandbeck Mathisen   Wed, 14 Jul 2021 21:46:38 +0200
+
 varnish (6.5.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru varnish-6.5.1/debian/control varnish-6.5.2/debian/control
--- varnish-6.5.1/debian/control2020-09-29 23:21:31.0 +0200
+++ varnish-6.5.2/debian/control2021-07-14 21:46:38.0 +0200
@@ -18,7 +18,7 @@
pkg-config,
python3-sphinx,
xsltproc
-Standards-Version: 4.4.1
+Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/varnish-team/varnish
 Vcs-Git: https://salsa.debian.org/varnish-team/varnish.git
 Homepage: https://www.varnish-cache.org/
diff -Nru varnish-6.5.1/debian/libvarnishapi-dev.install 
varnish-6.5.2/debian/libvarnishapi-dev.install
--- varnish-6.5.1/debian/libvarnishapi-dev.install  2020-09-29 
23:21:31.0 +0200
+++ varnish-6.5.2/debian/libvarnishapi-dev.install  2021-07-14 
21:46:38.0 +0200
@@ -2,5 +2,5 @@
 usr/share/aclocal
 usr/share/varnish/vsctool.py
 usr/share/varnish/vmodtool.py
-/usr/lib/*/libvarnishapi.so
-/usr/lib/*/pkgconfig/*.pc
+usr/lib/*/libvarnishapi.so
+usr/lib/*/pkgconfig/*.pc
diff -Nru varnish-6.5.1/debian/libvarnishapi2.install 
varnish-6.5.2/debian/libvarnishapi2.install
--- varnish-6.5.1/debian/libvarnishapi2.install 2020-09-29 23:21:31.0 
+0200
+++ varnish-6.5.2/debian/libvarnishapi2.install 2021-07-14 21:46:38.0 
+0200
@@ -1 +1 @@
-/usr/lib/*/lib*.so.*
+usr/lib/*/lib*.so.*
diff -Nru varnish-6.5.1/debian/varnish.install 
varnish-6.5.2/debian/varnish.install
--- varnish-6.5.1/debian/varnish.install2020-09-29 23:21:31.0 
+0200
+++ varnish-6.5.2/debian/varnish.install2021-07-14 21:46:38.0 
+0200
@@ -1,7 +1,7 @@
 etc/varnish/default.vcl
 usr/bin/*
 usr/sbin/*
-/usr/lib/*/varnish
+usr/lib/*/varnish
 usr/share/man
 usr/share/varnish/vcl
 debian/*.service lib/systemd/system/
diff -Nru varnish-6.5.1/doc/changes.html varnish-6.5.2/doc/changes.html
--

Bug#989224: [Pkg-puppet-devel] Bug#989224: puppet: Cron Provider breaks on crontab with certain environment variables (easy DOS for a user)

[Stig Sandbeck Mathisen]

Joerg Jaspert  writes:

> Upstream does not care, see
> https://tickets.puppetlabs.com/browse/PUP-10998

>From the upstream comment, it looks a bit more like "Upstream has not
understood your comment, has yet to see the issue from your perspective
or thought through the security implications of the bug".

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#986031: ogmrip crashes on startup with "malloc(): unsorted double linked list corrupted"

[Stig Sandbeck Mathisen]

Package: ogmrip
Version: 1.0.1-3
Severity: normal

Dear Maintainer,

The "ogmrip" command fails to start after installation.  I installed the
package and typed the "ogmrip" command with no arguments.

When called from the command line, it exits with:

A large number of these:

** (ogmrip:7501): CRITICAL **: 12:28:41.392: ogmrip_settings_install_key: 
assertion 'G_IS_PARAM_SPEC (pspec)' failed

(ogmrip:7501): GLib-GObject-CRITICAL **: 12:28:41.392: 
g_param_spec_internal: assertion 'g_param_spec_is_valid_name (name)' failed

** (ogmrip:7501): CRITICAL **: 12:28:41.392: ogmrip_settings_install_key: 
assertion 'G_IS_PARAM_SPEC (pspec)' failed

(ogmrip:7501): GLib-GObject-CRITICAL **: 12:28:41.392: 
g_param_spec_internal: assertion 'g_param_spec_is_valid_name (name)' failed
  
** (ogmrip:7501): CRITICAL **: 12:28:41.392: ogmrip_settings_install_key: 
assertion 'G_IS_PARAM_SPEC (pspec)' failed

And then finally:

MP4Box - GPAC version 1.0.1-rev1.0.1+dfsg1-3
(c) 2000-2020 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io

Please cite our work in your research:
GPAC Filters: https://doi.org/10.1145/3339825.3394929
GPAC: https://doi.org/10.1145/1291233.1291452

GPAC Configuration: --build=x86_64-linux-gnu --prefix=/usr 
--includedir=${prefix}/include --mandir=${prefix}/share/man 
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr 
--libdir=lib/x86_64-linux-gnu --mandir=${prefix}/share/man --extra-cflags=-Wall 
-fPIC -DPIC -I/usr/include/mozjs -DXP_UNIX -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-O2 -fdebug-prefix-map=/build/gpac-H8Ov47/gpac-1.0.1+dfsg1=. 
-fstack-protector-strong -Wformat -Werror=format-security 
--extra-ldflags=-Wl,-z,relro --enable-joystick --enable-debug --disable-ssl 
--verbose
Features: GPAC_CONFIG_LINUX GPAC_64_BITS GPAC_HAS_IPV6 GPAC_HAS_SOCK_UN 
GPAC_MINIMAL_ODF GPAC_HAS_QJS GPAC_HAS_FAAD GPAC_HAS_MAD GPAC_HAS_LIBA52 
GPAC_HAS_JPEG GPAC_HAS_PNG GPAC_HAS_FFMPEG GPAC_HAS_THEORA GPAC_HAS_VORBIS 
GPAC_HAS_XVID GPAC_HAS_LINUX_DVB  

(ogmrip:7501): GLib-GObject-CRITICAL **: 12:28:41.543: 
g_param_spec_internal: assertion 'g_param_spec_is_valid_name (name)' failed

** (ogmrip:7501): CRITICAL **: 12:28:41.543: ogmrip_settings_install_key: 
assertion 'G_IS_PARAM_SPEC (pspec)' failed

** (ogmrip:7501): WARNING **: 12:28:41.588: Cannot set key 
'container/format': no value
malloc(): unsorted double linked list corrupted


*** 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: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (499, 'stable'), (100, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-5-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages ogmrip depends on:
ii  gconf-service   3.2.6-7
ii  gconf2  3.2.6-7
ii  gpac1.0.1+dfsg1-3
ii  lame3.100-3
ii  libc6   2.31-10
ii  libdbus-glib-1-20.110-6
ii  libdvdread8 6.1.1-2
ii  libenchant-2-2  2.2.15-1
ii  libgconf-2-43.2.6-7
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglade2-0 1:2.6.4-2.3
ii  libglib2.0-02.66.7-2
ii  libgtk2.0-0 2.24.33-1
ii  libnotify4  0.7.9-3
ii  libogg0 1.3.4-0.1
ii  libogmrip1  1.0.1-3
ii  libpango-1.0-0  1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libtheora0  1.1.1+dfsg.1-15
ii  libtiff54.2.0-1
ii  libxml2 2.9.10+dfsg-6.3+b1
ii  mencoder2:1.4+ds1-1
ii  mkvtoolnix  52.0.0-1
ii  mplayer 2:1.4+ds1-1
ii  ogmrip-plugins  1.0.1-3
ii  ogmtools1:1.5-4+b3
ii  tesseract-ocr   4.1.1-2.1
ii  vorbis-tools1.4.0-11+b1

Versions of packages ogmrip recommends:
pn  ogmrip-ac3 
pn  ogmrip-dirac   
ii  ogmrip-doc 1.0.1-3
pn  ogmrip-mpeg
pn  ogmrip-oggz
pn  ogmrip-profiles
pn  ogmrip-video-copy  

ogmrip suggests no packages.

-- no debconf information

Bug#972098: dgit assumes 'master' as main branch

[Stig Sandbeck Mathisen]

Hello,

I've got an observation for this bug.

If ~/.config/git/config sets a default branch for new repositories other
than "master", this bug is triggered.

For instance, if I configure git to create repositories with "main" as
default branch.

# ~/.config/git/config 
[init]
defaultBranch = main

With this configuration, "dgit sbuild" gives me...

,
| $ dgit sbuild
| Format `3.0 (quilt)', need to check/update patch stack
| examining quilt state (multiple patches, linear mode)
| gzip: warning: GZIP environment variable is deprecated; use an alias or script
| dgit: base trees orig=53be9ecc4e6ed6cbcea7 o+d/p=53be9ecc4e6ed6cbcea7
| dgit: quilt differences: src:  == orig == gitignores:  == orig ==
| dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
| starting quiltify (multiple patches, linear mode)
| quiltify linearisation planning successful, executing...
| error: pathspec 'master' did not match any file(s) known to git
| dgit: failed command: git checkout -q master
| 
| dgit: error: subprocess failed with error exit status 1
| $ echo $?
| 255
`

Without this configuration, "dgit sbuild" gives me...

,
| $ dgit sbuild
| Format `3.0 (quilt)', need to check/update patch stack
| examining quilt state (multiple patches, linear mode)
| gzip: warning: GZIP environment variable is deprecated; use an alias or script
| dgit: base trees orig=53be9ecc4e6ed6cbcea7 o+d/p=53be9ecc4e6ed6cbcea7
| dgit: quilt differences: src:  == orig == gitignores:  == orig ==
| dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
| starting quiltify (multiple patches, linear mode)
| quiltify linearisation planning successful, executing...
| nothing quilty to commit, ok.
| dpkg-source: info: using source format '3.0 (quilt)'
| dpkg-source: info: building varnish-modules using existing 
./varnish-modules_0.16.0.orig.tar.gz
| dpkg-source: info: building varnish-modules in 
varnish-modules_0.16.0-3.debian.tar.xz
| dpkg-source: info: building varnish-modules in varnish-modules_0.16.0-3.dsc
| package seems new, not specifying -v
| dpkg-genchanges: info: not including original source code in upload
| sbuild (Debian sbuild) 0.79.1 (22 April 2020) on turbotape.localdomain
| [...]
`

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#971142: varnish-modules: diff for NMU version 0.16.0-2.1

[Stig Sandbeck Mathisen]

Adrian Bunk  writes:

> Control: tags 971142 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for varnish-modules (versioned as 0.16.0-2.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I should
> cancel it.

Hello Adrian,

Thank you for taking the time to do a package upload with a patch for
this bug. Feel free to leave in the delayed queue, or upload immediately
if you have the time.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#971521: varnish-modules: autopkgtest needs update for new version of varnish: Depends on old ABI

[Stig Sandbeck Mathisen]

Paul Gevers  writes:

> So, vanish stopped providing vanishabi-11.0 and vanish-modules needs
> to be fixed, otherwise vanish is not allowed to migrate to testing
> (until vanish-modules is removed from testing). vanish-modules in
> unstable is broken now, we don't want that to happen in testing.

Hello,

The varnish-modules package fails to build due to the build erroring out
on deprecated functions. The varnishabi bump should have happened in
6.5.0 but the 6.5.1 was released soon after to only bump the varnish
version.

Example from the build of varnish-modules against varnish 6.5.1:

,
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/varnish -I../src/foreign -Wall -Werror -Wall 
-Wno-format-y2k -Wstrict-prototypes -Wmissing-prototypes 
-Werror=missing-field-initializers -Wpointer-arith -Wreturn-type 
-Wwrite-strings -Wcast-qual -Wswitch -Wshadow -Wunused-parameter -Wcast-align 
-Wchar-subscripts -Wnested-externs -Wextra -Wno-sign-compare -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c vcc_saintmode_if.c  -fPIC -DPIC -o 
.libs/vcc_saintmode_if.o
| vmod_bodyaccess.c: In function ‘vmod_hash_req_body’:
| vmod_bodyaccess.c:205:2: error: ‘VSB_delete’ is deprecated 
[-Werror=deprecated-declarations]
|   205 |  VSB_delete(vsb);
|   |  ^~
| In file included from /usr/include/varnish/cache/cache_varnishd.h:36,
|  from vmod_bodyaccess.c:37:
| /usr/include/varnish/vsb.h:79:8: note: declared here
|79 | void   VSB_delete(struct vsb *) v_deprecated_;
|   |^~
`

The upstream changelog for varnish 6.5.0 says:

,[ 
https://github.com/varnishcache/varnish-cache/blob/master/doc/changes.rst ]
| * VSB support for dynamic vs. static allocations has been changed:
| 
|   For dynamic allocations use:
| 
| VSB_new_auto() + VSB_destroy()
| 
|   For preexisting buffers use:
| 
| VSB_init() + VSB_fini()
| 
| VSB_new() + VSB_delete() are now deprecated.
`

Varnish-modules uses VSB_new_auto() and VSB_delete() in vmod_bodyaccess
and vmod_saintmode. The long term is obviously for varnish-modules to
use one of the new VSB_ functions for allocations.

I'm not sure what is the best short term fix. Any suggestions? My C
skills are abysmal, so while I could probably get it to build, I'd not
be comfortable with pushing the result...

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#962784: [Pkg-puppet-devel] Bug#962784: facter aborts with free(): invalid pointer

[Stig Sandbeck Mathisen]

Russ Allbery  writes:

> Package: facter
> Version: 3.11.0-4.1
> Severity: grave
>
> facter no longer works at all on amd64.  When invoked, it dies with
> an invalid pointer error:

Looks like the same bug as http://bugs.debian.org/962692 and related to
https://bugs.debian.org/962320

A quick workaround to get facter to run is to create the three
directories:

/etc/facter/facts.d
/etc/puppetlabs/facter/facts.d
/opt/puppetlabs/facter/facts.d


root@bts962784-facter:~# facter
free(): invalid pointer
Aborted

root@bts962784-facter:~# mkdir -p /opt/puppetlabs/facter/facts.d 
/etc/facter/facts.d /etc/puppetlabs/facter/facts.d

root@bts962784-facter:~# facter
disks => {
  nvme0n1 => {
[...]

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#961750: varnish: "service varnish configtest" fails

[Stig Sandbeck Mathisen]

Control: notfound -1 5.0.0-7+deb9u2
Control: found -1 6.1.1-1+deb10u1
Control: found -1 6.4.0-3
Control: severity -1 minor

Johnathon Tinsley  writes:

>* What was the outcome of this action?
>Errors as follows;
>Error: Could not get socket :6081: Address already in use
>(-? gives usage)

This "service varnish configtest" action is run from the initscript,
even though the service was started by systemd. That is potentially
problematic, since /etc/default/varnish is only used by
/etc/init.d/varnish and not by /lib/systemd/system/varnish.service.

"service varnish configtest" runs varnishd with all the options from the
init script configuration in /etc/default/varnish, along with "-C" to
check config. One of the options in /etc/default/varnish is "-a :6081",
and even with "-C" to test and print the config, varnishd attempts to
bind to the port, which won't work when it is already in use by the
running varnish.

This changed between varnish 5 and varnish 6.

Using "-C" with "-a address:port" when a process is listening on that
port worked fine in varnish 5.0.0 in Debian 9 (stretch). Varnish would
check the configuration, and then exit.

Using "-C" with "-a address:port" when a process is listening on that
port does not work in varnish 6.1.1 in Debian 10 (buster) or with
varnish 6.4.0 in Debian 11 (bullseye). Varnish will attempt to bind to
the port, then check configuration and exit.

The init script "configtest" function runs varnishd with all options
defined in /etc/default/varnish to get the path to one or more VCL
files. The "configtest" action will need to use all these flags, adding
a "-C" and removing the arguments used to bind ports.

--
Stig Sandbeck Mathisen
Debian Developer

Bug#956305: varnish: CVE-2019-20637

[Stig Sandbeck Mathisen]

Sylvain Beucler  writes:

> As part of Debian LTS, I'm checking what versions are affected (esp.
> 4.x) and how to fix them (as cache_req_fsm.c in 4.x and 5.x is too
> different to apply the patch).
>
> Did anybody from Debian contact upstream for a PoC or an alternate
> patch yet? Otherwise I'll do it.

Hello,

I'm not aware of anyone who has contacted upstream for a fix or PoC for
4.x or 5.x. Please feel free.

Thank you for the work on Debian LTS. :)

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#952022: ruby-puppet-syntax: FTBFS: ERROR: Test "ruby2.7" failed: LoadError:

[Stig Sandbeck Mathisen]

Daniel Leidert  writes:

> Package: src:ruby-puppet-syntax
> Followup-For: Bug #952022
>
> The formentioned issue can probably be closed by applying this patch:
>
> --- a/lib/rspec-puppet/support.rb
> +++ b/lib/rspec-puppet/support.rb
> @@ -440,7 +440,7 @@
>  end
>  
>  def escape_special_chars(string)
> -  string.gsub!(/\$/, "\\$")
> +  string.gsub(/\$/, "\\$")
>string
>  end
>
> But then there are new errors (see below). I'll stop here and leave
> this to someone more experienced. So if anyone wants to go on, please
> feel free to do so.
>
> Regards, Daniel

I think that change turns the subroutine into a noop.

string.gsub(pattern,replacement) returns the changed string, and does
not change the original object. The output in this instance is
discarded.

string.gsub!(pattern,replacement) modifies the object.

The subroutine then returns the original or changed string.

See https://ruby-doc.org/core-2.7.0/String.html

-- 
Stig Sandbeck Mathisen
Debian Developer


signature.asc
Description: PGP signature

Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Stig Sandbeck Mathisen]

Thomas Goirand  writes:

> Note that I'm doing a git based workflow, packaging upstream tags,
> rather than using pristine-tar. If this bothers anyone, please let me
> know (but please only complain about the workflow if you really have
> the intention to contribute to the packaging, otherwise you're just
> getting on my way to be efficient for no reason).

I'm moving from pristine-tar to git based workflows for my own things,
and getting more and more impressed with dgit, so I won't complain. :)

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Stig Sandbeck Mathisen]

Thomas Goirand  writes:

> Could you list them? I'd be ok to do that work within the team, if
> someone else is working on Puppet itself.

>From the "puppet-agent" repository, at
https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116

puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core
puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core
puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core
puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core
puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core
puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core
puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core
puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core
puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core
puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task

>> From a user point of view, the missing modules mainly shows up when
>> doing rspec module testing.
>
> So, we're talking about Ruby stuff?

The resource types and provides are written in ruby, but distributed as
puppet modules.

When testing puppet modules, and your code use the "cron", "host",
"mount" (from the list above) resource types, they need to be present.

The resource types are present in the puppet 5 source repository, while
in puppet 6, they are maintained as separate puppet modules in their own
repositories, and we would need to add them as packaged dependencies.

--
Stig Sandbeck Mathisen
Debian Developer

Bug#950182: Puppet 5.5 EOL in November 2020

[Stig Sandbeck Mathisen]

Antoine Beaupre  writes:

> ... the upgrade from 5 to 6 doesn't involve much churn in the DSL, so
> it's not as big of a deal as the 3 to 4 or 4 to 5 migrations we had to
> suffer through. The tooling does change, however, so it might be
> tricky on the packaging side (which is why, I am guessing, P6 is not
> yet in Debian).

The biggest difference I've seen between Puppet 5 and 6 is that many
previously built-in resource types have moved from the puppet repository
to external modules. Puppet include those in their own packaging. We
will have to package those as well, and add them as dependencies.

>From a user point of view, the missing modules mainly shows up when
doing rspec module testing. I need to add those modules to the test
fixtures when using Puppet 6.

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#946689: munin-node: cidr_allow directive is sensitive to order when mixing IPv4 and IPv6

[Stig Sandbeck Mathisen]

Raphaël Hertzog  writes:

> After a lot of tweaking, I noticed that all the "cidr_allow" for the
> IPv4 addresses have to be before the first cidr_allow for an IPv6
> address. So just sorting the rules differently like this makes it work
> as expected (at least when connecting over IPv4):

Hello,

Thanks for reporting a bug. :)

The munin-node network listener is managed by Net::Server::Fork
instance, from the libnet-server-perl package, and the cidr_allow
parameters are passed directly to that module.

The bug report mentions you have that package "purged", so I do not want
to guess a version. The oldoldstable release from your bug report has
libnet-server-perl version 2.008-1, and the current is 2.009-1. Are you
using any of these, or a replacement?

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#946423: ITP: ruby-optimist -- Commandline option parser for Ruby that just gets out of your way.

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: wishlist
Owner: Stig Sandbeck Mathisen 

* Package name: ruby-optimist
  Version : 3.0.0
  Upstream Author : William Morgan, Keenan Brock, Jason Frey
* URL : https://www.manageiq.org/optimist/
* License : MIT/Expat
  Programming Lang: Ruby
  Description : Commandline option parser for Ruby that just gets out of 
your way.


Upstream description


Optimist is a commandline option parser for Ruby that just gets out of your
way.  One line of code per option is all you need to write. For that, you get a
nice automatically-generated help page, robust option parsing, and sensible
defaults for everything you don't specify.

Features:

- Dirt-simple usage.
- Sensible defaults. No tweaking necessary, much tweaking possible.
- Support for long options, short options, subcommands, and automatic type
  validation and conversion.
- Automatic help message generation, wrapped to current screen width.


Packaging and maintenance
-

The upstream project name has been changed from trollop to optimist.
(https://github.com/ManageIQ/optimist/issues/92)

ruby-optimist is a dependency for hiera-eyaml >= 3.0.0, and needs to be
available before newer versions of hiera-eyaml can be imported.

ruby-optimist will be maintained under the debian-ruby team umbrella.

Bug#939339: munin-node: systemd hardening hurts the df plugin

[Stig Sandbeck Mathisen]

 writes:

> yes, there were also a few issues raised and a few questions asked via IRC.
> The difference between executing "munin-run" and deploying the plugin in a 
> real
> environment can be an annoying source of confusion.
> But the hardening directives can be of really good use, since they prevent
> misbehaving or insecure plugins from causing damage.
>
> Thus I am not sure, how we should proceed.
>
> At the moment I see the following options:
> A) make these hardening flags configurable via debconf during
>installation/upgrade
>(I would need to investigate, how systemd units can be configured properly)
> B) disable hardening flags and mention their activation in README.Debian
> C) keep the hardening flags and somehow allow "munin-run" to use the same set
>of hardening flags, that the munin-node service uses.
>(or something along these lines - it feels really complicated)
>
> Any other opinions?

The hardening options in systemd have boolean as well as other values
special for each setting. The ProtectHome= systemd unit parameter also
takes "read-only", which _should_ allow monitoring to check filesystem
usage. See man:systemd.exec(5).

Since the job of munin-node is to do filesystem monitoring as default,
and the /home filesystem is often useful to monitor, I'd suggest
"read-only" as a new value for ProtectHome= in munin-node.service. If it
works. :)

(I'm probably responsible for the current value of ProtectHome= in
munin-node.service, to be honest.)

-- 
Stig Sandbeck Mathisen
Trust the Computer, the Computer is your Friend

Bug#939645: Please use YAML.load_stream() instead of YAML.load_documents(), which was removed in ruby 2.5

[Stig Sandbeck Mathisen]

Package: serverspec-runner
Version: 1.2.2-1
Severity: grave
Tags: patch upstream
Justification: renders package unusable

Dear Maintainer,

The package uses the YAML.load_documents() method, which is no longer present
in the Ruby version that ships with Debian.

The method is replaced with YAML.load_stream(), which is compatible.

The error message, when run, is:

/tmp/tmp.o0z1Ka0UgW$ serverspec-runner
Traceback (most recent call last):
7: from /usr/bin/serverspec-runner:61:in `'
6: from /usr/bin/serverspec-runner:61:in `load'
5: from /usr/share/serverspec-runner/Rakefile:14:in `'
4: from /usr/lib/ruby/vendor_ruby/rake/dsl_definition.rb:141:in 
`namespace'
3: from /usr/lib/ruby/vendor_ruby/rake/task_manager.rb:224:in 
`in_namespace'
2: from /usr/share/serverspec-runner/Rakefile:167:in `block in '
1: from /usr/share/serverspec-runner/Rakefile:167:in `open'
/usr/share/serverspec-runner/Rakefile:168:in `block (2 levels) in ': undefined method `load_documents' for Psych:Module (NoMethodError)
Did you mean?  load_stream


A patch is available in the upstream repo, at
https://github.com/hiracy/serverspec-runner/pull/47/commits/c459787defe1b08bbe46a5acf0ea07039fe44f61
this is also included in upstream version 1.3.8

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/24 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages serverspec-runner depends on:
ii  ruby 1:2.5.1
ii  ruby-net-ssh 1:5.1.0-1
ii  ruby-serverspec  2.41.3-3

serverspec-runner recommends no packages.

serverspec-runner suggests no packages.

-- no debconf information

Bug#934246: munin-node doesn't start any more after upgrade to buster

[Stig Sandbeck Mathisen]

Paolo Benvenuto  writes:

> Il giorno dom 11 ago 2019 alle ore 18:51  ha scritto:
>
>>
>> At the moment I suspect, that /var/log/munin is somehow symlinked on your
>> system into /tmp or /run. But this is just a very wild guess.
>>
>> actually /var/log is a symlink to /home/log
>
> Would it be the reason of the problem?

The ProtectHome= setting will make /home look empty (or readonly) for a
service. The symlink of /var/log to /home/log will therefore point to a
nonexistant location for that service by default.

Look at man:systemd.exec(5) for more information about that setting.


-- 
Stig Sandbeck Mathisen

Bug#902948: drop upstart-mode.el?

[Stig Sandbeck Mathisen]

Nicholas D Steeves  writes:

> Stig, as the author of this mode are you interested in maintaining it
> as an upstream?  The Debian Emacsen team is in the process of
> transitioning src:emacs-goodies-el from a native package of bundled
> lisp files to a dummy package that depends on a series of elpafied
> non-native packages with independent upstreams.

The upstream would be in my "elisp" repo at
https://github.com/ssm/elisp/blob/master/upstart-mode.el

If you forsee any theoretical demand for that emacs mode, I'd be happy
to make a separate repo for it, and try to elpafy (what a verb!) it
properly.

-- 
Stig Sandbeck Mathisen
https://localhost/ <- someone's somewhat secret secure self service site

Bug#887395: vim-puppet: package vim plugin from rodjek

[Stig Sandbeck Mathisen]

> On 15 Jan 2018, at 21:36, Gabriel Filion  wrote:
> 
> Package: vim-puppet
> Version: 3.8.5-2
> Severity: normal
> 
> Hello,
> 
> The vim-puppet package has no package above debian jessie. I can
> understand why that happened: the puppetlabs vim plugin has not been
> maintained for so long!
> 
> There is however an alternative that's available:
> 
> https://github.com/rodjek/vim-puppet

That plugin works well, but I think it should have a free software license 
before it can be included in Debian.

Stig

Bug#881808: [Pkg-varnish-devel] Bug#881808: varnish: CVE-2017-8807: Data leak - '-sfile' Stevedore transient objects

[Stig Sandbeck Mathisen]

Salvatore Bonaccorso <car...@debian.org> writes:

> Any news regarding the upload for unstable?

I'm building and testing it now, and it should hit unstable shortly.

-- 
Stig Sandbeck Mathisen

Bug#865488: [Packaging] Bug#865488: munin-node: systemd unit needs "After=network.target"

[Stig Sandbeck Mathisen]

Tobias Brink <tobias.br...@gmail.com> writes:

> Package: munin-node
> Version: 2.0.33-1
> Severity: important
> Tags: patch
>
> After upgrading an LXC container to stretch, the "munin-node.service" systemd
> unit does no longer start at boot, but works fine if started manually later.
> The fix for me was to add
>
> [Unit]
> After=network.target
>
> to the munin-node.service file. I assume the reason is that the executable
> tries to bind to an address which is not available, yet (I have a statement
> like "host 192.168.42.42" in /etc/munin/munin-node.conf). Waiting for the
> network fixes this.

After looking at
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, I
suspect that network-online.target might be a better choice than
network.target.  The page says about network-online.target:

  "It's [sic] primary purpose is to actively delay activation of
  services until the network is set up."

...so I'll go with that.

Thanks for reporting the bug.

-- 
Stig Sandbeck Mathisen

Bug#863424: jemalloc: Please build with -DLG_QUANTUM=4 on sh3

[Stig Sandbeck Mathisen]

John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> writes:

> We're currently in the process of bootstrapping Debian on sh3 which is
> an architecture similar to sh4 which is already in Debian Ports. sh3
> is an older architecture which is currently being redeveloped as the
> open source architecture J-Core, sh3 being the j3 CPU [1].
>
> jemalloc is one of the few packages which still lack support for sh3
> in Debian. Since adding support only involves setting the correct size
> for LG_QUANTUM, supprt can be trivially added with the attached
> patch. I will shortly send a pull request upstream to add the
> definition there for sh3 as well.
>
> Thanks for consideration.

Thank you for the patch, it looks simple enough. :)

I'll import it after the freeze is over.

-- 
Stig Sandbeck Mathisen
https://fnord.no/


signature.asc
Description: PGP signature

Bug#837788: [Packaging] Bug#837788: Bug#837788: munin: systemd control scripts are missing

[Stig Sandbeck Mathisen]

Simon McVittie <s...@debian.org> writes:

> Well, you're the maintainer; if you want munin to not mask the systemd
> unit generated from its init script, you don't have to install that
> symlink.  It seems to have been done deliberately:
> https://sources.debian.net/src/munin/2.0.33-1/debian/munin.links/ Do
> you know why? I couldn't see anything relevant-looking in d/changelog.
> I'd normally check the git history, but alioth is down at the moment.

Hello,

Munin needs /run/munin created with the correct permissions.

When using sysv init, the /etc/init.d/munin script does that, and exits.

When using systemd, this is handled with debian/munin-common.tmpfile
which installs into /usr/lib/tmpfiles.d/, and and the munin init script
is masked to prevent this from running twice.

Commit c8d748232a230b695e4e938c36a4d216901c16e0 made this change in the
munin packaging repo, the first debian release containing this was
2.0.16-3, in 2013.

In munin 3, still under development, the munin service start an instance
of rrdcached, while for munin 2, using rrdcached was left up to the
maintainer to scale munin beyond a handful of hosts.

-- 
Stig Sandbeck Mathisen
https://fnord.no/

Bug#856684: unblock: varnish/5.0.0-7

[Stig Sandbeck Mathisen]

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

Please unblock package varnish

The varnish package includes a script to reload the VCL set in
/etc/default/varnish, which the systemd unit does not use.  Running
"systemctl reload varnish" might not work at all, or load the wrong
configuration.  This version fixes this problem by dropping the
"reload" action from the systemd unit.

diff -Nru varnish-5.0.0/debian/changelog varnish-5.0.0/debian/changelog
--- varnish-5.0.0/debian/changelog  2016-12-20 22:04:01.0 +0100
+++ varnish-5.0.0/debian/changelog  2017-03-02 18:16:05.0 +0100
@@ -1,3 +1,9 @@
+varnish (5.0.0-7) unstable; urgency=medium
+
+  * Remove reload from varnish.service (Closes: #749272)
+
+ -- Stig Sandbeck Mathisen <s...@debian.org>  Thu, 02 Mar 2017 18:16:05 +0100
+
 varnish (5.0.0-6) unstable; urgency=medium
 
   * Update reload-vcl for varnish 5.x
diff -Nru varnish-5.0.0/debian/tests/spec/varnish/use_spec.rb 
varnish-5.0.0/debian/tests/spec/varnish/use_spec.rb
--- varnish-5.0.0/debian/tests/spec/varnish/use_spec.rb 2016-12-20 
22:04:01.0 +0100
+++ varnish-5.0.0/debian/tests/spec/varnish/use_spec.rb 2017-03-02 
18:16:05.0 +0100
@@ -23,7 +23,7 @@
 end
 
 describe command('systemctl reload varnish') do
-  its(:exit_status) { should eq 0 }
-  its(:stderr) { should eq '' }
+  its(:exit_status) { should eq 3 }
+  its(:stderr) { is_expected.to include('Job type reload is not applicable for 
unit varnish.service.') }
   its(:stdout) { should eq('') }
 end
diff -Nru varnish-5.0.0/debian/varnish.service 
varnish-5.0.0/debian/varnish.service
--- varnish-5.0.0/debian/varnish.service2016-12-20 22:04:01.0 
+0100
+++ varnish-5.0.0/debian/varnish.service2017-03-02 18:16:05.0 
+0100
@@ -7,7 +7,6 @@
 LimitNOFILE=131072
 LimitMEMLOCK=82000
 ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :6081 -T localhost:6082 
-f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
-ExecReload=/usr/share/varnish/reload-vcl
 ProtectSystem=full
 ProtectHome=true
 PrivateTmp=true

unblock varnish/5.0.0-7

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

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

Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd

[Stig Sandbeck Mathisen]

Stig Sandbeck Mathisen <s...@debian.org> writes:

> Michael Stapelberg <stapelb...@debian.org> writes:
>
>> Yet another alternative might be (and it pains me to say that, but
>> maybe it’s required to not break people’s setups) to have the service
>> file start a wrapper shell script which evaluates
>> /etc/default/varnish before starting varnish.
>
> That could actually be done when upgrading the package from whatever
> is in stable currently.
>
> For instance: If upgrading from 4.0.2-1, add a
> /etc/systemd/system/varnish.service.d/upgrade.conf with such a shell
> wrapper for people upgrading from the version in current stable.

Hm, after bootstrapping a stable debian installation, it looks like the
varnish systemd unit on stable didn't use an environment file at all.

It did, however, have ExecReload= set, using the reload-vcl script which
I'm not very content with.

Therefore, I think this issue can be resolved with just removing
"ExecReload=/usr/share/varnish/reload-vcl" from the systemd unit again,
and not have a "reload" action at all.

This has also been discussed previously at
https://github.com/varnishcache/pkg-varnish-cache/issues/30 for the
upstream packaging.

-- 
Stig Sandbeck Mathisen
https://fnord.no/

Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd

[Stig Sandbeck Mathisen]

Michael Stapelberg <stapelb...@debian.org> writes:

> Yet another alternative might be (and it pains me to say that, but
> maybe it’s required to not break people’s setups) to have the service
> file start a wrapper shell script which evaluates /etc/default/varnish
> before starting varnish.

That could actually be done when upgrading the package from whatever is
in stable currently.

For instance: If upgrading from 4.0.2-1, add a
/etc/systemd/system/varnish.service.d/upgrade.conf with such a shell
wrapper for people upgrading from the version in current stable.

Oh, and "ick!", but thanks. :)

I'd really like to avoid keeping /etc/default/* around for new installs.

-- 
Stig Sandbeck Mathisen
https://fnord.no/

Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd

[Stig Sandbeck Mathisen]

Michael Stapelberg <stapelb...@debian.org> writes:

> Hi,
>
> Gregory Colpart <r...@evolix.fr> writes:
>> tags 749272 - wontfix
>> severity 749272 serious
>> retitle 749272 varnish doesn't source /etc/default/varnish when started but 
>> uses it when reloaded
>
> This bug’s severity now results in varnish and, transitively,
> freeradius being removed from testing, so it warrants timely
> action. Whether that’s a downgrade or a fix is up to the package
> maintainers (ssm?).
>
> FWIW, I think the request to load environment variable files is
> reasonable. It’s not idiomatic for systemd, but it is a widely used
> technique in Debian and will smoothen the transition for our users.

A problem with /etc/default/varnish is that it is a shell script
fragment, with examples using interpolation, and not just key=value
statements.  If someone has used "Alternative 3" for Varnish from that
file, the "reload" script will still fail when using systemd.

I think a fix for this issue may be:

* remove the reload action from systemd.

* Possibly patch the reload script to ensure it does not attempt to run
  when using systemd, by checking for the presence of
  "/run/systemd/system" and exit with a message if it is present.

I wrote that reload-vcl script long ago, and it has developed other
problems as varnish has developed, and probably needs to be rewritten
from scratch.

It needs to synchronize its varnishd command line option parser with
what varnishd may possibly use, and that was last done a long time ago.

"What should the varnish service actually reload when told to reload"
has multiple options.  The VCL file used when starting up?  The compiled
VCL from starting up? The VCL file last loaded, etc.

-- 
Stig Sandbeck Mathisen
https://fnord.no/

Bug#844414: [Pkg-puppet-devel] Bug#844414: puppet: Remounts file systems for no reason at every run

[Stig Sandbeck Mathisen]

Control: tags -1 +confirmed pending fixed-upstream

Frederik Himpe <fhi...@vub.ac.be> writes:

> This bug is fixed upstream with this patch:
>
> https://github.com/puppetlabs/puppet/commit/ac6709f2e76cbb68639bb626b6481b743cd9b56b.patch
>
> Can it be applied to the Debian package?
>
> Thanks,

That commit is included in puppet 4.8.1, which is tagged in the upstream
git repo.  As soon as Puppet has finished the release, it will be
uploaded to Debian.

-- 
Stig Sandbeck Mathisen
https://fnord.no/

Bug#827867: puppet-agent package is not really necessary and conflicts with the upstream package by the same name

[Stig Sandbeck Mathisen]

Michael Moll <kved...@kvedulv.de> writes:

> What's the status of this bug? A quick fix would be to rename the
> puppet-agent package to puppet-client or similar. As the stretch
> release is nearing and PuppetLabs is pushing users to move to their
> Puppet 4 packages, something should be done. ;)

The package is still to be removed.  I'm a tad bit short of free time to
take care of it, so help would be welcome, if anyone else has time to do
this bug.

-- 
Stig Sandbeck Mathisen
https://fnord.no/

Bug#835206: [Packaging] Bug#835206: munin: diff for NMU version 2.0.25-2.1

[Stig Sandbeck Mathisen]

Much appreciated, thank you. :)

-- 
Stig Sandbeck Mathisen
https://fnord.no/


signature.asc
Description: PGP signature

Bug#829552: Acknowledgement (Please drop unnecessary sysv-rc dependency)

[Stig Sandbeck Mathisen]

Martin Pitt <mp...@debian.org> writes:

> Control: tag -1 pending
>
> Trivial, but attaching debdiff for good measure.

Thanks.  That's an _old_ dependency, which clearly should be removed. :)

-- 
Stig Sandbeck Mathisen

Bug#827867: [Pkg-puppet-devel] Bug#827867: puppet-agent package is not really necessary and conflicts with the upstream package by the same name

[Stig Sandbeck Mathisen]

Ryan Whitehurst <r...@puppet.com> writes:

> The package "puppet-agent" was recently added to Debian Testing
> ("Stretch"). All it does is add an init script and systemd unit file
> for running puppet as a service, something which would normally be
> included in the main package, not require a separate package. There
> isn't really any benefit to having a separate package for this.

Hi, and thanks for reporting a bug.

There has been separate packages in Debian just for running the puppet
agent and master services since puppet 0.25.3.  I've considered dropping
them[0], but left them in, mostly due to "that's the way it's been for a
long time".

Previously, the "puppet" and "puppetmaster" packages would contain only
the init script, upstart job and systemd service.  These were renamed to
"puppet-agent" and "puppet-master".  The puppet software itself was
contained in the "puppet-common" and "puppetmaster-common"
packages. These was merged into the "puppet" package.

Since this renaming clearly creates problems for Puppet (the software)
provided by Puppet (the company), I'll move the puppet agent and master
services into puppet (the Debian package), but I think I'll have to
disable them by default.

There is also a puppet-master-passenger package, which should be
separate due to its dependencies on apache httpd and passenger.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798636#20
-- 
Stig Sandbeck Mathisen <s...@debian.org>

Bug#673515: ITP: puppetdb -- Puppet data warehouse

[Stig Sandbeck Mathisen]

intrigeri <intrig...@debian.org> writes:

> Let's assume one needs exported resources, and thus PuppetDB, but they
> want to confine PuppetDB as much as possible, in order to avoid the
> need to trust 3rd-party (upstream) APT repositories on the
> puppetmaster. So, say PuppetDB is installed from upstream on a
> dedicated system. Then, if I got it right, the only bit missing in
> Debian, for the puppetmaster to be able to connect to PuppetDB without
> using any 3rd-party packages, is puppetdb-termini. Correct so far?

That is correct.  The puppetdb-termini package contains what the puppet
master needs to connect to a puppetdb.

> puppetdb-termini has no dependencies except puppet-agent. It just
> ships 16 .rb files, that live in the upstream Puppet Git repository,
> and are distributed in PuppetDB upstream tarballs.
>
> So it seems that the only realistic way to go, in order for Debian
> Stretch to support the use case I've described, without having to
> tackle the packaging of PuppetDB itself, would be to package
> puppetdb-termini. Would you, or anyone else, be up to it?

Yes.

In theory (and documentation) the puppetdb-termini package must match
the version of the puppetdb you are connecting to.  In practice, the
puppetdb-termini is updated less frequently than puppetdb, and it may
work without updating, but without any promises.

Debian only accepts one version of a package at a time.  This may
prevent you from upgrading puppetdb to a version not supported by the
puppetdb-termini in Debian, and when the puppetdb-termini package in
Debian is updated, you may have to update your PuppetDB installation to
follow.

Apart from that, it does not look very hard at all to build only the
puppetdb-termini from the puppetdb source.

-- 
Stig Sandbeck Mathisen <s...@debian.org>

Bug#673515: ITP: puppetdb -- Puppet data warehouse

[Stig Sandbeck Mathisen]

intrigeri <intrig...@debian.org> writes:

> Are there currently any plans to package PuppetDB for Debian?

I'm not aware of any.

I spent a few days on it in 2012, but the necessary free time investment
to learn all the required tools and package all the requirements was too
big for me then, and still is.

> Any expected specific difficulty that would be worth sharing here?

A packaging effort will require a familiarity with Leiningen, Maven and
Clojure in particular, and Java application packaging in general.  I'm
not familiar with either of these.

Leiningen is no longer packaged in Debian, it is only present in
"oldstable".

Puppet's Cloujure projects depend on "trapperkeeper"[0], also referred
to as "tk", and are built with a buildsystem called "ezbake"[1] which is
a Leiningen plugin.

PuppetDB also has a lot of other dependencies[2] which need to be mapped
to existing Debian packages, or packaged.

> Rationale for my question: the infrastructure behind Tails [0] relies
> on exported resources, and we can't allow ourselves to rely on
> third-party packages.

When you really need exported resources, there's nothing like it.

One can in _some_ cases use Hiera to provide the necessary data to
puppet for creating resources across many hosts.  This does, however,
require you to generate that data beforehand.

> (BTW: thanks for packaging & uploading Puppet 4!)

You're welcome. :)

[0] https://github.com/puppetlabs/trapperkeeper

[1] https://github.com/puppetlabs/ezbake

[2] look for ":dependencies" in
https://github.com/puppetlabs/puppetdb/blob/master/project.clj

-- 
Stig Sandbeck Mathisen

Bug#825719: Puppet cleans /var/lib/puppet while upgrade

[Stig Sandbeck Mathisen]

Control: tags -1 moreinfo

Klaus Ethgen <kl...@ethgen.de> writes:

> Upgrade to new puppet release removes all content in /var/lib/puppet,
> including all certificates.

I'm not able to reproduce this with:

* An upgrade of the package puppet in an instance running Debian testing
  (puppet 3.8.5-2) to puppet in Debian unstable (puppet 4.0.5-3).

* A dist-upgrade with "puppetmaster" installed, from jessie to unstable.

…so I need more information.

If you could provide it, the following would be helpful for me to
reproduce it:

* "grep puppet /var/log/dpkg.log" (so I can see which puppet packages
  was installed and removed)

* The log lines in /var/log/apt/term.log from the update session. (so I
  can see what apt did)

* The settings matching "dir" in /etc/puppet/puppet.conf, and if you
  have it, /etc/puppet/puppet.conf.* ()

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#825719: [Pkg-puppet-devel] Bug#825719: Puppet cleans /var/lib/puppet while upgrade

[Stig Sandbeck Mathisen]

Found it.

After an upgrade, "puppet-common" is left instate "removed".

When that package is purged (manually or automatically), /var/lib/puppet
is removed.

When looking at debian/puppet-common.postrm from puppet 3.8, it contains
a "rm -rf /var/lib/puppet" when called with "purge".

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#798636: Puppet 4 is now in experimental

[Stig Sandbeck Mathisen]

I've just uploaded puppet 4.5.0-1 to Debian experimental.


There is one problem with puppet 4 and packaged puppet modules.  If I
install puppet 4, packaged puppet modules (puppet-module-*) are
deinstalled.

This is caused by a dependency on a minimum version of puppet-common, or
a dependency on "puppet-module-puppetlabs-stdlib" which has such a
dependency.

The "puppet" package has "Provides: puppet-common", but this does not
satisfy a versioned dependency.

Some packaged puppet modules use "Depends: puppet-common (>= 3)", and
installing puppet 4 will cause these packages to be uninstalled.

These need to be updated to "Depends: puppet (>= 4) | puppet-common (>=
3)" before puppet 4 should be uploaded to Debian unstable:

  puppet-module-asciiduck-sssd (>= 3)
  puppet-module-puppetlabs-apt (>= 3)
  puppet-module-puppetlabs-concat (>= 3)
  puppet-module-puppetlabs-inifile (>= 3)
  puppet-module-puppetlabs-ntp (>= 3)
  puppet-module-puppetlabs-postgresql (>= 3)
  puppet-module-puppetlabs-stdlib (>= 3)
  puppet-module-saz-memcached (>= 3)

I'll upload new versions of these shortly, with the dependencies fixed.

The other packaged puppet modules use "Depends: puppet-common". These
should be updated to "Depends: puppet (>= 4) | puppet-common" at some
point.

-- 
Stig Sandbeck Mathisen

Bug#822873: ITP: puppet-module-vswitch -- provides puppet things for vSwitches

[Stig Sandbeck Mathisen]

Please consider using the module's qualified name, "openstack-vswitch"
in the package name.

That way we can have a hypothetical "foo-vswitch" module installed
alongside it, without wondering which "vswitch" module is which.

This name convention is used for all the other puppet modules, at least
the ones handled by the puppet packaging team under the puppet-module-*
package namespace.

-- 
Stig Sandbeck Mathisen

Bug#822978: ITP: puppet-module-puppetlabs-concat -- construct files from multiple ordered fragments of text

[Stig Sandbeck Mathisen]

This module is already packaged.

$ rmadison puppet-module-puppetlabs-concat
puppet-module-puppetlabs-concat | 1.1.1-1   | stable  | source, all
puppet-module-puppetlabs-concat | 1.1.1-1   | stable-kfreebsd | source, all
puppet-module-puppetlabs-concat | 2.1.0-1   | testing | source, all
puppet-module-puppetlabs-concat | 2.1.0-1   | unstable| source, all

-- 
Stig Sandbeck Mathisen

Bug#798636:

[Stig Sandbeck Mathisen]

Michael Stahnke <stah...@puppet.com> writes:

> FWIW, You can run puppet4 under MRI/passenger as the server. I
> wouldn't recommend it, but it is possible.

It seems to be working.

> As for the filesystem pathing, yes the projects have been updated to
> our newer standard paths, but in most cases that a pretty simple patch
> (or will fall back) to the layout debian may expect.

The "where in the world is puppet.conf" case does not seem to be one of
these.

The provided install.rb does take a --configdir argument, among others,
but those do not seem to affect the paths used by the installed
software, only where the software is actually installed.


A small status update on the puppet 4 packaging.

I've got puppet 4 packaged, and it works if I use
"/etc/puppetlabs/puppet/puppet.conf" as the configuration file path.
Some patching is required to use /etc/puppet/puppet.conf.  Instances of
/etc/puppetlabs/ ~/.puppetlabs and /opt/puppetlabs are hardcoded in
places instead of using a configuration method.


After thinking about it for a bit, I've taken the liberty of adjusting
the package names, so they do not reflect the state of puppet version
0.24, plus all the functionality added after that.

New package names, are:

* puppet (all the software.)

* puppet-agent (package containing just the init script and systemd unit
  for the puppet agent.  This package is possibly redundant.)

* puppet-master (init script and systemd unit for starting a single
  master.  This package is possibly redundant.)

* puppet-master-passenger (This package sets depends on apache httpd,
  and configures a puppet master using mod_passenger.  Due to the
  dependency on apache httpd, I'd like to keep this as a separate
  package)

The activerecord storedconfigs patch which was contributed for puppet
3.x has been removed, there does no longer seem to be any code for it to
patch.  If someone still wants to contribute and maintain it, it would
make sense as a separate package containing a terminus or extension for
puppet.  I've no idea if this would _actually_ work.

The editor support packages, puppet-el and vim-puppet, will no longer
use the "puppet" upstream repository and source package, they now have
separate repositories and multiple implementations.

PuppetDB and Puppet Server need a lot of infrastructure and dependencies
packaged.  Leiningen (clojure build system) was recently removed from
Debian, but someone is working on reintroducing it again.
(https://bugs.debian.org/819811)

-- 
Stig Sandbeck Mathisen <s...@debian.org>

Bug#816846: ITP: varnish-modules -- Varnish module collection

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: wishlist
Owner: Stig Sandbeck Mathisen <s...@debian.org>

* Package name: varnish-modules
  Version : 0.9.0
  Upstream Author : Varnish Software AS
* URL : https://github.com/varnish/varnish-modules
* License : BSD-2-clause
  Programming Lang: C
  Description : Varnish module collection

This is a collection of modules ("vmods") extending Varnish VCL used for
describing HTTP request/response policies with additional capabilities.
Included:

* Simpler handling of HTTP cookies
* Variable support
* Request and bandwidth throttling
* Modify and change complex HTTP headers
* 3.0-style saint mode
* Advanced cache invalidations, and more.

This collection contains the following vmods: cookie, vsthrottle, header,
saintmode, softpurge, tcp, var, xkey

The package will be maintained by the pkg-varnish team.

Bug#814084: [DRE-maint] Bug#814084: Please use update-alternatives to provide /usr/bin/librarian-puppet

[Stig Sandbeck Mathisen]

Thomas Goirand <z...@debian.org> writes:

> Please consider using update-alternatives to provide
> /usr/bin/librarian-puppet, so that one could install at the same time
> librarian-puppet and librarian-puppet-simple.

Added and uploaded.  I used the "10" priority.  Feel free to pick an
appropriate priority to override by default or not.

> P.S: I need librarian-puppet-simple for packaging OpenStack Fuel, and
> to be more exact, fuel-library, which is a collection of Puppet stuff
> for deploying OpenStack.

…aaand thanks for packaging OpenStack. :)

Cheers,
-- 
Stig Sandbeck Mathisen

Bug#812989: don't assume SSE2 instructions on i386

[Stig Sandbeck Mathisen]

Control: tags -1 + confirmed

Matthias Klose <d...@debian.org> writes:

> the configury assumes the availability of SSE2 instructions on i386
> when using a triplet or cpu starting with i686, which it shouldn't.
>
> patch at
> http://launchpadlibrarian.net/235541334/jemalloc_3.6.0-9_3.6.0-9ubuntu1.diff.gz

Hello,

Thanks for reporting a bug, and thanks for the patch.

This looks a bit like the issue discussed at
https://github.com/jemalloc/jemalloc/issues/52 in the upstream bug
tracker.

That issue mentions using a few options for ./configure,
"--build=i386-pc-linux-gnu" and "--host=i386-pc-linux-gnu".  Do you
think using that in debian/rules would also solve the issue?

-- 
Stig Sandbeck Mathisen

Bug#810481: [Pkg-puppet-devel] Bug#810481: puppet-module-puppetlabs-ntp: none

[Stig Sandbeck Mathisen]

Control: tags -1 + confirmed upstream fixed-upstream

Bernd Schatz <bernd.sch...@gmx.net> writes:

> Using the option logfile in the class ntp leads to a syntax error
> in the ntp.conf files of the clients.(Jessie 8.2).

This is fixed in commit 3a4342e8a7f98fdd5cbefbb92e47a56689e56b09 in the
upstream repository, and included in version 4.1.2.

An upload of this new version to Debian should fix this bug. Thanks for
reporting it.

-- 
Stig Sandbeck Mathisen

Bug#810484: [Pkg-puppet-devel] Bug#810484: puppet agent: ruby segfault during applying catalog

[Stig Sandbeck Mathisen]

Felix Hagemann <felix.hagem...@gmail.com> writes:

> Segmentation fault at 0x01
> ruby 2.2.3p173 (2015-08-18) [x86_64-linux-gnu]

According to
https://docs.puppetlabs.com/guides/platforms.html#ruby-versions, puppet
3.x is incompatible with ruby 2.2.

Please see if you can reproduce the issue with one of the other ruby
versions.

-- 
Stig Sandbeck Mathisen

Bug#808174: jemalloc FTCBFS for {hur,kfreebs}d-i386 m68k sparc{,64}: mistakes build architecture for host architecture

[Stig Sandbeck Mathisen]

Helmut Grohne <hel...@subdivi.de> writes:

> The intention behind all of these checks is to match the architecture
> that is being built for, which is called host architecture and not
> build architecture.

So the builder architecture is is DEB_HOST_, and while the target host
architecture is is DEB_BUILD_, or the other way around?  I obviously got
them mixed around in my head. :)

> The fix is simple:
>
> sed -i s/DEB_BUILD_/DEB_HOST_/g debian/rules

Thanks.  Upload coming soon.

-- 
Stig Sandbeck Mathisen <s...@debian.org>

Bug#807548: jemalloc: FTBFS on almost all architectures due to testsuite failure

[Stig Sandbeck Mathisen]

John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> writes:

> Since jemalloc is a build dependency of nghttp2 which is a build
> dependency of curl which - in turn - is a build dependency of a huge
> number of packages, including apt, things could become really ugly for
> the architectures affected.
>
> Thus, please fix jemalloc as soon as possible and also forward it your
> fixes upstream.

Hello, and thanks for the bug report.

The failing test seems to be for the profiling functionality enabled in
the last Debian revision.  (The failing test is test/unit/prof_accum,
somewhere in the middle) The commit which enables profiling is
ee6613abf814099e82e050f24a378bd38ce8fd4d in the packaging repo.

I guess the prudent thing to do would be to revert that commit, reopen
the wishlist bug in the Debian BTS, re-upload the package, and figure
out the cause in due time.

-- 
Stig Sandbeck Mathisen

Bug#799222: ITP: hitch -- scalable TLS proxy

[Stig Sandbeck Mathisen]

Vincent Bernat <ber...@debian.org> writes:

> Do you want to provide some upgrade path for stud users?  At some
> point, we'll have to remove stud since it is unmaintained upstream.

After checking again today, I see that "stud" is present in "wheezy"
(oldstable), but not in later Debian releases.  I missed that last
night.

I would like to be able to provide some kind of upgrade path. The
key/cert handling, options and invocation should be roughly similar.

On the other hand, "hitch" has new defaults, and new configuration and
command line options for its functionality.  It is not a drop-in
replacement.

The "stud" package has low enough popcon rank that I suspect a
/usr/share/doc/hitch/README.migrating-from-stud would suffice.

They can be installed in parallel, working on different ports towards
the same backend, using the same certificates, enabling a controlled
switchover between the daemons.

-- 
Stig Sandbeck Mathisen <s...@debian.org>


signature.asc
Description: PGP signature

Bug#799222: ITP: hitch -- scalable TLS proxy

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: wishlist
Owner: Stig Sandbeck Mathisen <s...@debian.org>

* Package name: hitch
  Version : 1.0.0~beta5
  Upstream Author : Varnish Software AB (and others)
* URL : https://hitch-tls.org/
* License : BSD
  Programming Lang: C
  Description : scalable TLS proxy

 hitch is a network proxy that terminates TLS/SSL connections and
 forwards the unencrypted traffic to some backend. It's designed to
 handle 10s of thousands of connections efficiently on multicore
 machines.
 .
 Features
  * TLS1.0, TLS1.1 and TLS1.2 support
  * SNI, with and without wildcard certificates.
  * Support for HAproxy's PROXY protocol.

hitch is a fork of stud (https://github.com/bumptech/stud) which has not
been packaged in Debian.

hitch is used at my workplace for TLS termination of online newspapers,
using Varnish as a backend.

Hitch will be maintained in the collab-maint group, or in the
pkg-varnish group. Extra hands for maintenance would be welcome.

Bug#798636: [Pkg-puppet-devel] Bug#798636: puppet: Plans to switch to puppet 4 (new upstream release)

[Stig Sandbeck Mathisen]

Raphaël Hertzog <hert...@debian.org> writes:

> what are your plans to switch to puppet 4?

They can be nicely summarized as UNDEF.

> I see that the watch file currently tracks version 3 but upstream
> makes regular releases of version 4.
>
> Should version 4 be packaged separately or do you intend to switch to
> it?

The puppet 3.8 packages contain the puppet 4 parser, so setting
"parser=future" in puppet.conf globally, or per-environment in
environment.conf enables the use of the very nice improvements in the
puppet 4 language.

I think the current puppet packaging could be used to provide a puppet 4
agent.  I've no idea if running a puppet master without using
"puppet-server" in version 4 actually works.  Puppet Labs is providing a
separate daemon for that, which uses many bits from "puppet".

A package rename would be nice, but not necessary. The current package
names reflect how puppet looked and worked at around puppet version 0.24
and before, which feels increasingly out of touch.

Having compatibility with the upstream packages would be a plus.  It
won't be the same package, as Puppet Labs is providing a "all in one"
package, which includes an embedded ruby, and all libraries used.

> I do not know anything about the changes between the two versions but
> I have customers who asked me about the status of puppet 4 in Debian
> and since I think that this will interest more people I opted to open
> a bug to keep track of this discussion.

The puppet server and puppetdb are written in Clojure, runs inside a
JVM, are built with Leiningen and Maven.  There are likely a few
(handfuls of) non-packaged dependencies for both of those.  To package
them, someone with experience with java and java packaging would be
helpful to have on the team.

Puppet Labs have opted to use /etc/puppetlabs/* as root for all related
configuration in puppet 4 and on. I've no idea yet if that makes sense
for Debian.  It would complicate the upgrading process, but greatly
simplify documentation and training.

-- 
Stig Sandbeck Mathisen <s...@debian.org>

Bug#790009: [Packaging] Bug#790009: munin-node gets killed after timeout, wrong pidfile location

[Stig Sandbeck Mathisen]

Control: tags + confirmed pending

Frank Hommes frank.hom...@hhu.de writes:

 In /lib/systemd/system/munin-node.service the variable pidfile is set to:
 PIDFile=/run/munin/munin-node.pid

 where in
 /etc/init.d/munin-node it's
 PIDFILE=/var/run/munin/munin-node.pid

 and in /etc/munin/munin-node.conf it's also
 pid_file /var/run/munin/munin-node.pid

 When starting munin-node with systemctl start munin-node.service it
 gets a timeout because there is no pid at /run/munin/munin-node.pid
 and kills the process.

 If you're lucky, munin-node will send data to munin-server before the
 timeout so you still get some graphs with data but sometimes it
 doesn't work so your graph gets white spaces in between.

 Solution is to unify the location of pidfile.

Since wheezy, /var/run should be a symlink to /run
(https://wiki.debian.org/ReleaseGoals/RunDirectory).

Cleanup of packages, and changing configuration files, takes a bit more
time, obviously.

-- 
Stig Sandbeck Mathisen

Bug#773802: [Packaging] Bug#773802: new upstream (2.1.10)

[Stig Sandbeck Mathisen]

Daniel Baumann daniel.baum...@progress-technologies.net writes:

 retitle 773802 new upstream (2.1.12)
 thanks

 2.1.12 is out.

Note: 2.1.x is the development series of munin.  There are more than a
few bits and pieces missing from 2.1.12 one would expect in a munin
master.

The new web interface is _much_ nicer, though.  :)

-- 
Stig Sandbeck Mathisen


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

Bug#779639: [Packaging] Bug#779639: munin-plugins-extra: Typo in /usr/share/munin/plugins/ejabberd_

[Stig Sandbeck Mathisen]

Holger Levsen hol...@layer-acht.org writes:

 will that patch also be merged in the 2.0 branch? 

I cherry-picked it to the stable-2.0 branch as
88514b2d8cc431c760112ea945ba337bf4630743

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#774643: [Pkg-puppet-devel] Bug#774643: [DRE-maint] Bug#774643: verify_active_connections is not present in ruby-activerecord 4.1.8

[Stig Sandbeck Mathisen]

Apollon Oikonomopoulos apoi...@debian.org writes:

 Then for Puppet 4/5/whatever we definitely need to provide a PuppetDB
 package.

To package puppetdb while following the Debian packaging policy,
experience with packaging clojure or java apps for Debian with leiningen
and maven would be a big bonus. The learning curve is scary steep.

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#775795: [Pkg-puppet-devel] Bug#775795: Patch to use /usr/sbin/service in Debian service-provider

[Stig Sandbeck Mathisen]

Apollon Oikonomopoulos apoi...@debian.org writes:

 On Fri, 27 Feb 2015 11:20:30 +0200 Apollon Oikonomopoulos 
 apoi...@debian.org wrote:
 The attached patch on top of 3.7.2-2 (hopefully) addresses all of
 these issues (and drops support for pre-2.88 sysv-rc if you don't
 mind). I have not tested it on a sysvinit Jessie system though, so if
 anyone could do this it would be appreciated!

 I also tested it on a sysv-rc Jessie system. This is an updated
 version of the patch, marking the systemctl command as optional.
 Without this, sysv-rc Jessie systems would have the Debian provider
 blacklisted because of the missing systemctl command.

Feel free to commit the patch to the packaging repo.

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#778265: [Pkg-puppet-devel] Bug#778265: CVE-2015-1426

[Stig Sandbeck Mathisen]

Control: tags -1 + patch confirmed

Moritz Muehlenhoff j...@inutil.org writes:

 Moritz Muehlenhoff wrote:
 Package: facter
 Severity: important
 Tags: security
 
 Please see http://puppetlabs.com/security/cve/cve-2015-1426

 Patch attached.

Lovely, thanks. :)

-- 
Stig Sandbeck Mathisen


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

Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades

[Stig Sandbeck Mathisen]

Control: severity -1 serious

Rik Theys rik.th...@esat.kuleuven.be writes:

 I was under the impression that upgrades from Wheezy to Jessie would
 switch the init system to systemd by default, unless a pin was
 configured prior to the upgrade (as instructed in the draft release
 notes)? Or do you mean upgrades from Jessie to Jessie+1 (Stretch?)?

No, you are right. The last message[1] on debian-devel-announce says
upgrade from wheezy to jessie will switch to systemd. Last time I read
about it, it was new installs get systemd, upgrades keep sysvinit.

[1] https://lists.debian.org/debian-devel-announce/2015/02/msg00013.html

 I installed the puppet package on a different Wheezy system to verify
 and it gets installed. 'dpkg -L puppet' also lists the file.

I tested the unstable packages, and not wheezy. I probably should have
tested wheezy.

 You've lost me. Where in the init script is puppet started with
 --disable?

The preinst script of the puppet-common package installs a lock file,
/var/lib/puppet/state/agent_disabled.lock to prevent it from applying a
catalog. The first packaged version of puppet which had this is 3.2.4-1,
which is … not in wheezy.

 Imagine I have a wheezy system with puppet installed and I've never
 updated /etc/default/puppet to change the START variable to have it
 started, my system would never have contacted any puppet master and
 would not have any certs. (we can argue that is doesn't make sense to
 have it installed if you're not using it, but there would be no
 security impact if you did as it wouldn't start by default).

It is also common to run puppet in masterless mode. If they install
the puppet package, they have the tools needed for that.

 When I then upgrade this wheezy system to jessie, my system will
 suddenly start puppet (as the init script/systemd unit no longer
 checks the START condition) and will send a certificate request to a
 puppet host on my network, which might not be under my control. If
 the admin of this rogue puppet master signs it and configures a
 manifest for my system, my system will happily apply it. Am I missing
 something? If this is correct, my opinion is that this has security
 implications.

I would argue that having someone else connect a server on your network,
and adding a puppet alias to your DNS pointing to this server has
security implications.

An installed puppet agent which has been disabled in wheezy will be
enabled in jessie is a bug. This would need to be solved before release
of jessie.

 Looking at the puppet postinst snippet of the jessie package I don't
 see any logic to only enable puppet when it was already enabled (by
 checking the START variable) before?

I've not used Debian stable for years, so I looked in the wrong place,
and misjudged the severity. Sorry.

 I'm not going to add it back, but unless I'm missing something in the
 scenario I've outlined above, I don't agree there are no security
 implications here.

There is a bug, which should be fixed. I've upgraded it to serious
again, so it is release critical.

There are security implications, but as it needs administrative
privileges to your DNS server or physical access to your network to
exploit. (Or, you need to place your laptop running puppet on a hostile
network, which is more likely.)

-- 
Stig Sandbeck Mathisen


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

Bug#759584: gearman-job-server: Gearman job server init script uses harcoded --listen argument

[Stig Sandbeck Mathisen]

Johannes Truschnigg johannes.truschn...@geizhals.at writes:

 it is, in my opinion, absolutely unacceptable that the
 /etc/default/gearman-job-server configuration file has no effect on
 jessie installations that use systemd to manage services.

Hello,

Thanks for contributing to the bug report.

The package is up for adoption, so if you would like to take over
maintainership, please see https://bugs.debian.org/775822

-- 
Stig Sandbeck Mathisen


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

Bug#759584: gearman-job-server: Gearman job server init script uses harcoded --listen argument

[Stig Sandbeck Mathisen]

Richard Ayotte rich.ayo...@ayottesoftware.com writes:

 Please update /lib/systemd/system/gearman-job-server.service to
 include the default params environment variables.

 [Unit]
 Description=gearman job control server

 [Service]
 EnvironmentFile=-/etc/default/gearman-job-server

[...]

 ExecStart=/usr/sbin/gearmand --pid-file=/run/gearman/server.pid $PARAMS

Thank you. I've added this to the systemd unit, and also updated the
upstart job with the same variable.

-- 
Stig Sandbeck Mathisen


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

Bug#778935: unblock: puppet-module-puppetlabs-postgresql/4.0.0-2

[Stig Sandbeck Mathisen]

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

Please unblock package puppet-module-puppetlabs-postgresql

The version of puppet-module-puppetlabs-postgresql attempts to install
postgresql 9.3 on a jessie system, while jessie has 9.4. Upstream has
corrected this in a later release, from which the fix has been cherry
picked.


debdiff puppet-module-puppetlabs-postgresql_4.0.0-1.dsc 
puppet-module-puppetlabs-postgresql_4.0.0-2.dsc
diff -Nru puppet-module-puppetlabs-postgresql-4.0.0/debian/changelog 
puppet-module-puppetlabs-postgresql-4.0.0/debian/changelog
--- puppet-module-puppetlabs-postgresql-4.0.0/debian/changelog  2014-10-24 
22:46:52.0 +0200
+++ puppet-module-puppetlabs-postgresql-4.0.0/debian/changelog  2015-02-21 
21:48:18.0 +0100
@@ -1,3 +1,10 @@
+puppet-module-puppetlabs-postgresql (4.0.0-2) unstable; urgency=medium
+
+  * [221918d] Import upstream commit 9bb1c5e to select correct postgresql
+version on jessie. Thanks to Andrew Starr-Bochicchio (Closes: #777607)
+
+ -- Stig Sandbeck Mathisen s...@debian.org  Sat, 21 Feb 2015 21:47:40 +0100
+
 puppet-module-puppetlabs-postgresql (4.0.0-1) unstable; urgency=medium
 
   * Imported upstream relase 4.0.0
diff -Nru 
puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/0001-Fixing-autodetected-version-for-Debian-Jessie-which-.patch
 
puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/0001-Fixing-autodetected-version-for-Debian-Jessie-which-.patch
--- 
puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/0001-Fixing-autodetected-version-for-Debian-Jessie-which-.patch
1970-01-01 01:00:00.0 +0100
+++ 
puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/0001-Fixing-autodetected-version-for-Debian-Jessie-which-.patch
2015-02-21 21:48:18.0 +0100
@@ -0,0 +1,30 @@
+From: Armin ranjbar z...@zoup.org
+Date: Fri, 21 Nov 2014 22:26:18 +0330
+Subject: Fixing autodetected version for Debian Jessie,
+ which uses postgresql 9.4
+
+---
+ manifests/globals.pp | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/manifests/globals.pp b/manifests/globals.pp
+index 1bbf7d5..823ad81 100644
+--- a/manifests/globals.pp
 b/manifests/globals.pp
+@@ -67,7 +67,7 @@ class postgresql::globals (
+   'Debian' = $::operatingsystemrelease ? {
+ /^6\./ = '8.4',
+ /^(wheezy|7\.)/ = '9.1',
+-/^(jessie|8\.)/ = '9.3',
++/^(jessie|8\.)/ = '9.4',
+ default = undef,
+   },
+   'Ubuntu' = $::operatingsystemrelease ? {
+@@ -102,6 +102,7 @@ class postgresql::globals (
+ '91'= '1.5',
+ '9.2'   = '2.0',
+ '9.3'   = '2.1',
++'9.4'   = '2.1',
+ default = undef,
+   }
+   $globals_postgis_version = pick($postgis_version, $default_postgis_version)
diff -Nru puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/series 
puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/series
--- puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/series 
1970-01-01 01:00:00.0 +0100
+++ puppet-module-puppetlabs-postgresql-4.0.0/debian/patches/series 
2015-02-21 21:48:18.0 +0100
@@ -0,0 +1 @@
+0001-Fixing-autodetected-version-for-Debian-Jessie-which-.patch


unblock puppet-module-puppetlabs-postgresql/4.0.0-2

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: 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#775535: [Pkg-puppet-devel] Bug#775535: CVE-2015-1029

[Stig Sandbeck Mathisen]

Moritz Muehlenhoff j...@debian.org writes:

 On Sat, Jan 17, 2015 at 12:09:51AM +0100, Moritz Muehlenhoff wrote:
 Package: puppet-module-puppetlabs-stdlib
 Severity: important
 Tags: security
 
 Hi,
 please see http://puppetlabs.com/security/cve/cve-2015-1029

 It's been a month, what's the status?

I replied with
http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/2015-January/009318.html,
but it seems I managed to send it as a followup to the pkg-puppet-devel
mailing list, and not to the BTS.

Sorry about that.

I think there is an error in the CVE. After reading the code, I think it
should be facter versions older than 1.7, and not facter version 1.7
and newer.

-- 
Stig Sandbeck Mathisen


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

Bug#778891: [Pkg-puppet-devel] Bug#778891: puppet: systemd unit file does not load environment from /etc/default/puppet - breaks upgrades

[Stig Sandbeck Mathisen]

Control: severity -1 wishlist wontfix
Control: tags -1 - security

Rik Theys rik.th...@esat.kuleuven.be writes:
 During an upgrade from wheezy to jessie, puppet was upgraded to 3.7.2
 and systemd became the default init system.

When jessie is released, an upgrade should keep the current init system.

 In our environment, our puppet master is not called puppet and we
 override this setting using the DAEMON_OPTS variable in
 /etc/default/puppet:

 DAEMON_OPTS=--server our-puppet-master.ourdomain.tld

 The wheezy (and jessie) init script supports this, but the systemd
unit file for puppet does not read this environment file and defaults
back to the puppet DNS name for puppet masters.

 The fix for this is simple and a patch for the systemd unit file is
 attached: the unit file should have an EnvironmentFile statement to
 load the environment from /etc/default/puppet (if it exists).

The /etc/default/puppet file is not shipped with the puppet packaging,
but is checked for in the sysv init script as a means to override the
configuration.

For systemd, please use override your systemd unit with one of:

* A fragment in /etc/systemd/system/puppet.service.d/something.conf

* Complete override with /etc/systemd/system/puppet.service

Please consider setting server under the [main] section in
/etc/puppet/puppet.conf. This will work no matter which init is used.

 I've flagged this as security as an upgrade from wheezy to jessie
 could open a system to a puppet server controlled by someone else. In
 case the puppet client did not yet have signed certificate it could be
 signed by the puppet puppet master, which could then execute
 arbitrary actions on the system.

The puppet agent starts disabled with puppet agent --disable, and has
to be manually enabled with puppet agent --enable. Even disabled, the
puppet agent will connect to the master, send its CSR, and ask for a
signed certificate periodically.

If it is manually enabled, and still connects to a master someone has
successfully installed on your network after having changed your domain
to add the puppet name to point to that puppet master, I would suggest
this is not primarily a security fault in the puppet agent packaging.

If you need to configure /etc/default/puppet with command line options
for a puppet master, install puppet agent, have it not to connect to the
master, upgrade it from wheezy to jessie, then change init systems, and
_then_ start the puppet agent, the window of opportunity for such an
attacker is rather small.

If the puppet agent has a puppet certificate, the puppet agent will
abort with a SSL error when connecting to the new master, since the CA
will differ.

,[ error when connecting to fake master ]
| Warning: SSL_connect returned=1 errno=0 state=unknown state:
| certificate verify failed: [self signed certificate in certificate
| chain for /CN=Puppet CA: mallet.example.com]
`

In theory, the impersonating node could be a current puppet agent,
signed by the legitimate CA, but it would have to have puppet (or the
hostname configured as server in puppet.conf) as an alternate name in
the agent sertificate.

Signing a puppet agent certificate on the puppet master with alternate
names requires extra commandline options to puppet cert sign, and
prompts you with a message in the master log, and on the agent node:

,[ error when signing a host certificate with extra hostnames ]
| Error: CSR 'mallet.example.com' contains subject alternative names
| (DNS:mallet.example.com, DNS:puppet), which are disallowed. Use
| `puppet cert --allow-dns-alt-names sign mallet.example.com` to sign
| this request.
`

This scenario is not very likely; I have removed the security tag.

 I did not check if the postinst script only enables the systemd unit
 when the START variable in /etc/default/puppet is set to yes. If it
 doesn't, the puppet service will be started on upgrades to jessie (and
 systemd), even if it was disabled before. It would also introduce the
 problem above by contacting the wrong puppet master.

The init script only uses DAEMON_OPTS if set. This is only a historic
feature for the sysvinit script. The START variable is not used at all.

I'll keep this bug open with wishlist and wontfix tags, until the
use of /etc/default/* with multiple init systems have settled, or
diminished over time.

-- 
Stig Sandbeck Mathisen


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

Bug#775795: [Pkg-puppet-devel] Bug#775795: Patch to use /usr/sbin/service in Debian service provider

[Stig Sandbeck Mathisen]

Gaudenz Steinlin gaud...@debian.org writes:

 Attached is an updated patch that uses a propoer Ruby constant for
 /usr/sbin/service. The first patch was botched by my Pythonistic
 approach to code this.

That looks much better, thanks.

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#775795: [Pkg-puppet-devel] Bug#775795: Patch to use /usr/sbin/service in Debian service provider

[Stig Sandbeck Mathisen]

Gaudenz Steinlin gaud...@debian.org writes:

 Attached is an updated patch that uses a propoer Ruby constant for
 /usr/sbin/service. The first patch was botched by my Pythonistic
 approach to code this.

Patch committed. I've tested the packages with autopkgtest as well as
manually. I've uploaded the new packages, and sent an unblock request to
the release team.

Thank you. :)

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#777173: unblock: puppet/3.7.2-2

[Stig Sandbeck Mathisen]

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

Please unblock package puppet


The puppet provider for handling services (starting, stopping, status
query) executed /etc/init.d/$service, which has unpredictable
results when using an init other than sysvinit.

A patch has been added to make puppet execute /usr/sbin/service
$service instead, ensuring that puppet can handle services no matter
which init system is used.



diff -Nru puppet-3.7.2/debian/changelog puppet-3.7.2/debian/changelog
--- puppet-3.7.2/debian/changelog   2014-10-24 13:47:25.0 +0200
+++ puppet-3.7.2/debian/changelog   2015-02-05 22:50:31.0 +0100
@@ -1,3 +1,11 @@
+puppet (3.7.2-2) unstable; urgency=medium
+
+  [ Gaudenz Steinlin ]
+  * [558cce5] Use /usr/sbin/service in the Debian service provider
+(Closes: #775795)
+
+ -- Stig Sandbeck Mathisen s...@debian.org  Thu, 05 Feb 2015 22:44:49 +0100
+
 puppet (3.7.2-1) unstable; urgency=medium
 
   * Imported upstream release 3.7.2
diff -Nru 
puppet-3.7.2/debian/patches/0004-debian-service-provider-use-service.patch 
puppet-3.7.2/debian/patches/0004-debian-service-provider-use-service.patch
--- puppet-3.7.2/debian/patches/0004-debian-service-provider-use-service.patch  
1970-01-01 01:00:00.0 +0100
+++ puppet-3.7.2/debian/patches/0004-debian-service-provider-use-service.patch  
2015-02-05 22:50:31.0 +0100
@@ -0,0 +1,56 @@
+From: Gaudenz Steinlin gaud...@debian.org
+Subject: Use /usr/sbin/service for service management on Debian
+
+In Debian jessie systemd will be the default init system. But the old system V
+and other alternative init systems are still supported. /usr/sbin/service
+provides an abstraction layer which is able to start, stop and restart
+services independent of the init system used.
+
+Bug: https://tickets.puppetlabs.com/browse/PUP-2023
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775795
+---
+Index: puppet/lib/puppet/provider/service/debian.rb
+===
+--- puppet.orig/lib/puppet/provider/service/debian.rb  2015-02-05 
12:07:37.451292892 +0100
 puppet/lib/puppet/provider/service/debian.rb   2015-02-05 
12:13:06.500095957 +0100
+@@ -16,6 +16,11 @@
+   # is resolved.
+   commands :invoke_rc = /usr/sbin/invoke-rc.d
+ 
++  # This isn't being used directly, it's just here to ensure
++  # that the /usr/sbin/service binary is available.
++  SERVICE = /usr/sbin/service
++  commands :service_cmd = SERVICE
++
+   defaultfor :operatingsystem = :debian
+ 
+   # Remove the symlinks
+@@ -61,4 +66,28 @@
+ update_rc -f, @resource[:name], remove
+ update_rc @resource[:name], defaults
+   end
++
++  # The start, stop, restart and status command use service
++  # this makes sure that these commands work with whatever init
++  # system is installed
++  def startcmd
++[SERVICE, @resource[:name], :start]
++  end
++
++  # The stop command is just the init script with 'stop'.
++  def stopcmd
++[SERVICE, @resource[:name], :stop]
++  end
++
++  def restartcmd
++(@resource[:hasrestart] == :true)  [SERVICE, @resource[:name], :restart]
++  end
++
++  # If it was specified that the init script has a 'status' command, then
++  # we just return that; otherwise, we return false, which causes it to
++  # fallback to other mechanisms.
++  def statuscmd
++(@resource[:hasstatus] == :true)  [SERVICE, @resource[:name], :status]
++  end
++
+ end
diff -Nru puppet-3.7.2/debian/patches/series puppet-3.7.2/debian/patches/series
--- puppet-3.7.2/debian/patches/series  2014-10-24 13:47:25.0 +0200
+++ puppet-3.7.2/debian/patches/series  2015-02-05 22:50:31.0 +0100
@@ -1,3 +1,4 @@
 0001-Do-not-require-rubygems.patch
 0002-Set-passenger-puppet-master-document-root.patch
 0003-fix-puppet-master-logcheck-rule.patch
+0004-debian-service-provider-use-service.patch




unblock puppet/3.7.2-2

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: 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#775795: Patch to use /usr/sbin/service in Debian service provider

[Stig Sandbeck Mathisen]

Hello,

Thanks for the patch.  It looks like it has the correct solution, using
the Debian abstraction layer over the alternative init systems.

However, I've found a problem with it using the puppet resource
command. Could you see if you find what causes it?

With puppet 3.7.22-1:

,
| root@dagon:~# puppet resource service apache2
| service { 'apache2':
|   ensure = 'stopped',
|   enable = 'true',
| }
`

With your patch:

,
| root@dagon:~# puppet resource service apache2
| Error: Could not run: undefined local variable or method `service' for 
#Puppet::Type::Service::ProviderDebian:0x00029b9d88
`

-- 
Stig Sandbeck Mathisen


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

Bug#775823: RFA: mod-gearman

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: normal

I am looking for a new maintainer for the mod-gearman package. It
provides the binary packages:

* mod-gearman-doc
* mod-gearman-module
* mod-gearman-worker
* mod-gearman-tools

I do not use mod-gearman anymore, and it would be nice for it to be
adopted by someone who does.


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

Bug#775827: RFA: grok -- powerful pattern-matching and reacting tool

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: normal

I request an adopter for the grok package. I no longer use it, so it
would be nice for it to have a maintainer that does.

The package description is:
 The grok program can parse log data and program output. You can match
 any number of complex patterns on any number of inputs (processes and
 files) and have custom reactions.
 .
 Grok is simple software that allows you to easily parse logs and
 other files. With grok, you can turn unstructured log and event data
 into structured data.


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

Bug#775822: RFA: gearmand

[Stig Sandbeck Mathisen]

Package: wnpp
Severity: normal

I am looking for a new maintainer for the gearmand package. It
provides the binary packages:

* gearman
* gearman-job-server
* gearman-tools
* libgearman-dbg
* libgearman-dev
* libgearman-doc
* libgearman7
* libgearman7-dbg

I do not use gearmand anymore, and it would be nice for it to be
adopted by someone who does.


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

Bug#774963: [Pkg-varnish-devel] Bug#774963: varnish: nonexistent -w in /etc/default/varnish

[Stig Sandbeck Mathisen]

Control: tags -1 + confirmed

Jakub Wilk jw...@debian.org writes:

 But varnishd doesn't have a -w option.

Well spotted, thank you.

This option was used in varnish 3, but disappeared in varnish 4. I've
committed a fix to the packaging repository, removing this line and its
related variables from the example.

-- 
Stig Sandbeck Mathisen


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

Bug#774690: unblock: gearmand/1.0.6-5

[Stig Sandbeck Mathisen]

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

Please unblock package gearmand

This version fixes #774143 (https://bugs.debian.org/774143), a bug
which makes the gearman job server unresponsive when given an invalid
http request, causing it to loop on the CPU and consume increasing
amounts of memory until killed.

The gearman http responder, which has this error, is not loaded by
default, but a command line switch in /etc/default/gearman-job-server
will enable it.

diff -Nru gearmand-1.0.6/debian/changelog gearmand-1.0.6/debian/changelog
--- gearmand-1.0.6/debian/changelog 2014-07-23 11:12:37.0 +0200
+++ gearmand-1.0.6/debian/changelog 2015-01-06 09:47:49.0 +0100
@@ -1,3 +1,10 @@
+gearmand (1.0.6-5) unstable; urgency=medium
+
+  * [db0b16d] Add patch to fix endless loop on bad http request.
+Thanks to Alexei Pastuchov (Closes: #774143)
+
+ -- Stig Sandbeck Mathisen s...@debian.org  Tue, 06 Jan 2015 09:47:37 +0100
+
 gearmand (1.0.6-4) unstable; urgency=medium
 
   * Change url for uscan to use launchpad.net
diff -Nru 
gearmand-1.0.6/debian/patches/0001-Bug-715322-gearmand-FTBFS-on-hurd-i386.patch 
gearmand-1.0.6/debian/patches/0001-Bug-715322-gearmand-FTBFS-on-hurd-i386.patch
--- 
gearmand-1.0.6/debian/patches/0001-Bug-715322-gearmand-FTBFS-on-hurd-i386.patch 
2014-07-23 11:12:48.0 +0200
+++ 
gearmand-1.0.6/debian/patches/0001-Bug-715322-gearmand-FTBFS-on-hurd-i386.patch 
2015-01-06 09:51:47.0 +0100
@@ -57,5 +57,5 @@
mach_timespec_t _mach_timespec;
host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, _clock_serv);
 -- 
-2.0.1
+2.1.4
 
diff -Nru 
gearmand-1.0.6/debian/patches/0002-bugfix-endless-loop-on-http-bad-request-or-bad-metho.patch
 
gearmand-1.0.6/debian/patches/0002-bugfix-endless-loop-on-http-bad-request-or-bad-metho.patch
--- 
gearmand-1.0.6/debian/patches/0002-bugfix-endless-loop-on-http-bad-request-or-bad-metho.patch
   1970-01-01 01:00:00.0 +0100
+++ 
gearmand-1.0.6/debian/patches/0002-bugfix-endless-loop-on-http-bad-request-or-bad-metho.patch
   2015-01-06 09:51:47.0 +0100
@@ -0,0 +1,39 @@
+From 44d251715c0857c3666cba845f1b8a80257c3bdf Mon Sep 17 00:00:00 2001
+From: Stig Sandbeck Mathisen s...@debian.org
+Date: Tue, 6 Jan 2015 08:39:53 +0100
+Subject: [PATCH] bugfix endless loop on http bad request or bad method
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774143
+Bug: https://bugs.launchpad.net/gearmand/+bug/1348865
+Origin: http://bazaar.launchpad.net/~1-infe-w/gearmand/1.0/revision/802
+Forwarded: not-needed
+Description: Fix endless loop on bad http request
+---
+ libgearman-server/plugins/protocol/http/protocol.cc | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/libgearman-server/plugins/protocol/http/protocol.cc 
b/libgearman-server/plugins/protocol/http/protocol.cc
+index 73393f7..720e9d8 100644
+--- a/libgearman-server/plugins/protocol/http/protocol.cc
 b/libgearman-server/plugins/protocol/http/protocol.cc
+@@ -293,7 +293,7 @@ public:
+ {
+   gearmand_log_error(GEARMAN_DEFAULT_LOG_PARAM, bad request line: %.*s, 
(uint32_t)request_size, request);
+   set_response(gearmand::protocol::httpd::HTTP_NOT_FOUND);
+-  ret_ptr= GEARMAN_SUCCESS;
++  ret_ptr= GEARMAN_INVALID_PACKET;
+   return 0;
+ }
+ 
+@@ -329,7 +329,7 @@ public:
+   {
+ gearmand_log_error(GEARMAN_DEFAULT_LOG_PARAM, bad method: %.*s, 
(uint32_t)method_size, method_str);
+ set_response(gearmand::protocol::httpd::HTTP_METHOD_NOT_ALLOWED);
+-ret_ptr= GEARMAN_SUCCESS;
++ret_ptr= GEARMAN_INVALID_PACKET;
+ return 0;
+   }
+ }
+-- 
+2.1.4
+
diff -Nru gearmand-1.0.6/debian/patches/series 
gearmand-1.0.6/debian/patches/series
--- gearmand-1.0.6/debian/patches/series2014-07-23 11:12:48.0 
+0200
+++ gearmand-1.0.6/debian/patches/series2015-01-06 09:51:47.0 
+0100
@@ -1,2 +1,3 @@
 # debian/source/git-patches exported from git by quilt-patches-deb-export-hook
 0001-Bug-715322-gearmand-FTBFS-on-hurd-i386.patch
+0002-bugfix-endless-loop-on-http-bad-request-or-bad-metho.patch
diff -Nru gearmand-1.0.6/debian/source/git-patches 
gearmand-1.0.6/debian/source/git-patches
--- gearmand-1.0.6/debian/source/git-patches2014-07-23 11:12:37.0 
+0200
+++ gearmand-1.0.6/debian/source/git-patches2015-01-06 09:47:49.0 
+0100
@@ -1 +1,2 @@
 upstream/1.0.6..patches/1.0.6/715322-ftbfs-on-gnu-hurd
+upstream/1.0.6..patches/1.0.6/774143-endless-loop-on-bad-request


unblock gearmand/1.0.6-5

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

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

Bug#774143: malicious HTTP request kills gearmand

[Stig Sandbeck Mathisen]

Hello,

Thank you for reporting this issue.

I see that this bug has been new/unassigned on the upstream bug
tracker since august last year, and that the gearman upstream has been
rather quiet for more than half a year.

The patch at
http://bazaar.launchpad.net/~1-infe-w/gearmand/1.0/revision/802 looks
very tempting.

-- 
Stig Sandbeck Mathisen


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

Bug#774643: [Pkg-puppet-devel] Bug#774643: Lacking support of exported resources

[Stig Sandbeck Mathisen]

micah mi...@riseup.net writes:

 Hello!

 bertagaz berta...@ptitcanardnoir.org writes:

 That's because in puppet 3.x, a switch has been made upstream from
 activerecord to puppetdb as a backend for catalog storage and
 searching.

 Hmm, I think that is not true. Activerecord storedconfigs still work,
 they are somewhat deprecated, and I believe removed in puppet 4, but I
 know people who have used storeconfigs in 3.6.2.

 Additionally, I've looked through the release notes[0] and I could
 find nothing that said that it was removed.

Activerecord storedconfigs should still work with the current puppet.

 It seems that puppetdb is not packaged into Debian at the moment.
 There's an open RFP for it at #673515, and upstream has a Debian
 package at apt.puppetlabs.com.

I did a stab at packaging it in 2012, but was not successful. At that
time I was not able to figure out how to build packages with Leiningen
while also following the Debian packaging policy.

The ITP became an RFP sometime later.

 This looks like a regression, which either need to be fixed before
 the Jessie release, or documented in the release notes, but the last
 option will probably bring a lot of hassle to sysadmins.

 What kind of errors are you getting that lead you to this conclusion?

 Also - I think that moving modules to make storedconfigs 'optional' is a
 very good thing to do. Many people use masterless puppet setups which
 cannot use storeconfigs and would benefit from any work that is done
 there!

It is possible to use PuppetDB masterless. You would probably need an
SSL CA, but a puppet master is not necessary. (For example, see
https://github.com/puppetlabs/puppetlabs-puppetdb/blob/master/README.md)

That said: puppetdb and puppetserver should be packaged. I would
consider them part of the normal puppet stack. Anyone possessing the
necessary experience with Clojure, Leiningen and Maven, or just an
overdeveloped sense of adventure, is welcome to try.

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#771863: [ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly, updating severity

[Stig Sandbeck Mathisen]

Joe Stringer joestrin...@nicira.com writes:

 I agree that this should be treated as a separate bug, yes please (I'm
 just following up as it wasn't clear to me whether you're working on
 this or not).

Ok, I'll report it as a new bug.

-- 
Stig Sandbeck Mathisen


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

Bug#771863: [ovs-dev] Bug#771863: Service does not start or parse interfaces correctly, updating severity

[Stig Sandbeck Mathisen]

Gurucharan Shetty shet...@nicira.com writes:

 I haven't looked at what needs to be done to handle those statements.
 I welcome a patch, preferably sent to d...@openvswitch.org after
 reading the CONTRIBUTING.md in the openvswitch repo.

I assume the openvswitch repo is at https://github.com/openvswitch/ovs

Do you use GitHub pull requests at all, or prefer just formatted patches
to the mailing list?

 I would like to clarify that 2.3.1 does get rid of the check on
 $RUNLEVEL which was the original bug description.

That's great, thanks. :)

I probably should treat this as a separate bug. Would you like me to
file a new bug for it in the Debian BTS, in addition to submitting an
upstream patch?

-- 
Stig Sandbeck Mathisen


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

Bug#771863: Service does not start or parse interfaces correctly, updating severity

[Stig Sandbeck Mathisen]

Control: severity -1 serious

Hello,

Since the service does not start under the new default init, and since
it also does not follow includes from /etc/network/interfaces, I would
think this justifies a serious severity. Updating the severity
accordingly.

(I feel less bad about bumping severity when there's a working patch
attached, though)

-- 
Regards,
Stig Sandbeck Mathisen


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

Bug#771863: openvswitch-switch: Patch update, handle interface files sourced from /etc/network/interfaces

[Stig Sandbeck Mathisen]

Package: openvswitch-switch
Version: 2.3.0+git20140819-2
Followup-For: Bug #771863

Dear Maintainer,

The network_interfaces() function in the /etc/init.d/openvswitch-switch
script also does not handle source or source-directory statements in
/etc/network/interfaces.

Please consider the attached patch which, including the first problem in
this bug, also uses the ifquery command to list available bridges.

The ifquery command is from the ifupdown package.

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

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

Versions of packages openvswitch-switch depends on:
ii  kmod   18-3
ii  libatomic1 4.9.1-19
ii  libc6  2.19-13
ii  libpython2.7-stdlib [python-argparse]  2.7.8-11
ii  libssl1.0.01.0.1j-1
ii  netbase5.3
ii  openvswitch-common 2.3.0+git20140819-2
ii  procps 2:3.3.9-8
pn  python:any none
ii  uuid-runtime   2.25.2-3

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- Configuration Files:
/etc/init.d/openvswitch-switch changed [not included]

-- no debconf information
--- /etc/init.d/openvswitch-switch.old	2014-08-19 17:30:43.0 +0200
+++ /etc/init.d/openvswitch-switch	2014-12-09 09:08:29.718205202 +0100
@@ -31,10 +31,7 @@
 test -e /etc/default/openvswitch-switch  . /etc/default/openvswitch-switch
 
 network_interfaces () {
-[ -z ${RUNLEVEL} ]  return
-INTERFACES=/etc/network/interfaces
-[ -e ${INTERFACES} ] || return
-bridges=`awk '{ if ($1 == allow-ovs) { print $2; } }' ${INTERFACES}`
+bridges=$(ifquery --allow=ovs --list)
 [ -n ${bridges} ]  $1 --allow=ovs ${bridges}
 }
 

Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created

[Stig Sandbeck Mathisen]

Mikaël Cluseau mclus...@isi.nc writes:

 Do we agree that with systemd the pid-file logic becomes useless, and
 thus the proper fix would be to get rid of them, or do you it would be
 better to keep them, meaning the proper logic becomes the one of
 tmpfiles.d ?

As long as the systemd units run the init scripts, which then fork the
daemon, and the daemon makes a PID file, I think PIDFile= should be
defined in the systemd unit.

If PIDFile= is not set, systemd will make a guess as to what the main
pid is, and it may be wrong.

The relevant bits from man systemd.service(5):

,[ GuessMainPID= ]
| Takes a boolean value that specifies whether systemd should try to
| guess the main PID of a service if it cannot be determined reliably.
| This option is ignored unless Type=forking is set and PIDFile= is
| unset because for the other types or with an explicitly configured PID
| file, the main PID is always known. The guessing algorithm might come
| to incorrect conclusions if a daemon consists of more than one
| process. If the main PID cannot be determined, failure detection and
| automatic restarting of a service will not work reliably. Defaults to
| yes.
`

,[ PIDFile= ]
| Takes an absolute file name pointing to the PID file of this daemon.
| Use of this option is recommended for services where Type= is set to
| forking. systemd will read the PID of the main process of the daemon
| after start-up of the service. systemd will not write to the file
| configured here.
`

-- 
Stig Sandbeck Mathisen


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

Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created

[Stig Sandbeck Mathisen]

Mikaël Cluseau n...@nwrk.info writes:

 Hi,

 isn't it a duplicate of
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767711 ?

Yes. I suggest a merging of bugs. :)

Note: The proposed solution in that bug will not work for services
sharing the same runtime directory. The services will delete each others
runtime directory and pid files.

-- 
Stig Sandbeck Mathisen


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

Bug#770706: [PKG-Openstack-devel] Bug#770706: Bug#770706: Bug#770706: keystone.service does not start, /var/run/keystone not created

[Stig Sandbeck Mathisen]

Gaudenz Steinlin gaud...@debian.org writes:

 I'll try to find some time to have a look, but can't promise anything.

Adding the following files fixed this issue for me:

head /etc/tmpfiles.d/*
== /etc/tmpfiles.d/ceilometer.conf ==
d /run/ceilometer 0755 ceilometer ceilometer - -

== /etc/tmpfiles.d/glance.conf ==
d /run/glance 0755 glance glance - -

== /etc/tmpfiles.d/keystone.conf ==
d /run/keystone 0755 keystone keystone - -

Packages will normally install these files into /usr/lib/tmpfiles.d/
instead.

If the packages:

* contain the file debian/packagename.tmpfile with content described
  above.

* is built using debhelper with dh_systemd (I see this is true for the
  keystone package)

...this will create the run directories when the packages are installed,
 as well as on boot, and then only if systemd is running as pid 1.

-- 
Stig Sandbeck Mathisen


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

Bug#770706: keystone.service does not start, /var/run/keystone not created

[Stig Sandbeck Mathisen]

Package: keystone
Version: 2014.1.3-2
Severity: important

Dear Maintainer,

When installing keystone on a host running systemd, the service does not
start.

The error from the unit on start is:

Nov 23 12:33:41 server.example.com keystone[18089]: mkdir: cannot create 
directory ‘/var/run/keystone’: Permission denied
Nov 23 12:33:41 server.example.com keystone[18089]: chown: cannot access 
‘/var/run/keystone’: No such file or directory
Nov 23 12:33:41 server.example.com keystone[18089]: start-stop-daemon: unable 
to open pidfile '/var/run/keystone/keystone.pid' for writing (No such file or 
directory)
Nov 23 12:33:41 server.example.com keystone[18089]: start-stop-daemon: child 
returned error exit status 2 (No such file or directory)
Nov 23 12:35:11 server.example.com systemd[1]: keystone.service start operation 
timed out. Terminating.
Nov 23 12:35:11 server.example.com systemd[1]: Failed to start OpenStack 
Identity service.
Nov 23 12:35:11 server.example.com systemd[1]: Unit keystone.service entered 
failed state.

Adding RuntimeDirectory=keystone under [Service] in the
/lib/systemd/system/keystone.service unit fixes the problem. This will
make systemd create the keystone runtime directory under /run.

I would like to submit a patch, but can't easily find the source of the
systemd units in the packaging repo at
http://anonscm.debian.org/cgit/openstack/keystone.git/ -- I do notice
that the override_dh_clean target removes them, so I suspect they are
generated somehow.

I set the severity to important, but suspect that an upgrade to
serious is necessary to get it unfrozen and fixed before the release
of jessie.

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

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

Versions of packages keystone depends on:
ii  adduser3.113+nmu3
ii  dbconfig-common1.8.47+nmu3
ii  debconf [debconf-2.0]  1.5.53
ii  dpkg   1.17.21
ii  lsb-base   4.1+Debian13+nmu1
ii  python-configobj   5.0.6-1
ii  python-keystone2014.1.3-2
pn  python:any none
ii  sqlite33.8.7.1-1
ii  ssl-cert   1.0.35

keystone recommends no packages.

keystone suggests no packages.

-- Configuration Files:
[not relevant, and just filled with defaults]

-- debconf information excluded


-- 
Stig Sandbeck Mathisen


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

Bug#770706: keystone.service does not start, /var/run/keystone not created

[Stig Sandbeck Mathisen]

Looks like my proposed solution (RuntimeDirectory=) does not work very
well with multiple services needing the same /run/something directories.

When I defined multiple services with the same RuntimeDir=, the services
delete each others runtime directories. This is documented in
systemd.exec(5) for RuntimeDirectory=. This affects the ceilometer-* and
glance-* services.

The processes are started, but since pidfiles are not created, and the
systemd units are configured with PIDFile=, systemd times out waiting
for the pidfiles to be created, and assumes the services didn't start
correctly, which again the packages from being installed.

I'll try using tmpfiles.d to solve this, as the systemd.exec(5) man
page already mentions.

-- 
Stig Sandbeck Mathisen


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

Bug#749479: [Pkg-puppet-devel] Bug#749479: Please include puppet into backports

[Stig Sandbeck Mathisen]

Apollon Oikonomopoulos apoi...@debian.org writes:

 I have prepared a backport of puppet 3.7.2 and all its dependencies.
 This currently includes:

   augeas  1.2.0-0.2~bpo70+1
   facter  2.2.0-1~bpo70+1
   hiera   1.3.4-1~bpo70+1
   puppet  3.7.2-1~bpo70+1
   ruby-augeas 0.5.0-2~bpo70+1
   ruby-hashie 2.0.5-1~bpo70+1
   ruby-rgen   0.7.0-1~bpo70+1
   ruby-safe-yaml  1.0.3-1~bpo70+1

 I have tested the client part, and will also test the master part in
 our setup tomorrow. If all goes well, I intend to upload them to
 wheezy-backports if noone objects.

A nice set of backports. :)

Regarding testing, there are DEP-8 tests in the puppet packaging. The
tests install a puppet master with apache and mod_passenger, and run the
agent against it. That should be a decent indicator if the packages are
good enough or not.

If any changes were necessary, and committed to git, would you like to
push to a wheezy-backports branch on each packaging repository? If not,
I should be able to use «gbp import-dsc» to add them to the packaging
repository.

-- 
Stig Sandbeck Mathisen


signature.asc
Description: PGP signature

Bug#767342: jemalloc: Allocator profiling capabilities should be enabled

[Stig Sandbeck Mathisen]

Giuseppe Lavagetto glavage...@wikimedia.org writes:

 I don't think there is any good reason not to enable this by default
 in debian. The patch I include will accomplish just that.

Thank you. I agree with this, and have committed it to the packaging
repository.

-- 
Stig Sandbeck Mathisen s...@debian.org


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

Bug#767200: munin-node: /etc/munin/plugin-conf.d/munin-node overrides some, but not all, other configuration

[Stig Sandbeck Mathisen]

Package: munin-node
Version: 2.0.24-1
Severity: important

The current configuration file supplied by the package should be
called 00-defaults, in order for users to be able to concistently
override the configuration.

Munin Node now reads configuration files for plugins from
/etc/munin/plugin-conf.d/ alphabetically.

A common pattern is to place configuration files with the same name as
the plugin being configured in this directory, and in that case, the
existing file would potentially override settings for all plugins with
a name being sorted before munin-node.

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

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

Versions of packages munin-node depends on:
ii  gawk 1:4.1.1+dfsg-1
ii  init-system-helpers  1.21
ii  libnet-server-perl   2.008-1
ii  lsb-base 4.1+Debian13
ii  munin-common 2.0.24-1
ii  munin-plugins-core   2.0.24-1
ii  perl 5.20.1-1
ii  procps   2:3.3.9-8

Versions of packages munin-node recommends:
ii  libnet-snmp-perl 6.0.1-2
ii  munin-plugins-extra  2.0.24-1

Versions of packages munin-node suggests:
ii  acpi  1.7-1
ii  ethtool   1:3.16-1
ii  hdparm9.43-1.1
ii  libcrypt-ssleay-perl  0.58-1+b2
ii  libdbd-pg-perl3.4.2-1
pn  liblwp-useragent-determined-perl  none
pn  libnet-irc-perl   none
pn  libtext-csv-xs-perl   none
ii  libwww-perl   6.08-1
ii  libxml-simple-perl2.20-1
pn  logtail   none
ii  munin 2.0.24-1
ii  munin-plugins-java2.0.24-1
pn  mysql-client  none
ii  net-tools 1.60-26
ii  python2.7.8-1
ii  ruby  1:2.1.0.4
pn  smartmontools none

-- 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#762904: [Packaging] Bug#762904: patch for bug 762904

[Stig Sandbeck Mathisen]

Control: tags -1 + confirmed upstream

Luc Maisonobe l...@spaceroots.org writes:

 Here is a patch fixing the problem.

Thank you. I've committed the change upstream. It'll make the next
stable release.

-- 
Stig Sandbeck Mathisen


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