Bug#922006: please move dkimpy-milter to python3

[Daniel Kahn Gillmor]

Package: dkimpy-milter
Version: 1.0.0-1

Hi Scott--

I see that python3-milter exists now.  it would be great to move
dkimpy-milter to python3 as well, so that mailserver administrators
using dkimpy-milter don't need to have python2 installed.

If you want a hand with the transition, i'd be happy to help.

Regards,

  --dkg


signature.asc
Description: PGP signature

Bug#919356: Licensing of include/linux/hash.h

[Domenico Andreoli]

On Mon, Feb 11, 2019 at 12:08:32AM +0100, Kristian Fiskerstrand wrote:
> On 1/23/19 9:50 AM, Domenico Andreoli wrote:
> > Ben Finney  writes:
> >> Domenico Andreoli  writes:

[...]

> >>> the only knot left is now the license of hash.h
> >>>
> >>> This file is also present in the kernel [0] with an updated copyright
> >>> but still without license.

[...]

> >> To know that work (that file) is free software, we need a clear grant of
> >> some specific license, for that work.
> >>
> >> If the work is not free, it would be incorrect to have the work in Debian.
> > 
> > Is it possible that for the kernel it is instead correct because it is,
> > as whole, covered by its COPYING?
> > 
> >> Alternatives, for complying with the Debian Free Software Guidelines with
> >> this package, include:
> >>
> >> * Find a credible grant of license under some GPL-compatible free
> >>   license to that exact file. Document that explicit grant in the Debian
> >>   package. This demonstrates the work is DFSG-free.
> >>
> >> * Convince ???dwarves-dfsg??? upstream to replace that file with a 
> >> different
> >>   implementation (I don't know whether such an implementation exists)
> >>   under a license compatible with the same version of GNU GPL. Document
> >>   that explicit grant in the Debian package. This demonstrates the
> >>   modified work is DFSG-free.
> >>
> >> * Replace that file in Debian only, with a different implementation as
> >>   above. Document that explicit grant in the Debian package. This
> >>   demonstrates the modified Debian package is DFSG-free.
> >>
> >> * Move the work to the ???non-free??? area.
> >>
> >> * Remove the work altogether.
> >>
> >> Those are in descending order of (my recommended) preference.

[...]

> It was [pointed out] by one of our license group that [hash.h]  is the
> same that has a GPL-2+ in [fio] which has a signed-off-by.
> 
> References:
> [pointed out]
> https://bugs.gentoo.org/677586#c1
> 
> [hash.h]
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c

Yes, the Signed-off-by is from Jens Axboe (in CC) but he's not the
original author, I guess he just copied the file as Arnaldo did. The
file he committed has not any reference to the license.

> [fio]
> https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright

I'm afraid that this entry in wrong. I'll seek confirmation with Martin 
Steigerwald.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#921439: matrix-synapse: Delete self-signed certificates during upgrade to version 0.99

[Joseph Nuthalapati]

Closing since the suggested fix is unsafe and incomplete.

-- 
Regards,
Joseph Nuthalapati




signature.asc
Description: OpenPGP digital signature

Bug#921439: matrix-synapse: Delete self-signed certificates during upgrade to version 0.99

[Joseph Nuthalapati]

Dear maintainer,

After going through the detailed documentation[1] on how the
matrix-synapse ACME client works, I found that obtaining certificates
using it is neither as automatic or easy as I expected.

Since deleting the self-signed certificates isn't the only step
involved, we should let the administrator handle the upgrade to 0.99 or
1.0. Reusing the server's Let's Encrypt certificate is provided as an
alternate option (which is what I'm planning to do in my case).

Automatically deleting the certificates during the Debian package
installation seems like a bad idea. I will close this issue.

1. https://github.com/matrix-org/synapse/blob/master/docs/ACME.md

-- 
Regards,
Joseph Nuthalapati




signature.asc
Description: OpenPGP digital signature

Bug#891434: grub-efi: System fails to boot after "No space left on device" on EFI variable storage

[Niels Thykier]

On Fri, 14 Dec 2018 10:22:49 +0100 Ralf Jung  wrote:
> Hi,
> 
> > Fixing this does seem like it would be a good idea for general
> > robustness against dodgy firmware (this is not the first iteration of
> > problems along these lines).  It would take some development work, but
> > hopefully not too much.
> > 
> > Things that GRUB can't do, as far as I can tell:
> > 
> >  * I don't think there's a way for GRUB to check whether it will be
> >possible to recreate a boot entry later; as I understand it, that
> >depends on various low-level details, including firmware-specific
> >quirks.
> >
> >  * Even detecting that nothing changed would require cooperation from
> >efibootmgr, since the encoding of the EFI variable is an
> >implementation detail there (so we can't just read it out and
> >compare), and efibootmgr doesn't expose a way for GRUB to say "set
> >this configuration, but only if it's different from what's already
> >there".
> > 
> > However, I think GRUB can at least manage to delete all but one entry
> > from the same distributor rather than all of them, and if it finds one
> > remaining entry then it can modify that rather than writing a brand new
> > variable.  As I understand it, that would probably be enough to fix this
> > bug?
> 
> Assuming that modification works even when the variable storage is (close to)
> full, then yes, that would at least keep the device bootable which would be a
> big improvement.
> 
> Kind regards,
> Ralf
> 
> 

Hi Colin,

Thanks for proposing this solution. :)

I also think it would be a good solution for now that will hopefully
avoid most of these errors. :)

Thanks,
~Niels

Bug#922004: transition: clamav

[Scott Kitterman]

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

Even though we are after the transition deadline, we would like to have
permission to go ahead with the clamav transition.  Typically we keep clamav
updated in stable for effectiveness reasons and we plan to do the same now.
In order to do that, we need to do sid/buster first.

Status of preparations:

