Bug#793404: massive waste of CPU time in debian/rules by inline commands

[Niels Thykier]

Hideki Yamane:
> Hi Niels,
> 
>  Thanks for your explanation :)
> 
> On Sat, 05 Jan 2019 09:52:00 +
> Niels Thykier  wrote:
>> We are very far from being able to flip the default.  There are some
>> 800+ packages that need to be updated to follow latest policy
>> requirements plus explicitly declare their need for (fake)root.
> 
>  Okay, maybe we can achieve it as compat level 13, 14 or 15...
>  but lg way to go, I agree with it.
> 
> 

Sorry, but this cannot be done via a compat level.  If it could have, I
would have done it in compat 12 and moved on.

Please see #884999 for the reasons why debhelper cannot change this
default for us.

Thanks,
~Niels

Bug#918452: RFS: libt3widget/1.0.3-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: libt3widget
  Version : 1.0.3-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3widget.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3widget-dev - Development files for libt3widget
  libt3widget2 - C++ terminal dialog toolkit

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3widget/libt3widget_1.0.3-1.dsc

Changes since the last upload:

  * New upstream release.
  * Change the platform requirement for libgpm-dev to match the build
platforms of libgpm.

Regards,
  Gertjan Halkes

Bug#918451: RFS: libt3highlight/0.4.6-1

