date:20181118

Package: lxcfs
Version: 2.0.8-1
Severity: important

The conffile /etc/init/lxcfs.conf is no longer shipped by the package
and now marked as obsolete conffile in the dpkg status db.

Please remove that conffile on upgrades.
A straightforward way is to use dh_installdeb and a debian/lxcfs.maintscript 
file.
See man dh_installdeb and man dpkg-maintscript-helper for more
information.


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

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

Versions of packages lxcfs depends on:
ii  libc6 2.27-8
ii  libfuse2  2.9.8-2
ii  lsb-base  9.20170808

lxcfs recommends no packages.

lxcfs suggests no packages.

-- no debconf information

Bug#913645: Oldstable also affected

2018-11-18 Thread Carsten Schoenert

Control: severity -1 grave

Hello Bastian,

Am 18.11.18 um 23:01 schrieb Bastian Neuburger:
> severity: critical
> 
> Dear Maintainer,
> 
> since I had an oldstable system with a key3.db around I also checked the 
> behaviour there.

this is not differing between the Debian releases(, unfortunately).
Debian hasn't touched any code here.

> I upgraded from
> thunderbird:amd64 (52.9.1-1~deb8u1, 60.3.0-1~deb8u1)
> and encountered the same situation:
> 
> I couldn't decrypt messages anymore.
> Before trying to decrypt an encrypted message, my certificate was still 
> visible in the "Your certificates" tab, after failing to display/decrypt 
> an encrypted message it is no longer visible.
> 
> I checked key4.db before this and I got the following output:
> 
> Enter ".help" for usage hints.
> sqlite> .tables
> nssPrivate
> sqlite> select * from nssPrivate;
> sqlite>
> 
> Also think the severity of this bug is critical since it causes severe 
> data loss (private key gone: encrypted data gone).

No, it's not critical but grave.

https://www.debian.org/Bugs/Developer#severities

> Please let me know if you have further questions.

First we/you need to check please if this behavior is also existing in
the upstream binaries. To check this you can simply download the
pre-compiled binary and start the thunderbird binary from that archive.

amd64
http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-x86_64/

i386
http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-i686/

If the issue is also existing here then this needs to be reported to the
Mozilla bugtracker and this report needs to be tagged to follow that report.

https://bugzilla.mozilla.org/

-- 
Regards
Carsten Schoenert

Bug#914075: julia-vim/0.0+git20181115.ef55a5-1 [QA]

2018-11-18 Thread Mo Zhou

Hi Paulo,

What does this bug mean? We (Debian Julia Team) are maintaining the
vim-julia package, and it has been waiting in the NEW queue.

https://salsa.debian.org/julia-team/vim-julia
https://ftp-master.debian.org/new/vim-julia_0.0~git20180821.120a0b6-1.html

On Mon, Nov 19, 2018 at 12:17:13AM -0200, Paulo Henrique de Lima Santana wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-CC: mike.gabr...@das-netzwerkteam.de
> 
> Hi, 
> 
> Please **don't sponsor and upload** this package because my AM (Mike Gabriel)
> will review it for me.
> 
>  * Package name: julia-vim
>Version : 0.0+git20181115.ef55a5-1
>Upstream Author : Carlo Baldassi 
>  * URL : https://github.com/JuliaEditorSupport/julia-vim
>  * License : MIT
>Section : editors
> 
> It builds this binary packages:
> 
>   julia-vim - vim plugin for programming in Julia
> 
> To access further information about these packages, please visit the
> following URL:
> 
> https://mentors.debian.net/package/julia-vim
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/j/julia-vim/julia-vim_0.0+git20181115.ef55a5-1.dsc
> 
> More information about kickpass can be obtained from
> https://github.com/JuliaEditorSupport/julia-vim
> 
> Best regards,
> 
> -- 
> Paulo Henrique de Lima Santana (phls)
> Curitiba - Brasil
> Membro da Comunidade Curitiba Livre
> Site: http://www.phls.com.br
> GNU/Linux user: 228719  GPG ID: 0443C450
> 
> Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
> http://www.heforshe.org/pt

Bug#914055: [pkg-go] Bug#914055: gitaly: misses versioned dependency on gitaly-proto (and probably more)

2018-11-18 Thread Pirate Praveen

Control: reassign -1 golang-gitaly-proto

On 2018, നവംബർ 19 2:20:39 AM IST, Paul Gevers  wrote:
>Dear maintainers,
>
>With a recent upload of gitlab the autopkgtest of gitaly fails in
>testing when that autopkgtest is run with the binary packages of gitlab
>from unstable. It passes when run with only packages from testing. In
>tabular form:
>   passfail
>gitlab from testing11.1.8+dfsg-2
>gitaly from testing0.100.1+debian2-1
>versioned deps [0] from testingfrom unstable
>all others from testingfrom testing
>
>I copied some of the output at the bottom of this report. If I
>understand the error message correctly, the failure is due to the fact
>that gitaly-proto from testing isn't found. None of our tools is aware
>that gitaly-proto version 0.99.0 is a dependency of gitaly 0.100.1
>because that dependency isn't declared in the regular way. If I further
>read the output of a passing autopkgtest, I fear that there are quite a
>few more packages that need documenting.
>
>Currently this regression is contributing to the delay of the migration
>of gitlab to testing [1], although that may "fix" itself once
>gitaly/0.111.4+debian-2 and golang-gitaly-proto/0.105.0+dfsg-2 migrate
>to testing in a couple of days.
>
>If this is a real problem in your package (and not only in your
>autopkgtest), the right binary package(s) from gitlab should really add
>a versioned Breaks on the unfixed version of (one of your) package(s).
>Note: the Breaks is nice even if the issue is only in the autopkgtest
>as
>it helps the migration software to figure out the right versions to
>combine in the tests.

Breaks should be in golang-gitaly-proto which builds ruby-gitaly (which 
provides gitaly-proto lib).

>PS: I'd like to let you know that an autopkgtest that only contains a
>no-op test (that just installs a package) is NOT wanted by the release
>team. It appears to me that your test doesn't do anything that isn't
>already done during installation (the logs are the same). Please add
>testcases that really use your installed package in any way, or drop
>your autopkgtest. We have piuparts testing to check for installability
>issues.

autopkgtest helps find dependency issues before a reverse dependency is 
uploaded. With long dependency chain, gitlab often fails to install when 
uncoordinated upload happens, so it is useful.

Also it is in my to do list to add functional tests.