clamav 0.101.1+dfsg-2 is in experimental and has built on all release archs
for which it has been tried (it's been waiting a week for mips64el/mipsel).

It's ready for unstable/buster.

rdepends:

dansguardian (still and issue for stable, but removed from unstable/buster),
maintianed fork e2guardian uses clamd, not libclamav, so not an issue.

libclamunrar: Update split from clamav source and uploaded to experimental.

python-clamav: Source changes needed.  Patched version uploaded to
experimental.

havp: Source changes needed.  New upstream release with fixes uploaded to
experimental (upstream only incorporates Debian patches and this change).

c-icap-modules: binNMU only - tested rebuild locally.

pg-snakeoil: binNMU only - tested rebuild locally.


Ben file (note: this is what reportbug generated, the auto one is fine):

title = "clamav";
is_affected = .depends ~ "libclamav7" | .depends ~ "libclamav9";
is_good = .depends ~ "libclamav9";
is_bad = .depends ~ "libclamav7";

Note that for the packages that need sourceful uploads, I am an uploader, so
no external maintainer coordination is required.

Scott K

Bug#922005: RM: mash [mips mips64el mipsel s390x hppa hurd-i386 ia64 powerpc ppc64 sparc64] -- ROM; Does not build on all architectures due to new Build-Depends

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

due to the new dependency libmurmurhash which is not yet build on all
architectures mash is not build on all architectures where it has build
before.  The background is that the new version of mash (as many other
Debian packages) was shipping a code copy of libmurmurhash which was
even less portable than the libmurmurhash package.  There is work
ongoing to make libmurmurhash building on all supported architectures
but since we are approaching the freeze this will not happen right in
time.  So please remove the said architectures for the time beeing to
enable mash migrating to testing.

Thank you for your work as ftpmaster

   Andreas.

Bug#922003: RFS: blastem/0.6.2.1-1 -- Fast and accurate Genesis emulator

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "blastem"

 * Package name: blastem
   Version : 0.6.2.1-1
   Upstream Author : Michael Pavone 
 * URL : https://www.retrodev.com/blastem
 * License : GPL-3+
   Section : games

  It builds those binary packages:

  blastem - Fast and accurate Genesis emulator

  To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/blastem

  Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/blastem/blastem_0.6.2.1-1.dsc

  More information about BlastEm can be obtained from 
https://gitlab.com/coringao/blastem.

  Changes since the last upload:

  blastem (0.6.2.1-1) unstable; urgency=medium

  * New upstream release
  * Fixed the FTBFS due to enabled hardening build flags

  Regards,
   Carlos Donizete Froes [a.k.a coringao]

Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

[Mykola Nikishov]

Carsten Schoenert  writes:

> Instead of discussing the severity of the bug report it would be more
> helpful

It is much more helpful to read original message in full:

> Yes, it uses 4 OpenSans-*.ttf fonts. fonts-open-sans already provides
> these fonts and is about 2 Mbytes in size.

> I've submitted PR 
> https://salsa.debian.org/webext-team/lightbeam/merge_requests/1

and only then hit 'Reply'.

-- 
Mykola

Libre/Free Java Software Engineer
https://manandbytes.gitlab.io/

Bug#919317: [Pkg-shadow-devel] Bug#919317: shadow: French documentation translation update

[Alban Vidal]

Control: tag -1 |upstream|
Control: tag -1 |pending|

---

Dear Maintainer,

Merge request sended in upstream project:
https://github.com/shadow-maint/shadow/pull/153

Regards,

Alban




signature.asc
Description: OpenPGP digital signature

Bug#922002: ITP: gotop -- terminal based graphical activity monitor inspired by gtop and vtop

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: gotop
  Version : 2.0.1
  Upstream Author : Caleb Bassi
* URL : https://github.com/cjbassi/gotop
* License : AGPL-3.0
  Programming Lang: Go
  Description : terminal based graphical activity monitor inspired by gtop 
and vtop

Packaging repo is here https://salsa.debian.org/debian/gotop
Currently it is able to produce a working deb package with vendord source.

Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

[Carsten Schoenert]

Hi,

Am 10.02.19 um 23:31 schrieb Mykola Nikishov:
> Carsten Schoenert  writes:
> 
>> The issue in question isn't breaking any policy, raises security issues,
>> makes the package not usable or is provoking any data loss, so a
>> severity of critical, grave or serious isn't a correct tagging.
>> Decreasing the severity to normal.
>>
>> [1] https://www.debian.org/Bugs/Developer#severities
> 
> important:
> a bug which has a major effect on the usability of a package,
> without rendering it completely unusable to everyone.
> 
> Does this one fit the bill?

is the *usability* really affected? Is this package (in detail the UI)
working badly in this version? I don't think so.

Instead of discussing the severity of the bug report it would be more
helpful to figure out which installed packages or files are useless so
we can solve this issue technically.
If you can help to identify the really required files and summarize
these here in this bug report would help to get the issue solved.

-- 
Regards
Carsten Schoenert

Bug#922001: nmu: libxml2_2.9.8+dfsg-1

[Andreas Beckmann]

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

nmu libxml2_2.9.8+dfsg-1 . ANY . experimental . -m "Rebuild against libicu63."

cruft cleanup in sid shows that the transition was not performed in
experimental.


Andreas

Bug#922000: src:kauth: Symbols file out of date

[Scott Kitterman]

Package: src:kauth
Version: 5.54.0-1
Severity: normal

Seen in the amd64 build logs for 5.54.0-1:

dpkg-gensymbols: warning: some libraries disappeared in the symbols file: 
kauth_backend_plugin.so kauth_helper_plugin.so
dpkg-gensymbols: warning: debian/libkf5auth5/DEBIAN/symbols doesn't match 
completely debian/libkf5auth5.symbols
--- debian/libkf5auth5.symbols (libkf5auth5_5.54.0-1_amd64)
+++ dpkg-gensymbolsUUn6iW   2019-01-18 12:55:12.883857964 +
@@ -1,9 +1,3 @@
-kauth_backend_plugin.so libkf5auth5 #MINVER#
- qt_plugin_instance@Base 5.0.0
- qt_plugin_query_metadata@Base 5.0.0
-kauth_helper_plugin.so libkf5auth5 #MINVER#
- qt_plugin_instance@Base 5.0.0
- qt_plugin_query_metadata@Base 5.0.0
 libKF5Auth.so.5 libkf5auth5 #MINVER#
  _ZN5KAuth10ExecuteJob11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
  _ZN5KAuth10ExecuteJob11qt_metacastEPKc@Base 4.96.0

It seems like it should be updated, but I'm not sure the correct solution, so
not touching it for the security update.

Scott K

Bug#921296: ccfits: FTBFS with upcoming doxygen 1.8.15

[Aurelien Jarno]

On 2019-02-04 10:53, Aurelien Jarno wrote:
> On 2019-02-04 01:04, Paolo Greppi wrote:
> > Source: ccfits
> > Severity: serious
> > 
> > Dear Maintainer,
> > 
> > I tested your package against a draft package for doxygen 1.8.15:
> > https://bugs.debian.org/919413
> > 
> > and it FTBFS with this error:
> > make[2]: *** [Makefile:8: refman.pdf] Error 1
> > 
> 
> That actually looks like a bug in doxygen. CCfits depends on
> doxygen-latex, which according to its description should provide
> everything needed:
> 
> | Package: doxygen-latex
> | ...
> | Description-en: Documentation system for C, C++, Java, Python and other 
> languages
> |  Doxygen is a documentation system for C, C++, Java, Objective-C, Python, 
> IDL
> |  and to some extent PHP, C#, and D.  It can generate an on-line class 
> browser
> |  (in HTML) and/or an off-line reference manual (in LaTeX) from a set of
> |  documented source files.
> |  .
> |  This dependency package adds dependencies for all LaTeX packages required
> |  to build documents using the default stylesheet.
> 
> ccfits doesn't do anything fancy, it just generates the latex file using
> doxygen and then run pdflatex on it. If a dependency is missing for
> that, it should be added to doxygen-latex.
> 

ccfits is now marked for autoremoval. Sending this email to reset the
autoremoval while waiting for an answer.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#921999: regionset FTCBFS: fails to pass cross tools to make

[Helmut Grohne]

Source: regionset
Version: 0.1-3.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

regionset fails to cross build from source, because the upstream
Makefile does not pick up the environment variables passed by cdbs and
thus uses plain gcc. dh_auto_build passes them as makefile variables and
thus sidesteps this issue. Once using dh_auto_build, regionset cross
builds successfully. Please consider applying the attached patch.

Helmut
diff -u regionset-0.1/debian/changelog regionset-0.1/debian/changelog
--- regionset-0.1/debian/changelog
+++ regionset-0.1/debian/changelog
@@ -1,3 +1,10 @@
+regionset (0.1-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Feb 2019 06:17:27 +0100
+
 regionset (0.1-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u regionset-0.1/debian/rules regionset-0.1/debian/rules
--- regionset-0.1/debian/rules
+++ regionset-0.1/debian/rules
@@ -5,0 +6,4 @@
+
+$(cdbs_make_build_stamps):
+   dh_auto_build
+   touch $@

Bug#874276: ca-certificates-java: fails to install on armhf: Error: missing `server' JVM at `/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'

[Andreas Beckmann]

Followup-For: Bug #874276

Let's try to fix this in ca-certificates-java for stretch, the openjdk-8
fix does not seem to be effective for stretch.
https://bugs.debian.org/921997


Andreas

Bug#921998: wpa FTCBFS: debian/rules exports CC=cc

[Helmut Grohne]

Source: wpa
Version: 2:2.7+git20190128+0c1e29f-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wpa fails to cross build from source, because debian/rules exports CC
with a (default) value of cc. That's the wrong compiler for cross
building and does no good: If there is a non-default, it already is
exported. After removing the export, wpa cross builds successfully.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru wpa-2.7+git20190128+0c1e29f/debian/changelog 
wpa-2.7+git20190128+0c1e29f/debian/changelog
--- wpa-2.7+git20190128+0c1e29f/debian/changelog2019-01-29 
18:11:01.0 +0100
+++ wpa-2.7+git20190128+0c1e29f/debian/changelog2019-02-11 
05:47:36.0 +0100
@@ -1,3 +1,10 @@
+wpa (2:2.7+git20190128+0c1e29f-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't export CC=cc. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 11 Feb 2019 05:47:36 +0100
+
 wpa (2:2.7+git20190128+0c1e29f-1) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru wpa-2.7+git20190128+0c1e29f/debian/rules 
wpa-2.7+git20190128+0c1e29f/debian/rules
--- wpa-2.7+git20190128+0c1e29f/debian/rules2019-01-29 18:11:01.0 
+0100
+++ wpa-2.7+git20190128+0c1e29f/debian/rules2019-02-11 05:47:33.0 
+0100
@@ -19,7 +19,7 @@
 
 PKG_CONFIG ?= $(DEB_HOST_GNU_TYPE)-pkg-config
 
-export CC BINDIR V PKG_CONFIG
+export BINDIR V PKG_CONFIG
 
 DEB_HOST_ARCH_OS  ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 HOSTAPD_DOT_CONFIG:= debian/config/hostapd/$(DEB_HOST_ARCH_OS)

Bug#921997: stretch-pu: package ca-certificates-java/20170929~deb9u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Control: block 921748 with -1

Hi,

ca-certificates-java is uninstallable on armhf: #874276

The proposed patch has only been build-tested (on amd64), the resulting
(arch:all) package has *not* been tested on armhf at all.
But it does not look like it could make the situation worse.
The package has *not* been uploaded, waiting for an explicit ACK.


Andreas
diff -Nru ca-certificates-java-20170531+nmu1/debian/changelog 
ca-certificates-java-20170929~deb9u1/debian/changelog
--- ca-certificates-java-20170531+nmu1/debian/changelog 2017-06-15 
17:33:00.0 +0200
+++ ca-certificates-java-20170929~deb9u1/debian/changelog   2019-02-11 
05:34:52.0 +0100
@@ -1,3 +1,21 @@
+ca-certificates-java (20170929~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Mon, 11 Feb 2019 05:34:52 +0100
+
+ca-certificates-java (20170929) unstable; urgency=low
+
+  [ Gianfranco Costamagna ]
+  * Team upload.
+  * Ack previous NMU, thanks
+
+  [ Rico Tzschichholz ]
+  * Fix temporary jvm-*.cfg generation on armhf (Closes: #874276)
+- the armhf installation path is different from other architectures.
+
+ -- Rico Tzschichholz   Wed, 27 Sep 2017 17:17:59 +0200
+
 ca-certificates-java (20170531+nmu1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru ca-certificates-java-20170531+nmu1/debian/jks-keystore.hook.in 
ca-certificates-java-20170929~deb9u1/debian/jks-keystore.hook.in
--- ca-certificates-java-20170531+nmu1/debian/jks-keystore.hook.in  
2017-05-31 14:39:26.0 +0200
+++ ca-certificates-java-20170929~deb9u1/debian/jks-keystore.hook.in
2017-09-27 17:17:59.0 +0200
@@ -53,7 +53,11 @@
 # the jre is not yet configured, but jvm.cfg is needed to run it
 temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
 mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
+if [ "$arch" == "armhf" ]; then
+printf -- "-client KNOWN\n-server ALIASED_TO -client\n" > $temp_jvm_cfg
+else
+printf -- "-server KNOWN\n" > $temp_jvm_cfg
+fi
 fi
 
 if dpkg-query --version >/dev/null; then
diff -Nru ca-certificates-java-20170531+nmu1/debian/postinst.in 
ca-certificates-java-20170929~deb9u1/debian/postinst.in
--- ca-certificates-java-20170531+nmu1/debian/postinst.in   2017-05-31 
14:39:26.0 +0200
+++ ca-certificates-java-20170929~deb9u1/debian/postinst.in 2017-09-27 
17:17:59.0 +0200
@@ -100,7 +100,11 @@
 # the jre is not yet configured, but jvm.cfg is needed to run 
it
 temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
 mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
+if [ "$arch" == "armhf" ]; then
+   printf -- "-client KNOWN\n-server ALIASED_TO -client\n" 
> $temp_jvm_cfg
+else
+   printf -- "-server KNOWN\n" > $temp_jvm_cfg
+fi
 fi
 
 trap do_cleanup EXIT

Bug#921996: guymager FTCBFS: uses wrong qmake, missing Build-Depends for lrelease

[Helmut Grohne]

Source: guymager
Version: 0.8.8-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

guymager fails to cross build from source, because it uses the wrong
qmake. For cross building we need to use -qmake on Debian
and that's what dh_auto_configure does. I note that the guymager
packaging uses an in-tree build. A lot of debian/rules' complexity (in
particular clean rules) could go away if dropping the --builddirectory
(in my patch).  It also fails running lrelease due to missing a
dependency on qt5-qmake:native. The attached patch fixes both (but
leaves the in-tree build). Please consider applying it.

Helmut
diff --minimal -Nru guymager-0.8.8/debian/changelog 
guymager-0.8.8/debian/changelog
--- guymager-0.8.8/debian/changelog 2018-08-30 13:38:17.0 +0200
+++ guymager-0.8.8/debian/changelog 2019-02-10 16:42:36.0 +0100
@@ -1,3 +1,12 @@
+guymager (0.8.8-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure use a cross qmake.
++ Missing Build-Depends: qt5-qmake:native for using lrelease.
+
+ -- Helmut Grohne   Sun, 10 Feb 2019 16:42:36 +0100
+
 guymager (0.8.8-2) unstable; urgency=medium
 
   * [7ffc3b5] Include patch to fix ftbfs with GCC-8. Thanks to Hilko
diff --minimal -Nru guymager-0.8.8/debian/control guymager-0.8.8/debian/control
--- guymager-0.8.8/debian/control   2018-03-22 10:15:15.0 +0100
+++ guymager-0.8.8/debian/control   2019-02-10 16:42:36.0 +0100
@@ -13,6 +13,7 @@
  libprocps-dev,
  libssl-dev,
  libudev-dev,
+ qt5-qmake:native,
  qtbase5-dev,
  qttools5-dev-tools,
  quilt,
diff --minimal -Nru guymager-0.8.8/debian/rules guymager-0.8.8/debian/rules
--- guymager-0.8.8/debian/rules 2018-05-18 10:27:32.0 +0200
+++ guymager-0.8.8/debian/rules 2019-02-10 16:42:34.0 +0100
@@ -3,6 +3,7 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
+export QT_SELECT=qt5
 
 %:
dh $@
@@ -10,7 +11,7 @@
 override_dh_auto_configure:
dh_quilt_patch
dh_testdir
-   qmake -qt5 DEFINES+="SPLASH_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR_QT=\'\\\"/usr/share/qt5/translations\\\"\'"
+   dh_auto_configure --builddirectory=. -- 
DEFINES+="SPLASH_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR=\'\\\"/usr/share/guymager\\\"\' 
LANGUAGE_DIR_QT=\'\\\"/usr/share/qt5/translations\\\"\'"
touch configure-stamp
 
 override_dh_auto_build:
@@ -27,7 +28,7 @@
rm -f build-stamp configure-stamp
# dpkg-buildpackage starts with cleaning, so we have to be sure that 
there's a
# Makefile (and thus call qmake):
-   qmake -qt5
+   dh_auto_configure --builddirectory=.
$(MAKE) clean
# remove leftover files:
rm -f .qmake.stash compileinfo.cpp manuals/guymager.1

Bug#921921: live-config: Buster Live LXQt does not autologin

[Alf Gaida]

Hi Daniel,

given that only KDE and LXQt use sddm as DM the patch looks right.

Thanks for the link, the next builds in a few days will look much nicer
and more like an mature debian flavour. But yay, the first official
Debian LXQt live iso i've started :)

(pcmanfm-qt 0.14.0 should soon hit testing - same for lxqt-theme-debian
which will bring a proper theme with the right™ debian background, only
the metapackages need some adjustment right now)

Cheers Alf

Bug#921995: kauth: Insecure handling of arguments in helpers

[Scott Kitterman]

Package: src:kauth
Version: 5.28.0-2
Severity: grave
Tags: security upstream patch
Justification: user security hole

See the KDE announce list [1].  It includes reference to a fix [2].  This is
CVE-2019-7443.

Scott K


[1] https://mail.kde.org/pipermail/kde-announce/2019-February/11.html
[2] 
https://cgit.kde.org/kauth.git/commit/?id=fc70fb0161c1b9144d26389434d34dd135cd3f4a

Bug#919308: scotch: do not use mpicc

[Drew Parsons]

Package: scotch
Version: 6.0.6-2
Followup-For: Bug #919308


Thanks Helmut. I think I'll defer this patch until after the freeze
and stable release.

Drew

Bug#921994: jansi-native package is architecture independent and doesn't include native components

[Keegan Witt]

Package: libjansi-native-java
Version: 1.8-1
Owner: pkg-java-maintain...@lists.alioth.debian.org

Unlike the Alpine packaging
(https://pkgs.alpinelinux.org/packages?name=java-jansi-native=edge),
which include files /usr/lib/libjansi.so and /usr/lib/libjansi-1.8.so,
Debian's packaging does not.  I believe this is the cause of errors
I'm seeing on other architectures.  The architectures I know are
problematic are below, as well as the error that from the Java program
trying to use Jansi (happens with both Debian's OpenJDK 8 and 11).  I
tested this on Sid (actually in OpenJDK Debian Docker images
(https://hub.docker.com/_/openjdk)), but it probably affects all
versions.

The errors that I get are from the so files in the linux32
(https://search.maven.org/search?q=g:org.fusesource.jansi%20a:jansi-linux32)
and linux64 
(https://search.maven.org/search?q=g:org.fusesource.jansi%20a:jansi-linux64)
jars, but if the native package were installed, Jansi should load that
(it worked on Alpine at least).

powerpc64le
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/tmp/libjansi-64-6177151729256195035.so: Error relocating
/tmp/libjansi-64-6177151729256195035.so: unsupported relocation type 7
(Possible cause: can't load AMD 64-bit .so on a Power PC 64-bit
platform)]

arm64v8
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/tmp/libjansi-64-6661390371961894243.so: Error relocating
/tmp/libjansi-64-6661390371961894243.so: unsupported relocation type 7
(Possible cause: can't load AMD 64-bit .so on a AARCH64-bit platform)]

s390x
Caused by: java.lang.UnsatisfiedLinkError: Could not load library.
Reasons: [no jansi in java.library.path,
/tmp/libjansi-64-7943786764210458085.so: Error loading shared library
/tmp/libjansi-64-7943786764210458085.so: Exec format error (Possible
cause: endianness mismatch)]

Bug#921993: RM: golang-gopkg-libgit2-git2go.v26 -- RoQA; superseded by golang-gopkg-libgit2-git2go.v27

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please remove 

golang-gopkg-libgit2-git2go.v26 | 0.26+git20170903.0.eb0bf21-1 | source
golang-gopkg-libgit2-git2go.v26-dev | 0.26+git20170903.0.eb0bf21-1 | all

from unstable which does FTBFS and has been superseded by *.v27.


Andreas

Bug#921781: fis-gtm: FTBFS (dh_auto_configure fails)

[Shah, Amul]

Thank you for the patch! We encountered the same problem with the deprecation 
of icu-config. I will fix the upstream source ASAP.

Best Regards,
Amul

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

Bug#921921: live-config: Buster Live LXQt does not autologin

[Daniel Lewart]

Alf, et al,

> it would be nice if one would point me to such an image.

http://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/
  * debian-live-testing-amd64-lxqt.iso  2019-02-07 14:22  2.3G

It should be overwritten Mon Feb 11, but I would expect this
issue to remain.

Peace!
Dan

Bug#684432: Microsoft final Waring

[Mohd Tarmize bin Ahmad]

Update your account

Our record indicates that your account has not been updated, which may result 
in the closure of your account.
 If you do not update your account, you will no longer be able to send and 
receive emails, and also you will be
 denied access to many of our latest enhanced conversations, contacts, and 
attachments.
Take a minute to update your account for a faster and more complete mailing 
experience.

Click Here to Update your account
Note: Failure to update your mailbox will result in a permanent deletion of 
your account.

Many Thanks,
The security team

Copyright © 2018 Webmail .Inc . All rights reserved.

Bug#921542: [Patch net 1/3] net_sched: fix a race condition in tcindex_destroy()

[Cong Wang]

tcindex_destroy() invokes tcindex_destroy_element() via
a walker to delete each filter result in its perfect hash
table, and tcindex_destroy_element() calls tcindex_delete()
which schedules tcf RCU works to do the final deletion work.
Unfortunately this races with the RCU callback
__tcindex_destroy(), which could lead to use-after-free as
reported by Adrian.

Fix this by migrating this RCU callback to tcf RCU work too,
as that workqueue is ordered, we will not have use-after-free.

This change requires us to store a net pointer inside struct
tcindex_data, to avoid the known race with tc_action_net_exit().

Fixes: 27ce4f05e2ab ("net_sched: use tcf_queue_work() in tcindex filter")
Reported-by: Adrian 
Cc: Ben Hutchings 
Cc: Jamal Hadi Salim 
Cc: Jiri Pirko 
Signed-off-by: Cong Wang 
---
 net/sched/cls_tcindex.c | 46 -
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index 9ccc93f257db..14e6d80dd58e 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -48,7 +48,8 @@ struct tcindex_data {
u32 hash;   /* hash table size; 0 if undefined */
u32 alloc_hash; /* allocated size */
u32 fall_through;   /* 0: only classify if explicit match */
-   struct rcu_head rcu;
+   struct net *net;
+   struct rcu_work rwork;
 };
 
 static inline int tcindex_filter_is_set(struct tcindex_filter_result *r)
@@ -229,15 +230,23 @@ static int tcindex_destroy_element(struct tcf_proto *tp,
return tcindex_delete(tp, arg, , NULL);
 }
 
-static void __tcindex_destroy(struct rcu_head *head)
+static void __tcindex_destroy(struct tcindex_data *p)
 {
-   struct tcindex_data *p = container_of(head, struct tcindex_data, rcu);
-
kfree(p->perfect);
kfree(p->h);
kfree(p);
 }
 
+static void tcindex_destroy_work(struct work_struct *work)
+{
+   struct tcindex_data *p = container_of(to_rcu_work(work),
+ struct tcindex_data,
+ rwork);
+
+   put_net(p->net);
+   __tcindex_destroy(p);
+}
+
 static inline int
 valid_perfect_hash(struct tcindex_data *p)
 {
@@ -258,14 +267,22 @@ static int tcindex_filter_result_init(struct 
tcindex_filter_result *r)
return tcf_exts_init(>exts, TCA_TCINDEX_ACT, TCA_TCINDEX_POLICE);
 }
 
-static void __tcindex_partial_destroy(struct rcu_head *head)
+static void __tcindex_partial_destroy(struct tcindex_data *p)
 {
-   struct tcindex_data *p = container_of(head, struct tcindex_data, rcu);
-
kfree(p->perfect);
kfree(p);
 }
 
+static void tcindex_partial_destroy_work(struct work_struct *work)
+{
+   struct tcindex_data *p = container_of(to_rcu_work(work),
+ struct tcindex_data,
+ rwork);
+
+   put_net(p->net);
+   __tcindex_partial_destroy(p);
+}
+
 static void tcindex_free_perfect_hash(struct tcindex_data *cp)
 {
int i;
@@ -333,6 +350,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, 
unsigned long base,
cp->alloc_hash = p->alloc_hash;
cp->fall_through = p->fall_through;
cp->tp = tp;
+   cp->net = net;
 
if (p->perfect) {
int i;
@@ -477,8 +495,13 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, 
unsigned long base,
rcu_assign_pointer(*fp, f);
}
 
-   if (oldp)
-   call_rcu(>rcu, __tcindex_partial_destroy);
+   if (oldp) {
+   if (oldp->net && maybe_get_net(oldp->net))
+   tcf_queue_work(>rwork,
+  tcindex_partial_destroy_work);
+   else
+   __tcindex_partial_destroy(oldp);
+   }
return 0;
 
 errout_alloc:
@@ -570,7 +593,10 @@ static void tcindex_destroy(struct tcf_proto *tp,
walker.fn = tcindex_destroy_element;
tcindex_walk(tp, );
 
-   call_rcu(>rcu, __tcindex_destroy);
+   if (maybe_get_net(p->net))
+   tcf_queue_work(>rwork, tcindex_destroy_work);
+   else
+   __tcindex_destroy(p);
 }
 
 
-- 
2.20.1

Bug#919982: apt-setup: preseeded installation hangs at "Use a network mirror?"

[Steve McIntyre]

[ Dropping Lucas from CC here... ]

Hi Wolfgang,

Finally getting back to this - it's been a busy couple of weeks...!

On Sat, Jan 26, 2019 at 11:24:40AM +0100, Wolfgang Schweer wrote:
>Hi Steve,
>
>On Fri, Jan 25, 2019 at 11:58:08PM +, Steve McIntyre wrote:
>> So I've been looking through this code again, and the corresponding
>> code in apt-setup that uses these values. Last time I played with
>> apt-setup, I added a table to describe what d-i will do based on the
>> information in cd_type, to explain exactly what d-i expects:
>> 
>> # Various different image types look different here:
>> #
>> # Image Type   cd_type
>> ###
>> # netinst  "not_complete"
>> # full CD sets (default desktop)   "full_cd"
>> # desktop-specific CD images   "full_cd/single"
>> # DVD  "dvd"
>> # bluray   "bluray"
>> # multi-arch CD/DVD"not_complete"
>> # live "live"
>
>Thanks for checking the code and providing this table.
>
>The Debian Edu BD image (bluray) is generated using COMPLETE=0, see: 
>https://salsa.debian.org/images-team/setup/blob/master/buster/cronjob.weekly#L268
> 
>because otherwise it turned out to be too big (~21 GiB).
>This image is intended for offline installations, no mirror useable.
>
>With this setting the Edu image differs from the stock BD/DLBD ones 
>where COMPLETE=0 is missing and the default (COMPLETE=1) takes effect, 
>see:
>https://salsa.debian.org/images-team/setup/blob/master/buster/cronjob.weekly#L169

Right.

>> The changes you've imported from the debian-edu fork of debian-cd
>> clearly don't match up with these, and that's a problem.
>
>Agreed; sorry for that.
>
>> We'll come back to this again shortly. To help with that, could you
>> describe exactly what debian-edu is expecting here please, i.e. what
>> the settings in cd_type mean for the debian-edu installer?
>
>I tried to understand the code that is used to write the content, see:
>https://salsa.debian.org/images-team/debian-cd/blob/master/tools/start_new_disc#L179
>
>If I understood correctly, for all cases with COMPLETE=0 the content of 
>cd_type is 'not_complete'.

Correct.

>If the EDU BD image has 'blueray/not_complete' then this content matches 
>the blueray*) case in apt-setup, see:
>https://sources.debian.org/src/apt-setup/1:0.145/generators/50mirror/#L104
>and the image is usable for offline installation.
>This is the only change that is actually needed for the Edu BD image.

Right - that's the information I was looking for. :-) If the Edu
images are doing nothing special (in terms of Edu setup) then that
makes life easier for me!

>Commit 
>https://salsa.debian.org/images-team/debian-cd/commit/15b482d49e642e21e983dba27a47b4fc2d8b90b4
>incorrectly altered the setting 'not_complete' to 'cd/not_complete' for 
>netinst, causing this bug. Sorry for not noticing it. 
>  
>> I'm worried that we may not have a clear solution here that can match 
>> the current expectations of both d-i and and the debian-edu setup.
>
>Hopefully I managed to clarify the Edu setup intention.

Definitely, thanks!

With a type of bluray/not_complete, we'll then get the following
behaviour from the current apt-setup code:

 * 41cdset will ask if you want to scan more media (the multi-line
   "if" code around L60 will *not* match)

 * 50mirror will *not* ask about using a mirror, as you say above
   (will match "bluray*" in L104

Is that what you're looking for? If not, we can tweak further to get
the right behaviour. To be fair, the interfaces here are not great,
and well overdue for some changes to make things clearer...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#919477: Any reason why acl2 will not propagate now?

[Camm Maguire]

???

Take care,
-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#921991: libregex-clojure: warning is printed when library is loaded

[Alex Miller]

This is just a warning that there is name shadowing happening. Everything
will work as expected, so it's not a problem.

It's also easy to fix in the code in question by excluding the `cat` name
from clojure.core to avoid the shadowing, but it's not required.

Would just add cat to the list of excluded symbols here:
https://github.com/cgrand/regex/blob/master/src/net/cgrand/regex.clj#L5

I created a PR for it here: https://github.com/cgrand/regex/pull/9

Alex





On Sun, Feb 10, 2019 at 7:36 PM Elana Hashman  wrote:

> Package: libregex-clojure
> Version: 1.1.0-2
> Severity: minor
>
> When libregex-clojure is loaded, the following warning is printed:
>
>
> WARNING: cat already refers to: #'clojure.core/cat in namespace:
> net.cgrand.regex, being replaced by: #'net.cgrand.regex/cat
>
> I believe this behaviour is also present in the autopkgtests. The
> upstream package does not do this, we should be consistent.
> ___
> Pkg-clojure-maintainers mailing list
> pkg-clojure-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-clojure-maintainers

Bug#921991: libregex-clojure: warning is printed when library is loaded

[Elana Hashman]

Package: libregex-clojure
Version: 1.1.0-2
Severity: minor

When libregex-clojure is loaded, the following warning is printed:


WARNING: cat already refers to: #'clojure.core/cat in namespace:
net.cgrand.regex, being replaced by: #'net.cgrand.regex/cat

I believe this behaviour is also present in the autopkgtests. The
upstream package does not do this, we should be consistent.


signature.asc
Description: PGP signature

Bug#921992: RM: python-mailmanclient python-mailmanclient-doc -- RoQA; NBS; builds only python3-mailmanclient

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Hi,

please clean up the cruft from python-mailmanclient

python-mailmanclient |3.2.0-1 | all
python-mailmanclient-doc |3.2.0-2 | all

as of 3.2.0-3 only python3-mailmanclient is built.

Andreas

Bug#906142: stretch-pu: package vulture/0.11-1+deb9u1

[Andreas Beckmann]

On 2019-02-10 20:48, Adam D. Barratt wrote:
> This ended up being handled in #921910.
> 
> Andreas - *please* check for existing requests first.

Hmm, too many bugs to look at. At least it wasn't one of my requests :-)


Andreas

Bug#906855: gcu-plugin: NPAPI plugins are no longer supported by firefox-esr

[Andreas Beckmann]

Followup-For: Bug #906855
Control: tag -1 pending

Hi,

I just backported the fix from sid, rebuilt the package for stretch and
opened a stretch-pu request. Let's see if this can still reach 9.8.
https://bugs.debian.org/921983


Andreas

Bug#921972: lintian-brush: when d/compat is missing

[Jelmer Vernooij]

On Mon, Feb 11, 2019 at 12:14:41AM +, Jelmer Vernooij wrote:
> On Sun, Feb 10, 2019 at 07:08:52PM +, Dmitry Bogatov wrote:
> > By the way, it is quite unfortunate, that fixer API disallow early
> > sys.exit(0).
> Agreed, that would be good to fix. A workaround is to
> use sys.exit(2) to exit early without a description.
This should be fixed in master; a fixer can now not provide a description so
long as it doesn't make any changes.

Bug#921736: minissdpd: Script in d/minissdpd.config uses /sbin/ifconfig, but package does not depend on net-tools

[Jean-Marc]

On Fri, 08 Feb 2019 17:57:04 +0100 Tim Dengel  
wrote:
> Package: minissdpd
> Version: 1.5.20180223-5
> Severity: important
> 
> Dear Maintainer,
> 
> the script in debian/minissdpd.config uses /sbin/ifconfig, but the package 
> does not depend on net-tools, causing the script to fail on upgrades if 
> net-tools is not installed.
> 

Is it possible to increase the bug severity to serious ?
Increasing it to serious allows apt-listbugs to list it in case of upgrade.


Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpjmWPf2mjFL.pgp
Description: PGP signature

Bug#921972: lintian-brush: when d/compat is missing

[Jelmer Vernooij]

On Sun, Feb 10, 2019 at 07:08:52PM +, Dmitry Bogatov wrote:
> please consider following patch to avoid warnings, when there is no
> `debian/compat'.
Thanks for the patch! Applied in master.

> By the way, it is quite unfortunate, that fixer API disallow early
> sys.exit(0).
Agreed, that would be good to fix. A workaround is to
use sys.exit(2) to exit early without a description.

Jelmer

Bug#921985: munin-node: df plugin fails to get data for /home

[Lars Kruse]

Control: merge -1 918851

Hello Marc,


Am Sun, 10 Feb 2019 22:55:45 +0100
schrieb Marc Donges :

> # Plugins like "df" require access to /home if that is a separate filesystem
> ProtectHome=false

Indeed, this setting prevents your use case.

See the other bug report for this issue:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918851

We are discussing whether there is good way to work around this.

Cheers,
Lars

Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large

[Zac Morris]

I guess this can be closed. Gone all day without being able to replicate
the sigfault, so nothing to capture.

It seems to be chugging along well now, must have been user error on my
side.

Thanks for the quick response!
-Zac Morris

On Sun, Feb 10, 2019 at 2:03 PM Bernhard Übelacker 
wrote:

> Ok, so the package corekeeper would be an option?
> Is gdb-minimal also already too much?
>
> Kind regards,
> Bernhard
>
> PS.: please leave the bugs email as CC or To. ;-)
>
>

Bug#921990: mypy should depend on the precise version of python3-mypy

[Salvo Tomaselli]

Package: mypy
Version: 0.670-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I upgraded mypy, python3-mypy did not get pulled in as dependency so it remained
as the old version.

This is what happens when I ran it.


$ mypy
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 789, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (mypy 0.660 (/usr/lib/python3/dist-packages), 
Requirement.parse('mypy==0.670'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/mypy", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 596, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mypy==0.670' distribution was not 
found and is required by the application



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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mypy depends on:
ii  python3   3.7.2-1
ii  python3-mypy  0.660-5

mypy recommends no packages.

Versions of packages mypy suggests:
pn  mypy-doc  

-- no debconf information

Bug#920225: pv: replace ash shell with dash

[Andrew Wood]

Thanks for this discussion and for the patch.  I have no idea why this
script uses ash instead of sh.  Digging into its history a little bit I see
that it has been unchanged since December 2003, so who knows what I was
thinking.

It will use /bin/sh in the next release.


On Tue, Jan 22, 2019 at 09:53:16PM -0500, Antoine Beaupre wrote:
> On Tue, Jan 22, 2019 at 09:01:21PM -0300, Juan Picca wrote:
> > Closed as not directly related to debian.
> > Thanks Antoine for your comments and sorry for the noise.
> 
> Glad I could be of service.
> 
> And no problem at all for the noise, I believe it was a fine patch, it's
> just we don't need it in Debian specifically. I would suggest you
> contact upstream here:
> 
> https://www.ivarch.com/personal/contact.shtml
> 
> They are usually quite supportive and responsive to patches, bug reports
> and suggestions. Don't expect a response immediately, however, they take
> their time, which is fine. :)

-- 
Andrew Wood

Bug#921030: Fails to import the ansible module since its migration to Python 3

[Samuel Henrique]

Hello Gregory,

I would like to see the last version of ansible-lint shipped on Debian
Buster, thus I would like to fix this bug by uploading the last 4.0.1-1 to
unstable. It won't get to Buster before the release but as it will fix a RC
bug, it should be ok.

Are you fine with me fixing the problem? I would also like to add myself as
an uploader while doing so.

Thanks.

-- 
Samuel Henrique 

Bug#921128: Info received (mailman3-web fails to initialize mysql: Specified key was too long)

[Antoine Beaupré]

On 2019-02-10 01:11:35, Pierre-Elliott Bécue wrote:
> Le vendredi 01 février 2019 à 21:05:38-0500, Antoine Beaupré a écrit :
>> I just read the README.Debian file and it says the mariadb version in
>> stretch might conflict with the mailman3-web version.
>> 
>> If that's really the case, might I suggest the backport be fixed to warn
>> explicitely about this somehow? maybe conflict with that mariadb
>> version?
>
> Please review and comment
> https://salsa.debian.org/mailman-team/mailman-suite/commit/1dc0dcf43e763b4b78e808877d65a8dbb6119170
>
> I'll upload in a couple of days. :)

That's a great start!

Couldn't we check if mariadb is actually installed or configured somehow
instead of just always prompting?

But if that's too much work, it's better than nothing for sure.

THanks! :)

A.

-- 
On ne résout pas un problème avec les modes de pensée qui l'ont
engendré.
- Albert Einstein

Bug#921989: ITP: sozu -- a fast, reliable, hot reconfigurable HTTP reverse proxy

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: sozu
  Version : 0.11.0
  Upstream Author : Geoffroy Couprie 
* URL : http://sozu.io
* License : AGPL-3.0
  Programming Lang: Rust
  Description : a fast, reliable, hot reconfigurable HTTP reverse proxy


Its authors intend it to be “the most reliable reverse proxy ever”:

- - it should never crash (currently fixing the remaining panics)
- - you should not need to restart it
  - it can receive configuration changes from a unix socket at runtime
  - it should be able to upgrade without any downtime
- - it should not have exploitable memory errors
  - even if it has one, workers will be sandboxed
- - you set up a limit on the number of concurrent connections to a worker
  - the reverse proxy will refuse new connections over that limit,
instead of requesting unavailable resources like memory


Moreover, HTTP frontends currently-available in Debian are either fairly
low-performance, or written in languages that do not guarantee memory safety,
making them a never-ending source of remotely-exploitable bugs.

As such, I believe sozū fills a gap within Debian's package ecosystem.


I intent to package it, and its various components, as part of the Debian Rust
team, and maybe get involved in upstream development (author in X-Debbugs-CC).


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlxgr1gRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MsH4A//SuqK/mo7Y3CliIM80Lyo6m6kmYOCUtpz
eGfVAXFiR+BjvyjitVHk0NZBK7Jx0qzuA4rUc2rwJKXW+QFQCcsdXo2elkJLp1+V
ZMRHZnfuOH76iSZYdS6Kupg6PqRh5YEZzBWmS/UaBcT8HtFaI2HAj0PBbvsvYCZB
G8zQc/bnDHfPhff/1qH13yKiegsDlCFrkyyyAJtmSqMx1jM7JT7zNsOomYBgdzqs
e6m4MOqPqreFa7Cn4tDiGBK4wTQ4I21Yly9mOzvRezR4uIUNJe/jTn5U80tp5KGf
ipLFlNI1AQcVzBn5fh+eaVht1YymwNP0y7afYloEJRDRKAj7V66k8vhbWSOCNI7S
ulthOW7Yez/caTPj+9Y9E1LAh7vouPY54ECkl8MxcGtcVhxj0ztIsjrbNZTJVhn9
Rw0HOnHI9XT6qhPTzJqHVDF2fJ9NLFmy2bH56O34X/ZW2DcMoIJbvJo+vg1khHe/
8t1bzjVEb6OEPFzYNhqL7MbBs6MymSxGUN37jVvYE5LPSOamEo1BB/fTLDBbvi1A
CKkhnfkjnFuAGior7TPhMOLtklDav70e+RGlq1tdkSOWca3ifk/wEsSxfZmKCCgP
QdA6vWDT1MT6NdieXY4mOjNNkeXw3bWvATo8f5OsIUhEF/LdvdEgjFdvFkv2Edv9
JJzCw5X3Is0=
=iP16
-END PGP SIGNATURE-

Bug#919356: Licensing of include/linux/hash.h

[Kristian Fiskerstrand]

On 1/23/19 9:50 AM, Domenico Andreoli wrote:
> Ben Finney  writes:
>> Domenico Andreoli  writes:
>>
>>>   the situation of dwarves-dfsg improved a lot over the weekend
>>
>> That's good to hear. What is the event you're referring to? Can you give
>> a URL to something that describes this change?
> 
> Upstream (in CC) reacted to my request of clarification and patches
> have been applied upstream and on Salsa. See bug 919356 [0] (please
> keep in CC).
> 
>>> the only knot left is now the license of hash.h
>>>
>>> This file is also present in the kernel [0] with an updated copyright
>>> but still without license.
>>
>> The file you show (in the Linux code base) seems likely to have an
>> equivalent implementation under a different license, from some other
>> code base.
> 
> This will require research and work unlikely to be done before Buster
> release. Are we going to drop this package for now?
> 
>>> I received a private email from somebody in the kernel community who
>>> already tried to contact Nadia in the past but did not get any reply.
>>
>> Thank you also for contacting the Linux developers forum to ask
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>.
> 
> (also in CC now)
> 
>>> I think that pushing it to non-free is formally the right thing but I
>>> actually feel it's not the right thing.
>>
>> To know that work (that file) is free software, we need a clear grant of
>> some specific license, for that work.
>>
>> If the work is not free, it would be incorrect to have the work in Debian.
> 
> Is it possible that for the kernel it is instead correct because it is,
> as whole, covered by its COPYING?
> 
>> Alternatives, for complying with the Debian Free Software Guidelines with
>> this package, include:
>>
>> * Find a credible grant of license under some GPL-compatible free
>>   license to that exact file. Document that explicit grant in the Debian
>>   package. This demonstrates the work is DFSG-free.
>>
>> * Convince ‘dwarves-dfsg’ upstream to replace that file with a different
>>   implementation (I don't know whether such an implementation exists)
>>   under a license compatible with the same version of GNU GPL. Document
>>   that explicit grant in the Debian package. This demonstrates the
>>   modified work is DFSG-free.
> 
> Arnaldo, what priority would you give to this task?
> 
>>
>> * Replace that file in Debian only, with a different implementation as
>>   above. Document that explicit grant in the Debian package. This
>>   demonstrates the modified Debian package is DFSG-free.
>>
>> * Move the work to the ‘non-free’ area.
>>
>> * Remove the work altogether.
>>
>> Those are in descending order of (my recommended) preference.
> 
> Thanks,
> Domenico
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356
> 

It was [pointed out] by one of our license group that [hash.h]  is the
same that has a GPL-2+ in [fio] which has a signed-off-by.

References:
[pointed out]
https://bugs.gentoo.org/677586#c1

[hash.h]
https://git.kernel.org/pub/scm/linux/kernel/git/axboe/fio.git/commit/hash.h?id=bdc7211e190482f0c17c109a0d90834a6611be1c

[fio]
https://metadata.ftp-master.debian.org/changelogs/main/f/fio/fio_3.12-2_copyright



-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Bug#921988: RM: erlang-cherly -- ROM; unmaintained upstream

[Nobuhiro Iwamatsu]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

It has not been maintained by Upstream for a long time.

Please remove erlang-cherly. It is obsolete and has not been
maintained by upstream a long time.
Its popcon is low, and has no reverse dependencies in Debian.

Best regards,
  Nobuhiro

Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)

[Ewen McNeill]

I'm also seeing this issue, also on a Debian Linux 4.19 kernel (on 
updated Debian unstable VM), also on KVM, straight after rebooting the 
VM.  But without any suspending involved, I just reboot the VM, and as 
soon as I can log in after rebooting its showing 6+ days of uptime.


The uptime jumps *very* early in the boot sequence, at the point that 
kvm-clock starts reporting, by many days in my case.


Of note, the KVM host here is pretty old (Ubuntu 14.04 LTS, on 
3.13.0-164-generic kernel, and qemu-kvm 2.0.0+dfsg-2ubuntu1.44).  It's 
also naturally a fairly old CPU (Intel Xeon X3450).


So I wonder if part of the trigger is newer (4.19) kernels relying on 
CPU/hypervisor features that older CPUs / older hypervisors do not 
provide/initialise.  And maybe reading an uninitialised value as a result.


From reading the upstream thread, this seems the closest to diagnosis:

https://lore.kernel.org/lkml/20190126020410.gb3...@feynman.vault24.org/

around guest clock sources being chosen, and apparently the upstream 
maintainer has managed to reproduce the issue:


https://lore.kernel.org/lkml/20190126161137.gme4vsrz3xmnc...@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net/

by changing the clock source (to HPET), as of late Jan 2019.

Ewen

-=- cut here -=-
ewen@debian-unstable:~$ uptime
 11:21:06 up 6 days, 22:40,  1 user,  load average: 0.88, 0.75, 0.52
ewen@debian-unstable:~$ last | head -5
ewen pts/0172.20.254.10Mon Feb 11 11:10   still logged in
reboot   system boot  4.19.0-2-amd64   Mon Feb 11 11:07   still running
ewen ttyS0 Mon Feb 11 11:06 - down   (00:00)
ewen pts/0172.20.254.10Mon Feb 11 11:06 - down   (00:00)
reboot   system boot  4.19.0-2-amd64   Mon Feb 11 11:05 - 11:06  (00:01)
ewen@debian-unstable:~$ date
Mon Feb 11 11:21:21 NZDT 2019
ewen@debian-unstable:~$
ewen@debian-unstable:~$ uname -r
4.19.0-2-amd64
ewen@debian-unstable:~$ dpkg -l | grep linux-image
ii  linux-image-4.19.0-1-amd64   4.19.13-1 
amd64Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.19.0-2-amd64   4.19.16-1 
amd64Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-amd644.19+102 
amd64Linux for 64-bit PCs (meta-package)

ewen@debian-unstable:~$
ewen@debian-unstable:~$ sudo dmesg | grep -A 4 "Hypervisor"
[0.00] Hypervisor detected: KVM
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock
[599207.077513] clocksource: kvm-clock: mask: 0x 
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns

[599207.077516] tsc: Detected 2659.982 MHz processor
ewen@debian-unstable:~$
ewen@debian-unstable:~$ sudo dmesg | head -20 | grep -v BIOS-e820
[0.00] Linux version 4.19.0-2-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-14)) 
#1 SMP Debian 4.19.16-1 (2019-01-17)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-2-amd64 
root=UUID=260df8b9-6a61-4f0e-9625-340dcdaf4017 ro console=ttyS0,9600

[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
01/01/2011

[0.00] Hypervisor detected: KVM
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock
[599207.077513] clocksource: kvm-clock: mask: 0x 
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns

[599207.077516] tsc: Detected 2659.982 MHz processor
[599207.078351] e820: update [mem 0x-0x0fff] usable ==> reserved
ewen@debian-unstable:~$
-=- cut here -=-

-=- cut here -=-
ewen@naosdell:~$ head -5 /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 30
model name  : Intel(R) Xeon(R) CPU   X3450  @ 2.67GHz
ewen@naosdell:~$
-=- cut here -=-

Bug#916696: initramfs-tools: search for nonexistent resume device

[Ben Hutchings]

Control: tag -1 - moreinfo
Control: tag -1 patch

On Sun, 2019-02-10 at 23:35 +0100, Trek wrote:
[...]
> my fix is to reset the resume_auto variable if the device is ephemeral,
> thus removing the need to check the ephemeral variable in the two
> if-construct after the for-loop
> 
>   $ephemeral || break # exit the for-loop if ephemeral=true
>   resume_auto=# otherwise empty resume_auto
> 
> 
> that's it :)
> thanks again for your time
> ciao!

OK, I understand now, thanks.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.




signature.asc
Description: This is a digitally signed message part

Bug#920533: asterisk: on upgrade from 13.23.1 to 16.1.1 RTP streams get misdirected to NAT devices

[James Bottomley]

On Tue, 2019-01-29 at 10:54 +0100, Bernhard Schmidt wrote:
> Hi James,
> 
> thanks. Have you raised this issue with upstream somehow? I know
> chan_sip is deprecated, but I doubt a bug this severe would be
> undetected for that long.
> 
> I'll try to whip together a test for this (my test installation is
> using chan_pjsip and IPv6).

Actually, you can close this; it turns out to be a firewall issue: the
asterisk 16 update apparently changed the rtp.conf file, moving the RTP
listening port range outside of the matching range on the firewall
hence an intermittent audio loss problem with external connections. 
What the patch does is mostly open the conntrack port on the firewall
allowing the inbound RTP stream.  The correct fix is, of course, to put
the rules back to matching each other.

James

Bug#921748: stretch-pu: package icedtea-web/1.6.2-3.1+deb9u1

[Adam D. Barratt]

On Fri, 2019-02-08 at 21:03 +0100, Moritz Muehlenhoff wrote:
> This disables the browser plugin (which was broken due to the Firefox
> Quantum changes),
> the equivalent change in sid was done in 1.7.1-1.

Unfortunately, at least in stable, the package no longer builds on
armhf:

Setting up ca-certificates-java (20170531+nmu1) ...
Error: missing `server' JVM at 
`/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/arm/server/libjvm.so'.
Please install or use the JRE or JDK that contains these missing components.
dpkg: error processing package ca-certificates-java (--configure):
 subprocess installed post-installation script returned error exit status 4

This looks like it needs #874276 backporting to stable.

Regards,

Adam

Bug#916696: initramfs-tools: search for nonexistent resume device

[Trek]

On Sun, 10 Feb 2019 17:32:08 +
Ben Hutchings  wrote:

> > I include a patch, tested with and without an ephemeral swap:
> > - the second block (-79,9 +83,10) is the actual fix
> If you would actually send me the log messages I might understand this
> fix, but as it is I don't.  I do need to understand it before I will
> apply it.

yes, sorry, you're right

here the log:

Calling hook resume
I: Configuration sets RESUME=
I: Checking swap device /dev/dm-1
I: /dev/dm-1 has device-mapper name sdb5_crypt; checking crypttab
I: Found cryptdev=sda5_crypt keyfile=/dev/urandom
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
I: Rejecting /dev/dm-1 since it has no permanent key
I: Checking swap device /dev/dm-0
I: /dev/dm-0 has device-mapper name sda5_crypt; checking crypttab
I: Found cryptdev=sda5_crypt keyfile=/dev/urandom
I: Rejecting /dev/dm-0 since it has no permanent key
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
Calling hook thermal


it ends up with the initrd file /main/conf/conf.d/zz-resume-auto
containing:

RESUME=/dev/dm-0


running resume with set -x explain what's going on:

+ report_verbose Rejecting /dev/dm-0 since it has no permanent key
+ test y != y
+ echo I: Rejecting /dev/dm-0 since it has no permanent key
I: Rejecting /dev/dm-0 since it has no permanent key
+ ephemeral=true
+ read -r cryptdev srcdev keyfile junk
+ report_verbose Found cryptdev=sdb5_crypt keyfile=/dev/urandom
+ test y != y
+ echo I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
I: Found cryptdev=sdb5_crypt keyfile=/dev/urandom
+ [ sdb5_crypt = sda5_crypt ]
+ read -r cryptdev srcdev keyfile junk
+ true
+ [ -n /dev/dm-0 ]
+ true
+ [  = auto ]
+ [ -n /dev/dm-0 ]
+ [ -z /dev/dm-0 ]
+ echo RESUME=/dev/dm-0


basically, it finishes the while-loop
  while read -r cryptdev srcdev keyfile junk; do
  + read -r cryptdev srcdev keyfile junk
then it checks the ephemeral variable inside the for-loop
  $ephemeral || break
  + true
now the for-loop is finished and it evaluates the first if-construct
  if [ -n "$resume_auto" ] && ! $ephemeral; then
  + [ -n /dev/dm-0 ]
  + true
it evaluates the second if-construct (the bug is here, as it doesn't
account for ephemeral)
  if [ "$RESUME" = auto ] || [ -n "$resume_auto" ]; then
  + [  = auto ]
  + [ -n /dev/dm-0 ]
then the inner if-construct 
  if [ -z "$resume_auto" ]; then
  + [ -z /dev/dm-0 ]
and finally it writes the resume file
  echo "RESUME=${resume_auto}" > "${DESTDIR}/conf/conf.d/zz-resume-auto"
  + echo RESUME=/dev/dm-0


my fix is to reset the resume_auto variable if the device is ephemeral,
thus removing the need to check the ephemeral variable in the two
if-construct after the for-loop

  $ephemeral || break   # exit the for-loop if ephemeral=true
  resume_auto=  # otherwise empty resume_auto


that's it :)
thanks again for your time
ciao!

Bug#904933: webext-lightbeam: Pulls in 1 GB of texlive-fonts-extra

[Mykola Nikishov]

Carsten Schoenert  writes:

> The issue in question isn't breaking any policy, raises security issues,
> makes the package not usable or is provoking any data loss, so a
> severity of critical, grave or serious isn't a correct tagging.
> Decreasing the severity to normal.
>
> [1] https://www.debian.org/Bugs/Developer#severities

important:
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.

Does this one fit the bill?

-- 
Mykola

Libre/Free Java Software Engineer
https://manandbytes.gitlab.io/

Bug#921987: fixed

[Jean-Marie Favreau]

Dear debian developers,

It seems that this bug disappeared with the last apt upgrade.

Best regards,


-- 
Jean-Marie Favreau - http://jmfavreau.info

Bug#921912: libwxbase3.0-0v5-dbg: No buster libwxbase3.0-0v5-dbg

[Olly Betts]

On Sun, Feb 10, 2019 at 01:38:18PM -0800, Ralf-Peter Rohbeck wrote:
> On 2/10/19 12:12 PM, Olly Betts wrote:
> > On Sat, Feb 09, 2019 at 09:29:10PM -0800, Ralf-Peter wrote:
> > > I tried to debug a Wxwindows application but when I installed the
> > > debug symbols, libwxbase3.0-0v5 was downgraded to the stretch version:
> > The debug symbols are now in libwxbase3.0-0v5-dbgsym.
> > 
> > Sounds like you have both stretch and buster in your sources list, hence
> > the unhelpful behaviour when you try to install a package which isn't
> > in buster.
> 
> Nope, it's not there:
> 
> root@tp:~# apt-cache search libwxbase3.0-0v5
> libwxbase3.0-0v5 - wxBase library (runtime) - non-GUI support classes of
> wxWidgets toolkit
> libwxbase3.0-0v5-dbg - debugging symbols for the wxBase library
> root@tp:~# apt-cache search libwxbase3.0-0v5-dbgsym
> root@tp:~#

Then you probably haven't configured the apt source for them - see:

https://wiki.debian.org/SourcesList#Debug_Symbol_Packages

Cheers,
Olly

Bug#921883: [921883] emacspeak fails to byte-compile in some case

[Pavel Kreuzt]

Correct, vm is installed and /etc/emacs/site-start.d/50vm.el exists.

On Sun, Feb 10, 2019 at 6:32 PM Paul Gevers  wrote:

> Hi Pavel,
>
> On 10-02-2019 16:51, Pavel Kreuzt wrote:
> > I suppose this is for debugging and not a solution, for it keeps
> > failing. Attached log file.
>
> It was, yes.
>
> I am getting help on IRC from hartmans and bremner on #debian-devel, can
> you confirm that you have vm installed and or
> /etc/emacs/site-start.d/50vm.el left over?
>
> Paul
>
>

Bug#921986: ruby-cheffish: FTBFS randomly (failing tests)

[Santiago Vila]

I said:

> the failures also seem to happen here:
> 
> https://tests.reproducible-builds.org/debian/history/ruby-cheffish.html

Oops, sorry. That part of the report is bogus and should be ignored
because of Bug #912246, which is now fixed and it was an "always-FTBFS".

Thanks.

Bug#921987: mysqld-akonadi: Could not open required defaults file

[Jean-Marie Favreau]

Package: akonadi-backend-mysql
Version: 4:18.08.3-3
Severity: important

Dear Maintainer,

Since yesturday, akonadi is not able to start in Debian Sid (up-do-date).

When I run "akonadictl start", here is the result:

Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
org.kde.pim.akonadiserver: database server stopped unexpectedly
org.kde.pim.akonadiserver: Database process exited unexpectedly during initial 
connection!
org.kde.pim.akonadiserver: executable: "/usr/sbin/mysqld-akonadi"
org.kde.pim.akonadiserver: arguments: ("--defaults-file=/home/[my 
login]/.local/share/akonadi/mysql.conf", "--datadir=/home/[my 
login]/.local/share/akonadi/db_data/", "--socket=/tmp/user/1000/akonadi-[my 
login].449afV/mysql.socket", "--pid-file=/tmp/user/1000/akonadi-[my 
login].449afV/mysql.pid")
org.kde.pim.akonadiserver: stdout: ""
org.kde.pim.akonadiserver: stderr: "mysqld-akonadi: [ERROR] Could not open 
required defaults file: /home/[my 
login]/.local/share/akonadi/mysql.conf\nmysqld-akonadi: [ERROR] Fatal error in 
defaults handling. Program aborted!\n"
org.kde.pim.akonadiserver: exit code: 1
org.kde.pim.akonadiserver: process error: "Unknown error"
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket 
'/tmp/user/1000/akonadi-[my login].449afV/mysql.socket' (2)'
Check that mysqld is running and that the socket: '/tmp/user/1000/akonadi-[my 
login].449afV/mysql.socket' exists!
org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadicontrol: Application 'akonadiserver' exited normally...

mysql.conf is set as following: -rw-r--r-- 

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

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

Versions of packages akonadi-backend-mysql depends on:
ii  libqt5sql5-mysql   5.11.3+dfsg-4
ii  mysql-client-core-5.7 [virtual-mysql-client-core]  5.7.25-1
ii  mysql-server-5.7 [virtual-mysql-server]5.7.25-1

Versions of packages akonadi-backend-mysql recommends:
ii  akonadi-server  4:18.08.3-3

akonadi-backend-mysql suggests no packages.

-- Configuration Files:
/etc/apparmor.d/usr.sbin.mysqld-akonadi changed [not included]

-- no debconf information

Bug#921986: ruby-cheffish: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:ruby-cheffish
Version: 13.1.0-2
Severity: important
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_autoreconf -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<>'
mkdir -p /<>/tmp
dh_auto_install
dh_ruby --install /<>/debian/ruby-cheffish
   dh_ruby --install

┌──────────────────────────────────────────────────────────────────────────────┐
│ Install files   
 │
└──────────────────────────────────────────────────────────────────────────────┘

install -d /<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby
install -D -m644 /<>/lib/cheffish.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish.rb
install -D -m644 /<>/lib/cheffish/key_formatter.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/key_formatter.rb
install -D -m644 /<>/lib/cheffish/with_pattern.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/with_pattern.rb
install -D -m644 /<>/lib/cheffish/chef_run.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_run.rb
install -D -m644 /<>/lib/cheffish/rspec/chef_run_support.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/chef_run_support.rb
install -D -m644 /<>/lib/cheffish/rspec/repository_support.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/repository_support.rb
install -D -m644 /<>/lib/cheffish/rspec/recipe_run_wrapper.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/recipe_run_wrapper.rb
install -D -m644 /<>/lib/cheffish/rspec/matchers.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers.rb
install -D -m644 
/<>/lib/cheffish/rspec/matchers/emit_no_warnings_or_errors.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/emit_no_warnings_or_errors.rb
install -D -m644 
/<>/lib/cheffish/rspec/matchers/partially_match.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/partially_match.rb
install -D -m644 /<>/lib/cheffish/rspec/matchers/be_idempotent.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/be_idempotent.rb
install -D -m644 /<>/lib/cheffish/rspec/matchers/have_updated.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec/matchers/have_updated.rb
install -D -m644 /<>/lib/cheffish/version.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/version.rb
install -D -m644 /<>/lib/cheffish/node_properties.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/node_properties.rb
install -D -m644 /<>/lib/cheffish/base_properties.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/base_properties.rb
install -D -m644 /<>/lib/cheffish/basic_chef_client.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/basic_chef_client.rb
install -D -m644 /<>/lib/cheffish/chef_run_listener.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_run_listener.rb
install -D -m644 /<>/lib/cheffish/server_api.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/server_api.rb
install -D -m644 /<>/lib/cheffish/recipe_dsl.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/recipe_dsl.rb
install -D -m644 /<>/lib/cheffish/chef_actor_base.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_actor_base.rb
install -D -m644 /<>/lib/cheffish/chef_run_data.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/chef_run_data.rb
install -D -m644 /<>/lib/cheffish/rspec.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/rspec.rb
install -D -m644 /<>/lib/cheffish/merged_config.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/merged_config.rb
install -D -m644 /<>/lib/cheffish/array_property.rb 
/<>/debian/ruby-cheffish/usr/lib/ruby/vendor_ruby/cheffish/array_property.rb
install -D -m644 /<>/lib/cheffish/base_resource.rb 

Bug#921984: RM: vblade-persist -- RoQA; dead upstream, alternative exists (vblade)

[Christoph Biedl]

Package: ftp.debian.org
Severity: normal

Hello,

please remove the vblade-persist package

The original author and maintainer of vblade-persist (dkg, Cc:'ed)
had orphaned the package for various reasons, as stated in in #862873.
In the meantime, the vblade package got support for persistence as
well, and there's also a conversion script so users of vblade-persist
can switch easily.

In other words, there is no need to provide this package in Debian
any longer, please remove it from unstable.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#921985: munin-node: df plugin fails to get data for /home

[Marc Donges]

Package: munin-node
Version: 2.0.45-1
Severity: normal

Dear Maintainer,

on one of my systems I noticed that munin no longer records disk free data for 
the separate /home filesystem.

While debugging I could not reproduce the problem when running the df plugin 
with munin-run. I could also not reproduce it with munin-node started directly 
from the command line.

Incomplete output with munin-node run as daemon from systemd:
marc@nephthys:~$ nc localhost 4949
# munin node at nephthys
fetch df
_dev_mapper_nephthys_root_crypt.value 73.5565195777657
_dev_shm.value 1.84851226160177
_run.value 10.594829277865
_run_lock.value 0.078125
_sys_fs_cgroup.value 0
_dev_sda1.value 25.5692545665476
.

Complete output with munin-node run from CLI:
marc@nephthys:~$ nc localhost 4949
# munin node at nephthys
fetch df
_dev_mapper_nephthys_root_crypt.value 73.5626819028434
_dev_shm.value 2.66106291417369
_run.value 10.5943386970173
_run_lock.value 0.078125
_sys_fs_cgroup.value 0
_dev_sda1.value 25.5692545665476
_dev_mapper_nephthys_home_crypt.value 95.5244404001415
.

See the last line with label _dev_mapper_nephthys_home_crypt.

I found that modifying the service file /lib/systemd/system/munin-node.service 
for munin-node fixes this. The default has:

ProtectHome=true

I changed it to:

# Plugins like "df" require access to /home if that is a separate filesystem
ProtectHome=false

This fixed the problem

Kind regards
Marc

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages munin-node depends on:
ii  libnet-server-perl  2.009-1
ii  lsb-base10.2018112800
ii  munin-common2.0.45-1
ii  munin-plugins-core  2.0.45-1
ii  netbase 5.5
ii  perl5.28.1-4

Versions of packages munin-node recommends:
ii  gawk 1:4.2.1+dfsg-1
ii  munin-plugins-extra  2.0.45-1
ii  procps   2:3.3.15-2

Versions of packages munin-node suggests:
pn  munin   
pn  munin-plugins-java  

-- Configuration Files:
/etc/munin/munin-node.conf changed:
log_level 4
log_file /var/log/munin/munin-node.log
pid_file /var/run/munin/munin-node.pid
background 1
setsid 1
user root
group root
ignore_file [\#~]$
ignore_file DEADJOE$
ignore_file \.bak$
ignore_file %$
ignore_file \.dpkg-(tmp|new|old|dist)$
ignore_file \.rpm(save|new)$
ignore_file \.pod$
allow ^127\.0\.0\.1$
allow ^::1$
allow ^192\.168\.102\.[0-9]*$
allow ^2001:6f8:1d3e:[:0-9a-f]*$
host 127.0.0.1
port 4949

/etc/munin/plugin-conf.d/README [Errno 13] Permission denied: 
'/etc/munin/plugin-conf.d/README'
/etc/munin/plugin-conf.d/munin-node [Errno 13] Permission denied: 
'/etc/munin/plugin-conf.d/munin-node'

-- no debconf information

Bug#763744: Reproducible on stretch?

[Santiago Vila]

Hi. I did not remember, but actually, the reply I just gave now
matches the one I left in Bugzilla :-)

https://bugzilla.samba.org/show_bug.cgi?id=10907#c9

So this was already "closed" for me.

If there is somebody who can still reproduce it, they will always be
able to reopen it.

Thanks.

Bug#921912: libwxbase3.0-0v5-dbg: No buster libwxbase3.0-0v5-dbg

[Ralf-Peter Rohbeck]

On 2/10/19 1:42 PM, Olly Betts wrote:

On Sun, Feb 10, 2019 at 01:38:18PM -0800, Ralf-Peter Rohbeck wrote:

On 2/10/19 12:12 PM, Olly Betts wrote:

On Sat, Feb 09, 2019 at 09:29:10PM -0800, Ralf-Peter wrote:

I tried to debug a Wxwindows application but when I installed the
debug symbols, libwxbase3.0-0v5 was downgraded to the stretch version:

The debug symbols are now in libwxbase3.0-0v5-dbgsym.

Sounds like you have both stretch and buster in your sources list, hence
the unhelpful behaviour when you try to install a package which isn't
in buster.

Nope, it's not there:

root@tp:~# apt-cache search libwxbase3.0-0v5
libwxbase3.0-0v5 - wxBase library (runtime) - non-GUI support classes of
wxWidgets toolkit
libwxbase3.0-0v5-dbg - debugging symbols for the wxBase library
root@tp:~# apt-cache search libwxbase3.0-0v5-dbgsym
root@tp:~#

Then you probably haven't configured the apt source for them - see:

https://wiki.debian.org/SourcesList#Debug_Symbol_Packages

Cheers,
 Olly


Ah, that worked. Thanks!

Bug#873719: [Debichem-devel] Bug#873719: /usr/bin/sc-libtool: Command not found

[Michael Banck]

Hi Andreas,

On Sat, Feb 09, 2019 at 03:32:25PM +0100, Andreas Beckmann wrote:
> I just backported the fix to stretch, prepared a stretch-pu request and
> uploaded the package: https://bugs.debian.org/921864

Many thanks!


Michael

Bug#763744: Reproducible on stretch?

[Santiago Vila]

On Sun, Feb 10, 2019 at 10:08:49PM +0100, Mathieu Parent wrote:

> Those are now old bugs. Can you reproduce the panics on stretch or
> testing (upcoming buster)?

No, I can't.

I actually moved the server to a different physical machine three
years ago, by installing a new system and configuring it with
salt/ansible the same way as the old one (which is what I usually do
when moving a server).

If I remember well, I think this is what made the panics to go away.
My theory at the time was that some binary file which stored status
was corrupt and the reinstall made such binary file to be sane again.

So I'm ok with this bug being closed, as I lost the possibility to
reproduce it. You can mark it as fixed in the stretch version.

Thanks.

Bug#916758: Accepted emacs 1:26.1+1-3.2 (source amd64 all) into unstable, unstable

[Rob Browning]

Holger Levsen  writes:

> On Mon, Feb 04, 2019 at 02:51:45PM +0100, Andreas Beckmann wrote:

>> Holger Levsen  writes:

>> > I'm really not sure this is a sensible approach. Usually we try to get
>> > rid off transitional packages, not to add new ones???!
>> 
>> ... s.t. we can finally drop the transitional packages that were
>> introduced in buster for buster +1
>
> as long as that happens... and I guess it also doesnt matter whether we
> have 200 or 203 transitional packages in Buster after all

For what it's worth, while I agree that we don't really "have to"
provide the older transition packages for the ancient versions, I also
agree that they're fairly trivial, and if they're not otherwise trouble,
I think Andreas' plan seems sound.

i.e. it may help some people avoid weird breakage, doesn't cost us much,
and is something we can drop in the not too distant future if/when we
like -- and after we do, I suspect we'll be a lot less likely to see
random bugs filed about strange breakages caused by old vestigial
packages, and we can be a lot more confident when we decide we want to
pursue the code cleanups Andreas has mentioned.

Thanks for the help.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#921131: CVE-2018-10897

[Mike Miller]

Hi Markus!

On Sun, Feb 10, 2019 at 11:15:35 +0100, Markus Frosch wrote:
> I'm not sure how active Mike is currently.

I'm quite active, but I have not touched the rpm/yum related packages in
years since they haven't seen much upstream activity. I'm also honestly
not very interested in rpm/yum currently. I should have given these
packages up for adoption by now, better late than never.

> Since I'm using the package in a multi distro build system, I would
> proceed with uploading a fix and join as co-maintainer.
> 
> I already created a salsa project:
> https://salsa.debian.org/debian/yum-utils
> 
> @Mike: Can I get a short approval?

There is an RPM packaging team that this package should be maintained
with

  * https://salsa.debian.org/pkg-rpm-team
  * https://tracker.debian.org/teams/pkg-rpm/
  * https://wiki.debian.org/Teams/pkg-rpm

Can you move your imported repository to the team group on salsa?

There used to be a mailing list on lists.alioth.d.o, I don't think there
is a replacement team list.

> Also: Is the experimental upload ready for buster?

I think so, I think it was only experimental because of a freeze.

I suggest I file an RFA for yum-utils and Cc you, we can discuss further
there, ok? Do you have any interest in the related packages createrepo,
deltarpm, and yum-metadata-parser?

Also thank you Holger for the nmu and fixing this bug so quickly.

-- 
mike


signature.asc
Description: PGP signature

Bug#884243: djmount status, two patches and about conversion to libupnp 1.8

[Uwe Kleine-König]

Control: affects 921982 + djmount

Hello,

On Mon, Jan 21, 2019 at 08:17:24PM +0100, Uwe Kleine-König wrote:
> I will report a request to remove djmount from unstable in February
> unless someone opposes (and does to work to convert it to libupnp-1.8).

I did this now, but forgot to Cc: this bug. The RM bug is #921982.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#921983: stretch-pu: package gnome-chemistry-utils/0.14.15-1+deb9u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

The gcu-plugin is not longer supported by current firefox. #906855
Stop building the package like it was done in sid.

There are no rdepends.
This will require a cruft-removal pass in stretch to ensure the obsolete
binary packages are actually gone. Does this require a separate RM bug?


Andreas
diff -Nru gnome-chemistry-utils-0.14.15/debian/changelog 
gnome-chemistry-utils-0.14.15/debian/changelog
--- gnome-chemistry-utils-0.14.15/debian/changelog  2016-11-22 
22:01:30.0 +0100
+++ gnome-chemistry-utils-0.14.15/debian/changelog  2019-02-10 
21:52:08.0 +0100
@@ -1,3 +1,13 @@
+gnome-chemistry-utils (0.14.15-1+deb9u1) stretch; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Non-maintainer upload.
+
+  [ Adrian Bunk ]
+  * Drop the obsolete gcu-plugin. (Closes: #906855, #890980)
+
+ -- Andreas Beckmann   Sun, 10 Feb 2019 21:52:08 +0100
+
 gnome-chemistry-utils (0.14.15-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru gnome-chemistry-utils-0.14.15/debian/control 
gnome-chemistry-utils-0.14.15/debian/control
--- gnome-chemistry-utils-0.14.15/debian/control2016-10-03 
12:58:51.0 +0200
+++ gnome-chemistry-utils-0.14.15/debian/control2019-02-10 
21:52:08.0 +0100
@@ -27,7 +27,6 @@
libtool (>= 2.2.6),
libx11-dev (>= 1.0.0),
libxml2-dev (>= 2.4.16),
-   npapi-sdk-dev,
rarian-compat | scrollkeeper,
shared-mime-info (>= 0.12),
xsltproc,
@@ -70,20 +69,6 @@
   * a periodic table of the elements (GChemTable)
   * a spectra viewer (GSpectrum)
 
-Package: gcu-plugin
-Architecture: any
-Depends: libgcu0v5 (= ${binary:Version}),
- ${misc:Depends},
- ${shlibs:Depends},
- ${vendor:Browser}
-Description: GNOME chemistry utils (browser plugin)
- The GNOME Chemistry Utils provide C++ classes and Gtk+-2 widgets
- related to chemistry. They will be used in future versions of both
- gcrystal and gchempaint.
- .
- This package provides a browser plugin for Gecko-based browsers.
- It does not (yet) work with WebKit-based browsers.
-
 Package: gcrystal
 Architecture: any
 Depends: chemical-mime-data,
diff -Nru gnome-chemistry-utils-0.14.15/debian/gcu-plugin.install 
gnome-chemistry-utils-0.14.15/debian/gcu-plugin.install
--- gnome-chemistry-utils-0.14.15/debian/gcu-plugin.install 2016-10-03 
12:58:51.0 +0200
+++ gnome-chemistry-utils-0.14.15/debian/gcu-plugin.install 1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-usr/lib/*/gchemutils/chem-viewer
-usr/lib/*/mozilla/plugins/*.so
diff -Nru gnome-chemistry-utils-0.14.15/debian/rules 
gnome-chemistry-utils-0.14.15/debian/rules
--- gnome-chemistry-utils-0.14.15/debian/rules  2016-10-03 12:58:51.0 
+0200
+++ gnome-chemistry-utils-0.14.15/debian/rules  2019-02-10 21:51:55.0 
+0100
@@ -18,7 +18,7 @@
 override_dh_auto_configure: configure
dh_auto_configure -- \
--libexecdir=\$${libdir}/gchemutils \
-   --with-mozilla-libdir=\$${libdir}/mozilla \
+   --disable-mozilla-plugin \
--without-kde-mime-dir \
--disable-update-databases \
CPPFLAGS="$(CPPFLAGS)" \
@@ -40,11 +40,3 @@
 
 override_dh_strip:
dh_strip --dbgsym-migration='libgcu-dbg (<< 0.14.14~)'
-
-override_dh_gencontrol:
-   dh_gencontrol -Ngcu-plugin
-ifneq (,$(filter Ubuntu,$(DEB_VENDOR)))
-   dh_gencontrol -pgcu-plugin -- -Vvendor:Browser='firefox | seamonkey'
-else
-   dh_gencontrol -pgcu-plugin -- -Vvendor:Browser='iceweasel | iceape'
-endif

Bug#921982: RM: djmount -- RoQA; FTBFS, inactive maintainer, dead upstream

[Uwe Kleine-König]

Package: ftp.debian.org
Severity: normal

Hello,

djmount fails to build from source since libupnp was bumped from
1.6.x to 1.8.x. The transition was long planned, the respective bug
(#884243) shows that upstream and the Debian maintainer don't even have
the setup to test patches any more. djmount was removed from testing
already in November 2018 because of that. djmount didn't see an upload
since 2014 apart from an NMU fixing #836753 in 2016.

Best regards
Uwe

Bug#763744: Reproducible on stretch?

[Mathieu Parent]

Hi,

Those are now old bugs. Can you reproduce the panics on stretch or
testing (upcoming buster)?

Regards

-- 
Mathieu Parent

Bug#921981: haproxy: Workers segmentation fault if unique-id-header is used

[Tim Duesterhus]

Package: haproxy
Version: 1.8.18-1~bpo9+1
Severity: important
Tags: patch upstream

Dear Maintainer,

please see this issue I already filed upstream:

https://github.com/haproxy/haproxy/issues/40

I'm including a short summary below:

If I run haproxy with the attached reproducer configuration and
direct concurrent requests to it then usually the worker process
segfaults.

The issue is a regression in 1.8.18 and already fixed upstream with this commit:

http://git.haproxy.org/?p=haproxy.git;a=commit;h=09c4bab41188c13e7a9227f8baaff230ebdd0875
https://github.com/haproxy/haproxy/commit/09c4bab41188c13e7a9227f8baaff230ebdd0875

Consider backporting it because of the impending soft freeze of Debian buster.

-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages haproxy depends on:
ii  adduser  3.115
ii  dpkg 1.18.25
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u3
ii  liblua5.3-0  5.3.3-1
ii  libpcre2-8-0 10.22-3
ii  libssl1.11.1.0j-1~deb9u1
ii  libsystemd0  232-25+deb9u8
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

haproxy recommends no packages.

Versions of packages haproxy suggests:
pn  haproxy-doc  
pn  vim-haproxy  

-- Configuration Files:
/etc/haproxy/haproxy.cfg changed:
defaults
unique-id-format %{+X}o\ FOO-%Ts%rt
frontend fe_http
mode http
bind *:8080
unique-id-header X-Req-ID

default_backend be_http
backend be_http
mode http
http-request set-header Host example.com
server example example.com:80


-- no debconf information

Bug#921980: O: posixtestsuite -- POSIX conformance test suite report log

[Guillem Jover]

Package: wnpp
Severity: normal

I intend to orphan the posixtestsuite package.

The package description is:
 The POSIX Test Suite is a free (as in speech) test suite with the goal
 of  performing conformance, functional, and stress testing of the IEEE
 1003.1-2001 System Interfaces specification in a manner that is agnostic
 to any given implementation.
 .
 This package only provides the test suite results in a log file. If you
 want to run the testsuite, use the source package of the same name (e.g.
 apt-get source posixtestsuite).


Upstream is dead, as it was merged into the Linux Test Project some
time ago:

  


anyone wanting to take over, might prefer to spend the effort instead
ressurrecting the ltp package. See #672776.

Thanks,
Guillem

Bug#683404: Feedback on this bug

[Mathieu Parent]

Control: severity -1 normal

Hello,

This bug was somewhat forgotten.

Can you try again from stretch, and also if possible from testing
(future buster)?

Can you provide your smb.conf?

Also note that wbinfo -r is not reliable, per manpage:

   -r|--user-groups username
   Try to obtain the list of UNIX group ids to which the user
belongs. This only works for users defined on a Domain Controller.

   There are two scenaries:

   1. User authenticated: When the user has been
authenticated, the access token for the user is cached. The correct
group
  memberships are then returned from the cached
user token (which can be outdated).

   2. User *NOT* authenticated: The information is
queries from the domain controller using the machine account
credentials which
  have limited permissions. The result is normally
incomplete and can be also incorrect.


Regards
-- 
Mathieu Parent

Bug#921979: lmfit-py: FTBFS randomly (test_covariance_matrix.test_bounded_parameters fails)

[Santiago Vila]

Package: src:lmfit-py
Version: 0.9.11+dfsg-1
Severity: serious
Tags: ftbfs patch

Hello Andreas et al.

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>/lmfit-py-0.9.11+dfsg'
dh_auto_build
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/lineshapes.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/models.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/jsonutils.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/printfuncs.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/_ampgo.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/model.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/minimizer.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/parameter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/confidence.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
copying lmfit/_version.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
copying lmfit/ui/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
copying lmfit/ui/ipy_fitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
copying lmfit/ui/basefitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/ui
UPDATING 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/_version.py
set 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build/lmfit/_version.py
 to '0.9.11'
I: pybuild pybuild:295: cp -r NIST_STRD 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython2_2.7_lmfit/build
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/lineshapes.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/models.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/jsonutils.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/printfuncs.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/_ampgo.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/model.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/minimizer.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/parameter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/confidence.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
copying lmfit/_version.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit
creating 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
copying lmfit/ui/__init__.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
copying lmfit/ui/ipy_fitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
copying lmfit/ui/basefitter.py -> 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/ui
UPDATING 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/_version.py
set 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build/lmfit/_version.py
 to '0.9.11'
I: pybuild pybuild:295: cp -r NIST_STRD 
/<>/lmfit-py-0.9.11+dfsg/.pybuild/cpython3_3.7_lmfit/build
PYTHONPATH=. http_proxy='localhost' sphinx-build -N -bhtml doc/ build/html  # 
HTML generator
Running Sphinx v1.7.9
making output directory...
loading pickled environment... not yet created
loading intersphinx inventory from https://docs.python.org/2/objects.inv...
loading intersphinx inventory from 
https://docs.scipy.org/doc/numpy/objects.inv...
loading intersphinx inventory from 
https://docs.scipy.org/doc/scipy/reference/objects.inv...
building [mo]: targets for 0 po files that are out of date
building [html]: 

Bug#917797:

[Michael Hudson-Doyle]

Ah yes this was indeed fixed by 2.37-1 or something around there but we
forgot to mention this bug in the changelog. Thanks for the reminder!

Bug#921978: RM: python3-redmine python-redmine [all] -- RoQA; renamed to python{,3}-redminelib

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please remove the obsolete arch:all packages 

python-redmine |1.5.1-1 | all
python3-redmine |1.5.1-1 | all

they have been renamed to python{,3}-redminelib in 2.1.1-1


Andreas

Bug#921953: apacheds: Further analysis

[Johan Grip]

Hi.

Looked at it a bit more and found the following things.

ApacheDS have moved it's configuration to a dynamic schema based setup, 
like OpenLDAP.
As part of the startup it tries to migrate the config.ldif to a folder 
based setup
in ou=config. Since the user it runs as doesn't have write permission 
for /etc/apacheds

it fails and then gives up starting.

Additionally, once the permission issue is sorted the current systemd 
unit checks for the
existance of the config.ldif file which will be renamed as part of the 
migration so it will

not start the server.

The patch below fixes both but I'm not sure if services are supposed to 
write in /etc.


--
diff -ur apache-directory-server-2.0.0~M15/debian/apacheds.postinst 
apache-directory-server-2.0.0~M15-mod/debian/apacheds.postinst
--- apache-directory-server-2.0.0~M15/debian/apacheds.postinst  
2015-07-01 22:22:10.0 +0200
+++ apache-directory-server-2.0.0~M15-mod/debian/apacheds.postinst  
2019-02-10 21:07:19.687924216 +0100

@@ -32,7 +32,9 @@
 # Fix directory permissions
 chown -R $APACHEDS_USER:$APACHEDS_GROUP /var/log/apacheds || 
true
 chown -R $APACHEDS_USER:$APACHEDS_GROUP /var/lib/apacheds || 
true

+chown $APACHEDS_USER:$APACHEDS_GROUP /etc/apacheds
 chown $APACHEDS_USER:$APACHEDS_GROUP /etc/apacheds/*
+chmod 640 /etc/apacheds
 chmod 640 /etc/apacheds/*
 ;;

diff -ur apache-directory-server-2.0.0~M15/debian/apacheds.service 
apache-directory-server-2.0.0~M15-mod/debian/apacheds.service
--- apache-directory-server-2.0.0~M15/debian/apacheds.service   
2015-07-01 22:22:10.0 +0200
+++ apache-directory-server-2.0.0~M15-mod/debian/apacheds.service   
2019-02-10 21:04:28.228844408 +0100

@@ -1,7 +1,8 @@
 [Unit]
 Description=Apache Directory Server
 After=network.target
-ConditionPathExists=/etc/apacheds/config.ldif
+ConditionPathExists=|/etc/apacheds/config.ldif
+ConditionPathIsDirectory=|/etc/apacheds/ou=config

 [Service]
 Type=simple

Regards,
  Johan

Bug#921975: ITS: attr

[Nathan Scott]

On Mon, Feb 11, 2019 at 6:39 AM Guillem Jover  wrote:
>
> Source: attr
> Source-Version: 1:2.4.47-2
> Severity: important
>
> Hi!
>
> This package needs some attention, and looks like a candidate for
> salvaging. Anibal is already being tracked by the MIA team, and I
> think it's just a matter of days until he gets an orphaning pass.
>
> I'd like to get updated packages uploaded for the next release, so
> some time before the freeze. That's why I'll probably be using a
> shorter salvaging process here. Nathan please let me know if you
> have any objection over this?

No objection at all Guillem, thanks for taking on this work.

cheers.

--
Nathan

Bug#921974: ITS: acl

[Nathan Scott]

On Mon, Feb 11, 2019 at 6:36 AM Guillem Jover  wrote:
>
> Source: acl
> Source-Version: 2.2.52-3
> Severity: important
>
> Hi!
>
> This package needs some attention, and looks like a candidate for
> salvaging. Anibal is already being tracked by the MIA team, and I
> think it's just a matter of days until he gets an orphaning pass.
>
> I'd like to get updated packages uploaded for the next release, so
> some time before the freeze. That's why I'll probably be using a
> shorter salvaging process here. Nathan please let me know if you
> have any objection over this?

No objection at all Guillem, thanks for taking on this work.

cheers.

--
Nathan

Bug#920995: spatialite: hangs during virtualknn test

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream

On 1/31/19 2:17 PM, Bas Couwenberg wrote:
> On 2019-01-31 13:36, Andreas Beckmann wrote:
>> during a test rebuild of spatialite/experimental I noticed that it hangs
>> during the virtualknn test. After killing that process the build
>> continued and succeeded. I think this has so far happened more than
>> once, not sure if on amd64 or or i386 or both.
> 
> I've confirmed this issue in an amd64 experimental chroot, and forwarded
> the issue upstream:
>  
> https://www.gaia-gis.it/fossil/libspatialite/tktview/2cad2f4b9df468fa062f624638d4ac6072611821

Upstream has tracked down the issue and committed a fix:

 https://www.gaia-gis.it/fossil/libspatialite/ci/90180e065dfdd8fa?sbs=0

A new (beta) release should be published next week, so I'll wait for
that instead of adding a patch with the fix since the issue only affects
the package in experimental.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#921977: stretch-pu: package unzip/6.0-21+deb9u1

[Santiago Vila]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello. Security team tells me this does not deserve a DSA but it's ok
for stable-proposed-updates.

(I know it's a little bit late for 9.8. Sorry for that, and no problem
if this is for 9.9 instead).

Debdiff below.

Thanks.

diff -Nru unzip-6.0/debian/changelog unzip-6.0/debian/changelog
--- unzip-6.0/debian/changelog  2016-12-11 21:03:30.0 +0100
+++ unzip-6.0/debian/changelog  2019-02-10 20:53:00.0 +0100
@@ -1,3 +1,10 @@
+unzip (6.0-21+deb9u1) stretch; urgency=medium
+
+  * Fix buffer overflow in password protected ZIP archives. Closes: #889838.
+Patch borrowed from SUSE. For reference, this is CVE-2018-135.
+
+ -- Santiago Vila   Sun, 10 Feb 2019 20:53:00 +0100
+
 unzip (6.0-21) unstable; urgency=medium
 
   * Rename all debian/patches/* to have .patch ending.
diff -Nru 
unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch 
unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch
--- unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch
1970-01-01 01:00:00.0 +0100
+++ unzip-6.0/debian/patches/20-cve-2018-135-unzip-buffer-overflow.patch
2019-02-10 20:53:00.0 +0100
@@ -0,0 +1,35 @@
+From: Karol Babioch 
+Subject: Fix buffer overflow in password protected zip archives
+Bug-Debian: https://bugs.debian.org/889838
+Origin: https://bugzilla.novell.com/attachment.cgi?id=759406
+
+--- a/fileio.c
 b/fileio.c
+@@ -1582,6 +1582,10 @@
+ int r = IZ_PW_ENTERED;
+ char *m;
+ char *prompt;
++char *zfnf;
++char *efnf;
++size_t zfnfl;
++int isOverflow;
+ 
+ #ifndef REENTRANT
+ /* tell picky compilers to shut up about "unused variable" warnings */
+@@ -1590,7 +1594,15 @@
+ 
+ if (*rcnt == 0) {   /* First call for current entry */
+ *rcnt = 2;
+-if ((prompt = (char *)malloc(2*FILNAMSIZ + 15)) != (char *)NULL) {
++zfnf = FnFilter1(zfn);
++efnf = FnFilter2(efn);
++zfnfl = strlen(zfnf);
++isOverflow = TRUE;
++if (2*FILNAMSIZ >= zfnfl && (2*FILNAMSIZ - zfnfl) >= strlen(efnf))
++{
++  isOverflow = FALSE;
++}
++if ((isOverflow == FALSE) && ((prompt = (char *)malloc(2*FILNAMSIZ + 
15)) != (char *)NULL)) {
+ sprintf(prompt, LoadFarString(PasswPrompt),
+ FnFilter1(zfn), FnFilter2(efn));
+ m = prompt;
diff -Nru unzip-6.0/debian/patches/series unzip-6.0/debian/patches/series
--- unzip-6.0/debian/patches/series 2016-12-11 20:00:00.0 +0100
+++ unzip-6.0/debian/patches/series 2019-02-10 20:51:54.0 +0100
@@ -17,3 +17,4 @@
 17-restore-unix-timestamps-accurately.patch
 18-cve-2014-9913-unzip-buffer-overflow.patch
 19-cve-2016-9844-zipinfo-buffer-overflow.patch
+20-cve-2018-135-unzip-buffer-overflow.patch

Bug#921538: Fails to start since upgrade to 1.9.0-1

[James Cloos]

Package: unbound
Followup-For: Bug #921538

I found the that problem is that 1.9.0-1 does a chroot("/etc/unbound") even 
though
there is no chroot option in the config files.

Once that occurs, it cannot see files like /var/lib/unbound/root.key et alia.

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

Kernel: Linux 4.15.0-2-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2018091102
ii  libc6   2.28-6
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.4.0-1
ii  libprotobuf-c1  1.3.1-1+b1
ii  libpython3.73.7.2-2
ii  libssl1.1   1.1.1a-1
ii  libsystemd0 240-5
ii  lsb-base10.2018112800
ii  openssl 1.1.1a-1
ii  unbound-anchor  1.8.1-1+b1

unbound recommends no packages.

Versions of packages unbound suggests:
pn  apparmor  

-- no debconf information

Bug#921976: mosquitto: CVE-2018-12546 CVE-2018-12550 CVE-2018-12551

[Salvatore Bonaccorso]

Source: mosquitto
Version: 1.5.5-1.1
Severity: grave
Tags: security upstream
Control: found -1 1.4.10-3+deb9u2
Control: found -1 1.4.10-3
Control: fixed -1 1.4.10-3+deb9u3

Hi,

The following vulnerabilities were published for mosquitto, fixed in
DSA with 1.4.10-3+deb9u3 but yet open for buster.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-12546
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12546
[1] https://security-tracker.debian.org/tracker/CVE-2018-12550
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12550
[2] https://security-tracker.debian.org/tracker/CVE-2018-12551
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12551

Regards,
Salvatore

Bug#906142: stretch-pu: package vulture/0.11-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2018-08-14 at 23:06 +0300, Adrian Bunk wrote:
>   * Non-maintainer upload.
>   * Add the missing dependency on python3-pkg-resources.
> (Closes: #904762)

This ended up being handled in #921910.

Andreas - *please* check for existing requests first.

Regards,

Adam

Bug#882824: stretch-pu: package python-arpy/1.1.1-3~deb9u1

[Adam D. Barratt]

Control: tags -1 +pending -moreinfo

[see below for why]

On Sat, 2018-02-10 at 10:37 +0100, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Mon, Nov 27, 2017 at 03:01:48 +0100, Andreas Beckmann wrote:
> 
> > Package: release.debian.org
> > Severity: normal
> > Tags: stretch
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > Let's fix the python3 dependencies. #867418
> > 
> > There is some metadata noise by just rebuilding the package from
> > sid.
> > And there is a lot of file movement noise in the python-arpy caused
> > by
> > rebuilding a 4 year old package in stretch:
> > 
> > $ debdiff python-arpy_1.1.1-2_all.deb python-arpy_1.1.1-
> > 3~deb9u1_all.deb
> > [The following lists of changes regard files as different if they
> > have
> > different names, permissions or owners.]
> > 
> 
> I'm not convinced this is worth the churn.  I can see it for a
> program,
> but for libraries what's the likelyhood anyone's actually going to
> run
> into the bug?

It turns out I got confused by the multiple requests for this package,
as evidenced by the fact that I accepted the upload but this isn't the
bug that ended up +pending.

However, I had previously acked #880622 back in 2017, which apparently
never got uploaded, so I'm going to ignore the fact that you uploaded
something that had been semi-NACKed a year beforehand. I would
appreciate us not ending up in a similar situation in future again.
Please check for duplicates before filing new requests, and please
don't upload if there were queries / issues.

Regards,

Adam

Bug#921975: ITS: attr

[Guillem Jover]

Source: attr
Source-Version: 1:2.4.47-2
Severity: important

Hi!

This package needs some attention, and looks like a candidate for
salvaging. Anibal is already being tracked by the MIA team, and I
think it's just a matter of days until he gets an orphaning pass.

I'd like to get updated packages uploaded for the next release, so
some time before the freeze. That's why I'll probably be using a
shorter salvaging process here. Nathan please let me know if you
have any objection over this?

(The usual salvaging process is described in the devref § 5.12.)

Thanks,
Guillem

Bug#921974: ITS: acl

[Guillem Jover]

Source: acl
Source-Version: 2.2.52-3
Severity: important

Hi!

This package needs some attention, and looks like a candidate for
salvaging. Anibal is already being tracked by the MIA team, and I
think it's just a matter of days until he gets an orphaning pass.

I'd like to get updated packages uploaded for the next release, so
some time before the freeze. That's why I'll probably be using a
shorter salvaging process here. Nathan please let me know if you
have any objection over this?

(The usual salvaging process is described in the devref § 5.12.)

Thanks,
Guillem

Bug#921973: RM: gtkdataboxmm -- ROM; RC buggy, de facto orphaned

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

according to

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849574#10

the Uploader is not using the package any more and popcon has
dropped dramatically so I see no need to invest more time into
the long standing RC bugs.

Please remove this package from Debian.

Kind regards

Andreas.

Bug#884770: grub2: Support for booting Xen on 64-bit Arm platforms

[Colin Watson]

On Tue, Dec 19, 2017 at 12:53:13PM +, Julien Grall wrote:
> Grub recently gain support of loading Xen on 64-bit Arm platforms. With
> this feature, Debian will be able to boot out-of-box on UEFI platform
> when using Xen.
> 
> I was wondering if it would be possible to upgrade grub for buster?

Hi,

Do you have a list of commits that could be cherry-picked for this?  I'm
provisionally willing to grab them, but probably can't identify the full
set for myself as I can't test it.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#921667: [pkg-lxc-devel] Bug#921667: lxc, lava-dev: lxc fails to install along lava-dev --install-recommends

[Antonio Terceiro]

On Sun, Feb 10, 2019 at 12:13:43AM +0100, Pierre-Elliott Bécue wrote:
> Le samedi 09 février 2019 à 22:19:13+0100, Andreas Beckmann a écrit :
> > On 2019-02-09 21:51, Pierre-Elliott Bécue wrote:
> > > I'm not sure that there is something we can do regarding lxc. Am I
> > > wrong?
> > 
> > You could try to figure out why lxc explodes.
> > Probably some package places some configuration file at some location
> > 
> > 
> > Andreas
> > 
> > PS: I should be able to get a shell in the chroot after the failure
> > occurred, in case you want me to collect some information.
> 
> That's a good idea. This error is not clear at all to me.

I can reproduce this on a clean chroot (but not on a clean VM)

> Could you please try to run the .postinst of lxc manually with a set -x?
> The goal would be to check which part explodes.

8<8<8<-
Setting up lxc (1:3.1.0+really3.0.3-2) ...
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/lxc.postinst configure 
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ upgrade configure 
+ [ ! -z  ]
+ [ -z  ]
+ which apparmor_parser
+ [ -e /etc/apparmor.d/lxc-containers ]
+ apparmor_parser -r -W -T /etc/apparmor.d/lxc-containers
Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
Use --subdomainfs to override.
dpkg: error processing package lxc (--configure):
 installed lxc package post-installation script subprocess returned error exit 
status 1
dpkg: dependency problems prevent configuration of lxc-templates:
 lxc-templates depends on lxc (>= 1:3.0.2-1~exp+1); however:
  Package lxc is not configured yet.

dpkg: error processing package lxc-templates (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 lxc
 lxc-templates
E: Sub-process /usr/bin/dpkg returned an error code (1)
8<8<8<-


signature.asc
Description: PGP signature

Bug#921932: RM: calendar-exchange-provider/3.9.0-4

[Mechtilde Stehmann]

Hello Adam,

the update has no longer been necessary. There is no such version in sid
or testing/buster.

Now I know that there is no version working with thunderbird 60.

Sorry for the confusion but the reason is the major update in Stable. So
I dad to reject all packages.

In sid and testing is now a new package webext-tbsync which can help for
this task.

Kind regards

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#921970: bugs.debian.org: case sensitiviness of email addresses

[Dmitry Bogatov]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

BTS incorrectly handles my email address, which contains uppercase
letters.

To reproduce problem, let's first visit some of my packages, like

  https://bugs.debian.org/dvtm

At top of page there is 'Maintainers for dvtm are' and link to

  https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=KAction%40debian.org

But if you follow this link, BTS says that no reports found. To get list
of my bugreports, you have to manually downcase my email address.

As far as I remember RFC, user part of email is to be considered opaque
and no transformation on it should be done.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)


pgpwPIwrI8G12.pgp
Description: PGP signature

Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large

[Zac Morris]

(meta: sorry reply all goes against my core nature ;-)

Ive stepped out for a bit so I'll take a look at gdb-minimal when I'm back,
but as of this morning I haven't been able to make it crash.  I'll try the
largest energized pak when I'm back and see if I can force a crash then.

Thanks,
Zac


On Sun, Feb 10, 2019, 2:03 PM Bernhard Übelacker 
wrote:

> Ok, so the package corekeeper would be an option?
> Is gdb-minimal also already too much?
>
> Kind regards,
> Bernhard
>
> PS.: please leave the bugs email as CC or To. ;-)
>
>

Bug#921972: lintian-brush: when d/compat is missing

[Dmitry Bogatov]

Package: lintian-brush
Version: 0.12
Severity: wishlist

Dear Maintainer,

please consider following patch to avoid warnings, when there is no
`debian/compat'.

By the way, it is quite unfortunate, that fixer API disallow early
sys.exit(0).

From 984f18ecf19eec6df94cb7c5701f62f35de88785 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sun, 10 Feb 2019 00:05:54 +
Subject: [PATCH] Do not throw exception on packages without d/compat

Previosly, following error message was triggered by missing `debian/compat':

 Some fixer scripts failed to run: 
{'package-needs-versioned-debhelper-build-depends'}. Run with --verbose for 
details.

Running with --verbose exposed Python exceptions to user, which is not
supposed to understand Python.
---
 ...e-needs-versioned-debhelper-build-depends.py | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/fixers/package-needs-versioned-debhelper-build-depends.py 
b/fixers/package-needs-versioned-debhelper-build-depends.py
index a48d768..c4a50ca 100755
--- a/fixers/package-needs-versioned-debhelper-build-depends.py
+++ b/fixers/package-needs-versioned-debhelper-build-depends.py
@@ -1,23 +1,26 @@
 #!/usr/bin/python3
 
+import sys
 from lintian_brush.control import (
 ensure_minimum_version,
 update_control,
 )
-
-
-with open('debian/compat', 'r') as f:
-minimum_version = f.read().strip()
-
-
 def bump_debhelper(control):
 control["Build-Depends"] = ensure_minimum_version(
 control["Build-Depends"],
 "debhelper",
 "%s~" % minimum_version)
 
+# Debian source package is not obliged to contain `debian/control'.
+# Firstly, it may not use debhelper; secondly it may use modern
+# `debhelper-compat' dependency style.
+try:
+with open('debian/compat', 'r') as f:
+minimum_version = f.read().strip()
+update_control(source_package_cb=bump_debhelper)
+except FileNotFoundError:
+minimum_version =  # Not used anyway.
 
-update_control(source_package_cb=bump_debhelper)
 print("Bump debhelper dependency to >= %s, since that's what is "
   "used in debian/compat." % minimum_version)
 print("Fixed-Lintian-Tags: package-needs-versioned-debhelper-build-depends")


pgpD_o_v7G_3X.pgp
Description: PGP signature

Bug#253012: why not reuse checkbashism

[Dmitry Bogatov]

[ 10 years later ]

Hi!

Probably I am missing something, but why not just reuse checkbashism(1)
from devscripts? It could be run on both maintainer scripts and scripts,
provided by binary package.

Any interest in patch?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpWt5Y8fqhQe.pgp
Description: PGP signature

Bug#921893: supercollider 3.7.0~repack-4+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: supercollider
Version: 3.7.0~repack-4+deb9u1

Explanation: disable support for XEmacs and Emacs <=23

Bug#921907: grokmirror 1.0.0-1.1~deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: grokmirror
Version: 1.0.0-1.1~deb9u1

Explanation: add missing dependency on python-pkg-resources

Bug#921911: yosys 0.7-2+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: yosys
Version: 0.7-2+deb9u1

Explanation: fix "ModuleNotFoundError: No module named 'smtio'"