[Gertjan Halkes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: libt3highlight
  Version : 0.4.6-1
  Upstream Author : Gertjan Halkes 
* URL : https://os.ghalkes.nl/t3/libt3highlight.html
* License : GPLv3
  Section : libs

It builds those binary packages:

  libt3highlight-dev - Development files for libt3highlight
  libt3highlight2 - Syntax highlighting library
  t3highlight - Command-line syntax highligher

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/libt/libt3highlight/libt3highlight_0.4.6-1.dsc

Changes since the last upload:

  * New upstream release.

Regards,
  Gertjan Halkes

Bug#918230: python-django: CVE-2019-3498: Content spoofing possibility in the default 404 page

[Chris Lamb]

Hi Salvatore,

> With the 0017-CVE-2019-3498.patch patch there is something strange.
> While it touches correctly the files django/views/defaults.py and the
> tests, it touches and modifies files in debian/*, other patches and
> series file.

Thanks for your review. I went through my shell's history and
unpicked what happened; whilst I had created and tested a regular
patch file at debian/patches/CVE-2019-3498.patch I wanted to store
everything in DPMT's Git repository and, as part of that,
accidentally used git commit --whilst on the magic git-pq(1) branch
and thus included all of these nonsense changes.

Updated patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/changelog b/debian/changelog
index b1c56f7c5..fa89c8b21 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-django (1:1.10.7-2+deb9u4) stretch-security; urgency=high
+
+  * CVE-2019-3498: Prevent a content-spoofing vulnerability in the default
+404 page. (Closes: #918230)
+
+ -- Chris Lamb   Sun, 06 Jan 2019 09:35:11 +0100
+
 python-django (1:1.10.7-2+deb9u3) stretch; urgency=medium
 
   * Default to supporting Spatialite >= 4.2. (Closes: #910240)
diff --git a/debian/patches/0017-CVE-2019-3498.patch 
b/debian/patches/0017-CVE-2019-3498.patch
new file mode 100644
index 0..588db30a8
--- /dev/null
+++ b/debian/patches/0017-CVE-2019-3498.patch
@@ -0,0 +1,95 @@
+From: Tom Hacohen 
+Date: Fri, 4 Jan 2019 02:21:55 +
+Subject: Fixed #30070,
+ CVE-2019-3498 -- Fixed content spoofing possiblity in the default 404 page.
+
+Co-Authored-By: Tim Graham 
+Backport of 1ecc0a395be721e987e8e9fdfadde952b6dee1c7 from master.
+---
+ django/views/defaults.py |  8 +---
+ tests/handlers/tests.py  | 12 
+ 2 files changed, 13 insertions(+), 7 deletions(-)
+
+diff --git a/django/views/defaults.py b/django/views/defaults.py
+index 348837e..5ec9ac8 100644
+--- a/django/views/defaults.py
 b/django/views/defaults.py
+@@ -2,6 +2,7 @@ from django import http
+ from django.template import Context, Engine, TemplateDoesNotExist, loader
+ from django.utils import six
+ from django.utils.encoding import force_text
++from django.utils.http import urlquote
+ from django.views.decorators.csrf import requires_csrf_token
+ 
+ ERROR_404_TEMPLATE_NAME = '404.html'
+@@ -21,7 +22,8 @@ def page_not_found(request, exception, 
template_name=ERROR_404_TEMPLATE_NAME):
+ Templates: :template:`404.html`
+ Context:
+ request_path
+-The path of the requested URL (e.g., '/app/pages/bad_page/')
++The path of the requested URL (e.g., '/app/pages/bad_page/'). It's
++quoted to prevent a content injection attack.
+ exception
+ The message from the exception which triggered the 404 (if one was
+ supplied), or the exception class name
+@@ -37,7 +39,7 @@ def page_not_found(request, exception, 
template_name=ERROR_404_TEMPLATE_NAME):
+ if isinstance(message, six.text_type):
+ exception_repr = message
+ context = {
+-'request_path': request.path,
++'request_path': urlquote(request.path),
+ 'exception': exception_repr,
+ }
+ try:
+@@ -50,7 +52,7 @@ def page_not_found(request, exception, 
template_name=ERROR_404_TEMPLATE_NAME):
+ raise
+ template = Engine().from_string(
+ 'Not Found'
+-'The requested URL {{ request_path }} was not found on this 
server.')
++'The requested resource was not found on this server.')
+ body = template.render(Context(context))
+ content_type = 'text/html'
+ return http.HttpResponseNotFound(body, content_type=content_type)
+diff --git a/tests/handlers/tests.py b/tests/handlers/tests.py
+index 9f01cb2..50a3488 100644
+--- a/tests/handlers/tests.py
 b/tests/handlers/tests.py
+@@ -2,6 +2,7 @@
+ 
+ from __future__ import unicode_literals
+ 
++import sys
+ import unittest
+ 
+ from django.core.exceptions import ImproperlyConfigured
+@@ -19,6 +20,8 @@ try:
+ except ImportError:  # Python < 3.5
+ HTTPStatus = None
+ 
++PY37 = sys.version_info >= (3, 7, 0)
++
+ 
+ class HandlerTests(SimpleTestCase):
+ 
+@@ -180,16 +183,17 @@ class HandlerRequestTests(SimpleTestCase):
+ 
+ def test_invalid_urls(self):
+ response = self.client.get('~%A9helloworld')
+-self.assertContains(response, '~%A9helloworld', status_code=404)
++self.assertEqual(response.status_code, 404)
++self.assertEqual(response.context['request_path'], 
'/~%25A9helloworld' if PY37 else '/%7E%25A9helloworld')
+ 
+ response = self.client.get('d%aao%aaw%aan%aal%aao%aaa%aad%aa/')
+-self.assertContains(response, 'd%AAo%AAw%AAn%AAl%AAo%AAa%AAd%AA', 
status_code=404)
++self.assertEqual(response.context['request_path'], 
'/d%25AAo%25AAw%25AAn%25AAl%25AAo%25AAa%25AAd%25AA')
+ 
+ response = self.cli

Bug#918366: FTBFS for armhf on arm64, fails some tests

[Yavor Doganov]

Steve McIntyre wrote:
> Package: src:gnustep-base
> Version: 1.25.1-4
> Severity: important

> I've tried to build gnustep-base for armhf on top of arm64, and AFAICS
> it's failing some of its tests:

Thanks for the report.  Only one test is failing:

| base/NSInvocation/general.m:
| Failed test: general.m:208 ... Can send/return NSRect

This is consistent failure as it failed 3 times on arm-arm-01 (arm64
buildd targeting armhf) in November when gnustep-base was binNMUed for
the ICU transition.  Finally it was given back again and built
successfully on arnold.

I see that libffi was also built on arm-arm-01.  It would help a lot
if you can retry the gnustep-base build with libffi built on armhf.
If it succeeds it would certainly mean that the problem is in libffi.
Otherwise, it may well be a GNUstep bug which we'll need to
investigate somehow.

Bug#918453: RM: libllvm-ocaml-dev [armel] -- NBS; Manual cruft removal needed

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal


llvm-defaults (0.46) unstable; urgency=medium

  * Remove armel support in libllvm-ocaml-dev

 -- Sylvestre Ledru   Sat, 17 Nov 2018 09:49:30 +0100

Bug#914965: nodejs: Node.js 10

[Jérémy Lal]

Package: nodejs
Followup-For: Bug #914965
Control: fixed -1 10.15.0~dfsg-6

Nodejs 10.15 is available in sid right now.



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

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

Versions of packages nodejs depends on:
ii  libc-ares2 1.14.0-1
ii  libc6  2.28-4
ii  libgcc11:8.2.0-13
ii  libicu63   63.1-5
ii  libnghttp2-14  1.35.1-1
ii  libnode64  10.15.0~dfsg-8
ii  libssl1.1  1.1.1a-1
ii  libstdc++6 8.2.0-13
ii  libuv1 1.24.0-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20180409
ii  nodejs-doc   10.15.0~dfsg-6

Versions of packages nodejs suggests:
ii  npm  5.8.0+ds6-2

-- no debconf information

Bug#902512: nodejs: FTBFS in buster/sid (failing tests)

[Jérémy Lal]

Package: src:nodejs
Followup-For: Bug #902512
Control: fixed -1 10.15.0~dfsg-6

This has been fixed in nodejs 10, now in sid.


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

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

Bug#913508: nodejs FTBFS with ICU 63.1

[Jérémy Lal]

Package: src:nodejs
Followup-For: Bug #913508
Control: fixed -1 10.15.0~dfsg-6

This has been fixed in nodejs 10.


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

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

Bug#900653: nodejs: autopkgtest regression

[Jérémy Lal]

Package: src:nodejs
Followup-For: Bug #900653
Control: fixed -1 10.15.0~dfsg-6

Fixed in unstable.


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

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

Bug#918438: orig tarball components with uppercase letters

[Andrey Rahmatullin]

On Sun, Jan 06, 2019 at 12:34:30AM +, Ian Jackson wrote:
> This allows the possibility of uppercase letters [1].  But of course
> distinguishing case of letters is troublesome for some computers.
Can you please explain why is this a problem for us?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#918454: vim should not Build-Depends: libtool-bin

[Helmut Grohne]

Source: vim
Version: 2:8.1.0693-1

Hi James,

I see that you added a build dependency on libtool-bin. That's
unfortunate as we want to remove libtool-bin (not libtool) from the
archive.

I'm hoping that we can still revert this part and find a better solution
as the reasons for adding it are still on your mind. debian/changelog
says you need them for libterm tests.

I see that vim is using autotools. Can you instead ask autotools to
create a libtool at configure time and use that for libterm?

Please refer to
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=842456;filename=lua5.3_5.3.1-1.2.debdiff;msg=5
for a very minimal of adding libtool to an autotools-less project. Very
likely, all you need is LT_INIT and AC_PROG_LIBTOOL and then using
${LIBTOOL} instead of libtool.

Can you look into that? Thanks in advance.

Helmut

Bug#917958: mirror listing update for mirror.librelabucm.org

[Peter Palfrader]

Control: retitle -1 mirror.librelabucm.org: upstream
Control: tag -1 +moreinfo

On Tue, 01 Jan 2019, Pablo Garcia de los Salmones wrote:

> Site: mirror.librelabucm.org
> Type: leaf
> Archive-architecture: amd64 arm64 armel armhf i386 kfreebsd-i386 mips
> Archive-http: /debian/
> Maintainer: Pablo Garcia de los Salmones 
> Country: ES Spain
> Location: Spain, Madrid, Universidad Complutense de Madrid, Facultad de 
> Informática, LibreLabUCM
> Sponsor: LibrelabUCM https://librelabucm.org

Hi!

According to
http://mirror.librelabucm.org/debian/project/trace/mirror.librelabucm.org
you use ftp.de.debian.org as an upstream mirror.

Please, do not use ftp.*.debian.org.  First, ftp.*.debian.org services only
guarantee that http is available on /debian, no guarantee for rsync access
exists.  Even if an ftp.CC.debian.org supports rsync now, there is no guarantee
that it will in the future.  Second, ftp.CC.debian.org might be a round robin
of different sites, so you would not always pull from the same upstream.

Better pick an individual name, such as debian.inf.tu-dresden.de which
currently is ftp.de.debian.org.


Also, weird choice of architectures :)

PS: I'm currently writing https://etherpad.wikimedia.org/p/debian-mirror --
  let me know if it's helpful or is missing anything.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#918455: [L10N,DE] tzdata: updated german debconf translation

[Holger Wansing]

Package: tzdata
Severity: wishlist
Tags: patch,l10n


Hi,
attached is the updated german debconf translation for tzdata, version 2018i.
Please include it in your package.

Thanks for your i18n efforts.


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076


tzdata_2018i-1_de.po.gz
Description: application/gzip

Bug#918456: nodejs: Buffer deprecation warning to stderr makes many tests fail

[Jérémy Lal]

Package: nodejs
Version: 10.15.0~dfsg-6
Severity: serious


Nodejs 10.15 prints a deprecation warning to stderr when
deprecated Buffer() call is made. (Correct way is now to
use e.g. Buffer.from()).

This makes many packages tests fail because autopkgtest fails
when something is printed to stderr.

It's a false positive, it should be fixed in all those packages,
however to allow quicker migration of nodejs 10 to testing,
i'm going to temporarily silence that warning.

Someone using NODE_PENDING_DEPRECATION=1 or --pending-deprecation flag
will still see it.

Jérémy

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

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

Versions of packages nodejs depends on:
ii  libc-ares2 1.14.0-1
ii  libc6  2.28-4
ii  libgcc11:8.2.0-13
ii  libicu63   63.1-5
ii  libnghttp2-14  1.35.1-1
ii  libnode64  10.15.0~dfsg-6
ii  libssl1.1  1.1.1a-1
ii  libstdc++6 8.2.0-13
ii  libuv1 1.24.0-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages nodejs recommends:
ii  ca-certificates  20180409
ii  nodejs-doc   10.15.0~dfsg-6

nodejs suggests no packages.

-- no debconf information

Bug#878340: libmariadbclient-dev-compat: mysqlclient.pc is not visible to pkg-config

[Helmut Grohne]

Control: tags -1 + patch

On Fri, Oct 13, 2017 at 01:47:19AM +0300, Nikolay Dimitrov wrote:
> Can you please double-check whether mysqlclient.pc is installed at the proper 
> path?

It isn't. Please use the attached patch.

Helmut
diff --minimal -Nru mariadb-10.1-10.1.37/debian/changelog 
mariadb-10.1-10.1.37/debian/changelog
--- mariadb-10.1-10.1.37/debian/changelog   2018-12-08 17:50:43.0 
+0100
+++ mariadb-10.1-10.1.37/debian/changelog   2019-01-06 11:03:04.0 
+0100
@@ -1,3 +1,10 @@
+mariadb-10.1 (1:10.1.37-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix path of mysqlclient.pc. (Closes: #878340)
+
+ -- Helmut Grohne   Sun, 06 Jan 2019 11:03:04 +0100
+
 mariadb-10.1 (1:10.1.37-3) unstable; urgency=low
 
   [ Otto Kekäläinen ]
diff --minimal -Nru 
mariadb-10.1-10.1.37/debian/libmariadbclient-dev-compat.links 
mariadb-10.1-10.1.37/debian/libmariadbclient-dev-compat.links
--- mariadb-10.1-10.1.37/debian/libmariadbclient-dev-compat.links   
2018-11-29 16:34:32.0 +0100
+++ mariadb-10.1-10.1.37/debian/libmariadbclient-dev-compat.links   
2019-01-06 11:02:47.0 +0100
@@ -1,4 +1,4 @@
 #!/usr/bin/dh-exec
 usr/lib/${DEB_HOST_MULTIARCH}/libmariadbclient.so 
usr/lib/${DEB_HOST_MULTIARCH}/libmysqlclient.so
 usr/lib/${DEB_HOST_MULTIARCH}/libmariadbclient_r.so 
usr/lib/${DEB_HOST_MULTIARCH}/libmysqlclient_r.so
-usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/mariadb.pc 
usr/lib/${DEB_HOST_MULTIARCH}/mysqlclient.pc
+usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/mariadb.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/mysqlclient.pc

Bug#918357: mirror listing update for mirror.unesp.br

[Peter Palfrader]

Control: retitle -1 mirror.unesp.br: upstream-name
Control: tag -1 +moreinfo

On Sat, 05 Jan 2019, Erley Barbosa da Silva / Valdir Barbosa wrote:

> Site: mirror.unesp.br
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Archive-rsync: debian/
> Maintainer: Erley Barbosa da Silva / Valdir Barbosa 
> Country: BR Brazil
> Location: Sao Paulo
> Sponsor: Universidade Estadual Paulista (UNESP) https://www.unesp.br
> Comment: Mirror at the university.

Hi!

o According to
  http://mirror.unesp.br/debian/project/trace/mirror.unesp.br
  you use ftp.br.debian.org as an upstream mirror.

  Please, do not use ftp.*.debian.org.  First, ftp.*.debian.org services
  only guarantee that http is available on /debian, no guarantee for
  rsync access exists.  Even if an ftp.CC.debian.org supports rsync now,
  there is no guarantee that it will in the future.  Second,
  ftp.CC.debian.org might be a round robin of different sites, so you
  would not always pull from the same upstream.

  Better pick an individual name, such as debian.c3sl.ufpr.br which
  currently is ftp.br.debian.org.

o Your mirror seems to not have updated for almost a day.  Are you sure
  you are running ftpsync four times a day?
  Or, once you correct your upstream name, you could also try running
  ftpsync-cron every hour or two instead.  It will check the upstream
  trace file http://debian.c3sl.ufpr.br/debian/project/trace/debian.c3sl.ufpr.br
  to see if an update is required and run ftpsync if so.

Cheers,

PS: I'm currently writing https://etherpad.wikimedia.org/p/debian-mirror --
  let me know if it's helpful or is missing anything.

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#854627: sudo with graphical apps doesn't work on wayland

[Frank lin Piat]

Hello

For reference, this bug is known upstream as 
https://bugzilla.redhat.com/show_bug.cgi?id=1274451


Regarding Gparted, a workaround has been implemented in Upstream 0.30.0
[UPPATCH] [UPNEWS].
(Some people complained about that workaround, see Debian bug #883812,
but it's works)
Note: for people using version <0.30.0, a workaround is to logout the
sessions and open a session using X11 instead of Wayland !



[UPPATCH]  https://gitlab.gnome.org/GNOME/gparted/commit/f38ccd02
[UPNEWS] https://gparted.org/news.php?item=214

Bug#916891: closed by Peter Palfrader (reply to Debian Mirror Team ) (Re: Bug#916891: mirror submission for debian.mirrors.theom.nz)

[Theo Morra]

Sorry about the delay, I’ve been just slightly busy over the Christmas period. 
Then it was off to Christchurch for my birthday yesterday. Anyway.

The mirror should be up, that being https://debian.mirrors.theom.nz 


The issue I’m facing at the moment while everyone slowly returns to work is 
that the mirror service has 2 mirrors in the cluster that are public facing (so 
far). Both service debian.mirrors.theom.nz  
but both will also return two different traces since they’re not perfectly in 
sync yet (such are the issues when running mirrors within ISPs).

Other than the traces being different both mirrors should have the same content 
as each other.

The TTL is also deliberately set low so if a mirror goes down the most downtime 
we face is 2 minutes.

As to the issue where multiple IPs are returned for different locations, that 
is unfortunately by design. We run GeoDNS that pushes users to the closest 
node, either in Christchurch (run by Snap! Internet but clustered in to 
debian.mirrors.theom.nz ), or the one in 
Auckland (run by myself and clustered in). In the coming weeks we’re looking at 
bringing up a node in Wellington as well to provide extra redundancy should we 
need it.

Any questions feel free to ask

> On 6/01/2019, at 11:12 PM, Debian Bug Tracking System  
> wrote:
> 



signature.asc
Description: Message signed with OpenPGP

Bug#776450: Xen PVH support for grub-xen in Buster

[Colin Watson]

On Sat, Jan 05, 2019 at 10:51:13PM +0100, Hans van Kranenburg wrote:
> On 1/5/19 8:04 PM, Colin Watson wrote:
> > I think I'm OK with cherry-picking the relevant patch stack.  Presumably
> > this would need to be in new grub-xen-pvh-bin / grub-xen-pvh binary
> > packages, as is usual for separate platform builds?
> 
> I was thinking about having an additional...
> 
> /usr/lib/grub-xen/grub-i386-xen_pvh.bin
> 
> ...in the grub-xen-host package, built with the same config file
> (debian/grub-xen-host_grub.cfg in the packaging) and then...
> 
> /usr/lib/grub/i386-xen_pvh/*.mod
> 
> ...in grub-xen-bin, just as an additional third option besides i386-xen
> and x86_64-xen? This would be the most convenient "upgrade path". If you
> want to switch to PVH, just change kernel line in the xen guest config
> file, and set type='pvh'.

Ah yes, I'd forgotten that i386-xen and x86_64-xen were both in
grub-xen-bin.  I agree it seems reasonable enough to combine them, which
simplifies things, and given that the boot loader (at least the first
stage - see below) is read from the dom0 filesystem, it makes sense to
include an image in grub-xen-host, although we may or may not be able to
use the exact same config file.

> > Can you elaborate on what you mean by "use as kernel image for the Xen
> > PVH virtual machine"?  In other words, what does the process of
> > installing a boot loader in a PVH guest look like?
> 
> You don't. There is no BIOS, no boot loader, it is like booting a PV
> guest with grub. The whole 'trick' about PVH is that it's HVM, but then
> without the qemu etc part.
> 
> https://wiki.xen.org/wiki/Virtualization_Spectrum#Almost_fully_PV:_PVH_mode
> 
> So, if I have this grub.cfg... (as example, not what we want for the
> package)
[...]

Thanks for clarifying all that.

> So this is what I'm used to [0], but the way in which the Debian
> grub-xen packages work is a bit different of course, since it tries to
> do most of the process inside the virtual machine, and has a very
> generic config file that delegates as much as possible to additional
> grub config with access to modules inside the virtual machine itself.
[...]
> > (Compare
> > https://salsa.debian.org/grub-team/grub/blob/master/debian/patches/grub-install-pvxen-paths.patch
> > which we carry for PV guests, although I gather PVH is sufficiently
> > different that the same approach probably doesn't work.)
> 
> Hm, I have never seen this /boot/xen/pvboot-*.elf stuff before, and I
> also don't see any of those files in the grub-xen-* packages?

Anything in /boot is copied/generated by grub-install rather than being
shipped in the packages themselves.

Let me give some background here.  The Xen PV boot protocol was the
result of a series of discussions between me, Ian Jackson (Xen), Ian
Campbell (Xen), Vladimir Serbinenko (GRUB), and possibly a few others
I've forgotten, and I don't recall to what extent we ever wrote down the
entire rationale in one place.  In fact
https://wiki.xen.org/wiki/PvGrub2 seems to have most of it now that I
look, but I'll try to summarise it all here.

Historically (before GRUB 2.02), there were two main choices for booting
a PV guest using GRUB:

 * Use pygrub.  This was very flexible, because it parsed boot loader
   configuration files from the guest's filesystem and decided what
   kernel and initramfs to boot based on that.  However, getting the
   configuration file parsing right was a difficult and moving target,
   and this system was inherently somewhat insecure because it required
   complex parsing of untrusted guest inputs in the dom0.

 * Use the PV port of GRUB Legacy (pvgrub).  This generally worked well
   and fixed the inherent security problems of pygrub because all the
   parsing work was done in the guest context, but it was a very old
   fork of unmaintained code and expected the GRUB Legacy configuration
   file syntax.  Guests running on a host using this generally had to
   carry around otherwise-obsolete code to generate appropriate menu.lst
   files so that they could declare how they expected to be booted.

Of course it was also possible to use pvgrub with the sort of scheme you
describe, where the host declares how the guest kernel should boot.
This works well enough in a small environment where there's a
substantial amount of cooperation between the people running the host
and the people running the guests, or where all the guests are
sufficiently similar.  But it's not great for a larger or more generic
environment, and we didn't want to rely on that degree of cooperation.
(However, if you're operating a Xen host and that approach works for
you, by all means go for it!  I understand that there exist environments
where that approach is more convenient.)

So, around the time Vladimir was doing the core PV porting work for GRUB
2, we were working on a better design for this.  The first pass was just
to provide the host with a pvgrub2 image which it would boot in the
guest context, configure

Bug#918382: trying to overwrite '/usr/lib/x86_64-linux-gnu/libIlmImf-2_3.so.24.0.0', which is also in package libopenexr23:amd64 2.3.0-3

[Mathieu Malaterre]

Control: tags -1 wontfix

Hi,

Thanks for the bug report.

On Sat, Jan 5, 2019 at 6:21 PM 積丹尼 Dan Jacobson  wrote:
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/libIlmImf-2_3.so.24.0.0', 
> which is also in package libopenexr23:amd64 2.3.0-3

Yeah that's correct. However please consider 2.3.0-3 a broken upload.
Sorry about that, you'll need to purge it first.

Sorry about that.

Bug#878340: [debian-mysql] Bug#878340: libmariadbclient-dev-compat: mysqlclient.pc is not visible to pkg-config

[Otto Kekäläinen]

Hello Helmut!

su 6. tammik. 2019 klo 12.09 Helmut Grohne (hel...@subdivi.de) kirjoitti:
>
> Control: tags -1 + patch
>
> On Fri, Oct 13, 2017 at 01:47:19AM +0300, Nikolay Dimitrov wrote:
> > Can you please double-check whether mysqlclient.pc is installed at the 
> > proper path?
>
> It isn't. Please use the attached patch.

Thanks for the patch!

Currenlty in Debian unstable we have mariadb-10.3. Would you be kind
and rebase, test and submit your patch on mariadb-10.3?
Preferred way to get patches if as Salsa merge requests. See easy
instructions at https://wiki.debian.org/Teams/MySQL/patches

Bug#776450: Xen PVH support for grub-xen in Buster

[Colin Watson]

On Sun, Jan 06, 2019 at 01:45:53AM +0100, Hans van Kranenburg wrote:
> Hm, so I have a PV (or PVH) domU in a test environment here, and I tried
> to use it in the Debian way of booting it.
> 
> If I install grub-xen-bin inside the domU then I get some stuff, but not
> update-grub. When I just also install grub2 it drags in more stuff, and
> then I end up with update-grub and a /boot/grub/grub.cfg file as result.

For the record, you wanted grub-xen rather than grub-xen-bin.

> I just copied *.mod that I got from my grub build (with the make blah
> shown before) into /usr/lib/grub/i386-xen_pvh of the domU,

I'd expect them to need to be in /boot/grub/i386-xen_pvh/ in order for
the boot loader to read them; grub-install copies modules there.
(However, a standalone image normally shouldn't need to read modules
from the guest anyway.)

> When trying to start that, I get:
> 
> Reading (memdisk)/boot/grub/grub.cfg
> 
> and then it exits back to the dom0 prompt and the domU is gone.

Seeing (memdisk) there suggests that $root is wrong.  I think that
putting your bootstrap configuration file in /boot/grub/grub.cfg in the
memdisk is a recipe for confusion; grub-xen-host puts it in /grub.cfg
instead, and generally hooks things up a bit differently.  You can
inspect debian/rules to see what it does.

Anyway, this sounds close enough that we can probably go for it and see
where it lands :-)

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

Bug#918457: xserver-xephyr: multi-screen setup with xinerama and RANDR extensions: extra screens not directly usable

[Ondřej Grover]

Package: xserver-xephyr
Version: 2:1.19.2-1+deb9u5
Severity: normal

Dear Maintainer,

I'm trying to use Xephyr to test my awesome (WM) multi-screen setup.
As per instructions found on the Internet I spawned a Xephyr server with 2 
screens and the Xinerama and RANDR extensions activated:

Xephyr -screen 960x540+0+0 -screen 960x540+960+0  +extension RANDR  +xinerama 
:1 &

This spawns 2 windows side-by-side (due to the +X+Y panning information, but 
also works without it and has the same issue), labeled :1.0 and :1.1
However, when I ask xrandr about the screens, it sees only one screen/output

DISPLAY=:1 xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 160 x 160, current 1920 x 540, maximum 1600 x 1200
default connected 960x540+0+0 (normal left inverted right x axis y axis) 0mm x 
0mm
   1600x1200  0.00  
   1400x1050  0.00  
   1280x960   0.00  
   1280x1024  0.00  
   1152x864   0.00  
   1024x768   0.00  
   832x6240.00  
   800x6000.00  
   720x4000.00  
   480x6400.00  
   640x4800.00  
   640x4000.00  
   320x2400.00  
   240x3200.00  
   160x1600.00  
   960x5400.00*

So when I start awesome (WM) on this display, it detects only the first 
screen/output

DISPLAY=:1 awesome &

Now if I attempt to start an xterm on the first screen, it works correctly

DISPLAY=:1.0 xterm &

I can even move this terminal toward the right screen and it becomes visible on 
the second (:1.1) screen, so perhaps Xinerama is working.

However, If I attempt to start an xterm on the second screen directly, it fails 
(even without awesome)

DISPLAY=:1.1 xterm &
xterm: Xt error: Can't open display: :1.1

My feeling so far is that the second (possibly any extra) display is not 
properly advertised or registered. Perhaps the RANDR extension is not working 
properly?
Xephyr doesn't seem to output anything, I wasn't able to find any option that 
would make it more verbose.


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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
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: systemd (via /run/systemd/system)

Versions of packages xserver-xephyr depends on:
ii  libaudit1 1:2.6.7-2
ii  libbsd0   0.8.3-1
ii  libc6 2.24-11+deb9u3
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdrm2   2.4.74-1
ii  libepoxy0 1.3.1-2
ii  libgcrypt20   1.7.6-2+deb9u3
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libpixman-1-0 0.34.0-1
ii  libselinux1   2.6-3+b3
ii  libsystemd0   232-25+deb9u6
ii  libudev1  232-25+deb9u6
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libx11-xcb1   2:1.6.4-3+deb9u1
ii  libxau6   1:1.0.8-1
ii  libxcb-glx0   1.12-1
ii  libxcb-icccm4 0.4.1-1
ii  libxcb-image0 0.4.0-1+b2
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.12-1
ii  libxcb-render-util0   0.3.9-1
ii  libxcb-render01.12-1
ii  libxcb-shape0 1.12-1
ii  libxcb-shm0   1.12-1
ii  libxcb-util0  0.3.8-3+b2
ii  libxcb-xf86dri0   1.12-1
ii  libxcb-xkb1   1.12-1
ii  libxcb-xv01.12-1
ii  libxcb1   1.12-1
ii  libxdmcp6 1:1.1.2-3
ii  libxfont2 1:2.0.1-3+deb9u1
ii  libxshmfence1 1.2-1+b2
ii  xserver-common2:1.19.2-1+deb9u5

Versions of packages xserver-xephyr recommends:
ii  libgl1-mesa-dri  13.0.6-1+b2

xserver-xephyr suggests no packages.

-- no debconf information

Bug#916890: problem still present in open-mpi 3.1.3-7 ?

[Bruno Torremans]

hello,
possible that the problem is still present ?
Bruno Torremans

root@bruno-pc:/home/bruno# apt --fix-broken install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer
required:
  famfamfam-silk kicad-common libalglib3.11 libargon2-0 libarmadillo8
libbind9-160 libboost-atomic1.62.0 libboost-chrono1.62.0
libboost-context1.62.0
  libboost-date-time1.62.0 libboost-locale1.62.0
libboost-program-options1.62.0 libboost-signals1.62.0 libcdio17 libcfitsio5
libclang1-6.0 libdns-export1100
  libdns-export1102 libdns-export169 libdns1102 libdns169 libgdbm5
libgeos-3.6.2 libgeos-3.7.0 libgit2-26 libgltf-0.1-1 libgraphblas1
libhttp-parser2.7.1
  libhypre-2.14.0 libipt1 libirs160 libisc-export166 libisc-export169
libisc166 libisc169 libisccc160 libisccfg160 libiso9660-10
libkf5akonadiprivate5abi1
  libkf5calendarcore5abi1 libkf5mimetreeparser5 liblept5 liblivemedia61
liblivemedia62 libllvm5.0 libllvm6.0 liblwres160 libmagickcore-6.q16-5
  libmagickcore-6.q16-5-extra libmagickwand-6.q16-5 libmbedcrypto1
libnftnl7 libokular5core7 libopencv-calib3d3.2 libopencv-contrib3.2
libopencv-features2d3.2
  libopencv-flann3.2 libopencv-photo3.2 libopencv-shape3.2
libopencv-stitching3.2 libopencv-superres3.2 libopencv-video3.2
libopencv-videostab3.2 libopencv-viz3.2
  libopengl0 libopenmpi2 liborcus-0.12-0 liborcus-0.13-0 libperl5.26
libplacebo2 libplacebo3 libplacebo4 libplacebo5 libpoppler73 libpoppler74
libproj12
  libprotobuf-lite10 libpyside1.2 libpython3.6 libpython3.6-minimal
libpython3.6-stdlib libqpdf18 libraw16 libshiboken1.2v5 libsuperlu-dist5
libtesseract4 libtidy5.6
  libtinyxml2-5 libunbound2 libvtk7.1 libx265-146 libx265-151 libx86emu1
linux-headers-4.16.9-towo.1-siduction-amd64
linux-headers-4.18.15-towo.2-siduction-amd64
  linux-headers-4.19.0-towo.2-siduction-amd64
linux-headers-4.19.2-towo.1-siduction-amd64
linux-headers-4.19.6-towo.3-siduction-amd64
  linux-image-4.16.9-towo.1-siduction-amd64
linux-image-4.18.15-towo.2-siduction-amd64
linux-image-4.19.0-towo.2-siduction-amd64
  linux-image-4.19.2-towo.1-siduction-amd64
linux-image-4.19.6-towo.3-siduction-amd64 open-coarrays-bin
perl-modules-5.26 python-pyside.qtcore python-pyside.qtgui
  python-pyside.qtsvg python-pyside.qtuitools python-pyside.qtxml
python3-pyqt5.qtmultimedia python3-pyqt5.qtopengl python3-pyqt5.qtsvg
python3-pyqt5.qtwebkit
  python3-qtpy python3.6 python3.6-minimal qml-module-org-kde-kirigami
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  libopenmpi3 openmpi-common
The following packages will be upgraded:
  libopenmpi3 openmpi-common
2 upgraded, 0 newly installed, 0 to remove and 498 not upgraded.
9 not fully installed or removed.
Need to get 0 B/2,338 kB of archives.
After this operation, 16.4 kB disk space will be freed.
Do you want to continue? [Y/n]
Reading changelogs... Done
(Reading database ... 422078 files and directories currently installed.)
Preparing to unpack .../libopenmpi3_3.1.3-7_amd64.deb ...
Unpacking libopenmpi3:amd64 (3.1.3-7) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such
file or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old libopenmpi3:amd64 package post-removal script subprocess
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive
/var/cache/apt/archives/libopenmpi3_3.1.3-7_amd64.deb (--unpack):
 there is no script in the new version of the package - giving up
Preparing to unpack .../openmpi-common_3.1.3-7_all.deb ...
Unpacking openmpi-common (3.1.3-7) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such
file or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old openmpi-common package post-removal script subprocess
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive
/var/cache/apt/archives/openmpi-common_3.1.3-7_all.deb (--unpack):
 there is no script in the new version of the package - giving up
Errors were encountered while processing:
 /var/cache/apt/archives/libopenmpi3_3.1.3-7_amd64.deb
 /var/cache/apt/archives/openmpi-common_3.1.3-7_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#918458: ambdec FTCBFS: uses the wrong pkg-config

[Helmut Grohne]

Source: ambdec
Version: 0.7.1-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ambdec fails to cross build from source, because it uses the build
architecture pkg-config as hard coded by debian/rules. It's nice to see
that pkg-config is already substitutable. Unfortunately, the variable
used is not commonly used. Thus dh_auto_build does not substitute it.
The attached patch changes it to use the standard variable PKG_CONFIG
and thus makes ambdec cross buildable. Please consider applying it.
Alternatively, I recommend seeding the variable from PKG_CONFIG as set
by /usr/share/dpkg/buildtools.mk.

Helmut
diff --minimal -Nru ambdec-0.7.1/debian/changelog ambdec-0.7.1/debian/changelog
--- ambdec-0.7.1/debian/changelog   2019-01-05 21:33:13.0 +0100
+++ ambdec-0.7.1/debian/changelog   2019-01-06 11:24:12.0 +0100
@@ -1,3 +1,11 @@
+ambdec (0.7.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use standard variable PKG_CONFIG to make cross building work. (Closes:
+#-1)
+
+ -- Helmut Grohne   Sun, 06 Jan 2019 11:24:12 +0100
+
 ambdec (0.7.1-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru 
ambdec-0.7.1/debian/patches/0002-Use-pkg-config-where-possible.patch 
ambdec-0.7.1/debian/patches/0002-Use-pkg-config-where-possible.patch
--- ambdec-0.7.1/debian/patches/0002-Use-pkg-config-where-possible.patch
2019-01-05 21:27:12.0 +0100
+++ ambdec-0.7.1/debian/patches/0002-Use-pkg-config-where-possible.patch
2019-01-06 11:24:10.0 +0100
@@ -6,26 +6,26 @@
  source/Makefile | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/source/Makefile b/source/Makefile
 index a2de6a7..9f09fae 100644
 --- a/source/Makefile
 +++ b/source/Makefile
 @@ -22,6 +22,7 @@
  PREFIX ?= /usr/local
  BINDIR ?= $(PREFIX)/bin
  SHARED ?= $(PREFIX)/share/ambdec
-+PKGCONF ?= pkgconf
++PKG_CONFIG ?= pkg-config
  
  VERSION = 0.7.1
  CPPFLAGS += -MMD -MP -DVERSION=\"$(VERSION)\" -DSHARED=\"$(SHARED)\"
 @@ -35,8 +36,8 @@ all: ambdec ambdec_cli
  AMBDEC_O = ambdec.o styles.o mainwin.o confwin.o radbut.o filewin.o \
 jclient.o nffilt.o xover2.o decoder.o adconf.o sstring.o \
 png2img.o meter.o
 -ambdec:   CPPFLAGS += $(shell pkgconf --cflags freetype2)
 -ambdec:   LDLIBS += -lclxclient -lclthreads -ljack -lpng -lpthread -lXft 
-lX11 -lrt
-+ambdec:   CPPFLAGS += $(shell $(PKGCONF) --cflags xft libpng x11)
-+ambdec:   LDLIBS += -lclxclient -lclthreads -ljack -lpthread $(shell 
$(PKGCONF) --libs xft libpng x11) -lrt
++ambdec:   CPPFLAGS += $(shell $(PKG_CONFIG) --cflags xft libpng x11)
++ambdec:   LDLIBS += -lclxclient -lclthreads -ljack -lpthread $(shell 
$(PKG_CONFIG) --libs xft libpng x11) -lrt
  ambdec:   $(AMBDEC_O)
$(CXX) $(LDFLAGS) -o $@ $(AMBDEC_O) $(LDLIBS)
  $(AMBDEC_O):
diff --minimal -Nru ambdec-0.7.1/debian/rules ambdec-0.7.1/debian/rules
--- ambdec-0.7.1/debian/rules   2019-01-05 21:30:39.0 +0100
+++ ambdec-0.7.1/debian/rules   2019-01-06 11:23:52.0 +0100
@@ -2,8 +2,6 @@
 
 export LDLIBS += -Wl,--as-needed
 export PREFIX = /usr
-export PKGCONF = pkg-config
-
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:

Bug#918460: dvtm: do not install auxiliary programs in PATH

[Dmitry Bogatov]

Package: dvtm
Version: 0.15+40.g311a8c0-1
Severity: normal
Tags: upstream

Dear Maintainer,

please do not install `dvtm-editor' and `dvtm-pager' into PATH.  These
programs are never used on their own, and, while they have
own manual pages, they belong to /usr/libexec.

Before doing it, dvtm(1) must be adjusted to incorporate
content of dvtm-pager(1) and dvtm-editor(1).


pgpzWCqrxtYKv.pgp
Description: PGP signature

Bug#918459: lintian: add `brightness' into data/systemd/init-whitelist

[Dmitry Bogatov]

Package: lintian
Version: 2.5.118
Severity: wishlist

Dear Maintainer,

please add `brightness' into data/systemd/init-whitelist file. This is
new init script, provided by bin:initscripts since version 2.93-3 (see
#746221).


pgpjfyQvAWfQi.pgp
Description: PGP signature

Bug#916122: pbuilder: misleading warning about missing cgroups

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 10 Dec 2018 12:22:09 +0100 Reiner Herrmann  wrote:
> Source: pbuilder
> Version: 0.230.1
> Severity: minor
> 
> Dear maintainer,
> 
> I noticed that pbuilder prints a warning at the beginning of each build
> that cgroups are not available:
> 
> > W: cgroups are not available on the host, not using them.
> 
> But they actually are available on my system:
> 
> # grep cgroup /proc/mounts
> cgroup /sys/fs/cgroup cgroup
rw,relatime,cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,perf_event
,net_prio,pids 0 0
> 
> pbuilder assumes that cgroup support is only available on systems with
systemd.
> But they can also be used with some basic file system operations in the
cgroup
> mount point.
> 
> Please change the warning message to something like:
> "W: cgroup support is currenly only implemented for hosts running systemd"
> 
> (Or instead add cgroup support independent of systemd (and change
> severity to wishlist) ;) )

Also, I also have the message while I *am* using systemd as init system.

Regards.
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlwx3KcACgkQ3rYcyPpX
RFv5AggAzy7e0sAhQDiw7RH07HxJNPvA9btl5aQPE2klt/t77n367jMRgwHa2dfS
5MDlSqA+MKc9Ahfk+qUopxEDlGLv5XTabgKtcXXgMAWxkCBeDIjSd34c0wJPcYWu
EYKjvDczLx4hzfi3U5wPy28wcZEyLdUeYkShvrUtb55ZIEgdIqSubGpxFzhnACG+
gjuDwgpOCHDFH7+pl7UHFIzRG2tnli9EMZUCmMCz+UgDOuhaX65EgQD3wztJSswC
xl1GlDceTcbCR6K2qJrJUo9jJ7rUHpDgvpvdUV5i2ZeGMFxDutH895rSzb3X/1DT
TErSSjvFnneEcYa/dXDSkZ9oppwFvw==
=WpOg
-END PGP SIGNATURE-

Bug#878340: [debian-mysql] Bug#878340: libmariadbclient-dev-compat: mysqlclient.pc is not visible to pkg-config

[Helmut Grohne]

Hi Otto,

On Sun, Jan 06, 2019 at 12:19:50PM +0200, Otto Kekäläinen wrote:
> Currenlty in Debian unstable we have mariadb-10.3. Would you be kind
> and rebase, test and submit your patch on mariadb-10.3?

If "apt-get source libmariadbclient-dev-compat" yields a non-default
version in unstable, then you have cruft in unstable. Would you be kind
and clean up that cruft to make standard workflows work?

> Preferred way to get patches if as Salsa merge requests. See easy
> instructions at https://wiki.debian.org/Teams/MySQL/patches

The preferred way to interact with contributors is the bug tracking
system. See easy instruction at
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-handling
for how to use that interface.

In particular, please don't let important bugs linger for extended
periods of time without any response. Much less ones that are as trivial
to fix as this one is.

Helmut

Bug#918461: qpdfview: consider packaging qpdfview 0.4.18-beta for Buster

[Muntasim-Ul-Haque]

Package: qpdfview
Version: 0.4.14-1+b1
Severity: wishlist

Dear Maintainer,

qpdfview 0.4.18-beta is out for a while now. Please consider packaging it
before Buster's transition freeze on 2019-01-12.

Thanks.



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qpdfview depends on:
ii  hicolor-icon-theme    0.15-1
ii  libc6 2.24-11+deb9u3
ii  libcups2  2.2.1-8+deb9u2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libpoppler-qt5-1  0.48.0-2+deb9u2
ii  libqt5concurrent5 5.7.1+dfsg-3+b1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui5    5.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5sql5    5.7.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.7.1+dfsg-3+b1
ii  libqt5svg5    5.7.1~20161021-2+b2
ii  libqt5widgets5    5.7.1+dfsg-3+b1
ii  libqt5xml5    5.7.1+dfsg-3+b1
ii  libstdc++6    6.3.0-18+deb9u1
ii  zlib1g    1:1.2.8.dfsg-5

Versions of packages qpdfview recommends:
ii  qpdfview-djvu-plugin   0.4.14-1+b1
ii  qpdfview-ps-plugin 0.4.14-1+b1
pn  qpdfview-translations  

qpdfview suggests no packages.

-- no debconf information

Bug#918462: Error in `/usr/share/doc-base/icewm-faq', line 10: all `Format' sections are invalid.

[積丹尼 Dan Jacobson]

Package: icewm-common
Version: 1.4.3.0~pre-20181030-2
File: /usr/share/doc-base/icewm-faq

# aptitude purge ~o
The following packages will be REMOVED:
  librarian0{pu} (D: rarian-compat)  rarian-compat{p}
Removing rarian-compat (0.8.1-6+b1) ...
Removing librarian0 (0.8.1-6+b1) ...
Processing triggers for sgml-base (1.29) ...
Processing triggers for libc-bin (2.28-4) ...
Processing triggers for doc-base (0.10.8) ...
Scrollkeeper was removed, forcing re-registration of all documents.
Unregistering 278 doc-base files, re-registering 279 doc-base files...
Error in `/usr/share/doc-base/icewm-faq', line 10: all `Format' sections are 
invalid.
Note: `install-docs --verbose --check file_name' may give more details about 
the above error.
Unregistering documents from scrollkeeper...
(Reading database ... 148014 files and directories currently installed.)
Purging configuration files for rarian-compat (0.8.1-6+b1) ...

Bug#918463: Sound volume jumps to maximum volume when new video starts

[scrap]

Package: pavucontrol-qt
Version: 0.2.0-1

I am running Debian 9 Stable (Jessie) with LXQt.

When I adjust the desired volume with Pavucontrol-Qt and a new track 
starts (e.g. on YouTube), the volume slider always jumps back to maximum 
volume what is a bit annoying.


Could you have a look if there is some bug related for this behavior?

The situation appears when:

- starting new tracks on YouTube (browser runs in QEMU-VM)
- continuing current tracks on YouTube after loading
- several other videos played via browser

I am confused what could cause this.

Thanks a lot for your help!

With best regards!
Daniel

Bug#918316: nocache: FTBFS in sid

[Sven Joachim]

Control: clone -1 -2
Control: retitle -2 nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' 
failed.
Control: severity -2 normal

On 2019-01-05 08:54 +0100, Sven Joachim wrote:

> I get a different error here:
>
> ,
> | ## #916415
> | timeout 11 ./nocache apt show coreutils 1>>/dev/null
> | apt: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
> | Aborted
> | make[1]: *** [debian/rules:21: override_dh_auto_test] Error 134
> `

That is unrelated to Santiago's problem, and I should have reported it
separately.  Creating a new clone now, will followup when I have the
cloned bug's number.

Cheers,
   Sven

Bug#918382: broken upload

[積丹尼 Dan Jacobson]

As you can see in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918382
gimp is relying (Depending) on a broken upload.

Perhaps you could make it Depend on libopenexr24 instead of libopenexr23.

Bug#857490: dgit: shouldn't fail when previous backport not mentioned in changelog

[Sean Whitton]

control: tag -1 -moreinfo

Hello,

On Sat 05 Jan 2019 at 07:14pm GMT, Ian Jackson wrote:

> Stepping back a bit: with a rebasing workflow such as you describe,
> dgit's sanity check strategy for overwriting-pseudomerges (which are
> basically like force pushes) cannot work.
>
> I am not sure if there is a better sanity check strategy that could
> work.  It seems difficult.  If the user is in this situation their
> branch is not ff from the suite branch *and* their changelog doesn't
> mention the previous upload.
>
> It is difficult to see how to distinguish this from the case where
> someone (for example) simply prepares a fresh backport of a package
> without regard to any previous work.  And of course doing such a fresh
> backport without looking at the previous work risks introducing a
> regression, if a naive backport would introduce a bug which is in fact
> fixed, right now, by extra change(s) in the current backport.
>
> So I think the right answer is perhaps indeed to require that the user
> says
>   --overwrite=2.13.0-1.1~bpo8+1
> or whatever, so forcing them to at least prove that they knew there
> was a previous backport.
>
>
> Does that make some kind of sense ?  How can we better guide the user
> who finds themselves in this situation ?

Suggesting that the user use --overwrite=2.13.0-1.1~bpo8+1, or `git
merge -s ours dgit/dgit/stretch-backports`, is indeed what we should do.

I think that official backports is the only case where this is likely to
come up often.  So I suggest that we start a dgit-maint-bpo(7) with tips
and techniques for maintaining official backports (also see #898494).
In that page we can say that if you are using what in this bug I've
called a rebase workflow, you will need to use --overwrite=X.Y.Z for
each upload.

(Calling it dgit-maint-bpo(7) rather than dgit-maint-backport(s)(7) is
meant to make explicit reference to backports.debian.org.)

I also think that dgit could emit a recommendation to look at that
manpage in the kind of case that prompted me to file this bug.  It can
just look for ~bpoNN in the version number that is missing from
d/changelog, and output a hint.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#918138: qtox: Add AppArmor profile

[Yangfl]

intrigeri  于2019年1月5日周六 下午8:45写道：
>
> Hi,
>
> Vincas Dargis:
> > intrigeri  what's your take on this? Where should new profiles be
> > "placed"?
>
> Having the policy live along with the software it confines, i.e.
> in the upstream VCS, is ideal, as long as upstream somewhat cares
> about it and the maintainer of said policy tracks upstream changes
> and updates policy before releases.
>
> If that's not possible, shipping the policy with the Debian package
> that ships the software is great.
>
> Maintaining policy elsewhere (e.g. apparmor-profiles-extra) creates
> all kinds of busywork, policy is bound to be outdated from time to
> time, and it's not sustainable on the long run. I see it as
> a temporary stop-gap and not a good long term solution.
>
> In any case, it's good to have experienced eyes review the policy :)
>
> > P.S. I know you don't want new profiles for Buster, and I am not
> > really targeting Buster (especially due to GUI-application-confining
> > issues), let's see this as (yet another) long-term personal
> > project :)
>
> :)
>
> Cheers,
> --
> intrigeri

OK. Once you're done, just reply to this bug with profile attached.
I'll take care of it in the next release.

Bug#918465: sunxi-tools installation fils without udev installed

[Adrian Bunk]

Package: sunxi-tools
Version: 1.4.2+git20181114.6d598a-2
Severity: serious

https://piuparts.debian.org/sid/fail/sunxi-tools_1.4.2+git20181114.6d598a-2.log

...
  Preparing to unpack .../sunxi-tools_1.4.2+git20181114.6d598a-2_amd64.deb ...
  Unpacking sunxi-tools (1.4.2+git20181114.6d598a-2) ...
  Setting up sunxi-tools (1.4.2+git20181114.6d598a-2) ...
  /var/lib/dpkg/info/sunxi-tools.postinst: 9: 
/var/lib/dpkg/info/sunxi-tools.postinst: udevadm: not found
  dpkg: error processing package sunxi-tools (--configure):
   installed sunxi-tools package post-installation script subprocess returned 
error exit status 127
  Errors were encountered while processing:
   sunxi-tools
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#918372: unblock: med-fichier/4.0.0+repack-6

[Paul Gevers]

Hi Gilles,

On Sat, 05 Jan 2019 17:04:05 +0100 Gilles Filippini  wrote:
> Please unblock package med-fichier. Is has currently to wait for 43 days
> because of an autopkgtest regression against the version of gmsh in testing
> (3.0.6+dfsg1-4) [1]. But it succeeds against version 3.0.6+dfsg1-4.1 in
> unstable [1] which waiting for med-fichier to migrate [2].

You can also handle this yourself by one of the following solutions:

- in med-fichier: in any of the binary packages add a *versioned* breaks
on any of the binary packages from gmsh.

- in gmsh: add a *versioned* test dependency on any of the med-fichier
binary packages

- in gmsh: in any of the binary packages add a *versioned* dependency on
any of the binary packages from med-fichier

The result of any of the actions above is that the autopkgtests will be
done with both packages from unstable and will be used for both
migrations. I didn't spend the time on the relations to see which is
most appropriate in your case.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#918456: [Pkg-javascript-devel] Bug#918456: marked as done (nodejs: Buffer deprecation warning to stderr makes many tests fail)

[Jonas Smedegaard]

Control: reopen -1
Control: severity -1 important

Quoting Debian Bug Tracking System (2019-01-06 11:39:09)
>* Patch to silence buffer deprecations. Closes: #918456.
>  This patch is meant to ease migration to testing, and to be
>  removed as soon as possible.
>  It avoids printing to stderr deprecation warning about
>  calling Buffer as a constructor without the new operator.

Let's reopen but lower severity, as arguably this is only a temporariy 
workaround and should (as indicated in above changelog entry) soon be 
addressed properly.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#917733: ocaml-atd: FTBFS: dh_install: missing files, aborting

[Johannes Schauer]

Hi,

On Sat, 29 Dec 2018 23:22:43 +0100 Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

I bisected snapshots and the last good one is 20181213T124500Z and the first
bad one is 20181213T163000Z. The difference between these two is, that the
former has dune 1.0~beta20-1 while the latter comes with dune 1.6.2-1.

So the upload of dune 1.6.2-1 broke ocaml-atd.

Stéphane, you uploaded that version. Maybe you know what changed?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#918467: lxpanel: Weather plugin uses obsolete APIs, does not work.

[Teemu Ikonen]

Package: lxpanel
Version: 0.9.3-1
Severity: normal
Tags: upstream

The weather plugin of lxpanel does not update the weather information
any more. A look at the source reveals that a query is made to
yahooapis.com, which does not seem to exist any more.

Yahoo does have another weather API (see
https://developer.yahoo.com/weather/ ), but it seems to require
authentication, API keys etc.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-1-686-pae (SMP w/2 CPU cores)
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxpanel depends on:
ii  libasound2   1.1.7-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-2
ii  libcairo21.16.0-2
ii  libfm-gtk4   1.3.1-1
ii  libfm-modules1.3.1-1
ii  libfm4   1.3.1-1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.1-2
ii  libgtk2.0-0  2.24.32-3
ii  libiw30  30~pre9-13
ii  libkeybinder00.3.1-1
ii  libmenu-cache3   1.1.0-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libwnck222.30.7-6
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  lxmenu-data  0.1.5-2
ii  lxpanel-data 0.9.3-1

Versions of packages lxpanel recommends:
ii  lxterminal [x-terminal-emulator]  0.3.2-1
ii  pavucontrol   3.0-4
ii  rxvt-unicode [x-terminal-emulator]9.23~pre.ti-1
ii  stterm [x-terminal-emulator]  0.8.1-1
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xkb-data  2.23.1-1
ii  xterm [x-terminal-emulator]   341-1

Versions of packages lxpanel suggests:
ii  chromium [www-browser] 72.0.3626.7-4
ii  firefox-esr [www-browser]  60.4.0esr-1
ii  lynx [www-browser] 2.8.9rel.1-2
ii  menu   2.1.47+b1
ii  w3m [www-browser]  0.5.3-36+b1

-- no debconf information

Bug#918466: gpg-agent: logcheck rule is not working

[Rafael Laboissière]

Package: gpg-agent
Version: 2.2.12-1
Severity: normal
Tags: patch

The following syslog entry is not being filtered by logcheck:

   Jan  6 06:25:03 rlaboiss systemd[22100]: Listening on GnuPG cryptographic 
agent and passphrase cache (access for web browsers).

The following line in /etc/logcheck/ignore.d.server/gpg-agent should 
be adjusted, accordingly:


   ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening 
on GnuPG cryptographic agent \(access for web browsers\)\.$

by adding to it the phrase "and passphrase cache".

Thanks,

Rafael Laboissière


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500, 'oldstable-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gpg-agent depends on:
ii  gpgconf 2.2.12-1
ii  libassuan0  2.5.1-2
ii  libc6   2.27-8
ii  libgcrypt20 1.8.4-3
ii  libgpg-error0   1.32-3
ii  libnpth01.6-1
ii  pinentry-curses [pinentry]  1.1.0-1+b1
ii  pinentry-gtk2 [pinentry]1.1.0-1+b1

Versions of packages gpg-agent recommends:
ii  gnupg  2.2.12-1

Versions of packages gpg-agent suggests:
pn  dbus-user-session  
ii  libpam-systemd 239-11
pn  pinentry-gnome3
pn  scdaemon   

-- Configuration Files:
/etc/logcheck/ignore.d.server/gpg-agent [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/gpg-agent'

-- no debconf information

Bug#918468: mark lua-inifile Multi-Arch: foreign

[Helmut Grohne]

Package: lua-inifile
Version: 1.0-1
Tags: patch
Control: affects -1 + src:prosody

prosody fails to cross build from source, because its transitive
dependency on lua-inifile is unsatisfiable. In general, Architecture:
all packages can never satisfy cross Build-Depends unless marked
Multi-Arch: foreign. In this case, such a marking is correct, because
lua-inifile practically is a data package with no maintainer scripts or
dependencies that could induce any architecture-dependence. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru lua-inifile-1.0/debian/changelog 
lua-inifile-1.0/debian/changelog
--- lua-inifile-1.0/debian/changelog2016-07-25 04:02:51.0 +0200
+++ lua-inifile-1.0/debian/changelog2019-01-06 12:49:23.0 +0100
@@ -1,3 +1,10 @@
+lua-inifile (1.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark lua-inifile Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Jan 2019 12:49:23 +0100
+
 lua-inifile (1.0-1) unstable; urgency=medium
 
   * Initial release. (Closes: #832337)
diff --minimal -Nru lua-inifile-1.0/debian/control 
lua-inifile-1.0/debian/control
--- lua-inifile-1.0/debian/control  2016-07-25 04:02:51.0 +0200
+++ lua-inifile-1.0/debian/control  2019-01-06 12:48:42.0 +0100
@@ -10,6 +10,7 @@
 
 Package: lua-inifile
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Provides: ${lua:Provides}
 XB-Lua-Versions: ${lua:Versions}

Bug#918469: Please Provides ebtables and arptables

[Laurent Bigonville]

Package: iptables
Version: 1.8.2-3
Severity: normal

Hi,

Shouldn't the iptables packages Provides ebtables and arptables now that
it ships these executables as well?

AFAICS, the implementation shipped in iptables are providing the same
functionalities and parameters are the one shipped in their respective
packages.

In the end it might be a good idea to remove the other packages as well
as the two versions/implementations are providing the same features.

What do you think?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages iptables depends on:
ii  libc62.28-4
ii  libip4tc01.8.2-3
ii  libip6tc01.8.2-3
ii  libiptc0 1.8.2-3
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.2-2
ii  libxtables12 1.8.2-3

Versions of packages iptables recommends:
ii  nftables  0.9.0-2

Versions of packages iptables suggests:
ii  kmod  25-2

-- no debconf information

Bug#918470: Please remove Recommends against ebtables

[Laurent Bigonville]

Package: firewalld
Version: 0.6.3-4
Severity: normal

Hi,

Recent versions of the iptables package is shipping a ebtables
executable.

This executable seems to provide the same parameters as the one shipped
in the "ebtables" package.

IMHO, that recommends can now be removed as the executable will be
present by pulling the iptables package which is a hard dependency.

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages firewalld depends on:
ii  dbus 1.13.8-1bigon1
ii  gir1.2-glib-2.0  1.58.3-1
ii  init-system-helpers  1.56+nmu1
ii  iptables 1.8.2-3
ii  policykit-1  0.115-3
ii  python3  3.7.1-3
ii  python3-dbus 1.2.8-2+b3
ii  python3-gi   3.30.4-1
ii  python3-slip-dbus0.6.5-2

Versions of packages firewalld recommends:
ii  ebtables  2.0.10.4+snapshot20181205-1
ii  ipset 6.38-1

firewalld suggests no packages.

-- Configuration Files:
/etc/firewalld/firewalld.conf [Errno 13] Permission non accordée: 
'/etc/firewalld/firewalld.conf'
/etc/firewalld/lockdown-whitelist.xml [Errno 13] Permission non accordée: 
'/etc/firewalld/lockdown-whitelist.xml'

-- no debconf information

Bug#918465: sunxi-tools installation fils without udev installed

[Ian Campbell]

On Sun, 2019-01-06 at 13:32 +0200, Adrian Bunk wrote:
> Package: sunxi-tools
> Version: 1.4.2+git20181114.6d598a-2
> Severity: serious
> 
> https://piuparts.debian.org/sid/fail/sunxi-tools_1.4.2+git20181114.6d598a-2.log

Thanks, I was just working on a fix having spotted the report on
tracker.debian.org, upload coming shortly.

Ian.

Bug#918472: Please remove Recommends against ebtables

[Laurent Bigonville]

Package: libvirt-daemon-system
Version: 4.10.0-2
Severity: normal

Hi,

Recent versions of the iptables package is shipping a ebtables
executable.

This executable seems to provide the same parameters as the one shipped
in the "ebtables" package.

IMHO, that recommends can now be removed as the executable will be
present by pulling the iptables package which is a hard dependency.

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages libvirt-daemon-system depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  firewalld  0.6.3-4
ii  gettext-base   0.19.8.1-9
ii  iptables   1.8.2-3
ii  libacl12.2.52-3+b1
ii  libapparmor1   2.13.2-3
ii  libaudit1  1:2.8.4-2
ii  libblkid1  2.33-0.2
ii  libc6  2.28-4
ii  libcap-ng0 0.7.9-1+b1
ii  libdbus-1-31.13.8-1bigon1
ii  libdevmapper1.02.1 2:1.02.155-1
ii  libgnutls303.6.5-2
ii  libnl-3-2003.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libnuma1   2.0.12-1
ii  libselinux12.8-2
ii  libvirt-clients4.10.0-2
ii  libvirt-daemon 4.10.0-2
ii  libvirt0   4.10.0-2
ii  libxml22.9.4+dfsg1-7+b3
ii  libyajl2   2.1.0-3
ii  logrotate  3.14.0-4
ii  lsb-base   10.2018112800
ii  policykit-10.115-3

Versions of packages libvirt-daemon-system recommends:
ii  dmidecode3.2-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  ebtables 2.0.10.4+snapshot20181205-1
ii  iproute2 4.19.0-2
ii  parted   3.2-23

Versions of packages libvirt-daemon-system suggests:
ii  apparmor2.13.2-3
ii  auditd  1:2.8.4-2
ii  nfs-common  1:1.3.4-2.3
ii  open-iscsi  2.0.874-7.1
ii  pm-utils1.4.1-18
pn  radvd   
ii  systemd 240-2
pn  systemtap   
pn  zfsutils

-- Configuration Files:
/etc/libvirt/nwfilter/allow-arp.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/allow-arp.xml'
/etc/libvirt/nwfilter/allow-dhcp-server.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/allow-dhcp-server.xml'
/etc/libvirt/nwfilter/allow-dhcp.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/allow-dhcp.xml'
/etc/libvirt/nwfilter/allow-incoming-ipv4.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/allow-incoming-ipv4.xml'
/etc/libvirt/nwfilter/allow-ipv4.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/allow-ipv4.xml'
/etc/libvirt/nwfilter/clean-traffic-gateway.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/clean-traffic-gateway.xml'
/etc/libvirt/nwfilter/clean-traffic.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/clean-traffic.xml'
/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-arp-spoofing.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/no-arp-spoofing.xml'
/etc/libvirt/nwfilter/no-ip-multicast.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/no-ip-multicast.xml'
/etc/libvirt/nwfilter/no-ip-spoofing.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/no-ip-spoofing.xml'
/etc/libvirt/nwfilter/no-mac-broadcast.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/no-mac-broadcast.xml'
/etc/libvirt/nwfilter/no-mac-spoofing.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/nwfilter/no-mac-spoofing.xml'
/etc/libvirt/nwfilter/no-other-l2-traffic.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/no-other-l2-traffic.xml'
/etc/libvirt/nwfilter/no-other-rarp-traffic.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/no-other-rarp-traffic.xml'
/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml'
/etc/libvirt/nwfilter/qemu-announce-self.xml [Errno 13] Permission non 
accordée: '/etc/libvirt/nwfilter/qemu-announce-self.xml'
/etc/libvirt/qemu.conf [Errno 13] Permission non accordée: 
'/etc/libvirt/qemu.conf'
/etc/libvirt/qemu/networks/default.xml [Errno 13] Permission non accordée: 
'/etc/libvirt/qemu/networks/default.xml'

-- debconf i

Bug#918388: fixed in nodejs 10.15.0~dfsg-8

[Pirate Praveen]

Control: reopen -1

On Sun, 06 Jan 2019 10:34:48 + =?utf-8?b?SsOpcsOpbXkgTGFs?=
 wrote:
>* Suggests npm - because nodejs must not be blocked by it.
>  Closes: #918388.

I don't think this reasoning is correct. gitlab recommends gitaly with
the expectation that gitaly andd gitlab could be on different machines.
ruby-rails currently recommends packages not even in the archive
currently and it is not marked for auto removals for that.

I'd be happy to be proven wrong.



signature.asc
Description: OpenPGP digital signature

Bug#918471: ipset restore fails to restore timeout of each member

[Frank Myhr]

Package: ipset
Version: 6.30-2

$ ipset -f testset.save save testset

$ more testset.save
create testset hash:ip family inet hashsize 1024 maxelem 65536 timeout 
4294967 counters comment

add testset b1.b2.b3.b4 timeout 4253474 packets 1 bytes 40
add testset b5.b6.b7.b8 timeout 4245200 packets 7 bytes 280
...

$ ipset destroy testset

$ ipset -f testset.save restore

$ ipset list testset
...
b1.b2.b3.b4 timeout 4294967 packets 1 bytes 40
b5.b6.b7.b8 timeout 4294967 packets 7 bytes 280
...

Note that testset members and packet & byte counters are restored 
correctly, but each member is assigned the *default* timeout rather than 
the saved timeout.


$ uname -a
Linux mack 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 
GNU/Linux

Bug#918473: symbols-file-missing-build-depends-package-field fails on packages with more than one shared library

[Mike Gabriel]

Package: lintian
Version: 2.5.118
Severity: minor

Hi,

I have seen this more than once now...

If a src:package contains more than one shared lib and -dev bin:pkg  
couple with a debian/libfooX.symbols file, then lintian fails to  
perform the symbols-file-missing-build-depends-package-field test on  
all shared libs / .symbols files.


My current example: mate-control-center 1.20.4-1 (upload coming in a  
minute). Although, both included shared libs' .symbols files have the  
"* Build-Depends-Package: ...-dev" line, the  
libmate-window-settings1.symbols file still always gets reported by  
lintian (false positive).


light+love + thanks for providing such a well-maintained lintian,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp2CvHlYEWgI.pgp
Description: Digitale PGP-Signatur

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Jakub Sokołowski]

I suspect this might be hardware related since I saw another person having the 
same issue on a forum, and were both using motherboards using Intels X99 
chipset.

Bug#918464: nocache: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.

[Sven Joachim]

Control: tags -1 - pending patch

[Following up on the cloned bug 918464 and dropping Santiago from CC.]

On 2019-01-06 18:20 +1100, Dmitry Smirnov wrote:

> On Saturday, 5 January 2019 6:54:39 PM AEDT Sven Joachim wrote:
>> I get a different error here:
>> 
>> ,
>> 
>> | ## #916415
>> | timeout 11 ./nocache apt show coreutils 1>>/dev/null
>> | apt: nocache.c:148: init_mutexes: Assertion `fds_lock != NULL' failed.
>> | Aborted
>> | make[1]: *** [debian/rules:21: override_dh_auto_test] Error 134
>> 
>> `
>
> Exit code suggests that APT is not happy hence timeout have nothing to do 
> with that so I suspect this is unrelated to "nocache".

ITYM it has nothing to do with timeout.  As the failed assertion comes
from nocache.c, it certainly has to do with nocache. ;-)

> Can you reproduce manually by "apt show coreutils"?

No, but with any program under nocache, e.g. "nocache true".

> Also, on which architecture is this?

Plain amd64.


The good news is that I seem to have found the explanation for the
failed assertion.  In line 147 of nocache.c we have

fds_lock = malloc(max_fds * sizeof(*fds_lock));

and malloc obviously returned NULL.  With a debug printf statement I
found out that max_fds == 1073741816, with sizeof(*fds_lock) == 40 it is
not too surprising that malloc failed.

Why is max_fds so high?  In the systemd changelog I found out the
following:

,
| systemd (240-2) unstable; urgency=medium
| 
|   * Don't bump fs.nr_open in PID 1.
| In v240, systemd bumped fs.nr_open in PID 1 to the highest possible
| value. Processes that are spawned directly by systemd, will have
| RLIMIT_NOFILE be set to 512K (hard).
| pam_limits in Debian defaults to "set_all", i.e. for limits which are
| not explicitly configured in /etc/security/limits.conf, the value from
| PID 1 is taken, which means for login sessions, RLIMIT_NOFILE is set to
| the highest possible value instead of 512K. Not every software is able
| to deal with such an RLIMIT_NOFILE properly.
| While this is arguably a questionable default in Debian's pam_limit,
| work around this problem by not bumping fs.nr_open in PID 1.
| (Closes: #917167)
| 
|  -- Michael Biebl   Thu, 27 Dec 2018 14:03:57 +0100
`

And this sid system has an uptime of 13 days, so was booted with systemd
240-1 which explains the high RLIMIT_NOFILE.  On a freshly booted
laptop, I get max_fds == 1048576 instead, and obviously malloc'ing 40
Megabytes rather than 40 Gigabytes of RAM is easily possible.

I guess I should reboot in the near future.  Feel free to close the bug
if you think that dealing with a too high value of RLIMIT_NOFILE is not
possible for nocache.

Cheers,
   Sven

Bug#918388: fixed in nodejs 10.15.0~dfsg-8

[Pirate Praveen]

[asking -release]

On 1/6/19 5:31 PM, Pirate Praveen wrote:
> Control: reopen -1
> 
> On Sun, 06 Jan 2019 10:34:48 + =?utf-8?b?SsOpcsOpbXkgTGFs?=
>  wrote:
>>* Suggests npm - because nodejs must not be blocked by it.
>>  Closes: #918388.
> 
> I don't think this reasoning is correct. gitlab recommends gitaly with
> the expectation that gitaly andd gitlab could be on different machines.
> ruby-rails currently recommends packages not even in the archive
> currently and it is not marked for auto removals for that.
> 
> I'd be happy to be proven wrong.
> 

Hi Release team,

Can you confirm if an rc bug in a packaged listed in recommends will
block testing migration of a package? (in this specific case, the fear
is that rc bug in npm will block nodejs testing migration).

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Axel Ludszuweit]

On Sun, 6 Jan 2019 11:53:49 + =?UTF-8?Q?Jakub_Soko=C5=82owski?= 
 wrote:

> I suspect this might be hardware related since I saw another person having 
> the same issue on a forum, and were both using motherboards using Intels X99 
> chipset.

I also use a motherboard with X99 chipset, manufacturer is Asrock

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Axel Ludszuweit]

On Sat, 5 Jan 2019 22:30:27 +0100 Michael Biebl  wrote:

> Am 05.01.19 um 22:09 schrieb Axel Ludszuweit:

> > Hello Michael,
> > 
> > yes, I am willing to try your package tomorrow, but I have the following 
> > questions:
> > - in the initramfs rescue shell the keyboard doesn‘t work, therefore I can 
> > run your suggested commands
> 
> Do you have a PS/2 keyboard? This should require any special (USB)
> kernel modules.
> 
> > - I must boot with the 4.18 initrd version. Installation of  your package 
> > via apt triggers creation of new 4.18 initrd image and could make my system 
> > complete unbootable. Can I do the following steps to keep a bootable system:
> > - boot into 4.18
> > - save bootable 4.18 initrd image
> > - install your package
> > - create initrd image for 4.19 via update-initram command
> > - replaced modified 4.18 initrd image by the saved one
> > - try to boot into 4.19
> 
> That sounds like a reasonable plan.
> 
> 
> > Does installation of  your package via dpkg trigger also creation of new 
> > initrd image?
> 
> Yes, installing the udev package will update the initramfs of the
> currently running kernel.
> 
> > What is the syntax, to reinstall udev 240-2, if your package does not work?
> 
> Get a copy of the 240-2 udev package (along with libudev 240-2) and then
> install them via dpkg -i *.deb


Hello Michael,

I have try your udev240-3, unfortunately it fails in the same way as udev240-2. 
Due to a lack of PS2 keyboard I can't run your suggested commands in the 
initramfs shell.
One  thing was other than I expected:
I have booted with 4.18 initrd image running 4.18 kernel, checked via uname. 
After installing 
- udev_240-3~test0_amd64.deb
- libudev-dev_240-3~test0_amd64.deb
- libudev1_240-3~test0_amd64.deb
via dpkg -i *.deb only initrd.img-4.19.0-1-amd64 was rebuilt, although 4.18 
kernel was running.
With the above mentioned udev packages I can boot into 4.18 but not into 4.19.

Bug#918388: [Pkg-javascript-devel] Bug#918388: nodejs should depend or recommend npm

[Jonas Smedegaard]

Quoting Pirate Praveen (2019-01-05 19:05:16)
> Since upstream nodejs comes with npm, people installing nodejs in 
> debian expect npm to be available.

For the record:

I agree that _some_ people installing nodejs expect npm to be available.

I disagree, however, that all but exotic uses of the binary package 
nodejs require npm to be available - quite contrary, I believe that uses 
involving npm are tied to _development_ more than _execution_ of nodejs, 
and therefore more sensibly relates to nodejs-dev than (binary) nodejs.

Also, I believe the relationship between nodejs-dev and npm is 
directional - i.e. npm that needs nodejs-dev whereas there a plenty of 
uses of nodejs-dev not requiring npm.

It may be that people familiar with nodejs outside Debian has come to 
expect it to ship "batteries included" and we may want to address that - 
not by having binary package nodejs recommend npb, but by offering 
metapackage nodejs-all which depends on or recommends the equivalent of 
installing the source package - e.g. libraries, executables, 
documentation, development headers, helper tools, and example files.

I doubt, however, that such metapackage would have much real value, so 
am only mentioning that for clarification (and invitation for others to 
consider spending time implementing).

Hope that clarifies my rather terse previous post to this bugreport.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#914357: Cannot reproduce this problem

[Santiago Vila]

On Sun, Jan 06, 2019 at 09:59:51AM +0800, Yanhao Mo wrote:

> Hmm, the reproducible building is still failed. And I still cannot
> reproduce the error.  Accordding to the error message:
> 
> > XPASS  : TestKallsyms::testProc() 'kallsyms.parseMapping(path)' returned 
> > TRUE unexpectedly. ()
> >   Loc: 
> > [/<>/hotspot-1.1.0+git20180816/3rdparty/perfparser/tests/auto/kallsyms/tst_kallsyms.cpp(138)]
> > QDEBUG : TestKallsyms::testParseErrors() "Mapping is empty."
> > QDEBUG : TestKallsyms::testParseErrors() "Invalid address: this"
> > QDEBUG : TestKallsyms::testParseErrors() "No such file or directory"
> 
> I guess that because the build environments used by
> tests.reproducible-builds.org dosen't have a normal /proc/kallsyms file.
> Or maybe it doesn't have such file at all. Could you please help verify
> that? Very appreciated.

It is usual and customary for build tools to mount the /proc directory
from host machine inside the chroot in which the build happens.

I know that sbuild does that, and it would be a real surprise if
pbuilder (used by reproducible-builds) did not do that as well.

In either case, since I'm using sbuild and the package fails to build
for me, not having /proc properly mounted is very unlikely to be the
reason for the failure.

> And if what I'm guessing is true for the /proc/kallsyms file. Then what
> operations am I excepted to take? Should I just disable the specific
> testcase?

Only as a last resort. Before that, I can offer ssh access to a
machine where this seems to happen all the time. Please contact me
privately for details.

Thanks.

Bug#918474: ITP: libmojo-ioloop-readwriteprocess-perl - Execute external programs or internal code blocks as separate process

[Hideki Yamane]

Package: wnpp
Owner: Hideki Yamane 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmojo-ioloop-readwriteprocess-perl
  Version : 0.23
  Upstream Author : Ettore Di Giacinto 
* URL : https://metacpan.org/release/Mojo-IOLoop-ReadWriteProcess
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description: Execute external programs or internal code blocks as separate 
process

Mojo::IOLoop::ReadWriteProcess is yet another process manager.

The package will be maintained under the umbrella of the Debian Perl Group.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Jakub Sokołowski]

On Sun, 6 Jan 2019 08:33:09 +0100 ludszuweit1  
wrote:
> Is it possible, that dev 240-2 have problems to boot with m2 connected SSDs?

I don't use m2(though I do have it). I'm using regular SATA ports on my MSI 
X99A SLI Plus, which uses the Intel X99 Express chipset. Anyone else using X99 
and experiencing the issue?

Bug#918475: mercurial fails to fetch clone bundles from bitbucket.org (SSL error)

[Nicolas Braud-Santoni]

Package: mercurial
Version: 4.8.1-2
Severity: important

Dear maintainers,

I just installed mercurial on my buster system, and it fails to clone
repositories from bitbucket.org:

> $ hg clone https://bitbucket.org/pypy/pypy
> 
> destination directory: pypy
> applying clone bundle from 
> https://api.media.atlassian.com/file/ade8a479-34db-4526-9823-6bd33d7703fa/binary?client=b64ca8e6-e703-4cb9-8f30-cae44f70ea24&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2Nlc3MiOnsidXJuOmZpbGVzdG9yZTpmaWxlOmFkZThhNDc5LTM0ZGItNDUyNi05ODIzLTZiZDMzZDc3MDNmYSI6WyJyZWFkIl19LCJleHAiOjE1NDY3Nzg3NDAsImlzcyI6ImI2NGNhOGU2LWU3MDMtNGNiOS04ZjMwLWNhZTQ0ZjcwZWEyNCIsIm5iZiI6MTU0Njc3ODMyMH0.DyHo3Ft-mk_ixHgL1Q6LXGJ1grzALRLarTtXJKD91rk
> error fetching bundle: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert 
> handshake failure (_ssl.c:727)
> abort: error applying bundle
> (if this error persists, consider contacting the server operator or disable 
> clone bundles via "--config ui.clonebundles=false")


Accessing the bundle URL with a different HTTP client (in my case, Firefox
nightly) works without issue, so this is unlikely to be a server-side issue.

The suggested workaround (--config ui.clonebundles=false) works, but performance
is abysmal on large repositories (such as the PyPy repo I was trying to clone).


Best,

  nicoo

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

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

Versions of packages mercurial depends on:
ii  libc6 2.28-2
ii  mercurial-common  4.8.1-2
ii  python2.7.15-3
ii  ucf   3.0038+nmu1

Versions of packages mercurial recommends:
ii  openssh-client  1:7.9p1-4

Versions of packages mercurial suggests:
ii  meld  3.18.3-1
pn  qct   

-- no debconf information

Bug#918438: orig tarball components with uppercase letters

[Ian Jackson]

Andrey Rahmatullin writes ("Re: Bug#918438: orig tarball components with 
uppercase letters"):
> On Sun, Jan 06, 2019 at 12:34:30AM +, Ian Jackson wrote:
> > This allows the possibility of uppercase letters [1].  But of course
> > distinguishing case of letters is troublesome for some computers.
> 
> Can you please explain why is this a problem for us?

People should be able to convey Debian packages (including source
packages) across such computers.  There are all sorts of situations
where a user may for whatever reason have to do so.

Note that even Debian systems sometimes mishandle this: ISO9660
(without Rock Ridge) and VFAT filesystems, both of which we commonly
use for distributing our own software, are case-insensitive.

Yes, this could be avoided by never using those filesystems and only
ever providing our softare as ext2 (say) instead of VFAT, or whatever.
Hopefully you can see why we don't do that...

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#918339: dovecot-mysql: dovecot/auth segfaults with double-free in mysql_close() / passdb_deinit()

[Apollon Oikonomopoulos]

Control: severity -1 important

Hi and thanks for the report!

On 11:00 Sat 05 Jan , Dominik Röttsches wrote:
> Package: dovecot-mysql
> Version: 1:2.3.4-2
> Severity: grave
> Tags: security
> Justification: user security hole

Downgrading severity to important; although this is a double-free memory 
corruption, I would not describe it as a grave security issue based on 
the information available. Furthermore, it being triggered from deinit, 
I expect the auth system to otherwise work normally.

> 
> Dear Maintainer,
> 
> while running dovecot with the mysql auth package, I frequently get auth 
> segfaults in the kernel log such as:
> 
> [51013.656961] auth[17706]: segfault at 60 ip 7f003b360a7b sp 
> 7ffe800d7f30 error 4 in libmariadb.so.3[7f003b354000+26000]
> [51013.658978] Code: 85 ff 0f 84 27 01 00 00 55 48 89 e5 41 54 53 48 8b 87 f0 
> 04 00 00 48 89 fb 48 85 c0 74 2d 4c 8b 20 4d 85 e4 74 25 49 8b 04 24 <48> 8b 
> 40 60 48 85 c0 74 02 ff d0 4c 89 e7 e8 92 3c ff ff 48 8b 83
> 
> I attached gdb to the auth process, but I was unable to get debug symbols for 
> libmariadbclient.so.18. Anyway, I get these stacktraces for the crash - which 
> seems to be a crash on disconnect / mysql_close().
> 
> #1  0x7f59d8d08535 in __GI_abort () at abort.c:79
> #2  0x7f59d8d5f718 in __libc_message (action=action@entry=do_abort, 
> fmt=fmt@entry=0x7f59d8e6a29a "%s\n")
> at ../sysdeps/posix/libc_fatal.c:181
> #3  0x7f59d8d65e3a in malloc_printerr (str=str@entry=0x7f59d8e6bf60 
> "free(): double free detected in tcache 2") at malloc.c:5382
> #4  0x7f59d8d6791d in _int_free (av=0x7f59d8ea1c40 , 
> p=0x564222bd44e0, have_lock=) at malloc.c:4193
> #5  0x7f59d8c1ea8e in mysql_close () from 
> target:/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
> #6  0x7f59d91801fe in ?? () from 
> target:/usr/lib/dovecot/modules/auth/libdriver_mysql.so
> #7  0x564220be2a14 in ?? ()
> #8  0x564220bd88f1 in db_sql_unref ()
> #9  0x564220bcd92e in passdb_deinit ()
> #10 0x564220bb7099 in auths_deinit ()
> #11 0x564220bb5e0c in main ()
> 
> I would expect not to have such crashes during the operation of the auth 
> module.
> 
> My sql auth configuration is as follows:
> 
> driver = mysql
> connect = host=127.0.0.1 dbname=maildb user=mail password=
> default_pass_scheme = CRYPT
> password_query = SELECT email AS user, newcrypt AS password FROM passwd WHERE 
> email = '%u'
> iterate_query = SELECT email AS user FROM passwd
> 
> The table schema for the passwd table is:
> 
> DESCRIBE passwd
> 
> email char(128)   NO  PRI
> newcrypt  char(128)   NO
> name  char(128)   NO
> uid   int(10) unsignedNO  8
> gid   int(10) unsignedNO  8
> home  char(255)   NO
> maildir   char(255)   NO
> quota char(255)   NO
> 
> -- Package-specific info:
> 
> dovecot configuration
> -
> # 2.3.4 (0ecbaf23d): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.4 ()
> # OS: Linux 4.19.0-1-amd64 x86_64 Debian buster/sid ext4
> # Hostname: mail.drwebdesign.de
> protocol lmtp {
>   mail_plugins = fts fts_solr sieve
> }
> protocol imap {
>   mail_max_userip_connections = 100
> }
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
> to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
> en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dovecot-mysql depends on:
> ii  dovecot-core 1:2.3.4-2
> ii  libc62.28-3

> ii  libmariadbclient18 [libmariadbclient18]  1:10.3.11-3
 
This issue appears to manifest only with libmariadbclient18 10.3.x, and 
not with 10.1.x from testing. I suspect the culprit to be 
libmariadbclient18, but will need to investigate further.

Regards,
Apollon

Bug#918476: ITS: fish

[Mo Zhou]

Package: fish
Version: 2.7.1-3+b1
X-Debbugs-CC: Tristan Seligmann 

Hi Tristan,

fish is my default login shell and I wish to use fish 3.0 and push
fish 3.0.X into Buster. So following the ITS process I'm filing this
bug.

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#ps-guidelines

And I'm preparing the NEW release here
https://salsa.debian.org/lumin/fish
before pushing anything to the original git repo

Bug#857490: dgit: shouldn't fail when previous backport not mentioned in changelog

[Ian Jackson]

Sean Whitton writes ("Re: Bug#857490: dgit: shouldn't fail when previous 
backport not mentioned in changelog"):
> Suggesting that the user use --overwrite=2.13.0-1.1~bpo8+1, or `git
> merge -s ours dgit/dgit/stretch-backports`, is indeed what we should do.
> 
> I think that official backports is the only case where this is likely to
> come up often.  So I suggest that we start a dgit-maint-bpo(7) with tips
> and techniques for maintaining official backports (also see #898494).
> In that page we can say that if you are using what in this bug I've
> called a rebase workflow, you will need to use --overwrite=X.Y.Z for
> each upload.
> 
> (Calling it dgit-maint-bpo(7) rather than dgit-maint-backport(s)(7) is
> meant to make explicit reference to backports.debian.org.)

SGTM.

> I also think that dgit could emit a recommendation to look at that
> manpage in the kind of case that prompted me to file this bug.  It can
> just look for ~bpoNN in the version number that is missing from
> d/changelog, and output a hint.

Are you volunteering to write the (7) manpage ? :-)

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#918388: [Pkg-javascript-devel] Bug#918388: nodejs should depend or recommend npm

[Jonas Smedegaard]

Quoting Pirate Praveen (2019-01-05 19:05:16)
> Package: nodejs
> severity: important

Why is secerity important?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#914317: dgit: sometimes ignores configured clean-mode

[Ian Jackson]

Hi again.

I tried quite hard to investigate this allegation that the clean mode
was honoured differently according to whether it was specified in the
git config, or on the command line; with no success.  I also traced
the code.  I think you are mistaken on that.

However, I did repro the original poor error message like this:

   git clean -xdff
   git reset --hard c6dda1ee~1
   git-cherry-pick -n c6dda1ee
   git-deborig ||:
   dgit -wddn --include-dirty build-source
   git commit -m X
   dgit -D -v7.20181105-1 -wgf sbuild -c build

The problem is that dgit sbuild nowadays doesn't clean things at all.
As discussed in the manpage:

   dgit will only actually clean the tree if it needs to (because it
   needs to build the source package or binaries from your working
   tree).  Otherwise any untracked files will be simply ignored.

But this is wrong, in fact, because it does "need to" or things go
wrong.  Earlier I wrote a case analysis of clean modes here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910705#56

But I never completed the impleentation of the `ACTION ON SOURCE
BUILD' entries for git/git-ff.

I have now done that and the result is in my tree being tested.
With my current master, my repro above produces this:

   Would remove .pc/
   Would remove debian/patches/

   dgit: error: tree contains uncommited, untracked, unignored files
   dgit: You can use --clean=git[-ff],always (-wga/-wgfa) to delete them.

And using -wgfa indeed makes it delete the files, and then succeed.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914317: [[DRAFT PATCH]] dgit: clean mode: Refactor -wg parsing to prep for suffixes

[Ian Jackson]

This will make it convenient to add new suffix letter(s) to -wg.

No functional change.

Signed-off-by: Ian Jackson 
---
 dgit | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/dgit b/dgit
index 9b107c26..55c80701 100755
--- a/dgit
+++ b/dgit
@@ -7298,12 +7298,10 @@ sub parseopts () {
} elsif (s/^-wn$//s) {
push @ropts, $&;
$cleanmode = 'none';
-   } elsif (s/^-wg$//s) {
+   } elsif (s/^-wg(f?)$//s) {
push @ropts, $&;
$cleanmode = 'git';
-   } elsif (s/^-wgf$//s) {
-   push @ropts, $&;
-   $cleanmode = 'git-ff';
+   $cleanmode .= '-ff' if $1;
} elsif (s/^-wd(d?)([na]?)$//s) {
push @ropts, $&;
$cleanmode = 'dpkg-source';
-- 
2.11.0

Bug#913102: pulseaudio does not restore correct mic/speaker state

[Alexandre Vaissière]

Le 07/11/2018 à 05:32, Alexandre Vaissière a écrit :
> Le 06/11/2018 à 23:55, Felipe Sateler a écrit :
>> Control: tags -1 moreinfo
>>
>> On Tue, Nov 6, 2018 at 7:27 PM Alexandre Vaissiere > > wrote:
>>
>> Package: pulseaudio
>> Version: 12.2-2
>> Severity: normal
>>
>>
>> * Expected behaviour
>>
>> When I restart my machine, I expect that the sound/mic state is
>> properly
>> restored:
>> - If sound/mic was muted at shutdown, I expect for it to be muted
>> at startup,
>> - If sound/mic was unmuted at shutdown, I expect for it to be
>> unmuted at
>> startup.
>>
>> * Current behaviour
>>
>> Currently, whatever the state was at shutdown, mic and sound are
>> *unmuted* at
>> startup.
>>
>> This doesn't look like pulseaudio, but that someone is changing the
>> mute level. The first potential culprit is gnome-shell. Does this
>> problem happen if you log into a console instead of gnome?
>
> You seem to be right: if I log into a console, and I start pulseaudio
> (as it does not start by itself in this case) with systemctl --user
> start pulseaudio, then both mic/sound are correctly muted.
>
> What is maybe weirder is that if afterthat:
>
> - I close my console session
> - I open a gnome session
>
> Then in this case, the mic/sound remains muted in gnome.
>
> In log files, the difference between when it works and when it does
> not seems to be the bolded lines, that are not printed when it works.
>
> nov. 07 06:22:26 brisingr pulseaudio[1379]: I: [pulseaudio]
> module-suspend-on-idle.c: Source
> alsa_input.pci-_00_1f.3.analog-stereo idle for too long,
> suspending ...
> nov. 07 06:22:26 brisingr pulseaudio[1379]: I: [alsa-source-ALC257
> Analog] alsa-source.c: Device suspended...
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] source.c:
> alsa_input.pci-_00_1f.3.analog-stereo: suspend_cause: (none) -> IDLE
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] source.c:
> alsa_input.pci-_00_1f.3.analog-stereo: state: IDLE -> SUSPENDED
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] core.c:
> Hmm, no streams around, trying to vacuum.
> nov. 07 06:22:26 brisingr pulseaudio[1379]: I: [pulseaudio]
> module-suspend-on-idle.c: Sink
> alsa_output.pci-_00_1f.3.analog-stereo idle for too long,
> suspending ...
> nov. 07 06:22:26 brisingr pulseaudio[1379]: I: [alsa-sink-ALC257
> Analog] alsa-sink.c: Device suspended...
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] sink.c:
> alsa_output.pci-_00_1f.3.analog-stereo: suspend_cause: (none) -> IDLE
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] sink.c:
> alsa_output.pci-_00_1f.3.analog-stereo: state: IDLE -> SUSPENDED
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] source.c:
> alsa_output.pci-_00_1f.3.analog-stereo.monitor: suspend_cause:
> (none) -> IDLE
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] source.c:
> alsa_output.pci-_00_1f.3.analog-stereo.monitor: state: IDLE ->
> SUSPENDED
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio] core.c:
> Hmm, no streams around, trying to vacuum.
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio]
> module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
> nov. 07 06:22:26 brisingr pulseaudio[1379]: D: [pulseaudio]
> module-udev-detect.c: Resuming all sinks and sources of card
> alsa_card.pci-_00_1f.3.
> *nov. 07 06:22:30 brisingr pulseaudio[1379]: D: [alsa-sink-ALC257
> Analog] alsa-sink.c: Read hardware volume: front-left: 30129 /  46% /
> -20,25 dB,   front-right: 30129 /  46% / -20,25 dB**
> **nov. 07 06:22:30 brisingr pulseaudio[1379]: D: [pulseaudio] sink.c:
> The mute of sink alsa_output.pci-_00_1f.3.analog-stereo changed
> from yes to no.**
> **nov. 07 06:22:30 brisingr pulseaudio[1379]: D: [alsa-sink-ALC257
> Analog] alsa-sink.c: Read hardware volume: front-left: 30129 /  46% /
> -20,25 dB,   front-right: 30129 /  46% / -20,25 dB**
> **nov. 07 06:22:30 brisingr pulseaudio[1379]: I: [pulseaudio]
> module-device-restore.c: Storing volume/mute for device+port
> sink:alsa_output.pci-_00_1f.3.analog-stereo:analog-output-speaker.**
> **nov. 07 06:22:30 brisingr pulseaudio[1379]: D: [alsa-source-ALC257
> Analog] alsa-source.c: Read hardware volume: front-left: 20724 /  32%
> / -30,00 dB,   front-right: 20724 /  32% / -30,00 dB**
> **nov. 07 06:22:30 brisingr pulseaudio[1379]: D: [pulseaudio]
> source.c: The mute of source alsa_input.pci-_00_1f.3.analog-stereo
> changed from yes to no.**
> **nov. 07 06:22:30 brisingr pulseaudio[1379]: I: [pulseaudio]
> module-device-restore.c: Storing volume/mute for device+port
> source:alsa_input.pci-_00_1f.3.analog-stereo:analog-input-internal-mic.**
> **nov. 07 06:22:40 brisingr pulseaudio[1379]: I: [pulseaudio]
> module-device-restore.c: Synced.*
>
After more tests, I noticed that the mute was changed right when gdm
session was killed.

I then

Bug#918454: vim should not Build-Depends: libtool-bin

[James McCoy]

On Sun, Jan 06, 2019 at 10:51:54AM +0100, Helmut Grohne wrote:
> I see that you added a build dependency on libtool-bin. That's
> unfortunate as we want to remove libtool-bin (not libtool) from the
> archive.
> 
> I'm hoping that we can still revert this part and find a better solution
> as the reasons for adding it are still on your mind. debian/changelog
> says you need them for libterm tests.
> 
> I see that vim is using autotools. Can you instead ask autotools to
> create a libtool at configure time and use that for libterm?

I package a number of projects that write simple Makefiles that directly
use libtool, with no sign of autotools.  Does this mean that I'm
expected to patch all of those builds systems locally to use autotools?

libvterm is one of those projects, which Vim upstream has unfortunately
decided to embed, instead of just using the library (making changes to
it at the same time).

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#887022: xfce4-clipman: History vanishes on reboot

[Thulium Equasman]

Package: xfce4-clipman
Version: 2:1.4.1-1
Followup-For: Bug #887022

Dear Maintainer,

I also noticed the same behavior. xfce4-clipman frequently clears it's memory
(history) after re-boot. My guess is that, it clears the memory after the
history counts reaches the maximum value: in that case it's 1000.

Could you please solve this issue? I'l be happy to provide further related info
if needed.

Thanks.



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

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

Versions of packages xfce4-clipman depends on:
ii  libc6   2.24-11+deb9u3
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgtk-3-0  3.22.11-1
ii  libqrencode33.4.4-1+b2
ii  libx11-62:1.6.4-3+deb9u1
ii  libxfce4ui-2-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  libxtst62:1.2.3-1

xfce4-clipman recommends no packages.

xfce4-clipman suggests no packages.

-- no debconf information

Bug#918382: broken upload

[Mathieu Malaterre]

On Sun, Jan 6, 2019 at 12:09 PM 積丹尼 Dan Jacobson  wrote:
>
> As you can see in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918382
> gimp is relying (Depending) on a broken upload.
>
> Perhaps you could make it Depend on libopenexr24 instead of libopenexr23.
>

Well then, take the binary package from sid:

https://packages.debian.org/sid/libopenexr23

Bug#918477: libkarma FTCBFS: Build-Depends: cli-common-dev unsatisfiable

[Helmut Grohne]

Source: libkarma
Version: 0.1.2-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Thank you for applying my cross build patch. Unfortunately, merging
Build-Depends-Indep breaks cross building, because cli-common-dev cannot
be satisfied. Please split Build-Depends-Indep again. The attached patch
implements that in a way that works for arch-only, indep-only and full
builds.

Helmut
diff --minimal -Nru libkarma-0.1.2/debian/changelog 
libkarma-0.1.2/debian/changelog
--- libkarma-0.1.2/debian/changelog 2019-01-02 00:36:36.0 +0100
+++ libkarma-0.1.2/debian/changelog 2019-01-06 14:42:40.0 +0100
@@ -1,3 +1,10 @@
+libkarma (0.1.2-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Split out Build-Depends-Indep again. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 06 Jan 2019 14:42:40 +0100
+
 libkarma (0.1.2-4) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru libkarma-0.1.2/debian/control libkarma-0.1.2/debian/control
--- libkarma-0.1.2/debian/control   2019-01-02 00:34:12.0 +0100
+++ libkarma-0.1.2/debian/control   2019-01-06 14:42:38.0 +0100
@@ -6,6 +6,7 @@
  libtagc0-dev,
  libusb-dev,
  zlib1g-dev,
+Build-Depends-Indep:
  cli-common-dev (>= 0.8~),
  mono-devel (>= 2.4.2.3),
 Standards-Version: 4.3.0
diff --minimal -Nru libkarma-0.1.2/debian/rules libkarma-0.1.2/debian/rules
--- libkarma-0.1.2/debian/rules 2019-01-02 00:34:22.0 +0100
+++ libkarma-0.1.2/debian/rules 2019-01-06 14:42:40.0 +0100
@@ -18,8 +18,10 @@
 override_dh_auto_install:
dh_auto_install -- MCS=$(shell which mono-csc)
 
+DH_ADDONS=
 %:
-   dh $@ --with cli --no-parallel
+   dh $@ --with=$(DH_ADDONS) --no-parallel
+build binary %-indep: DH_ADDONS=cli
 
 # dh_clideps expects to see dh_makeshlibs called before it, but dh_makeshlibs
 # is never called when building only arch-indep packages. So we force the issue

Bug#918478: digikam: ImageEditor window is blank when opened a second time

[Andrea Borgia]

Package: digikam
Version: 4:5.9.0-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

Starting from a clean install of digikam(*), go through the config questions, 
find an image and click to open the image editor.
Carefully observe the toolbar buttons at the bottom.
Now close the editor, NOT with the "close editor" button but with the X at the 
top right (that is, the close window command), and exit digikam.
Start digikam again and re-enter the editor: you'll now see that the toolbar is 
missing.
If the image editor is always closed with the menu button, the issue does not 
show up.
Tested on two different "testing" installations.

This is already known upstream: https://bugs.kde.org/show_bug.cgi?id=395875

(*) delete ~/.config/digikamrc and ~/.local/share/kxmlgui5/digikam


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

Kernel: Linux 4.20.0-rc6-18.12.13.amdgpu (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), 
LANGUAGE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages digikam depends on:
ii  digikam-data  4:5.9.0-1
ii  digikam-private-libs  4:5.9.0-1+b1
ii  kipi-plugins  4:5.9.0-1+b1
ii  libc6 2.28-2
ii  libgcc1   1:8.2.0-13
ii  libkf5configcore5 5.51.0-1
ii  libkf5coreaddons5 5.51.0-1
ii  libkf5filemetadata3   5.51.0-1
ii  libkf5i18n5   5.51.0-1
ii  libqt5core5a  5.11.3+dfsg-2
ii  libqt5gui55.11.3+dfsg-2
ii  libqt5sql55.11.3+dfsg-2
ii  libqt5sql5-mysql  5.11.3+dfsg-2
ii  libqt5sql5-sqlite 5.11.3+dfsg-2
ii  libqt5widgets55.11.3+dfsg-2
ii  libstdc++68.2.0-13
ii  perl  5.28.1-3

Versions of packages digikam recommends:
ii  ffmpegthumbs   4:18.12.0-1
ii  firefox-esr [www-browser]  60.4.0esr-1
ii  w3m [www-browser]  0.5.3-36+b1

Versions of packages digikam suggests:
pn  digikam-doc 
pn  systemsettings  

-- no debconf information

Bug#918322: initramfs-tools: kernel fails to boot with "Gave up waiting for root file system device"

[Jakub Sokołowski]

On Sun, 6 Jan 2019 13:32:32 +0100 Axel Ludszuweit  
wrote:
> With the above mentioned udev packages I can boot into 4.18 but not into 4.19.

Same here. I tried the udev 240-3 that was linked and 4.19.0-1 didn't work for 
me either.

Bug#918454: vim should not Build-Depends: libtool-bin

[Helmut Grohne]

Hi James,

On Sun, Jan 06, 2019 at 08:33:12AM -0500, James McCoy wrote:
> I package a number of projects that write simple Makefiles that directly
> use libtool, with no sign of autotools.  Does this mean that I'm
> expected to patch all of those builds systems locally to use autotools?

As much as I would like to tell you otherwise, that's my understanding.
libtool seems to have been designed as an add-on to autotools and while
Debian has packaged a libtool output in libtool-bin, that package only
works for native builds. The "libtool" command must be different for any
distinct pair of build and host architecture. With around 10 release
architectures and more ports that'd result in hundreds of libtools, so
the only reasonable way is to generate it at build time. If you find an
easier way to generate it than autotools, please tell me. Indeed, what I
did for lua5.3 is creating an addon autotools project just for creating
a libtool to use with the Makefile build system. Possibly, the Debian
libtool package could carry a "make-me-a-libtool-for ${DEB_BUILD_ARCH}
${DEB_HOST_ARCH}"?

Helmut

Bug#918382: broken upload

[積丹尼 Dan Jacobson]

I had to do
# aptitude purge gimp
# aptitude -t sid install gimp
# aptitude forbid-version  libilmbase23  libopenexr23  libpoppler-glib8
Marking version 2.3.0-3 of package libilmbase23 as forbidden
Marking version 2.3.0-3 of package libopenexr23 as forbidden
Marking version 0.71.0-1 of package libpoppler-glib8 as forbidden
to get rid of all the bugs.

Bug#918479: freecad: autopkgtest regression

[Graham Inggs]

Source: freecad
Version: 0.17+dfsg1-5
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 0.17+dfsg1-5, freecad has been failing its own
autopkgtests [1] with the following error:

autopkgtest [04:10:57]: test freecadtest: [---
Traceback (most recent call last):
  File "", line 39, in 
  File "/usr/share/freecad/Mod/Test/TestApp.py", line 95, in TestText
s = unittest.defaultTestLoader.loadTestsFromName(s)
  File "/usr/lib/python2.7/unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
: No module named 1
FreeCAD 0.17, Libs: 0.17R
(c) Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2018
  #   ###   
  ##  # #   #   #
  # ##     # #   #  #   #
    # # #  # #  #  # #  #   #
  # #      ## # #   #
  # #   ## ## # #   #  ##  ##  ##
  # #       ### # #    ##  ##  ##

autopkgtest [04:10:57]: test freecadtest: ---]
autopkgtest [04:10:58]: test freecadtest:  - - - - - - - - - - results
- - - - - - - - - -
freecadtest  FAIL non-zero exit status 1
autopkgtest [04:10:58]: test freecadtest:  - - - - - - - - - - stderr
- - - - - - - - - -
Traceback (most recent call last):
  File "", line 39, in 
  File "/usr/share/freecad/Mod/Test/TestApp.py", line 95, in TestText
s = unittest.defaultTestLoader.loadTestsFromName(s)
  File "/usr/lib/python2.7/unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
: No module named 1
autopkgtest [04:10:58]:  summary
freecadtest  FAIL non-zero exit status 1

Regards
Graham


[1] https://ci.debian.net/packages/f/freecad/unstable/amd64/

Bug#918138: qtox: Add AppArmor profile

[Vincas Dargis]

On 2019-01-05 14:33, intrigeri wrote:> Vincas Dargis:

intrigeri  what's your take on this? Where should new profiles be
"placed"?


Having the policy live along with the software it confines, i.e.
in the upstream VCS, is ideal, as long as upstream somewhat cares
about it


Yeah, I guess so, it would be more scalable approach for profiles to live in upstream repositories. 
There are so many applications and so little AppArmor devs/contributors.


I'll try to speak with qTox upstream, see how it goes.

Bug#918480: squashfs-tools: Please move to "squashfskit" fork

[Chris Lamb]

Package: squashfs-tools
Version: 1:4.3-7
Severity: wishlist
X-Debbugs-CC: lyn...@fe80.eu, intrig...@boum.org, 
reproducible-bui...@lists.alioth.debian.org

Hi László,

First, thanks for maintaining squashfs-tools! As I understand it,
upstream has been replaced with a more-active fork maintained by
Lynxis Couzens:

  https://github.com/squashfskit/squashfskit

§

This contains a number of patches that I, Intrigeri & Tails are using
for generating reproducibile output, such as:

From: Chris Lamb 
Date: Sun, 6 Jan 2019 11:03:42 +0100
Subject: If SOURCE_DATE_EPOCH is set, use that timestamp for the mkfs time.

See https://reproducible-builds.org/specs/source-date-epoch/ for more
information about this environment variable.

Based on a patch by Alexander Couzens  posted on
https://sourceforge.net/p/squashfs/mailman/message/34673610/
---
 squashfs-tools/mksquashfs.c | 33 +
 1 file changed, 33 insertions(+)

and:

From: intrigeri 
Date: Sun, 6 Jan 2019 11:07:08 +0100
Subject: If SOURCE_DATE_EPOCH is set,
 also clamp content timestamps with that value.

Based on a patch by Alexander Couzens  posted on
https://sourceforge.net/p/squashfs/mailman/message/34673610/

Updated by Chris Lamb  to use (time_t)0 as a
sentinel value over -1.
---
 squashfs-tools/mksquashfs.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

Although I do note this latter one would require a slightly different
rebase due to, at least:

  [ Michael Vogt  ]
  * debian/patches/0005-add-fstime.patch: initializing the time_t variable
with (time_t)0 instead of (time_t)-1 to avoid creating all filesystems
on "Wed Dec 31 23:59:59 1969"

… that was part of the squashfs-tools 1:4.3-6 upload.

§

Anyway, thanks again for maintaining this package.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#908868: Would like to maintain Docker.io package

[Manas Kashyap]

Hola ,
I am Manas Kashyap an active Debian contributor and i have knowledge about
Debian packaging and i would like to maintain the package .
Thanking you
Manas kashyap 

Bug#918480: squashfs-tools: Please move to "squashfskit" fork

[Chris Lamb]

Chris Lamb wrote:

> Updated by Chris Lamb  to use (time_t)0 as a
>  sentinel value over -1.

I've at least pushed/poked this upstream so it's somewhere a bit
more obvious:

  https://github.com/squashfskit/squashfskit/pull/2


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#918481: gnuradio: FTBFS on hurd-i386

[Samuel Thibault]

Source: gnuradio
Version: 3.7.13.4-2
Severity: important
Tags: patch

Hello,

gnuradio currently FTBFS on hurd-i386 because of some inconsistency in
enabled modules (missing libgnuradio-fcd3.7.13 package). The attached
patch also enables zeromq support, now available in hurd-i386, and
qtgui.

Samuel

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
 RR> Ce que je cherche à démontrer, c'est qu'il est injuste de faire
 RR> l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
 un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
 -+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-
--- debian/control.original 2019-01-06 10:09:31.0 +
+++ debian/control  2019-01-06 10:15:16.0 +
@@ -35,7 +35,7 @@
   libvolk1-dev (>=1.4),
libxi-dev,
libxrender-dev,
-   libzmq3-dev [!hurd-i386] | libzmq-dev [!hurd-i386],
+   libzmq3-dev | libzmq-dev,
pkg-config (>=0.15.0),
portaudio19-dev,
python-cheetah,
@@ -45,11 +45,11 @@
python-lxml,
python-numpy,
python-opengl,
-  python-pyqt5 [!hurd-i386],
+  python-pyqt5,
python-scipy,
python-sphinx,
python-wxgtk3.0,
-   python-zmq [!hurd-i386],
+   python-zmq,
   qt5-qmake,
   qtbase5-dev,
   qttools5-dev,
@@ -238,7 +238,7 @@
 
 Package: libgnuradio-fcd3.7.13
 Section: libs
-Architecture: kfreebsd-any linux-any
+Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Multi-Arch: same
@@ -323,7 +323,7 @@
 
 Package: libgnuradio-qtgui3.7.13
 Section: libs
-Architecture: kfreebsd-any linux-any
+Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Multi-Arch: same
@@ -418,7 +418,7 @@
 
 Package: libgnuradio-zeromq3.7.13
 Section: libs
-Architecture: kfreebsd-any linux-any
+Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Multi-Arch: same

Bug#918276: vlc: When you open VLC 3.0.5-1 any .mp4 file a Debian 9.6 hangs

[Сергей Фёдоров]

In Debian 9.6 Sid after trying to open any .mp4-file in VLC  3.0.5-2 Debian 
hangs immediately before first frame is displaing (only the mouse cursor can be 
moved around the screen, the keybord and mouse buttons are locked) and only 
reinstalling Debian from CD or USB is resolved the situation. The same thing 
happened for all versions VLC above 3.0.3-1-0+deb9u1. Then I reinstall Debian 
and install from Stretch repository VLC  3.0.3-1-0+deb9u1, normally open the 
same .mp4 file and everything is displayed normally.

It Turn out that in Debian Sid I use Mesa-drivers:

mesa-common-dev v. 18.2.8-2 (Developer documentation for Mesa)
mesa-utils v. 8.4.0-1+b1 (Mesa GL different utilities)
mesa-va-drivers v. 18.2.8-2 (Mesa VA-API video acceleration drivers)
mesa-vdpau-drivers v. 18.2.8-2 (Mesa VDPAU video acceleration drivers)

Through Sebastian Ramacher's questions i decided to install Nvidea driver.

Nvidia-detect v. 390.87-5 from Debain Sid reports:

Detected NVIDIA GPUs:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7300 
GT] [10de:0393] (rev a1)
Checking card:  NVIDIA Corporation G73 [GeForce 7300 GT] (rev a1)
Your card is only supported by the 304 legacy drivers series, which is only 
available up to stretch.

But I agreed not with nvidia-detect and installed from Sid resitory Nvidia 
packets:

glx-alternative-nvidia (0.9.0)
glx-diversions (0.9.0)
libegl-nvidia0 (390.87-5)
libgl1-nvidia-glvnd-glx (390.87-5)
libgles-nvidia1 (390.87-5)
libgles-nvidia2 (390.87-5)
libglx-nvidia0 (390.87-5)
libnvidia-cfg1 (390.87-5)
libnvidia-ml1 (390.87-5)
nvidia-alternative (390.87-5)
nvidia-driver (390.87-5)
nvidia-driver-bin (390.87-5)
nvidia-driver-libs (390.87-5)
nvidia-egl-common (390.87-5)
nvidia-egl-icd (390.87-5)
nvidia-installer-cleanup (20151021+8)
nvidia-kernel-common (20151021+8)
nvidia-kernel-dkms (390.87-5)
nvidia-kernel-support (390.87-5)
nvidia-legacy-check (390.87-5)
nvidia-modprobe (390.25-1)
nvidia-persistenced (390.25-1)
nvidia-settings (390.67-1)
nvidia-support (20151021+8)
nvidia-vdpau-driver (390.87-5)
nvidia-vulkan-common (390.87-5)
nvidia-vulkan-icd (390.87-5)
xserver-xorg-video-nvidia (390.87-5)

I rebooted Debian and beheld that monitor resolution is set to  1024x768 
insteed 1280x1024, what was with the mesa-drivers (the same is going and with 
nvidia-legacy-304xx-driver metapackage v. 304.137-6 and with 
nvidia-legacy-340xx-driver NVIDIA metapackage 340xx legacy version v. 340.107-3 
install. Both versions from Sid repository). I started Aegisub for subtitles 
correction, but Aegisub issued an error message:

An assertion failed!
../src/unix/glx11.cpp(589): assert "ok" failed in GetGLXVersion(): GLX version 
not found

and stopped working.

I installed  VLC 3.0.5-2 and open in it arbitrary .mp4 file. A file is opened 
and VLC became normally display .mp4 file but in lower resolution 1024x768 (I 
remember in mesa — 1280x1024). I desided to check what Debian is going under 
stress: went to the local Debian repository and start under root its copying 
about 340 Gb «cp Rp . "/some dir/"». VLC worked normally but mouse cursor 
through switch to different tasks freezed fore a some seconds, that was not 
going under mesa-drivers. I stopped VLC, stopped copying, deleted libvlc* and 
vlc* packets of  3.0.5-2 version and installed  VLC  3.0.3-1-0+deb9u1 from  
Stretch repository.

Results: for my video card Asus EN7300GT/Silent/HTD/256M/A in VLC version 
higher 3.0.3-1-0+deb9u1 Debian hangs not  at the .mp4 file opening with 
NVIDIA-drivers only (hangs for mesa drivers only). But herewith video card is 
installed more lowed resolution -  1024x768 for 19"-monitor insteed  1280x1024, 
it stops working subtitles correction programm Aegisub, Debian behaves more 
slowly under stress on nvidia-drivers, then under mesa-drivers. I think, that 
«www.videolan.org» is necessary to pay attention to it and to give the chance 
(as before) to work VLC under mesa-drivers.

Bug#917788: libmedc11: Overwrites a file from libmedc1v5

[Gilles Filippini]

On Sat, 5 Jan 2019 22:11:44 +0100 pini  wrote:
> On Sat, 5 Jan 2019 21:53:13 +0100 Gilles Filippini  wrote:
> Oh, looking at cruft-report [1] I see that syrthes-tools still dépends on 
> libmedc1v5, preventing the removal :
> * source package med-fichier version 4.0.0+repack-6 no longer builds
>   binary package(s): libmed1v5 libmedc1v5
>   on amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x
>   - suggested command:
> dak rm -m "[auto-cruft] NBS (no longer built by med-fichier)" -s unstable 
> -a amd64,arm64,armel,armhf,hurd-i386,i386,mips,mips64el,mipsel,ppc64el,s390x 
> -p -R -b libmed1v5 libmedc1v5
>   - broken Depends:
> syrthes: syrthes-tools [amd64 arm64 armel armhf hurd-i386 i386 mips 
> mips64el mipsel ppc64el]
> 
> [1] http://ftp-master.debian.org/cruft-report-daily.txt
> 
> I'm going to fix that.

I've uploaded a new release of the syrthes package. There shouldn't be
any blocker left for these cruft packages removal.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#892930: tlsh: diff for NMU version 3.4.4+20151206-1.1

[Niels Thykier]

Control: tags 892930 + pending


Dear maintainer,

I've prepared an NMU for tlsh (versioned as 3.4.4+20151206-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru tlsh-3.4.4+20151206/debian/changelog 
tlsh-3.4.4+20151206/debian/changelog
--- tlsh-3.4.4+20151206/debian/changelog2016-01-16 15:23:51.0 
+
+++ tlsh-3.4.4+20151206/debian/changelog2019-01-06 14:56:51.0 
+
@@ -1,3 +1,16 @@
+tlsh (3.4.4+20151206-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Niels Thykier ]
+  * Set Rules-Requires-Root to "no" as tlsh does not need (fake)root.
+  * Bump priority to optional as extra has been deprecated.
+
+  [ Helmut Grohne ]
+  * Multiarchify python Build-Depends. (Closes: #892930)
+
+ -- Niels Thykier   Sun, 06 Jan 2019 14:56:51 +
+
 tlsh (3.4.4+20151206-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru tlsh-3.4.4+20151206/debian/control tlsh-3.4.4+20151206/debian/control
--- tlsh-3.4.4+20151206/debian/control  2016-01-16 13:47:10.0 +
+++ tlsh-3.4.4+20151206/debian/control  2019-01-06 14:53:50.0 +
@@ -1,14 +1,17 @@
 Source: tlsh
Maintainer: Jérémy Bobbio 
 Section: admin
-Priority: extra
+Priority: optional
 Build-Depends: cmake,
debhelper (>= 9),
dh-python,
-   python-all-dev,
-   python3-all-dev,
+   libpython-all-dev,
+   libpython3-all-dev,
+   python-all-dev:any,
+   python3-all-dev:any,
python-docutils,
python-setuptools
+Rules-Requires-Root: no
 Standards-Version: 3.9.6
 Homepage: https://github.com/trendmicro/tlsh
 Vcs-Git: git://anonscm.debian.org/collab-maint/tlsh.git

Bug#918483: O: cairo-clock -- Analog clock drawn with vector-graphics

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918482: O: flashplugin-nonfree -- installer package for adobe flash player

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918484: O: cmdpack -- cd image compress

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918138: qtox: Add AppArmor profile

[Vincas Dargis]

https://github.com/qTox/qTox/issues/5484

Bug#916060: tuxmath: Starts and immediately closes

[Holger Levsen]

Hi Chris,

On Sun, Jan 06, 2019 at 10:39:39AM +1100, Chris Donoghue wrote:
> This patch fixes issue with deprecated rsvg_handle_get_desc now return
> NULL value.
> 
> Tuxmath now runs fine for me.

I've come up with the same patch yesterday, though I didnt have the time
yet to confirm it, so many thanks for that.

I'll upload a fixed version soon, probably tomorrow, maybe later today.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#918485: O: freedroidrpg -- rpg game influenced by paradroid

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918488: O: pepperflashplugin-nonfree -- pepper flash installer package

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918487: O: libio-lockedfile-perl -- IO::LockedFile Class - supply object methods for locking files

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918486: O: num-utils -- dealing with numbers on command line

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918490: O: empty-expect -- Run processes and applications under pseudo-terminal

[Bart Martens]

Package: wnpp
Severity: normal

Bug#918489: O: grdesktop -- GNOME frontend for the rdesktop client

[Bart Martens]

Package: wnpp
Severity: normal

Bug#898820: yaz blocking removal of icu-config

[Vincent Danjean]

  Hi,

Le 06/01/2019 à 13:44, Hugh McMaster a écrit :
> Hi Vincent,
> 
> I hope you're having a good weekend!
> 
> We are now six days from the transition freeze for Buster, so it
> doesn't seem likely that we will
> have time for the transition (assuming yaz passes through NEW soon).
> 
> In #898820 [1], Laszlo has asked if we can release a new version of
> yaz that removes calls to icu-config. yaz is the (last) blocker
> preventing the removal of icu-config from Debian.
> 
> I used an upstream patch and everything builds correctly. Since our
> salsa changelog is already listed for 5.27.1 experimental, how can we
> can add a new 4.x version?

Go ahead with a nmu upload in unstable. I'm sorry I won't have time
to handle this myself these days. I'm too busy with my paid work for
this moment.

  Regards,
Vincent

> Ideally, this version would be uploaded to unstable very soon.
> 
> Hugh
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898820
> 

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#878340: [debian-mysql] Bug#878340: libmariadbclient-dev-compat: mysqlclient.pc is not visible to pkg-config

[Otto Kekäläinen]

Hello!

su 6. tammik. 2019 klo 12.54 Helmut Grohne (hel...@subdivi.de) kirjoitti:
>
> Hi Otto,
>
> On Sun, Jan 06, 2019 at 12:19:50PM +0200, Otto Kekäläinen wrote:
> > Currenlty in Debian unstable we have mariadb-10.3. Would you be kind
> > and rebase, test and submit your patch on mariadb-10.3?
>
> If "apt-get source libmariadbclient-dev-compat" yields a non-default
> version in unstable, then you have cruft in unstable. Would you be kind
> and clean up that cruft to make standard workflows work?

I think I have been doing Debian packaging almost every day, even on
weekends, for the past 5 weeks. Currently we are in the middle of
having mariadb-10.1 in testing and mariadb-10.3 in unstable (along
with an updated mysql-defaults in unstable). There are a multitude of
issues and due to the complexity of having to adopt to upstream
changes that sometimes conflict with Debian needs there is a lot of
work. Also, as some areas are regression prone, I have been forced to
spend time to develop on CI tooling to ensure we don't get old
regressions back again.

So all help and encouragement is welcome. Thanks for your patch!

In mariadb-10.3 the package libmariadbclient-dev-compat has been
replaced by libmariadb-dev-compat (which was previously alreadi in
Debian as well as part of
https://tracker.debian.org/pkg/mariadb-connector-c but upstream merged
the connector into the server source so we need to adapt now.

> In particular, please don't let important bugs linger for extended
> periods of time without any response. Much less ones that are as trivial
> to fix as this one is.

Sorry, I wasn't active with the packaging in the fall 2017 due to
other priorities and the person active at the time overlooked this,
and I seem to have overlooked it as well when i in DebConf 2018
triaged and updated all bugs (but apparently not this one, sorry).

Bug#918480: squashfs-tools: Please move to "squashfskit" fork

[GCS]

Hi Chris,

On Sun, Jan 6, 2019 at 3:30 PM Chris Lamb  wrote:
> First, thanks for maintaining squashfs-tools! As I understand it,
> upstream has been replaced with a more-active fork maintained by
> Lynxis Couzens:
>
>   https://github.com/squashfskit/squashfskit
 Checked the activity of this project, compared to the upstream one[1].
The one you promotes has the following latest commits:
master - Sep 23, 2017
staging - May 25, 2017
feature_versionsh - Nov 1, 2017

Upstream latest commit:
master - Jun 12, 2018

It seems more recent. What do I miss with the one you mentioned? That
seems untouched for more than a year.

> This contains a number of patches that I, Intrigeri & Tails are using
> for generating reproducibile output, such as:
[...]
 I don't see commits from this year, only your pull request.

> … that was part of the squashfs-tools 1:4.3-6 upload.
 Indeed and I think the package is up to date with all the patches
needed for the Buster release. If you may need additional changes,
please tell me so. I don't see how squashfskit might be better - going
to do a diff of the two projects.

Thanks for the heads-up,
Laszlo/GCS
[1] https://github.com/plougher/squashfs-tools