Bug#1036755: linux: 6.1.26 <= x < 6.1.30 breaks applications using mmap(MAP_32BIT)
Hi Salvatore, Thanks for the quick response! On 19:12 Thu 25 May , Salvatore Bonaccorso wrote: > Control: tags -1 + confirmed pending > > I'm not yet certain, that critical severity is right, and making it > RC. But will look into the issue today. Well, technically it is a regression and it does break userspace, although I admit it probably does so only for a handful of edge-cases. Anyway, critical is probably an overstatement, so feel free to downgrade if you wish. > Defitnively the issue will be fixed. Just at this stage for the > bookworm release I will pick it for the first upload after the release > in a point release update or a security update (whatever will come > first likely). I understand that it is late in the release cycle and it would be a shame to delay the Bookworm release for this. As far as Ganeti is concerned, we can let people know that they should wait for the first point release before upgrading their clusters. Again, thanks for your work! Cheers, Apollon
Bug#1036755: linux: 6.1.26 <= x < 6.1.30 breaks applications using mmap(MAP_32BIT)
Source: linux Version: 6.1.27-1 Severity: critical Tags: upstream Affects: ganeti Justification: breaks unrelated software Dear Kernel Maintainers, A regression was introduced with upstream commit 58c5d0d6d5, subsequently backported to 6.1 as 7e6631f7 and released with 6.1.26. These commits break MAP_32BIT and affect applications relying on it. In particular, we are seeing failures in ganeti's autopkgtests[1], where a daemon written in Haskell (the GHC linker uses MAP_32BIT) segfaults with a null pointer dereference. From the build artifacts: ganeti-luxid: mmap 4096 bytes at (nil): Cannot allocate memory ganeti-luxid: Try specifying an address with +RTS -xm -RTS This has already been discussed on GHC's discourse[2] and has been fixed upstream, with the fix queued for 6.1.30[3]. Please consider upgrading to 6.1.30 or cherry-picking the fix for Bookworm. Thanks, Apollon [1] https://ci.debian.net/packages/g/ganeti/testing/amd64/, notably the run at 2023-05-14 15:13:51 UTC, the first one running on 6.1.27. [2] https://discourse.haskell.org/t/facing-mmap-4096-bytes-at-nil-cannot-allocate-memory-youre-not-alone/6259/9 [3] https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/releases/6.1.30/maple_tree-make-maple-state-reusable-after-mas_empty_area.patch?id=5e2b871e17ca1d2f1f88c4dc6b6995b72e5fc8f2
Bug#1031765: ganeti-testsuite: autopkgtest failure with procps 2:4.0.3-1
control: reassign -1 procps 2:4.0.3-1
control: retitle -1 pgrep: signal handler matching breaks argument parsing
thanks
Hi Adrian,
Thanks for the report!
On 11:07 Wed 22 Feb , Adrian Bunk wrote:
>
> # Check with a single, known unused user-id
> #
> # We use "-1" here, which is not a valid user-id, so it's
> # guaranteed that it's unused.
> uid = uidpool.RequestUnusedUid(set([-1]))
> self.assertEqualValues(uid.GetUid(), -1)
>
>
> "pgrep -u -1" is now rejected by procps.
This is a (presumably) unintentional side effect of procps commit
866abacf ("pgrep: Support matching on the presence of a userspace signal
handler")[1], which added the same "-" argument of pkill to pgrep.
With this change, pgrep parses the numerical options in the same way as pkill:
it uses getopt_long() for most options, but it performs a manual argv
scan[2] specifically to find signal-like options (e.g. -1, -88, -kill,
etc.).
The result is that anything that looks like a signal option, but is
passed as an argument to any of the other options, is removed early on
from the argument list, causing a subsequent call to getopt_long() to
fail if the original option takes a mandatory argument:
$ pgrep -u -93
pgrep: option requires an argument -- 'u'
...
$ pgrep -d -2
pgrep: option requires an argument -- 'd'
...
$ pgrep -u -hup
pgrep: option requires an argument -- 'u'
...
We could probably question the usefulness of negative UID/PID/SIDs
here, on the other hand this had been working for at least 15 years
before breaking in a minor release. I'm reassigning this bug to procps
for further discussion.
Cheers,
Apollon
[1]
https://gitlab.com/procps-ng/procps/-/commit/866abacf8805a74fb7c59cae1f64963e0a540b14
[2]
https://gitlab.com/procps-ng/procps/-/blob/806eb270f217ff7e1e745c7bda2b002b5be74be4/src/pgrep.c#L798
Bug#1013755: bullseye-pu: package ganeti/3.0.2-1~deb11u1
Hi Adam, On 22:23 Wed 29 Jun , Adam D. Barratt wrote: > > Apart from upstream fixes, this p-u also includes fixes for Debian > > bugs #993559 and #140 affecting Debian packaging, as well as the > > removal of an unnecessary dependency on bridge-utils. Note that I > > might revert the latter for the stable update to avoid breaking any > > custom scripts (e.g. hooks) that still rely on brctl mid-release. > > Hmm, that does sound like it might be safest. > > Please go ahead; thanks. Thank you for the fast review! Uploaded to bullseye with the following interdiff: diff -u ganeti-3.0.2/debian/changelog ganeti-3.0.2/debian/changelog --- ganeti-3.0.2/debian/changelog 2022-06-25 13:48:16.0 +0300 +++ ganeti-3.0.2/debian/changelog 2022-06-30 10:24:43.0 +0300 @@ -1,8 +1,10 @@ ganeti (3.0.2-1~deb11u1) bullseye; urgency=medium * Rebuild for bullseye. + * Restore the dependency on bridge-utils to ensure that a stable update will +not break any user scripts that might depend on brctl. - -- Apollon Oikonomopoulos Sat, 25 Jun 2022 13:48:16 +0300 + -- Apollon Oikonomopoulos Thu, 30 Jun 2022 10:24:43 +0300 ganeti (3.0.2-1) unstable; urgency=medium diff -u ganeti-3.0.2/debian/control ganeti-3.0.2/debian/control --- ganeti-3.0.2/debian/control 2022-06-25 13:48:16.0 +0300 +++ ganeti-3.0.2/debian/control 2022-06-30 10:24:43.0 +0300 @@ -96,6 +96,7 @@ lvm2, openssh-client, openssh-server, + bridge-utils, iproute2, iputils-arping, libcap2-bin, diff -u ganeti-3.0.2/debian/control.in ganeti-3.0.2/debian/control.in --- ganeti-3.0.2/debian/control.in 2022-06-25 13:46:01.0 +0300 +++ ganeti-3.0.2/debian/control.in 2022-06-30 10:23:33.0 +0300 @@ -96,6 +96,7 @@ lvm2, openssh-client, openssh-server, + bridge-utils, iproute2, iputils-arping, libcap2-bin, Regards, Apollon signature.asc Description: PGP signature
Bug#1013755: bullseye-pu: package ganeti/3.0.2-1~deb11u1
,10 +76,11 @@ _SHEBANG = re.compile(r"^#(?:|!(?:/usr/bin/python3?(?:| -u)|/bin/(?:|ba)sh))$") -_COPYRIGHT_YEAR = r"20[01][0-9]" -_COPYRIGHT = re.compile(r"# Copyright \(C\) (%s(?:, %s)*) Google Inc\.$" % +_COPYRIGHT_YEAR = r"20[012][0-9]" +_COPYRIGHT = re.compile(r"# Copyright \(C\) (%s(?:, %s)*) " + "(Google Inc\.|the Ganeti project)$" % (_COPYRIGHT_YEAR, _COPYRIGHT_YEAR)) -_COPYRIGHT_DESC = "Copyright (C) [, ...] Google Inc." +_COPYRIGHT_DESC = "Copyright (C) [, ...] the Ganeti project" _AUTOGEN = "# This file is automatically generated, do not edit!" diff -Nru ganeti-3.0.1/cabal/ganeti.template.cabal ganeti-3.0.2/cabal/ganeti.template.cabal --- ganeti-3.0.1/cabal/ganeti.template.cabal2021-02-03 10:24:16.0 +0200 +++ ganeti-3.0.2/cabal/ganeti.template.cabal2022-02-28 22:51:21.0 +0200 @@ -64,7 +64,7 @@ , utf8-string >= 0.3.7 , attoparsec>= 0.10.1.1 && < 0.14 -, base64-bytestring >= 1.0.0.1&& < 1.1 +, base64-bytestring >= 1.0.0.1&& < 1.2 , case-insensitive >= 0.4.0.1&& < 1.3 , curl >= 1.3.7 && < 1.4 , hinotify >= 0.3.2 && < 0.5 @@ -95,7 +95,7 @@ if flag(htest) build-depends: HUnit >= 1.2.4.2&& < 1.7 - , QuickCheck>= 2.8&& < 2.14 + , QuickCheck>= 2.8&& < 2.15 , test-framework>= 0.6&& < 0.9 , test-framework-hunit >= 0.2.7 && < 0.4 , test-framework-quickcheck2>= 0.2.12.1 && < 0.4 diff -Nru ganeti-3.0.1/configure.ac ganeti-3.0.2/configure.ac --- ganeti-3.0.1/configure.ac 2021-02-03 10:24:16.0 +0200 +++ ganeti-3.0.2/configure.ac 2022-02-28 22:51:21.0 +0200 @@ -1,7 +1,7 @@ # Configure script for Ganeti m4_define([gnt_version_major], [3]) m4_define([gnt_version_minor], [0]) -m4_define([gnt_version_revision], [1]) +m4_define([gnt_version_revision], [2]) m4_define([gnt_version_suffix], []) m4_define([gnt_version_full], m4_format([%d.%d.%d%s], diff -Nru ganeti-3.0.1/debian/changelog ganeti-3.0.2/debian/changelog --- ganeti-3.0.1/debian/changelog 2021-03-02 15:13:17.0 +0200 +++ ganeti-3.0.2/debian/changelog 2022-06-25 13:48:16.0 +0300 @@ -1,3 +1,36 @@ +ganeti (3.0.2-1~deb11u1) bullseye; urgency=medium + + * Rebuild for bullseye. + + -- Apollon Oikonomopoulos Sat, 25 Jun 2022 13:48:16 +0300 + +ganeti (3.0.2-1) unstable; urgency=medium + + * New upstream release (closes: #1006003, #993920) + * Drop patches merged upstream + * d/copyright: adjust years and upstream copyright info + + -- Apollon Oikonomopoulos Sat, 12 Mar 2022 23:23:27 +0200 + +ganeti (3.0.1-4) unstable; urgency=medium + + * Drop ganeti-3.0's dependency on bridge-utils (Ganeti 3.0 uses iproute2). + + -- Apollon Oikonomopoulos Mon, 31 Jan 2022 08:14:57 +0200 + +ganeti (3.0.1-3) unstable; urgency=medium + + * postrm: remove diversion only on package removal (Closes: #993559) +* Restore the diversion on postinst in case it was accidentally removed + due to #993559. + * Fix FTBFS by removing duplicate index entry. +Thanks to Marius Bakke (Closes: #997053) + * d/control: remove unnecessary B-D on libpcre3-dev (Closes: #140) + * Fix FTBFS with sphinx >= 2.1. +Thanks to Sascha Lucas + + -- Apollon Oikonomopoulos Thu, 16 Dec 2021 14:22:41 +0200 + ganeti (3.0.1-2) unstable; urgency=medium * Ignore signatures while creating LVs (Closes: #982960) diff -Nru ganeti-3.0.1/debian/control ganeti-3.0.2/debian/control --- ganeti-3.0.1/debian/control 2021-03-02 14:42:23.0 +0200 +++ ganeti-3.0.2/debian/control 2022-06-25 13:48:16.0 +0300 @@ -36,7 +36,6 @@ libghc-test-framework-hunit-dev, libghc-temporary-dev, libghc-old-time-dev, - libpcre3-dev, libcurl4-openssl-dev, python3-simplejson, python3-pyparsing, @@ -97,7 +96,6 @@ lvm2, openssh-client, openssh-server, - bridge-utils, iproute2, iputils-arping, libcap2-bin, diff -Nru ganeti-3.0.1/debian/control.in ganeti-3.0.2/debian/control.in --- ganeti-3.0.1/debian/control.in 2021-03-02 14:40:51.0 +0200 +++ ganeti-3.0.2/debian/control.in 2022-06-25 13:46:01.0 +0300 @@ -36,7 +36,6 @@ libghc-test-framework-hunit-dev, libghc-temporary-dev, libghc-old-time-dev, - libpcre3-dev, libcurl4-openssl-dev, python3-simplejson, python3-pyparsing, @@ -97,7 +96,6 @@ lvm2, openssh-client, openssh-server, - bridge-utils, iproute2, iputils-arping, libcap2-bin, diff -Nru gan
Bug#1005806: gtk2hs-buildtools: gtk2hsC2hs fails with code preprocessed by GCC-11
Package: gtk2hs-buildtools Version: 0.13.8.0-1 Severity: serious Tags: upstream fixed-upstream Justification: Other packages FTBFS Control: block 1005657 by -1 Control: block 1005676 by -1 gtk2hsC2hs fails when fed with code preprocessed by GCC-11, as it doesn't expect zeros in line numbers. This is similar to #984167 and has been fixed upstream in https://github.com/gtk2hs/gtk2hs/pull/304. Regards, Apollon
Bug#984167: Possibly fixed upstream
Control: tags -1 pending Verified this and the fix, pending upload. Also, I should have read the instructions better and add a blocking bug rather than reassign/merge. Apologies for the inconvenience doko and company, I'll do verification builds myself and I promise I'll be more careful next time :-) Regards, Apollon
Bug#984167: Possibly fixed upstream
Control: reassign -1 c2hs Control: retitle -1 c2hs fails with code preprocessed by gcc-11 Control: found -1 0.28.6-1 Control: tags -1 upstream fixed-upstream Control: forwarded -1 https://github.com/haskell/c2hs/issues/268 Hi Rob, On 15:57 Fri 03 Dec , Rob Moss wrote: > I believe this is caused by a specific c2hs issue > (https://github.com/haskell/c2hs/issues/268) which has been fixed in > c2hs 0.28.8. Thanks for bringing this up, indeed it looks like a valid issue. I'm reassigning to c2hs and tagging accordingly. It also looks like this issue has been reported against multiple Haskell packages, I will proceed to merge all bugs under this one. Cheers, Apollon
Bug#987907: ganeti: fails to upgrade from buster: ganeti-2.16 is still needed, but scheduled for removal
Andreas Beckmann writes: > On 20/05/2021 11.07, Julien Cristau wrote: >> Do we know what specifically causes old python to be removed? > > buster: > > Package: python > Source: python-defaults > Version: 2.7.16-1 > Depends: python2.7 (>= 2.7.16-1~), libpython-stdlib (= 2.7.16-1), python2 (= > 2.7.16-1) > Pre-Depends: python-minimal (= 2.7.16-1) > > bullseye: > > Package: python2 > Source: python-defaults > Version: 2.7.18-2 > Depends: python2.7 (>= 2.7.18~), libpython2-stdlib (= 2.7.18-2) > Pre-Depends: python2-minimal (= 2.7.18-2) > > ==> python/buster is not co-installable with python2/bullseye > ==> python/buster must be removed to upgrade python2 > > Package: python2.7 > Version: 2.7.18-7 > Depends: python2.7-minimal (= 2.7.18-7), libpython2.7-stdlib (= 2.7.18-7), > mime-support > Breaks: libpython-stdlib (<< 2.7.18), python (<< 2.7.18), python-minimal (<< > 2.7.18), python-virtualenv (<< 1.7.1.2-2~), vim-athena (<< 2:7.3.547-4), > vim-gnome (<< 2:7.3.547-4), vim-gtk (<< 2:7.3.547-4), vim-nox (<< 2:7.3.547-4) > > The explicit versioned Breaks in python2.7 against unversioned > python packages are there to help apt making the right decision: > remove unversioned python and upgrade python2 to bullseye > (otherwise it would try to not upgrade python2/buster in order > to keep python/buster installed in quite a bunch of upgrade > scenarios) > > @apollon: > Would it be possible to build ganeti-2.16 in bullseye (with > reduced dependencies?) s.t. it depends on python2 instead of > python? Then it could be reintroduced into bullseye like buster > had ganeti-2.15 in addition to ganeti (2.16). It would be possible, but that would also have to be done for at least python-simplejson, python-fdsend and possibly others. To be honest, I'd much prefer promoting upgrades via buster-backports for Ganeti, it's much more straightforward. Regards, Apollon
Bug#987907: ganeti: fails to upgrade from buster: ganeti-2.16 is still needed, but scheduled for removal
Apollon Oikonomopoulos writes: > Hi Julien, > > Julien Cristau writes: > >> On Thu, May 20, 2021 at 11:28:12AM +0300, Apollon Oikonomopoulos wrote: >>> Control: severity -1 important >>> Control: tags -1 wontfix >>> >>> Hi Andreas >>> >>> Thanks for the report. >>> >>> Andreas Beckmann writes: >>> >>> > Package: ganeti >>> > Version: 3.0.1-2 >>> > Severity: serious >>> > User: debian...@lists.debian.org >>> > Usertags: piuparts >>> > >>> > Hi, >>> > >>> > during a test with piuparts I noticed your package fails to upgrade from >>> > 'buster'. >>> > It installed fine in 'buster', then the upgrade to 'bullseye' fails. >>> > >>> > In order to run 'gnt-cluster upgrade' both ganeti-3.0 and ganeti-2.16 >>> > need to be installed, but the package from buster needs to be removed >>> > due to the removal of unversioned python and the Python 2 modules >>> > (python-*) before the local admin could run 'gnt-cluster upgrade' >>> > >>> > I'm not sure how a clean upgrade is intended to be performed in this >>> > case. This may also be an interesting question for DSA. >>> >>> Yes, the removal of unversioned python makes things more complicated. I >>> was hoping that ganeti-2.16's dependencies would be enough to keep the >>> Python 2 modules around until gnt-cluster upgrade could run. >>> >> Do we know what specifically causes old python to be removed? >> > > Broken python2.7:amd64 Breaks on libpython-stdlib:amd64 < 2.7.16-1 @ii mK > Ib > (< > 2.7.18) > Considering libpython-stdlib:amd64 11 as a solution to python2.7:amd64 23 > Added libpython-stdlib:amd64 to the remove list > Broken python2.7:amd64 Breaks on python:amd64 < 2.7.16-1 @ii mK Ib > (< > 2.7.18) > Considering python:amd64 15 as a solution to python2.7:amd64 23 > Added python:amd64 to the remove list > Broken python2.7:amd64 Breaks on python-minimal:amd64 < 2.7.16-1 @ii mK Ib > > (< 2.7.18) > Considering python-minimal:amd64 11 as a solution to python2.7:amd64 23 > Added python-minimal:amd64 to the remove list > Fixing python2.7:amd64 via remove of libpython-stdlib:amd64 > Fixing python2.7:amd64 via remove of python:amd64 > Fixing python2.7:amd64 via remove of python-minimal:amd64 > > python2.7 in Bullseye explicitly Breaks: python (<< 2.7.18), > python-minimal (<< 2.7.18). This causes the removal of all packages that > Depend on python (including ganeti-2.16, python-simplejson etc). This was added in python2.7 (2.7.18-7) unstable; urgency=medium [ Andreas Beckmann ] * python2.7, libpython2.7-minimal: Add Breaks: python (<< 2.7.18) to ensure removal of the unversioned python packages on upgrades from buster. The previously added (transitive) Breaks are not sufficient in a few upgrade scenarios. Closes: #987661. -- Matthias Klose Wed, 28 Apr 2021 19:39:59 +0200 I admit I'm not aware of what we are trying to achieve here, but this approach might be a bit too aggressive, as it requires that you have to fix e.g. all locally-built packages depending on unversioned python *before* upgrading to bullseye. I wonder if transitional packages would work better for bullseye (but I guess it's a bit too late for that). Regards, Apollon
Bug#987907: ganeti: fails to upgrade from buster: ganeti-2.16 is still needed, but scheduled for removal
Hi Julien, Julien Cristau writes: > On Thu, May 20, 2021 at 11:28:12AM +0300, Apollon Oikonomopoulos wrote: >> Control: severity -1 important >> Control: tags -1 wontfix >> >> Hi Andreas >> >> Thanks for the report. >> >> Andreas Beckmann writes: >> >> > Package: ganeti >> > Version: 3.0.1-2 >> > Severity: serious >> > User: debian...@lists.debian.org >> > Usertags: piuparts >> > >> > Hi, >> > >> > during a test with piuparts I noticed your package fails to upgrade from >> > 'buster'. >> > It installed fine in 'buster', then the upgrade to 'bullseye' fails. >> > >> > In order to run 'gnt-cluster upgrade' both ganeti-3.0 and ganeti-2.16 >> > need to be installed, but the package from buster needs to be removed >> > due to the removal of unversioned python and the Python 2 modules >> > (python-*) before the local admin could run 'gnt-cluster upgrade' >> > >> > I'm not sure how a clean upgrade is intended to be performed in this >> > case. This may also be an interesting question for DSA. >> >> Yes, the removal of unversioned python makes things more complicated. I >> was hoping that ganeti-2.16's dependencies would be enough to keep the >> Python 2 modules around until gnt-cluster upgrade could run. >> > Do we know what specifically causes old python to be removed? > Broken python2.7:amd64 Breaks on libpython-stdlib:amd64 < 2.7.16-1 @ii mK Ib > (< 2.7.18) Considering libpython-stdlib:amd64 11 as a solution to python2.7:amd64 23 Added libpython-stdlib:amd64 to the remove list Broken python2.7:amd64 Breaks on python:amd64 < 2.7.16-1 @ii mK Ib > (< 2.7.18) Considering python:amd64 15 as a solution to python2.7:amd64 23 Added python:amd64 to the remove list Broken python2.7:amd64 Breaks on python-minimal:amd64 < 2.7.16-1 @ii mK Ib > (< 2.7.18) Considering python-minimal:amd64 11 as a solution to python2.7:amd64 23 Added python-minimal:amd64 to the remove list Fixing python2.7:amd64 via remove of libpython-stdlib:amd64 Fixing python2.7:amd64 via remove of python:amd64 Fixing python2.7:amd64 via remove of python-minimal:amd64 python2.7 in Bullseye explicitly Breaks: python (<< 2.7.18), python-minimal (<< 2.7.18). This causes the removal of all packages that Depend on python (including ganeti-2.16, python-simplejson etc). Cheers, Apollon
Bug#987907: ganeti: fails to upgrade from buster: ganeti-2.16 is still needed, but scheduled for removal
Control: severity -1 important Control: tags -1 wontfix Hi Andreas Thanks for the report. Andreas Beckmann writes: > Package: ganeti > Version: 3.0.1-2 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'buster'. > It installed fine in 'buster', then the upgrade to 'bullseye' fails. > > In order to run 'gnt-cluster upgrade' both ganeti-3.0 and ganeti-2.16 > need to be installed, but the package from buster needs to be removed > due to the removal of unversioned python and the Python 2 modules > (python-*) before the local admin could run 'gnt-cluster upgrade' > > I'm not sure how a clean upgrade is intended to be performed in this > case. This may also be an interesting question for DSA. Yes, the removal of unversioned python makes things more complicated. I was hoping that ganeti-2.16's dependencies would be enough to keep the Python 2 modules around until gnt-cluster upgrade could run. That said, I think the best way forward is to upgrade buster clusters to 3.0 using the packages from buster-backports, before attempting to dist-upgrade to bullseye. This should probably be documented in the release notes. Since there's really not much else we can do about it now, I'm downgrading to important and tagging it as wontfix. Please let me know what you think. Regards, Apollon > > From the attached log (scroll to the bottom...): > > The following packages were automatically installed and are no longer > required: > ganeti-haskell-2.16 ganeti-htools-2.16 libprocps7 libpython2-stdlib > libpython2.7-minimal libpython2.7-stdlib libreadline5 libreadline7 > python-six python2 python2-minimal python2.7 python2.7-minimal > Use 'sudo apt autoremove' to remove them. > The following packages will be REMOVED: > ganeti-2.16 libpython-stdlib python python-asn1crypto python-bcrypt > python-bitarray python-cffi-backend python-cryptography python-enum34 > python-fdsend python-ipaddr python-ipaddress python-minimal python-nacl > python-openssl python-paramiko python-psutil python-pyasn1 python-pycurl > python-pyinotify python-pyparsing python-simplejson > The following NEW packages will be installed: > ganeti-3.0 ganeti-haskell-3.0 ganeti-htools-3.0 gcc-10-base libapt-pkg6.0 > libbpf0 libbrotli1 libcbor0 libcrypt1 libffi7 libfido2-1 libgcc-s1 > libgdbm-compat4 libgdbm6 libhogweed6 libmd0 libmpdec3 libnettle8 libnsl2 > libpcre2-8-0 libperl5.32 libprocps8 libpython3-stdlib libpython3.9-minimal > libpython3.9-stdlib libreadline8 libtirpc-common libtirpc3 libxxhash0 > logsave mailcap media-types perl perl-modules-5.32 python3 python3-bcrypt > python3-bitarray python3-cffi-backend python3-cryptography python3-minimal > python3-nacl python3-openssl python3-paramiko python3-psutil > python3-pycurl > python3-pyinotify python3-pyparsing python3-simplejson python3-six > python3.9 > python3.9-minimal runit-helper tzdata > The following packages will be upgraded: > [...] > 135 upgraded, 53 newly installed, 22 to remove and 0 not upgraded. > [...] > Selecting previously unselected package ganeti-3.0. > Preparing to unpack .../44-ganeti-3.0_3.0.1-2_all.deb ... > Adding 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to > /usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0' > Unpacking ganeti-3.0 (3.0.1-2) ... > Preparing to unpack .../45-libcurl4_7.74.0-1.2_amd64.deb ... > Unpacking libcurl4:amd64 (7.74.0-1.2) over (7.64.0-4+deb10u2) ... > Preparing to unpack .../46-libpcre3_2%3a8.39-13_amd64.deb ... > Unpacking libpcre3:amd64 (2:8.39-13) over (2:8.39-12) ... > Setting up libpcre3:amd64 (2:8.39-13) ... > Selecting previously unselected package ganeti-haskell-3.0. > Preparing to unpack .../ganeti-haskell-3.0_3.0.1-2_amd64.deb ... > Unpacking ganeti-haskell-3.0 (3.0.1-2) ... > Selecting previously unselected package ganeti-htools-3.0. > Preparing to unpack .../ganeti-htools-3.0_3.0.1-2_amd64.deb ... > Unpacking ganeti-htools-3.0 (3.0.1-2) ... > Preparing to unpack .../ganeti_3.0.1-2_all.deb ... > Unpacking ganeti (3.0.1-2) over (2.16.0-5) ... > Removing ganeti-2.16 (2.16.0-5) ... > dpkg: error processing package ganeti-2.16 (--remove): >installed ganeti-2.16 package pre-removal script subprocess returned error > exit status 30 > dpkg: python-simplejson: dependency problems, but removing anyway as you > requested: >ganeti-2.16 depends on python-simplejson. > > Removing python-simplejson (3.16.0-1) ... > dpkg: python-fdsend: dependency problems, but removing anyway as you > requested: >ganeti-2.16 depends on python-fdsend. > > Removing python-fdsend (0.2.1-2) ... > dpkg: python-paramiko: dependency problems, but removing anyway as you > requested: >ganeti-2.16 depends on python-paramiko. > > Removing python-paramiko (2.4.2-0.1) ... >
Bug#958898: (no subject)
control: unarchive -1 control: found -1 1:2.0.10-1 Hi, This bug affects stable but the original message didn't specify the epoch in the Version: pseudo-header so it falsely appears as not affecting stable. I'm unarchiving and tagging this explicitly as found in Buster's 1:2.0.10-1. Additionally I confirm that upstream commit fccdeba mentioned by the original reporter fixes the issue; I believe this is a good candidate for a stable update, please consider preparing one (I can help if you lack time). Regards, Apollon
Bug#969028: ganeti: migration_caps break migration
control: tags -1 upstream Hi Joerg! Joerg Jaspert writes: > Source: ganeti > Version: 2.16.0-5 > Severity: important > > Dear Maintainer, > > using Ganeti 2.16 and qemu 1:5.0-14~bpo10+1 I tried setting > migration_caps for the cluster. But no matter which value i use it > breaks migration. > > Migration then "goes" > - Setup disks and prepare target node > - starting memore transfer > - "Migration failed, aborting" > - Closing disks > > That is entirely independent on which value I put into the caps. > > Unsetting migration_caps and retrying the migration - it fails again. > > Looking more in detail it appears that its setting the caps on the > source side. But possibly forgets to set them on the target side so qemu > hates doing migration?! > > And when it breaks, it forgets to unset the capabilities, so next > migrations break too. One has to manually connect to the monitor and > unset them, before migration works again. Thanks for the report. I'm trying to figure out whether this is a change in the behavior of recent QEMU versions. Did you do any successful migrations with migration_caps set on previous QEMU versions? Cheers, Apollon
Bug#962692: [Pkg-puppet-devel] Bug#962692: puppet: Crashes due to "missing" facts.d directories
Control: reassign -1 facter Control: merge -1 962784 Hi and thanks for the report! Wilmer van der Gaast writes: > Package: puppet > Version: 5.5.19-1 > Severity: grave > Justification: renders package unusable > > > Since the recent Ruby upgrade, Puppet invocations have been very noisy for a > while already. > > But by now it's not even starting. Even after a dpkg -P including most > dependencies (including apt-get remove ruby.*) then reinstalling, all I > get is: > > wilmer@veer:~/adsb$ sudo puppet agent --waitforcert 60 -t > /usr/lib/ruby/vendor_ruby/puppet/util.rb:461: warning: URI.escape is > obsolete > /usr/lib/ruby/vendor_ruby/puppet/file_system/file_impl.rb:80: warning: Using > the last argument as keyword parameters is deprecated > free(): invalid pointer > Aborted > This is a facter issue, as outlined in #962784. I'm reassigning this bug to facter and merging with #962784. Regards, Apollon
Bug#945931: haskell-crypto: Removal notice: broken and unmaintained
Control: affects -1 - ganeti Hey, On 13:04 Sun 01 Dec , Ilias Tsitsimpis wrote: > Source: haskell-crypto > Version: 4.2.5.1-9 > Severity: grave > Justification: renders package unusable > > This package is no longer maintained (last upstream upload in 2012). It > is also broken with GHC 8.6.4 and unlikely to ever be fixed (see [1]). > > I intend to remove this package once ganeti has been updated to use > cryptonite instead (see [2]). Ganeti has been ported[3] to cryptonite, you can safely remove haskell-crypto. Thanks for keeping the Haskell ecosystem in Debian healthy :) [3] https://salsa.debian.org/ganeti-team/ganeti/commit/8f8a95bea4661153380a75908038768b0af50594 Cheers, Apollon
Bug#931545: addition
Control: severity -1 normal Control: tags -1 wontfix Hi, On 15:03 Sun 07 Jul , Michael Becker wrote: > forgot to mention: dovecot runs in an LXC container Apologies for the late response. For posterity, this error is because systemd inside LXC cannot create additional namespaces under Debian's default configuration. Dovecot's systemd unit uses some hardening features which rely on systemd namespace support. There are 3 possible workarounds for this: - Try enabling unprivileged userns cloning in the host kernel, by setting the kernel.unprivileged_userns_clone sysctl to 1. This is probably the least intrusive option, but I'm not 100% it will work. - Override and unset ProtectSystem, PrivateDevices and PrivateTmp in the systemd unit (preferrably using an override in /etc/systemd/dovecot.service.d). Note however that this will disable the last line of defense for a service running as root (but that's also what you get when you run under sysvinit). - Change your LXC container to a privileged one, which kinda beats the purpose. Cheers, Apollon
Bug#935880: RM: ganeti-2.15 -- ROM; Required only for upgrades to Buster
Package: ftp.debian.org Severity: normal Dear FTP Masters, Please remove the ganeti-2.15 source package and its resulting binary packages from unstable. ganeti-2.15 was provided to assist upgrades from Stretch to Buster because of #905176 and it's not required anymore. Regards, Apollon
Bug#934398: RM: beanstalkc -- ROM; no Python 3 subpackage and no reverse deps
Hi Ondrej,
On 07:49 Mon 12 Aug , Ondrej Novy wrote:
> Hi,
>
> first of all I would like to say thanks to Andrey. He is hard working to
> remove Python 2 from Debian. It's not easy job.
Indeed, it's not an easy job, thanks for seeing to it.
>
> ne 11. 8. 2019 v 9:24 odesílatel Apollon Oikonomopoulos
> napsal:
>
> > While I understand the urge to get Python 2 out of bullseye as early as
> > possible, I don't feel happy about how this particular case was handled,
> > and I notice that it is not in agreement with what was posted on
> > debian-python[1].
> >
>
> it was. Cite:
>
> DPMT / PAPT
> ===
> No need to wait for a bug report. If you have a leaf package, remove it now.
>
> If you're not a DD, do it in the git repo and ping Piotr.
>
> beanstalkc was team leaf package without reverse {build-,}depends.
I never asked why you thought beanstalkc should be removed, I asked why
you removed it *without letting me know in advance*. beanstalkc had a
perfectly good reason to be in the archive, which the team couldn't know
of without parsing the whole source archive and which thus didn't take
into account.
Cc'ing the uploaders would have taken less than 5 seconds. Figuring out
what happened, writing two follow-up e-mails and filing the ITP took me
more than an hour, and this is what I'm complaining about. Pardon me,
but team maintenance is no excuse for poor communication.
> - X-Debbugs-Cc beansta...@packages.debian.org at bug report time,
> >as finding out at the time of *removal* is arguably too late.
> >
>
> yes, this make sense.
I saw that the next round of removals was Cc'd, so thanks for that.
Regards,
Apollon
Bug#934884: ITP: beanstalkc -- simple beanstalkd client library for Python
Package: wnpp Severity: wishlist Owner: Apollon Oikonomopoulos * Package name: beanstalkc Version : 0.4.0 Upstream Author : Andreas Bolka * URL : http://www.example.org/ * License : Apache-2.0 Programming Lang: Python Description : simple beanstalkd client library for Python beanstalkc is a simple beanstalkd client library for Python. beanstalkd is a fast, distributed, in-memory workqueue service. Beanstalkc is written in pure Python and is compatible with eventlet and gevent. I am reintroducing beanstalkc to the archive as a Python 3 package, after its unfortunate removal by #934398.
Bug#934398: RM: beanstalkc -- ROM; no Python 3 subpackage and no reverse deps
[Cc-ing debian-python] Hi Andrey, On 21:53 Sat 10 Aug , Andrey Rahmatullin wrote: > Package: ftp.debian.org > Severity: normal > > The code seems to support Python 3 but there is no subpackage. > > Reverse deps checked by dak rm -Rnb python-beanstalkc beanstalkc is used by beanstalkd's DEP-8 tests, which as a consequence have just been broken. The fact that dak doesn't care about autopkgtests makes `dak rm -Rnb` especially tricky and we shouldn't rely on just that to get an idea whether a package can be safely removed or not. It would be nice if dak had a notion of "Test-Depends" of course, but I don't think this information exists in the archive's metadata currently. While I understand the urge to get Python 2 out of bullseye as early as possible, I don't feel happy about how this particular case was handled, and I notice that it is not in agreement with what was posted on debian-python[1]. In all honesty and leaving [1] aside, I would very much have preferred if you had done one of the following instead: - Open an RC bug on the package to add Python-3 support in the first place, which would have given me more time to react and at least spare me writing this e-mail and filing for an ITP in the middle of August - X-Debbugs-Cc beansta...@packages.debian.org at bug report time, as finding out at the time of *removal* is arguably too late. Please keep these in mind before filing for future removals. Regards, Apollon [1] https://lists.debian.org/debian-python/2019/07/msg00080.html
Bug#932335: buster-pu: package facter/3.11.0-2+deb10u1
On 16:20 Fri 26 Jul , Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On 2019-07-17 18:45, Apollon Oikonomopoulos wrote: > > I would like to update facter in Buster to fix #918250, whereby facter > > fails to parse routes with the `onlink' flag, producing a lot of noise > > in the process and possibly acquiring a distorted view of the network. > > ifupdown adds the `onlink' flag to gateway routes by default, so this > > tends to affect a lot of systems. > > > > The issue has been fixed upstream, and backporting the fix is trivial — > > in fact I have already uploaded a fixed version in unstable. Full source > > debdiff against buster attached. > > Please go ahead; thanks. > > Regards, Uploaded, thanks! Apollon
Bug#924920: [Pkg-puppet-devel] Bug#924920: facter: augeas-tools missing from Recommends directive
Control: reassign -1 puppet Control: priority -1 wishlist Hi John, On 13:17 Mon 18 Mar , John Bond wrote: > Package: facter > Version: 3.11.0-1.1+b1 > Severity: normal > > Dear Maintainer, > > `augparse`, which is provided by `augeas-tools`, is required by `facter` to > resolve the `augeasversion` fact[1]. If augparse is not present facter > returns an empty string and exits cleanly. please consider adding the > following Thanks for the report! While I do understand your frustration, I don't think it is appropriate to add augeas-tools to facter's Recommends; I simply don't think it's the right place to solve this issue. Having facter Recommend: augeas-tools just to get a fact resolved by default is like Recommend'ing zfs-dkms to get the zfs facts resolved by default. Facter is there just to tell you what your system looks like and we shouldn't configure our systems around facter to get every possible fact supported. That said, I admit that most of the times, facter co-exists with puppet and puppet has already pulled in most of augeas, although not augeas-tools. I think it's possible to include augeas-tools in puppet's Recommends instead, which should do what you want, what do you think? Regards, Apollon
Bug#932335: buster-pu: package facter/3.11.0-2+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear SRMs,
I would like to update facter in Buster to fix #918250, whereby facter
fails to parse routes with the `onlink' flag, producing a lot of noise
in the process and possibly acquiring a distorted view of the network.
ifupdown adds the `onlink' flag to gateway routes by default, so this
tends to affect a lot of systems.
The issue has been fixed upstream, and backporting the fix is trivial —
in fact I have already uploaded a fixed version in unstable. Full source
debdiff against buster attached.
Regards,
Apollon
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog 2019-04-02 08:24:17.0 -0300
+++ facter-3.11.0/debian/changelog 2019-07-17 17:04:05.0 -0300
@@ -1,3 +1,9 @@
+facter (3.11.0-2+deb10u1) buster; urgency=medium
+
+ * Fix parsing of Linux route non-kv flags (e.g. onlink) (Closes: #918250)
+
+ -- Apollon Oikonomopoulos Wed, 17 Jul 2019 17:04:05
-0300
+
facter (3.11.0-2) unstable; urgency=medium
* Acknowledge 3.11.0-1.1 NMU. Thanks to gregor herrmann!
diff -Nru
facter-3.11.0/debian/patches/0006-FACT-1916-fix-route-parsing-on-Linux.patch
facter-3.11.0/debian/patches/0006-FACT-1916-fix-route-parsing-on-Linux.patch
---
facter-3.11.0/debian/patches/0006-FACT-1916-fix-route-parsing-on-Linux.patch
1969-12-31 21:00:00.0 -0300
+++
facter-3.11.0/debian/patches/0006-FACT-1916-fix-route-parsing-on-Linux.patch
2019-07-17 17:03:15.0 -0300
@@ -0,0 +1,101 @@
+From: John Bond
+Date: Thu, 2 May 2019 14:48:44 +0100
+Subject: (FACT-1916): fix route parsing on Linux
+
+This PR removes the assumption that a every all values in the out put of
+ip route show includes key value pairs. !1283 first introduced this
+assumption fixing. This PR also removes the patch for FACT-1405 introduced
+in !1372 as it is no longer needed. one could further remove the code
+from !1464 to address FACT-1394 as that seems to be cause by the same
+issue, however i have left that in as one dosen't need to parse linkdown
+routes.
+
+Currently the none cases of values which are not key value pairs are
+ * flags: linkdown, pervasive, onlink
+ * params with optional values: mtu [lock] value
+
+ We could add something like the following to the loop at
+https://github.com/puppetlabs/facter/blob/master/lib/src/facts/linux/networking_resolver.cc#L198
+however this may be overkill as the flags and mtuy alwasy come after the
+dev and src paramaters.
+
+```c++
+unordered_set route_flags {
+ "linkdown",
+ "pervasive",
+ "onlink"
+}
+size_t step = 2;
+for (size_t i = dst_idx+1; i < parts.size(); i += step) {
+std::string key(parts[i].begin(), parts[i].end());
+std::string value(parts[i+1].begin(), parts[i+1].end());
+step = 2;
+if route_flags.find(key) {
+ step = 1;
+ continue;
+} else if (key == "mtu" and value == "lock"){
+ step = 3;
+ continue;
+}
+if (key == "dev") {
+r.interface.assign(value);
+}
+if (key == "src") {
+r.source.assign(value);
+}
+}
+```
+
+I also wonder if its worth always passing `-d` to `ip route show` to
+ensure the route_type is always included but i'm unsure if that flag is
+available on all linux
+
+(cherry picked from commit 6a391557d6a38f0e3c6f8d20ebb2f8d6ba916d18)
+Signed-off-by: Apollon Oikonomopoulos
+---
+ lib/src/facts/linux/networking_resolver.cc | 27 +++
+ 1 file changed, 7 insertions(+), 20 deletions(-)
+
+diff --git a/lib/src/facts/linux/networking_resolver.cc
b/lib/src/facts/linux/networking_resolver.cc
+index 6f247a3..a3db340 100644
+--- a/lib/src/facts/linux/networking_resolver.cc
b/lib/src/facts/linux/networking_resolver.cc
+@@ -150,31 +150,18 @@ namespace facter { namespace facts { namespace linux {
+ return true;
+ }
+
+-// remove trailing "onlink" or "pervasive" flags
+-while (parts.size() > 0) {
+-std::string last_token(parts.back().begin(),
parts.back().end());
+-if (last_token == "onlink" || last_token == "pervasive")
+-parts.pop_back();
+-else
+-break;
+-}
+-
+-size_t dst_idx = 0;
+-if (parts.size() % 2 == 0) {
+-std::string route_type(parts[0].begin(), parts[0].end());
+-if (known_route_types.find(route_type) ==
known_route_types.end()) {
+-LOG_WARNING("Could not process routing table entry:
Expected a destination followed by key/value pairs, got '{1}'", line);
+-return true;
+-} else {
+-dst_idx = 1;
+-}
++
Bug#913904: redsocks: Transparent proxy traffic no longer works on Debian Buster
Control: tags -1 unreproducible moreinfo Hi, On 14:06 Fri 16 Nov , Clauzio Cristiano Perpétuo wrote: > Package: redsocks > Version: 0.5-2 > Severity: normal > > Dear Maintainer, > > Transparent proxy traffic no longer works... > > The same configuration, as recommended in the official documentation, > worked on some previous updates. In the stable version (stretch) on the > same network, the traffic is ok. The iptables rules are the same as the > official documentation. > > I do not know if the problem is in the redsocks package, the kernel version > or the iptables version. Apologies for the late response. Unfortunately, I cannot reproduce this bug, as forwarding seems to work in my case. If I had to guess, I would probably say your issue is due to the iptables/nftables migration and you ended up having loaded both, iptables-legacy and iptables-nft rules, which leads to unpredictable behavior. Please let me know if you are still seeing this issue. Regards, Apollon
Bug#932135: [Pkg-puppet-devel] Bug#932135: puppetdb can't create/upgrade its DB schema past version 65 with postgres-11 11.4-1
Control: tags -1 confirmed upstream fixed-upstream Control: severity -1 important Control: clone -1 -2 Control: reassign -2 postgresql-11 Control: tags -2 upstream Control: found -2 11.4-1 Control: affects -2 puppetdb Control: severity -2 serious Control: forwarded -2 https://www.postgresql.org/message-id/15865-17940eacc8f8b081%40postgresql.org Control: retitle -2 ALTER TABLE statements causing "relation already exists" errors when some indexes exist Hi, On 13:46 Mon 15 Jul , Gabriel Filion wrote: > Hi there! > > I've hit a bug with a new installation of puppetdb on buster (e.g. I've > re-created my puppetmaster vagrant box) where puppetdb would fail to start, > erroring out on an SQL upgrade of the database schema during the first service > start. > > I'll include the error log lower down since it's pretty long. > > I've found a bug report on pupperware (puppet packaged up in docker > containers) > that describes exactly the same problem, identifies a faulty postgresql 9.6.x > version and seems to point to an upstream bug report that contains a fix. > > https://github.com/puppetlabs/pupperware/issues/82 > > Since in buster we're using postgresql-11, we've had to identify which version > had introduced the problem. I'm not sure about the exact minor version of > postgres, but for certain when downgrading the debian package to postgres-11 > version 11.3-1, then puppetdb is able to start and complete its schema > upgrade. > So the bug must have been introduced somewhere between 11.3 and 11.4 > > The upstream bug report says that there might be a fix for puppetdb available: > > https://tickets.puppetlabs.com/browse/PDB-4422 > > It might be interesting to test applying the fix from the most appropriate > branch (I'm not sure whether 6.0 or 6.3 makes more sense) and then test a new > install with postgresql-11 version 11.4-1 to see if it goes through the schema > upgrade successfully. Thanks for the report and detailed information! According to https://ci.debian.net/packages/p/puppetdb/testing/amd64/, PuppetDB broke with postgresql-common/202, however it's really postgresql-11 11.4 that broke things while fixing CVE-2019-10164[1]. I'm inclined to say "this is a PostgreSQL bug", but there's no clear resolution from the Postgres side yet. PuppetDB upstream has already fixed this and the patch is trivial, so I'll prepare an upload to unstable to make it work again. However, I won't be filing for a stable update yet; instead, let's clone this bug as a PostgreSQL one and see what the Postgres maintainers say. Cheers, Apollon [1] https://www.postgresql.org/message-id/15865-17940eacc8f8b081%40postgresql.org
Bug#820108: taskwarrior: truncated non-ASCII descriptions
Control: tags -1 patch
Control: forwarded -1
https://github.com/GothenburgBitFactory/taskwarrior/issues/1852
Hi,
On 16:29 Tue 05 Apr , Jakub Wilk wrote:
> Package: taskwarrior
> Version: 2.5.1+dfsg-1
>
> Taskwarrior to truncate non-ASCII descriptions for tasks that have
> annotations:
>
> $ task add 'Zażółć gęślą jaźń'
> Created task 1.
>
> $ task 1 info | grep ^Description
> Description Zażółć gęślą jaźń
>
> $ task 1 ann muu
> Annotating task 1 'Zażółć gęślą jaźń'.
> Annotated 1 task.
>
> $ task 1 info | grep ^Description
> Description Zażółć gęś
The attached patch fixes the issue for me. It all comes down to
extractLine() mixing display characters and bytes, failing to account
for multi-byte characters. AFAICT, upstream's new code for 2.6.0[1] is
not affected by this bug.
Please consider applying the fix and backporting it to a buster stable
release, as UTF-8 support has been a long-term release goal.
[1]
https://github.com/GothenburgBitFactory/libshared/blob/eadeda5d170bb513e52cf1a00ec2cc9501077bbf/src/shared.cpp#L293
Regards,
Apollon
From: Apollon Oikonomopoulos
Date: Wed, 10 Jul 2019 21:50:29 +0300
Subject: Fix non-ASCII description truncation
Annotated descriptions with non-ASCII characters get truncated, as
outlined in #820108. This happens because extractLine() keeps track of
the line length in terms of displayed characters while using text.substr to
extract lines, failing to account for multi-byte characters (which only
increment line_length by 1).
Fix this by relying on the cursor set by utf8_next_char, rather than
line_length.
Closes: #820108
---
src/text.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/text.cpp b/src/text.cpp
index f5e3496..89f3b78 100644
--- a/src/text.cpp
+++ b/src/text.cpp
@@ -248,7 +248,7 @@ bool extractLine (
// Premature EOL.
if (character == '\n')
{
- line = text.substr (offset, line_length);
+ line = text.substr (offset, cursor - offset - 1);
offset = cursor;
return true;
}
Bug#927801: [Pkg-puppet-devel] Bug#927801: File backup default value does not work in site.pp
Control: tags -1 unreproducible moreinfo
Hi,
On 16:06 Tue 23 Apr , IB Development Team wrote:
> Package: puppet-master
> Version: 5.5.10-2
>
> Global setting
>
> File { backup => false }
>
> in site.pp does not disable creating file backups on puppet client (backups
> are created in /var/lib/puppet/clientbucket but should not).
Thanks for the report. Unfortunately, I'm unable to trivially reproduce
this; the following sample works as expected:
File { backup => false }
node default {
file { '/tmp/test':
content => "test\n",
}
}
Can you make sure that site.pp is actually consulted when constructing
the catalog? `puppet master --debug --compile ` might help
you out with this.
Regards,
Apollon
Bug#927360: unblock: dovecot/1:2.3.4.1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dovecot
Dovecot 1:2.3.4.1-4, already in unstable, fixes a crash related to
processing of invalid external input. The issue is known as
CVE-2019-10691[1], and was fixed in the Debian package by backporting
the upstream fix.
Full source debdiff attached.
Regards,
Apollon
[1] https://dovecot.org/pipermail/dovecot/2019-April/115687.html
unblock dovecot/1:2.3.4.1-4
diff -Nru dovecot-2.3.4.1/debian/changelog dovecot-2.3.4.1/debian/changelog
--- dovecot-2.3.4.1/debian/changelog2019-03-25 23:06:01.0 +0200
+++ dovecot-2.3.4.1/debian/changelog2019-04-18 10:21:19.0 +0300
@@ -1,3 +1,9 @@
+dovecot (1:2.3.4.1-4) unstable; urgency=high
+
+ * [d04d4ba] Fix assert-crash in JSON encoder (CVE-2019-10691)
+
+ -- Apollon Oikonomopoulos Thu, 18 Apr 2019 10:21:19
+0300
+
dovecot (1:2.3.4.1-3) unstable; urgency=high
* [07c9212] Fix two buffer overflows when reading oversized FTS headers
diff -Nru dovecot-2.3.4.1/debian/patches/CVE-2019-10691
dovecot-2.3.4.1/debian/patches/CVE-2019-10691
--- dovecot-2.3.4.1/debian/patches/CVE-2019-10691 1970-01-01
02:00:00.0 +0200
+++ dovecot-2.3.4.1/debian/patches/CVE-2019-10691 2019-04-18
10:21:19.0 +0300
@@ -0,0 +1,66 @@
+From 973769d74433de3c56c4ffdf4f343cb35d98e4f7 Mon Sep 17 00:00:00 2001
+From: Aki Tuomi
+Date: Tue, 2 Apr 2019 13:09:48 +0300
+Subject: [PATCH 1/2] lib: json - Escape invalid UTF-8 as unicode bytes
+
+This prevents dovecot from crashing if invalid UTF-8 input
+is given.
+---
+ src/lib/json-parser.c | 12
+ src/lib/test-json-parser.c | 8
+ 2 files changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/src/lib/json-parser.c b/src/lib/json-parser.c
+index 677091d64..e7846a329 100644
+--- a/src/lib/json-parser.c
b/src/lib/json-parser.c
+@@ -803,9 +803,13 @@ void json_append_escaped_data(string_t *dest, const
unsigned char *src, size_t s
+
+ for (i = 0; i < size;) {
+ bytes = uni_utf8_get_char_n(src+i, size-i, );
+- /* refuse to add invalid data */
+- i_assert(bytes > 0 && uni_is_valid_ucs4(chr));
+- json_append_escaped_ucs4(dest, chr);
+- i += bytes;
++ if (bytes > 0 && uni_is_valid_ucs4(chr)) {
++ json_append_escaped_ucs4(dest, chr);
++ i += bytes;
++ } else {
++ str_append_data(dest, UNICODE_REPLACEMENT_CHAR_UTF8,
++UTF8_REPLACEMENT_CHAR_LEN);
++ i++;
++ }
+ }
+ }
+diff --git a/src/lib/test-json-parser.c b/src/lib/test-json-parser.c
+index bae6fb202..9ce1e489b 100644
+--- a/src/lib/test-json-parser.c
b/src/lib/test-json-parser.c
+@@ -267,20 +267,20 @@ static void test_json_append_escaped(void)
+ string_t *str = t_str_new(32);
+
+ test_begin("json_append_escaped()");
+- json_append_escaped(str,
"\b\f\r\n\t\"\\\001\002-\xC3\xA4\xf0\x90\x90\xb7");
+- test_assert(strcmp(str_c(str),
"\\b\\f\\r\\n\\t\\\"\\u0001\\u0002-\\u00e4\\ud801\\udc37") == 0);
++ json_append_escaped(str,
"\b\f\r\n\t\"\\\001\002-\xC3\xA4\xf0\x90\x90\xb7\xff");
++ test_assert(strcmp(str_c(str),
"\\b\\f\\r\\n\\t\\\"\\u0001\\u0002-\\u00e4\\ud801\\udc37"
UNICODE_REPLACEMENT_CHAR_UTF8) == 0);
+ test_end();
+ }
+
+ static void test_json_append_escaped_data(void)
+ {
+ static const unsigned char test_input[] =
+- "\b\f\r\n\t\"\\\000\001\002-\xC3\xA4\xf0\x90\x90\xb7";
++ "\b\f\r\n\t\"\\\000\001\002-\xC3\xA4\xf0\x90\x90\xb7\xff";
+ string_t *str = t_str_new(32);
+
+ test_begin("json_append_escaped()");
+ json_append_escaped_data(str, test_input, sizeof(test_input)-1);
+- test_assert(strcmp(str_c(str),
"\\b\\f\\r\\n\\t\\\"\\u\\u0001\\u0002-\\u00e4\\ud801\\udc37") == 0);
++ test_assert(strcmp(str_c(str),
"\\b\\f\\r\\n\\t\\\"\\u\\u0001\\u0002-\\u00e4\\ud801\\udc37"
UNICODE_REPLACEMENT_CHAR_UTF8) == 0);
+ test_end();
+ }
+
+--
+2.11.0
+
diff -Nru dovecot-2.3.4.1/debian/patches/series
dovecot-2.3.4.1/debian/patches/series
--- dovecot-2.3.4.1/debian/patches/series 2019-03-25 23:06:01.0
+0200
+++ dovecot-2.3.4.1/debian/patches/series 2019-04-18 10:21:19.0
+0300
@@ -10,4 +10,5 @@
lib-master-test-event-stats-Use-PRIu64-format.patch
avoid-double-closing-mysql.patch
CVE-2019-7524
+CVE-2019-10691
debian-changes
signature.asc
Description: PGP signature
Bug#926291: [Pkg-puppet-devel] Bug#926291: puppetdb 6 not compatible with puppet-master 5
Control: tags -1 unreproducible moreinfo Hi, On 20:23 Tue 02 Apr , Cwsights wrote: > Package: puppetdb > Version: 6.2.0-3 > Severity: normal > > Hi, > Debian (Buster) packages puppetdb 6 and puppet-master(-passenger) 5. > Unfortunately > puppetdb 6 requires puppet-master to be 6.0.0 or later[1]. This makes it > impossible > to use the puppet-master in buster with the puppetdb in buster. > > [1] https://puppet.com/docs/puppetdb/6.2/index.html#puppet-600 It is true that upstream's release notes mention this restriction. However, there seems to be no *technical* requirement for this. Have you encountered an actual issue while trying to use PuppetDB 6 with Puppet 5 masters? Regards, Apollon
Bug#926239: Acknowledgement (unblock: facter/3.11.0-2)
Attaching the source debdiff I forgot :)
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog 2018-12-01 01:19:32.0 +0200
+++ facter-3.11.0/debian/changelog 2019-04-02 14:24:17.0 +0300
@@ -1,3 +1,13 @@
+facter (3.11.0-2) unstable; urgency=medium
+
+ * Acknowledge 3.11.0-1.1 NMU. Thanks to gregor herrmann!
+ * B-D on ruby (Closes: #897556)
+ * Do not allow unsuitable custom facts to override built-in facts
+(Closes: #926197)
+ * Bump Standards-Version to 4.3.0; no changes needed
+
+ -- Apollon Oikonomopoulos Tue, 02 Apr 2019 14:24:17
+0300
+
facter (3.11.0-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru facter-3.11.0/debian/control facter-3.11.0/debian/control
--- facter-3.11.0/debian/control2018-12-01 01:16:40.0 +0200
+++ facter-3.11.0/debian/control2019-04-02 14:24:17.0 +0300
@@ -28,7 +28,8 @@
libssl-dev,
rapidjson-dev,
ruby-all-dev,
-Standards-Version: 4.1.3
+ ruby,
+Standards-Version: 4.3.0
Vcs-Git: https://salsa.debian.org/puppet-team/facter.git
Vcs-Browser: https://salsa.debian.org/puppet-team/facter
Homepage: https://github.com/puppetlabs/facter
diff -Nru facter-3.11.0/debian/patches/fix-custom-facts-overriding-core.patch
facter-3.11.0/debian/patches/fix-custom-facts-overriding-core.patch
--- facter-3.11.0/debian/patches/fix-custom-facts-overriding-core.patch
1970-01-01 02:00:00.0 +0200
+++ facter-3.11.0/debian/patches/fix-custom-facts-overriding-core.patch
2019-04-02 14:21:58.0 +0300
@@ -0,0 +1,259 @@
+From 4b7d4a7bebe20433c170b57771645cf774f1f281 Mon Sep 17 00:00:00 2001
+From: Enis Inan
+Date: Sat, 6 Oct 2018 18:44:17 -0700
+Subject: [PATCH] (FACT-1873) Use builtin fact if custom facts don't resolve or
+ have 0 wt.
+
+Previously, if any builtin facts have conflicting custom facts that all
+fail to resolve, and at least one of the custom facts has a weight > 0,
+Facter will not report a value for that fact. This is undesirable
+behavior because we always want to fall back to the builtin value if
+all custom facts fail to resolve. Note that the "weight > 0" part is
+important because Facter _will_ use the builtin value if all custom
+facts have 0 weight.
+
+Furthermore, the builtin fact should have precedence over 0 weight
+custom facts. The existing code enforces this condition when _all_
+custom facts have 0 weight, but it does _not_ enforce the condition
+when only _some_ custom facts have 0 weight. In the latter case, the 0
+weight custom facts will take precedence over the builtin fact value.
+
+This commit fixes the fact resolution logic so that it falls back to the
+built-in fact if all custom facts fail to resolve, while also ensuring
+that it has precedence over 0 weight custom facts.
+---
+ .../conflicts_with_builtin_fact.rb| 106 ++
+ lib/src/ruby/fact.cc | 98 +---
+ 2 files changed, 163 insertions(+), 41 deletions(-)
+ create mode 100644
acceptance/tests/custom_facts/conflicts_with_builtin_fact.rb
+
+diff --git a/acceptance/tests/custom_facts/conflicts_with_builtin_fact.rb
b/acceptance/tests/custom_facts/conflicts_with_builtin_fact.rb
+new file mode 100644
+index ..34c5e615
+--- /dev/null
b/acceptance/tests/custom_facts/conflicts_with_builtin_fact.rb
+@@ -0,0 +1,106 @@
++test_name 'Facter should appropriately resolve a custom fact when it
conflicts with a builtin fact' do
++ tag 'risk:medium'
++
++ def create_custom_fact_on(host, custom_fact_dir, fact_file_name, fact)
++fact_file_contents = <<-CUSTOM_FACT
++Facter.add(:#{fact[:name]}) do
++ has_weight #{fact[:weight]}
++ setcode do
++#{fact[:value]}
++ end
++end
++CUSTOM_FACT
++
++fact_file_path = File.join(custom_fact_dir, fact_file_name)
++create_remote_file(host, fact_file_path, fact_file_contents)
++ end
++
++ def clear_custom_facts_on(host, custom_fact_dir)
++step "Clean-up the previous test's custom facts" do
++ on(agent, "rm -f #{custom_fact_dir}/*")
++end
++ end
++
++ agents.each do |agent|
++custom_fact_dir = agent.tmpdir('facter')
++teardown do
++ on(agent, "rm -rf '#{custom_fact_dir}'")
++end
++
++fact_name = 'timezone'
++builtin_value = on(agent, facter('timezone')).stdout.chomp
++
++step "Verify that Facter uses the custom fact's value when its weight is
> 0" do
++ custom_fact_value = "custom_timezone"
++ create_custom_fact_on(
++agent,
++custom_fact_dir,
++'custom_timezone.rb',
++name: fact_name,
++weight: 10,
++value: "'#{custom_fact_value}'"
++ )
++
++ on(agent, facter("--custom-dir=#{custom_fact_dir} timezone")) do
|result|
++assert_match(/#{custom_fact_value}/, result.stdout.chomp, "Facter
does not use the cus
Bug#926239: unblock: facter/3.11.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package facter 3.11.0-2, uploaded today in unstable, adds a missing build-dependency and fixes a regression since the facter 2.x series. The facter package was lacking an explicit B-D on ruby, which has been transitively satisfied via rake so far. However, since the source directly uses /usr/bin/ruby, it should really B-D on ruby itself (see #897556). Additionally, the version in Buster introduces a small regression compared to the 2.x series, by allowing custom facts to completely override built-in facts, even when this should not happen. This issue was discovered by the DSA and has been fixed upstream, so I cherry-picked the relevant commit. See #926197 for details. Other than that, the package in unstable acknowledges the previous NMU, and bumps Standards-Version to 4.3.0. Full source debdiff since 3.11.0-1.1 attached. unblock facter/3.11.0-2
Bug#925924: unblock: dovecot/2.3.4.1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dovecot.
2.3.4.1-3, which was uploaded to unstable today, fixes two cases of
buffer overflows (collectively known as CVE-2019-7524). Please allow it
to migrate to testing as soon as possible. Full source debdiff against
testing attached.
Thanks,
Apollon
unblock dovecot/2.3.4.1-3
diff -Nru dovecot-2.3.4.1/debian/changelog dovecot-2.3.4.1/debian/changelog
--- dovecot-2.3.4.1/debian/changelog2019-03-14 11:02:39.0 +0200
+++ dovecot-2.3.4.1/debian/changelog2019-03-25 23:06:01.0 +0200
@@ -1,3 +1,10 @@
+dovecot (1:2.3.4.1-3) unstable; urgency=high
+
+ * [07c9212] Fix two buffer overflows when reading oversized FTS headers
+and/or oversized POP3-UIDL headers (CVE-2019-7524).
+
+ -- Apollon Oikonomopoulos Mon, 25 Mar 2019 23:06:01
+0200
+
dovecot (1:2.3.4.1-2) unstable; urgency=medium
[ Laurent Bigonville ]
diff -Nru dovecot-2.3.4.1/debian/patches/CVE-2019-7524
dovecot-2.3.4.1/debian/patches/CVE-2019-7524
--- dovecot-2.3.4.1/debian/patches/CVE-2019-75241970-01-01
02:00:00.0 +0200
+++ dovecot-2.3.4.1/debian/patches/CVE-2019-75242019-03-25
23:06:01.0 +0200
@@ -0,0 +1,59 @@
+From 2d31f0e08a80217c039be4aaae8de25bed0251f4 Mon Sep 17 00:00:00 2001
+From: Apollon Oikonomopoulos
+Date: Mon, 25 Mar 2019 23:04:44 +0200
+Subject: [PATCH] Fix CVE-2019-7524
+
+commit ad1350ff036965c33f0aae20432ec73ca84f7819
+Author: Timo Sirainen
+Date: Mon Feb 4 19:25:13 2019 -0800
+
+fts: Fix buffer overflow when reading oversized fts header
+
+commit 89e05f17de80e19078544ef887d83d160491214e
+Author: Timo Sirainen
+Date: Mon Feb 4 19:23:02 2019 -0800
+
+lib-storage: Fix buffer overflow when reading oversized hdr-pop3-uidl
header
+---
+ src/lib-storage/index/index-pop3-uidl.c | 4 ++--
+ src/plugins/fts/fts-api.c | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/lib-storage/index/index-pop3-uidl.c
b/src/lib-storage/index/index-pop3-uidl.c
+index 13b7363ef..e537e9ff5 100644
+--- a/src/lib-storage/index/index-pop3-uidl.c
b/src/lib-storage/index/index-pop3-uidl.c
+@@ -37,7 +37,7 @@ bool index_pop3_uidl_can_exist(struct mail *mail)
+ /* this header isn't set yet */
+ return TRUE;
+ }
+- memcpy(, data, size);
++ memcpy(, data, sizeof(uidl));
+ return mail->uid <= uidl.max_uid_with_pop3_uidl;
+ }
+
+@@ -95,7 +95,7 @@ void index_pop3_uidl_update_exists_finish(struct
mailbox_transaction_context *tr
+
+ /* check if we have already the same header */
+ if (size >= sizeof(uidl)) {
+- memcpy(, data, size);
++ memcpy(, data, sizeof(uidl));
+ if (trans->highest_pop3_uidl_uid == uidl.max_uid_with_pop3_uidl)
+ return;
+ }
+diff --git a/src/plugins/fts/fts-api.c b/src/plugins/fts/fts-api.c
+index 5a5b2a919..4f8a1c125 100644
+--- a/src/plugins/fts/fts-api.c
b/src/plugins/fts/fts-api.c
+@@ -425,7 +425,7 @@ bool fts_index_get_header(struct mailbox *box, struct
fts_index_header *hdr_r)
+ i_zero(hdr_r);
+ ret = FALSE;
+ } else {
+- memcpy(hdr_r, data, data_size);
++ memcpy(hdr_r, data, sizeof(*hdr_r));
+ ret = TRUE;
+ }
+ mail_index_view_close();
+--
+2.20.1
+
diff -Nru dovecot-2.3.4.1/debian/patches/series
dovecot-2.3.4.1/debian/patches/series
--- dovecot-2.3.4.1/debian/patches/series 2019-03-14 11:02:39.0
+0200
+++ dovecot-2.3.4.1/debian/patches/series 2019-03-25 23:06:01.0
+0200
@@ -9,4 +9,5 @@
ssl-dh-params-location.patch
lib-master-test-event-stats-Use-PRIu64-format.patch
avoid-double-closing-mysql.patch
+CVE-2019-7524
debian-changes
Bug#924580: upgrade from old version w/o ssl_dh in conf file breaks ssl
Control: tags -1 + confirmed Hi Joey, Thanks for the report! On 11:45 Thu 14 Mar , Joey Hess wrote: > My dovecot installation dates from 2014 (2.2.13) and on upgrade to > this > version, it started failing on ssl connections: > > Mar 13 19:01:40 kite dovecot[9278]: imap-login: Error: Failed to initialize > SSL server context: Can't load DH parameters: error:1408518A:SSL > routines:ssl3_ctx_ctrl:dh key too small: user=<>, rip=xxx, lip=xxx, > session=<45XeyQGEZOzOSmkw> > > Fixing this involved adding this line to the config: > ssl_dh = > There was no ssl_dh setting in my config before, so I guess it was using > some other file by default which no longer provides valid DH params. The old setting was called ssl_parameters and apart from the name change, the file format has also changed from DER to PEM. This is documented in the dovecot wiki[1], which is also being pointed to from within NEWS.Debian. [1] https://wiki2.dovecot.org/Upgrading/2.3#dhparams I'll give it some more thought, but I'm afraid that trying to resolve this automatically is not trivial, especially since the SSL config was managed outside the conffiles system for many years. I think the best thing to do is document this in the release notes, what do you think? > > I also moved /var/lib/dovecot/ssl-parameters.dat out of the way, > which may or may not have been needed. It was not needed, but the file is not useful anymore anyway. > > This seems like the kind of upgrade breakage that would be worth documenting, > or avoiding, rather than leave the user to diff conffiles and scratch their > head. Cheers, Apollon
Bug#924578: unblock: dovecot/2.3.4.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dovecot
2.3.4.1-2 (already in unstable) fixes a double-free crash in the MySQL
driver, used primarily by dovecot's auth subsystem (see #918339). The
fix has been cherry-picked from upstream.
The only other change is bumping Standards-Version, which is trivial.
Full source debdiff attached.
Thanks,
Apollon
unblock dovecot/2.3.4.1-2
diff -Nru dovecot-2.3.4.1/debian/changelog dovecot-2.3.4.1/debian/changelog
--- dovecot-2.3.4.1/debian/changelog2019-02-05 16:19:12.0 +0200
+++ dovecot-2.3.4.1/debian/changelog2019-03-14 11:02:39.0 +0200
@@ -1,3 +1,16 @@
+dovecot (1:2.3.4.1-2) unstable; urgency=medium
+
+ [ Laurent Bigonville ]
+ * [ac99918] Fix double-free crash in mysql driver
+Fix double closing of the connection in the mysql driver, this should
+fix the crash in the dovecot auth process, taken from upstream.
+(Closes: #918339)
+
+ [ Apollon Oikonomopoulos ]
+ * [8a30446] Bump Standards-Version to 4.3.0; no changes needed
+
+ -- Apollon Oikonomopoulos Thu, 14 Mar 2019 11:02:39
+0200
+
dovecot (1:2.3.4.1-1) unstable; urgency=high
* [bebf0b4] New upstream version 2.3.4.1
diff -Nru dovecot-2.3.4.1/debian/control dovecot-2.3.4.1/debian/control
--- dovecot-2.3.4.1/debian/control 2019-02-05 16:19:12.0 +0200
+++ dovecot-2.3.4.1/debian/control 2019-03-14 11:02:39.0 +0200
@@ -32,7 +32,7 @@
lsb-release,
pkg-config,
zlib1g-dev
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
Homepage: http://dovecot.org/
Vcs-Git: https://salsa.debian.org/debian/dovecot.git
Vcs-Browser: https://salsa.debian.org/debian/dovecot
diff -Nru dovecot-2.3.4.1/debian/patches/avoid-double-closing-mysql.patch
dovecot-2.3.4.1/debian/patches/avoid-double-closing-mysql.patch
--- dovecot-2.3.4.1/debian/patches/avoid-double-closing-mysql.patch
1970-01-01 02:00:00.0 +0200
+++ dovecot-2.3.4.1/debian/patches/avoid-double-closing-mysql.patch
2019-03-14 11:02:39.0 +0200
@@ -0,0 +1,39 @@
+From 3c5101ffdd2a8115e03ed7180d53578765dea4c9 Mon Sep 17 00:00:00 2001
+From: Aki Tuomi
+Date: Tue, 4 Dec 2018 14:40:04 +0200
+Subject: [PATCH] driver-mysql: Avoid double-closing MySQL connection
+
+Fixes double-free
+---
+ src/lib-sql/driver-mysql.c | 8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/src/lib-sql/driver-mysql.c b/src/lib-sql/driver-mysql.c
+index c87e825e4..5dd1c3124 100644
+--- a/src/lib-sql/driver-mysql.c
b/src/lib-sql/driver-mysql.c
+@@ -173,7 +173,9 @@ static int driver_mysql_connect(struct sql_db *_db)
+ static void driver_mysql_disconnect(struct sql_db *_db)
+ {
+ struct mysql_db *db = (struct mysql_db *)_db;
+- mysql_close(db->mysql);
++ if (db->mysql != NULL)
++ mysql_close(db->mysql);
++ db->mysql = NULL;
+ }
+
+ static int driver_mysql_parse_connect_string(struct mysql_db *db,
+@@ -311,7 +313,9 @@ static void driver_mysql_deinit_v(struct sql_db *_db)
+ _db->no_reconnect = TRUE;
+ sql_db_set_state(>api, SQL_DB_STATE_DISCONNECTED);
+
+- mysql_close(db->mysql);
++ if (db->mysql != NULL)
++ mysql_close(db->mysql);
++ db->mysql = NULL;
+
+ sql_connection_log_finished(_db);
+ event_unref(&_db->event);
+--
+2.20.1
+
diff -Nru dovecot-2.3.4.1/debian/patches/series
dovecot-2.3.4.1/debian/patches/series
--- dovecot-2.3.4.1/debian/patches/series 2019-02-05 16:19:12.0
+0200
+++ dovecot-2.3.4.1/debian/patches/series 2019-03-14 11:02:39.0
+0200
@@ -8,4 +8,5 @@
dovecot_name.patch
ssl-dh-params-location.patch
lib-master-test-event-stats-Use-PRIu64-format.patch
+avoid-double-closing-mysql.patch
debian-changes
Bug#918339: dovecot: diff for NMU version 1:2.3.4.1-1.1
Hi Laurent, On 13:26 Wed 13 Mar , Laurent Bigonville wrote: > Control: tags 918339 + patch > Control: tags 918339 + pending > > > Dear maintainer, > > I've prepared an NMU for dovecot (versioned as 1:2.3.4.1-1.1) and > uploaded it to DELAYED/3. Please feel free to tell me if I > should delay it longer. > > Regards. Thanks for the NMU and apologies for the late response. To keep the history clean, I committed your changes to the repository and uploaded them as part of 2.3.4.1-2. I will file an unblock request tomorrow or the day after. Regards, Apollon
Bug#924409: removing hiera from debian? or do not ship with buster
Control: severity -1 important Control: tags -1 - buster Control: retitle -1 hiera should be removed after Buster is released Hi, On 13:07 Tue 12 Mar , Antoine Beaupre wrote: > I see that Hiera in Puppet is at version 3.2.0 in buster. That's at > least two minor versions behind upstream, which is (unofficially) at > 3.5: > > https://github.com/puppetlabs/hiera/releases > > That said, Hiera itself is deprecated as a standalone system: Hiera 5 > has been part of Puppet since 4.9: > > https://puppet.com/docs/hiera/3.3/index.html > > The Hiera README on GitHub says the same: > > https://github.com/puppetlabs/hiera/blob/master/README.md > > "This project is deprecated in favor of Hiera version 5 which is > implementation in Puppet." > > Since Buster will likely ship with Puppet 5.5 (or later), it doesn't > seem to make sense to ship Hiera in buster and it should be > removed. It could also be removed from unstable as well, but I wanted > to checkin with maintainers here first before filing a formal removal. Puppet currently lists `hiera` (3) as a runtime dependency in its gemspec[1]. This is to provide backward compatibility until users manually upgrade[2] their Puppet manifests, as Hiera 3 and Hiera 5 are incompatible. Since Hiera 5 was introduced after Stretch was released, we should keep plain `hiera` around for Buster to allow users to upgrade in a non-disruptive fashion. Of course we should document all of this on the release notes :) I'm lowering severity to non-RC, but keeping the bug around with an updated title so that we can remove hiera after Buster's release. Thanks, Apollon [1] https://github.com/puppetlabs/puppet/blob/master/.gemspec#L35 [2] https://puppet.com/docs/puppet/5.3/hiera_migrate.html
Bug#924468: unblock: puppet/5.5.10-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package puppet
puppet 5.5.10-2 (already in unstable) fixes an issue whereby the Puppet
master deserializes incoming agent reports producing variable output,
depending on the availability of a specific package in the system
(ruby-multi-json). This in turn can cause certain report processors
(notably PuppetDB) to fail. See #923976 for details.
Full source debdiff against testing attached.
Regards,
Apollon
unblock puppet/5.5.10-2
diff -Nru puppet-5.5.10/debian/changelog puppet-5.5.10/debian/changelog
--- puppet-5.5.10/debian/changelog 2019-01-16 10:56:17.0 +0200
+++ puppet-5.5.10/debian/changelog 2019-03-12 12:51:05.0 +0200
@@ -1,3 +1,9 @@
+puppet (5.5.10-2) unstable; urgency=medium
+
+ * Make sure oj does not use BigDecimals on data load (Closes: #923976)
+
+ -- Apollon Oikonomopoulos Tue, 12 Mar 2019 12:51:05
+0200
+
puppet (5.5.10-1) unstable; urgency=medium
* New upstream bugfix release; see
diff -Nru
puppet-5.5.10/debian/patches/0009-Avoid-BigDecimals-when-loading-JSON-using-Oj.patch
puppet-5.5.10/debian/patches/0009-Avoid-BigDecimals-when-loading-JSON-using-Oj.patch
---
puppet-5.5.10/debian/patches/0009-Avoid-BigDecimals-when-loading-JSON-using-Oj.patch
1970-01-01 02:00:00.0 +0200
+++
puppet-5.5.10/debian/patches/0009-Avoid-BigDecimals-when-loading-JSON-using-Oj.patch
2019-03-12 12:51:05.0 +0200
@@ -0,0 +1,35 @@
+From: Apollon Oikonomopoulos
+Date: Sun, 10 Mar 2019 01:22:29 +0200
+Subject: Avoid BigDecimals when loading JSON using Oj
+
+This is already done for JrJackson and needs to be done for Oj as well
+to avoid sending malformed reports to PuppetDB.
+
+Bug-Debian: https://bugs.debian.org/923976
+---
+ lib/puppet/util/json.rb | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/lib/puppet/util/json.rb b/lib/puppet/util/json.rb
+index 6baea59..ba2491b 100644
+--- a/lib/puppet/util/json.rb
b/lib/puppet/util/json.rb
+@@ -32,13 +32,16 @@ module Puppet::Util
+ def self.load(string, options = {})
+ if defined? MultiJson
+ begin
+- # This ensures that JrJackson will parse very large or very small
++ # This ensures that JrJackson and Oj will parse very large or very
small
+ # numbers as floats rather than BigDecimals, which are serialized as
+ # strings by the built-in JSON gem and therefore can cause schema
errors,
+ # for example, when we are rendering reports to JSON using
`to_pson` in
+ # PuppetDB.
+- if MultiJson.adapter.name == "MultiJson::Adapters::JrJackson"
++ case MultiJson.adapter.name
++ when "MultiJson::Adapters::JrJackson"
+ options[:use_bigdecimal] = false
++ when "MultiJson::Adapters::Oj"
++options[:bigdecimal_load] = :float
+ end
+
+ MultiJson.load(string, options)
diff -Nru puppet-5.5.10/debian/patches/series
puppet-5.5.10/debian/patches/series
--- puppet-5.5.10/debian/patches/series 2018-11-09 09:54:47.0 +0200
+++ puppet-5.5.10/debian/patches/series 2019-03-12 12:51:05.0 +0200
@@ -6,3 +6,4 @@
0007-Fix-service-listing-and-enable-disable-in-Debian.patch
0008-fix-locale-loading.patch
reproducible-build.patch
+0009-Avoid-BigDecimals-when-loading-JSON-using-Oj.patch
Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte
Control: tags -1 - moreinfo + patch pending
Control: severity -1 serious
On 13:43 Mon 11 Mar , Kienan Stewart wrote:
> Hi Apollon,
>
> On Sat, Mar 09, 2019 at 11:24:27PM +0200, Apollon Oikonomopoulos wrote:
> > Control: tags -1 - unreproducible
> >
> > Hi,
> >
> >
> > Thanks for the patch, it should do the trick. However, before applying
> > it I want to be 100% sure that we know what's happening and why.
> >
> > So, I managed to reproduce this by simply installing ruby-multi-json,
> > which allows Puppet to use different json backends. Can you verify that
> > ruby-multi-json is installed, presumably on the master?
> >
>
> ruby-multi-json (1.12.1-1) is installed.
>
> Checking with 'apt-cache policy rdepends ruby-multi-json', it's like because
> we use r10k
OK, thanks for confirming this and thanks for the detailed report, it's
very helpful!
I'm bumping this bug to RC, as I don't think Puppet report storage
should break merely by installing an unrelated Ruby package.
Additionally this is a regression from Puppet 4.x.
So, here's what's happening:
- Puppet 5 switched from a custom wire format (PSON) to JSON for
transmitting facts and reports.
- There is no issue when using the ruby-json JSON library to parse
reports.
- Some JSON libraries (Oj and JrJackson) de-serialize floats with many
decimal digits - such as the timing metrics found in a Puppet agent
report - as BigDecimal.
- When BigDecimal's are serialized again to JSON, they are serialized
as Strings (and not floats), causing PuppetDB's schema validation to
fail.
- This path is only triggered when ruby-oj and ruby-multi-json are
installed, enabling Puppet to use Oj via multi-json. (JrJackson is
Jruby-only, and there are provisions upstream handling BigDecimal
conversion in this case).
Your patch fixes the issue, but it does so right before the report is
transmitted to PuppetDB. I think it's best to instruct Oj to never
deserialize floats as BigDecimals and avoid having to do any conversions
in the first place. Additionally, this will guard all other report
processors (e.g. store) which might want to handle metrics against
similar issues.
Can you test the attached patch and confirm that it works?
Regards,
Apollon
From: Apollon Oikonomopoulos
Date: Sun, 10 Mar 2019 01:22:29 +0200
Subject: Avoid BigDecimals when loading JSON using Oj
This is already done for JrJackson and needs to be done for Oj as well
to avoid sending malformed reports to PuppetDB.
Bug-Debian: https://bugs.debian.org/923976
---
lib/puppet/util/json.rb | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/puppet/util/json.rb b/lib/puppet/util/json.rb
index 6baea59..3475990 100644
--- a/lib/puppet/util/json.rb
+++ b/lib/puppet/util/json.rb
@@ -32,13 +32,15 @@ module Puppet::Util
def self.load(string, options = {})
if defined? MultiJson
begin
- # This ensures that JrJackson will parse very large or very small
+ # This ensures that JrJackson and Oj will parse very large or very small
# numbers as floats rather than BigDecimals, which are serialized as
# strings by the built-in JSON gem and therefore can cause schema errors,
# for example, when we are rendering reports to JSON using `to_pson` in
# PuppetDB.
if MultiJson.adapter.name == "MultiJson::Adapters::JrJackson"
options[:use_bigdecimal] = false
+ elsif MultiJson.adapter.name == "MultiJson::Adapters::Oj"
+options[:bigdecimal_load] = :float
end
MultiJson.load(string, options)
Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte
Control: tags -1 - unreproducible
Hi,
On 12:26 Fri 08 Mar , Kienan Stewart wrote:
> Hi,
>
> I have made a patch which seems to resolve the issue. I'm not at all confident
> it's in the right place. The patch applies to the PuppetDB source which is
> used
> to make the puppet-terminus-puppetdb package.
>
> diff --git a/puppet/lib/puppet/reports/puppetdb.rb
> b/puppet/lib/puppet/reports/puppetdb.rb
> index d3f0c07..b78f02c 100644
> --- a/puppet/lib/puppet/reports/puppetdb.rb
> +++ b/puppet/lib/puppet/reports/puppetdb.rb
> @@ -129,7 +129,7 @@ Puppet::Reports.register_report(:puppetdb) do
> [:puppetdb, :metrics_list, :build]) do
>metrics_list = []
>metrics.each do |name, data|
> -metric_hashes = data.values.map {|x| {"category" => data.name,
> "name" => x.first, "value" => x.last}}
> +metric_hashes = data.values.map {|x| {"category" => data.name,
> "name" => x.first, "value" => x.last.to_f}}
> metrics_list.concat(metric_hashes)
>end
>metrics_list
>
> I'm not aware if there will be consequences to forcing all the metrics values
> to
> floats.
Thanks for the patch, it should do the trick. However, before applying
it I want to be 100% sure that we know what's happening and why.
So, I managed to reproduce this by simply installing ruby-multi-json,
which allows Puppet to use different json backends. Can you verify that
ruby-multi-json is installed, presumably on the master?
Thanks,
Apollon
Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte
Control: tags -1 unreproducible moreinfo
On 15:47 Fri 08 Mar , Apollon Oikonomopoulos wrote:
> On 14:54 Thu 07 Mar , Kienan wrote:
> > When running puppet 5.x with reports enabled and sent to PuppetDB 6.x,
> > PuppetDB fails to store the report with the following error:
> >
> > 2019-03-01T17:06:01.396-05:00 ERROR [p.p.command] [100] [store report]
> > Fatal error on attempt 0 for pm-buster.test
> > clojure.lang.ExceptionInfo: throw+: {:fatal true, :cause #error {
> > :cause "Value does not match schema: {:metrics [nil nil nil nil nil nil
> > nil nil nil nil nil nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} {:value (not (instance? java.lang.Number
> > a-java.lang.String))} {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> > a-java.lang.String))} nil nil nil nil nil nil nil nil nil {:value (not
> > (instance? java.lang.Number a-java.lang.String))} nil nil nil nil nil
> > nil]}"
> >
> > A copy of the Puppet DB log file is attached with the complete
> > backtrace.
> >
> > I'm filing this bug against the puppet package for the following reasons
> >
> > * hosts running puppet 4.x (stretch) are able to submit reports to same
> > version of Puppet DB.
>
> So, this sounds like a regression. I would not be surprised if Puppet 4
> nodes failed to work with PuppetDB 6, but this is clearly a bug.
>
> > * I am able to "solve" the problem by modifying a number of places in
> > the puppet agent files where report information is returned and calling
> > "to_i" or "to_f" to force casting into a numeric value instead of a
> > string.
> >
> > The metrics keys affected include: convert_catalog and
> > transaction_evaluation. The keys affected may change depending on the
> > manifest used for the node.
> >
> > This being said, it may be appropriate to move this bug to the PuppetDB
> > package. I haven't been able to find any upstream bugs regarding this
> > behaviour.
> >
> > To reproduce:
> >
> > 1. Install puppet, puppet-master-passenger, and puppetdb on the same
> > host.
> > 2. Configure the puppet master to storeconfigs with the PuppetDB and the
> > agent to submit reports:
> >
> > (snippet from /etc/puppet.conf)
> >
> > [main]
> > reports = puppetdb
>
> Note to self: let's add report storage to the puppet/puppetdb
> autopkgtests.
Turns out this is already enabled and running in our tests without
issues. I'm unable to trivially reproduce this, which makes me wonder if
it's a matter of the terminus version. Which version of the
puppet-terminus-puppetdb package are you using on the master?
Regards,
Apollon
Bug#923976: [Pkg-puppet-devel] Bug#923976: puppet: Reports submitte
Hi,
Thanks for the report!
On 14:54 Thu 07 Mar , Kienan wrote:
> When running puppet 5.x with reports enabled and sent to PuppetDB 6.x,
> PuppetDB fails to store the report with the following error:
>
> 2019-03-01T17:06:01.396-05:00 ERROR [p.p.command] [100] [store report] Fatal
> error on attempt 0 for pm-buster.test
> clojure.lang.ExceptionInfo: throw+: {:fatal true, :cause #error {
> :cause "Value does not match schema: {:metrics [nil nil nil nil nil nil
> nil nil nil nil nil nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} {:value (not (instance? java.lang.Number
> a-java.lang.String))} {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> a-java.lang.String))} nil nil nil nil nil nil nil nil nil {:value (not
> (instance? java.lang.Number a-java.lang.String))} nil nil nil nil nil
> nil]}"
>
> A copy of the Puppet DB log file is attached with the complete
> backtrace.
>
> I'm filing this bug against the puppet package for the following reasons
>
> * hosts running puppet 4.x (stretch) are able to submit reports to same
> version of Puppet DB.
So, this sounds like a regression. I would not be surprised if Puppet 4
nodes failed to work with PuppetDB 6, but this is clearly a bug.
> * I am able to "solve" the problem by modifying a number of places in
> the puppet agent files where report information is returned and calling
> "to_i" or "to_f" to force casting into a numeric value instead of a
> string.
>
> The metrics keys affected include: convert_catalog and
> transaction_evaluation. The keys affected may change depending on the
> manifest used for the node.
>
> This being said, it may be appropriate to move this bug to the PuppetDB
> package. I haven't been able to find any upstream bugs regarding this
> behaviour.
>
> To reproduce:
>
> 1. Install puppet, puppet-master-passenger, and puppetdb on the same
> host.
> 2. Configure the puppet master to storeconfigs with the PuppetDB and the
> agent to submit reports:
>
> (snippet from /etc/puppet.conf)
>
> [main]
> reports = puppetdb
Note to self: let's add report storage to the puppet/puppetdb
autopkgtests.
> [master]
> storeconfigs = true
> storeconfig_backend = true
> [agent]
> report = true
>
> 3. Run puppet using a minimal node manifest:
>
> node 'pm-buster.test' {
>
> }
>
> 4. The puppet run should complete successfully with no additional
> output.
> 5. Check the PuppetDB log at /var/log/puppetdb/puppetdb.log there should
> be an error submitting the report present.
>
> Note: this affects hosts running puppet 5.x which submit their reports
> to the puppet master as well.
Does this mean that storing reports on the Puppet master is also broken?
>
> I would expect normally that reports are able to be stored without
> error.
Agreed. This is definitely worth fixing for Buster, I'll look into it.
Thanks,
Apollon
Bug#922936: Acknowledgement (ganeti: KVM/QEMU Virtual machines won't start after the last qemu-system-x86_64 update.)
Control: tags -1 + upstream fixed-upstream - newcomer Hi and thanks for the report! On 02:30 Fri 22 Feb , Paul Parsons wrote: > I can confirm, altering the following file, compiling it and restarting the > ganeti service restores functionality :- > > /usr/share/ganeti/2.16/ganeti/hypervisor/hv_kvm/__init__.py > > Ln1286 - kvm_cmd.extend(["*-device", "virtio-balloon*"]) This has been fixed upstream[1] and I will upload a fixed version soon. Note that it's not only `-balloon` that has been dropped, but `-balloon` is the only option that is passed to *every* instance by default and so it will prevent all instances from starting. Cheers, Apollon [1] https://github.com/ganeti/ganeti/pull/1342
Bug#918437: ring-clojure: FTBFS randomly due to filesystem ordering
Hi,
Thanks a lot for looking into this!
On 14:06 Fri 08 Feb , Cyril Brulebois wrote:
> Hi,
>
> Santiago Vila (2019-01-06):
> > This happens because the "find path | xargs clojure" construction
> > which was common in many clojure packages is prone to error as its
> > success or not depends critically on the output order of the find
> > command.
> >
> > Cyril Brulebois has already fixed several similar packages so I'm
> > just Cc:ing him.
>
> I don't seem to have received a copy but I was chased down on IRC
> anyway. Pushed a commit to fix this but I'm now hitting issues with
> jh_classpath that I'm not sure how to fix:
> |jh_classpath
> | error: Can't rename /usr/share/java/ring-core-1.6.2.jar as
> /usr/share/java/ring-core-1.6.2.zbk Permission denied
> | at /usr/share/perl5/Archive/Zip/Archive.pm line 471.
> |
> Archive::Zip::Archive::overwriteAs(Archive::Zip::Archive=HASH(0x563056bf7140),
> "/usr/share/java/ring-core-1.6.2.jar") called at
> /usr/share/perl5/Archive/Zip/Archive.pm line 439
> |
> Archive::Zip::Archive::overwrite(Archive::Zip::Archive=HASH(0x563056bf7140))
> called at /usr/bin/jh_manifest line 342
> | main::update_jar("/usr/share/java/ring-core-1.6.2.jar", undef) called
> at /usr/bin/jh_manifest line 147
> | jh_manifest: Writing modified jar (/usr/share/java/ring-core-1.6.2.jar)
> failed: Permission denied
> | jh_classpath: jh_manifest -plibring-core-clojure
> "--classpath=/usr/share/java/clojure.jar /usr/share/java/tools.reader.jar
> /usr/share/java/ring-codec.jar /usr/share/java/commons-io.jar
> /usr/share/java/commons-fileupload.jar /usr/share/java/clj-time.jar
> /usr/share/java/crypto-random.jar /usr/share/java/crypto-equality.jar"
> /usr/share/java/ring-core.jar returned exit code 13
> | make: *** [debian/rules:10: binary] Error 13
>
> Trying to remove the leading slash in debian/*.classpath makes this
> issue (EPERM) go away but I'm seeing this now which doesn't seem very
> reassuring:
> | jh_classpath: Cannot find usr/share/java/ring-servlet.jar: skipping
> | jh_classpath: Cannot find /usr/share/java/ring-jetty-adapter.jar: skipping
Apparently there are two bugs in jh_classpath:
foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmpdir = tmpdir($dh{FIRSTPACKAGE});
my $pkgfile = pkgfile($package, 'classpath');
if (not $pkgfile and -f 'debian/classpath') {
$pkgfile = 'debian/classpath';
}
next if not $pkgfile;
my @lines = filedoublearray($pkgfile);
for my $line (@lines) {
my ($jar, @classpath_parts) = @{$line};
my $classpath = join(' ', @classpath_parts);
if (not -f $jar) {
my $jar_in_tmp = "${tmpdir}/${jar}";
if (not -f $jar_in_tmp) {
warning("Cannot find $jar: skipping");
next;
}
$jar = $jar_in_tmp;
}
doit('jh_manifest', "-p$dh{FIRSTPACKAGE}",
"--classpath=${classpath}", $jar)
}
}
The first one is that if /usr/share/java/blah.jar exists (which can
happen if you have a version of the package already installed on the
build system), it will try to update the classpath of that jar file,
even though it lies outside the build root. Now, stripping the initial
slash from the filename prevents this from happening, but…
… $tmpdir always points to the first package's temporary directory, so
jh_classpath won't be able to find any of the jars in the second and
subsequent packages.
I'll try to work around this by invoking jh_classpath separately for
each package and will file bugs afterwards.
Cheers,
Apollon
Bug#919361: arcanist: ArcanistPuppetLinter is broken with modern versions of puppet-lint, uses obsolete log-format key
Package: arcanist
Version: 0~git20180509-2
Severity: normal
Tags: patch
Control: forward -1
https://discourse.phabricator-community.org/t/arcanistpuppetlinter-broken-with-modern-versions-of-puppet-lint-uses-obsolete-log-format-key/2296
Dear Maintainer,
`arc lint` on Puppet manifests is broken with modern versions of
puppet-lint because it uses an old log-format directive.
Trying to lint a Puppet repository with arc lint using puppet-lint >=
2.1.0 produces:
Exception
Some linters failed:
- CommandException: Command failed with error #1!
COMMAND
'puppet-lint' '--error-level=all'
'--log-format=%{linenumber}|%{column}|%{kind}|%{check}|%{message}'
'/some/path/puppet/manifests/site.pp'
STDOUT
(empty)
STDERR
/usr/lib/ruby/vendor_ruby/puppet-lint.rb:119:in `%': key{linenumber}
not found (KeyError)
from /usr/lib/ruby/vendor_ruby/puppet-lint.rb:119:in
`format_message'
from /usr/lib/ruby/vendor_ruby/puppet-lint.rb:166:in `block in
report'
from /usr/lib/ruby/vendor_ruby/puppet-lint.rb:156:in `each'
from /usr/lib/ruby/vendor_ruby/puppet-lint.rb:156:in `report'
from /usr/lib/ruby/vendor_ruby/puppet-lint.rb:215:in
`print_problems'
from /usr/lib/ruby/vendor_ruby/puppet-lint/bin.rb:67:in `block
in run'
from /usr/lib/ruby/vendor_ruby/puppet-lint/bin.rb:62:in `each'
from /usr/lib/ruby/vendor_ruby/puppet-lint/bin.rb:62:in `run'
from /usr/bin/puppet-lint:7:in `'
(Run with `--trace` for a full exception trace.)
`%{linenumber}` had been deprecated since 2014[1] in favor of `%{line}`
and was eventually removed in puppet-lint 2.1.0[2].
The attached patch fixes the issue, making arcanist compatible with the
current puppet-lint version in Debian.
Regards,
Apollon
[1]
https://github.com/rodjek/puppet-lint/commit/dd77ecaab12dc516c45ca620212e0f45b6b5a628
[2]
https://github.com/rodjek/puppet-lint/commit/870cc9577b1dd58c3453402880cbf9fd5900fc31
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'testing'), (90, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages arcanist depends on:
ii libphutil 0~git20180509-2
ii php-cli 2:7.3+68
ii php-curl2:7.3+68
ii php-xml 2:7.3+68
ii php5-cli5.6.30+dfsg-0+deb8u1
ii php7.0-cli [php-cli]7.0.31-1
ii php7.0-xml [php-xml]7.0.31-1
ii php7.2-cli [php-cli]7.2.9-1
ii php7.2-curl [php-curl] 7.2.9-1
ii php7.2-xml [php-xml]7.2.9-1
ii php7.3-cli [php-cli]7.3.0~rc4-1
ii php7.3-curl [php-curl] 7.3.0~rc4-1
ii php7.3-xml [php-xml]7.3.0~rc4-1
arcanist recommends no packages.
Versions of packages arcanist suggests:
ii python 2.7.15-3
-- no debconf information
>From f7cad0d4c46409a403f6fad5161e45742ec445b0 Mon Sep 17 00:00:00 2001
From: Apollon Oikonomopoulos
Date: Mon, 14 Jan 2019 23:27:12 +0200
Subject: [PATCH] Puppet linter: use %{line} in the log format
`arc lint` on Puppet manifests is broken with modern versions of
puppet-lint because it uses an old log-format directive.
`%{linenumber}` had been deprecated since 2014[1] in favor of `%{line}`
and was eventually removed in puppet-lint 2.1.0[2].
Fix this by using `%{line}`, which should work for everyone these days.
[1] https://github.com/rodjek/puppet-lint/commit/dd77ecaab12dc516c45ca620212e0f45b6b5a628
[2] https://github.com/rodjek/puppet-lint/commit/870cc9577b1dd58c3453402880cbf9fd5900fc31
---
src/lint/linter/ArcanistPuppetLintLinter.php | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lint/linter/ArcanistPuppetLintLinter.php b/src/lint/linter/ArcanistPuppetLintLinter.php
index 8336cd42..5b78ffd0 100644
--- a/src/lint/linter/ArcanistPuppetLintLinter.php
+++ b/src/lint/linter/ArcanistPuppetLintLinter.php
@@ -56,7 +56,7 @@ final class ArcanistPuppetLintLinter extends ArcanistExternalLinter {
return array(
'--error-level=all',
sprintf('--log-format=%s', implode('|', array(
-'%{linenumber}',
+'%{line}',
'%{column}',
'%{kind}',
'%{check}',
--
2.19.2
Bug#918339: dovecot-mysql: dovecot/auth segfaults with double-free in mysql_close() / passdb_deinit()
Control: severity -1 important
Hi and thanks for the report!
On 11:00 Sat 05 Jan , Dominik Röttsches wrote:
> Package: dovecot-mysql
> Version: 1:2.3.4-2
> Severity: grave
> Tags: security
> Justification: user security hole
Downgrading severity to important; although this is a double-free memory
corruption, I would not describe it as a grave security issue based on
the information available. Furthermore, it being triggered from deinit,
I expect the auth system to otherwise work normally.
>
> Dear Maintainer,
>
> while running dovecot with the mysql auth package, I frequently get auth
> segfaults in the kernel log such as:
>
> [51013.656961] auth[17706]: segfault at 60 ip 7f003b360a7b sp
> 7ffe800d7f30 error 4 in libmariadb.so.3[7f003b354000+26000]
> [51013.658978] Code: 85 ff 0f 84 27 01 00 00 55 48 89 e5 41 54 53 48 8b 87 f0
> 04 00 00 48 89 fb 48 85 c0 74 2d 4c 8b 20 4d 85 e4 74 25 49 8b 04 24 <48> 8b
> 40 60 48 85 c0 74 02 ff d0 4c 89 e7 e8 92 3c ff ff 48 8b 83
>
> I attached gdb to the auth process, but I was unable to get debug symbols for
> libmariadbclient.so.18. Anyway, I get these stacktraces for the crash - which
> seems to be a crash on disconnect / mysql_close().
>
> #1 0x7f59d8d08535 in __GI_abort () at abort.c:79
> #2 0x7f59d8d5f718 in __libc_message (action=action@entry=do_abort,
> fmt=fmt@entry=0x7f59d8e6a29a "%s\n")
> at ../sysdeps/posix/libc_fatal.c:181
> #3 0x7f59d8d65e3a in malloc_printerr (str=str@entry=0x7f59d8e6bf60
> "free(): double free detected in tcache 2") at malloc.c:5382
> #4 0x7f59d8d6791d in _int_free (av=0x7f59d8ea1c40 ,
> p=0x564222bd44e0, have_lock=) at malloc.c:4193
> #5 0x7f59d8c1ea8e in mysql_close () from
> target:/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
> #6 0x7f59d91801fe in ?? () from
> target:/usr/lib/dovecot/modules/auth/libdriver_mysql.so
> #7 0x564220be2a14 in ?? ()
> #8 0x564220bd88f1 in db_sql_unref ()
> #9 0x564220bcd92e in passdb_deinit ()
> #10 0x564220bb7099 in auths_deinit ()
> #11 0x564220bb5e0c in main ()
>
> I would expect not to have such crashes during the operation of the auth
> module.
>
> My sql auth configuration is as follows:
>
> driver = mysql
> connect = host=127.0.0.1 dbname=maildb user=mail password=
> default_pass_scheme = CRYPT
> password_query = SELECT email AS user, newcrypt AS password FROM passwd WHERE
> email = '%u'
> iterate_query = SELECT email AS user FROM passwd
>
> The table schema for the passwd table is:
>
> DESCRIBE passwd
>
> email char(128) NO PRI
> newcrypt char(128) NO
> name char(128) NO
> uid int(10) unsignedNO 8
> gid int(10) unsignedNO 8
> home char(255) NO
> maildir char(255) NO
> quota char(255) NO
>
> -- Package-specific info:
>
> dovecot configuration
> -
> # 2.3.4 (0ecbaf23d): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.4 ()
> # OS: Linux 4.19.0-1-amd64 x86_64 Debian buster/sid ext4
> # Hostname: mail.drwebdesign.de
> protocol lmtp {
> mail_plugins = fts fts_solr sieve
> }
> protocol imap {
> mail_max_userip_connections = 100
> }
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=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 /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages dovecot-mysql depends on:
> ii dovecot-core 1:2.3.4-2
> ii libc62.28-3
> ii libmariadbclient18 [libmariadbclient18] 1:10.3.11-3
This issue appears to manifest only with libmariadbclient18 10.3.x, and
not with 10.1.x from testing. I suspect the culprit to be
libmariadbclient18, but will need to investigate further.
Regards,
Apollon
Bug#917319: libdovecot: Segfault -- service(dict) killed with signal 11
Control: tags -1 + upstream fixed-upstream Hi! On 03:40 Fri 04 Jan , Christian Schrötter wrote: > > Not tested yet, but it looks like the right commit... > > Tested and confirmed, it's the right bugfix! :-) > > @Maintainer: I think this will be included in Dovecot v2.3.5. I don't > know when the next release will be available, so maybe it's a good idea > to include the patch [1] in the next package update as temporary > solution for all affected users? > > Patched sources are available at [2]. Test build for amd64 is available > at [3]. This is only a small personal repository for private stuff. Thanks to both of you for the report and the triaging. If upstream does not release v2.3.5 soon, I'll go ahead and upload a patched 2.3.4. Regards, Apollon
Bug#918184: dovecot-core: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'
Control: tags -1 + wontfix Control: severity -1 wishlist Hi, On 22:04 Thu 03 Jan , pradeep nambiar wrote: > Package: dovecot-core > Version: 1:2.2.27-3+deb9u2 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? : Using Roundcube mail client. Unable to > login with SSLv2 disabled in dovecot conf file: 10-ssl.conf > This bug seems to be similar to this which says it has been fixed > earlier: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844347 >* What exactly did you do (or not do) that was effective (or > ineffective)? I had to re-enable SSLv2 > with setting > ssl_protocl = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 > did not work. > with setting > ssl_protocols = !SSLv3 !TLSv1 !TLSv1.1 > worked > >* What was the outcome of this action? Had to enable SSLv2. But SSLv2 has > known vulnerability. >* What outcome did you expect instead? Would like to disable SSLv2 in > 10-ssl.conf file Thanks for the report. Since Debian Stretch, SSLv2 is not supported by the OpenSSL library in Debian at all, so there is no need to disable it. In fact, this bug is due to OpenSSL not knowing how to disable a protocol it does not support at all. Regards, Apollon
Bug#908082: [pkg-go] Bug#908082: golang-github-juju-testing: Autobuilder hangs when building with eatmydata
Control: reassign -1 eatmydata Control: affects -1 mongodb-server-core Control: retitle -1 eatmydata is incompatible with tcmalloc Hi, On 09:24 Thu 06 Sep , Michael Stapelberg wrote: > This is not a bug with this package, but with mongodb-server: > > root@gce1535991:~# mongod --version > db version v3.4.15 > git version: 52e5b5fbaa3a2a5b1a217f5e647b5061817475f9 > OpenSSL version: OpenSSL 1.1.0f 25 May 2017 > allocator: tcmalloc > modules: none > build environment: > distarch: x86_64 > target_arch: x86_64 > root@gce1535991:~# eatmydata mongod --version > ^C It looks like this is an incompatibility between eatmydata and tcmalloc: (gdb) bt #0 0x7f4e24cf9c41 in __GI___nanosleep (requested_time=0x7ffcaa6523e0, remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28 #1 0x7f4e25d08753 in base::internal::SpinLockDelay(int volatile*, int, int) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #2 0x7f4e25d08623 in SpinLock::SlowLock() () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #3 0x7f4e25cfcf54 in tcmalloc::ThreadCache::InitModule() () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #4 0x7f4e25cfd06d in tcmalloc::ThreadCache::CreateCacheIfNecessary() () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #5 0x7f4e25d0b20a in tc_calloc () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #6 0x7f4e2503ba25 in _dlerror_run ( operate=operate@entry=0x7f4e2503b3b0 , args=args@entry=0x7ffcaa652500) at dlerror.c:140 #7 0x7f4e2503b42f in __dlsym (handle=handle@entry=0x, name=name@entry=0x7f4e26144000 "open") at dlsym.c:70 #8 0x7f4e261430b1 in eatmydata_init () at libeatmydata/libeatmydata.c:80 #9 0x7f4e261434a5 in eatmydata_is_hungry () at libeatmydata/libeatmydata.c:96 #10 msync (addr=, length=, flags=) at libeatmydata/libeatmydata.c:204 #11 0x7f4e24911fc4 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8 #12 0x7f4e24915d21 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8 #13 0x7f4e2491601f in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8 #14 0x7f4e24916569 in ?? () from /usr/lib/x86_64-linux-gnu/libunwind.so.8 #15 0x7f4e24912ac1 in _ULx86_64_step () from /usr/lib/x86_64-linux-gnu/libunwind.so.8 #16 0x7f4e25d0905b in ?? () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #17 0x7f4e25d09634 in GetStackTrace(void**, int, int) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #18 0x7f4e25cfa6a6 in tcmalloc::PageHeap::GrowHeap(unsigned long) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #19 0x7f4e25cfa93b in tcmalloc::PageHeap::New(unsigned long) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #20 0x7f4e25cf8865 in tcmalloc::CentralFreeList::Populate() () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #21 0x7f4e25cf8a68 in tcmalloc::CentralFreeList::FetchFromOneSpansSafe(int, void**, void**) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #22 0x7f4e25cf8b67 in tcmalloc::CentralFreeList::RemoveRange(void**, void**, int) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #23 0x7f4e25cfc3a0 in tcmalloc::ThreadCache::FetchFromCentralCache(unsigned int, int, void* (*)(unsigned long)) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #24 0x7f4e25d0c775 in tcmalloc::allocate_full_malloc_oom(unsigned long) () from /usr/lib/x86_64-linux-gnu/libtcmalloc.so.4 #25 0x7f4e24f46416 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #26 0x7f4e261af0ca in call_init (l=, argc=argc@entry=2, argv=argv@entry=0x7ffcaa6535e8, env=env@entry=0x7ffcaa653600) at dl-init.c:72 #27 0x7f4e261af1d6 in call_init (env=0x7ffcaa653600, argv=0x7ffcaa6535e8, argc=2, l=) at dl-init.c:118 #28 _dl_init (main_map=0x7f4e261c9170, argc=2, argv=0x7ffcaa6535e8, env=0x7ffcaa653600) at dl-init.c:119 #29 0x7f4e261a124a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 Without digging too deep, AFAICT eatmydata is injected in tcmalloc's initialization path (#24) through msync (#10), which in turn tries to calloc() more memory, causing a deadlock. I'm reassigning this to eatmydata, since I guess it should be as transparent as possible and not interfere with the underlying memory allocator used. Regards, Apollon
Bug#884462: Please update mongodb to 3.6
Control: tags -1 - pending + wontfix Hi, This didn't happen sofar (mostly due to lack of time), but now I will not upgrade MongoDB to 3.6 (or any later version) until the license issues have been sorted out. See #916107 for details. Regards, Apollon
Bug#916107: mongodb: MongoDB should not be part of a stable release
Source: mongodb Version: 1:3.4.15-1 Severity: serious Justification: Cannot be properly supported MongoDB should not be part of (at least) Buster for the following reasons: - MongoDB 3.4 will be EOL by June 2019[1], which is way too soon for it to be included in Buster. - MongoDB 3.6 and 4.0 will be supported longer, but upstream's switch to SSPLv1 complicates matters. As discussed in #915537, we will not be distributing any SSPL-licensed software, and keeping the last AGPL-licensed version (3.6.8 or 4.0.3) without the ability to cherry-pick upstream fixes is not a viable option. (I am currently not considering distributing mongodb in non-free.) I will not request removal immediately, to allow other packages time to adjust their dependencies, but eventually auto-removal will kick in. That said, MongoDB 3.4 will probably remain in sid for as long as it is AGPL-licensed and supported upstream. Apollon [1] https://www.mongodb.com/support-policy
Bug#905027: tgt-glusterfs: bs-type glfs doesn't work at all
Control: severity -1 important Control: tags -1 + moreinfo Hi, Thanks for the report and apologies for the late response. On 20:56 Mon 30 Jul , Moritz Molle wrote: > Package: tgt-glusterfs > Version: 1:1.0.69-1 > Severity: grave Downgrading severity to important. Although this bug makes the package unusable for this particular scenario, it does not do so in general. > Tags: upstream > Justification: renders package unusable > > Dear Maintainer, > > with a relatively simple setup: > > local glusterfs, with a replica 2 volume, I tried to use tgtd with glfs. My > tgt config was like so: > > > vendor_id xx > bs-type glfs > bsopts "logfile=/var/log/bs-glfs.log;loglevel=3" > write-cache off > initiator-address 10.10.8.0/24 > backing-store "gv_b_0@127.0.0.1:/iSCSI_VOL1.img" > backing-store "gv_b_0@127.0.0.1:/iSCSI_VOL2.img" > controller_tid=10 > > > ... > > /var/log/daemon.log gives me this endlessly > Jul 30 20:28:55 storage-b-02 tgtd[30479]: tgtd: abort_task_set(1349) found > 38ec 0 > Jul 30 20:28:55 storage-b-02 tgtd[30479]: tgtd: abort_cmd(1325) found 38ec 6 > Jul 30 20:29:05 storage-b-02 tgtd[30479]: tgtd: abort_task_set(1349) found > 38ec 0 > Jul 30 20:29:05 storage-b-02 tgtd[30479]: tgtd: abort_cmd(1325) found 38ec 6 > > /var/log/messages contains this > Jul 30 20:34:17 storage-b-02 kernel: [436035.821673] tgtd[31394]: segfault at > 220 ip 7f6944b24dcb sp 7fffdf64f800 error 4 in > libgfapi.so.0.0.0[7f6944b1d000+25000] > Jul 30 20:37:39 storage-b-02 kernel: [436237.496969] tgtd[31627]: segfault at > 220 ip 7f370a520dcb sp 7ffd3c51e5c0 error 4 in > libgfapi.so.0.0.0[7f370a519000+25000] > > I don't know, if it's related to the Volume-Files being 10T big, but it > shouldn't, I think. > Unfortunately these messages don't help much. FWIW this could also be a bug in glusterfs code. Any chance you can give it a try with the version from unstable? Could you also try to obtain a core dump or a backtrace using gdb and the tgt-dbgsym and glusterfs-common-dbgsym packages? Thanks, Apollon
Bug#915411: dovecot-core: doveadm crashes with segmentation fault ('batch -A : kick')
Control: tags -1 + upstream confirmed Control: forwarded -1 https://www.dovecot.org/pipermail/dovecot/2018-December/113819.html Hi, On 11:52 Fri 07 Dec , Bernhard Übelacker wrote: > I could reproduce this crash in a minimal stretch amd64 VM > with just dovecot-core installed and default configuration. > > That command crashes also in a similar VM with current > buster/testing version. Thanks to both of you for the information. I have forwarded this bug upstream, it looks like `batch` is set up to work primarily with "version 1" doveadm commands, converting "version 2" commands to 1 under the hood. Apparently `kick` is lacking an allocation function that would allow it to work as a "version 1" command, causing a null pointer dereference on the way there. Regards, Apollon
Bug#915652: ganeti: Fails to build reproducibly: embeds path of ip found via PATH
Hi Andreas! On 22:13 Thu 06 Dec , Andreas Henriksson wrote: > I agree that fixing these merged-usr reproducability issues on their > own > is pretty useless, not only for ganeti but for all affected packages. > Still I'm attaching a patch that makes ganeti reproducible in > merged-usr vs non-merged systems. I think it would be great if > you could still consider applying it (and then continuing the discussion > upstream about general improvements), because it would be nice to see > people stop discussing this useless change. Local builds will break > for so many other reasons than merged-usr. fixing the things > people complain about could still be nice though, just to avoid > further discussions. Agreed. Unfortunately, the patch is malformed, it only contains the following two lines: > ganeti_2.16.0-2.1.dsc > ganeti_2.16.0-2.dsc Could you resend it? Thanks! Apollon
Bug#915652: ganeti: Fails to build reproducibly: embeds path of ip found via PATH
Control: tags -1 upstream confirmed Hi Gunnar, On 09:50 Wed 05 Dec , Gunnar Wolf wrote: > We have found ganeti to embed the system path for ip — which is /bin > on non-/usrmerged systems, and /usr/bin on /usrmerged systems. Thanks for the report! Unfortunately ganeti embeds a lot of other paths, detected at ./configure time. Apart from making the build non-reproducible, it also happens to make an assumption that the running system will have binaries at the same paths as the build system, which obviously does not hold. IMHO, it should just rely on $PATH to find the external programs it needs to execute. I'll see what I can do about it. Cheers, Apollon
Bug#915537: MongoDB SSPL v1 license and the DFSG
Package: ftp.debian.org Severity: normal [ Continuing the thread in debian-legal[0] and Cc'ing debian-legal as well ] Dear FTP masters, I would like your opinion on whether MongoDB's new SSPL license is suitable for inclusion in the main archive. To give a bit of background, MongoDB was previously distributed under a mixed AGPL-3.0/Apache-2.0 license. On 2018-10-15, upstream did a commit replacing AGPL-3.0 with the new Server Side Public License Version 1[1] — of which MongoDB is the steward. The same change was backported to two stable branches, with the 3.6.9 and 4.0.4 stable revisions carrying the new license. MongoDB has submitted the license to OSI for review[2]; the discussion there is still ongoing, but the initial response seems to be negative. In essence, the license (at least v1 which is currently in use) is almost identical to AGPL-3.0, with the exception of Section 13, which states: > 13. Offering the Program as a Service. > > If you make the functionality of the Program or a modified version > available to third parties as a service, you must make the Service > Source Code available via network download to everyone at no charge, > under the terms of this License. Making the functionality of the > Program or modified version available to third parties as a service > includes, without limitation, enabling third parties to interact with > the functionality of the Program or modified version remotely through > a computer network, offering a service the value of which entirely or > primarily derives from the value of the Program or modified version, > or offering a service that accomplishes for users the primary purpose > of the Program or modified version. > > “Service Source Code” means the Corresponding Source for the Program > or the modified version, and the Corresponding Source for all programs > that you use to make the Program or modified version available as a > service, including, without limitation, management software, user > interfaces, application program interfaces, automation software, > monitoring software, backup software, storage software and hosting > software, all such that a user could run an instance of the service > using the Service Source Code you make available. What this section says (at least to my eyes), is that the SSPL requires *all software* interfacing with MongoDB to form a "service" to be licensed under the SSPL too. This is a much broader restriction than linking, but still does not seem to violate DFSG #9. It is also not a universal restriction, but one that is based on use/field of endeavor: + The same ancillary software, when made part of a "MongoDB service", must be licensed under the SSPL, while when used for other purposes may carry any license. + Conversely, when building a service around MongoDB, you are only allowed to use SSPL-licensed software to build that service, something that may turn out to be impractical or even impossible. Note that this does not violate DFSG #6, as it does not prohibit *using* MongoDB itself for specific purposes, but it places heavy restrictions on *other* software you are able to use alongside MongoDB to build a service (for instance you can use bacula to backup your personal MongoDB instance, but you can't use bacula to backup your MongoDB-as-a-service unless bacula switches to SSPL). This has been somewhat rectified in v2, which was submitted to OSI for review[3], but the spirit remains. Also note that judging whether something is a "MongoDB service" depends on how much of its value it derives from MongoDB, or whether its primary purpose is "MongoDB", criteria that are both rather vague in themselves. Finally, I worry that "enabling third parties to interact with the functionality of the Program […] remotely through a computer network" could be interpreted to also include Debian packages, in which case the above restrictions would apply to the Debian infrastructure as well. Given the above and the fact that I'm not aware of any similar precedent in the archive, I would like your opinion on the license's DFSG compatibility. My personal view is that while the license does not violate the DFSG directly, it also does not agree with the DFSG's spirit (esp. DFSG #6). If we deem the license to be DFSG-incompatible, then MongoDB will most likely have to be removed from the archive eventually; keeping the last AGPL-licensed version around without the ability to cherry-pick commits from upstream is not viable (definitely so for inclusion in stable), given the size and the complexity of the codebase. Regards, Apollon [0] https://lists.debian.org/debian-legal/2018/10/msg1.html [1] https://www.mongodb.com/licensing/server-side-public-license [2] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html [3]
Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library
Hi, On 23:08 Sat 24 Nov , Roberto C. Sanchez wrote: > Package: wnpp > Severity: wishlist > Owner: "Roberto C. Sanchez" > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > * Package name: mongo-cxx-driver > Version : 3.4.0 > Upstream Author : Mongo C++ Driver Team > > * URL : http://mongocxx.org/ > * License : Apache License 2.0 > Programming Lang: C++ > Description : MongoDB C++ client library > > libmongocxx is the officially supported MongoDB client library for C++ > applications. > > This package will be maintained by the upstream development team. Thanks for the ITP! Please consider joining the Debian MongoDB team[1] and maintaining the package as part of it. Cheers, Apollon [1] https://salsa.debian.org/mongodb-team
Bug#914178: xmobar: after update, xmobar often segfaults
Control: reassign -1 ghc Control: found -1 8.4.3+dfsg1-1 Control: fixed -1 8.4.4+dfsg1-1 Control: affects -1 xmobar Hi, On 09:07 Tue 20 Nov , Samuel Hym wrote: > After updating xmobar to 0.28.1-1, it often segfaults. I don’t really > know how to explore the cause. It seems to happen when some other > process opens a window (in particular dunst showing a notification), I > think. > Reverting to 0.24.5-1 solves the problem. Thanks for the report! This is most likely GHC bug #15260[1], which has been fixed in GHC 8.4.4. Hopefully, the next upload of xmobar will behave correctly. [1] https://ghc.haskell.org/trac/ghc/ticket/15260 Regards, Apollon
Bug#903161: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission denied
On 11:29 Mon 26 Nov , Marcus Frings wrote: > Hi Apollon, > > On Sun, 25 Nov 2018 20:22:11 +0200, Apollon Oikonomopoulos > wrote: > > > The issue described in the upstream mailing list is a bit different, > > as it applies to dovecot 2.3.1. Dovecot 2.3.1 by default set the > > stats-writer permissions to root:root, 0600. In 2.3.2 this was > > relaxed to root:dovecot, 0660, which means that if you add your plain > > user to the dovecot group, doveadm should work fine. Can you try this > > out? If it works, I'll add a note in README.Debian about running > > doveadm as non-root. > > I reverted my manual change of permissions > for /var/run/dovecot/stats-writer from 666 (suggested at the dovecot > mailing list) to 660 (Debian's current default) and added my > user to the dovecot group: I can confirm that running doveadm as normal > user now allows the nightly maintenance work (such as expunging mails). > Hence, it seems to work fine. > > But do you think that this is the way to go (to add ordinary users to > the dovecot group)? It all comes down to the following question: do we trust everyone on the system to submit dovecot stats or not? For some people it might be okay to just change permissions to 0666. OTOH, upstream seems to be more conservative about this. Regarding the dovecot group, upstream notes the following: commit 5cf6951e37bd37bb11b3335a3dbd029065143454 Author: Timo Sirainen Date: Wed Feb 7 13:03:23 2018 +0200 master: Add default_internal_group setting, defaulting to "dovecot" It's expected that this is the primary group of the default_internal_user. This group will be used to provide access to sockets that are generally required by all Dovecot processes, but aren't safe enough to be allowed completely open access from untrusted processes. So, it looks like the intention is precisely to allow more fine-grained access control for certain sockets. Finally, bear in mind that doveadm is an administrative tool and not meant to be run by "regular" users. For instance, it will fail if the user invoking it does not have read permissions on all files under /etc/dovecot/conf.d. Regards, Apollon
Bug#903161: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission denied
Control: tags -1 + moreinfo Hi, On 12:46 Sat 07 Jul , Marcus Frings wrote: > Package: dovecot-core > Version: 1:2.3.2-2 > Severity: normal > > Since dovecot 2.3 has entered sid, my nightly cron runs of doveadm (as > user) produce the error message, which is shown in the subject. > > This has already been reported upstream: > https://www.dovecot.org/list/dovecot/2018-January/110549.html > > (My situation is the same as described in the original upstream report!) > > A solution has also been provided by the developers: > https://www.dovecot.org/list/dovecot/2018-January/110552.html > > Hence, please consider changing the socket permissions (as suggested by > upstream) in the next package upgrade of dovecot. Thanks for the report and apologies for the late response. The issue described in the upstream mailing list is a bit different, as it applies to dovecot 2.3.1. Dovecot 2.3.1 by default set the stats-writer permissions to root:root, 0600. In 2.3.2 this was relaxed to root:dovecot, 0660, which means that if you add your plain user to the dovecot group, doveadm should work fine. Can you try this out? If it works, I'll add a note in README.Debian about running doveadm as non-root. Thanks, Apollon
Bug#904042: dovecot-sieve: Failed to initialize script execution: Invalid postmaster_address
Control: tags -1 + moreinfo upstream Hi, On 19:45 Wed 18 Jul , Graham Cobb wrote: > The problem appears to be that the default dovecot configuration > (/etc/dovecot/conf.d/15-lda.conf) > allows the postmaster_address setting to default. The default value is > postmaster@%d. > Unfortunately in some contexts the domain (%d) is not known and so the > postmaster_address > ends up with the invalid value 'postmaster@'. Thanks for the report! The default was changed in 2.3.4 to expand to postmaster@ if %d is empty. Can you check if it works for you so that I can close the bug? Thanks, Apollon
Bug#913728: ganeti-2.15: Can not export/import VMs using gnt-backup
Control: tags -1 moreinfo Hi again, On 09:06 Wed 14 Nov , Maximiliano Boscovich wrote: > root@lisa:~# gnt-backup export -n lisa acme.sf-az2-fe > Wed Nov 14 08:13:51 2018 Shutting down instance acme.sf-az2-fe > Wed Nov 14 08:15:53 2018 Creating a snapshot of disk/0 on node lisa > Wed Nov 14 08:15:53 2018 Starting instance acme.sf-az2-fe > Wed Nov 14 08:15:54 2018 Exporting snapshot/0 from lisa to lisa > Wed Nov 14 08:15:57 2018 snapshot/0 is now listening, starting export > Wed Nov 14 08:16:05 2018 snapshot/0 sent 0M, 0.0 MiB/s > Wed Nov 14 08:16:55 2018 - WARNING: import > 'import-disk0-2018-11-14_08_15_54-a5_3EV' on lisa failed: Exited due to > signal 15 > Wed Nov 14 08:16:55 2018 snapshot/0 failed to receive data: Exited due to > signal 15 (recent output: Child process didn't establish connection in time > (60s), sending SIGTERM\nsocat: W exiting on signal 15) > Wed Nov 14 08:16:55 2018 - WARNING: Aborting export > 'export-disk0-2018-11-14_08_15_59-6wxfk8' on > b2e076b8-499a-45a0-8a65-1a4d2005708f > Wed Nov 14 08:16:57 2018 - WARNING: export > 'export-disk0-2018-11-14_08_15_59-6wxfk8' on lisa failed: Exited due to > signal 15 > Wed Nov 14 08:16:57 2018 snapshot/0 failed to send data: Exited due to > signal 15 (recent output: DUMP: Date of this level 0 dump: Wed Nov 14 > 08:15:59 2018\n DUMP: Dumping > /dev/mapper/vg--ganeti-76049ec2--8232--413d--8151--d263c3efa80e.disk0.snap-1 > (an unlisted file system) to standard output\n DUMP: Label: none\n DUMP: > Writing 10 Kilobyte records\n DUMP: mapping (Pass I) [regular files]\n > DUMP: mapping (Pass II) [directories]\n DUMP: estimated 247771 blocks.\n > DUMP: Volume 1 started with block 1 at: Wed Nov 14 08:15:59 2018\n DUMP: > dumping (Pass III) [directories]\n DUMP: DUMP: The ENTIRE dump is > aborted.\nSignal on pipe: cannot recover\n DUMP: The ENTIRE dump is > aborted.\nsocat: W exiting on signal 15) > Wed Nov 14 08:16:57 2018 Removing snapshot of disk/0 on node lisa > Wed Nov 14 08:16:57 2018 - WARNING: Some disk exports have failed; there > may be leftover data for instance acme.sf-az2-fe on node lisa > Failure: command execution error: > Export failed, errors in export finalization, disk export: disk(s) 0 I can reproduce this when blocking the import/export connections between nodes. Are you running a firewall on the machine? If so, does it filter traffic on the loopback interface? Keep in mind that import/export uses two completely random, high ports for the transfer. Regards, Apollon
Bug#913728: ganeti-2.15: Can not export/import VMs using gnt-backup
Hi, On 09:06 Wed 14 Nov , Maximiliano Boscovich wrote: > I also tried to import a instances exported from another cluster, > and I > had the same result. > I think its a problem related with SOCAT, i saw some other bugs > reported, but anyone match exactly with this problem and output. Thanks for the report! Can you please share any relevant information from /var/log/ganeti/node-daemon.log on lisa? Regards, Apollon
Bug#908612: stretch-pu: package ganeti/2.15.2-7+deb9u3
On 17:42 Sat 03 Nov , Georg Faerber wrote: > Hi Apollon, > > Not sure if you did the upload already, but the upload window for 9.6, > scheduled for the upcoming weekend, is closing this weekend. (Sorry for > the noise in case that's already done; and in any case, thanks for your > work, as always.) > > Cheers, > Georg Thanks for the heads-up, uploaded! Cheers, Apollon
Bug#908112: possible fix
Control: tags -1 pending Hi, On 14:48 Wed 31 Oct , Mauro Gaioni wrote: > See #895599 > Apply fix in > https://github.com/ganeti/ganeti/commit/5f90a0f64bf5fee7fe353a95d02c79736a5943c5 > > For me works. > Regards, Mauro Yes, this is already queued up for a stable update. Thanks!
Bug#910323: nmu: dovecot-antispam_2.0+20171229-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Please schedule a binNMU for dovecot-antispam to build against dovecot 2.3.3. Regards, Apollon nmu dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "Rebuild against dovecot 2.3.3" dw dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "dovecot-dev (>= 1:2.3.3-1)"
Bug#908136: src:h2o: FTBFS on amd64
On 15:53 Fri 14 Sep , Apollon Oikonomopoulos wrote: > The tests in t/50reverse-proxy-proxy-protocol.t and > t/40session-ticket.t report no session reuse with OpenSSL 1.1.1 and > need further investigation. t/40session-ticket.t is a false positive: in TLSv1.3 session information is sent after the handshake has finished, and the way s_client is invoked in the test means that it can exit before it receives the session data. Until this is fixed upstream, I patched the test to always use TLSv1.2. t/50reverse-proxy-session-resumption.t needs further investigation, but it seems that H2O's client code doesn't support session resumption for TLSv1.3 upstreams (which is H2O itself in the test case). I'm tempted to just disable the test even if resumption is indeed broken for TLSv1.3 upstreams.
Bug#908136: src:h2o: FTBFS on amd64
Control: tags -1 confirmed upstream Hi, On 15:42 Thu 06 Sep , Chris Hofstaedtler wrote: > Package: src:h2o > Version: 2.2.5+dfsg1-6 > Severity: serious > > Dear Maintainer, > > when trying to build h2o from source on amd64, inside sbuild, it fails: > > h2o server (pid:14780) is ready to serve requests > fetch-ocsp-response (using OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018) > failed to extract ocsp URI from examples/h2o/server.crt > [OCSP Stapling] disabled for certificate file:examples/h2o/server.crt > > # Failed test at t/50reverse-proxy-session-resumption.t line 118. > # got: '0' > # expected: '1' > killing /<>/obj-x86_64-linux-gnu/h2o... received SIGTERM, > gracefully shutting down > killed (got 0) > killing /<>/obj-x86_64-linux-gnu/h2o... received SIGTERM, > gracefully shutting down > killed (got 0) > # Looks like you failed 1 test of 5. > > # Failed test 'lifetime' > # at t/50reverse-proxy-session-resumption.t line 121. > > And further failures. > Please also see the attached build log. Thanks for the report! It looks like the tests in t/50access-log.t and t/40ssl-cipher-suite.t are failing when h2o is built against OpenSSL 1.1.1, because they don't expect OpenSSL to support TLSv1.3 and are confused by TLSv1.3-related output (mostly cipher names). The tests in t/50reverse-proxy-proxy-protocol.t and t/40session-ticket.t report no session reuse with OpenSSL 1.1.1 and need further investigation. That said, I intend to move away from PicoTLS and towards OpenSSL for TLSv1.3 support in H2O if it works hassle-free. Cheers, Apollon
Bug#908612: stretch-pu: package ganeti/2.15.2-7+deb9u3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Dear SRMs, I'd like to update ganeti in Stretch once more, fixing the following issues: - The fix for #895599 that was included in +deb9u2 unfortunately was incomplete; I failed to cherry-pick an additional patch rendering the fix ineffective. - Ganeti uses an embedded CA to establish trust between cluster nodes. This CA signs certificates using SHA-1 digests by default and SHA-1-signed certificates are not acceptable by OpenSSL when a security level of 2 or higher is in effect. OpenSSL in Buster will (most probably) have a security level of 2 on by default, meaning that upon upgrading to Buster ganeti clusters will experience breakage. Since SHA-1 is weak and deprecated anyway, I would like to backport a change from unstable to make the CA use SHA-256 for certificate signatures, to allow cluster administrators to upgrade their crypto before actually upgrading to Buster. See #907216 and #907569 for more information. - The bash completion script shipped in Stretch is ineffective. Although nothing changed on Ganeti's side between Jessie and Stretch, bash completion stopped working when dh_bash-completion stopped placing scripts in /etc/bash_completion.d/ (see #668254) and moved to /usr/share/bash-completion/ instead. This change broke ganeti's completion because it is not autoloadable: there's only one script which does not match any command name (see #864755). This has already been fixed in unstable by symlinking the completion file to all supported command names. This being really a regression from a functional point of view, I would like to backport the fix to Stretch. Attached is the full source debdiff for the proposed update. I might update the wording in d/NEWS and the `gnt-cluster verify' output before uploading, but functionally I don't expect any further changes. Regards, Apollon diff -Nru ganeti-2.15.2/debian/changelog ganeti-2.15.2/debian/changelog --- ganeti-2.15.2/debian/changelog 2018-06-11 17:42:10.0 +0300 +++ ganeti-2.15.2/debian/changelog 2018-09-08 20:22:03.0 +0300 @@ -1,3 +1,14 @@ +ganeti (2.15.2-7+deb9u3) stretch; urgency=medium + + * Properly verify SSL certificates during VM export (#2) (Closes: #895599, #908112) + * Sign generated certificates using SHA256 instead of SHA1 (Closes: #907569) ++ d/NEWS: ask users to run gnt-cluster renew-crypto ++ cluster verify: warn about weak certificates + * Make bash completions autoloadable (Closes: #864755) ++ Cleanup obsolete /etc/bash_completion.d/ganeti + + -- Apollon Oikonomopoulos Sat, 08 Sep 2018 20:22:03 +0300 + ganeti (2.15.2-7+deb9u2) stretch; urgency=medium * Properly verify SSL certificates during VM export (Closes: #895599) diff -Nru ganeti-2.15.2/debian/ganeti.maintscript ganeti-2.15.2/debian/ganeti.maintscript --- ganeti-2.15.2/debian/ganeti.maintscript 1970-01-01 02:00:00.0 +0200 +++ ganeti-2.15.2/debian/ganeti.maintscript 2018-09-08 20:22:03.0 +0300 @@ -0,0 +1 @@ +rm_conffile /etc/bash_completion.d/ganeti 2.15.2-7+deb9u3~ diff -Nru ganeti-2.15.2/debian/gbp.conf ganeti-2.15.2/debian/gbp.conf --- ganeti-2.15.2/debian/gbp.conf 2018-06-11 17:42:10.0 +0300 +++ ganeti-2.15.2/debian/gbp.conf 2018-09-08 20:22:03.0 +0300 @@ -4,6 +4,8 @@ upstream-tag = v%(version)s upstream-tree = tag upstream-branch = stable-2.15 +debian-branch = debian/stable/stretch +dist = stretch [git-buildpackage] export-dir = ../build-area/ diff -Nru ganeti-2.15.2/debian/NEWS ganeti-2.15.2/debian/NEWS --- ganeti-2.15.2/debian/NEWS 2018-06-11 17:42:10.0 +0300 +++ ganeti-2.15.2/debian/NEWS 2018-09-08 20:22:03.0 +0300 @@ -1,3 +1,27 @@ +ganeti (2.15.2-7+deb9u2) stretch; urgency=medium + + This version changes Ganeti's internal CA, which is used to secure + intra-cluster RPC, to use SHA256 digests when signing certificates. + Previously issued certificates were signed using SHA1 and will be rejected + by newer OpenSSL versions, causing cluster malfunction. This will be a + problem with the upcoming Debian Buster release, so Ganeti's CA must be + switched over to SHA-256 before upgrading to Buster. + + After upgrading all nodes to this package version, please run + +gnt-cluster renew-crypto --new-cluster-certificate + + at a convenient time to re-generate the cluster's certificates using the new + signing algorithm. This operation does not incur any instance downtime, + however you will not be able to issue any gnt-* commands while renew-crypto + is running. + + If you are using built-in certificates for RAPI and/or spice, please + consider adding --new-rapi-certificate and --new-spice-certificate + respectively to the above command. + + -- Apollon Oikonomopoulos Mon, 03 Sep 2018 14:36:39 +0300 + ganeti
Bug#895599: The fix is incomplete
Unfortunately the fix for this bug is incomplete, as reported on the ganeti mailing list[1]. It looks like I forgot to cherry-pick upstream commit 5f90a0f64bf5fee7fe353a95d02c79736a5943c5[2]. [1] https://groups.google.com/forum/#!topic/ganeti/0jh6xxI3bM4 [2] https://github.com/ganeti/ganeti/commit/5f90a0f64bf5fee7fe353a95d02c79736a5943c5
Bug#907569: ganeti: SHA256 certificate support should be backported to stretch to allow smooth upgrades
Source: ganeti Version: 2.15.2-7+deb9u2 Severity: important Tags: patch Following up on #907216, the patch to use SHA256 for certificate signing should be backported to Stretch to allow users to switch to SHA256 certificates before upgrading to Buster. Certificate renewal has to take place in a co-ordinated fashion across a ganeti cluster (using `gnt-cluster upgrade`) and cannot be done for each node separately in the package's maintainer scripts, which means that we cannot rely on APT's sequencing between ganeti and libssl1.1 to resolve the situation on dist-upgrade. Backporting the patch will allow users to prepare their clusters before upgrading to Buster and avoid the breakage caused by the installation of OpenSSL 1.1.1.
Bug#907216: ganeti: autopkgtest needs update for new version of openssl
On 12:38 Mon 27 Aug , Apollon Oikonomopoulos wrote: > So, it turns out ganeti's internal CA is using SHA1 to sign all > generated certificates, which - by the looks of it - is not acceptable > by OpenSSL 1.1. > > I'll need some time to investigate and see how we should handle this. The good news is that it's pretty straightforward to get Ganeti to issue SHA256-signed certificates. The bad news is that this will need a cluster-wide crypto material renewal (CA cert + client certs) using `gnt-cluster upgrade', which must be performed *after* installing the updated package on *all* nodes and cannot be done as part of a maintainer script (and thus can't be properly sequenced using Breaks). I still need to investigate the following bits: - Whether I can get ganeti-luxid to use SECLEVEL=1 so that it won't refuse to load the existing client certificates and thus won't cause breakage during the time after the package installation and before gnt-cluster upgrade. A quick look here says that this is not possible, since libcurl seems to set the cipher list (which is used to piggy-back security level information) *after* loading the client certificates[1]. Using curl(1) confirms this as well. [1] https://github.com/curl/curl/blob/curl-7_61_0/lib/vtls/openssl.c#L2396 - Whether a cluster that doesn't work because of SECLEVEL=2 + SHA-1 certs can be restored simply by using `gnt-cluster renew-crypto --new-cluster-cert`, which will greatly simplify things. IOW, whether `gnt-cluster renew-crypto` works without using Ganeti's RPC. Finally, to ensure a smooth upgrade, SHA256 support must be backported to Stretch to allow users to upgrade their crypto material and upgrade to Buster without problems. Regards, Apollon
Bug#907216: ganeti: autopkgtest needs update for new version of openssl
Control: tags -1 confirmed Hi Paul, Thanks for the report! On 21:47 Fri 24 Aug , Paul Gevers wrote: > Source: ganeti > Version: 2.16.0~rc2-4 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: needs-update > Control: affects -1 src:openssl > Control: block 907015 by -1 > > Dear maintainers, > > With a recent upload of openssl the autopkgtest of ganeti started to > fail in testing. I copied the output below. > > Of course, openssl shouldn't just break your autopkgtest (or even worse, > your package), but the change in openssl was intended and your package > needs to update to the new situation. If needed, please change the bug's > severity. > > If this is a real problem in your package (and not only in your > autopkgtest), the right binary package(s) from openssl should really add > a versioned Breaks on the unfixed version of (one of your) package(s), > hence I added a blocking relation on the openssl bug that tracks that. > Note: the Breaks is nice even if the issue is only in the autopkgtest as > it helps the migration software to figure out the right versions to > combine in the tests. > > A quote from the openssl maintainer about the openssl update: > " > This is probably the result of the default openssl.cfg now having: > [system_default_sect] > MinProtocol = TLSv1.2 > CipherString = DEFAULT@SECLEVEL=2 > > Where the SECLEVEL 2 requires a 112 / 2048 bit security level. > " >From the test artifacts I can dig out the following interesting bit: code: CurlSSLCertProblem, explanation: could not load PEM client certificate, OpenSSL error error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak which I now saw was also present in the excerpt you attached with the bug report. So, it turns out ganeti's internal CA is using SHA1 to sign all generated certificates, which - by the looks of it - is not acceptable by OpenSSL 1.1. I'll need some time to investigate and see how we should handle this. Regards, Apollon
Bug#906460: [Pkg-puppet-devel] Bug#906460: facter: FTBFS in buster (catching polymorphic type by value)
Hi Santiago, On 14:03 Thu 23 Aug , Santiago Vila wrote: > retitle 906460 facter: FTBFS in buster (catching polymorphic type by value) > thanks > > On Thu, Aug 23, 2018 at 06:25:00AM +, Niels Thykier wrote: > > > This package was just rebuilt successfully in sid as a part of the > > libleatherman transition (which also matches the build logs of the > > reproducible builds project). > > > > Can you confirm the problem still exist? > > I confirm that it FTBFS in buster and builds ok in sid. > > Most probably, there is a buggy build-dependency somewhere, but I > don't know which one it is (I would prefer to reassign the bug). > > I usually try to avoid buster-only bugs, but once they are reported, > I'm not very happy with them being closed without a minimum of > investigation on the side of package maintainers. > > But if you think this can/should be closed, please go ahead and close it. I already closed it (using control commands to do some reassignment and not -done, so you didn't get any mail ):. This was a bug in leatherman and has been fixed in 1.4.2+dfsg-1. Thanks, Apollon
Bug#906460: [Pkg-puppet-devel] Bug#906460: facter: FTBFS in buster/sid (catching polymorphic type by value)
Control: tags -1 - moreinfo Control: reassign -1 leatherman Control: found -1 1.4.0+dfsg-1 Control: close -1 1.4.2+dfsg-1 Hi Santiago, Niels, On 06:25 Thu 23 Aug , Niels Thykier wrote: > Control: tags -1 moreinfo > > On Fri, 17 Aug 2018 19:20:54 + Santiago Vila wrote: > > Package: src:facter > > Version: 3.11.0-1 > > Severity: serious > > Tags: ftbfs > > > > Dear maintainer: > > > > I tried to build this package in buster but it failed: > > > > > > [...] > > > > > The build was made with "dpkg-buildpackage -B" in my autobuilder. > > Most probably, it also fails here in reproducible builds: > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/facter.html > > > > where you can get a full build log if you need it. > > > > If this is really a bug in one of the build-depends, please use reassign > > and affects, > > so that this is still visible in the BTS web page for this package. > > > > Thanks. > > Hi, > > This package was just rebuilt successfully in sid as a part of the > libleatherman transition (which also matches the build logs of the > reproducible builds project). > > Can you confirm the problem still exist? Thanks for the report and feedback. The build failure was caused by -Werror which was sourced from leatherman's CMake configuration (and was also responsible for #897778). This has been resolved in leatherman 1.4.2+dfsg-1, that's why the build succeeded. Regards, Apollon
Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails
Control: tag -1 - moreinfo
Hi,
On 13:50 Thu 02 Aug , Andreas Beckmann wrote:
> Control: tag -1 moreinfo
> Control: severity -1 important
>
> On 2018-08-02 09:00, Apollon Oikonomopoulos wrote:
> > Finally, I want to stress again that the root cause of all this is the
> > flawed libcurl3 → libcurl4 transition: if the OpenSSL API changes the
>
> Let's wait for libcurl3 to leave testing, that might clean up the
> upgrade path automatically. The pure existence of libcurl3 in testing
> causes trouble on a few other upgrade paths as well, since it is not
> always considered as a candidate for removal.
>
> If that doesn't work, ganeti might need to add Breaks or Conflicts
> against ganeti-{haskell,htools}-2.15 to ensure they are removed before
> the new ganeti is unpacked. This should hopefully be resolvable without
> updating the version in stable.
Unfortunately this won't help: ganeti-*-2.15 and ganeti-*-2.16 are
designed to be co-installable (hence the different package names)
and in fact they must both be installed and configured for the cluster
upgrade to take place. IOW, the intended behavior when dist-upgrading is
to end up with *both* sets of packages installed and configured, and
Breaks/Replaces defeats this purpose.
As libcurl4 and libcurl3 conflict, a set of packages that collectively
depends on both will not be installable. So we'll either need a version
of ganeti-*-2.15 that depends on libcurl4 in buster (because we can't
have it in stretch, as stretch doesn't have libcurl4), or a version that
uses a different libcurl variant in stretch (and buster presumably).
I tend to think the former is more robust.
Apollon
Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails
[ Adding the release team in the loop ] Hello Andreas, Thanks for the report. On 11:49 Wed 01 Aug , Andreas Beckmann wrote: > (Reading database ... 7847 files and directories currently installed.) > Removing ganeti-htools-2.15 (2.15.2-7+deb9u2) ... > dpkg: error processing package ganeti-htools-2.15 (--remove): >installed ganeti-htools-2.15 package pre-removal script subprocess > returned error exit status 30 > Removing ganeti-haskell-2.15 (2.15.2-7+deb9u2) ... > dpkg: error processing package ganeti-haskell-2.15 (--remove): >installed ganeti-haskell-2.15 package pre-removal script subprocess > returned error exit status 30 This is the prerm script of ganeti-htools-2.15 and ganeti-haskell-2.15 failing because ganeti 2.16 has not been configured yet, and so the active version is still 2.15. Ganeti is a clustered service and all nodes must be running the same minor version. Ganeti includes a mechanism to perform cluster-wide upgrades itself, which works by having multiple minor versions co-installed (hence the versioned package names) and calling `gnt-cluster upgrade', after which all nodes are switched to the new version in a coordinated fashion. This is a bit similar to the way postgres packages work, but in a multi-node setup. Unfortunately all of this breaks because of the libcurl3 -> libcurl4 transition in buster: > dpkg: libcurl3:amd64: dependency problems, but removing anyway as >you requested: >ganeti-htools-2.15 depends on libcurl3 (>= 7.16.2). >ganeti-haskell-2.15 depends on libcurl3 (>= 7.16.2). > Removing libcurl3:amd64 (7.52.1-5+deb9u6) ... The 2.15 packages depend on libcurl3 which is conflicted and replaced by libcurl4. As the 2.15 packages do not exist in buster, APT has to remove them together with libcurl3. For the reasons behind the conflict between libcurl4 and libcurl3, see #858398. Now, I could "fix" this for piuparts by allowing the packages to be uninstalled, no questions asked, *but* this would just cause user clusters to break on stretch → buster upgrades. Given that in #858398 it was decided not to do a SONAME bump for libcurl4 (which would have avoided the problem in the first place), the way I see it, there are two possible solutions: 1. Do a *stable update* for ganeti, rebuilding it against curl/gnutls (possibly after doing so for unstable as well). Note that the original reasons for using OpenSSL (#751886) should in theory be resolved, since GHC does not take over GMP heap management as of 7.10. 2. Upload a new ganeti-2.15 source in unstable, building *only* the versioned binary packages (ganeti-haskell-2.15 and ganeti-htools-2.15) which will depend on libcurl4 and will be used only to facilitate upgrades from stretch. ganeti-2.15 will be removed from unstable after buster is out. I'm not a big fan of changing the crypto implementation on a stable update, especially since there have been issues in the past. OTOH, maintaining 2.15, even at best-effort level, for another stable release is not ideal either. Finally, I want to stress again that the root cause of all this is the flawed libcurl3 → libcurl4 transition: if the OpenSSL API changes the library's ABI, it should be part of the library name, just as we distinguish between curl/gnutls and curl/nss. A Conflicts/Replaces between libraries - especially without a Provides - is a clear sign that something's very wrong. I do realize that ganeti is a corner-case, since the versioned packages for 2.15 only exist in stretch and not in buster, but still this will also affect any locally-built or 3rd-party packages as well. Does anyone from the release team have an opinion on any of the above? Regards, Apollon
Bug#902979: nmu: dovecot-antispam_2.0+20171229-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Please schedule a binNMU for dovecot-antispam to build against dovecot 2.3. Regards, Apollon nmu dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "Rebuild against dovecot 2.3.2" dw dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "dovecot-dev (>= 1:2.3.2-1)"
Bug#901331: stretch-pu: package ganeti/2.15.2-7+deb9u2
On 18:41 Sun 01 Jul , Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Mon, 2018-06-11 at 18:02 +0300, Apollon Oikonomopoulos wrote: > > I would like to update ganeti in Stretch to resolve #895599, whereby > > ganeti fails to "export" (aka dump) VMs because of an SSL > > verification > > error. The bug is fixed by cherry-picking an upstream commit, > > already > > included in 2.16 which is in unstable. > > Please go ahead. > Uploaded! Thanks, Apollon
Bug#902151: RM: ganeti [mips mipsel] -- ROM; RC-buggy, missing B-Ds
Package: ftp.debian.org Severity: normal Dear FTP Masters, I would like to ask the removal of ganeti from unstable on mips and mipsel. The current package is out-of-date and RC-buggy (FTBFS) and the fixed package does not build because of a chain of missing Haskell dependencies leading up to #899166, with unknown ETA. Frankly, ganeti on mips/mipsel has best-effort support and unclear usefulness. As long as it builds, I'm happy to maintain it, but having mips/mipsel block migrations of fixed packages to testing is clearly a priority inversion. Regards, Apollon
Bug#901946: nmu: dovecot-antispam_2.0+20171229-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, Please schedule a binNMU for dovecot-antispam to be built against the current dovecot version. Regards, Apollon nmu dovecot-antispam_2.0+20171229-1 . ANY . unstable . -m "Rebuild against dovecot 2.2.36"
Bug#901331: stretch-pu: package ganeti/2.15.2-7+deb9u2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear SRMs,
I would like to update ganeti in Stretch to resolve #895599, whereby
ganeti fails to "export" (aka dump) VMs because of an SSL verification
error. The bug is fixed by cherry-picking an upstream commit, already
included in 2.16 which is in unstable.
Full source debdiff attached.
Regards,
Apollon
diff -Nru ganeti-2.15.2/debian/changelog ganeti-2.15.2/debian/changelog
--- ganeti-2.15.2/debian/changelog 2017-10-03 17:31:05.0 +0300
+++ ganeti-2.15.2/debian/changelog 2018-06-11 17:42:10.0 +0300
@@ -1,3 +1,9 @@
+ganeti (2.15.2-7+deb9u2) stretch; urgency=medium
+
+ * Properly verify SSL certificates during VM export (Closes: #895599)
+
+ -- Apollon Oikonomopoulos Mon, 11 Jun 2018 17:42:10 +0300
+
ganeti (2.15.2-7+deb9u1) stretch; urgency=medium
* Depend on lsb-base (>= 3.0.6) for init-functions.
diff -Nru ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch
--- ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch 1970-01-01 02:00:00.0 +0200
+++ ganeti-2.15.2/debian/patches/impexpd-fix-certificate-verification-with-new-socat.patch 2018-06-11 17:42:10.0 +0300
@@ -0,0 +1,55 @@
+From 7bb03511f6b13f83cc7cbc5fe6a30bd46105b0bd Mon Sep 17 00:00:00 2001
+From: Apollon Oikonomopoulos
+Date: Wed, 20 Dec 2017 12:57:12 +0200
+Subject: [PATCH] impexpd: fix certificate verification with new socat versions
+
+Socat versions after 1.7.3 verify the server certificate's subject
+against either the hostname, or the openssl-commonname option. Since
+ganeti uses 'ganeti.example.com' for all self-signed certs, certificate
+verification will fail, as socat will be told to connect to the node
+using its proper name.
+
+Fix this by passing the openssl-commonname option. Since this option is
+only available on newer socat versions and older socat versions will
+break when passed the unknown option, we need to parse `socat -V` output
+to check if we need to specify the option or not.
+
+This fixes #1226.
+
+Signed-off-by: Apollon Oikonomopoulos
+---
+ lib/impexpd/__init__.py | 18 ++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/lib/impexpd/__init__.py b/lib/impexpd/__init__.py
+index 97a9716cc..850bdb987 100644
+--- a/lib/impexpd/__init__.py
b/lib/impexpd/__init__.py
+@@ -197,6 +197,24 @@ class CommandBuilder(object):
+ "intervall=1",
+ ] + common_addr_opts
+
++ # For socat versions >= 1.7.3, we need to also specify
++ # openssl-commonname, otherwise server certificate verification will
++ # fail.
++ socat = utils.RunCmd([SOCAT_PATH, "-V"])
++ # No need to check for errors here. If -V is not there, socat is really
++ # old. Any other failure will be handled when running the actual socat
++ # command.
++ for line in socat.output.splitlines():
++match = re.match(r"socat version ((\d+\.)*(\d+))", line)
++if match:
++ try:
++version = tuple(int(x) for x in m.group(1).split('.'))
++if version >= (1, 7, 3):
++ addr2 += ["openssl-commonname=%s" % constants.X509_CERT_CN]
++ except TypeError:
++pass
++ break
++
+ else:
+ raise errors.GenericError("Invalid mode '%s'" % self._mode)
+
+--
+2.17.1
+
diff -Nru ganeti-2.15.2/debian/patches/series ganeti-2.15.2/debian/patches/series
--- ganeti-2.15.2/debian/patches/series 2017-10-03 14:09:55.0 +0300
+++ ganeti-2.15.2/debian/patches/series 2018-06-11 17:42:10.0 +0300
@@ -16,3 +16,4 @@
use-hv-class-to-check-for-migration.patch
do-not-specify-socat-ssl-method.patch
fix-failover-from-dead-node.patch
+impexpd-fix-certificate-verification-with-new-socat.patch
Bug#897553: [Pkg-puppet-devel] Bug#897553: leatherman: FTBFS: dh_auto_test: cd obj-x86_64-linux-gnu && make -j8 -Oline test ARGS\+=-j8 returned exit code 2
Control: severity -1 normal Control: tags -1 - buster sid + pending Control: retitle -1 leatherman should B-D on ruby directly Hi, Thanks for the report! On 22:58 Wed 02 May , Lucas Nussbaum wrote: > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > > Relevant part (hopefully): > > could not locate a ruby library As discussed in #897556, this was caused by the temporary removal of the rake → ruby dependency (see #897279) and has since been fixed. I'm lowering severity but will add a direct dependency against ruby nevertheless. Regards, Apollon
Bug#897556: [Pkg-puppet-devel] Bug#897556: facter: FTBFS: dh_install: missing files, aborting
Control: severity -1 normal Control: tags -1 - moreinfo sid buster + pending Control: retitle -1 facter should B-D directly on ruby Hi, On 13:41 Thu 07 Jun , Juhani Numminen wrote: > On Wed, 2 May 2018 22:58:19 +0200 Lucas Nussbaum > wrote: > > Source: facter > > Version: 3.11.0-1 > > Severity: serious > > Tags: buster sid > > User: debian...@lists.debian.org > > Usertags: qa-ftbfs-20180502 qa-ftbfs > > Justification: FTBFS on amd64 > > > > dh_install: Cannot find (any matches for) "usr/lib/ruby" (tried in ., > > > debian/tmp) > > > > > > dh_install: facter missing files: usr/lib/ruby > > > dh_install: missing files, aborting > > > make: *** [debian/rules:10: binary] Error 25 > > > > The full build log is available from: > >http://aws-logs.debian.net/2018/05/02/facter_3.11.0-1_unstable.log > > The build log also contains: > > -- Could NOT find Ruby (missing: RUBY_EXECUTABLE RUBY_INCLUDE_DIR > > RUBY_LIBRARY) (Required is at least version "1.9") > > However, my local rebuild succeeds, and there's currently no FTBFS at > Reproducible Builds either, so I added the moreinfo tag. > > https://tests.reproducible-builds.org/debian/history/facter.html This seems to have been caused by the (temporary) removal of the rake → ruby dependency in rake 12.3.1-2 (see #897279). The build requires /usr/bin/ruby to detect the Ruby version, so it wouldn't harm if facter would B-D directly on ruby, even if this is not necessary. I'm lowering severity since this not RC, but will add the dependency anyway. Thanks, Apollon
Bug#884462: Please update mongodb to 3.6
Control: tags -1 pending Hi Robie, On 13:49 Mon 16 Apr , Robie Basak wrote: > I've updated Ubuntu to mongodb 3.6. > > Rather than spam the bug with the entire patchset, you can view the > changes I had to make here: > > https://git.launchpad.net/ubuntu/+source/mongodb/log?id=upload/1%253.6.3-0ubuntu1 Thanks for the patches! I had already started working on 3.6 and I cherry-picked the "strip test binaries" patch which was causing me build trouble as well. I'll probably upload the package to unstable in the following days. Regards, Apollon
Bug#894488: release.debian.org: Please let mongodb transition to testing; i386 is not built anymore
Hi Emilio, On 13:35 Sat 31 Mar , Emilio Pozuelo Monfort wrote: > On 31/03/18 08:57, Apollon Oikonomopoulos wrote: > > Package: release.debian.org > > Severity: normal > > > > Dear Release Team, > > > > Following upstream's decision to drop 32-bit support, the mongodb source > > Was it so hard to maintain? Unfortunately, yes. We maintained i386 support for 3.2, despite upstream dropping it. However the new storage engine, Wiredtiger, was written from scratch for 64-bit architectures only and never supported i386. We got away with setting MMapv1 as the default engine for i386 in 3.2, but that also broke in 3.4, making me think that it probably did not make much sense to continue supporting i386 ourselves. > > as of 3.4 no longer builds an i386 package. AFAICT, this breaks > > britney's rules for arch:all -> arch:any dependencies and does not let > > the package migrate to testing. > > > > Could you please let mongodb through manually? > > force-hint added, it should migrate in the next britney run. Thanks! Apollon
Bug#894488: release.debian.org: Please let mongodb transition to testing; i386 is not built anymore
Package: release.debian.org Severity: normal Dear Release Team, Following upstream's decision to drop 32-bit support, the mongodb source as of 3.4 no longer builds an i386 package. AFAICT, this breaks britney's rules for arch:all -> arch:any dependencies and does not let the package migrate to testing. Could you please let mongodb through manually? Regards, Apollon -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (90, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#894400: RM: mongodb [i386] -- ANAIS; i386 support dropped upstream
Package: ftp.debian.org Severity: normal Dear FTP masters, Please remove the i386 binary packages for mongodb from unstable. Upstream has dropped support for 32-bit platforms and so i386 is not built from source anymore. Regards, Apollon
Bug#892872: redsocks: Redsocks 0.5 is incompatible with libevent 2.1
Control: severity -1 important Control: tags -1 + confirmed upstream Hi, thanks for the report! On 08:11 Wed 14 Mar , CUI Hao wrote: > Package: redsocks > Version: 0.5-1+b1 > Severity: grave > Tags: upstream > Justification: renders package unusable [ Downgrading severity, as the package is not completely unusable ] > Dear Maintainer, > > Redsocks doesn't function on Debian buster. It hangs after receiving > packets direct by iptables and never redirects packets to proxy. > > It seems redsocks 0.5 is incompatible with libevent 2.1 which is in > buster and sid's repo. Here are related upstream issues: > https://github.com/darkk/redsocks/issues/107 > https://github.com/darkk/redsocks/issues/122 Doing some preliminary testing with the config in #122, this seems to be limited to the http-relay and http-connect modes. At least on my system, socks5 works fine. I'll do some more experiments and see if I can get it fixed. Regards, Apollon
Bug#718819: python3 has circular Depends on dh-python
On 13:01 Tue 20 Mar , Apollon Oikonomopoulos wrote: > Hi, > > [Following up on #718819] > As illustrated by #718819, python3 now pulls in dpkg-dev transitively > via dh-python, which on many systems will also pull in build-essential > as a Recommends. s/718819/893477/, sorry!
Bug#718819: python3 has circular Depends on dh-python
Hi, [Following up on #718819] On 13:04 Sun 05 Feb , Piotr Ozarowski wrote: > [Faidon Liambotis, 2017-02-05] > > Hi! > > > > On Tue, Aug 06, 2013 at 10:21:43AM +0200, Matthias Klose wrote: > > > > There is a circular dependency between python3 and dh-python: > > > > > > > > python3 :Depends: dh-python > > > > dh-python :Depends: python3 (>= 3.2.3-3~) > > > > > > expected. > > > > Could you perhaps explain why is that the case? I came looking in the > > BTS because I found it odd that the python3 package, presumably intended > > for end-users (or end-systems), just wanting to run python3 code, > > depends on dh-python, a package that contains "Debian helper tools for > > packaging Python libraries and applications". > > that's because many packages still build depend on python3 without > dh-python (dh_python3 used to be shipped in python3 package). dh-python > build depends on python3-minimal only so it shouldn't be that big of a > problem. python3 will drop dh-python dependency in Buster (it's too late > to deal with all the FTBFS in Strech) As illustrated by #718819, python3 now pulls in dpkg-dev transitively via dh-python, which on many systems will also pull in build-essential as a Recommends. It appears there are roughly 250 source packages[1] in the archive that call dh_python3 (either directly, or via dh) and do not Build-Depend(-Indep) on dh-python. This will require an MBF, so if we want the dependency gone by the time Buster is out, now is probably a good time to act. Regards, Apollon [1] Obtained by diff'ing the results of the following query on codesearch.d.n: dh_python3|--with[= ][\S]*python3 path:debian/rules* against grep-dctrl -n -w -F Build-Depends,Build-Depends-Indep -s Package dh-python on sid main
Bug#893477: dh-python: New depencency (dpkg-dev) forces the installation of unwanted packages
Control: reassign -1 python3 Control: severity -1 important Control: merge 718819 -1 Hi, Thanks for the report! On 10:38 Mon 19 Mar , jim_p wrote: > Package: dh-python > Version: 3.20180313 > Severity: normal > > Dear Maintainer, > > Today's upgrade to dh-python from 3.20180313 to 3.20180318 wants to install > dpkg-dev and, in turn, dpkg-dev wants > to install all its direct dependencies (patch, make, binutils etc), which is > a 30+MB loss of space for me. It was > not a dependency of the previous version which was released 5 days ago, so I > was wondering if it can be avoided. > Removing dh-python also removes stuff I really need, like icdiff, youtube-dl, > reportbug etc. dh-python is a packaging tool, so it's pretty acceptable for it to depend on dpkg-dev. The problem is that python3 depends on dh-python (and thus transitively on dpkg-dev). This causes dpkg-dev to be pulled in whenever a python3 program or library is installed, something which is not strictly necessary. There is a separate bug (#718819) filed already for this issue, so I'm merging these two bugs. Dear Python maintainers, would it be possible to drop the dh-python dependency from python3, as stated in #718819? This appears to be a good point in Buster's release cycle to do so. Regards, Apollon
Bug#892955: [Pkg-mongodb-maintainers] Bug#892955: mongodb-server: enabling the 'oplog' config option makes server fail to start
Hi, Thanks for the report! On 21:13 Wed 14 Mar , Toni Mueller wrote: > Package: mongodb-server > Version: 1:3.2.11-2+deb9u1 > Severity: normal > > I just installed mongodb and wanted to get more detailed logging, so I > removed the comment from 'oplog = 0' and switched to 7: > > # Set oplogging level where n is > # 0=off (default) > # 1=W > # 2=R > # 3=both > # 7=W+some reads > oplog = 7 > > > After that, the server refused to start, and I found this in the log: > > ... mongod[385]: Error parsing INI config file: unrecognised option 'oplog' Indeed, it appears the option has been called "diaglog" for the past 9 years, can you give it a try? We need to update the package's default config I guess... Cheers, Apollon
Bug#892908: [Pkg-puppet-devel] Bug#892908: puppet 5 is now builtin to puppet since 4.9
Control: retitle -1 puppet: Hiera 5 is now built-in, please drop hiera 3 dependency Control: tags -1 wontfix Hi, On 07:32 Wed 14 Mar , Gabriel Filion wrote: > I'm just curious whether the package's dependency on the hiera package > is still needed. hiera 3.x (as distributed by the hiera package) is > still maintained but I'm wondering if we require it with newer puppet > installs. It appears it's still necessary, at least in order to provide backward compatibility. Puppet itself declares it as a runtime dependency in its gemspec, so I guess it's not that easy to get rid of it (thus marking it as `wontfix' for the time being). > I haven't made any sort of test yet. I guess to test this, we'd need a > puppet package without the dependency on hiera installed on a host > without hiera, then check that lookups are still working regardless of > the tool's absence. > > If tests are successful then I believe we could simply drop the > dependency to hiera from the puppet package. You can always force-remove ruby-hiera: dpkg --ignore-depends=puppet --remove hiera and see what's working or not :) Regards, Apollon
Bug#892737: [Pkg-puppet-devel] Bug#892737: marked as done (ruby-gettext-setup: outdated version, hijacks gettext and breaks puppet)
I've also added a Breaks: ruby-gettext-setup (<< 0.17) to puppet 5.4.0-2, which I will be uploading shortly. This will force ruby-gettext-setup to be upgraded when installing puppet. Cheers, Apollon
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Control: tags -1 pending Hi Georg, On 02:30 Tue 13 Mar , Georg Faerber wrote: > Hi Apollon, > > On 18-03-13 00:19:06, Apollon Oikonomopoulos wrote: > > On 23:09 Mon 12 Mar , Georg Faerber wrote: > > > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote: > > > > So, the version of ruby-gettext-setup is pretty outdated and > > > > predates > > > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules > > > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext > > > > default domain, causing breakage. This has been fixed upstream[1] in > > > > 0.17. > > > > > > > > We should upgrade ruby-gettext-setup to the latest upstream version. > > > > > > I could take care of this, tomorrow. Just need someone to sponsor the > > > upload. > > > > Please do! I'd be glad to sponsor this, ping me when you're ready or > > if you need any help. > > I've pushed in git to branch debian/0.30-1. Please especially review > eeff22b6, in particular the changes I've made to > spec/lib/tasks/gettext_rake_spec.rb. > > (This file loads an rake task contained in lib/. I'm not really sure if > I'm happy with my proposed change, however, I've tried various methods > and didn't found anything else working besides this. Reasoning for this > change: Upstreams code doesn't work if specs are run via autopkgtest, as > lib/ is moved away during autopkgtest runs. In case you would like to > change this: Please go ahead.) Looks good to me! I've pushed an additional change (unexport LANGUAGE in d/rules) to fix a test failure occurring on my system. I'll upload the package shortly. Thanks for your work! Apollon
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Hi Georg, On 23:09 Mon 12 Mar , Georg Faerber wrote: > On 18-03-12 23:28:20, Apollon Oikonomopoulos wrote: > > So, the version of ruby-gettext-setup is pretty outdated and > > predates > > Puppet's i18n system. When pulled in via i18n-enabled Puppet modules > > (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext > > default domain, causing breakage. This has been fixed upstream[1] in > > 0.17. > > > > We should upgrade ruby-gettext-setup to the latest upstream version. > > I could take care of this, tomorrow. Just need someone to sponsor the > upload. Please do! I'd be glad to sponsor this, ping me when you're ready or if you need any help. Cheers, Apollon
Bug#892737: [Pkg-puppet-devel] Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Control: reassign -1 ruby-gettext-setup Control: retitle -1 ruby-gettext-setup: outdated version, hijacks gettext and breaks puppet Control: found -1 0.7-1 Control: tags -1 severity serious Hi, On 21:04 Mon 12 Mar , Mykola Nikishov wrote: > Package: puppet > Version: 5.4.0-1 > Followup-For: Bug #892737 > > I have librarian-puppet and found out that downgrading it to jessie > will fix the problem. Downgrade will remove ruby-puppet-forge and > ruby-gettext-setup. > > Seems ruby-gettext-setup causes this problem. So, the version of ruby-gettext-setup is pretty outdated and predates Puppet's i18n system. When pulled in via i18n-enabled Puppet modules (e.g. ruby-puppet-forge), it will completely hijack Puppet's gettext default domain, causing breakage. This has been fixed upstream[1] in 0.17. We should upgrade ruby-gettext-setup to the latest upstream version. Regards, Apollon [1] https://github.com/puppetlabs/gettext-setup-gem/commit/0fcb0971faf094b0689bf302b04327a09de41c0e
Bug#892737: [Pkg-puppet-devel] Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Control: tags -1 - unreproducible moreinfo On 21:04 Mon 12 Mar , Mykola Nikishov wrote: > Package: puppet > Version: 5.4.0-1 > Followup-For: Bug #892737 > > I have librarian-puppet and found out that downgrading it to jessie > will fix the problem. Downgrade will remove ruby-puppet-forge and > ruby-gettext-setup. > > Seems ruby-gettext-setup causes this problem. Okay, it's actually ruby-semantic-puppet that resets the default text domain. Thanks for your feedback! Regards, Apollon
Bug#892737: [Pkg-puppet-devel] Bug#892737: Bug#892737: puppet: /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in `copy_default_translations': undefined method `chain'
Control: tags -1 unreproducible moreinfo Control: tags -1 severity important Hi Jan, [Downgrading severity as it does not seem to be affecting all systems ATM] On 13:54 Mon 12 Mar , Jan Huijsmans wrote: > Hi Apollon, > > On Mon, 12 Mar 2018 13:57:03 +0200 Apollon Oikonomopoulos > <apoi...@debian.org> wrote: > > Hi, > > > > Thanks for the report, > > > > On 12:33 Mon 12 Mar , Jan Huijsmans wrote: > > > Would love tips on how to get this setup working or downgrade back > > > to 4.10.4. > > > > I'll have a look at the issue as soon as possible. In the meantime, > > you can obtain 4.10.4 from > > http://snapshot.debian.org/package/puppet/4.10.4-2/ > > Thanks for the link, great to be able to get the packages. Reinstalled > the old version and everything works again as expected. > > I'll compare the debian (a few clients) and the raspbian > (puppet-master) to see if I can find differences. Iy looks like > gettext(-setup) is a dependency. (but have it installed and it gives > the error) It's not a strict dependency: puppet tries to load it, but it works fine without it. It's this line that worries me most to be honest: > /usr/lib/ruby/vendor_ruby/puppet/gettext/config.rb:156:in > `copy_default_translations': undefined method `chain' for > # (NoMethodError) It seems that somehow it has managed to get the internal state mixed up, as the object should be a FastGettext::TranslationRepository::Chain, and not FastGettext::TranslationRepository::Po. I have no idea how that happened, but you can help me find out. Can you please run the attached script (ruby puppet-locale-test.rb) on your master and reply with the output? Regards, Apollon puppet-locale-test.rb Description: application/ruby signature.asc Description: PGP signature