>[0] You can see what packages were added from the second line of the
>log
>file quoted below. The migration software adds source package from
>unstable to the list if they are needed to install packages from
>gitlab/11.1.8+dfsg-2. I.e. due to versioned dependencies or
>breaks/conflicts.
>[1] https://qa.debian.org/excuses.php?package=gitlab
>
>https://ci.debian.net/data/autopkgtest/testing/amd64/g/gitaly/1330154/log.gz
>
>Setting up gitaly (0.100.1+debian2-1) ...
>[31mCould not find gem 'gitaly-proto (~> 0.99.0)' in any of the gem
>sources listed
>in your Gemfile.[0m
>dpkg: error processing package gitaly (--configure):
> installed gitaly package post-installation script subprocess returned
>error exit status 7
>dpkg: dependency problems prevent configuration of autopkgtest-satdep:
> autopkgtest-satdep depends on gitaly; however:
>  Package gitaly is not configured yet.
>
>dpkg: error processing package autopkgtest-satdep (--configure):
> dependency problems - leaving unconfigured
>Processing triggers for libc-bin (2.27-8) ...
>Processing triggers for ca-certificates (20170717) ...
>Updating certificates in /etc/ssl/certs...
>0 added, 0 removed; done.
>Running hooks in /etc/ca-certificates/update.d...
>done.
>Processing triggers for systemd (239-11) ...
>Errors were encountered while processing:
> gitaly

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#914081: stretch-pu: package jdupes/1.7-2

2018-11-18 Thread Joao Eriberto Mota Filho

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

>From the jdupes upstream:

"All versions from 1.5.1 up to 1.7 have potentially serious bugs in the
internal memory allocator which caused crashes on Debian ARM and macOS
Sierra. These should be updated to a minimum of v1.8 if at all possible.

If that isn't possible, the following commits improving/fixing the internal
memory allocator should be patched into the old versions:

e2bebfdbadd0474a6b5f16f46ce1b48201d75150
78e06c3eb1f1cfdebf8ca555f5c699b69b3a9aad
1f2fe4a0c1bca7486cfc5aa84877246e90d1321a
1498a04e2ad5ba6cef6e94c5f64408d35670f7b8"

This upload will close #914078

Thanks in advance.

Regards,

Eriberto
diff -Nru jdupes-1.7/debian/changelog jdupes-1.7/debian/changelog
--- jdupes-1.7/debian/changelog 2017-02-06 22:19:51.0 -0200
+++ jdupes-1.7/debian/changelog 2018-11-19 00:10:16.0 -0200
@@ -1,3 +1,10 @@
+jdupes (1.7-2+deb9u1) stretch; urgency=medium
+
+  * debian/patches/20_fix-crash-arm.patch: add to fix a potential crash in
+ARM. Thanks to Jody Bruchon . (Closes: #914078)
+
+ -- Joao Eriberto Mota Filho   Mon, 19 Nov 2018 00:10:16 
-0200
+
 jdupes (1.7-2) unstable; urgency=medium
 
   * debian/patches/10_fix-segfault.patch: added to fix a segmentation fault in
diff -Nru jdupes-1.7/debian/patches/20_fix-crash-arm.patch 
jdupes-1.7/debian/patches/20_fix-crash-arm.patch
--- jdupes-1.7/debian/patches/20_fix-crash-arm.patch1969-12-31 
21:00:00.0 -0300
+++ jdupes-1.7/debian/patches/20_fix-crash-arm.patch2018-11-19 
00:10:16.0 -0200
@@ -0,0 +1,250 @@
+Description: fix a potential crash in ARM.
+ From the jdupes upstream:
+
+ "All versions from 1.5.1 up to 1.7 have potentially serious bugs in the
+ internal memory allocator which caused crashes on Debian ARM and macOS
+ Sierra. These should be updated to a minimum of v1.8 if at all possible.
+
+ If that isn't possible, the following commits improving/fixing the internal
+ memory allocator should be patched into the old versions:
+
+ e2bebfdbadd0474a6b5f16f46ce1b48201d75150
+ 78e06c3eb1f1cfdebf8ca555f5c699b69b3a9aad
+ 1f2fe4a0c1bca7486cfc5aa84877246e90d1321a
+ 1498a04e2ad5ba6cef6e94c5f64408d35670f7b8
+Author: Jody Bruchon 
+Origin: upstream
+
https://github.com/jbruchon/jdupes/commit/e2bebfdbadd0474a6b5f16f46ce1b48201d75150.patch
+
https://github.com/jbruchon/jdupes/commit/78e06c3eb1f1cfdebf8ca555f5c699b69b3a9aad.patch
+
https://github.com/jbruchon/jdupes/commit/1f2fe4a0c1bca7486cfc5aa84877246e90d1321a.patch
+
https://github.com/jbruchon/jdupes/commit/1498a04e2ad5ba6cef6e94c5f64408d35670f7b8.patch
+Bug-Debian: https://bugs.debian.org/914078
+Last-Update: 2017-01-19
+--- jdupes-1.7.orig/jdupes.c
 jdupes-1.7/jdupes.c
+@@ -501,18 +501,24 @@ extern int check_conditions(const file_t
+ }
+ 
+ 
+-/* Create a new traversal check object */
+-static int travdone_alloc(struct travdone **trav, const char * const restrict 
dir)
++/* Create a new traversal check object and initialize its values */
++static struct travdone *travdone_alloc(const jdupes_ino_t inode, const dev_t 
device)
+ {
+-  *trav = string_malloc(sizeof(struct travdone));
+-  if (*trav == NULL) {
++  struct travdone *trav;
++
++  LOUD(fprintf(stderr, "travdone_alloc(%jd, %jd)\n", (intmax_t)inode, 
(intmax_t)device);)
++
++  trav = (struct travdone *)string_malloc(sizeof(struct travdone));
++  if (trav == NULL) {
+ LOUD(fprintf(stderr, "travdone_alloc: malloc returned NULL\n");)
+-return -1;
++return NULL;
+   }
+-  (*trav)->left = NULL;
+-  (*trav)->right = NULL;
+-  if (getdirstats(dir, &((*trav)->inode), &((*trav)->device)) != 0) return -1;
+-  return 0;
++  trav->left = NULL;
++  trav->right = NULL;
++  trav->inode = inode;
++  trav->device = device;
++  LOUD(fprintf(stderr, "travdone_alloc returned %p\n", (void *)trav);)
++  return trav;
+ }
+ 
+ 
+@@ -545,22 +551,23 @@ static void grokdir(const char * const r
+   LOUD(fprintf(stderr, "grokdir: scanning '%s' (order %d)\n", dir, 
user_dir_count));
+ 
+   /* Double traversal prevention tree */
++  if (getdirstats(dir, , ) != 0) goto error_travdone;
+   if (travdone_head == NULL) {
+-if (travdone_alloc(_head, dir) != 0) goto error_travdone;
++travdone_head = travdone_alloc(inode, device);
++if (travdone_head == NULL) goto error_travdone;
+   } else {
+-if (getdirstats(dir, , ) != 0) goto error_travdone;
+ traverse = travdone_head;
+ while (1) {
+   /* Don't re-traverse directories we've already seen */
+   if (inode == traverse->inode && device == traverse->device) {
+ LOUD(fprintf(stderr, "already seen dir '%s', skipping\n", dir);)
+ return;
+-  }
+-  if (inode >= traverse->inode) {
++  } else if (inode > traverse->inode || (inode == traverse->inode && 
device > traverse->device)) {
+ /* Traverse right */
+ if (traverse->right == NULL) {
+   LOUD(fprintf(stderr,

Bug#913896:

2018-11-18 Thread A. Jesse Jiryu Davis

I'm a libbson maintainer, and I believe this is only a minor bug, not
a grave vulnerability.

The bug is triggered when libbson reads BSON data corrupted in a
specific manner. The faulty logic will read up to 4 bytes past the end
of a buffer.

This is not a grave vulnerability for two reasons. First, applications
use libbson to read BSON data from trusted sources, either a MongoDB
server or the local file system, not from untrusted sources. We do not
consider a MongoDB server or a filesystem under malicious control to
be an attack vector that we can secure libbson against. Second, when
libbson reads past the end of the buffer, it does nothing with the
data it read: it considers it part of an unstructured binary blob. It
does no further parsing of the data and does not use that data in any
conditional statements or use it as a pointer, so it does not provide
a mechanism for remote code execution or any other type of attack.

Bug#914080: med-fichier: autopkgtest fails with ld --as-needed

2018-11-18 Thread Logan Rosen

Package: med-fichier
Version: 3.3.1+repack-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

The new autopkgtest tests in med-fichier fail to run with ld
--as-needed, which is the default in Ubuntu.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/t/build{1,2}: Move -lmedC after file that needs it to fix failure with
ld --as-needed.

Thanks for considering the patch.

Logan Rosen

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

Kernel: Linux 4.18.0-10-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru med-fichier-3.3.1+repack/debian/tests/build1 
med-fichier-3.3.1+repack/debian/tests/build1
--- med-fichier-3.3.1+repack/debian/tests/build12018-07-08 
11:20:02.0 -0400
+++ med-fichier-3.3.1+repack/debian/tests/build12018-11-18 
21:34:17.0 -0500
@@ -217,7 +217,7 @@
 
 EOF
 
-mpicc -I/usr/include/hdf5/openmpi/ -I/usr/include/hdf5/serial -I/usr/include 
-lmedC  -o usescase usescase.c
+mpicc -I/usr/include/hdf5/openmpi/ -I/usr/include/hdf5/serial -I/usr/include 
-o usescase usescase.c -lmedC
 echo "build: OK"
 [ -x usescase ]
 ./usescase
diff -Nru med-fichier-3.3.1+repack/debian/tests/build2 
med-fichier-3.3.1+repack/debian/tests/build2
--- med-fichier-3.3.1+repack/debian/tests/build22018-07-08 
11:20:13.0 -0400
+++ med-fichier-3.3.1+repack/debian/tests/build22018-11-18 
21:34:32.0 -0500
@@ -431,7 +431,7 @@
 
 EOF
 
-mpicc -I/usr/include/hdf5/openmpi/ -I/usr/include/hdf5/serial -I/usr/include 
-lmedC  -o usescase usescase.c
+mpicc -I/usr/include/hdf5/openmpi/ -I/usr/include/hdf5/serial -I/usr/include 
-o usescase usescase.c -lmedC
 echo "build: OK"
 [ -x usescase ]
 ./usescase

Bug#914079: Obsolete conffile /etc/dbus-1/system.d/org.kde.kcontrol.kcmkwallet.conf not removed/renamed on upgrades

Package: kwalletmanager
Version: 4:18.04.1-1
Severity: important
File: /etc/dbus-1/system.d/org.kde.kcontrol.kcmkwallet.conf

The file /etc/dbus-1/system.d/org.kde.kcontrol.kcmkwallet.conf
is no longer shipped by the kwalletmanager package and now marked as an
obsolete conffile
Apparently the file was renamed to
/etc/dbus-1/system.d/org.kde.kcontrol.kcmkwallet5.conf

You should either rename the conffile as part of the upgrade process or
remove the old conffile.
Please see man dh_installdeb / dpkg-maintscript-helper on how to
properly rename/remove a conffile.

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

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

Versions of packages kwalletmanager depends on:
ii  kio   5.51.0-1
ii  libc6 2.27-8
ii  libkf5archive55.51.0-1
ii  libkf5auth5   5.51.0-1
ii  libkf5codecs5 5.51.0-1
ii  libkf5configcore5 5.51.0-1
ii  libkf5configwidgets5  5.51.0-1
ii  libkf5coreaddons5 5.51.0-1
ii  libkf5crash5  5.51.0-1
ii  libkf5dbusaddons5 5.51.0-1
ii  libkf5i18n5   5.51.0-1
ii  libkf5iconthemes5 5.51.0-1
ii  libkf5itemviews5  5.51.0-1
ii  libkf5jobwidgets5 5.51.0-1
ii  libkf5kiocore55.51.0-1
ii  libkf5notifications5  5.51.0-1
ii  libkf5service-bin 5.51.0-1
ii  libkf5service55.51.0-1
ii  libkf5wallet-bin  5.51.0-1
ii  libkf5wallet5 5.51.0-1
ii  libkf5widgetsaddons5  5.51.0-1
ii  libkf5xmlgui5 5.51.0-1
ii  libqt5core5a  5.11.2+dfsg-6
ii  libqt5dbus5   5.11.2+dfsg-6
ii  libqt5gui55.11.2+dfsg-6
ii  libqt5widgets55.11.2+dfsg-6
ii  libqt5xml55.11.2+dfsg-6
ii  libstdc++68.2.0-9

kwalletmanager recommends no packages.

kwalletmanager suggests no packages.

-- no debconf information

Bug#914078: jdupes: crashes on ARM

2018-11-18 Thread Joao Eriberto Mota Filho

Package: jdupes
Version: 1.7-2
Severity: important
Tags: upstream

>From the jdupes upstream:

"All versions from 1.5.1 up to 1.7 have potentially serious bugs in the
internal memory allocator which caused crashes on Debian ARM and macOS
Sierra. These should be updated to a minimum of v1.8 if at all possible.

If that isn't possible, the following commits improving/fixing the internal
memory allocator should be patched into the old versions:

e2bebfdbadd0474a6b5f16f46ce1b48201d75150
78e06c3eb1f1cfdebf8ca555f5c699b69b3a9aad
1f2fe4a0c1bca7486cfc5aa84877246e90d1321a
1498a04e2ad5ba6cef6e94c5f64408d35670f7b8

While we're cherry-picking, I'd also suggest pulling in this revision that
respects $(PROGRAM_NAME) in the Makefile:

26b85e826f861f5d472c09b56e07e465b63bf1c9"

Thanks to Jody Bruchon


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

Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jdupes depends on:
ii  libc6  2.24-11+deb9u3

jdupes recommends no packages.

jdupes suggests no packages.

-- no debconf information

Bug#914077: Obsolete conffile /etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf not properly removed on upgrades

Package: k3b-data
Version: 18.08.1-1
Severity: normal
File: /etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf

/etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf is no longer shipped
by k3b-data and  now marked as an obsolete conffile.
It should be removed on upgrades.

The simplest way to to that is via a .maintscript file.
See dh_installdeb.


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

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

-- no debconf information

Bug#914074: ln: failed to create symbolic link '/sbin/iptables': File exists

2018-11-18 Thread Thorsten Glaser

On Mon, 19 Nov 2018, Thorsten Glaser wrote:

> Setting up iptables (1.8.2-1) ...
> ln: failed to create symbolic link '/sbin/iptables': File exists
> dpkg: error processing package iptables (--configure):
>  installed iptables package post-installation script subprocess returned 
> error exit status 1

Cause:

/usr/sbin/iptables also does not exist, while the symlink /sbin/iptables
already exists.

-e is *not* the right test for symlink existence in shell!

This is two bugs, then. The absence of iptables from the iptables
package (which probably ought to be grave) and the symlink check bug.

Bug#914076: Obsolete conffile /etc/bash_completion.d/cowbuilder not removed on upgrades

Package: cowbuilder
Version: 0.87+b1
Severity: normal
File: /etc/bash_completion.d/cowbuilder

cowbuilder now ships the bash-completion file as
/usr/share/bash-completion/completions/cowbuilder

The obsolete conffile /etc/bash_completion.d/cowbuilder should properly
be removed on upgrades though.

The simples way to do that is using a cowbuilder.maintscript.
See man dh_installdeb.


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

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

Versions of packages cowbuilder depends on:
ii  cowdancer0.87+b1
ii  libc62.27-8
ii  libncurses6  6.1+20181013-1
ii  libtinfo66.1+20181013-1
ii  pbuilder 0.230.1

cowbuilder recommends no packages.

cowbuilder suggests no packages.

-- no debconf information

Bug#914075: julia-vim/0.0+git20181115.ef55a5-1 [QA]

2018-11-18 Thread Paulo Henrique de Lima Santana

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: mike.gabr...@das-netzwerkteam.de

Hi, 

Please **don't sponsor and upload** this package because my AM (Mike Gabriel)
will review it for me.

 * Package name: julia-vim
   Version : 0.0+git20181115.ef55a5-1
   Upstream Author : Carlo Baldassi 
 * URL : https://github.com/JuliaEditorSupport/julia-vim
 * License : MIT
   Section : editors

It builds this binary packages:

  julia-vim - vim plugin for programming in Julia

To access further information about these packages, please visit the
following URL:

https://mentors.debian.net/package/julia-vim

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

  dget -x
https://mentors.debian.net/debian/pool/main/j/julia-vim/julia-vim_0.0+git20181115.ef55a5-1.dsc

More information about kickpass can be obtained from
https://github.com/JuliaEditorSupport/julia-vim

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgpePSRZjLFax.pgp
Description: PGP signature

Bug#914074: ln: failed to create symbolic link '/sbin/iptables': File exists

2018-11-18 Thread Thorsten Glaser

Package: iptables
Version: 1.8.2-1
Severity: serious
Justification: not installable

Setting up iptables (1.8.2-1) ...
ln: failed to create symbolic link '/sbin/iptables': File exists
dpkg: error processing package iptables (--configure):
 installed iptables package post-installation script subprocess returned error 
exit status 1


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages iptables depends on:
ii  libc62.27-8
ii  libip4tc01.8.2-1
ii  libip6tc01.8.2-1
ii  libiptc0 1.8.2-1
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl71.1.1-1
ii  libxtables12 1.8.2-1

iptables recommends no packages.

Versions of packages iptables suggests:
ii  kmod  25-2

-- no debconf information

Bug#914073: RM: mailping -- RoQA; no upstream, python 2, low popcon, non-working package

2018-11-18 Thread gustavo panizzo

Package: ftp.debian.org
Severity: normal

Hello FTP team

I request the removal of the package mailping

The package has no upstream, it only works with Python2, it has a low
popcon number and it hasn't worked for, at least, 3 years.

The current version in Stretch is non-functional and nobody noticed it
since May 2015, I fixed some issues with my QA upload to unstable in
September 2018 but the code needs further work to make it work properly.

I've CCed the original and latest maintainer of the package to this bug
to give them a chance to reply.

thanks!

Bug#914072: python2.7: Version name 2.7.15+ is not accepted by some tools

2018-11-18 Thread Stephen Swatman

Package: python2.7
Version: 2.7.15-4
Severity: normal

Recently, the version number of the Python 2.7 package appears to have been 
changed to "2.7.15+". I've experienced trouble with tools not accepting this
as a valid version number. In particular, the popular tool "pipenv" relies on
a library called "pythonfinder" which rejects "2.7.15+" as a valid version
number, rendering pipenv unusable.

I am no expert in Python version numbering but PEP 0440 describes the format
for version numbers. While "+" is mentioned in this PEP as a way to add a
local version label, I believe the document assumes that the plus is
followed by some non-empty string.

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

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

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.15-4
ii  mime-support 3.61
ii  python2.7-minimal2.7.15-4

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.31.1-7
pn  python2.7-doc  

-- no debconf information

Bug#914065: nheko FTBFS: Could not find a package configuration file provided by "MatrixClient"

2018-11-18 Thread Axel Beckert

Hi,

Adrian Bunk wrote:
> ...
> Build type set to 'RelWithDebInfo'
> -- Version: 0.6.1
> -- Boost version: 1.67.0
> -- Found the following Boost libraries:
> --   atomic
> --   chrono
> --   date_time
> --   iostreams
> --   random
> --   regex
> --   system
> --   thread
> -- Found ZLIB: /usr/lib/aarch64-linux-gnu/libz.so (found version "1.2.11") 
> -- Found OpenSSL: /usr/lib/aarch64-linux-gnu/libcrypto.so (found version 
> "1.1.1")  
> CMake Error at CMakeLists.txt:251 (find_package):
>   By not providing "FindMatrixClient.cmake" in CMAKE_MODULE_PATH this project
>   has asked CMake to find a package configuration file provided by
>   "MatrixClient", but CMake did not find one.
> 
>   Could not find a package configuration file provided by "MatrixClient"
>   (requested version 0.1.0) with any of the following names:
> 
> MatrixClientConfig.cmake
> matrixclient-config.cmake

The cause for this might be much earlier:

[...]
-- Boost version: 1.67.0
-- Found the following Boost libraries:
--   atomic
--   chrono
--   date_time
--   iostreams
--   random
--   regex
--   system
--   thread
CMake Warning at CMakeLists.txt:200 (export):
  Cannot create package registry file:


/sbuild-nonexistent/.cmake/packages/MatrixClient/217899eff9ecbd2457b9e7580f99b5aa

  No such file or directory



-- Configuring done
-- Generating done
[...]

At least it's very suspicious that a build tries to write to a user's
home directory (which does not exist on purpose on build daemons). So
CMake not finding such a package file could be a result of not being
able to create a file (or directory) containing ".cmake/packages/" in
its path.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#914071: RM: networking-ovs-dpdk -- RoM; RoQA; outdated, doesn't work in current Debian

2018-11-18 Thread Jeremy Bicha

Package: ftp.debian.org
X-Debbugs-Cc: networking-ovs-d...@packages.debian.org
Affects: src:networking-ovs-dpdk
Control: block 897022 by -1
Control: tags 897022 -moreinfo
Control: unblock 897022 by 882268

Please remove networking-ovs-dpdk since it is the last thing blocking
the removal of the unmaintained python-tempest-lib.

networking-ovs-dpdk was removed from Testing a year ago because it
couldn't build from source. According to Thomas Goirand, it doesn't
work anyway since it needs dpdk support in OVS. And it would need work
to be compatible with the OpenStack release targeted for Buster.

I am filing this bug on behalf of Thomas based on comment 15 of
https://bugs.debian.org/897022

The build failure bug is https://bugs.debian.org/882268

Thanks,
Jeremy Bicha

Bug#914070: ITS: dhcpcd5

2018-11-18 Thread Scott Leggett

Package: dhcpcd5
Severity: important

Hi,

I would like to see active maintenance of this package so I'm offering
to salvage and maintain the package if the current maintainer is no
longer interested. Apologies in advance if that is not the case.

Here is my assessment of package salvage eligibility[0]:

  * Package recently removed from testing due to #846938, then fixed and
re-entered testing via NMU[1].
  * Package many releases behind upstream prior to the recent NMU.
  * Last maintainer upload April 2016[1].
  * No replies to bugs on this package since last maintainer upload.
  * A couple of QA issues on package[1]

Regards,
Scott.

[0] 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#ps-eligibility
[1] https://tracker.debian.org/pkg/dhcpcd5
[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=dhcpcd5

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

Versions of packages dhcpcd5 depends on:
ii  libc6  2.24-11+deb9u3

Versions of packages dhcpcd5 recommends:
ii  resolvconf  1.79

Versions of packages dhcpcd5 suggests:
pn  dhcpcd-gtk  

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#913930: lintian: Potentially false-positive public-upstream-key-unusable upstream/signing-key.asc

2018-11-18 Thread Pierre-Elliott Bécue

Le 19 novembre 2018 00:56:42 GMT+01:00, Felix Lechner 
 a écrit :
>Hi Pierre-Elliott,
>
>Looks like the call to 'gpg --list-packets' failed, but I cannot
>reproduce the issue. Your report mentioned lintian 2.5.112~bpo9+1 and
>stable, while the build log was for lintian 2.5.112 on experimental.
>With which release are you working, please? Thank you!
>
>Kind regards,
>Felix Lechner

The build chroot I used wat under experimental, indeed. But I made the report 
with the host, which is under stretch + some bpo. As the versions are looking 
alike I didn't bother to mention it.

Sorry!

Cheers, 
-- 
PEB

Bug#913944: flare-game: Loosing skill on load / level up / death

2018-11-18 Thread Manuel A. Fernandez Montecelo

Control: tags -1 + fixed-upstream

Hi,

Em sáb, 17 de nov de 2018 às 12:06, Philipp Klaus Krause  
escreveu:
>
> Package: flare-game
> Version: 1.07-1
> Severity: normal
> Tags: upstream
>
> In 1.07, when wearing an item that gives a skill bonus, this bonus is
> subtracted permanently from a random skill each time a character levels up,
> dies or a savegame is loaded.
> This makes such items pretty much unuseable; for unsuspecting players they can
> quickly make a character equipped with such items unplayable.
>
> This bug is fixed in the 1.08 upstream release.

Right, thanks.

1.08 has been out for a while already, do you know if there are other
fixes worth including, or if 1.09 is imminent?


Cheers.
-- 
Manuel A. Fernandez Montecelo

Bug#913930: lintian: Potentially false-positive public-upstream-key-unusable upstream/signing-key.asc

2018-11-18 Thread Felix Lechner

Hi Pierre-Elliott,

Looks like the call to 'gpg --list-packets' failed, but I cannot
reproduce the issue. Your report mentioned lintian 2.5.112~bpo9+1 and
stable, while the build log was for lintian 2.5.112 on experimental.
With which release are you working, please? Thank you!

Kind regards,
Felix Lechner

Bug#908050: lxc: Please drop recommends on bridge-utils

2018-11-18 Thread Pierre-Elliott Bécue

Hi,

Le mercredi 05 septembre 2018 à 15:36:01+0200, Andreas Henriksson a écrit :
> Source: lxc
> Version: 1:2.0.9-6
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I've tried investigating why lxc has a Recommends: bridge-utils, but
> unfortunately haven't found anything information why it's there or
> why it was added initially.

Because it's a quite classic thing to use a bridge to bind a container on
the host's physical interface in order to provide it some network access,
although there's other solutons.

> I can only find usage of the 'brctl' command in:
> 1: ./templates/lxc-gentoo.in
> 2: ./src/tests/lxc-test-usernic.in
> 
> The second one seems to only conditionally be installed on ubuntu
> according to src/tests/Makefile.am, so not relevant. I'm not sure how
> relevant the first one is either, but I'll include a trivial (untested)
> patch you can drop into debian/patches if you'd like it to use bridge
> (from iproute2) instead.
>
> I hope this means bridge-utils can be dropped (or replaced by iproute2
> if needed). If you know of any reason not to drop bridge-utils I'd like
> to hear about it!

.-(0:38:20)-(~)-(peb@pimeys)-
`--[255]-> sudo ip l add toto type bridge

.-(0:38:29)-(~)-(peb@pimeys)-
`---> sudo ip l set dev toto up

.-(0:38:49)-(~)-(peb@pimeys)-
`---> sudo bridge link show
[nothing]
.-(0:38:52)-(~)-(peb@pimeys)-
`---> sudo brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.   no
toto8000.   no

bridge link remains a mistery to me, and I failed to use it in any relevant
way.

That said, you're right, one could use iproute2, as ip link show type bridge
works perfectly fine to list bridges, and ip link is actually able to manage
bridges as well as brctl.

That said, I'm not sure at all that removing any recommendation to
bridge-utils is a fine idea. The number of people not aware of the fact that
ip link does the same job is quite high.

I'm open to discussion on it, of course. I added iproute2 as a
Recommend for lxc 3.0.2-1~exp+3 (3.0.2-1~exp+2 is in experimental for now,
+3 will follow at some point), but without removing bridge-utils yet.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#769541: Dato: 18.11.2018

2018-11-18 Thread David Edward John R

Dato: 18.11.2018
  
Jeg har et fortroligt forretningsforslag til dig, som er et betydeligt beløb 
værd (13,5 mio. GBP). Hvis du er interesseret, svar tilbage via nedenstående 
e-mail for flere detaljer.
 
Bemærk: Hvis du kan tale eller skrive på engelsk, svar venligst på engelsk for 
bedre kommunikation.
 
Med venlig hilsen
Sir David Edward John R.
Vicedirektør
Markeder og bankvirksomhed,
Bank of England.
Tlf .: 075 4328 2201
E-mail: dvr...@gmx.com
__
Sekretær: Fru Anne Gerard

Bug#890517: killer's CRON logs out users once per hour

2018-11-18 Thread Petter Reinholdtsen

[Wolfgang Schweer]
> Mike, could you test this change to killer (might be smarter, some one 
> w/ Perl skills should check it:

I had a look at the patch, and it is not obviously wrong, at least.  I do
not know the code well any more, but did test and read it, and it might
work.  I do not have x2go myself, so I can not test that part, though.

-- 
Happy hacking
Petter Reinholdtsen

Bug#847096: Bug#905230: elfutils: FTBFS on x32 due to bugs in testsuite

2018-11-18 Thread Kurt Roeckx

On Thu, Aug 02, 2018 at 11:11:24PM +0200, Thorsten Glaser wrote:
> 
> Given #847096 it might be wise to just *always* disable the biarch stuff
> since Debian does not normally use biarch *anyway*, and since we test it
> on all architectures during their native build anyway.

I'm not conviced that that is a good solution. Elfutils supports
many different backends at the same time. You disable a test that
tests part of that functionality.

The only thing I've seen here so far is a setup that breaks
elfutils' test suite. As far as I understand, it's perfectly
possible to build the x32 version.

Kurt

Bug#914013: perl: missing-depends-on-sensible-utils

2018-11-18 Thread Dominic Hargreaves

On Sun, Nov 18, 2018 at 04:05:43PM +0200, Niko Tyni wrote:
> Package: perl
> Version: 5.28.0-3
> 
> As prompted by lintian:
> 
> E: libperl-dev: missing-depends-on-sensible-utils 
> usr/lib/x86_64-linux-gnu/libperl.a
> E: perl-modules-5.28: missing-depends-on-sensible-utils 
> usr/share/perl/5.28.0/Pod/Perldoc/ToTerm.pm
> E: libperl5.28: missing-depends-on-sensible-utils 
> usr/lib/x86_64-linux-gnu/libperl.so.5.28.0
> E: libperl5.28: missing-depends-on-sensible-utils 
> usr/lib/x86_64-linux-gnu/perl/5.28.0/CORE/patchlevel-debian.h
> E: libperl5.28: missing-depends-on-sensible-utils 
> usr/lib/x86_64-linux-gnu/perl/5.28.0/Config_heavy.pl
> E: perl-base: missing-depends-on-sensible-utils usr/bin/perl
> E: perl-base: missing-depends-on-sensible-utils usr/bin/perl5.28.0
> E: perl-base: missing-depends-on-sensible-utils 
> usr/lib/x86_64-linux-gnu/perl-base/Config_heavy.pl
> E: perl-debug: missing-depends-on-sensible-utils usr/bin/debugperl
> 
> This is a result of us building with -Dpager=/usr/bin/sensible-pager,
> which ends up in the binary files, and patching Pod::Perldoc::ToTerm
> to treat sensible-pager like 'less'. (The lintian check simply looks
> for relevant strings in the binary packages, skipping /usr/share/doc
> and /usr/share/locale.)
> 
> It looks to me like
> 
> - patchlevel-debian.h, libperl.{a,so} and the statically linked binaries
>   only have sensible-pager in a patch description, so false positives
> 
> - the Pod::Perldoc::ToTerm changes in debian/perldoc-pager.diff don't
>   imply any kind of dependency on sensible-pager, so a false positive
> 
> The only relevant hit is Config_heavy.pl. The implied dependency (perl
> default pager) should IMO be at most a recommendation, though I'd lean
> on the side of a suggestion.
> 
> So I propose we fix this by adding Suggests: sensible-utils in perl-base
> and libperl5.28, and overriding the rest.
> 
> Thoughts?

Sounds good to me!

Bug#912819: llvm-toolchain-7: FTBFS on hurd-i386




Le 18/11/2018 à 22:44, Samuel Thibault a écrit :

Sylvestre Ledru, le dim. 18 nov. 2018 20:48:00 +0100, a ecrit:

Le 18/11/2018 à 14:09, Samuel Thibault a écrit :

FI, here are the patches I am currently using to get the package built.
D54378 and 54379 are still being discussed upstream, and the last two
still need to be cleaned and submitted upstream.

Would be nice if you could do a MR on salsa!

You mean before it's merged upstream?


if you want this in 7 :)

Bug#913930: lintian: Potentially false-positive public-upstream-key-unusable upstream/signing-key.asc

2018-11-18 Thread Chris Lamb

tags 913930 + moreinfo
thanks

Pierre-Elliott Bécue wrote:

> lxc source: public-upstream-key-unusable upstream/signing-key.asc cannot
> be processed

Felix, any insight here?


Regards,

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

Bug#913974: lintian: warn against direct access to the dpkg database from upstream code

2018-11-18 Thread Chris Lamb

tags 913974 + pending
thanks

Hi Guillem,

> to emit tags, as the bulk of the offending accesses are being
> done from upstream code.

I somehow missed this bit in your followup; sorry about that.
Anyway this is now implemented in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/b09c17bd8e29f57a2b0570ae4c6af43337c65e6a

  checks/files.desc  | 29 ++
  checks/files.pm| 27 
  checks/scripts.desc| 28 -
  data/scripts/maintainer-script-bad-command |  2 --
  debian/changelog   |  4 +++
  .../debian/files-uses-dpkg-database-directly.docs  |  2 ++
  .../files-uses-dpkg-database-directly.install  |  4 +++
  .../debian/test-1  |  9 +++
  .../debian/test-2  |  3 +++
  t/tests/files-uses-dpkg-database-directly/desc |  5 
  t/tests/files-uses-dpkg-database-directly/tags |  2 ++
  t/tests/legacy-maintainer-scripts/desc |  2 +-
  t/tests/legacy-maintainer-scripts/tags |  4 +--
  t/tests/scripts-maintainer-general/desc|  3 +--
  t/tests/scripts-maintainer-general/tags|  9 +--
  15 files changed, 90 insertions(+), 43 deletions(-)


Regards,

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

Bug#913645: Oldstable also affected

2018-11-18 Thread Bastian Neuburger


severity: critical

Dear Maintainer,

since I had an oldstable system with a key3.db around I also checked the 
behaviour there.


I upgraded from
thunderbird:amd64 (52.9.1-1~deb8u1, 60.3.0-1~deb8u1)
and encountered the same situation:

I couldn't decrypt messages anymore.
Before trying to decrypt an encrypted message, my certificate was still 
visible in the "Your certificates" tab, after failing to display/decrypt 
an encrypted message it is no longer visible.


I checked key4.db before this and I got the following output:

Enter ".help" for usage hints.
sqlite> .tables
nssPrivate
sqlite> select * from nssPrivate;
sqlite>

Also think the severity of this bug is critical since it causes severe 
data loss (private key gone: encrypted data gone).


Please let me know if you have further questions.

Kind regards,

Bastian

Bug#914069: rkhunter: Script directly accesses internal dpkg database

2018-11-18 Thread Guillem Jover

Source: rkhunter
Source-Version: 1.4.6-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script that directly access the dpkg internal
database [S], instead of using the correct public interface
«dpkg --verify» (note that it currently does not return an error exit
code when it finds modified files, that will be fixed in 1.19.3, but
you can always just check the output). If the code also needs to check
whether the package is installed it could use something like
«dpkg-query --showformat='${db:Status-Status}' --show PKGNAME» (or use
a format of '${binary:Package} ${db:Status-Status}\n' and then pass no
package name to get all packages).

  [S] files/rkhunter

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913952: python-xarray: empty package when only python3 version is python3.7

2018-11-18 Thread Jeremy Bicha


From e49ee2712f5c6c35262c06fb58180c5a1506f889 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sat, 17 Nov 2018 07:22:24 -0500
Subject: [PATCH] Simplify debian/rules a bit & fix python3.7-only build

Closes: #913952
---
 debian/rules | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/debian/rules b/debian/rules
index f19fc81..5ca8c2d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,18 +15,12 @@ ifeq (,$(findstring nodoc,$(DEB_BUILD_PROFILES)))
 	$(MAKE) -C doc clean
 endif
 
-build-python%:
-	python$* setup.py build
-
 override_dh_auto_install: $(PYTHON3:%=install-python%)
 	dh_auto_install
-	rm -rf debian/python3-xarray/usr/lib/python3.7
 	find debian/python3-xarray -name '*.idx' -exec chmod -x {} \;
 
-override_dh_auto_build: export http_proxy=127.0.0.1:9
-override_dh_auto_build: export https_proxy=127.0.0.1:9
-override_dh_auto_build: $(PYTHON3:%=build-python%)
-	dh_auto_build
+override_dh_auto_build:
+	http_proxy=127.0.0.1:9 https_proxy=127.0.0.1:9 dh_auto_build
 ifeq (,$(findstring nodoc,$(DEB_BUILD_PROFILES)))
 	PYTHONPATH=$(CURDIR) $(MAKE) -C doc html
 endif
-- 
2.19.1

Bug#883851: kodi: Crash Loop when inserting Audio CD

2018-11-18 Thread Bálint Réczey

Control: reassign -1 libcdio 1.0.0-1
Control: forcemerge 763647 -1

Hi Bernhard,

Bernhard Übelacker  ezt írta (időpont: 2018.
szept. 16., V, 19:26):
>
> Hello all,
> I think this bug is a duplicate of #885606 (or vice versa).
>
> Because the stack looks quite similar, especially
> the line in libcdio.so.17 matches in both log files:
> /lib/x86_64-linux-gnu/libcdio.so.17(+0x8937)

Thanks! Merging the bugs.

Cheers,
Balint

Bug#912819: llvm-toolchain-7: FTBFS on hurd-i386

2018-11-18 Thread Samuel Thibault

Sylvestre Ledru, le dim. 18 nov. 2018 20:48:00 +0100, a ecrit:
> Le 18/11/2018 à 14:09, Samuel Thibault a écrit :
> > FI, here are the patches I am currently using to get the package built.
> > D54378 and 54379 are still being discussed upstream, and the last two
> > still need to be cleaned and submitted upstream.
> 
> Would be nice if you could do a MR on salsa!

You mean before it's merged upstream?

Samuel

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

2018-11-18 Thread Lisandro Damián Nicanor Pérez Meyer

El domingo, 18 de noviembre de 2018 18:30:48 -03 Dmitry Shachnev escribió:
> Hi Pino!
> 
> On Sun, Nov 18, 2018 at 10:19:49PM +0100, Pino Toscano wrote:
> > This is correct, but not enough.  The fix of the qhelpgenerator
> > detection works only when the cmake config module for it is installed,
> > which is shipped in qttools5-dev.  Sadly, this package is not installed
> > by all the Frameworks packages that generate QCH documentation, so
> > uploading extra-cmake-modules with the above commit will do not it
> > alone.
> > 
> > The additional fix is to add also qttools5-dev as build dependency, and
> > possibly also limit the documentation building to indep-only builds
> > (since the QCH files are shipped in arch:any -doc packages).  Imagine
> > that there are almost 80 sources of Frameworks, and 60 of them provide
> > a QCH documentation...
> 
> Ah. I tested kcoreaddons and it worked for me, but that's because it
> explicitly build-depends on qttools5-dev.
> 
> Then I will now upload qtbase with the debian/rules change I mentioned,
> it should also fix this bug.

This felt like IRC, I was trying to reply to any of your mails and got the 
following one later :-)

Paul: sorry for the useless test rebuild.

Dmitry: if I understand correctly changing to libdir-qmake should be as fine 
as the other work around, arguably even better. But let's try.

-- 
No pienses que estoy loco, es sólo una manera de actuar
  De mí - Charly García

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#913082: autopkgtest: support multi-arch test dependencies

2018-11-18 Thread Alexandre Viau

Hello,

Thank you both for working on this.

On 2018-11-18 4:22 p.m., Paul Gevers wrote:
> On 18-11-18 21:57, Martin Pitt wrote:
>> Paul Gevers [2018-11-18 21:32 +0100]:
>> Right now it's not yet clear whether
>> Alexandre needs this for proper Debian packages or just his own test runs.
> 
> So I hope he will respond.

Oh yeah I actually need this for Debian.

DXVK[1] is the package that got me asking for this. For a full DXVK
install, you would need both wine32 and wine64 installed.

There are scripts in DXVK that behave differently depending on the wine
prefix:
 - if the prefix only supports 32bit
 - if the prefix only supports 64bit
 - if the prefix supports both 32bit and 64bit

In order to get a wine prefix that supports both 32bit and 64bit, my
tests need to depend on both wine32 and wine64, which requires multi-arch.

1. https://tracker.debian.org/pkg/dxvk

Cheers,

-- 
Alexandre Viau
av...@debian.org

signature.asc
Description: OpenPGP digital signature

Bug#914068: freelan FTBFS with boost 1.67

Source: freelan
Version: 2.0-8
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=freelan=sid

...
In file included from build/release/include/freelan/configuration.hpp:62,
 from 
build/release/apps/freelan/src/configuration_helper.hpp:50,
 from 
build/release/apps/freelan/src/configuration_helper.cpp:47:
build/release/include/fscp/server.hpp:1284:4: error: invalid use of 
template-name 'boost::asio::strand' without an argument list
boost::asio::strand m_socket_strand;
^

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

2018-11-18 Thread Dmitry Shachnev

Hi Pino!

On Sun, Nov 18, 2018 at 10:19:49PM +0100, Pino Toscano wrote:
> This is correct, but not enough.  The fix of the qhelpgenerator
> detection works only when the cmake config module for it is installed,
> which is shipped in qttools5-dev.  Sadly, this package is not installed
> by all the Frameworks packages that generate QCH documentation, so
> uploading extra-cmake-modules with the above commit will do not it
> alone.
>
> The additional fix is to add also qttools5-dev as build dependency, and
> possibly also limit the documentation building to indep-only builds
> (since the QCH files are shipped in arch:any -doc packages).  Imagine
> that there are almost 80 sources of Frameworks, and 60 of them provide
> a QCH documentation...

Ah. I tested kcoreaddons and it worked for me, but that's because it
explicitly build-depends on qttools5-dev.

Then I will now upload qtbase with the debian/rules change I mentioned,
it should also fix this bug.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#914067: caffe FTBFS with boost 1.67

Source: caffe
Version: 1.0.0-8
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=caffe=sid

...
Make Warning at /usr/share/cmake-3.12/Modules/FindBoost.cmake:1743 (message):
  No header defined for python-py367; skipping header check
Call Stack (most recent call first):
  cmake/Dependencies.cmake:153 (find_package)
  CMakeLists.txt:46 (include)


-- Could NOT find Boost
CMake Warning at /usr/share/cmake-3.12/Modules/FindBoost.cmake:1743 (message):
  No header defined for python-py36; skipping header check
Call Stack (most recent call first):
  cmake/Dependencies.cmake:160 (find_package)
  CMakeLists.txt:46 (include)


-- Could NOT find Boost
CMake Warning at /usr/share/cmake-3.12/Modules/FindBoost.cmake:1743 (message):
  No header defined for python-py3; skipping header check
Call Stack (most recent call first):
  cmake/Dependencies.cmake:160 (find_package)
  CMakeLists.txt:46 (include)


-- Could NOT find Boost
CMake Warning at /usr/share/cmake-3.12/Modules/FindBoost.cmake:1743 (message):
  No header defined for python-py36; skipping header check
Call Stack (most recent call first):
  cmake/Dependencies.cmake:172 (find_package)
  CMakeLists.txt:46 (include)


-- Could NOT find Boost
-- Python interface is disabled or not all required dependencies found. 
Building without it...
-- Found Git: /usr/bin/git (found version "2.19.1") 
-- 
-- *** Caffe Configuration Summary ***
-- General:
--   Version   :   1.0.0
--   Git   :   unknown
--   System:   Linux
--   C++ compiler  :   /usr/bin/c++
--   Release CXX flags :   -O3 -DNDEBUG -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall  -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall 
-Wno-sign-compare -Wno-uninitialized
--   Debug CXX flags   :   -g -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall  -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -Wall -Wno-sign-compare -Wno-uninitialized
--   Build type:   Release
-- 
--   BUILD_SHARED_LIBS :   ON
--   BUILD_python  :   ON
--   BUILD_matlab  :   OFF
--   BUILD_docs:   OFF
--   CPU_ONLY  :   ON
--   USE_OPENCV:   ON
--   USE_LEVELDB   :   ON
--   USE_LMDB  :   ON
--   USE_NCCL  :   OFF
--   ALLOW_LMDB_NOLOCK :   OFF
-- 
-- Dependencies:
--   BLAS  :   Yes (Generic)
--   Boost :   Yes (ver. 1.67)
--   glog  :   Yes
--   gflags:   Yes
--   protobuf  :   Yes (ver. 3.6.1)
--   lmdb  :   Yes (ver. 0.9.22)
--   LevelDB   :   Yes (ver. 1.20)
--   Snappy:   Yes (ver. ..)
--   OpenCV:   Yes (ver. 3.2.0)
--   CUDA  :   No
-- 
-- Install:
--   Install path  :   /usr
-- 
-- Configuring done
CMake Error at CMakeLists.txt:104 (add_dependencies):
  The dependency target "pycaffe" of target "pytest" does not exist.


The Ubuntu diff seems to contain a fix.

Bug#914066: bum: Perl module has unused implementation accessing internal dpkg database

2018-11-18 Thread Guillem Jover

Source: bum
Source-Version: 2.5.2-1
Severity: minor
Tags: upstream
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-inert

Hi!

This package contains a perl module with an old unused implementation to
directly access the dpkg internal database [M], which it does not use
anyway as it is properly using the «dpkg-query» interface in get_pkg().
And while this is indeed not problematic at run-time, it would be nice
to cleanup to avoid triggering future checks, either manual or from
lintian.

  [M] lib/bumlib.pm:old_get_pkg()

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913082: autopkgtest: support multi-arch test dependencies

Hi Martin,

On 18-11-18 21:57, Martin Pitt wrote:
> Paul Gevers [2018-11-18 21:32 +0100]:
> Correct. That's all that there's to it -- autopkgtest itself is not supposed 
> to
> configure apt repositories or otherwise change the testbed by itself.

I was about to write "It already does with any of the --add-apt-source,
--add-apt-release, --apt-default-release, --apt-pocket, and
--pin-packages options". But than I realized those are set by the "user"
of autopkgtest. So I agree with you now.

> We can clone this to debci to enable i386 in the amd64 testbeds, if
> there is some actual demand for it.

Sure, let's see what the response below is and discuss that over at the
debci side when requested.

> Right now it's not yet clear whether
> Alexandre needs this for proper Debian packages or just his own test runs.

So I hope he will respond.

Paul

Bug#913948: segfault, apparently not always at the same location?

2018-11-18 Thread Felipe Sateler

On Sat, Nov 17, 2018 at 9:09 AM clayton  wrote:

> Package: pulseaudio
> Version: 12.2-2
> Severity: important
>
> Happens every time since a recent upgrade:
>
> $ pulseaudio --start
> E: [pulseaudio] main.c: Daemon startup failed.
>
> syslog:
> Nov 17 19:49:16 t410 kernel: [ 5309.938318] pulseaudio[9741]: segfault at
> 50 ip
> 0050 sp 7ffca06f4948 error 14 in
> pulseaudio[561dc906c000+5000]
> Nov 17 19:49:16 t410 kernel: [ 5309.938324] Code: Bad RIP value.
>
> Nov 17 19:51:30 t410 pulseaudio[9811]: Stale PID file, overwriting.
>
> Nov 17 19:52:18 t410 pulseaudio[9816]: Stale PID file, overwriting.
>
> Nov 17 19:52:18 t410 kernel: [ 5491.725943] pulseaudio[9816]: segfault at
> 21 ip
> 7fc276cb091a sp 7fff65097450 error 6 in
> libasound.so.2.0.0[7fc276ca3000+8f000]
> Nov 17 19:52:18 t410 kernel: [ 5491.725950] Code: 55 53 48 83 ec 08 48 8b
> 35 13 47 0c 00 48
> 85 ff 0f 84 0d 01 00 00 48 8b 57 20 48 8b 4f 28 48 89 fb 31 ed 48 8d 05 f6
> 46 0c 00 <48> 89
> 11 48 89 4a 08 48 39 c6 74 05 48 39 00 74 75 8b 03 85 c0 74
>

Sounds a lot like #913573 . Could you try upgrading libasound2 and
libasound2-plugins?
-- 

Saludos,
Felipe Sateler

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

2018-11-18 Thread Pino Toscano

In data domenica 18 novembre 2018 22:08:17 CET, Dmitry Shachnev ha scritto:
> Hi Lisandro and Paul!
> 
> On Sun, Nov 18, 2018 at 05:47:04PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > None of the qtbase changes should be triggering this. *But* all the packages
> > are being built with qttools5-dev-tools 5.11.2-4 instead of 5.11.2-5, and 
> > that
> > might be the issue, as the latest version contains a fix for some clang 
> > stuff:
> >
> > 
> >
> > Ideally this tests should be retried with qttools-dev-tools 5.11.2-5. Can 
> > that
> > be done? No enough build power here to try myself.
> 
> No, retrying them won’t help.
> 
> (TL;DR: we need to patch extra-cmake-modules. Extended description below.)
> 
> The failures are caused by my commit which was fixing bug #913499:
> 
> https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/44912fe676105951250e2cf5ad6c9bccf21e72cc
> 
> It broke the logic in FindQHelpGenerator.cmake, which was detecting
> qhelpgenerator using the path from location of Qt5::qmake.
> 
> Previously it was correctly detecting it in /usr/lib/qt5/bin/qhelpgenerator,
> but after the above commit it detects it in /usr/bin/qhelpgenerator which
> fails with:
> 
>   qhelpgenerator: could not find a Qt installation of ''
> 
> I see that Pino already fixed this in extra-cmake-modules upstream:
> 
> https://cgit.kde.org/extra-cmake-modules.git/commit/?id=96d169b87292d935
> 
> The best way forward will be to cherry-pick that patch in extra-cmake-modules.

This is correct, but not enough.  The fix of the qhelpgenerator
detection works only when the cmake config module for it is installed,
which is shipped in qttools5-dev.  Sadly, this package is not installed
by all the Frameworks packages that generate QCH documentation, so
uploading extra-cmake-modules with the above commit will do not it
alone.

The additional fix is to add also qttools5-dev as build dependency, and
possibly also limit the documentation building to indep-only builds
(since the QCH files are shipped in arch:any -doc packages).  Imagine
that there are almost 80 sources of Frameworks, and 60 of them provide
a QCH documentation...

-- 
Pino Toscano

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

Bug#914065: nheko FTBFS: Could not find a package configuration file provided by "MatrixClient"

Source: nheko
Version: 0.6.1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=nheko=sid

...
Build type set to 'RelWithDebInfo'
-- Version: 0.6.1
-- Boost version: 1.67.0
-- Found the following Boost libraries:
--   atomic
--   chrono
--   date_time
--   iostreams
--   random
--   regex
--   system
--   thread
-- Found ZLIB: /usr/lib/aarch64-linux-gnu/libz.so (found version "1.2.11") 
-- Found OpenSSL: /usr/lib/aarch64-linux-gnu/libcrypto.so (found version 
"1.1.1")  
CMake Error at CMakeLists.txt:251 (find_package):
  By not providing "FindMatrixClient.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "MatrixClient", but CMake did not find one.

  Could not find a package configuration file provided by "MatrixClient"
  (requested version 0.1.0) with any of the following names:

MatrixClientConfig.cmake
matrixclient-config.cmake

  Add the installation prefix of "MatrixClient" to CMAKE_PREFIX_PATH or set
  "MatrixClient_DIR" to a directory containing one of the above files.  If
  "MatrixClient" provides a separate development package or SDK, be sure it
  has been installed.


-- Configuring incomplete, errors occurred!

Bug#914063: tagpy FTBFS with boost 1.67

Source: tagpy
Version: 2013.1-6
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=tagpy=sid

...
x86_64-linux-gnu-g++ -pthread -shared -Wl,-Bsymbolic-functions -Wl,-z,relro 
-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fdebug-prefix-map=/build/python2.7-A8UpPM/python2.7-2.7.15=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
build2.7/temp.linux-x86_64-2.7/src/wrapper/basics.o 
build2.7/temp.linux-x86_64-2.7/src/wrapper/id3.o 
build2.7/temp.linux-x86_64-2.7/src/wrapper/rest.o -ltag -lboost_python-py27 -o 
build2.7/lib.linux-x86_64-2.7/_tagpy.so
/usr/bin/ld: cannot find -lboost_python-py27
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-g++' failed with exit status 1
make[1]: *** [debian/rules:23: override_dh_auto_build-2.7] Error 1


The Ubuntu diff seems to contain a fix.

Bug#912566: sparse FTBFS with llvm/clang 7




Le 18/11/2018 à 22:08, Uwe Kleine-König a écrit :

Hello,

On Sat, Nov 17, 2018 at 09:40:39AM +0100, Sylvestre Ledru wrote:

reassign 912566 sparse
forwarded 912566 https://bugs.llvm.org/show_bug.cgi?id=8220
thanks

similar to Adrian I fail to follow why this is spare's problem. Unless
sparse used llvm-config wrongly I think the problem at hand is that the
output of llvm-config is bad and responsible for the build failure.

Agreed that this is llvm-config. I reassigned to sparse because this isn't
a recent issue that llvm-config is bad and sparse is already workarounding
its limitations.

I proposed this MR to address that:
https://salsa.debian.org/ukleinek/sparse/merge_requests/1

Right, sparse could work around the problem by filtering the output of
llvm-config, but this is not the right fix for this problem.

Please implement the filtering in llvm (and also drop -pedantic and
-DNDEBUG from it, too).


I will (you are welcome providing a patch if you are interested)

Cheers,

S

Bug#914064: vdr-plugin-fritzbox FTBFS with boost 1.67

Source: vdr-plugin-fritzbox
Version: 1.5.3-7
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=vdr-plugin-fritzbox=sid

...
TcpClient.cpp: In member function 'void network::TcpClient::expireStreamNow()':
TcpClient.cpp:58:57: error: no matching function for call to 
'boost::asio::basic_socket_iostream::expires_from_now(boost::posix_time::seconds)'
   stream->expires_from_now(boost::posix_time::seconds(0));
 ^
In file included from /usr/include/boost/asio.hpp:31,
 from TcpClient.h:25,
 from TcpClient.cpp:22:
/usr/include/boost/asio/basic_socket_iostream.hpp:392:12: note: candidate: 
'boost::asio::basic_socket_iostream::duration 
boost::asio::basic_socket_iostream::expires_from_now() const [with Protocol = boost::asio::ip::tcp; 
Clock = std::chrono::_V2::steady_clock; WaitTraits = 
boost::asio::wait_traits; 
boost::asio::basic_socket_iostream::duration = 
std::chrono::duration >]'
   duration expires_from_now() const
^~~~
/usr/include/boost/asio/basic_socket_iostream.hpp:392:12: note:   candidate 
expects 0 arguments, 1 provided
/usr/include/boost/asio/basic_socket_iostream.hpp:407:8: note: candidate: 'void 
boost::asio::basic_socket_iostream::expires_from_now(const duration&) [with Protocol = 
boost::asio::ip::tcp; Clock = std::chrono::_V2::steady_clock; WaitTraits = 
boost::asio::wait_traits; 
boost::asio::basic_socket_iostream::duration = 
std::chrono::duration >]'
   void expires_from_now(const duration& expiry_time)
^~~~
/usr/include/boost/asio/basic_socket_iostream.hpp:407:8: note:   no known 
conversion for argument 1 from 'boost::posix_time::seconds' to 'const 
duration&' {aka 'const std::chrono::duration >&'}
make[2]: *** [Makefile:9: TcpClient.o] Error 1

Bug#914062: pyexiv2 FTBFS with boost 1.67

Source: pyexiv2
Version: 0.3.2-8
Severity: serious
Tags: ftbfs buster sid

https://buildd.debian.org/status/package.php?p=pyexiv2=sid

...
g++ -o build/libexiv2python.so -Wl,-z,relro -shared build/exiv2wrapper.os 
build/exiv2wrapper_python.os -lboost_python-py27 -lexiv2
/bin/ld: cannot find -lboost_python-py27
collect2: error: ld returned 1 exit status
scons: *** [build/libexiv2python.so] Error 1


The Ubuntu diff seems to contain a fix.

Bug#912566: sparse FTBFS with llvm/clang 7

2018-11-18 Thread Uwe Kleine-König

Hello,

On Sat, Nov 17, 2018 at 09:40:39AM +0100, Sylvestre Ledru wrote:
> reassign 912566 sparse
> forwarded 912566 https://bugs.llvm.org/show_bug.cgi?id=8220
> thanks

similar to Adrian I fail to follow why this is spare's problem. Unless
sparse used llvm-config wrongly I think the problem at hand is that the
output of llvm-config is bad and responsible for the build failure.

> I proposed this MR to address that:
> https://salsa.debian.org/ukleinek/sparse/merge_requests/1

Right, sparse could work around the problem by filtering the output of
llvm-config, but this is not the right fix for this problem.

Please implement the filtering in llvm (and also drop -pedantic and
-DNDEBUG from it, too).

Best regards
Uwe

signature.asc
Description: PGP signature

Bug#914002: qtcreator's clang code model appears to be broken with kit = clang

2018-11-18 Thread Lisandro Damián Nicanor Pérez Meyer

El domingo, 18 de noviembre de 2018 16:45:57 -03 Sylvestre Ledru escribió:
> Le 18/11/2018 à 20:06, Lisandro Damián Nicanor Pérez Meyer a écrit :
> > clone 914002 -1
> > reassign -1 src:llvm-toolchain-7 1:7.0.1~+rc2-4
> > affects -1 qtcreator
> > thanks
> > 
> > El domingo, 18 de noviembre de 2018 10:18:03 -03 Adam Majer escribió:
> >> On 2018-11-18 12:30 p.m., Roman Lebedev wrote:
> >>> If kit is clang (tried with both the clang 7, and llvm trunk),
> >>> the parsing appears to fail, pretty much all the C++ std:: symbols
> >>> are underscored, and marked as not found.
> >>> 
> >>> ii  libclang1-71:7.0.1~+rc2-4
> >> 
> >> The problem is clang. Clang in Testing works just fine. When I upgraded
> >> Qt
> >> Creator, all is fine. But as soon as clang was updated, it breaks.
> >> Downgrading to clang 1:7-6 fixes the problem.
> >> 
> >> Looks like regression caused by clang 1:7.0.1~+rc2-4 and related.
> > 
> > Cloning the bug so. Hope I've got the right bts invocations.
> 
> Can you try if rebuilding qtcreator against this version of clang fixes the
> issue or not?

I personally can't promise it.

I was pointed at:



Is that in the archive already? It might be the cause of this bug.

-- 
A proprietary undocumented text format as the de facto standard -- and that's
what .doc is -- is a shame for all parties involved. It's like using a special
patented ink that can only be read with special patented sun glasses. Who
would want to use that for all their scientific, private and business
documents? Probably nobody. Why they do so with computers is beyond me.
  Matthias Ettrich, founder of the KDE project.
  https://lwn.net/Articles/273715/rss

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#914061: performous FTBFS with boost 1.67

Source: performous
Version: 1.1-2
Severity: serious
Tags: ftbfs buster sid

https://buildd.debian.org/status/package.php?p=performous=sid

...
/<>/game/audio.cc: In static member function 'static 
boost::posix_time::time_duration AudioClock::getDuration(double)':
/<>/game/audio.cc:80:86: error: no matching function for call to 
'boost::date_time::subsecond_duration::subsecond_duration(double)'
  static time_duration getDuration(double seconds) { return microseconds(1e6 * 
seconds); }

  ^
In file included from 
/usr/include/boost/date_time/posix_time/posix_time_config.hpp:16,
 from 
/usr/include/boost/date_time/posix_time/posix_time_system.hpp:13,
 from /usr/include/boost/date_time/posix_time/ptime.hpp:12,
 from /usr/include/boost/date_time/posix_time/posix_time.hpp:15,
 from /usr/include/boost/date_time/local_time/local_time.hpp:11,
 from /usr/include/boost/date_time.hpp:15,
 from /<>/game/audio.hh:3,
 from /<>/game/audio.cc:1:
/usr/include/boost/date_time/time_duration.hpp:285:14: note: candidate: 
'template boost::date_time::subsecond_duration::subsecond_duration(const T&, typename 
boost::enable_if, void>::type*)'
 explicit subsecond_duration(T const& ss,
  ^~
/usr/include/boost/date_time/time_duration.hpp:285:14: note:   template 
argument deduction/substitution failed:
/usr/include/boost/date_time/time_duration.hpp: In substitution of 
'template 
boost::date_time::subsecond_duration::subsecond_duration(const T&, typename 
boost::enable_if >::type*) [with T = double]':
/<>/game/audio.cc:80:86:   required from here
/usr/include/boost/date_time/time_duration.hpp:285:14: error: no type named 
'type' in 'struct boost::enable_if, void>'
In file included from 
/usr/include/boost/date_time/posix_time/posix_time_config.hpp:16,
 from 
/usr/include/boost/date_time/posix_time/posix_time_system.hpp:13,
 from /usr/include/boost/date_time/posix_time/ptime.hpp:12,
 from /usr/include/boost/date_time/posix_time/posix_time.hpp:15,
 from /usr/include/boost/date_time/local_time/local_time.hpp:11,
 from /usr/include/boost/date_time.hpp:15,
 from /<>/game/audio.hh:3,
 from /<>/game/audio.cc:1:
/usr/include/boost/date_time/time_duration.hpp:270:30: note: candidate: 
'boost::date_time::subsecond_duration::subsecond_duration(const 
boost::date_time::subsecond_duration&)'
   class BOOST_SYMBOL_VISIBLE subsecond_duration : public base_duration
  ^~
/usr/include/boost/date_time/time_duration.hpp:270:30: note:   no known 
conversion for argument 1 from 'double' to 'const 
boost::date_time::subsecond_duration&'
/usr/include/boost/date_time/time_duration.hpp:270:30: note: candidate: 
'boost::date_time::subsecond_duration::subsecond_duration(boost::date_time::subsecond_duration&&)'
/usr/include/boost/date_time/time_duration.hpp:270:30: note:   no known 
conversion for argument 1 from 'double' to 
'boost::date_time::subsecond_duration&&'
/<>/game/audio.cc: In member function 
'boost::posix_time::time_duration Music::durationOf(int64_t) const':
/<>/game/audio.cc:152:99: error: no matching function for call to 
'boost::date_time::subsecond_duration::subsecond_duration(double)'
  time_duration durationOf(int64_t samples) const { return microseconds(1e6 * 
samples / srate / 2.0); }

   ^
In file included from 
/usr/include/boost/date_time/posix_time/posix_time_config.hpp:16,
 from 
/usr/include/boost/date_time/posix_time/posix_time_system.hpp:13,
 from /usr/include/boost/date_time/posix_time/ptime.hpp:12,
 from /usr/include/boost/date_time/posix_time/posix_time.hpp:15,
 from /usr/include/boost/date_time/local_time/local_time.hpp:11,
 from /usr/include/boost/date_time.hpp:15,
 from /<>/game/audio.hh:3,
 from /<>/game/audio.cc:1:
/usr/include/boost/date_time/time_duration.hpp:285:14: note: candidate: 
'template boost::date_time::subsecond_duration::subsecond_duration(const T&, typename 
boost::enable_if, void>::type*)'
 explicit subsecond_duration(T const& ss,
  ^~
/usr/include/boost/date_time/time_duration.hpp:285:14: note:   template 
argument deduction/substitution failed:
/usr/include/boost/date_time/time_duration.hpp: In substitution of 
'template 
boost::date_time::subsecond_duration::subsecond_duration(const T&, typename 
boost::enable_if >::type*) [with T = double]':
/<>/game/audio.cc:152:99:   required from here
/usr/include/boost/date_time/time_duration.hpp:285:14: error: no type named 
'type' in 'struct

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

2018-11-18 Thread Dmitry Shachnev

Hi Lisandro and Paul!

On Sun, Nov 18, 2018 at 05:47:04PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> None of the qtbase changes should be triggering this. *But* all the packages
> are being built with qttools5-dev-tools 5.11.2-4 instead of 5.11.2-5, and that
> might be the issue, as the latest version contains a fix for some clang stuff:
>
> 
>
> Ideally this tests should be retried with qttools-dev-tools 5.11.2-5. Can that
> be done? No enough build power here to try myself.

No, retrying them won’t help.

(TL;DR: we need to patch extra-cmake-modules. Extended description below.)

The failures are caused by my commit which was fixing bug #913499:

https://salsa.debian.org/qt-kde-team/qt/qtbase/commit/44912fe676105951250e2cf5ad6c9bccf21e72cc

It broke the logic in FindQHelpGenerator.cmake, which was detecting
qhelpgenerator using the path from location of Qt5::qmake.

Previously it was correctly detecting it in /usr/lib/qt5/bin/qhelpgenerator,
but after the above commit it detects it in /usr/bin/qhelpgenerator which
fails with:

  qhelpgenerator: could not find a Qt installation of ''

I see that Pino already fixed this in extra-cmake-modules upstream:

https://cgit.kde.org/extra-cmake-modules.git/commit/?id=96d169b87292d935

The best way forward will be to cherry-pick that patch in extra-cmake-modules.

But if the are other places that are broken, I can change this line:

  sed -i 's,lib/qt5/bin/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,'

to this:

  sed -i 's,lib/qt5/bin/qmake,lib/$(DEB_HOST_MULTIARCH)/qt5/bin/qmake,'

in qtbase debian/rules. That should also fix the issue.

--
Dmitry Shachnev

signature.asc
Description: PGP signature

Bug#914058: cupt FTBFS when binNMU'ed

Source: cupt
Version: 2.10.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=cupt=sid

...
#   Failed test 'executable version'
#   at tt/version.t line 11.
#   'executable: 2.10.2+b1
# library: 2.10.2+b1
# '
# doesn't match '(?^m:^executable: (?^:2\.\d+\.\d+~?)$)'

#   Failed test 'library version'
#   at tt/version.t line 12.
#   'executable: 2.10.2+b1
# library: 2.10.2+b1
# '
# doesn't match '(?^m:^library: (?^:2\.\d+\.\d+~?)$)'
# Looks like you failed 2 tests of 4.

#   Failed test 'invoking via version'
#   at tt/version.t line 15.

#   Failed test 'executable version'
#   at tt/version.t line 11.
#   'executable: 2.10.2+b1
# library: 2.10.2+b1
# '
# doesn't match '(?^m:^executable: (?^:2\.\d+\.\d+~?)$)'

#   Failed test 'library version'
#   at tt/version.t line 12.
#   'executable: 2.10.2+b1
# library: 2.10.2+b1
# '
# doesn't match '(?^m:^library: (?^:2\.\d+\.\d+~?)$)'
# Looks like you failed 2 tests of 4.

#   Failed test 'invoking via -v'
#   at tt/version.t line 15.

#   Failed test 'executable version'
#   at tt/version.t line 11.
#   'executable: 2.10.2+b1
# library: 2.10.2+b1
# '
# doesn't match '(?^m:^executable: (?^:2\.\d+\.\d+~?)$)'

#   Failed test 'library version'
#   at tt/version.t line 12.
#   'executable: 2.10.2+b1
# library: 2.10.2+b1
# '
# doesn't match '(?^m:^library: (?^:2\.\d+\.\d+~?)$)'
# Looks like you failed 2 tests of 4.

#   Failed test 'invoking via --version'
#   at tt/version.t line 15.
# Looks like you failed 3 tests of 3.
[09:07:26] tt/version.t 
...
 
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/3 subtests 
[09:07:26]

Test Summary Report
---
tt/version.t
 (Wstat: 768 Tests: 3 Failed: 3)
  Failed tests:  1-3
  Non-zero exit status: 3
Files=181, Tests=2072, 124 wallclock secs ( 2.19 usr  0.54 sys + 79.92 cusr 
17.00 csys = 99.65 CPU)
Result: FAIL
make[4]: *** [test/CMakeFiles/test.dir/build.make:60: test/CMakeFiles/test] 
Error 1

Bug#914059: git-remote-gcrypt: fails without mentioning that the fingerprint for the RSA key sent by the remote host has changed

2018-11-18 Thread moire

Package: git-remote-gcrypt
Version: 1.0.1-1
Severity: important

Hi,

   * What led up to the situation?

I was no longer able to use an encrypted git repo after the fingerprint
for the RSA key sent by the remote host changed, and the failure message
did not help me to understand why.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I tried to fetch updates from an encrypted git repository I've been
using for a while.

   * What was the outcome of this action?

gcrypt: Repository not found: "my encrypted git repo"
gcrypt: ..but repository ID is set. Aborting.

   * What outcome did you expect instead?

An indication of the cause of the failure.

I discovered that the fingerprint had changed by trying to clone the
repository somewhere else.
Cheers,

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

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

Versions of packages git-remote-gcrypt depends on:
ii  git 1:2.11.0-3+deb9u4
ii  gnupg   2.2.10-3
ii  gnupg2  2.1.18-8~deb9u2

Versions of packages git-remote-gcrypt recommends:
ii  curl   7.52.1-5+deb9u8
ii  rsync  3.1.2-1+deb9u1

git-remote-gcrypt suggests no packages.

-- no debconf information

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

Hi Lisandro,

Thanks for the reply.

On 18-11-18 21:47, Lisandro Damián Nicanor Pérez Meyer wrote:
> None of the qtbase changes should be triggering this. *But* all the packages 
> are being built with qttools5-dev-tools 5.11.2-4 instead of 5.11.2-5, and 
> that 
> might be the issue, as the latest version contains a fix for some clang stuff:
> 
> 
> 
> Ideally this tests should be retried with qttools-dev-tools 5.11.2-5. Can 
> that 
> be done? No enough build power here to try myself.

I've just triggered one package (kpackage), but if this is really the
case, it should normally be fixed in the dependency registration
somehow, e.g. most likely a versioned breaks in qtbase-opensource-src on
the broken version of qttools5-dev-tools. I guess that waiting one day
will fix the issue also (if/when qttools-opensource-src migrates).

Paul

signature.asc
Description: OpenPGP digital signature

Bug#914053: Acknowledgement (boost1.67: Please use binary-indep target to build doc package)

2018-11-18 Thread John Paul Adrian Glaubitz

An example for a package which correctly separates the binary-indep
and binary-arch packages can be found in the debian/rules of the ffmpeg
package.

See: https://sources.debian.org/src/ffmpeg/7:4.0.2-1/debian/rules/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#914060: freeture FTBFS with boost 1.67

Source: freeture
Version: 1.2.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=freeture=sid

...
SMTPClient.cpp: In static member function 'static void 
SMTPClient::sendMail(std::__cxx11::string, std::__cxx11::string, 
std::__cxx11::string, std::__cxx11::string, 
std::vector >, std::__cxx11::string, 
std::__cxx11::string, std::vector >, 
SmtpSecurity)':
SMTPClient.cpp:347:57: error: 'boost::asio::ip::tcp::socket' {aka 'class 
boost::asio::basic_stream_socket'} has no member named 
'native'
 OpenSSL openSSL(socket.GetSocket()->native());
 ^~


This Ubuntu diff seems to contain a fix.

Bug#913082: autopkgtest: support multi-arch test dependencies

2018-11-18 Thread Martin Pitt

Hello Paul,

Paul Gevers [2018-11-18 21:32 +0100]:
> If I understand correctly, your fix for this bug only enables pulling
> packages from foreign architectures if those architectures are otherwise
> enabled in the testbed.

Correct. That's all that there's to it -- autopkgtest itself is not supposed to
configure apt repositories or otherwise change the testbed by itself.

> Well, but if tests go the manual way, they don't need the fix to this
> bug anyways.

Right, I was just pointing it out as a possible workaround.

> So, I rather keep this bug open until autopkgtest really supports
> multi-arch test dependencies.

What else would you change in autopkgtest itself for this? (I don't see
anything). We can clone this to debci to enable i386 in the amd64 testbeds, if
there is some actual demand for it. Right now it's not yet clear whether
Alexandre needs this for proper Debian packages or just his own test runs.

Thanks,

Martin

Bug#914057: python3-debianbts: debianbts.get_bugs does not support the use of HTTP and HTTPS proxy servers

Package: python3-debianbts
Version: 2.7.2
Severity: important

Dear Maintainer,

This bug is related to bug #717563 in reportbug package. Message #59
on that bug shows the following code
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717563#msg59):

>  bugs = debianbts.get_bugs(pkg_filter, package)

There is no opportunity to pass proxy information, which reportbug
supports via commandline option --proxy (aliased to --http_proxy) to
the SoapClient instantiated by debianbts.

get_bugs, and other methods, should support a dict similar to that
constructed by reportbug and used by urllib2 (underlying reportbug) or
some other method of setting proxy information.

I am happy to implement whatever changes are considered appropriate for this bug
and #717563.

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages python3-debianbts depends on:
ii  python3   3.6.7-1
ii  python3-pysimplesoap  1.16-2.1

python3-debianbts recommends no packages.

python3-debianbts suggests no packages.

-- no debconf information

Bug#914056: cclive FTBFS with boost 1.67

Source: cclive
Version: 0.9.3-0.1
Severity: serious
Tags: ftbfs buster sid

https://buildd.debian.org/status/package.php?p=cclive=sid

...
In file included from ./ccprogressbar:1,
 from cc/file.cpp:41:
./cc/progressbar.h: In static member function 'static std::__cxx11::string 
cc::progressbar::eta_from_seconds(double)':
./cc/progressbar.h:319:48: error: no matching function for call to 
'boost::posix_time::seconds::seconds(const double&)'
 const pt::time_duration& td = pt::seconds(s);
^
In file included from 
/usr/include/boost/date_time/posix_time/posix_time_types.hpp:16,
 from 
/usr/include/boost/date_time/posix_time/time_formatters.hpp:16,
 from /usr/include/boost/date_time/posix_time/posix_time.hpp:24,
 from ./cc/progressbar.h:26,
 from ./ccprogressbar:1,
 from cc/file.cpp:41:
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: note: 
candidate: 'template boost::posix_time::seconds::seconds(const T&, 
typename boost::enable_if >::type*)'
   explicit seconds(T const& s,
^~~
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: note:   
template argument deduction/substitution failed:
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp: In 
substitution of 'template boost::posix_time::seconds::seconds(const 
T&, typename boost::enable_if >::type*) [with T = 
double]':
./cc/progressbar.h:319:48:   required from here
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:57:16: error: 
no type named 'type' in 'struct boost::enable_if, 
void>'
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: 
candidate: 'boost::posix_time::seconds::seconds(const 
boost::posix_time::seconds&)'
   class BOOST_SYMBOL_VISIBLE seconds : public time_duration
  ^~~
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note:   
no known conversion for argument 1 from 'const double' to 'const 
boost::posix_time::seconds&'
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note: 
candidate: 'boost::posix_time::seconds::seconds(boost::posix_time::seconds&&)'
/usr/include/boost/date_time/posix_time/posix_time_duration.hpp:53:30: note:   
no known conversion for argument 1 from 'const double' to 
'boost::posix_time::seconds&&'
make[3]: *** [Makefile:593: cc/file.o] Error 1

Bug#914053: Acknowledgement (boost1.67: Please use binary-indep target to build doc package)

2018-11-18 Thread John Paul Adrian Glaubitz

Correction:

The installation targets used should be

override_dh_install-indep and override_dh_install-arch

Sorry for the confusion.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#914054: calamares FTBFS with boost 1.67

Source: calamares
Version: 3.2.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=calamares=sid

...
cd /<>/obj-x86_64-linux-gnu/src/libcalamares && /usr/bin/c++  
-DDLLEXPORT_PRO -DPYTHONQT_USE_RELEASE_PYTHON_FALLBACK -DQT_CORE_LIB 
-DQT_NO_DEBUG -DQT_SHARED -DQT_SHAREDPOINTER_TRACK_POINTERS 
-DQT_STRICT_ITERATORS -Dcalamares_EXPORTS 
-I/<>/obj-x86_64-linux-gnu/src/libcalamares/calamares_autogen/include
 -I/<>/src -I/<>/src/libcalamares 
-I/<>/src/libcalamaresui 
-I/<>/obj-x86_64-linux-gnu/src 
-I/<>/obj-x86_64-linux-gnu/src/libcalamares 
-I/<>/obj-x86_64-linux-gnu/src/libcalamaresui 
-I/usr/include/python3.6m -I/usr/include/PythonQt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,--no-undefined 
-Wl,--fatal-warnings -Wnon-virtual-dtor -Woverloaded-virtual 
-Werror=return-type -fdiagnostics-color=auto -fPIC   -fPIC -std=gnu++14 -o 
CMakeFiles/calamares.dir/GlobalStorage.cpp.o -c 
/<>/src/libcalamares/GlobalStorage.cpp
In file included from /usr/include/yaml-cpp/node/iterator.h:13,
 from /usr/include/yaml-cpp/node/impl.h:11,
 from /usr/include/yaml-cpp/yaml.h:17,
 from /<>/src/modules/test_conf.cpp:29:
/usr/include/yaml-cpp/node/detail/iterator.h: In member function 'void 
YAML::detail::iterator_base::increment()':
/usr/include/yaml-cpp/node/detail/iterator.h:48:54: error: 'next' is not a 
member of 'boost'
   void increment() { this->base_reference() = boost::next(this->base()); }
  ^~~~
/usr/include/yaml-cpp/node/detail/iterator.h:48:54: note: suggested 
alternatives:
In file included from /usr/include/c++/8/bits/stl_algobase.h:66,
 from /usr/include/c++/8/bits/char_traits.h:39,
 from /usr/include/c++/8/ios:40,
 from /usr/include/c++/8/ostream:38,
 from /usr/include/c++/8/iostream:39,
 from /<>/src/modules/test_conf.cpp:27:
/usr/include/c++/8/bits/stl_iterator_base_funcs.h:213:5: note:   'std::next'
 next(_InputIterator __x, typename
 ^~~~
In file included from /usr/include/boost/mpl/next.hpp:17,
 from /usr/include/boost/mpl/bind.hpp:25,
 from /usr/include/boost/mpl/lambda.hpp:18,
 from /usr/include/boost/mpl/apply.hpp:25,
 from /usr/include/boost/iterator/iterator_facade.hpp:36,
 from /usr/include/yaml-cpp/node/detail/node_iterator.h:12,
 from /usr/include/yaml-cpp/node/detail/iterator.h:12,
 from /usr/include/yaml-cpp/node/iterator.h:13,
 from /usr/include/yaml-cpp/node/impl.h:11,
 from /usr/include/yaml-cpp/yaml.h:17,
 from /<>/src/modules/test_conf.cpp:29:
/usr/include/boost/mpl/next_prior.hpp:29:8: note:   'boost::mpl::next'
 struct next
^~~~
make[3]: *** [src/modules/CMakeFiles/test_conf.dir/build.make:66: 
src/modules/CMakeFiles/test_conf.dir/test_conf.cpp.o] Error 1

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

2018-11-18 Thread Lisandro Damián Nicanor Pérez Meyer

El domingo, 18 de noviembre de 2018 16:46:06 -03 Paul Gevers escribió:
[snip]
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/k/krunner/1331006/log.g
> z
> 
> CMake Error at src/cmake_install.cmake:119 (file):
>   file INSTALL cannot find
> 
> "/tmp/autopkgtest-lxc.p952k2pe/downtmp/build.LIE/src/obj-x86_64-linux-gnu/sr
> c/KF5Runner.qch". Call Stack (most recent call first):
>   cmake_install.cmake:88 (include)
> 
> 
> make[1]: *** [Makefile:65: install] Error 1
> make[1]: Leaving directory
> '/tmp/autopkgtest-lxc.p952k2pe/downtmp/build.LIE/src/obj-x86_64-linux-gnu'
> dh_auto_install: cd obj-x86_64-linux-gnu && make V=1 -j2 install
> DESTDIR=/tmp/autopkgtest-lxc.p952k2pe/downtmp/build.LIE/src/debian/tmp
> AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" returned
> exit code 2
> make: *** [debian/rules:7: binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
> returned exit status 2

None of the qtbase changes should be triggering this. *But* all the packages 
are being built with qttools5-dev-tools 5.11.2-4 instead of 5.11.2-5, and that 
might be the issue, as the latest version contains a fix for some clang stuff:



Ideally this tests should be retried with qttools-dev-tools 5.11.2-5. Can that 
be done? No enough build power here to try myself.

Thanks for the pointer, Lisandro.

-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#914053: boost1.67: Please use binary-indep target to build doc package

2018-11-18 Thread John Paul Adrian Glaubitz

Source: boost1.67
Version: 1.67.0-10
Severity: normal

Hello!

Currently, the debian/rules file of the boost1.67 package contains the
following code in the override_dh_auto_build target:

ifneq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
mkdir -p doc
else
$(JAM_DOC) --build-dir=build-doc doc
endif

This means that the building of the documentation is toggled through the
status "nodoc" build flag. This means, however, that the documentation is
always built even when it is not used for the doc package which is only
built when sbuild is called with "--arch-all" to build both the arch:any
and arch:all targets. This means, the buildds are wasting CPU time for
generating documentation which is later just thrown away since the doc
package is not being created.

To fix this, I propose using the override_dh_auto_build-indep and
override_dh_auto_install-indep and override_dh_auto_build-arch and
override_dh_auto_install-arch to build documentation and binary-specific
files in separate targets.

For example:

override_dh_auto_build-indep:
$(JAM_DOC) --build-dir=build-doc doc

override_dh_compress-indep:
dh_compress -Xlibboost$(PKGVERSION)-doc/doc

override_dh_auto_install-indep:
# package libboost-doc
mkdir -p 
debian/libboost$(PKGVERSION)-doc/usr/share/doc/libboost$(PKGVERSION)-doc
cp -a doc 
debian/libboost$(PKGVERSION)-doc/usr/share/doc/libboost$(PKGVERSION)-doc
# provide a constant symlink to the latest documents and examples
dh_link -plibboost$(PKGVERSION)-doc \
   usr/share/doc/libboost$(PKGVERSION)-doc/doc \
   usr/share/doc/libboost-doc/doc
dh_link -plibboost$(PKGVERSION)-doc \
   usr/share/doc/libboost$(PKGVERSION)-doc/examples \
   usr/share/doc/libboost-doc/examples

Would be great if the change could be included in the next upload and
for all other boost1.XY packages.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#914055: gitaly: misses versioned dependency on gitaly-proto (and probably more)

Package: gitaly
Version: 0.100.1+debian2-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, git...@packages.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gitlab

Dear maintainers,

With a recent upload of gitlab the autopkgtest of gitaly fails in
testing when that autopkgtest is run with the binary packages of gitlab
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
gitlab from testing11.1.8+dfsg-2
gitaly from testing0.100.1+debian2-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. If I
understand the error message correctly, the failure is due to the fact
that gitaly-proto from testing isn't found. None of our tools is aware
that gitaly-proto version 0.99.0 is a dependency of gitaly 0.100.1
because that dependency isn't declared in the regular way. If I further
read the output of a passing autopkgtest, I fear that there are quite a
few more packages that need documenting.

Currently this regression is contributing to the delay of the migration
of gitlab to testing [1], although that may "fix" itself once
gitaly/0.111.4+debian-2 and golang-gitaly-proto/0.105.0+dfsg-2 migrate
to testing in a couple of days.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from gitlab should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul
PS: I'd like to let you know that an autopkgtest that only contains a
no-op test (that just installs a package) is NOT wanted by the release
team. It appears to me that your test doesn't do anything that isn't
already done during installation (the logs are the same). Please add
testcases that really use your installed package in any way, or drop
your autopkgtest. We have piuparts testing to check for installability
issues.

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
gitlab/11.1.8+dfsg-2. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=gitlab

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gitaly/1330154/log.gz

Setting up gitaly (0.100.1+debian2-1) ...
[31mCould not find gem 'gitaly-proto (~> 0.99.0)' in any of the gem
sources listed
in your Gemfile.[0m
dpkg: error processing package gitaly (--configure):
 installed gitaly package post-installation script subprocess returned
error exit status 7
dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 autopkgtest-satdep depends on gitaly; however:
  Package gitaly is not configured yet.

dpkg: error processing package autopkgtest-satdep (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.27-8) ...
Processing triggers for ca-certificates (20170717) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for systemd (239-11) ...
Errors were encountered while processing:
 gitaly



signature.asc
Description: OpenPGP digital signature

Bug#914052: uhd FTBFS with boost 1.67

Source: uhd
Version: 3.13.0.2-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=uhd=sid

...
-- Configuring LibUHD - Python API support...
--   Dependency ENABLE_LIBUHD = ON
--   Dependency BOOST_PYTHON_FOUND = 
--   Dependency HAVE_PYTHON_MODULE_NUMPY = TRUE
--   Dependency PythonLibs_FOUND = TRUE
CMake Error at cmake/Modules/UHDComponent.cmake:56 (MESSAGE):
  Dependencies for required component LibUHD - Python API not met.
Call Stack (most recent call first):
  CMakeLists.txt:430 (LIBUHD_REGISTER_COMPONENT)


-- Configuring incomplete, errors occurred!

Bug#914051: python-freecontact FTBFS with boost 1.67

Source: python-freecontact
Version: 1.1-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=python-freecontact=sid

...
   dh_auto_build -a -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_ext
building 'freecontact' extension
creating build
creating build/temp.linux-amd64-2.7
creating build/temp.linux-amd64-2.7/src
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-fno-strict-aliasing -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python2.7 -c src/freecontact.cpp -o 
build/temp.linux-amd64-2.7/src/freecontact.o
cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC 
but not for C++
x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fdebug-prefix-map=/build/python2.7-A8UpPM/python2.7-2.7.15=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
-Wl,-z,now -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 build/temp.linux-amd64-2.7/src/freecontact.o -lfreecontact 
-lboost_python-py27 -o 
/<>/.pybuild/cpython2_2.7_freecontact/build/freecontact.so
/usr/bin/ld: cannot find -lboost_python-py27
collect2: error: ld returned 1 exit status
error: command 'x86_64-linux-gnu-g++' failed with exit status 1
E: pybuild pybuild:338: build: plugin distutils failed with: exit code=1: 
/usr/bin/python setup.py build 
dh_auto_build: pybuild --build -i python{version} -p 2.7 returned exit code 13
make: *** [debian/rules:11: build-arch] Error 25

Bug#914050: python-casacore FTBFS with boost 1.67

Source: python-casacore
Version: 2.2.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=python-casacore=sid

...
  dh_auto_test -a -O--buildsystem=pybuild -O--parallel
pybuild --test -i python{version} -p 2.7
I: pybuild base:217: cd /<>/.pybuild/cpython2_2.7_casacore/build; 
python2.7 -m unittest discover -v 

--
Ran 0 tests in 0.000s

OK
pybuild --test -i python{version} -p "3.7 3.6"
I: pybuild base:217: cd /<>/.pybuild/cpython3_3.7_casacore/build; 
python3.7 -m unittest discover -v 
Segmentation fault
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=139: cd 
/<>/.pybuild/cpython3_3.7_casacore/build; python3.7 -m unittest 
discover -v 
dh_auto_test: pybuild --test -i python{version} -p "3.7 3.6" returned exit code 
13
make: *** [debian/rules:8: build-arch] Error 25


The Ubuntu diff contains changes that might (or might not) be related.

Bug#913827: pgagent: should depend on postgresql?

2018-11-18 Thread Christoph Berg

Re: Jeremy Bicha 2018-11-15 

> Source: pgagent
> Version: 4.0.0-4
> 
> I've been working on the postgresql 10 → 11 transition in Ubuntu.
> pgagent didn't show up on our transition tracker because it doesn't
> actually depend on a versioned postgresql like other affected packages
> do.
> 
> Please investigate whether this dependency should be added.

Hi,

the dependency was not present so far because, in theory, pgagent
could be running on a remote host without a local PostgreSQL server.
Also, because the server-side part of the package is a SQL-only
extension, there's no separate postgresql-*-pgagent binary packages.

This is a hack, and the fact that the package behaves differently from
the remaining modules has bitten me as well, so you are right in
asking for a proper solution. I just uploaded a new package that adds
a dependency on the list of server versions targeted (ORed).

Cheers,
Christoph

Bug#914049: progressivemauve FTBFS with boost 1.67

Source: progressivemauve
Version: 1.2.0+4713+dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=progressivemauve=sid

...
repeatoire.cpp: In function 'void 
processNovelSubsetMatches(GappedMatchRecord*&, 
std::vector >, std::vector > > >&, bool, ProcrastinationQueue&, 
std::vector&, int, uint, int&, size_t&)':
repeatoire.cpp:1594:34: error: no matching function for call to 
'std::vector >, std::vector > > >::push_back(GappedMatchRecord*&)'
   novel_subset_list.push_back(M_n);
  ^
In file included from /usr/include/c++/8/vector:64,
 from /usr/include/libGenome/gnGenomeSpec.h:21,
 from /usr/include/libGenome/gnSequence.h:27,
 from repeatoire.cpp:1:
/usr/include/c++/8/bits/stl_vector.h:1074:7: note: candidate: 'void 
std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = 
boost::tuples::tuple >, std::vector > >; _Alloc = 
std::allocator >, std::vector > > >; std::vector<_Tp, _Alloc>::value_type = 
boost::tuples::tuple >, std::vector > >]'
   push_back(const value_type& __x)
   ^
/usr/include/c++/8/bits/stl_vector.h:1074:7: note:   no known conversion for 
argument 1 from 'GappedMatchRecord*' to 'const value_type&' {aka 'const 
boost::tuples::tuple >, std::vector > >&'}
/usr/include/c++/8/bits/stl_vector.h:1090:7: note: candidate: 'void 
std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&) 
[with _Tp = boost::tuples::tuple >, std::vector > >; _Alloc = 
std::allocator >, std::vector > > >; std::vector<_Tp, _Alloc>::value_type = 
boost::tuples::tuple >, std::vector > >]'
   push_back(value_type&& __x)
   ^
/usr/include/c++/8/bits/stl_vector.h:1090:7: note:   no known conversion for 
argument 1 from 'GappedMatchRecord*' to 
'std::vector >, std::vector > > >::value_type&&' {aka 
'boost::tuples::tuple >, std::vector > >&&'}
make[3]: *** [Makefile:1070: repeatoire.o] Error 1

Bug#913082: autopkgtest: support multi-arch test dependencies

Hi Martin,

On 18-11-18 21:21, Martin Pitt wrote:
> Paul Gevers [2018-11-18 19:48 +0100]:
> It's less about "options" but more which foreign architectures are enabled in
> the testbeds.

If I understand correctly, your fix for this bug only enables pulling
packages from foreign architectures if those architectures are otherwise
enabled in the testbed.

> The common case is certainly to pull in i386 dependencies on
> amd64, and if there's a good case to be made for it, our amd64 containers 
> could
> certainly grow a "dpkg --add-architecture i386" (unless they already have it).

They don't.

> Other than that, tests of course always have the option to do that manually,
> and install the foreign-arch dependency manually with apt-get instead of
> d/t/control Depends:.

Well, but if tests go the manual way, they don't need the fix to this
bug anyways. Also, I really recommend against manual apt-getting except
when apt-getting is part of the functionality that the package provides.
I have seen multiple packages that get it wrong because the testbed of
us (and Ubuntu) is weird because we mix unstable and testing and have
the apt pinning in place. Autopkgtests shouldn't need to know the
details of our set-up, especially because we may want or need to change
them (like my attempt with disable-apt-fallback).

So, I rather keep this bug open until autopkgtest really supports
multi-arch test dependencies. (Of course your fix is still valuable in
it's own right, I just don't think it fixes this bug).

Paul

Bug#913082: autopkgtest: support multi-arch test dependencies

2018-11-18 Thread Martin Pitt

Hello Paul,

Paul Gevers [2018-11-18 19:48 +0100]:
> I wonder if this is enough for what Alexandre is looking for. With this
> change one can run ones own autopkgtest with the right options set (like
> in the test case) but this isn't enough to work in frameworks like
> ci.d.n IIUC. E.g. I think if we really want to support this, there
> should be a way to add the required architectures automatically somehow.

It's less about "options" but more which foreign architectures are enabled in
the testbeds. The common case is certainly to pull in i386 dependencies on
amd64, and if there's a good case to be made for it, our amd64 containers could
certainly grow a "dpkg --add-architecture i386" (unless they already have it).

Other than that, tests of course always have the option to do that manually,
and install the foreign-arch dependency manually with apt-get instead of
d/t/control Depends:.

Martin

Bug#717563:

2018-11-18 Thread Kay Mccormick

debianbts.get_bugs does not support passing of proxy into SoapClient.
I would try to fix this but I am not sure right now of the correct approach.

pysimplesoap uses httplib2 if it is available and if a specific transport
library is not specified in the call to get_http_wrapper, which it is not
in this application.

See patch above for other changes to reportbug to support proxy handling.
Take note that the patch sets the proxy for 'https' to the proxy specified
for 'http'. Reportbug itself only allows to specify a single proxy for
http, so this was required to support proxying for https.

Probably another argument should be added to reportbug for https proxy
configuration, in order to prevent simply using the http proxy, which may
not be correct.

On the other hand, I believe the environment configuration could be changed
(i.e. stuff the proxy information into os.environ for the duration of the
reportbug session). This would reduce in fewer code changes, which can be
considered a good thing.

I dont know what approach people wish to take, but part of this is a defect
in debianbts which is another package.

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

Am 18.11.18 um 20:46 schrieb John David Anglin:
> On 2018-11-18 1:54 p.m., Michael Biebl wrote:
>> Thanks for your detailed analysis.
>> If there is something to fix on the systemd side, it would be great if
>> you can create a pull request upstream as suggested in
>> https://github.com/systemd/systemd/issues/10548
> There's definitely something that needs fixing but I don't know what it
> is.  It could be in the
> debian build infrastructure or ninja.  It's not at all clear how we get
> both the -fPIE and -fPIC
> options in various compilations.  The don't seem to be explicitly
> specified in the systemd
> package.  Do you know?

Unfortunately not. You could talk to Jussi Pakkanen, our meson
maintainer and upstream of meson, maybe he can help here.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#913811: iptables fails to upgrade from 1.8.1-2 to 1.8.2-1

2018-11-18 Thread Matthew W.S. Bell

For the avoidance of doubt: all shell file test operators act on the target
of symbolic links, except for -h/-L, the test for a file being a symbolic
link.


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

Bug#914048: mirror submission for debian.petarmaric.com

2018-11-18 Thread Petar Maric

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.petarmaric.com
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Petar Maric 
Country: RS Serbia
Location: Novi Sad
Sponsor: Faculty of Technical Sciences, University of Novi Sad 
http://www.ftn.uns.ac.rs/
Comment: INFO_THROUGHPUT=500Mb
 




Trace Url: http://debian.petarmaric.com/debian/project/trace/
Trace Url: 
http://debian.petarmaric.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.petarmaric.com/debian/project/trace/debian.petarmaric.com

Bug#896130: RFP: vim-julia -- Vim plugin for Julia support

2018-11-18 Thread Paulo Henrique de Lima Santana

On Fri, 20 Apr 2018 00:12:37 +0200 "Francesco Poli (wintermute)"
 wrote:
> 
> I think this package may be useful to make the user's life easier,
> while editing Julia code.
> I hope someone will package and maintain it in Debian, it would
> be really great. Thanks to anyone willing to do so!

Hi, could you release a version on github?
It's better to package if there is a version released.

I am studying to package it.

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Membro da Comunidade Curitiba Livre
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas)  
http://www.heforshe.org/pt


pgpoZPHVZyC8A.pgp
Description: PGP signature

Bug#914047: mirror submission for debian.petarmaric.com

2018-11-18 Thread Petar Maric

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.petarmaric.com
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Maintainer: Petar Maric 
Country: RS Serbia
Location: Novi Sad
Sponsor: Faculty of Technical Sciences, University of Novi Sad 
http://www.ftn.uns.ac.rs/
Comment: INFO_THROUGHPUT=500Mb
 




Trace Url: http://debian.petarmaric.com/debian/project/trace/
Trace Url: 
http://debian.petarmaric.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.petarmaric.com/debian/project/trace/debian.petarmaric.com

Bug#914045: qtbase-opensource-src breaks lots of autopkgtests

Source: qtbase-opensource-src
Version: 5.11.2+dfsg-6
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks

Dear maintainers,

With a recent upload of qtbase-opensource-src the autopkgtest of quite a
few packages fail in testing when their autopkgtest are run with the
binary packages of qtbase-opensource-src from unstable. They pass when
run with only packages from testing. In tabular form:
passfail
qtbase-opensource-src from testing5.11.2+dfsg-6
(e.g.) krunner from testing5.49.0-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. I checked
several packages and the error is extremely similar. I have the feeling
that there is a versioned (test) dependency missing somewhere. On the
other hand, I don't know the KDE/Qt stack, so maybe this can/should be
"fixed" by a versioned breaks. I note explicitly that it's the source of
krunner from testing that is build with qtbase-opensource-src from
unstable, while e.g. extra-cmake-modules is still from testing (as it
isn't required by any dependency or breaks relation to come from unstable).

Currently this regression is contributing to the delay of the migration
of qtbase-opensource-src to testing [1]. Due to dependencies, there are
quite a few packages waiting for that migration as well AFAICT. Can you
please investigate the situation.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
qtbase-opensource-src/5.11.2+dfsg-6. I.e. due to versioned dependencies
or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=qtbase-opensource-src

https://ci.debian.net/data/autopkgtest/testing/amd64/k/krunner/1331006/log.gz

CMake Error at src/cmake_install.cmake:119 (file):
file INSTALL cannot find

"/tmp/autopkgtest-lxc.p952k2pe/downtmp/build.LIE/src/obj-x86_64-linux-gnu/src/KF5Runner.qch".
Call Stack (most recent call first):
cmake_install.cmake:88 (include)

make[1]: *** [Makefile:65: install] Error 1
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.p952k2pe/downtmp/build.LIE/src/obj-x86_64-linux-gnu'
dh_auto_install: cd obj-x86_64-linux-gnu && make V=1 -j2 install
DESTDIR=/tmp/autopkgtest-lxc.p952k2pe/downtmp/build.LIE/src/debian/tmp
AM_UPDATE_INFO_DIR=no "INSTALL=install --strip-program=true" returned
exit code 2
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2

signature.asc
Description: OpenPGP digital signature

Bug#909396: systemd: FTBFS on hppa and x32 - relocation can not be used when making a shared object

2018-11-18 Thread John David Anglin


On 2018-11-18 1:54 p.m., Michael Biebl wrote:

Thanks for your detailed analysis.
If there is something to fix on the systemd side, it would be great if
you can create a pull request upstream as suggested in
https://github.com/systemd/systemd/issues/10548
There's definitely something that needs fixing but I don't know what it 
is.  It could be in the
debian build infrastructure or ninja.  It's not at all clear how we get 
both the -fPIE and -fPIC
options in various compilations.  The don't seem to be explicitly 
specified in the systemd

package.  Do you know?

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#912819: llvm-toolchain-7: FTBFS on hurd-i386

Hello,

Le 18/11/2018 à 14:09, Samuel Thibault a écrit :
> FI, here are the patches I am currently using to get the package built.
> D54378 and 54379 are still being discussed upstream, and the last two
> still need to be cleaned and submitted upstream.


Would be nice if you could do a MR on salsa!

Thanks
S

Bug#816277: gawk: Invalid program crashes the parser

2018-11-18 Thread Stefan Tatschner

On Mon, 29 Feb 2016 11:53:19 + Steve Kemp 
wrote:
> Package: gawk
> Version: 1:4.1.1+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> The following wonderful program causes an immediate segfault in the
parse-process of gawk:
> 
> for (i = ) in foo bar baz
> 

I did some AFL experiments and I found a shorter one:

  ()in a

awk -f out/crashes/id:00,sig:06,src:02,op:havoc,rep:2.min
awk: out/crashes/id:00,sig:06,src:02,op:havoc,rep:2.min:1: ()in a
awk: out/crashes/id:00,sig:06,src:02,op:havoc,rep:2.min:1:  ^ syntax 
error
awk: out/crashes/id:00,sig:06,src:02,op:havoc,rep:2.min:1: fatal error: 
internal error: segfault
fish: “awk -f out/crashes/id:00,si…” terminated by signal SIGABRT (Abort)

Stefan

Bug#770128: (no subject)

Agreed, and further I am having trouble with reportbug and SElinux, which makes
reporting bugs impossible for me right now. However, I am not sure how this
would work - running ssh to collect information about packages instlled on
the remote system, etc? how might this be implemented?

Bug#914002: qtcreator's clang code model appears to be broken with kit = clang

Le 18/11/2018 à 20:06, Lisandro Damián Nicanor Pérez Meyer a écrit :
> clone 914002 -1
> reassign -1 src:llvm-toolchain-7 1:7.0.1~+rc2-4
> affects -1 qtcreator
> thanks
> 
> El domingo, 18 de noviembre de 2018 10:18:03 -03 Adam Majer escribió:
>> On 2018-11-18 12:30 p.m., Roman Lebedev wrote:
>>> If kit is clang (tried with both the clang 7, and llvm trunk),
>>> the parsing appears to fail, pretty much all the C++ std:: symbols
>>> are underscored, and marked as not found.
>>>
>>> ii  libclang1-71:7.0.1~+rc2-4
>>
>> The problem is clang. Clang in Testing works just fine. When I upgraded Qt
>> Creator, all is fine. But as soon as clang was updated, it breaks.
>> Downgrading to clang 1:7-6 fixes the problem.
>>
>> Looks like regression caused by clang 1:7.0.1~+rc2-4 and related.
> 
> Cloning the bug so. Hope I've got the right bts invocations.
Can you try if rebuilding qtcreator against this version of clang fixes the 
issue or not?

Thanks
S




signature.asc
Description: OpenPGP digital signature

Bug#914046: ircd-hybrid: Hangs indefinitely during install

2018-11-18 Thread Genomian

Package: ircd-hybrid
Version: 1:8.2.21+dfsg.1-1
Severity: important

Dear Maintainer,
during install (dpkg --configure) postinst hangs, it seems because of service 
starting,
since from what I've seen typing # service irc-hybrid stop in another console 
fix the problem

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 9.4 (stretch)
Release:9.4
Codename:   stretch
Architecture: armv7l

Kernel: Linux 4.14.79-v7+ (SMP w/4 CPU cores)
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: sysvinit (via /sbin/init)

Versions of packages ircd-hybrid depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3
ii  libgeoip1  1.6.9-4
ii  libgnutls303.5.8-5+deb9u3
ii  libltdl7   2.4.6-2
ii  lsb-base   9.20161125+rpi1
ii  openssl1.1.0f-3+deb9u2

Versions of packages ircd-hybrid recommends:
ii  whois  5.2.17~deb9u1

Versions of packages ircd-hybrid suggests:
pn  anope  

-- Configuration Files:
/etc/ircd-hybrid/cert.cnf [Errno 13] Permission denied: 
'/etc/ircd-hybrid/cert.cnf'
/etc/ircd-hybrid/ircd.conf [Errno 13] Permission denied: 
'/etc/ircd-hybrid/ircd.conf'
/etc/ircd-hybrid/ircd.motd [Errno 13] Permission denied: 
'/etc/ircd-hybrid/ircd.motd'

-- debconf-show failed

Bug#717563: (no subject)

diff --git a/reportbug/checkversions.py b/reportbug/checkversions.py
index d94bf76..c37399d 100644
--- a/reportbug/checkversions.py
+++ b/reportbug/checkversions.py
@@ -84,7 +84,7 @@ def get_versions_available(package, timeout, dists=None, http_proxy=None, arch='
 # or to binary packages available on the current arch
 url += '=source,all,' + arch
 try:
-page = open_url(url)
+page = open_url(url, http_proxy, timeout)
 except NoNetwork:
 return {}
 except urllib.error.HTTPError as x:
diff --git a/reportbug/urlutils.py b/reportbug/urlutils.py
index c16e48c..a3f2e20 100644
--- a/reportbug/urlutils.py
+++ b/reportbug/urlutils.py
@@ -146,6 +146,7 @@ def open_url(url, http_proxy=None, timeout=60):
 proxies = urllib.request.getproxies()
 if http_proxy:
 proxies['http'] = http_proxy
+proxies['https'] = http_proxy
 
 try:
 page = urlopen(url, proxies, timeout)

Bug#717563: (no subject)

diff --git a/reportbug/checkversions.py b/reportbug/checkversions.py
index d94bf76..c37399d 100644
--- a/reportbug/checkversions.py
+++ b/reportbug/checkversions.py
@@ -84,7 +84,7 @@ def get_versions_available(package, timeout, dists=None, http_proxy=None, arch='
 # or to binary packages available on the current arch
 url += '=source,all,' + arch
 try:
-page = open_url(url)
+page = open_url(url, http_proxy, timeout)
 except NoNetwork:
 return {}
 except urllib.error.HTTPError as x:
diff --git a/reportbug/urlutils.py b/reportbug/urlutils.py
index c16e48c..a3f2e20 100644
--- a/reportbug/urlutils.py
+++ b/reportbug/urlutils.py
@@ -146,6 +146,7 @@ def open_url(url, http_proxy=None, timeout=60):
 proxies = urllib.request.getproxies()
 if http_proxy:
 proxies['http'] = http_proxy
+proxies['https'] = http_proxy
 
 try:
 page = urlopen(url, proxies, timeout)

Bug#914044: HOME=/tmp kbuildsycoca5 is bad

2018-11-18 Thread Helmut Grohne

Source: tuxpaint
Version: 1:0.9.23-1
Severity: important
Tags: security

tuxpaint runs "HOME=/tmp kbuildsycoca5" during build. I'm not exactly
sure what this does, but I see a number of issues with doing so:

 * kbuildsycoca5 reads /tmp/.config/QtProject/qtlogging.ini. I'm not
   sure whether that can be turned into a privilege escalation.
 * kbuildsycoca5 reads various locales from /tmp. Again I'm not sure
   whether malicious locales could be used to take over the process.
 * kbuildsycoca5 tries to create a directory /tmp/.cache. If that
   location is occupied with a regular file, the build fails (FTBFS).
 * kbuildsycoca5 reads /tmp/.config/kbuildsycoca5rc.

This looks like plenty of surface and the chances that this code is
fully covered against that scenario are dim. It seems very likely, that
a privilege escalation is underneath. Using HOME=/tmp looks like a
recipe for desaster.

I question the need to call this at all during a package build.
kbuildsycoca5 is meant to modify a per-user cache, but that cache is not
installed into the binary package. Possibly removing the command is the
simplest fix.

Helmut

Bug#913581: Bug still present

2018-11-18 Thread Er_Maqui

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

After a full reinstallation with gitlab 11.1.8, bug is still present.

Here is the final install log with the error:

Running rake checks...
Check if Gitlab is configured correctly...
Checking GitLab Shell ...

GitLab Shell version >= 7.1.4 ? ... OK (7.2.0)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by gitlab:root, or gitlab:gitlab?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ... can't check, you have no projects
Running /usr/share/gitlab-shell/bin/check
Check GitLab API access: FAILED. code: 401
gitlab-shell self-check failed
  Try fixing it:
  Make sure GitLab is running;
  Check the gitlab-shell configuration file:
  sudo -u gitlab -H editor /usr/share/gitlab-shell/config.yml
  Please fix the error above and rerun the checks.

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Reply by email is disabled in config/gitlab.yml
Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads
folder yet)
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have namespace: ... can't check, you have no projects
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.3 ? ... yes (2.5.1)
Git version >= 2.9.5 ? ... yes (2.19.1)
Git user has default SSH configuration? ... yes
Active users: ... 0

Checking GitLab ... Finished

Please, give a hand with this, these error are present since firsts 10.x
packaged versions.


Thanks,


https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQIUZK8y555KYqDrRx8WMDgQjPp8gUCW/G23wAKCRB8WMDgQjPp
8vTJAKDfcEhL8Tkhm2LMFFaNWzJcXtpHDgCgvH8LSGVXzjPYkrL6Y1BdTV3m8ww=
=t+4i
-END PGP SIGNATURE-

Bug#914043: boost-defaults breaks boost1.62 autopkgtest