Bug#924899: 8080/tcp is already in use

[Harald Dunkel]

Package: monitorix
Version: 3.10.1-1
Severity: wishlist

Monitorix providing its own web service is surely a major
improvement, but using port 8080/tcp per default has a high
chance to introduce a conflict with other tools, esp. on
test systems run by unprivileged users. Port 8080/tcp is
the first port they use.

I would highly recommend to choose another default port
for monitorix' web service, e.g. /tcp. Of course this
might conflict, too, but port 8080 is in *very* wide use.


Regards
Harri

Bug#924748: unblock: shibboleth-sp/3.0.4+dfsg1-1

[wferi]

Control: tag -1 - moreinfo

Jonathan Wiltshire  writes:

> Please go ahead and remove the moreinfo tag when it is ready to unblock.

Thanks, uploaded.  Looks like Niels has already unblocked it, but I'm
removing the moreinfo tag nevertheless.
-- 
Regards,
Feri

Bug#886731: linux-image-4.9.0-4-amd64: DKMS sends system in suspend since linux-image-4.9.0-3-amd64

[Marc-Robin Wendt]

Hello Michael,

no, I'm using Intel driver and cards. i915 is loaded.
Problem is not solved anyway. I helped myself in disabling automatic
suspend at all and have to do it manually now.

Greetings
Marc-Robin

On Mon, 2019-03-18 at 00:15 +0100, Michael Biebl wrote:
> Picking up this old bug report...
> 
> 
> Are you using the proprietary nvidia driver or noveau?
> 

Bug#924900: unblock: libzip/1.5.1-4

[Ondřej Surý]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package libzip

libzip 1.5.1-4 contains fix for upstream issue that
can result in corrupted archive, I was poked by upstream
to fix this in Debian buster:

> We've fixed a serious bug in AES encryption today. With some
> particular file sizes the HMAC would not be written, and incomplete
> files were in the archive.

Thanks,
Ondrej

unblock libzip/1.5.1-4

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

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

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlyPVFpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcIEcQ//V14C6SH49m2im4pTgZJWqu2LY9w/rQzWC0dNq6LX6EQDorrh2x+ntvMf
DtuDK8dKdcpBQsbUVdUueaHP1UjdK31GDLFB5ITW19yO3ohdc87rWKH+Uyk7r1rO
pogWyLp20W0WPfIStn2+RdnVGZ7JavVoe5n8htIKoKgG341EauJcRVg1Mmdpzn75
xMePY4/J6XA5XDIl5IHieNjwEx6o0ALQE+oEa9IIt2aUtLzCNXVm1fTvSigXa31n
I0lsbnblrp5HdK/a2vADXtmHTicli9hqhj/7btGPp29WuCaYmjfteUfnsuX6S8mh
ySm/S+Ar0ijB1N4y2xIgXkFdSailWm8b7TE3x6rJGcxJ/tb765j1xC77XrRPydqr
Gt3jOg5o2UogYGdVrfBg1szM5zUv2RzSrJj7JZ/VGs1UObj0kqTV0TcMmTcheO4p
9dCZP6fMdagOsTNXDPV8zzdEn2eOn6E7IBE7tL8cXk/YddouP4S6kh6SroGQERuB
Xh6V8ZAzFXx/9xXNYmnWHFgprYbVBRpXL78Fs4fZZq3oO28UdCKg9zpG8kX8lLxQ
XS7rxt3sxcX1ngAS13tBOkWoVOmerZD0nbdRicu2MlP+4Eh30AUI6cqEpbb6pVl+
brQzvxOqVhkPLwgyiylvyt/8sMpaVMbN/z/hOZmnSihiLf0EROg=
=9+Ee
-END PGP SIGNATURE-

Bug#924792: pidof: unsanitized user input makes pidof crash

[Ian Campbell]

On Sun, 2019-03-17 at 19:06 +0100, Matteo Croce wrote:
> #571590 added the '-f' argument to pidof, which allows to specify an
> arbitrary format string for the PIDs.
> Unfortunately this is broken, because passing plain user input to
> printf() can easily exploited:

What's the attack vector here (making this an exploit rather than
"just" a bug)?

Wouldn't you need to have some process which was passing untrusted data
directly to the `-f` argument, is that likely in the real world?

Ian.

Bug#924901: Chromium ignores SIGTERM even when respective settings are turned off.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: chromium
Version: 72.0.3626.122-1~deb9u1

Even with "Continue running background apps when Chromium is closed" option 
turned off in settings,
Chromium still runs in the background when I close all tabs, close the entire 
window, or choose "Exit" in the menu.
As seen on the attached screenshot.
Even worse, the residual process does not accept SIGTERM, thus wasting cycles 
and RAM. SIGKILL still works, though.
Maybe this (mis-)feature is good for some users, but if you offer an option 
there and I turned it off, it should respect that.
---
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a terminal.
Thanks for your co-operation.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcj1jHAAoJENi1YDlFXXQfPooH/0SiLMNXFLme6HyGEmOg
RnmP9JX1OEebzIQnhLuvl5CwVhRhw6A967DoSUouqwiSxwe4GfRNfXuQxlTr
Yd7/PC1M9kHbRQeRm7dA0GLSYSdgv4Kf5xQPXHpFxDx2KfhgS5F8vhWkdcnm
yVJGlrV7ZQYCFziyXsirodZlzf/J09qAFgv5dsc18GjRIL/NAh9wztkrP5pl
4BlRa3WXJC+0vmg3PIN6Z1ZTNVgCOVY1ONCLe1vyJ0jS/dq7Drn9d2CwqMpz
LYCUf/fYD/zZHQH1+1n4hcJlpix55rXdiAi8TcnIUJ0KvXJq1aIE2tjnVz2B
BGdM4UNZF5wAAGxgp9D+6xk=
=dp2P
-END PGP SIGNATURE-



2019-03-18-162629_1600x1200_scrot.png.sig
Description: PGP signature


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#924902: unblock: libstatgen/1.0.14-5

[Andreas Tille]

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

Please unblock package libstatgen


diff -Nru libstatgen-1.0.14/debian/changelog libstatgen-1.0.14/debian/changelog
--- libstatgen-1.0.14/debian/changelog  2018-12-08 17:20:08.0 +0100
+++ libstatgen-1.0.14/debian/changelog  2019-03-18 09:34:14.0 +0100
@@ -1,3 +1,12 @@
+libstatgen (1.0.14-5) unstable; urgency=medium
+
+  * Team upload.
+  * Rebuild for new version of gcc to fix symbols
+Closes: #924819
+  * Standards-Version: 4.3.0
+
+ -- Andreas Tille   Mon, 18 Mar 2019 09:34:14 +0100
+
 libstatgen (1.0.14-4) unstable; urgency=medium

   * Restrict arch to any-amd64 only, not design for other arches.
diff -Nru libstatgen-1.0.14/debian/control libstatgen-1.0.14/debian/control
--- libstatgen-1.0.14/debian/control2018-12-08 17:20:08.0 +0100
+++ libstatgen-1.0.14/debian/control2019-03-18 09:34:14.0 +0100
@@ -8,7 +8,7 @@
libssl-dev,
zlib1g-dev,
d-shlibs
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/libstatgen
 Vcs-Git: https://salsa.debian.org/med-team/libstatgen.git
 Homepage: https://genome.sph.umich.edu/wiki/C++_Library:_libStatGen
diff -Nru libstatgen-1.0.14/debian/libstatgen0.symbols 
libstatgen-1.0.14/debian/libstatgen0.symbols
--- libstatgen-1.0.14/debian/libstatgen0.symbols2018-12-08 
17:20:08.0 +0100
+++ libstatgen-1.0.14/debian/libstatgen0.symbols2019-03-18 
09:34:14.0 +0100
@@ -128,6 +128,9 @@
  (c++)"VectorFunc::VectorFunc(double (*)(Vector&))@Base" 1.0.14
  (c++)"VectorFunc::VectorFunc()@Base" 1.0.14
  (c++)"VectorFunc::~VectorFunc()@Base" 1.0.14
+ 
_ZNSt6vectorIfSaIfEE17_M_realloc_insertIJRKfEEEvN9__gnu_cxx17__normal_iteratorIPfS1_EEDpOT_@Base
 1.0.14
+ 
_ZNSt6vectorIfSaIfEE17_M_realloc_insertIJfEEEvN9__gnu_cxx17__normal_iteratorIPfS1_EEDpOT_@Base
 1.0.14
+ 
_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 1.0.14
  (c++)"VectorFunc::~VectorFunc()@Base" 1.0.14
  (c++)"VectorFunc::~VectorFunc()@Base" 1.0.14
  (c++)"glfHandler::EndSection()@Base" 1.0.14
@@ -2011,7 +2014,6 @@
  (c++)"std::vector 
>::_M_fill_insert(std::_Bit_iterator, unsigned long, bool)@Base" 1.0.14
  (c++)"void std::vector 
>::emplace_back(char&&)@Base" 1.0.14
  (c++)"void std::vector >::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, char const&)@Base" 1.0.14
- (c++)"void std::vector 
>::emplace_back(float&&)@Base" 1.0.14
  (c++)"void std::vector 
>::emplace_back(unsigned char&&)@Base" 1.0.14
  (c++)"void std::vector 
>::_M_range_insert(__gnu_cxx::__normal_iterator >  >, unsigned char*, 
unsigned char*, std::forward_iterator_tag)@Base" 1.0.14
  (c++)"void std::vector 
>::emplace_back(int&&)@Base" 1.0.14



unblock libstatgen/1.0.14-5

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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)

Bug#924903: dh-runit: Use mode 700 for directories inside 'supervise'

[Lorenzo Puliti]

Package: dh-runit
Version: 2.8.9
Severity: wishlist

Hi,

directories inside supervise are shipped with mode 755 for both services and 
log,
but runsv uses mode 700, maybe it's better to use runsv mode?

Alternatively, you can add
/var/lib/runit/supervise
and
/var/lib/runit/log/supervise
to runit directories and do not ship anything inside supervise
with dh_runit, as those directories, if missing, are created by 
runsv as the service is started.

Thanks,
Lorenzo


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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages dh-runit depends on:
ii  debhelper  12.1.1

dh-runit recommends no packages.

dh-runit suggests no packages.

-- no debconf information

Bug#924904: unblock: putty/0.70-6

[Colin Watson]

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

The EU recently funded a bug bounty for PuTTY, and PuTTY 0.71 was
released over the weekend including a large number of security fixes
many of which were found by that.  Since this is too late for buster,
the upstream maintainer kindly sent me a backported patch series which
he recommended that we apply to 0.70, and I uploaded that to unstable
yesterday.  I think we should have this in buster, so please unblock.

(When I last asked, no CVEs had been allocated for any of this yet.)

unblock putty/0.70-6

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
diff -Nru putty-0.70/debian/.git-dpm putty-0.70/debian/.git-dpm
--- putty-0.70/debian/.git-dpm  2018-10-28 17:18:52.0 +
+++ putty-0.70/debian/.git-dpm  2019-03-17 09:36:53.0 +
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-694018afd4da9c7e00c7247c275e44b3aab49d4b
-694018afd4da9c7e00c7247c275e44b3aab49d4b
+1ebfc3bc04d0bbde174da1999a922b491a0e90dd
+1ebfc3bc04d0bbde174da1999a922b491a0e90dd
 8d3b8df5deee84238c92dfa4b4c4e3a787d73b64
 8d3b8df5deee84238c92dfa4b4c4e3a787d73b64
 putty_0.70.orig.tar.gz
diff -Nru putty-0.70/debian/changelog putty-0.70/debian/changelog
--- putty-0.70/debian/changelog 2018-10-28 18:07:45.0 +
+++ putty-0.70/debian/changelog 2019-03-17 09:37:02.0 +
@@ -1,3 +1,22 @@
+putty (0.70-6) unstable; urgency=high
+
+  * Apply security patch series from upstream:
+- New facility for removing pending toplevel callbacks.
+- Fix one-byte buffer overrun in random_add_noise().
+- uxnet: clean up callbacks when closing a NetSocket.
+- sk_tcp_close: fix memory leak of output bufchain.
+- Fix handling of bad RSA key with n=p=q=0.
+- Sanity-check the 'Public-Lines' field in ppk files.
+- Introduce an enum of the uxsel / select_result flags.
+- Switch to using poll(2) in place of select(2).
+- RSA kex: enforce the minimum key length.
+- Fix crash on ESC#6 + combining chars + GTK + odd-width terminal.
+- Limit the number of combining chars per terminal cell.
+- minibidi: fix read past end of line in rule W5.
+- Fix crash printing a width-2 char in a width-1 terminal.
+
+ -- Colin Watson   Sun, 17 Mar 2019 09:37:02 +
+
 putty (0.70-5) unstable; urgency=medium
 
   [ Colin Watson ]
diff -Nru putty-0.70/debian/patches/fix-bad-rsa-key-handling.patch 
putty-0.70/debian/patches/fix-bad-rsa-key-handling.patch
--- putty-0.70/debian/patches/fix-bad-rsa-key-handling.patch1970-01-01 
01:00:00.0 +0100
+++ putty-0.70/debian/patches/fix-bad-rsa-key-handling.patch2019-03-17 
09:36:52.0 +
@@ -0,0 +1,48 @@
+From 475366539d4bf768567b635782c577cdfde40026 Mon Sep 17 00:00:00 2001
+From: Simon Tatham 
+Date: Wed, 6 Feb 2019 21:09:29 +
+Subject: Fix handling of bad RSA key with n=p=q=0.
+
+In this situation, rsa_verify won't notice anything wrong until it
+gets to the point where decbn() tries to subtract 1 from p, and
+underruns the Bignum buffer.
+
+Just in case some other attack vector reaches that same problem point,
+I've also put a protective assertion in decbn() itself just before the
+memory overwrite would have happened.
+
+Last-Update: 2019-03-16
+
+Patch-Name: fix-bad-rsa-key-handling.patch
+---
+ sshbn.c  | 1 +
+ sshrsa.c | 4 
+ 2 files changed, 5 insertions(+)
+
+diff --git a/sshbn.c b/sshbn.c
+index 6768204b..b21797f0 100644
+--- a/sshbn.c
 b/sshbn.c
+@@ -1400,6 +1400,7 @@ void decbn(Bignum bn)
+ int i = 1;
+ while (i < (int)bn[0] && bn[i] == 0)
+   bn[i++] = BIGNUM_INT_MASK;
++assert(i < (int)bn[0]);
+ bn[i]--;
+ }
+ 
+diff --git a/sshrsa.c b/sshrsa.c
+index e565a64a..1dbf16bf 100644
+--- a/sshrsa.c
 b/sshrsa.c
+@@ -411,6 +411,10 @@ int rsa_verify(struct RSAKey *key)
+ Bignum n, ed, pm1, qm1;
+ int cmp;
+ 
++/* n cannot be zero. */
++if (!bignum_cmp(key->modulus, Zero))
++return 0;
++
+ /* n must equal pq. */
+ n = bigmul(key->p, key->q);
+ cmp = bignum_cmp(n, key->modulus);
diff -Nru putty-0.70/debian/patches/fix-double-width-crash.patch 
putty-0.70/debian/patches/fix-double-width-crash.patch
--- putty-0.70/debian/patches/fix-double-width-crash.patch  1970-01-01 
01:00:00.0 +0100
+++ putty-0.70/debian/patches/fix-double-width-crash.patch  2019-03-17 
09:36:53.0 +
@@ -0,0 +1,46 @@
+From 1ebfc3bc04d0bbde174da1999a922b491a0e90dd Mon Sep 17 00:00:00 2001
+From: Simon Tatham 
+Date: Thu, 14 Mar 2019 18:13:01 +
+Subject: Fix crash printing a width-2 char in a width-1 terminal.
+
+If the terminal is one column wide, it's not possible to print a
+double-width CJK character at all - it won't fit. Replace it with
+U+FFFD to indicate that impossibility.
+
+The previous behaviour was to notice that we're in the rightmost
+column of the terminal, and invoke the LATTR_WRAPPED2 special case to
+wrap

Bug#924905: unblock: libayatana-indicator/0.6.2-3

[Mike Gabriel]

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

Please unblock package libayatana-indicator

+  * debian/control:
++ Drop D (libayatana-indicator3-dev) on libayatana-indicator-dev.
+  This caused build-envs to pull in the full GTK-2+ build stack when
+  only GTK-3+ was required. (Closes: #924879).

This reduces the build chroot size of all src:pkgs build-depending on
libayatana-indicator3-dev.

unblock libayatana-indicator/0.6.2-3

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libayatana-indicator-0.6.2/debian/changelog 
libayatana-indicator-0.6.2/debian/changelog
--- libayatana-indicator-0.6.2/debian/changelog 2018-08-14 19:06:59.0 
+0200
+++ libayatana-indicator-0.6.2/debian/changelog 2019-03-18 10:22:30.0 
+0100
@@ -1,3 +1,12 @@
+libayatana-indicator (0.6.2-3) unstable; urgency=medium
+
+  * debian/control:
++ Drop D (libayatana-indicator3-dev) on libayatana-indicator-dev.
+  This caused build-envs to pull in the full GTK-2+ build stack when
+  only GTK-3+ was required. (Closes: #924879).
+
+ -- Mike Gabriel   Mon, 18 Mar 2019 10:22:30 +0100
+
 libayatana-indicator (0.6.2-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru libayatana-indicator-0.6.2/debian/control 
libayatana-indicator-0.6.2/debian/control
--- libayatana-indicator-0.6.2/debian/control   2018-08-14 19:06:59.0 
+0200
+++ libayatana-indicator-0.6.2/debian/control   2018-12-18 20:32:54.0 
+0100
@@ -66,7 +66,6 @@
  ${misc:Depends},
  libgtk-3-dev (>= 2.91.3),
  libayatana-indicator3-7 (= ${binary:Version}),
- libayatana-indicator-dev (= ${binary:Version}),
 Description: panel indicator applet - library development files (GTK-3+)
  The Ayatana Indicators library contains information to build indicators
  to go into modern desktops' indicator applets.

Bug#924906: valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed.

[Jeffrey Walton]

Package: valgrind
Version: 1:3.12.0~svn20160714-1+b1
Severity: serious
Tags: upstream
Justification: 4

Dear Maintainer,

   * What led up to the situation?

 valgrind ./myprog
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 Looks like an upstream bug that was fixed: 
https://bugs.kde.org/show_bug.cgi?id=362935
 
-- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Versions of packages valgrind depends on:
ii  libc6  2.24-11+deb9u4
ii  libc6-dbg  2.24-11+deb9u4

Versions of packages valgrind recommends:
ii  gdb   7.12-6
pn  valgrind-dbg  

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

Bug#924907: unblock: gatb-core/1.4.1+git20181225.44d5a44+dfsg-2

[Andreas Tille]

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

Please unblock package gatb-core



  * Rebuild for new version of gcc to fix symbols
Closes: #924849

 -- Andreas Tille   Mon, 18 Mar 2019 09:45:17 +0100



unblock gatb-core/1.4.1+git20181225.44d5a44+dfsg-2

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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)
diff -Nru gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/changelog 
gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/changelog
--- gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/changelog   2019-01-24 
11:50:33.0 +0100
+++ gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/changelog   2019-03-18 
09:45:17.0 +0100
@@ -1,3 +1,10 @@
+gatb-core (1.4.1+git20181225.44d5a44+dfsg-2) unstable; urgency=medium
+
+  * Rebuild for new version of gcc to fix symbols
+Closes: #924849
+
+ -- Andreas Tille   Mon, 18 Mar 2019 09:45:17 +0100
+
 gatb-core (1.4.1+git20181225.44d5a44+dfsg-1) unstable; urgency=medium
 
   * New upstream checkout
diff -Nru 
gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/libgatbcore2.symbols.amd64 
gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/libgatbcore2.symbols.amd64
--- gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/libgatbcore2.symbols.amd64  
2019-01-24 11:50:33.0 +0100
+++ gatb-core-1.4.1+git20181225.44d5a44+dfsg/debian/libgatbcore2.symbols.amd64  
2019-03-18 09:45:17.0 +0100
@@ -159,6 +159,7 @@
  _ZN19AbstractHeaderCoderD1Ev@Base 1.4.1
  _ZN19AbstractHeaderCoderD2Ev@Base 1.4.1
  _ZN3dag10dag_vector9push_backEm@Base 1.4.1
+ _ZN3dag10dag_vectoraSERKS0_@Base 1.4.1+git20181225.44d5a44+dfsg
  _ZN3dag11rank_vector9add_blockEv@Base 1.4.1
  _ZN3dag11rank_vectorC1ERKS0_@Base 1.4.1
  _ZN3dag11rank_vectorC2ERKS0_@Base 1.4.1
@@ -437,7 +438,6 @@
  
_ZN4gatb4core4kmer4impl12BloomBuilderILm64EE5buildEPNS0_5tools2dp8IteratorINS2_4KmerILm64EE5CountEEEPNS5_4misc11IPropertiesE@Base
 1.4.1
  
_ZN4gatb4core4kmer4impl12BloomBuilderILm96EE5buildEPNS0_5tools2dp8IteratorINS2_4KmerILm96EE5CountEEEPNS5_4misc11IPropertiesE@Base
 1.4.1
  _ZN4gatb4core4kmer4impl12KxmerPointerILm128EE4nextEv@Base 1.4.1
- _ZN4gatb4core4kmer4impl12KxmerPointerILm32EE4nextEv@Base 1.4.1
  _ZN4gatb4core4kmer4impl12KxmerPointerILm64EE4nextEv@Base 1.4.1
  
_ZN4gatb4core4kmer4impl12KxmerPointerILm64EEC1EPPNS0_5tools4math8LargeIntILi2EEEiPmPPt@Base
 1.4.1
  
_ZN4gatb4core4kmer4impl12KxmerPointerILm64EEC2EPPNS0_5tools4math8LargeIntILi2EEEiPmPPt@Base
 1.4.1
@@ -458,12 +458,7 @@
  _ZN4gatb4core4kmer4impl12SampleRepartILm96EED0Ev@Base 1.4.1
  _ZN4gatb4core4kmer4impl12SampleRepartILm96EED1Ev@Base 1.4.1
  _ZN4gatb4core4kmer4impl12SampleRepartILm96EED2Ev@Base 1.4.1
- 
_ZN4gatb4core4kmer4impl12SuperKReaderILm128EEC1EmPmPPNS0_5tools4math8LargeIntILi4EEES5_PPtm@Base
 1.4.1
- 
_ZN4gatb4core4kmer4impl12SuperKReaderILm128EEC2EmPmPPNS0_5tools4math8LargeIntILi4EEES5_PPtm@Base
 1.4.1
  
_ZN4gatb4core4kmer4impl12SuperKReaderILm128EEclERNS0_5tools4math8LargeIntILi4EEE@Base
 1.4.1
- 
_ZN4gatb4core4kmer4impl12SuperKReaderILm64EEclERNS0_5tools4math8LargeIntILi2EEE@Base
 1.4.1
- 
_ZN4gatb4core4kmer4impl12SuperKReaderILm96EEC1EmPmPPNS0_5tools4math8LargeIntILi3EEES5_PPtm@Base
 1.4.1
- 
_ZN4gatb4core4kmer4impl12SuperKReaderILm96EEC2EmPmPPNS0_5tools4math8LargeIntILi3EEES5_PPtm@Base
 1.4.1
  
_ZN4gatb4core4kmer4impl12SuperKReaderILm96EEclERNS0_5tools4math8LargeIntILi3EEE@Base
 1.4.1
  
_ZN4gatb4core4kmer4impl13Configuration4loadERNS0_5tools7storage4impl5GroupE@Base
 1.4.1
  
_ZN4gatb4core4kmer4impl13Configuration4saveERNS0_5tools7storage4impl5GroupE@Base
 1.4.1
@@ -799,6 +794,7 @@
  _ZN4gatb4core4kmer4impl18CountProcessorDumpILm128EE7endPartEmm@Base 1.4.1
  
_ZN4gatb4core4kmer4impl18CountProcessorDumpILm128EE7processEmRKNS0_5tools4math8LargeIntILi4EEERKSt6vectorIiSaIiEEi@Base
 1.4.1
  _ZN4gatb4core4kmer4impl18CountProcessorDumpILm128EE9beginPartEmmmPKc@Base 
1.4.1
+ 
_ZN4gatb4core4kmer4impl18CountProcessorDumpILm128EEC1ERNS0_5tools7storage4impl5GroupEmPNS0_6system13ISynchronizerEPNS7_9PartitionINS2_4KmerILm128EE5CountEEEm@Base
 1.4.1+git20181225.44d5a44+dfsg
  _ZN4gatb4core4kmer4impl18CountProcessorDumpILm128EED0Ev@Base 1.4.1
  _ZN4gatb4core4kmer4impl18CountProcessorDumpILm128EED1Ev@Base 1.4.1
  
_ZN4gatb4core4kmer4impl18CountProcessorDumpILm32EE12finishClonesERSt6vectorIPNS1_15ICountProcessorILm32EEESaIS8_EE@Base
 1.4.1
@@ -815,6 +811,7 @@
  _ZN4gatb4core4kmer4impl18CountProcessorDumpILm64EE7endPartEmm@Base 1.4.1
  
_ZN4gatb4core4kmer4impl18CountProcessorDumpILm64EE7processEmRKNS0_5tools4math8LargeIntILi2EEERKSt6vectorIiSaIiEEi@Base
 1.4.1
  _ZN4gatb4core4kmer4impl18CountProcessorDumpILm64EE9beginPartEmmmPKc@Base 1.4.1
+ 
_ZN4gatb4core4

Bug#924908: RM: qgis [armhf] -- ROM; FTBFS on armhf

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove qgis from armhf, it FTBFS due to a segfault.

Kind Regards,

Bas

Bug#924909: texlive-fonts-extra: dpkg install texlive-fonts-extra_2018.20190227-1_all.deb hangs

[ael]

Package: texlive-fonts-extra
Version: 2018.20190131-1
Severity: normal

Quick report: an apt-get upgrade hangs when installing
texlive-fonts-extra_2018.20190227-1_all.deb. Neede tp kill process.

Running 
dpkg -i /var/cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb
directly also hangs in same way. Actually it looks like a crash:-
Running with
dpkg -i -D10 /var/cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb

The process runs for many minutes and then appears to crash (the screen
also blanks and has to be restored).
The last messages are:
-
D10: path_remove_tree '/usr/share/texlive/texmf-dist/tex/plain/ly1.dpkg-tmp'
D10: path_remove_tree 
'/usr/share/texlive/texmf-dist/tex/plain/ly1/texnansi.tex.dpkg-tmp'
D10: path_remove_tree 
'/usr/share/texlive/texmf-dist/tex/plain/semaphor.dpkg-tmp'
D10: path_remove_tree 
'/usr/share/texlive/texmf-dist/tex/plain/semaphor/semaf.tex.dpkg-tmp'
D10: path_remove_tree '/var.dpkg-tmp'
D10: path_remove_tree '/var/lib.dpkg-tmp'
D10: path_remove_tree '/var/lib/tex-common.dpkg-tmp'
D10: path_remove_tree '/var/lib/tex-common/fontmap-cfg.dpkg-tmp'
D10: path_remove_tree '/var/lib/tex-common/fontmap-cfg/texlive.dpkg-tmp'
D10: path_remove_tree 
'/var/lib/tex-common/fontmap-cfg/texlive/texlive-fonts-extra.cfg.dpkg-tmp'
D10: path_remove_tree '/var/lib/dpkg/tmp.ci'
D10: path_remove_tree running rm -rf '/var/lib/dpkg/tmp.ci'
D10: path_remove_tree '/var/lib/dpkg/reassemble.deb'
dpkg: dependency problems prevent configuration of texlive-fonts-extra:
 texlive-fonts-extra depends on texlive-base (>= 2018.20190227); however:
  Package texlive-base is not configured yet.

dpkg: error processing package texlive-fonts-extra (--install):
 dependency problems - leaving unconfigured
Processing triggers for tex-common (6.11) ...
Running mktexlsr. This may take some time... done.
texlive-base is not ready, delaying updmap-sys call
update-language: texlive-base not installed and configured, doing nothing!
texlive-base is not ready, skipping fmtutil --all call
Errors were encountered while processing:
 texlive-fonts-extra



##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1245 Mar 11 14:29 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 14:28 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  2 02:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  2 02:27 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Mar 11 14:28 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  2 02:27 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Mar  2 02:27 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2968 Mar 11 14:28 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 May 30  2014 mktex.cnf
-rw-r--r-- 1 root root 475 Mar 11 14:28 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-fonts-extra depends on:
it  tex-common6.11
iu  texlive-base  2018.20190227-2

Versions of packages texlive-fonts-extra recommends:
ii  fonts-adf-accanthis0.20110505-3
ii  fonts-adf-berenis  0.20110505-3
ii  fonts-adf-gillius  0.20110505-3
ii  fonts-adf-universalis  0.20110505-3
ii  fonts-cabin1.5-2
ii  fonts-comfortaa3.001-2
ii  fonts-croscore 20181227-1
ii  fonts-crosextra-caladea20130214-2
ii  fonts-crosextra-carlito20130920-1
ii  fonts-dejavu-core  2.37-1
ii  fonts-dejavu-extra 2.37-1
ii  fonts-ebgaramond   0.016-1
ii  fonts-ebgaramond-extra 0.016-1
ii  fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
ii  fonts-freefont-otf 20120503-9
ii  fonts-freefont-ttf 20120503-9
ii  fonts-gfs-artemisia1.1-5
ii  fonts-gfs-complutum1.1-6
ii  fonts-gfs-didot1.1-6
ii  fonts-gfs-neohellenic  1.1-6
ii  fonts-gfs-olga 1.1-5
ii  fonts-gfs-solomos

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Tim Rühsen]

On 3/17/19 11:11 PM, Daniel Kahn Gillmor wrote:
> On Sun 2019-03-17 13:14:54 +0100, Tim Rühsen wrote:
>> Fixed it by building my own libiconv on MinGW systems. It really is
>> straight forward and possibly no extra Debian package is needed.
> 
> Thanks for the feedback, Tim.  For your fix, are you building libiconv
> itself, or win-iconv for MinGW systems?

Libiconv 1.15 itself from tarball.

If you are interested in the details, have a look at our CI Dockerfile
where we build/install the dependencies needed for testing:

https://gitlab.com/gnuwget/build-images/blob/master/docker-debian-mingw/Dockerfile

Regards, Tim



signature.asc
Description: OpenPGP digital signature

Bug#924910: unblock: librostlab-blast/1.0.1-10

[Andreas Tille]

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

Please unblock package librostlab-blast


diff -Nru librostlab-blast-1.0.1/debian/changelog 
librostlab-blast-1.0.1/debian/changelog
--- librostlab-blast-1.0.1/debian/changelog 2018-09-20 11:22:42.0 
+0200
+++ librostlab-blast-1.0.1/debian/changelog 2019-03-18 10:48:04.0 
+0100
@@ -1,3 +1,12 @@
+librostlab-blast (1.0.1-10) unstable; urgency=medium
+
+  * Do not render PDF documentation any more since its not really important
+for users and doxygen 1.8.5 breaks the build of PDF documentation
+Closes: #924834
+  * Standards-Version: 4.3.0
+
+ -- Andreas Tille   Mon, 18 Mar 2019 10:48:04 +0100
+
 librostlab-blast (1.0.1-9) unstable; urgency=medium
 
   * Drop unneeded get-orig-source target
diff -Nru librostlab-blast-1.0.1/debian/control 
librostlab-blast-1.0.1/debian/control
--- librostlab-blast-1.0.1/debian/control   2018-09-20 11:22:42.0 
+0200
+++ librostlab-blast-1.0.1/debian/control   2019-03-18 10:48:04.0 
+0100
@@ -14,7 +14,7 @@
librostlab-dev,
texlive-fonts-recommended,
texlive-latex-extra
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/librostlab-blast
 Vcs-Git: https://salsa.debian.org/med-team/librostlab-blast.git
 Homepage: http://rostlab.org/
diff -Nru librostlab-blast-1.0.1/debian/librostlab-blast-doc.doc-base 
librostlab-blast-1.0.1/debian/librostlab-blast-doc.doc-base
--- librostlab-blast-1.0.1/debian/librostlab-blast-doc.doc-base 2018-09-20 
11:22:42.0 +0200
+++ librostlab-blast-1.0.1/debian/librostlab-blast-doc.doc-base 2019-03-18 
10:48:04.0 +0100
@@ -9,6 +9,3 @@
 Format: html
 Files: /usr/share/doc/librostlab-blast-doc/html/*.html
 Index: /usr/share/doc/librostlab-blast-doc/html/index.html
-
-Format: PDF
-Files: /usr/share/doc/librostlab-blast-doc/librostlab-blast.pdf.gz
diff -Nru librostlab-blast-1.0.1/debian/librostlab-blast-doc.docs 
librostlab-blast-1.0.1/debian/librostlab-blast-doc.docs
--- librostlab-blast-1.0.1/debian/librostlab-blast-doc.docs 2018-09-20 
11:22:42.0 +0200
+++ librostlab-blast-1.0.1/debian/librostlab-blast-doc.docs 2019-03-18 
10:48:04.0 +0100
@@ -1,3 +1,3 @@
 doxygen-doc/html/
-doxygen-doc/librostlab-blast.pdf
+# doxygen-doc/librostlab-blast.pdf
 lib/librostlab-blast.tag
diff -Nru librostlab-blast-1.0.1/debian/rules 
librostlab-blast-1.0.1/debian/rules
--- librostlab-blast-1.0.1/debian/rules 2018-09-20 11:22:42.0 +0200
+++ librostlab-blast-1.0.1/debian/rules 2019-03-18 10:48:04.0 +0100
@@ -19,7 +19,7 @@
debian/tmp/usr/lib/*/*.so
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-doxygen-dot --enable-doxygen-pdf
+   dh_auto_configure -- --enable-doxygen-dot --enable-doxygen-pdf=No
 
 override_dh_auto_build:
dh_auto_build




unblock librostlab-blast/1.0.1-10

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core)
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)

Bug#924814: grub-efi-amd64-signed: FTBFS: build-dependency not installable: grub-efi-amd64-bin (= 2.02+dfsg1-11)

[Colin Watson]

Control: tag -1 - sid

On Sun, Mar 17, 2019 at 07:03:42PM +0100, Lucas Nussbaum wrote:
> Source: grub-efi-amd64-signed
> Version: 1+2.02+dfsg1+11
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20190315 qa-ftbfs
> Justification: FTBFS in buster on amd64
> 
> Hi,
> 
> During a rebuild of all packages in buster (in a buster chroot, not a
> sid chroot), your package failed to build on amd64.
[...]
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-grub-efi-amd64-signed-dummy : Depends: 
> > grub-efi-amd64-bin (= 2.02+dfsg1-11) but it is not going to be installed

This is because grub2 2.02+dfsg1-12 migrated to testing without the
corresponding grub-efi-{amd64,arm64,ia32}-signed packages, thus
rendering the latter unbuildable and violating their Built-Using fields.
The version in unstable is fine when built against unstable;
grub-efi-amd64-signed 1+2.02+dfsg1+12 would have been fine if it had
migrated to testing before being superseded by 1+2.02+dfsg1+13; and once
the next grub2 + grub-efi-*-signed set migrates to testing then it will
be fine again there.

Release team: is there some way to make sure that this mismatched
migration doesn't happen in future?  It seems that the promotion
machinery ought to have prevented this, particularly due to the way it
caused Built-Using to be violated.

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

Bug#922042: Acknowledgement (x2gobroker: traceback when run as WSGI process from apache)

[Mike Gabriel]

Control: tags -1 patch

Hi Linnea,

On Fri, 15 Feb 2019 16:15:05 +0100 Linnea Skogtvedt 
 wrote:

> This issue appears to have been caused by this commit:
>
> 
https://code.x2go.org/gitweb?p=x2gobroker.git;a=commit;h=f9dd59dd656019f593d37d234a2859cc17696061

>
> This is supported by the fact that I could work around the bug by adding
> in the deleted code in a wsgi wrapper script as follows:
>
> # cat /etc/x2go/wsgi/x2gobroker.wsgi
>
> #!/usr/bin/python3
> from x2gobroker.loggers import logger_broker, logger_access,
> logger_error, tornado_log_request, PROG_NAME
> exec(open("/usr/bin/x2gobroker").read())
>
>
>

can you verify that the attached patch makes your workaround unnecessary?

Thanks+Greets,
Mike
diff --git a/bin/x2gobroker b/bin/x2gobroker
index d5e8bdb..84adae7 100755
--- a/bin/x2gobroker
+++ b/bin/x2gobroker
@@ -112,7 +112,6 @@ if __name__ == "__main__":
 setproctitle.setproctitle(os.path.basename(sys.argv[0]))
 
 index = 0
-argv = []
 argv.append(sys.argv[0])
 double_dash_pos = 0
 double_dash_argv = []
@@ -299,16 +298,18 @@ if __name__ == "__main__":
 urls = ()
 settings = {}
 
-# raise log level to DEBUG if requested...
-if x2gobroker.defaults.X2GOBROKER_DEBUG and not x2gobroker.defaults.X2GOBROKER_TESTSUITE:
-logger_broker.setLevel(logging.DEBUG)
-logger_access.setLevel(logging.DEBUG)
-logger_error.setLevel(logging.DEBUG)
+
 
 
 # run the Python Tornado standalone daemon or handle interactive command line execution (via SSH)
 if __name__ == "__main__":
 
+# raise log level to DEBUG if requested...
+if x2gobroker.defaults.X2GOBROKER_DEBUG and not x2gobroker.defaults.X2GOBROKER_TESTSUITE:
+logger_broker.setLevel(logging.DEBUG)
+logger_access.setLevel(logging.DEBUG)
+logger_error.setLevel(logging.DEBUG)
+
 logfile_prelude(mode=cmdline_args.mode.upper())
 
 if cmdline_args.mode.upper() == 'HTTP' or PROG_NAME == 'x2gobroker-daemon':
@@ -371,6 +372,16 @@ else:
 
 ### launch as WSGI application ###
 
+logger_broker = x2gobroker.loggers.logger_broker
+logger_access = x2gobroker.loggers.logger_broker
+logger_error = x2gobroker.loggers.logger_error
+
+# raise log level to DEBUG if requested...
+if x2gobroker.defaults.X2GOBROKER_DEBUG and not x2gobroker.defaults.X2GOBROKER_TESTSUITE:
+logger_broker.setLevel(logging.DEBUG)
+logger_access.setLevel(logging.DEBUG)
+logger_error.setLevel(logging.DEBUG)
+
 prep_http_mode()
 
 import tornado.wsgi

Bug#924911: gcc-8-base: please add Breaks: gnat-6 (<< 6.4)

[Andreas Beckmann]

Package: gcc-8-base
Version: 8.3.0-3
Severity: important

Hi,

this should fix some upgrade paths from stretch to buster as encountered
by piuparts. In some cases apt tries to keep gnat-6 installed instead of
installing gnat-8. The existing Breaks: gnat (<< 7) is not sufficient to
"solve" this properly. While I haven't tried to rebuild gcc-8 with this
change and rerun the test with that version available, I'm pretty sure
from my experience in the last years that this will work as intended.
The version (<< 6.4) is chosen to cover upgrades from stretch (which
currently has 6.3.0-18+deb9u1), but not touch setups where people still
have the newer 6.4 or 6.5 (that was previously in sid/testing) installed
(in case such setups are actually possible).

Andreas

PS: I have a machine that still has every g++-x(.y) installed that was
in sid since g++-4.3 (and the corresponding for clang) :-)


libaws3.3.2-dev_None.log.gz
Description: application/gzip

Bug#922042: Acknowledgement (x2gobroker: traceback when run as WSGI process from apache)

[Mike Gabriel]

Hi again,

please find a corrected patch attached.

On Fri, 15 Feb 2019 16:15:05 +0100 Linnea Skogtvedt 
 wrote:

> This issue appears to have been caused by this commit:
>
> 
https://code.x2go.org/gitweb?p=x2gobroker.git;a=commit;h=f9dd59dd656019f593d37d234a2859cc17696061

>
> This is supported by the fact that I could work around the bug by adding
> in the deleted code in a wsgi wrapper script as follows:
>
> # cat /etc/x2go/wsgi/x2gobroker.wsgi
>
> #!/usr/bin/python3
> from x2gobroker.loggers import logger_broker, logger_access,
> logger_error, tornado_log_request, PROG_NAME
> exec(open("/usr/bin/x2gobroker").read())

The patch I sent a little bit earlier contained a flawed line. Please 
test with this patch.


Thanks,
Mike
commit 8bc58d7ed8201b2fad5cfc0da83b2dd052cf1ed3
Author: Mike Gabriel 
Date:   Mon Mar 18 11:01:37 2019 +0100

Correctly initialize the loggers when using x2gobroker via WSGI in Apache2.

diff --git a/bin/x2gobroker b/bin/x2gobroker
index d5e8bdb..092f937 100755
--- a/bin/x2gobroker
+++ b/bin/x2gobroker
@@ -299,16 +299,18 @@ if __name__ == "__main__":
 urls = ()
 settings = {}
 
-# raise log level to DEBUG if requested...
-if x2gobroker.defaults.X2GOBROKER_DEBUG and not x2gobroker.defaults.X2GOBROKER_TESTSUITE:
-logger_broker.setLevel(logging.DEBUG)
-logger_access.setLevel(logging.DEBUG)
-logger_error.setLevel(logging.DEBUG)
+
 
 
 # run the Python Tornado standalone daemon or handle interactive command line execution (via SSH)
 if __name__ == "__main__":
 
+# raise log level to DEBUG if requested...
+if x2gobroker.defaults.X2GOBROKER_DEBUG and not x2gobroker.defaults.X2GOBROKER_TESTSUITE:
+logger_broker.setLevel(logging.DEBUG)
+logger_access.setLevel(logging.DEBUG)
+logger_error.setLevel(logging.DEBUG)
+
 logfile_prelude(mode=cmdline_args.mode.upper())
 
 if cmdline_args.mode.upper() == 'HTTP' or PROG_NAME == 'x2gobroker-daemon':
@@ -371,6 +373,16 @@ else:
 
 ### launch as WSGI application ###
 
+logger_broker = x2gobroker.loggers.logger_broker
+logger_access = x2gobroker.loggers.logger_broker
+logger_error = x2gobroker.loggers.logger_error
+
+# raise log level to DEBUG if requested...
+if x2gobroker.defaults.X2GOBROKER_DEBUG and not x2gobroker.defaults.X2GOBROKER_TESTSUITE:
+logger_broker.setLevel(logging.DEBUG)
+logger_access.setLevel(logging.DEBUG)
+logger_error.setLevel(logging.DEBUG)
+
 prep_http_mode()
 
 import tornado.wsgi

Bug#920177: linux-image-amd64-rt: BUG while removing the sunrpc module

[Laurent Bonnaud]

Hi,

the bug is still there in this package version:

Source: linux-signed-amd64 (4.19.28+2)
Version: 4.19.28-2

[  311.093489] RPC: Unregistered named UNIX socket transport module.
[  311.093493] RPC: Unregistered udp transport module.
[  311.093494] RPC: Unregistered tcp transport module.
[  311.093494] RPC: Unregistered tcp NFSv4.1 backchannel transport module.
[  311.093546] 
=
[  311.093548] BUG rpc_inode_cache (Not tainted): Objects remaining in 
rpc_inode_cache on __kmem_cache_shutdown()
[  311.093548] 
-

[  311.093549] Disabling lock debugging due to kernel taint
[  311.093551] INFO: Slab 0xf538f3cb objects=18 used=13 
fp=0x36f8e292 flags=0x17fffc08100
[  311.093554] CPU: 0 PID: 2939 Comm: rmmod Tainted: GB 
4.19.0-4-rt-amd64 #1 Debian 4.19.28-2
[  311.093555] Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 
06/28/2018
[  311.093555] Call Trace:
[  311.093564]  dump_stack+0x5c/0x80
[  311.093568]  slab_err+0xb0/0xd4
[  311.093572]  ? cpumask_next+0x16/0x20
[  311.093574]  ? flush_all+0x66/0x100
[  311.093576]  __kmem_cache_shutdown.cold.103+0x1c/0x26
[  311.093581]  shutdown_cache+0x15/0x1c0
[  311.093583]  kmem_cache_destroy+0x216/0x240
[  311.093603]  unregister_rpc_pipefs+0x16/0x30 [sunrpc]
[  311.093617]  cleanup_sunrpc+0x1e/0x39 [sunrpc]
[  311.093620]  __x64_sys_delete_module+0x190/0x2c0
[  311.093623]  do_syscall_64+0x53/0x100
[  311.093626]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  311.093628] RIP: 0033:0x7f4dd72d8137
[  311.093630] Code: 73 01 c3 48 8b 0d 59 0d 0c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 29 0d 0c 00 f7 d8 64 89 01 48
[  311.093631] RSP: 002b:7ffce99a5c78 EFLAGS: 0206 ORIG_RAX: 
00b0
[  311.093633] RAX: ffda RBX: 557deefcf220 RCX: 7f4dd72d8137
[  311.093634] RDX: 000a RSI: 0800 RDI: 557deefcf288
[  311.093634] RBP:  R08: 7ffce99a4bf1 R09: 
[  311.093635] R10: 7f4dd7349ae0 R11: 0206 R12: 7ffce99a5ea0
[  311.093636] R13: 7ffce99a6c31 R14: 557deefce010 R15: 557deefcf220
[  311.093638] kmem_cache_destroy rpc_inode_cache: Slab cache still has objects
[  311.099909] CPU: 0 PID: 2939 Comm: rmmod Tainted: GB 
4.19.0-4-rt-amd64 #1 Debian 4.19.28-2
[  311.099910] Hardware name: Dell Inc. OptiPlex 7010/0KRC95, BIOS A29 
06/28/2018
[  311.099910] Call Trace:
[  311.099915]  dump_stack+0x5c/0x80
[  311.099919]  kmem_cache_destroy+0x233/0x240
[  311.099937]  unregister_rpc_pipefs+0x16/0x30 [sunrpc]
[  311.099950]  cleanup_sunrpc+0x1e/0x39 [sunrpc]
[  311.099952]  __x64_sys_delete_module+0x190/0x2c0
[  311.099957]  do_syscall_64+0x53/0x100
[  311.099959]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  311.099961] RIP: 0033:0x7f4dd72d8137
[  311.099963] Code: 73 01 c3 48 8b 0d 59 0d 0c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 29 0d 0c 00 f7 d8 64 89 01 48
[  311.099964] RSP: 002b:7ffce99a5c78 EFLAGS: 0206 ORIG_RAX: 
00b0
[  311.099965] RAX: ffda RBX: 557deefcf220 RCX: 7f4dd72d8137
[  311.099966] RDX: 000a RSI: 0800 RDI: 557deefcf288
[  311.099967] RBP:  R08: 7ffce99a4bf1 R09: 
[  311.099967] R10: 7f4dd7349ae0 R11: 0206 R12: 7ffce99a5ea0
[  311.099968] R13: 7ffce99a6c31 R14: 557deefce010 R15: 557deefcf220

-- 
Laurent.

Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz

[Andreas Beckmann]

Package: pristine-tar
Version: 1.46
Severity: important

In this repository:

https://salsa.debian.org/python-team/modules/python-django.git

$ pristine-tar checkout python-django_1.11.20.orig.tar.gz
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrect
xdelta3: please verify the source file with sha1sum or equivalent
pristine-tar: Failed to reproduce original tarball. Please file a bug
report.
pristine-tar: failed to generate tarball


Andreas

Bug#924909: texlive-fonts-extra: dpkg install texlive-fonts-extra_2018.20190227-1_all.deb hangs

[Norbert Preining]

Hi

Can you please the full log of the installation?

And maybe remove the deb and re-download it, please.

Disk space is fine, do you have enough space left?

> D10: path_remove_tree 
> '/usr/share/texlive/texmf-dist/tex/plain/ly1.dpkg-tmp'
> D10: path_remove_tree 
> '/usr/share/texlive/texmf-dist/tex/plain/ly1/texnansi.tex.dpkg-tmp'
> D10: path_remove_tree 
> '/usr/share/texlive/texmf-dist/tex/plain/semaphor.dpkg-tmp'
> D10: path_remove_tree 
> '/usr/share/texlive/texmf-dist/tex/plain/semaphor/semaf.tex.dpkg-tmp'
> D10: path_remove_tree '/var.dpkg-tmp'
> D10: path_remove_tree '/var/lib.dpkg-tmp'
> D10: path_remove_tree '/var/lib/tex-common.dpkg-tmp'
> D10: path_remove_tree '/var/lib/tex-common/fontmap-cfg.dpkg-tmp'
> D10: path_remove_tree '/var/lib/tex-common/fontmap-cfg/texlive.dpkg-tmp'
> D10: path_remove_tree 
> '/var/lib/tex-common/fontmap-cfg/texlive/texlive-fonts-extra.cfg.dpkg-tmp'
> D10: path_remove_tree '/var/lib/dpkg/tmp.ci'
> D10: path_remove_tree running rm -rf '/var/lib/dpkg/tmp.ci'
> D10: path_remove_tree '/var/lib/dpkg/reassemble.deb'
> dpkg: dependency problems prevent configuration of texlive-fonts-extra:
>  texlive-fonts-extra depends on texlive-base (>= 2018.20190227); however:
>   Package texlive-base is not configured yet.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#924032: mpqc3: FTBFS: Could NOT find MPI

[Andreas Tille]

Control: tags -1 help

Hi,

I stumbled upon bug #924032 which has no response so far.  I tagged
it help and repost here on Debian Science list since there is usually
some competence to solve issues like

-- Detecting Fortran/C Interface
-- Detecting Fortran/C Interface - Found GLOBAL and MODULE mangling
-- Verifying Fortran/CXX Compiler Compatibility
-- Verifying Fortran/CXX Compiler Compatibility - Success
-- Found PAPI: /usr/lib/x86_64-linux-gnu/libpapi.a  
-- Found MPI_C: /usr/lib/x86_64-linux-gnu/libmpich.so (found version "3.1") 
-- Could NOT find MPI_CXX (missing: MPI_CXX_WORKS) 
-- Found MPI_Fortran: /usr/lib/x86_64-linux-gnu/libmpichfort.so (found version 
"3.1") 
-- Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1")
CMake Error at external/MPI:36 (message):
  MPI not found


Any idea?

Kind regards

  Andreas.


-- 
http://fam-tille.de

Bug#924799: qtspeech-opensource-src: FTBFS: dh_auto_test: make -j4 check -Ctests/auto QT_HASH_SEED=0 QT_QPA_PLATFORM=minimal returned exit code 2

[Lucas Nussbaum]

Hi,

On 17/03/19 at 18:06 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El domingo, 17 de marzo de 2019 17:54:39 -03 Lisandro Damián Nicanor Pérez 
> Meyer escribió:
> > Hi Lucas!
> > 
> > El domingo, 17 de marzo de 2019 15:20:23 -03 Lucas Nussbaum escribió:
> > > Source: qtspeech-opensource-src
> > > Version: 5.11.3-2
> > > Severity: serious
> > > Tags: buster sid
> > > User: debian...@lists.debian.org
> > > Usertags: qa-ftbfs-20190315 qa-ftbfs
> > > Justification: FTBFS in buster on amd64
> > > 
> > > Hi,
> > > 
> > > During a rebuild of all packages in buster (in a buster chroot, not a
> > > sid chroot), your package failed to build on amd64.
> > 
> > [snip]
> > 
> > This:
> > > > "Failed to start audio output (error 1)" BFAIL  :
> > And then:
> > > > FAIL!  : tst_QTextToSpeech::volume() 'tts.volume() > 0.65' returned
> > > > FALSE.
> > 
> > Makes me think if the test is failing due to no audio setup in your VMs.
> > Maybe we have hit an interesting bug which was never caught on the buildds?
> > Should a buildd have audio setup?
> 
> The problem seems to be different, as I can reproduce it on a porterbox 
> (except barriere also has no audio).
> 
> Non the less I'm still interested in knowing if your VMs provide an audio 
> setup.

AFAIK they don't, but that shouldn't be a requirement to build the
package?

Lucas


signature.asc
Description: PGP signature

Bug#924854: mmdebstrap: flaky autopkgtest

[Jonas Smedegaard]

Quoting Johannes Schauer (2019-03-18 07:53:34)
> Hi Paul,
> 
> Quoting Paul Gevers (2019-03-17 19:50:22)
> > Since the end of February the autopkgtest of mmdebstrap sometimes 
> > fails in unstable and testing, while a retry not much later 
> > succeeds. Because the unstable-to-testing migration software now 
> > blocks on regressions in testing, flaky tests, i.e. tests that flip 
> > between passing and failing without changes to the list of installed 
> > packages, are wasting peoples time. Please either fix the test to be 
> > more robust, or mark this particular test as "flaky".
> > 
> > I copied some of the output at the bottom of this report. 
> > Unfortunately, the failure doesn't always seem to be on the same 
> > place.
> 
> yes, this is because the source of the flakiness are from M-A:same 
> version skews in unstable. For example recently:
> 
> https://buildd.debian.org/status/package.php?p=gcc-8
> 
> As you can see the armhf version was built only 13 hours after the 
> amd64 version.
> 
> To correct, this mmdebstrap can be patched to use "testing" as the 
> target distribution where packages only migrate to after they have 
> been built on all architectures.
> 
> But due to the freeze I guess this is only realistic for buster+1? You 
> made this bug severity important so I guess you don't mean to say that 
> this issue has RC severity and thus warrents an exception from the 
> release team?

Please consider making the proposed minimal change of simply flagging 
that one test as flaky, and request exception by release managers for 
getting that change into Buster: Improves reliability of the tests!

Then going forward - i.e. targeted Bullseye, it makes sense to try 
redesign the tests to be less flaky.


 - Jonas

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

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


signature.asc
Description: signature

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Alois Schlögl]

Source: linux
Severity: normal

Dear Maintainer,

   On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
(testing).
   After the upgrade, the touchpad and the trackpoint was not usable
anymore.


   This already has some bug report here,
   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600

   As a workaround, one can run the command,
   sudo sh -c 'echo -n "elantech">
/sys/bus/serio/devices/serio1/protocol'
   in order to use the touchpad. However, on a GUI Interface and without
   an external mouse, it's impossible to apply this workaround
  (switching to the terminal -F1, login, and run the command
above might work)

   I expect to be able to use the touchpad just out of the box, not needing
   to run the above workaround


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

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

Bug#924914: pcscd: socket activation masks socket

[Mathias Behrle]

Package: pcscd
Version: 1.8.24-1
Severity: important
Tags: patch

Dear Maintainer,

pcscd.socket masks the socket of pcscd, which is then not available for
programs needing it (e.g. can easily reproduced by running pcsc_scan).

The additional line

SocketMode=0666

in pcscd.socket re-instates the usual socket as usually created by
pcscd.

Cheers
Mathias

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

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

Versions of packages pcscd depends on:
ii  libc6 2.28-8
ii  libccid [pcsc-ifd-handler]1.4.30-1
ii  libifd-cyberjack6 [pcsc-ifd-handler]  3.99.5final.sp09-1.1
ii  libpcsclite1  1.8.24-1
ii  libsystemd0   241-1
ii  libudev1  241-1
ii  lsb-base  10.2018112800

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  241-1

-- no debconf information

Bug#924591: should be there

[Hans-Christoph Steiner]

Tags: moreinfo

Thanks for the bug report!  I am guessing you installed fastboot using
`apt-get install fastboot` rather than `apt-get install android-sdk` or
`apt-get install android-sdk-platform-tools`.  Installing either
android-sdk or android-sdk-platform-tools should fix your problem.

The question that remains is: can we handle this better?  I don't think
fastboot should Depends: on android-sdk-platform-tools since the most
common use cases do not require android-sdk-platform-tools to work.  I
think adding Recommends: android-sdk-platform-tools could make sense.

Bug#924009: update

[di dit]

New update: I rebuilt freefem++ from source using the instructions from:
  https://wiki.debian.org/SimpleBackportCreation
The issue disappeared.
The PC used to rebuild the package is the one for which freefem++
crashed before (2 CPUs).

Bug#924807: [Pkg-javascript-devel] Bug#924807: Bug#924807: Bug#924807: Bug#924807: Bugs come from conflict between node-uglify and node-uglify-js

[Jonas Smedegaard]

Quoting Xavier (2019-03-18 06:56:42)
> Le 18/03/2019 à 06:19, Xavier a écrit :
> > Le 18/03/2019 à 00:02, Jonas Smedegaard a écrit :
> >> Quoting Jonas Smedegaard (2019-03-17 23:48:57)
> >>> Quoting Xavier (2019-03-17 23:12:51)
>  Control: reassign 924807 uglify-js
>  Control: reassign 924809 uglify-js
>  Control: merge 924807 924809
> 
>  Bug seems to come from conflict between
>  https://tracker.debian.org/pkg/uglify-js and
>  https://tracker.debian.org/pkg/uglifyjs: webpack can't now be installed
>  with uglifyjs
> >>>
> >>> Problem is packages depending on uglifyjs and webpack together: webpack 
> >>> depends indirectly on node-uglify 2.x, whereas uglifyjs is either a 
> >>> virtual package provided by node-uglify 2.x or (since recently) a real 
> >>> package depending on node-uglyfy-js 3.x.
> >>>
> >>> Yes, the problem emerged when node-uglify was introduced as a real 
> >>> package, but the fix is for those packages depending on uglifyjs and 
> >>> webpack together to depend on node-uglify 2.x instead of the virtual 
> >>> package.
> >>>
> >>> Please revert these reassignments: This cannot be fixed in uglifyjs 3.x.
> >>
> >> Put differently, the problem is packages depending both unversioned and 
> >> transitively versioned on uglifyjs - that works only as long as the 
> >> transitive dependency happens to be newest major release of uglifyjs.
> >>
> >>  - Jonas
> > 
> > List of packages that are affected by this change:

Please clarify how you produced a list of packages which depend *both* 
unversioned and *also* transitively versioned on uglifyjs.

...or clarify what other list you produced and why you find such other 
list relevant here.


> If I understand (but maybe I'm wrong), this means that in buster it is 
> not possible to have uglifyjs installed with one of these 14 packages 
> or their dependencies (`apt-cache rdepends --recurse node-uglify` 
> returns several thousands package names).

Please elaborate why - either based on my explanation of the problem 
quoted above, or elaborate on which _different_ theory you have of what 
is the underlying problem you try to solve.


 - Jonas

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

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


signature.asc
Description: signature

Bug#924915: unblock: gitsome/0.7.0+git20180130.5751a31+ds-2

[林上智]

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

Dear Release Team,

Please consider unblocking 0.7.0+git20180130.5751a31+ds-2, the only
change is to fix FTBFS issue by replacing python-tox with tox in
Build-Depends.

unblock gitsome/0.7.0+git20180130.5751a31+ds-2

Thanks,

SZ


0.7.0+git20180130.5751a31+ds-2.debdiff
Description: Binary data

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

[Dirk Eddelbuettel]

reassign 924514 r-cran-dosefinding
thanks


The relationship between 'multcomp' and 'DoseFinding' is, as seen on the
upstream package for 'DoseFinding' at

  http://cloud.r-project.org/package=DoseFinding

in its DESCRIPTION file:

  Suggests: numDeriv, Rsolnp, quadprog, parallel, multcomp

so 'multcomp' is only suggested. Further, as one can see browsing the code
(via the CRAN mirror at GitHub) at

  https://github.com/cran/DoseFinding

there is exactly one use here (per a search for multcompin these sources)

  https://github.com/cran/DoseFinding/search?q=multcomp&unscoped_q=multcomp

and that is generation of data in one testfile. As such I will not consider
myself with the bug in package 'multcomp'.  I suggest the DoseFinding
maintainer get in touch with its upstream.

Thanks,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#924807: Bugs come from conflict between node-uglify and node-uglify-js

[Xavier]

Le 18/03/2019 à 11:46, Jonas Smedegaard a écrit :
> Quoting Xavier (2019-03-18 06:56:42)
>> Le 18/03/2019 à 06:19, Xavier a écrit :
>>> Le 18/03/2019 à 00:02, Jonas Smedegaard a écrit :
 Quoting Jonas Smedegaard (2019-03-17 23:48:57)
> Quoting Xavier (2019-03-17 23:12:51)
>> Control: reassign 924807 uglify-js
>> Control: reassign 924809 uglify-js
>> Control: merge 924807 924809
>>
>> Bug seems to come from conflict between
>> https://tracker.debian.org/pkg/uglify-js and
>> https://tracker.debian.org/pkg/uglifyjs: webpack can't now be installed
>> with uglifyjs
>
> Problem is packages depending on uglifyjs and webpack together: webpack 
> depends indirectly on node-uglify 2.x, whereas uglifyjs is either a 
> virtual package provided by node-uglify 2.x or (since recently) a real 
> package depending on node-uglyfy-js 3.x.
>
> Yes, the problem emerged when node-uglify was introduced as a real 
> package, but the fix is for those packages depending on uglifyjs and 
> webpack together to depend on node-uglify 2.x instead of the virtual 
> package.
>
> Please revert these reassignments: This cannot be fixed in uglifyjs 3.x.

 Put differently, the problem is packages depending both unversioned and 
 transitively versioned on uglifyjs - that works only as long as the 
 transitive dependency happens to be newest major release of uglifyjs.

  - Jonas
>>>
>>> List of packages that are affected by this change:
> 
> Please clarify how you produced a list of packages which depend *both* 
> unversioned and *also* transitively versioned on uglifyjs.
> 
> ...or clarify what other list you produced and why you find such other 
> list relevant here.

I pushed this list taken from UDD database (reverse build depends) +
"apt-cache rdepends", just to help to understand the impact of this bug.
If it is not useful, please ignore my message

>> If I understand (but maybe I'm wrong), this means that in buster it is 
>> not possible to have uglifyjs installed with one of these 14 packages 
>> or their dependencies (`apt-cache rdepends --recurse node-uglify` 
>> returns several thousands package names).
> 
> Please elaborate why - either based on my explanation of the problem 
> quoted above, or elaborate on which _different_ theory you have of what 
> is the underlying problem you try to solve.

I do not have a theory, just want to help (I'm not uploader of any
package concerned). So ignore my mail if it is not clear/useful.

The fact is that today, it is not possible to have both webpack (or some
other packages) and uglifyjs on the same machine.

Bug#924621: [Pkg-openssl-devel] Bug#924621: Bug#924621: openssl 1.1.1b-1 make fetchmail unusable

[Kurt Roeckx]

On Mon, Mar 18, 2019 at 01:55:50PM +0900, Atsuhito Kohda wrote:
> Hi Kurt,
> 
> > So from what I understand, the problem is really on the dovecot
> > side. What does dovecot's log show?
> > 
> > Dovecot can configure DH, which seems to default to:
> > ssl_dh =  > 
> > That file should be fine, it's 4096 bit.
> 
> I generated 4096 bit dh_key:
> openssl dhparam -out /path/to/dh.pem 4096
> 
> then I modified a configuration file of dovecot as follows:
> ssl_dh= then I restarted dovecot. Now fetch mail works fine
> after I upgraded openssl 1.1.1b-1 .

I have no idea which part of dovecot failed, but I think there
might still be some other issue.

Do you have any idea which version of TLS is being negotiated?
Since both use the same version of openssl, it should be able to
do TLS 1.3 and have used X25519 instead of DHE. It could be that
some side of the connection for some reasons blocks TLS 1.3.

The other reason it can fail is that the change between 1.1.1a and
1.1.1b now just caused dovecot to not properly set up TLS. That
you are in fact not using DHE, but that setting up DHE now failed,
causing the connection issue.


Kurt

Bug#924032: mpqc3: FTBFS: Could NOT find MPI

[Drew Parsons]

On 2019-03-18 18:27, Andreas Tille wrote:

Control: tags -1 help

Hi,

I stumbled upon bug #924032 which has no response so far.  I tagged
it help and repost here on Debian Science list since there is usually
some competence to solve issues like

-- Detecting Fortran/C Interface
-- Detecting Fortran/C Interface - Found GLOBAL and MODULE mangling
-- Verifying Fortran/CXX Compiler Compatibility
-- Verifying Fortran/CXX Compiler Compatibility - Success
-- Found PAPI: /usr/lib/x86_64-linux-gnu/libpapi.a
-- Found MPI_C: /usr/lib/x86_64-linux-gnu/libmpich.so (found version 
"3.1")

-- Could NOT find MPI_CXX (missing: MPI_CXX_WORKS)
-- Found MPI_Fortran: /usr/lib/x86_64-linux-gnu/libmpichfort.so (found
version "3.1")
-- Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1")
CMake Error at external/MPI:36 (message):
  MPI not found




The bug report does not report the arch, which is important information 
here (please use reportbug!)


The log snippet refers to mpich, but most arches use openmpi by default. 
 So that's a clue.


The full attached log says it's a simple x86_64.  Why then is mpich 
installed?


All the same, it should be possible to use mpich on amd64.

I think the final clue is "Could NOT find MPI_CXX".  It suggests mpicc 
is not being used, which makes these MPI builds simpler.

But the log says mpicc is used, -DMPI_C_COMPILER=mpicc

My guess is the C++ compiler needs to be set: -DMPI_CXX_COMPILER=mpic++  
 (or mpicxx)


Drew

Bug#924874: [pre-upload approval] unblock: arctica-greeter/0.99.1.3-1

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 17/03/2019 21:44, Mike Gabriel wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please consider pre-upload approving an unblock of package arctica-greeter

LGTM. Please go ahead and ping us when it is accepted into sid.

Emilio

Bug#924909: texlive-fonts-extra: dpkg install texlive-fonts-extra_2018.20190227-1_all.deb hangs

[ael]

On Mon, Mar 18, 2019 at 07:24:05PM +0900, Norbert Preining wrote:
> Hi
> 
> Can you please the full log of the installation?

I will attach dpkg.log.gz unless you are asking for
/var/log/dpkg/history.log.

> And maybe remove the deb and re-download it, please.

I will try that later. Meanwhile:
# cksum ./cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb
3652611647 411876816 
./cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb

root@shelf:/var# sha1sum 
./cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb
249ea879c68110dafe596f42c80c00d8f3192d36  
./cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb

> Disk space is fine, do you have enough space left?

I did wonder about that, especially /tmp/. I did check dmesg after the
run/crash but there didn't seem to be anything relevant there.

Main space has 158GB free, but /tmp is on RAM:

# findmnt /tmp
TARGET SOURCE FSTYPE OPTIONS
/tmp   tmpfs  tmpfs  rw,nosuid,nodev
with (by default) 7.8GB free.

This machine has 16GB of RAM, and I think the tmpfs can use up to 50%,
but I might be wrong about that.

>From the debug messages with -D10 on dpkg, there were a vast number of
files being, was it "deferred", and I did wonder whether those entries
were going on a stack somewhere which might have overflowed?

As a temporary fix, I tried "holding" texlive-fonts-extra, but that
didn't work out, so I removed it, and then completed the apt-get
upgrade. I marked some of the dependent packages manually for install
which all wnet through smoothly. But obviously I would like the package
back.

Just a quick reply: out of time this morning, but hope to reload etc
later today.

Thanks for prompt reply,

ael



dpkg.log.gz
Description: application/gzip

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Romain Perier]

Hello,

On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
> 
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
> (testing).
>    After the upgrade, the touchpad and the trackpoint was not usable
> anymore.
> 
> 
>    This already has some bug report here,
>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
> 
>    As a workaround, one can run the command,
>    sudo sh -c 'echo -n "elantech">
> /sys/bus/serio/devices/serio1/protocol'
>    in order to use the touchpad. However, on a GUI Interface and without
>    an external mouse, it's impossible to apply this workaround
>   (switching to the terminal -F1, login, and run the command
> above might work)
> 
>    I expect to be able to use the touchpad just out of the box, not needing
>    to run the above workaround
> 

Could you :

- Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and confirm 
or
  not is the problem still exists ?

- According to the bug on launchpad and to the fix pushed upstream, the
  fix seems to be an hardware quirks, could you give me the output of the
  following command :
  $ /sys/bus/serio/devices/serio1/firmware_id


Thanks,
Regards,
Romain

> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled


signature.asc
Description: PGP signature

Bug#924807: Bugs come from conflict between node-uglify and node-uglify-js

[Jonas Smedegaard]

Quoting Xavier (2019-03-18 12:01:52)
> Le 18/03/2019 à 11:46, Jonas Smedegaard a écrit :
> > Quoting Xavier (2019-03-18 06:56:42)
> >> Le 18/03/2019 à 06:19, Xavier a écrit :
> >>> Le 18/03/2019 à 00:02, Jonas Smedegaard a écrit :
>  Quoting Jonas Smedegaard (2019-03-17 23:48:57)
> > Quoting Xavier (2019-03-17 23:12:51)
> >> Control: reassign 924807 uglify-js
> >> Control: reassign 924809 uglify-js
> >> Control: merge 924807 924809
> >>
> >> Bug seems to come from conflict between
> >> https://tracker.debian.org/pkg/uglify-js and
> >> https://tracker.debian.org/pkg/uglifyjs: webpack can't now be installed
> >> with uglifyjs
> >
> > Problem is packages depending on uglifyjs and webpack together: webpack 
> > depends indirectly on node-uglify 2.x, whereas uglifyjs is either a 
> > virtual package provided by node-uglify 2.x or (since recently) a real 
> > package depending on node-uglyfy-js 3.x.
> >
> > Yes, the problem emerged when node-uglify was introduced as a real 
> > package, but the fix is for those packages depending on uglifyjs and 
> > webpack together to depend on node-uglify 2.x instead of the virtual 
> > package.
> >
> > Please revert these reassignments: This cannot be fixed in uglifyjs 3.x.
> 
>  Put differently, the problem is packages depending both unversioned and 
>  transitively versioned on uglifyjs - that works only as long as the 
>  transitive dependency happens to be newest major release of uglifyjs.
> 
>   - Jonas
> >>>
> >>> List of packages that are affected by this change:
> > 
> > Please clarify how you produced a list of packages which depend *both* 
> > unversioned and *also* transitively versioned on uglifyjs.
> > 
> > ...or clarify what other list you produced and why you find such other 
> > list relevant here.
> 
> I pushed this list taken from UDD database (reverse build depends) +
> "apt-cache rdepends", just to help to understand the impact of this bug.
> If it is not useful, please ignore my message
> 
> >> If I understand (but maybe I'm wrong), this means that in buster it is 
> >> not possible to have uglifyjs installed with one of these 14 packages 
> >> or their dependencies (`apt-cache rdepends --recurse node-uglify` 
> >> returns several thousands package names).
> > 
> > Please elaborate why - either based on my explanation of the problem 
> > quoted above, or elaborate on which _different_ theory you have of what 
> > is the underlying problem you try to solve.
> 
> I do not have a theory, just want to help (I'm not uploader of any
> package concerned). So ignore my mail if it is not clear/useful.

Ok: Since I don't recognize your list as matching the problem as I see 
it, I will ignore your provided list.

Please note that I am _not_ saying that your list is wrong, nor that my 
view of the problem is correct.  Only that I don't understand your info.


> The fact is that today, it is not possible to have both webpack (or 
> some other packages) and uglifyjs on the same machine.

Since you merged and reassigned bugs, packages will get kicked out of 
Buster because they cannot be fixed.

I urge you to either stand by your change by engaging in discussions on 
theories as to what is the real problem here, or if you don't want to do 
that (or don't have the time, or don't understand the problem well 
enough) then I recommend that you consider reverting those changes done 
by you.


 - Jonas

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

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


signature.asc
Description: signature

Bug#922040: x2gobroker-wsgi: default apache configuration gives 403 error

[Mike Gabriel]

Control: tags -1 patch

Hi Linnea,

On Mon, 11 Feb 2019 15:11:01 +0100 Linnea Skogtvedt 
 wrote:

> Package: x2gobroker-wsgi
> Version: 0.0.4.0-3
>
> wget -O - http://127.0.0.1/x2gobroker/ yields a 403 Forbidden error
> message. /var/log/apache2/error.log shows the following message:
> [authz_core:error] ... [client 127.0.0.1:49216] AH01630: client denied
> by server configuration: /usr/bin/x2gobroker
>
> Editing /etc/apache2/conf-available/x2gobroker-wsgi.conf to change
>  to  and restarting
> apache2 removes the 403 Forbidden error, but it's not a good
> configuration. I suggest creating a WSGI wrapper script in its own
> subdirectory.
>
>
> I am using a freshly installed Debian testing VM, with unstable added in
> sources.list to be able to install x2gobroker. I used the following
> command to install the packages: apt install apache2 x2gobroker
> x2gobroker-wsgi

can you rebuild your x2gobroker instance from source with attached patch 
applied (or alternatively, reconfigure your runtime instance as 
demonstrated by the patch's content) and check whether the above issue 
is solved then?


Thanks,
Mike
>From 5bb47a9cb08804af8cd22085da9de3ca08fa7c97 Mon Sep 17 00:00:00 2001
From: Mike Gabriel 
Date: Mon, 18 Mar 2019 12:22:46 +0100
Subject: [PATCH] x2gobroker-wsgi: Placa WSGI script symlink (pointing to
 /x2gobroker) into a dedicated folder and configure Apache2 to use
 WSGIScriptAlias from that folder. (See Debian bug #922040).

---
 Makefile | 3 +++
 debian/x2gobroker-wsgi.install   | 1 +
 etc/x2gobroker-wsgi.apache.conf  | 4 ++--
 etc/x2gobroker-wsgi.apache.vhost | 4 ++--
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index ca1c85f..ad2bec9 100755
--- a/Makefile
+++ b/Makefile
@@ -182,6 +182,9 @@ install:
 	${INSTALL_FILE} etc/x2gobroker-wsgi.apache.{conf,vhost} \
 	"${DESTDIR}${ETCDIR}/"
 	${INSTALL_FILE} logrotate/x2gobroker-wsgi "${DESTDIR}/etc/logrotate.d/"
+	mkdir -p "${DESTDIR}${LIBDIR}/x2gobroker/wsgi"
+	${INSTALL_SYMLINK} "${BINDIR}/x2gobroker" \
+	"${DESTDIR}${LIBDIR}/x2gobroker/wsgi/x2gobroker-wsgi"
 
 	# x2gobroker
 	mkdir -p "${DESTDIR}${BINDIR}" "${DESTDIR}${SBINDIR}" \
diff --git a/debian/x2gobroker-wsgi.install b/debian/x2gobroker-wsgi.install
index 743a1cc..42b6b92 100644
--- a/debian/x2gobroker-wsgi.install
+++ b/debian/x2gobroker-wsgi.install
@@ -1,3 +1,4 @@
 etc/x2go/x2gobroker-wsgi.apache.conf
 etc/x2go/x2gobroker-wsgi.apache.vhost
 etc/logrotate.d/x2gobroker-wsgi
+usr/lib/x2gobroker/wsgi/
diff --git a/etc/x2gobroker-wsgi.apache.conf b/etc/x2gobroker-wsgi.apache.conf
index 3ee97ee..42da235 100644
--- a/etc/x2gobroker-wsgi.apache.conf
+++ b/etc/x2gobroker-wsgi.apache.conf
@@ -28,10 +28,10 @@ SetEnv X2GOBROKER_DEFAULT_BACKEND inifile
 # if you have to-be-statically-served files somewhere below the broker URL
 #Alias /x2gobroker/static /some/static/path/
 
-WSGIScriptAlias /x2gobroker /usr/bin/x2gobroker
+WSGIScriptAlias /x2gobroker /usr/lib/x2gobroker/wsgi/x2gobroker-wsgi
 WSGIProcessGroup x2gobroker
 
-
+
 
 Require local
 
diff --git a/etc/x2gobroker-wsgi.apache.vhost b/etc/x2gobroker-wsgi.apache.vhost
index 9b9e1cd..44df536 100644
--- a/etc/x2gobroker-wsgi.apache.vhost
+++ b/etc/x2gobroker-wsgi.apache.vhost
@@ -42,10 +42,10 @@
 # if you have to-be-statically-served files somewhere below the broker URL
 #Alias /x2gobroker/static /some/static/path/
 
-WSGIScriptAlias / /usr/bin/x2gobroker
+WSGIScriptAlias / /usr/lib/x2gobroker/wsgi/x2goroker-wsgi
 WSGIProcessGroup x2gobroker
 
-
+
 
 Require local
 
-- 
2.11.0

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[seamlik]

I believe we should just patch the code and make it use programs in
`/usr/bin`. And we should do this for all other programs in AOSP. The
symlinks installed in the SDK directory are only intended to make IDEs
or Gradle.

Bug#924913: trackpad on L480 unusable after upgrade to testing

[Alois Schlögl]

On 3/18/19 12:20 PM, Romain Perier wrote:
> Hello,
>
> On Mon, Mar 18, 2019 at 11:27:41AM +0100, Alois Schlögl wrote:
>> Source: linux
>> Severity: normal
>>
>> Dear Maintainer,
>>
>>    On a Lenovo L480 laptop, I've upgraded Debian from 9 (stretch) to 10
>> (testing).
>>    After the upgrade, the touchpad and the trackpoint was not usable
>> anymore.
>>
>>
>>    This already has some bug report here,
>>    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803600
>>
>>    As a workaround, one can run the command,
>>    sudo sh -c 'echo -n "elantech">
>> /sys/bus/serio/devices/serio1/protocol'
>>    in order to use the touchpad. However, on a GUI Interface and without
>>    an external mouse, it's impossible to apply this workaround
>>   (switching to the terminal -F1, login, and run the command
>> above might work)
>>
>>    I expect to be able to use the touchpad just out of the box, not needing
>>    to run the above workaround
>>
> Could you :
>
> - Test with the last kernel uploaded to unstable (4.19.0-4:4.19.28) and 
> confirm or
>   not is the problem still exists ?


Dear Romainm


I upgraded the kernel and rebooted:

schloegl@debian10:~$ uname -a
Linux debian10 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
x86_64 GNU/Linux


With this kernel the trackpoint is working, the trackpad is still not
usable.

(This improves the situation because now at least one pointer device is
available).


> - According to the bug on launchpad and to the fix pushed upstream, the
>   fix seems to be an hardware quirks, could you give me the output of the
>   following command :
>   $ /sys/bus/serio/devices/serio1/firmware_id


root@debian10:~# cat /sys/bus/serio/devices/serio1/firmware_id
PNP: LEN2036 PNP0f13


>
> Thanks,
> Regards,
> Romain


Thank You, 

   Alois



>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers testing
>>   APT policy: (990, 'testing'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
>> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled

Bug#924799: qtspeech-opensource-src: FTBFS: dh_auto_test: make -j4 check -Ctests/auto QT_HASH_SEED=0 QT_QPA_PLATFORM=minimal returned exit code 2

[Lisandro Damián Nicanor Pérez Meyer]

El lun., 18 mar. 2019 07:33, Lucas Nussbaum  escribió:

>
> AFAIK they don't, but that shouldn't be a requirement to build the
> package?


Not building, but tests might require them and we might haven't noticed it.

Anyways that turned out not to be the issue. Something changed in between
but I still can't find the reason.

Thanks for the follow up!

Bug#924368: I'll take it

[Gianfranco Costamagna]

On Tue, 12 Mar 2019 16:09:35 +0100 Adam Borowski  wrote:
> Control: retitle -1 ITA: btrfs-progs -- Checksumming Copy on Write Filesystem 
> utilities
> Control: owner -1 !
> 
> As a long-time user ("thou shalt have no other filesystems before btrfs")
> and an occassional contributor, I can take it.
> 

Thanks Adam for taking care of it!
Just a side note: I think I sponsored a lot of backports for Nicholas in the 
past,
he is a good contributor, and he sends patches upstream and to Debian packaging 
(dated 2017).

Maybe you can both work on the package, he is a DM so he might even upload by 
himself if you
feel comfortable with his work (Nicholas please tell us if you are still 
interested in btrfs!)

In any case, two is better than one, specially when one is an upstream 
contributor and Debian maintainer :)

I hope to see Nicholas back in the team :)

G.

Bug#924916: RM: python-django-openstack-auth -- RoM; provided by python3-django-horizon

[Andreas Beckmann]

Source: python-django-openstack-auth
Version: 3.5.0-2
Severity: serious

Hi Thomas,

can this package be removed? If so, please reassign to ftp.debian.org
(and lover the severity to normal).

I'm again investigating openstack-dashboard related upgrade failures.
This may be #905183 returning, never being fixed, or a different
problem.

Having python-django-openstack-auth and python3-django-openstack-auth
available as both real packages (from src:python-django-openstack-auth)
and virtual packages (Provides/Conflicts/Replaces by
python3-django-horizon) does not make things easier for apt in this
case.
And I doubt that providing a python2 module from a python3 package is a
good idea ...

There are no rdepends left that depend on these packages.
So maybe consider dropping the Provides and Replaces (but keep the
Conflicts) in python3-django-horizon as well.


Thanks

Andreas

Bug#920339: matrix-synapse: installation process hangs with unknown reason

[Peter Gervai]

Package: matrix-synapse
Version: 0.99.2-2
Followup-For: Bug #920339

Still exists in the recent version. It seems that the server is spawned and
disowned, and the configure script waits forever for some return value which 
never 
comes.



Also this output is not really happy:

Setting up matrix-synapse (0.99.2-2) ...
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/synapse/config/__main__.py", line 31, in 

print(getattr(config, key))
AttributeError: 'HomeServerConfig' object has no attribute 'signing_key_path'
chown: missing operand after 'matrix-synapse:nogroup'
Try 'chown --help' for more information.
chmod: missing operand after '0600'
Try 'chmod --help' for more information.




As a sidenote: _no_ systemd here. Sysvinit for your service, which may or may 
not 
relate to the problem; it is a completely valid config though.

Bug#917296: emacs-gtk: Emacs GNUS can no longer use movemail

[Florian Weimer]

* Sven Joachim:

> It does not, since Emacs is already configured that way.  In Emacs 26.2,
> the issue will be fixed by the patch at[1] which should probably be
> cherry-picked for the Debian package.
>
> Cheers,
>Sven
>
>
> 1. 
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=63f1dc4f7c33cc7cc738dbfae3d8192ae448b2f6

Not sure why this bug doesn't qualify as important.  It did break my
Gnus setup, but I don't know how often movemail is used these days.

Setting mail-source-movemail-program to "movemail" appears to be a
feasible workaround.

Bug#924909: texlive-fonts-extra: dpkg install texlive-fonts-extra_2018.20190227-1_all.deb hangs

[Norbert Preining]

Hi

> I will attach dpkg.log.gz unless you are asking for

That doesn't help indeed, nothing of interest in there.
Nor the history.

Could you run the dpkg from the command line with debugging (as you did)
and send me the output (private email is fine if you don't want in in
the BTS).

> # cksum ./cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb
> 3652611647 411876816 
> ./cache/apt/archives/texlive-fonts-extra_2018.20190227-1_all.deb

Same as mine.

> Main space has 158GB free,

definitely fine.

> but /tmp is on RAM:
> with (by default) 7.8GB free.

Could be critical. The file, the unpacked version etc all might be
located in tmp.

Can you for the time being set /tmp to something outside of RAM 
(maybe export TMPDIR=/var/tmp is already enough?) and retry.

That sounds like the most probable reason.

If this is not the case, you or I should reassign that to dpkg, this has
nothing to do with the texlive package per se, but is a dpkg issue.

> From the debug messages with -D10 on dpkg, there were a vast number of
> files being, was it "deferred", and I did wonder whether those entries
> were going on a stack somewhere which might have overflowed?

No idea, sorry, this is dpkg parlance.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#924876: debci: Unable to get network up when following documentation

[Antonio Terceiro]

Control: tag -1 + moreinfo

On Sun, Mar 17, 2019 at 10:31:54PM +0100, Xavier Guimard wrote:
> Package: debci
> Version: 2.0
> Severity: normal
> 
> Hi all,
> 
> I followed exactly
> https://ci.debian.net/doc/file.MAINTAINERS.html#label-How+can+I+reproduce+the+test+run+locally-3F
> steps to get a LXC environment. Step "debci setup" fails because network
> isn't well configured. I got these errors:
> 
>   Cannot initiate the connection to deb.debian.org:80 
> (2001:67c:2564:a119::148:14). - connect (101: Network is unreachable)
>
>   ~# cat /etc/lxc/default.conf 
>   lxc.net.0.type = veth
>   lxc.net.0.link = virbr0
>   lxc.net.0.flags = up
>   lxc.apparmor.profile = generated
>   lxc.apparmor.allow_nesting = 1
> 
> Could you update documentation ?

"Network is unreachable" looks like a problem in your general network
setup, or a transient problem in your connection.

You need to provide more information. So far I'm inclined to think there
is nothing wrong in the documentation.


signature.asc
Description: PGP signature

Bug#924917: ITP: golang-github-gliderlabs-ssh -- Easy SSH servers in Golang

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-gliderlabs-ssh
  Version : 0.1.3-1
  Upstream Author : Glider Labs
* URL : https://github.com/gliderlabs/ssh
* License : BSD-3-clause
  Programming Lang: Go
  Description : Easy SSH servers in Golang

 This Go package wraps the crypto/ssh package
 (https://godoc.org/golang.org/x/crypto/ssh) with a higher-level API
 for building SSH servers. The goal of the API was to make it as simple
 as using net/http (https://golang.org/pkg/net/http/), so the API is
 very similar.

This package is in the dependency tree of Lazygit (#908894)

and it depends on another package: "golang-github-anmitsu-go-shlex-dev" 
(#924783)

Bug#924917: RFS: golang-github-gliderlabs-ssh/0.1.3-1

[Dawid Dziurla]

Dear Go team,

I am looking for a sponsor for the package "golang-github-gliderlabs-ssh".
This package is a prerequisite for upcoming package "lazygit" (#908894).

I pushed to our team's Salsa:

  https://salsa.debian.org/go-team/packages/golang-github-gliderlabs-ssh

Could you please reviewing/sponsoring this?
Any kind of reviews and suggestions are appreciated.


This package depends on another package: "golang-github-anmitsu-go-shlex-dev" 
(#924783)

Bug#924918: ITP: golang-github-stvp-roll -- Simple(er) Rollbar client for Go

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-stvp-roll
  Version : 0.0~git20170522.3627a5c-1
  Upstream Author : Stovepipe Studios
* URL : https://github.com/stvp/roll
* License : Expat
  Programming Lang: Go
  Description : Simple(er) Rollbar client for Go

 roll is a basic Rollbar client for Go that reports errors and logs
 messages. It automatically builds stack traces and also supports arbitrary
 traces. All errors and messages are sent to Rollbar synchronously.

This package is in the dependency tree of Lazygit (#908894)

Bug#924863: debian-reference: [INTL:pt] Updated Portuguese translation

[Osamu Aoki]

control: tags -1 pending

On Sun, Mar 17, 2019 at 07:35:43PM +, Américo Monteiro wrote:
> Package: debian-reference
> Version: 2.75
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for  debian-reference messages
> Translator: Américo Monteiro 
> Feel free to use it.
> 
> For translation updates please contact 'Last Translator' 

There is a new fuzzy due to English update.  Sorry.

By the way, if you need write access, please ask via web interface ;-)

Osamu

Bug#924919: RM: python-django-openstack-auth -- ROM; Included in Horizon, deprecated

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP masters,

django-openstack-auth is now integrated in django-horizon, and therefore,
should be completely removed from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#924368: I'll take it

[Adam Borowski]

On Mon, Mar 18, 2019 at 12:53:12PM +0100, Gianfranco Costamagna wrote:
> On Tue, 12 Mar 2019 16:09:35 +0100 Adam Borowski  wrote:
> > Control: retitle -1 ITA: btrfs-progs -- Checksumming Copy on Write 
> > Filesystem utilities
> > Control: owner -1 !
> > 
> > As a long-time user ("thou shalt have no other filesystems before btrfs")
> > and an occassional contributor, I can take it.
> > 
> 
> Thanks Adam for taking care of it!
> Just a side note: I think I sponsored a lot of backports for Nicholas in the 
> past,
> he is a good contributor, and he sends patches upstream and to Debian 
> packaging (dated 2017).
>
> Maybe you can both work on the package, he is a DM so he might even upload by 
> himself if you
> feel comfortable with his work (Nicholas please tell us if you are still 
> interested in btrfs!)

That might work, yeah.

On the other hand, even though there's some quite obvious work to do, doing
disruptive changes to an udeb-producing package during the freeze would be a
very bad idea, thus I plan no uploads anytime soon, doing all changes in
git.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄

Bug#924740: plasma-desktop: plasma activities preview fails with svg wallpapers

[Larus Contract]

The same problem happens when the background is set to a solid colour or 
slideshow; it looks exactly like with an SVG. I would have expected to see the 
colour or a preview of  the image which is currently set as background (meaning 
the current item of the slideshow) to be put into the preview.
Obviously it's the same with Hunyango or Haenau, but I couldn't test image of 
the day, as there doesn't seem to be a provider available.

Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz

[Andreas Beckmann]

On 2019-03-18 13:51, Antonio Terceiro wrote:
> Interesting, it just worked for me on a fresh git clone:

In that case it's probably a dependency problem, my build machine is a
mixed stable..experimental system :-)
I'll investigate ...

Andreas

Bug#838018: mupdf: Inconsistent page navigation - fixed

[Mike]

"this should be configurable"


It IS configurable - use the source. ;-)


I like the fast mupdf very much and have imho fixed it in a more 
consistent way:



https://github.com/linuxCowboy/mupdf/tree/update


It seems upstream didn't care, but maybe we get this in our debian...


lxc

Bug#924920: facter: augeas-tools missing from Recommends directive

[John Bond]

Package: facter
Version: 3.11.0-1.1+b1
Severity: normal

Dear Maintainer,

`augparse`, which is provided by `augeas-tools`, is required by `facter` to
resolve the `augeasversion` fact[1].  If augparse is not present facter
returns an empty string and exits cleanly. please consider adding the
following

--- debian/control  2019-03-18 12:58:07.225993823 +
+++ debian/control.new  2019-03-18 12:58:31.486045832 +
@@ -36,6 +36,7 @@
 Package: facter
 Architecture: any
 Depends: libfacter3.11.0 (= ${binary:Version}), ${shlibs:Depends},
${misc:Depends}
+Recommends: augeas-tools
 Description: collect and display facts about the system
  Facter is Puppet’s cross-platform system profiling library. It discovers
and
  reports per-node facts, which are collected by the Puppet agent and are
made

Thanks John

[1]
https://github.com/puppetlabs/facter/blob/3.11.0/lib/src/facts/resolvers/augeas_resolver.cc#L28-L41

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

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

Versions of packages facter depends on:
ii  libboost-program-options1.67.0  1.67.0-13
ii  libc6   2.28-8
ii  libfacter3.11.0 3.11.0-1.1+b1
ii  libgcc1 1:8.3.0-2
ii  libleatherman1.4.2  1.4.2+dfsg-2+b1
ii  libstdc++6  8.3.0-2

facter recommends no packages.

facter suggests no packages.

-- no debconf information

Bug#922875: xdu: miscounts the size of root directory

[Rémi Vanicat]

Hello,

Le 22 février 2019, Tanaka Akira a écrit:

> Package: xdu
> Version: 3.0-18+b2
> Severity: normal
>
> I found that xdu miscounts the size of root directory.


Well, to be honest, this is an old well known upstream bug for a
software without active upstream.

I will accept any patch that solve it, and might look at it this
summer.

Thanks for your report.

[...]


-- 
Rémi Vanicat

Bug#924918: RFS: golang-github-stvp-roll/0.0~git20170522.3627a5c-1

[Dawid Dziurla]

Dear Go team,

I am looking for a sponsor for the package "golang-github-stvp-roll".
This package is a prerequisite for upcoming package "lazygit" (#908894).

I pushed to our team's Salsa:

  https://salsa.debian.org/go-team/packages/golang-github-stvp-roll

Could you please reviewing/sponsoring this?
Any kind of reviews and suggestions are appreciated.

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Hans-Christoph Steiner]

why do you think patching would be better?  Seems like it would be more
maintenance work than the symlinks.

Bug#923249: [Pkg-libvirt-maintainers] Bug#923249: libvirt0: libvirt sets disable_ipv6 on bridge, entirely breaking internal IPv6 networking

[Guido Günther]

Hi,
On Thu, Feb 28, 2019 at 07:49:47AM +0100, Guido Günther wrote:
> Hi,
> On Wed, Feb 27, 2019 at 10:08:24PM +0100, Ralf Jung wrote:
> > Btw, I reported this upstream at
> > , and made some headway
> > debugging things there.
> 
> Cool, thanks!

https://bugzilla.redhat.com/show_bug.cgi?id=1680681 indicates it's a
kernel issue. Can you add a link to the debian bug you filed so I can
close this issue but mark the other one as affecting libvirt?
Cheers
 -- Guido

>  -- Guido

Bug#924704: bumblebee-nvidia: nvidia-driver 410 doesn't appear to allow the unloading of the nvidia module

[Luca Boccassi]

There are other threads on the upstream repositories with people
suggesting various acpi values for the kernel command line, have a look
if one of the combinations work for your hardware

On Sun, 2019-03-17 at 19:13 -0400, Danfun360 wrote:
> Having set PMMethod to "none" and AlwaysUnloadKernelDriver to "true",
> I still get the bug involving the inability to unload the
> nvidia module for the purpose of VGA Passthrough. I wonder if my
> issue is connected to 
> https://github.com/Bumblebee-Project/bbswitch/issues/173 as "lsmod |
> grep nvidia" gives the result 
> 
> nvidia  16670720  9
> ipmi_msghandler65536  2 ipmi_devintf,nvidia
> 
> Any new suggestions?
> 
> On Sun, Mar 17, 2019 at 12:29 PM Luca Boccassi 
> wrote:
> > As mentioned your hardware might not work with bbswitch and might
> > instead work with the kernel PM. Remove bbswitch and set
> > AlwaysUnloadKernelDriver=true in bumblebee's config file.
> > 
> > On Sat, 2019-03-16 at 22:22 -0400, Danfun360 wrote:
> > > Well, the good news is, the GLX alternative bug with legacy-390xx
> > > appears
> > > to have been fixed.
> > > 
> > > The bad news is that the main bug of bumblebeed failing to load
> > at
> > > startup
> > > for whatever reason is still there. Have any suggestions for
> > > troubleshooting? (Also, since this bug affects both the latest
> > > nvidia-driver (410) as well as nvidia-driver-legacy-390xx, I'd
> > prefer
> > > trying to work with 410)
> > > 
> > > On Sat, Mar 16, 2019 at 5:48 PM Luca Boccassi 
> > > wrote:
> > > 
> > > > That's not the case anymore in buster, 390xx works fine with
> > other
> > > > packages
> > > > 
> > > > On Sat, 16 Mar 2019, 21:03 Danfun360  > wrote:
> > > > 
> > > > > I already tried legacy-390xx. As I said before, there doesn't
> > > > > seem to be
> > > > > equivalents of nvidia-cuda-toolkit and nvidia-cuda-dev that
> > don't
> > > > > try to
> > > > > force the latest nvidia drivers. Also, bumblebee doesn't
> > > > > recognize the
> > > > > legacy-390xx drivers as a GLX alternative (I get an error
> > stating
> > > > > such).
> > > > > 
> > > > > If I was to remove bbswitch, would I be unable to use PRIMUS?
> > > > > Also how
> > > > > would I go about with my VGA Passthrough setup?
> > > > > 
> > > > > On Sat, Mar 16, 2019 at 4:12 PM Luca Boccassi <
> > bl...@debian.org>
> > > > > wrote:
> > > > > 
> > > > > > Control: severity -1 minor
> > > > > > 
> > > > > > Try switching to legacy-390xx, or removing bbswitch and
> > using
> > > > > > the
> > > > > > kernel's power management, with these laptops it's always a
> > > > > > dice roll
> > > > > > on what will actually work
> > > > > > 
> > > > > > On Sat, 2019-03-16 at 14:19 -0400, Danfun360 wrote:
> > > > > > > The graphics card in my laptop is an Nvidia Geforce GTX
> > 1050.
> > > > > > > 
> > > > > > > On Sat, Mar 16, 2019 at 7:20 AM Luca Boccassi
> >  > > > > > > gmail.co
> > > > > > > m>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > What Nvidia card does your laptop have?
> > > > > > > > 
> > > > > > > > On Sat, 16 Mar 2019, 03:42 Daniel O. <
> > danfun...@gmail.com
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > Package: bumblebee-nvidia
> > > > > > > > > Version: 3.2.1-20
> > > > > > > > > Severity: grave
> > > > > > > > > Justification: renders package unusable
> > > > > > > > > 
> > > > > > > > > Dear Maintainer, I write this bug report because this
> > > > > > > > > bumblebee/bumblebeed
> > > > > > > > > doesn't work as it should.
> > > > > > > > > 
> > > > > > > > >* What led up to the situation? Bumblebee used to
> > work
> > > > > > > > > correctly when
> > > > > > > > > the
> > > > > > > > > nvidia driver was at 390. A few days ago it was
> > upgraded
> > > > > > > > > to 410.
> > > > > > > > > At the
> > > > > > > > > time I
> > > > > > > > > was running Debian Buster (testing as of this
> > writing).
> > > > > > > > > That's
> > > > > > > > > where
> > > > > > > > > things
> > > > > > > > > started to get problematic. It appears that the
> > nvidia
> > > > > > > > > module
> > > > > > > > > couldn't be
> > > > > > > > > unloaded or something. bbswitch reported as "ON"
> > without
> > > > > > > > > optirun,
> > > > > > > > > and as
> > > > > > > > > the
> > > > > > > > > nvidia drivers were considered in use, I was unable
> > to
> > > > > > > > > unbind the
> > > > > > > > > nvidia
> > > > > > > > > driver
> > > > > > > > > for VGA Passthrough as I had been doing before.
> > > > > > > > >* What exactly did you do (or not do) that was
> > > > > > > > > effective (or
> > > > > > > > >  ineffective)? I uninstalled every bumblebee and
> > > > > > > > > nvidia
> > > > > > > > > package. I
> > > > > > > > > then
> > > > > > > > > reinstalled everything. No luck. I then uninstalled
> > > > > > > > > everything
> > > > > > > > > and went
> > > > > > > > > for the
> > > > > > > > > legacy 390 package. Unfortunately there were problems
> > > > > > > > > with that:
> > > > > > > > > nvidia-cuba-
> > > 

Bug#924922: ITP: golang-gopkg-src-d-go-billy.v4 -- The missing interface filesystem abstraction for Go

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-gopkg-src-d-go-billy.v4
  Version : 4.3.0-1
  Upstream Author : source{d}
* URL : https://github.com/src-d/go-billy
* License : Apache-2.0
  Programming Lang: Go
  Description : The missing interface filesystem abstraction for Go

 Billy implements an interface based on the os standard library,
 allowing to develop applications without dependency on the underlying storage.
 Makes it virtually free to implement mocks and testing over filesystem 
operations.

This package is in the dependency tree of Lazygit (#908894)

Bug#924921: ITP: golang-github-nozzle-throttler -- Throttler fills the gap between sync.WaitGroup and manually monitoring your goroutines with channels.

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-nozzle-throttler
  Version : 1.1-1
  Upstream Author : Nozzle
* URL : https://github.com/nozzle/throttler
* License : Apache-2.0
  Programming Lang: Go
  Description : Throttler fills the gap between sync.WaitGroup and manually 
monitoring your goroutines with channels.

 The API is almost identical to WaitGroups,
 but it allows you to set a max number of workers that can be
 running simultaneously. It uses channels internally to block until a job
 completes by calling Done() or until all jobs have been completed. It
 also provides a built in error channel that captures your goroutine
 errors and provides access to them as []error after you exit the loop.

This package is in the dependency tree of Lazygit (#908894)

Bug#924924: Release 1.79.2

[Mathieu Malaterre]

Source: docbook-xsl

It seems like there is a new release: 1.79.2 :

https://github.com/docbook/xslt10-stylesheets/releases/tag/release%2F1.79.2

This means the d/watch file should not refer to the old sf.net page anymore:

https://sourceforge.net/projects/docbook/files/docbook-xsl/

Bug#924923: unblock: fltk1.3/1.3.4-9

[Aaron M. Ucko]

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

Please unblock package fltk1.3.

As noted in #924820, I issued my latest upload to unstable on Feb. 27.
The only reason it didn't migrate before the freeze is that I
addressed #921294 (fallout from texlive-latex-extra tabu.sty bug
#920459) by specifically build-depending on an unbroken version of
texlive-latex-extra, which alas turned out not to migrate in a
sufficiently timely fashion.

I see that TeX Live has now migrated, so the only obstacle to
fltk1.3's migration is the freeze.

You can find the changes from 1.3.4-7 at
https://salsa.debian.org/ucko/fltk1.3/compare/debian%2F1.3.4-7...debian%2F1.3.4-9
or in the attached debdiff.

Thanks!

unblock fltk1.3/1.3.4-9

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 fltk1.3-1.3.4/debian/.gitignore fltk1.3-1.3.4/debian/.gitignore
--- fltk1.3-1.3.4/debian/.gitignore 2017-01-16 18:26:31.0 -0500
+++ fltk1.3-1.3.4/debian/.gitignore 2019-02-27 21:21:30.0 -0500
@@ -1,7 +1,9 @@
 *.debhelper
 *.debhelper.log
 *.substvars
+autoreconf.*
 common-build-stamp
+configure.saved
 debhelper-build-stamp
 files
 fltk1.3-doc
diff -Nru fltk1.3-1.3.4/debian/FLTKLibraries-noconfig.cmake.in 
fltk1.3-1.3.4/debian/FLTKLibraries-noconfig.cmake.in
--- fltk1.3-1.3.4/debian/FLTKLibraries-noconfig.cmake.in2011-07-04 
00:07:20.0 -0400
+++ fltk1.3-1.3.4/debian/FLTKLibraries-noconfig.cmake.in1969-12-31 
19:00:00.0 -0500
@@ -1,96 +0,0 @@
-#
-# Generated CMake target import file for configuration "".
-#
-
-# Commands may need to know the format version.
-SET(CMAKE_IMPORT_FILE_VERSION 1)
-
-# Import target "fluid" for configuration ""
-SET_PROPERTY(TARGET fluid APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
-SET_TARGET_PROPERTIES(fluid PROPERTIES
-  IMPORTED_LOCATION_NOCONFIG "/usr/bin/fluid"
-  )
-
-# Import target "fltk" for configuration ""
-SET_PROPERTY(TARGET fltk APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
-SET_TARGET_PROPERTIES(fltk PROPERTIES
-  IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "C;CXX"
-  IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG 
"-lXft;-lfontconfig;-lXinerama;-lX11;-lm"
-  IMPORTED_LOCATION_NOCONFIG "@libdir@/libfltk.a"
-  )
-
-# Import target "fltk_cairo" for configuration ""
-SET_PROPERTY(TARGET fltk_cairo APPEND PROPERTY IMPORTED_CONFIGURATIONS 
NOCONFIG)
-SET_TARGET_PROPERTIES(fltk_cairo PROPERTIES
-  IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "CXX"
-  IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "fltk;-lcairo"
-  IMPORTED_LOCATION_NOCONFIG "@libdir@/libfltk_cairo.a"
-  )
-
-# Import target "fltk_forms" for configuration ""
-SET_PROPERTY(TARGET fltk_forms APPEND PROPERTY IMPORTED_CONFIGURATIONS 
NOCONFIG)
-SET_TARGET_PROPERTIES(fltk_forms PROPERTIES
-  IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "CXX"
-  IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "fltk"
-  IMPORTED_LOCATION_NOCONFIG "@libdir@/libfltk_forms.a"
-  )
-
-# Import target "fltk_images" for configuration ""
-SET_PROPERTY(TARGET fltk_images APPEND PROPERTY IMPORTED_CONFIGURATIONS 
NOCONFIG)
-SET_TARGET_PROPERTIES(fltk_images PROPERTIES
-  IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "CXX"
-  IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "fltk;-lpng;-lz;-ljpeg"
-  IMPORTED_LOCATION_NOCONFIG "@libdir@/libfltk_images.a"
-  )
-
-# Import target "fltk_gl" for configuration ""
-SET_PROPERTY(TARGET fltk_gl APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
-SET_TARGET_PROPERTIES(fltk_gl PROPERTIES
-  IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "CXX"
-  IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "fltk;-lGLU;-lGL"
-  IMPORTED_LOCATION_NOCONFIG "@libdir@/libfltk_gl.a"
-  )
-
-# Import target "fltk_SHARED" for configuration ""
-SET_PROPERTY(TARGET fltk_SHARED APPEND PROPERTY IMPORTED_CONFIGURATIONS 
NOCONFIG)
-SET_TARGET_PROPERTIES(fltk_SHARED PROPERTIES
-  IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG ""
-  IMPORTED_LOCATION_NOCONFIG "@libdir@/libfltk.so.1.3"
-  IMPORTED_SONAME_NOCONFIG "libfltk.so.0"
-  )
-
-# Import target "fltk_cairo_SHARED" for configuration ""
-SET_PROPERTY(TARGET fltk_cairo_SHARED APPEND PROPERTY IMPORTED_CONFIGURATIONS 
NOCONFIG)
-SET_TARGET_PROPERTIES(fltk_cairo_SHARED PROPERTIES
-  IMPORTED_LINK_INTERFACE_LANGUAGES_NOCONFIG "CXX"
-  IMPORTED_LINK_INTERFACE

Bug#924843: msxpertsuite: FTBFS: MassSpectrum.cpp:50:10: fatal error: pwiz/data/msdata/MSDataFile.hpp: No such file or directory

[Filippo Rusconi]

found 924843 5.7.3-1
fixed 924843 5.8.6-2
block 924843 by 923928

thanks

The fix in version 5.8.6-2 (currently in unstable) is needed because libpwiz
changed recently the location of the header files. msxpertsuite was uploaded
after libpwiz exactly as a result of this. However msxpertsuite unfortunately is
blocked in unstable because the documentation building system (daps) cannot yet
enter testing. The un-blocking of daps does not seem be happening anytime soon,
sadly (the un-block bug report was closed last Sun, 17 Mar, see #923928).  


So, if the release managers would reconsider not un-blocking daps, then this bug
would be easily fixable by letting msxpertsuite 5.8.6-2 migrate to testing.

daps is an all-arch project that has no other reverse-dependencies than
msxpertsuite.  The fact that msxpertsuite's documentation (fairly large and
complex) can build using daps is a testimony of the robustness of its debian
packaging.

Thank you for your work on the release of Buster !
Cheers,
Filippo

On Sun, Mar 17, 2019 at 06:58:26PM +0100, Lucas Nussbaum wrote:

Source: msxpertsuite
Version: 5.7.3-1
Severity: serious
Tags: buster sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20190315 qa-ftbfs
Justification: FTBFS in buster on amd64

Hi,

During a rebuild of all packages in buster (in a buster chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):

cd /<>/debian/build/libmass && /usr/bin/c++  -DQT_CORE_LIB -DQT_GUI_LIB -DQT_SCRIPT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB 
-I/<>/debian/build/libmass -I/<>/libmass -I/<>/debian/build/libmass/mass_autogen/include 
-I/<>/debian/build -I/<> -I/usr/include/pwiz -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSvg -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtSql -isystem /usr/include/x86_64-linux-gnu/qt5/QtScript  -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g   -Wno-unknown-pragmas -fPIC -Wall -g -O0 -fopenmp -fPIC -std=c++11 -o CMakeFiles/mass.dir/MassSpectrum.cpp.o -c 
/<>/libmass/MassSpectrum.cpp
/<>/libmass/MassSpectrum.cpp:50:10: fatal error: 
pwiz/data/msdata/MSDataFile.hpp: No such file or directory
 #include 
  ^
compilation terminated.
make[4]: *** [libmass/CMakeFiles/mass.dir/build.make:196: 
libmass/CMakeFiles/mass.dir/MassSpectrum.cpp.o] Error 1


The full build log is available from:
  http://aws-logs.debian.net/2019/03/15/msxpertsuite_5.7.3-1_testing.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#924925: projectm-pulseaudio crashes after a few seconds

[Leszek Lesner]

Package: projectm-pulseaudio
Version: 2.1.0+dfsg-4+b4

Running the visualizer crashes after a few seconds with the following terminal 
output:

> dir:/usr/share/projectM/config.inp
> reading ~/.projectM/config.inp
> [projectM] config file: /home/leszek/.projectM/config.inp
> No Textures Loaded from "/usr"/share/projectM/textures
> [projectM] Allocating idle preset...
> [PresetFactory] path is Geiss & Sperl - Feedback (projectM idle HDR
> mix).milk
> [PresetFactory] url is idle://Geiss & Sperl - Feedback (projectM idle HDR
> mix).milk unconnected: connecting...
> connectHelper:  "alsa_output.pci-_00_1f.3.analog-stereo.monitor"
> CREATED
> READY
> [PresetFactory] path is r/share/projectM/presets/phat_CloseIncouneters.milk
> [PresetFactory] url is
> /usr/share/projectM/presets/phat_CloseIncouneters.milk
> free(): double free detected in tcache 2
> Aborted

Using Debian Buster/Testing with libc6 2.28-8



-- 
ZevenOS / Neptune Team
https://neptuneos.com
Leszek Lesner 

Bug#924032: mpqc3: FTBFS: Could NOT find MPI

[Andreas Tille]

Hi Drew,

On Mon, Mar 18, 2019 at 07:09:22PM +0800, Drew Parsons wrote:
> 
> The log snippet refers to mpich, but most arches use openmpi by default.  So
> that's a clue.
> 
> The full attached log says it's a simple x86_64.  Why then is mpich
> installed?

I think

https://salsa.debian.org/debichem-team/mpqc3/blob/master/debian/control

line 22+23 are answering the question.
 
If I understand your question correctly you would rather suggest:


diff --git a/debian/control b/debian/control
index c47f755..8cdb361 100644
--- a/debian/control
+++ b/debian/control
@@ -19,8 +19,7 @@ Build-Depends: cmake (>= 2.8.11),
libpsi3-dev,
libtbb-dev,
libtiledarray-dev,
-   libmpich-dev,
-   mpich,
+   mpi-default-dev,
psi3 
 Standards-Version: 3.9.6
 Homepage: http://www.mpqc.org


I tried this but this ends up in:


...
-- Performing Test LIBINT_SUPPORTS_G12_T1G12_INTEGRALS
-- Performing Test LIBINT_SUPPORTS_G12_T1G12_INTEGRALS - Failed
-- Found Libint2:
-- <--->LIBINT2_LIBRARY=/usr/lib/libint2.so
-- <--->LIBINT2_INCLUDE_DIR=/usr/include
-- Performing Test PSI3_COMPILES
-- Performing Test PSI3_COMPILES - Success
-- Performing Test HAVE_PSIO_PURGE
-- Performing Test HAVE_PSIO_PURGE - Failed
-- Found PSI3:
-- 
<--->PSI3_LIBRARIES=/usr/lib/libPSI_dpd.a;/usr/lib/libPSI_chkpt.a;/usr/lib/libPSI_iwl.a;/usr/lib/libPSI_qt.a;/usr/lib/libPSI_ciomr.a;/usr/lib/libPSI_psio.a
-- <--->PSI3_INCLUDE_DIR=/usr/include
-- Found TiledArray:
-- <--->TiledArray_INCLUDE_DIR=/usr/include;/usr/include/TiledArray/external
-- <--->TiledArray_LIBRARIES=tiledarray
-- Performing Test TILEDARRAY_COMPILES
CMake Error in 
/build/mpqc3-0.0~git20170114/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CMakeLists.txt:
  Imported target "tiledarray" includes non-existent path

"/usr/include/x86_64-linux-gnu/mpich"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in 
/build/mpqc3-0.0~git20170114/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CMakeLists.txt:
  Imported target "tiledarray" includes non-existent path

"/usr/include/x86_64-linux-gnu/mpich"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

...


Any further hint?

Kind regards

   Andreas.
 

-- 
http://fam-tille.de

Bug#899007: bauble: Depends on unmaintained python-gdata

[Andreas Tille]

Hi,

On Sun, Mar 17, 2019 at 01:49:54PM -0500, Mario Frasca wrote:
> bauble as bauble is indeed dead, both the classic and the web version,
> which by the way never saw light.
> 
> → HOWEVER →
> 
> → while Debian and ubuntu still distribute the grossly outdated bauble
> 0.9.7, development of bauble went up to version 1.0.56, which is still a
> very decent option.

So we should have strived for this since a long time, right?
 
> → beyond version 1.0.56 development goes absolutely uninterrupted on,
> now under the name ghini.desktop.  the last released version of bauble
> informs the user about ghini.desktop, and its new releases.
> 
> → there is no plan to substitute ghini.desktop with a web application:
> there is a ghini.web, which serves a quite different task (integrating
> databases),
> 
> → there might come a ghini.web version allowing limited data insertion. 
> this is not planned at all at the moment. 
> 
> → other packages in the Ghini suite are two Android apps.
> 
> I have been working at a python3 ghini.desktop version, and hope to
> release it before we reach EOL for python2.  I'm stuck with some strange
> delays in database access, which I still need to pin down.

Where is your development done?
 
> I have not been able to follow all necessary steps to put ghini.desktop
> in Debian format, I'm sorry.  once there's a well defined package for
> it, I might be able to keep it up to date, but the initial steps are far
> beyond my limited ability to comply with strict rules.

Why not asking for help?

> Debian Science team?  what is it?

Well, there might be people who would tell you that a web search could
be enlightening ;-P - but I'll try with my own words:  Debian Science is
a team inside Debian (mailing list in CC) which cares for scientic
software that has no dedicated team behind (like astro, chemestry, GIS
etc.)  Its a so called Pure Blend[1] and usually you are well advised to
join this team if you deal with scientific software.  I'm personally
very picky to get any software in the field of *micro*biology into
Debian Med since this team tries to cover all in this field.  However,
from my perception bauble does not really fit into this.

The Debian Science team has a policy[2] that explains how to do the
packaging in this team.  For your comfort I have just commited bauble in
its current state + the fix for its RC bug into Git[3].  I'd volunteer
to make the packaging fully conform to the recent standards (packaging
is quite aged :-().  However, since we are in freeze currently the
changes needed are not really accepted by the release team and thus I
sticked to a minimum set of acceptable changes.

Now I have some questions for you:

1. Would you mind testing the status in Git[3] whether this
   works or not (I have neither any idea nor any interest in
   this program)?
2. Do you think it is sensible to release Buster with this
   status?
If the answer to 2. is
   "yes" we can stop for the moment if it is
   "no" lets remove it from testing and proceed with upgrading
   either to
   a) latest version of bauble?
   b) latest version of ghini.desktop (may be there is
  even a migration path??)

What do you think?

Kind regards

   Andreas.


[1] https://www.debian.org/blends/
[2] https://science-team.pages.debian.net/policy/
[3] https://salsa.debian.org/science-team/bauble
 
> On 17/03/2019 13:05, Giacomo Catenazzi wrote:
> > Hello Andreas,
> >
> > I gave the package to Mario Frasca, which then orphaned the package:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903644
> >
> > gdata is not the only problem, there are other dependencies (which
> > seems to be more complex to solve). Additionally as far I know there
> > is no interest of upstream to continue such package, which I think it
> > is also reasonable: a web application is a lot better.
> >
> > For my point of view, you can put into Debian Science, but possibly we
> > should let it go.
> >
> > ciao
> > cate
> >
> >
> > On 17.03.19 18:29, Andreas Tille wrote:
> >> Hi Giacomo,
> >>
> >> the bug log states that the files using gdata have been removed
> >> upstream[1].  I'd volunteer to commit this package to Salsa in Debian
> >> Science, apply the needed patch and upload as a team upload if you don't
> >> mind.  If I will not hear from you soon I assume you are fine with
> >> the move into Debian Science team.
> >>
> >> Kind regards
> >>
> >>  Andreas.
> >>
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899007#15
> >>
> 
> 

-- 
http://fam-tille.de

Bug#924926: libgpiod2 should not conflict with libgpiod1

[Ben Harris]

Package: libgpiod2
Version: 1.2-3
Severity: normal

Dear Maintainer,

The libgpiod2 package currently conflicts with libgpiod1.  As far as I 
can tell, this is unnecessary.  The two packages share no files and 
provide different SONAMEs, and seem to be co-installable.  I have tried 
installing both (with --force-conflicts) and my program linked against 
libgpiod.so.1 still works.

This conflict is a problem because it means that I can't install the new 
libgpiod-dev and recompile my program against it without first breaking 
the existing version.  This makes a smooth upgrade more difficult than 
it should be.

Debian Policy, in a footnote, has this to say about conflicts between 
versions of shared libraries:

"There are some exceptional situations in which co-installation of two 
versions of a shared library is not safe, and the new shared library 
package has to conflict with the previous shared library package. This 
is never desirable, since it causes significant disruption during 
upgrades and potentially breaks unpackaged third-party binaries, but is 
sometimes unavoidable. These situations are sufficiently rare that they 
usually warrant project-wide discussion, and are complex enough that the 
rules for them cannot be codified in Debian Policy."


I've glanced over the last year of debian-devel and I haven't noticed 
any sign of the expected project-wide discussion.

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

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

Versions of packages libgpiod2 depends on:
ii  libc6   2.28-8
ii  libgcc1 1:8.3.0-2
ii  libstdc++6  8.3.0-2

libgpiod2 recommends no packages.

libgpiod2 suggests no packages.

-- no debconf information

Bug#923249: [Pkg-libvirt-maintainers] Bug#923249: libvirt0: libvirt sets disable_ipv6 on bridge, entirely breaking internal IPv6 networking

[Ralf Jung]

Hi,

> https://bugzilla.redhat.com/show_bug.cgi?id=1680681 indicates it's a
> kernel issue. Can you add a link to the debian bug you filed so I can
> close this issue but mark the other one as affecting libvirt?
> Cheers
>  -- Guido

That Debian kernel bug is at
.

; Ralf

Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Daniel Kahn Gillmor]

On Mon 2019-03-18 10:55:44 +0100, Tim Rühsen wrote:
> Libiconv 1.15 itself from tarball.
>
> If you are interested in the details, have a look at our CI Dockerfile
> where we build/install the dependencies needed for testing:
>
> https://gitlab.com/gnuwget/build-images/blob/master/docker-debian-mingw/Dockerfile

interesting, thanks!

If anyone else needs win-iconv in debian, please speak up!

Otherwise i'll probably move forward with orphaning the package soon.

 --dkg

Bug#924767: pgadmin3: Incorrectly installs entire database engine as dependency

[Christoph Berg]

Re: Svjatoslav Agejenko 2019-03-17 
<155281965045.6203.3913833993162259864.reportbug@n0laptop>
> Package: pgadmin3
> Version: 1.22.2-5
> Severity: important
> 
> Dear Maintainer,
> 
> When I install pgadmin3 via apt-get, PostgreSQL database engine and service
> also gets installed.

Hi,

this is because

Package: pgadmin3
Recommends: pgagent, postgresql-client

Package: pgagent
Depends: [] postgresql-11

> I can uninstall PostgreSQL database manually afterwards, but it should
> not be auto installed in the first place.

You could turn off installing recommends automatically, e.g. using

apt-get install --no-install-recommends pgadmin3

> I want admin application to manage remote installations.
> I don't want local database engine to be installed and always
> running just in case.

Nod. I'll demote the dependency to a "Suggests" in the next upload.
(The change will likely not make it into Debian buster, though.)

Christoph

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Hans-Christoph Steiner]

circular Depends:/Recommends: are easy, circular Build-Depends: are
what's hard.  Plus using the /usr/bin/ method, that will make fastboot
require e2fsprogs and other packages, rather than just recommend.

Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz

[Antonio Terceiro]

Control: tag -1 + moreinfo

On Mon, Mar 18, 2019 at 11:25:33AM +0100, Andreas Beckmann wrote:
> Package: pristine-tar
> Version: 1.46
> Severity: important
> 
> In this repository:
> 
> https://salsa.debian.org/python-team/modules/python-django.git
> 
> $ pristine-tar checkout python-django_1.11.20.orig.tar.gz
> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
> xdelta3: normally this indicates that the source file is incorrect
> xdelta3: please verify the source file with sha1sum or equivalent
> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
> xdelta3: normally this indicates that the source file is incorrect
> xdelta3: please verify the source file with sha1sum or equivalent
> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
> xdelta3: normally this indicates that the source file is incorrect
> xdelta3: please verify the source file with sha1sum or equivalent
> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
> xdelta3: normally this indicates that the source file is incorrect
> xdelta3: please verify the source file with sha1sum or equivalent
> xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
> xdelta3: normally this indicates that the source file is incorrect
> xdelta3: please verify the source file with sha1sum or equivalent
> pristine-tar: Failed to reproduce original tarball. Please file a bug
> report.
> pristine-tar: failed to generate tarball

Interesting, it just worked for me on a fresh git clone:

python-django (debian/sid) $ pristine-tar checkout 
python-django_1.11.20.orig.tar.gz
pristine-tar: successfully generated python-django_1.11.20.orig.tar.gz

Do you have anything locally that is not also in the remote repository?


signature.asc
Description: PGP signature

Bug#924876: debci: Unable to get network up when following documentation

[Xavier]

Le 18/03/2019 à 13:14, Antonio Terceiro a écrit :
> Control: tag -1 + moreinfo
> 
> On Sun, Mar 17, 2019 at 10:31:54PM +0100, Xavier Guimard wrote:
>> Package: debci
>> Version: 2.0
>> Severity: normal
>>
>> Hi all,
>>
>> I followed exactly
>> https://ci.debian.net/doc/file.MAINTAINERS.html#label-How+can+I+reproduce+the+test+run+locally-3F
>> steps to get a LXC environment. Step "debci setup" fails because network
>> isn't well configured. I got these errors:
>>
>>   Cannot initiate the connection to deb.debian.org:80 
>> (2001:67c:2564:a119::148:14). - connect (101: Network is unreachable)
>>
>>   ~# cat /etc/lxc/default.conf 
>>   lxc.net.0.type = veth
>>   lxc.net.0.link = virbr0
>>   lxc.net.0.flags = up
>>   lxc.apparmor.profile = generated
>>   lxc.apparmor.allow_nesting = 1
>>
>> Could you update documentation ?
> 
> "Network is unreachable" looks like a problem in your general network
> setup, or a transient problem in your connection.


Thanks for looking at this.

I'm using a new debian/testing laptop installed last week with weekly
build installer, without any "dpkg-reconfigure" or modification except
postfix. No network problem except for LXC (tried many times) [default
Wifi/DHCP configuration, local network clean - fiber]. No unstable
packages except lintian.

> You need to provide more information. So far I'm inclined to think there
> is nothing wrong in the documentation.

Which files can I provide ?

My goal is to reproduce a FTBFS on node-formidable that builds well
using autopkgtest/schroot.

Cheers,
Xavier

Bug#899007: bauble: Depends on unmaintained python-gdata

[Mario Frasca]

Hi!

On 18/03/2019 08:36, Andreas Tille wrote:
> So we should have strived for this since a long time, right?

well, yes, I think so.  the original author opened this one in 2012:

https://bugs.launchpad.net/ubuntu/+source/bauble/+bug/1093035


> Where is your development done? 

https://github.com/Ghini

bauble is also on github.  In October 2015 I had been made owner of the
project (https://github.com/Bauble/bauble.classic).  Soon after that,
the slot 'bauble.web' became occupied and I preferred moving everything
under a new organization.


>> I have not been able to follow all necessary steps to put ghini.desktop
>> in Debian format, I'm sorry.  once there's a well defined package for
>> it, I might be able to keep it up to date, but the initial steps are far
>> beyond my limited ability to comply with strict rules.
> Why not asking for help?

eh, , how to say that?  I've not been successful at finding the
right person.  I got some help from, …, I can't remember and I don't
think it's relevant here.  the guy gave me information and hints, but it
was still me who had to follow the Debian rules, and after several
attempts, bouncing back with "not good enough", I gave up.


>
>> Debian Science team?  what is it?
> Well, there might be people who would tell you that a web search could
> be enlightening ;-P - but I'll try with my own words:  

thank you!  I prefer email, and at the moment I have a very fast and
quite expensive connection to the internet, before you know, opening one
single page eats up 5% of my weekly allowance.  I appreciate your text.

I have read the remainder of your email, and I'm looking into your
questions 1 and 2.  possibly short-circuiting, if your "this status"
means "bauble-0.9.x", then you already have my answer to question 2: no,
it's not sensible. 

but let me check and I will come back to you shortly.

ciao,

Mario

> Debian Science is
> a team inside Debian (mailing list in CC) which cares for scientic
> software that has no dedicated team behind (like astro, chemestry, GIS
> etc.)  Its a so called Pure Blend[1] and usually you are well advised to
> join this team if you deal with scientific software.  I'm personally
> very picky to get any software in the field of *micro*biology into
> Debian Med since this team tries to cover all in this field.  However,
> from my perception bauble does not really fit into this.
>
> The Debian Science team has a policy[2] that explains how to do the
> packaging in this team.  For your comfort I have just commited bauble in
> its current state + the fix for its RC bug into Git[3].  I'd volunteer
> to make the packaging fully conform to the recent standards (packaging
> is quite aged :-().  However, since we are in freeze currently the
> changes needed are not really accepted by the release team and thus I
> sticked to a minimum set of acceptable changes.
>
> Now I have some questions for you:
>
> 1. Would you mind testing the status in Git[3] whether this
>works or not (I have neither any idea nor any interest in
>this program)?
> 2. Do you think it is sensible to release Buster with this
>status?
> If the answer to 2. is
>"yes" we can stop for the moment if it is
>"no" lets remove it from testing and proceed with upgrading
>either to
>a) latest version of bauble?
>b) latest version of ghini.desktop (may be there is
>   even a migration path??)
>
> What do you think?
>
> Kind regards
>
>Andreas.
>
>
> [1] https://www.debian.org/blends/
> [2] https://science-team.pages.debian.net/policy/
> [3] https://salsa.debian.org/science-team/bauble
>  
>> On 17/03/2019 13:05, Giacomo Catenazzi wrote:
>>> Hello Andreas,
>>>
>>> I gave the package to Mario Frasca, which then orphaned the package:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903644
>>>
>>> gdata is not the only problem, there are other dependencies (which
>>> seems to be more complex to solve). Additionally as far I know there
>>> is no interest of upstream to continue such package, which I think it
>>> is also reasonable: a web application is a lot better.
>>>
>>> For my point of view, you can put into Debian Science, but possibly we
>>> should let it go.
>>>
>>> ciao
>>> cate
>>>
>>>
>>> On 17.03.19 18:29, Andreas Tille wrote:
 Hi Giacomo,

 the bug log states that the files using gdata have been removed
 upstream[1].  I'd volunteer to commit this package to Salsa in Debian
 Science, apply the needed patch and upload as a team upload if you don't
 mind.  If I will not hear from you soon I assume you are fine with
 the move into Debian Science team.

 Kind regards

  Andreas.

 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899007#15

Bug#924784: python-django: FTBFS on i386: OverflowError: timestamp out of range for platform time_t

[Chris Lamb]

forwarded 924784 https://code.djangoproject.com/ticket/30264#ticket
thanks

I've forwarded this upstream here:

  https://code.djangoproject.com/ticket/30264#ticket


Regards,

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

Bug#924916: RM: python-django-openstack-auth -- RoM; provided by python3-django-horizon

[Thomas Goirand]

On 3/18/19 12:56 PM, Andreas Beckmann wrote:
> Source: python-django-openstack-auth
> Version: 3.5.0-2
> Severity: serious
> 
> Hi Thomas,
> 
> can this package be removed? If so, please reassign to ftp.debian.org
> (and lover the severity to normal).
> 
> I'm again investigating openstack-dashboard related upgrade failures.
> This may be #905183 returning, never being fixed, or a different
> problem.
> 
> Having python-django-openstack-auth and python3-django-openstack-auth
> available as both real packages (from src:python-django-openstack-auth)
> and virtual packages (Provides/Conflicts/Replaces by
> python3-django-horizon) does not make things easier for apt in this
> case.
> And I doubt that providing a python2 module from a python3 package is a
> good idea ...
> 
> There are no rdepends left that depend on these packages.
> So maybe consider dropping the Provides and Replaces (but keep the
> Conflicts) in python3-django-horizon as well.
> 
> 
> Thanks
> 
> Andreas

Andreas,

Indeed, django-openstack-auth has been removed upstream and included
directly in django-horizon. I'm not sure what's the best way to get
completely rid of it on upgrades and get Horizon the best way
possible... I thought I did well, but you're telling me the opposite.
So, any advice would be welcome.

I've filed a new bug for its removal: #924919. So I'm therefore closing
this one.

Cheers,

Thomas Goirand (zigo)

Bug#923720: plasma-discover: Plasma-discover segfaults on Stretch

[Bernhard Übelacker]

Control: reassign 923720 libappstreamqt2/0.10.6-2
Control: affects 923720 plasma-discover
Control: fixed 923720 libappstreamqt2/0.11.3-1
Control: fixed 923720 plasma-discover/5.10.5-1
Control: tags 923720 + upstream fixed-upstream patch



Hello Everyone,
tried to get some more information from the backtrace.

I could not reproduce it but I think in this case method
AppStream::Pool::load got called with strerror being a null
pointer and for some reason the pool could not be loaded,
therefore line 77 was reached, trying to dereference strerror.

(gdb) list AppStream::Pool::load(QString*)   
71
72  bool Pool::load(QString* strerror)
73  {
74  g_autoptr(GError) error = nullptr;
75  bool ret = as_pool_load (d->m_pool, NULL, &error);
76  if (!ret && error) {
77  *strerror = QString::fromUtf8(error->message);  <<<
78  }
79  return ret;
80  }
81

This led to upstream fix in package appstream, available since 0.11.3: [1] [2]
Another fix was done in discover before, available since v5.10.5: [3] [4]

Therefore I assume this just affects Stretch.

Kind regards,
Bernhard


[1] https://github.com/ximion/appstream/pull/126
[2] 
https://github.com/ximion/appstream/commit/32f1445fd3f348598edd5e24e29ad3644c299639
[3] https://bugs.kde.org/show_bug.cgi?id=382916
[4] 
https://cgit.kde.org/discover.git/commit/?id=3a718124d45d60c49bb586e14d348f233178b34b

# Stretch amd64 qemu VM

apt update
apt dist-upgrade

apt install devscripts dpkg-dev systemd-coredump gdb xserver-xorg sddm 
plasma-desktop muon libappstreamqt2-dbgsym plasma-discover-dbgsym 
libglib2.0-0-dbg


systemctl start sddm



mkdir /tmp/source/appstream/orig -p
cd/tmp/source/appstream/orig
apt source appstream
cd



###

export DISPLAY=:0
# plasma-discover
gdb -q --args plasma-discover


set width 0
set pagination off
directory /tmp/source/appstream/orig/appstream-0.10.6
display/i $pc
break AppStream::Pool::load
y
run
disa 1.1
disa 1.3
disa 1.4
cont
bt






benutzer@debian:~$ gdb -q --args plasma-discover
Reading symbols from plasma-discover...Reading symbols from 
/usr/lib/debug/.build-id/8e/af6f71ec2d372a44c646c9eb0311f4bb45dd50.debug...done.
done.
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /tmp/source/appstream/orig/appstream-0.10.6
Source directories searched: 
/tmp/source/appstream/orig/appstream-0.10.6:$cdir:$cwd
(gdb) display/i $pc
1: x/i $pc

(gdb) break AppStream::Pool::load
Function "AppStream::Pool::load" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (AppStream::Pool::load) pending.
(gdb) run
Starting program: /usr/bin/plasma-discover 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe66c2700 (LWP 2475)]
[New Thread 0x7fffe5a39700 (LWP 2476)]
[New Thread 0x7fffe5238700 (LWP 2478)]
[New Thread 0x7fffd278d700 (LWP 2479)]
[New Thread 0x7fffd1f8c700 (LWP 2480)]
[New Thread 0x7fffd178b700 (LWP 2481)]
[New Thread 0x7fffd0f8a700 (LWP 2482)]
[New Thread 0x7fffd0789700 (LWP 2483)]
[New Thread 0x7fffcff88700 (LWP 2484)]
[New Thread 0x7fffcf787700 (LWP 2485)]
[New Thread 0x7fffcef86700 (LWP 2486)]
[New Thread 0x7fffce01e700 (LWP 2487)]
[New Thread 0x7fffcd81c700 (LWP 2488)]
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami/GlobalDrawer.qml:213:9:
 QML Flickable: Binding loop detected for property "contentWidth"
invalid kns backend! "" because: "Couldn't find knsrc file: comic.knsrc"

Thread 1 "plasma-discover" hit Breakpoint 1, 0x7fffc77e3cd0 in 
AppStream::Pool::load()@plt () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/discover/packagekit-backend.so
1: x/i $pc
=> 0x7fffc77e3cd0 <_ZN9AppStream4Pool4loadEv@plt>:  jmpq   *0x2305ca(%rip)  
  # 0x7fffc7a142a0
(gdb) disa 1.1
(gdb) disa 1.3
(gdb) disa 1.4
(gdb) cont
Continuing.

Thread 1 "plasma-discover" hit Breakpoint 1, AppStream::Pool::load 
(this=this@entry=0x55dcd3c8, strerror=strerror@entry=0x0) at 
./qt/pool.cpp:73
73  {
1: x/i $pc
=> 0x7fffc738d020 :push   %r12
(gdb) next
75  bool ret = as_pool_load (d->m_pool, NULL, &error);
1: x/i $pc
=> 0x7fffc738d038 : mov0x10(%rdi),%rax
(gdb) 
74  g_autoptr(GError) error = nullptr;
1: x/i $pc
=> 0x7fffc738d03c : movq   $0x0,0x10(%rsp)
(gdb) 
75  bool ret = as_pool_load (d->m_pool, NULL, &error);
1: x/i $pc
=> 0x7fffc738d045 : test   %rax,%rax
(gdb) 
76  if (!ret && error) {
1: x/i $pc
=> 0x7fffc738d065 : jne0x7fffc738d0b8 


(gdb) bt
#0  0x7fffc738d065 in AppStream::Pool::load(QString*) 
(this=this@entry=0x55dcd3c8, strerror=strerror@entry=0x0) at 
./qt/pool.cpp:76
#1  0x7fffc738d147 in AppStream::Pool::load() 
(this=this@entry=0x55dcd3c8) at ./qt/pool.cpp:69
#2  0x7fffc77ea7f3 in PackageKitBackend::PackageKitBackend(QObject*) 
(this=0x55dcd3b0, parent=) at 
./libdiscover/backends/Pac

Bug#924692: apport: /var/crash/.lock created insecurely

[Ritesh Raj Sarraf]

On Fri, 2019-03-15 at 22:39 +0100, Jakub Wilk wrote:
> Apport tries to create /var/crash/.lock if doesn't exist already.
> But 
> /var/crash/ is world-writable, so a malicious local user could do:
> 
>ln -sf /nonexistent /var/crash/.lock
> 
> to prevent Apport from creating the lock file.

Yes. /var/crash/ is world writable and has the sticky bit set. It is
needed so that normal (unprivileged) user processes also write down
their crash reports without seeking root privileges.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#924115: golang-gopkg-data-dog-go-sqlmock.v1-dev: directory vs. symlink conflict: /usr/share/gocode/src/gopkg.in/DATA-DOG/go-sqlmock.v1

[rajudev]

Reply In Between

Shengjing Zhu writes:

> On Tue, Mar 12, 2019 at 11:25 PM rajudev  wrote:
>>
>>
>> Shengjing Zhu writes:
>>
>> > Hi Raju,
>>
>> Ni Hao :)
>> >
>> > This package seems problematic in other  perspective,
>> Indeed it is confusing.
>> >
>> > golang-github-data-dog-go-sqlmock-dev is already in archive, and can
>> > be imported as gopkg.in/DATA-DOG/go-sqlmock.v1 or
>> > github.com/DATA-DOG/go-sqlmock.
>> >
>> > So this package is duplicated.
>>
>> I think no.
>>
>> >
>> > gopkg.in/DATA-DOG/go-sqlmock.v1 is not in
>> > src:golang-github-data-dog-go-sqlmock's Go-Import-Path field, this
>> > should be fixed in golang-github-data-dog-go-sqlmock. I think that's
>> > why you were not aware, and upload a new one.
>> I did looked at the other package and I was aware.
>>
>> then I looked at https://gopkg.in/DATA-DOG/go-sqlmock.v1
>>
>> The upstream maintains three different versions of the same package.
>> And authors of other golang packages use different versions in there code.
>
> the current version
> + golang-gopkg-data-dog-go-sqlmock.v1-dev is 1.3.0-1
> + golang-github-data-dog-go-sqlmock-dev is 1.3.0-1
>
> They are the same version, and same code. So it's duplicated.
>
> And as I said before, golang-github-data-dog-go-sqlmock-dev can be
> used for package which imports gopkg.in/DATA-DOG/go-sqlmock.v1.
> Please just think why it installs a symlink named
> /usr/share/gocode/src/gopkg.in/DATA-DOG/go-sqlmock.v1.
> And take prometheus-mysqld-exporter package as example, it imports
> gopkg.in/DATA-DOG/go-sqlmock.v1 and build fine with
> golang-github-data-dog-go-sqlmock-dev.
>
>>
>> The efforts behind this package were made as it is a dependency for
>> micro text editor, which is now in upload queue.
>>
>> https://ftp-master.debian.org/new/micro_1.4.1-1.html
>>
>
> I don't see golang-gopkg-data-dog-go-sqlmock.v1-dev is in micro's
> Build-Depends.

Initially I got this package done as it was shown as a estimated
dependency of go-colorful[1], which is a dependency of multiple packages
including micro.

[1]
https://salsa.debian.org/libregeekingkid-guest/micro/wikis/Dependency-Tree-of-Micro

so I packaged it as required. I have now checked that go-colorful builds
fine with golang-github-data-dog-go-sqlmock-dev as you suggested.

Hence now I agree that golang-github-data-dog-go-sqlmock.v1 should be removed 
instead.

Thanks for pointing this out.

I'll file the removal bug. 

>
>
>>
>> >
>> > I think file a RM request for ftp-master is the solution here.
>>
>> If we file an RM request for this one, it will break micro.
>>
>> I am open to any suggestions, or comments on the situation.
>>
>> -
>> rajudev

Bug#924693: apport: /var/crash/.lock is world-writable

[Ritesh Raj Sarraf]

On Fri, 2019-03-15 at 22:40 +0100, Jakub Wilk wrote:
> Apport creates /var/crash/.lock as readable and writable for anyone:
> 
># ls -l /var/crash/.lock
>-rwxrwxrwx 1 root root 0 Mar 15 22:30 /var/crash/.lock
> 
> This allows malicious local users to do bad things:
> 
> * They could fill up the disk, bypassing quotas.
> 
> * They could acquire lock on the file and never release it,
> effectively 
> disabling core dumping for everyone.
> 
> * They could use the file as an aid in exploitation other 
> vulnerabilities, such as this:
> http://www.halfdog.net/Security/2015/MandbSymlinkLocalRootPrivilegeEscalation/
> 
> 
> Please make the lock file accessible only to root.

Please see attached patch. I think it should fix the issue and not
create any regressions. The reason I say "I think" is because I gave up
on using apport lately. Also as you can see from the package log, this
package has only been part of experimental and lately I'm more inclined
to get it removed from Debian.

Do you use apport ? Or have interest for it in Debian ?

rrs@priyasi:~/rrs-home/Community/Packaging/apport (master)$ cat 
debian/patches/lock-file-perms.patch 
Interim fix for the security issues reported
--- a/bin/crash-digger
+++ b/bin/crash-digger
@@ -195,7 +195,7 @@
 
 if opts.lockfile:
 try:
-f = os.open(opts.lockfile, os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o666)
+f = os.open(opts.lockfile, os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o644)
 os.write(f, ("%u\n" % os.getpid()).encode())
 os.close(f)
 except OSError as e:
--- a/data/apport
+++ b/data/apport
@@ -34,7 +34,7 @@
 # create a lock file
 lockfile = os.path.join(apport.fileutils.report_dir, '.lock')
 try:
-fd = os.open(lockfile, os.O_WRONLY | os.O_CREAT | os.O_NOFOLLOW)
+fd = os.open(lockfile, os.O_WRONLY | os.O_CREAT | os.O_NOFOLLOW, 0o644)
 except OSError as e:
 error_log('cannot create lock file (uid %i): %s' % (os.getuid(), 
str(e)))
 sys.exit(1)
20:04 ♒♒♒   ☺ 😄

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#923720: plasma-discover: Plasma-discover segfaults on Stretch

[Bernhard Übelacker]

reassign 923720 libappstreamqt2 0.10.6-2

Bug#924927: debian-edu-config: broken PXE installation framework

[Wolfgang Schweer]

Package: debian-edu-config
Version: 2.10.62
Severity: important

While testing offline installation using the BD ISO image I noticed that
setting up the PXE installation framework doesn't work.

the d-i version is still at 9 (Stretch)
distribution determination gives back n/a because lsb_release is missing the
related attribute in offline mode.

Wolfgang

Bug#923711:

[Pacho Ramos]

Dropping 0016-remove-frag_deflator_thread.patch and
0017-add-zstd-support.patch stops the memory leak

Bug#924928: translations dashboards include broken links if the file is deleted

[Laura Arjona Reina]

Package: www.debian.org
User: www.debian@packages.debian.org
Usertag: scripts
Severity: normal

Hi all
When a file is deleted in the /english tree, the translation coordinations 
dashboards shows something like:


devel/cvs_packages  0 (0.00 ‰)  [L] [V] [F]

The [L] link points to a broken URL:
https://salsa.debian.org/webmaster-team/webwml/commits//english/devel/cvs_packages.wml

The commit deleting the file was:
https://salsa.debian.org/webmaster-team/webwml/commit/e64f14dabbc209061f6ad3b317236189aa702271

If the translator clicks in the [L] to see what changed in the original English, 
it arrives to a 404 page (Not Found).
I'm not sure if everybody can infer from the "0 (0.00 ‰)" column that the file 
is deleted and they should delete in their language subtree too.


Kind regards
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#922042: Acknowledgement (x2gobroker: traceback when run as WSGI process from apache)

[Mike Gabriel]

Hi Linnea,

On  Mo 18 Mär 2019 14:36:20 UTC, Linnea Skogtvedt wrote:


Den 18.03.2019 11:02, skrev Mike Gabriel:

Hi again,

please find a corrected patch attached.

On Fri, 15 Feb 2019 16:15:05 +0100 Linnea Skogtvedt
 wrote:

This issue appears to have been caused by this commit:



https://code.x2go.org/gitweb?p=x2gobroker.git;a=commit;h=f9dd59dd656019f593d37d234a2859cc17696061



This is supported by the fact that I could work around the bug by adding
in the deleted code in a wsgi wrapper script as follows:

# cat /etc/x2go/wsgi/x2gobroker.wsgi

#!/usr/bin/python3
from x2gobroker.loggers import logger_broker, logger_access,
logger_error, tornado_log_request, PROG_NAME
exec(open("/usr/bin/x2gobroker").read())


The patch I sent a little bit earlier contained a flawed line. Please
test with this patch.

Thanks,
Mike


Hi Mike, I can confirm that the patch fixes the issue.

Kind regards,

Linnea


Thanks! Very good.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgpjEzA758D6m.pgp
Description: Digitale PGP-Signatur

Bug#922040: x2gobroker-wsgi: default apache configuration gives 403 error

[Mike Gabriel]

Hi Linnea,

(re-Cc-ing the Debian bug)

On  Mo 18 Mär 2019 14:38:54 UTC, Linnea Skogtvedt wrote:


Den 18.03.2019 12:25, skrev Mike Gabriel:

Control: tags -1 patch

Hi Linnea,

On Mon, 11 Feb 2019 15:11:01 +0100 Linnea Skogtvedt
 wrote:

Package: x2gobroker-wsgi
Version: 0.0.4.0-3

wget -O - http://127.0.0.1/x2gobroker/ yields a 403 Forbidden error
message. /var/log/apache2/error.log shows the following message:
[authz_core:error] ... [client 127.0.0.1:49216] AH01630: client denied
by server configuration: /usr/bin/x2gobroker

Editing /etc/apache2/conf-available/x2gobroker-wsgi.conf to change
 to  and restarting
apache2 removes the 403 Forbidden error, but it's not a good
configuration. I suggest creating a WSGI wrapper script in its own
subdirectory.


I am using a freshly installed Debian testing VM, with unstable added in
sources.list to be able to install x2gobroker. I used the following
command to install the packages: apt install apache2 x2gobroker
x2gobroker-wsgi


can you rebuild your x2gobroker instance from source with attached patch
applied (or alternatively, reconfigure your runtime instance as
demonstrated by the patch's content) and check whether the above issue
is solved then?

Thanks,
Mike


Hi Mike,

I have tested by purging all x2gobroker packages and rebuilding with
your patch. Can confirm that it solves the issue.

Kind regards,

Linnea


Thanks. Very cool!

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgpynMM7Rq0qN.pgp
Description: Digitale PGP-Signatur

Bug#924617: poppler-utils: I am also waiting for this release

[Kristof Csillag]

Package: poppler-utils
Version: 0.71.0-3
Followup-For: Bug #924617

I am also waiting for this update, because of an different bug.

Thanks.

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

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

Versions of packages poppler-utils depends on:
ii  libc6 2.28-8
ii  libcairo2 1.16.0-4
ii  libfreetype6  2.9.1-3
ii  liblcms2-22.9-3
ii  libpoppler82  0.71.0-3
ii  libstdc++68.3.0-3

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- debconf-show failed

Bug#924692: apport: /var/crash/.lock created insecurely

[Ritesh Raj Sarraf]

On Mon, 2019-03-18 at 19:57 +0530, Ritesh Raj Sarraf wrote:
> On Fri, 2019-03-15 at 22:39 +0100, Jakub Wilk wrote:
> > Apport tries to create /var/crash/.lock if doesn't exist already.
> > But 
> > /var/crash/ is world-writable, so a malicious local user could do:
> > 
> >ln -sf /nonexistent /var/crash/.lock
> > 
> > to prevent Apport from creating the lock file.
> 
> Yes. /var/crash/ is world writable and has the sticky bit set. It is
> needed so that normal (unprivileged) user processes also write down
> their crash reports without seeking root privileges.

Yes. But that still does not fix the security concern raised in this
bug report. What would be the optimal fix for this ? Set /var/crash/ to
root:adm and 1664 permissions ?


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#924032: mpqc3: FTBFS: Could NOT find MPI

[Alastair McKinstry]

Hi,

This is fixed with an upload to mpich this morning (GCC / MPICH version 
issue). It builds with the latest version


regards

Alastair

On 18/03/2019 13:06, Andreas Tille wrote:

Hi Drew,

On Mon, Mar 18, 2019 at 07:09:22PM +0800, Drew Parsons wrote:

The log snippet refers to mpich, but most arches use openmpi by default.  So
that's a clue.

The full attached log says it's a simple x86_64.  Why then is mpich
installed?

I think

 https://salsa.debian.org/debichem-team/mpqc3/blob/master/debian/control

line 22+23 are answering the question.
  
If I understand your question correctly you would rather suggest:



diff --git a/debian/control b/debian/control
index c47f755..8cdb361 100644
--- a/debian/control
+++ b/debian/control
@@ -19,8 +19,7 @@ Build-Depends: cmake (>= 2.8.11),
 libpsi3-dev,
 libtbb-dev,
 libtiledarray-dev,
-   libmpich-dev,
-   mpich,
+   mpi-default-dev,
 psi3
  Standards-Version: 3.9.6
  Homepage: http://www.mpqc.org


I tried this but this ends up in:


...
-- Performing Test LIBINT_SUPPORTS_G12_T1G12_INTEGRALS
-- Performing Test LIBINT_SUPPORTS_G12_T1G12_INTEGRALS - Failed
-- Found Libint2:
-- <--->LIBINT2_LIBRARY=/usr/lib/libint2.so
-- <--->LIBINT2_INCLUDE_DIR=/usr/include
-- Performing Test PSI3_COMPILES
-- Performing Test PSI3_COMPILES - Success
-- Performing Test HAVE_PSIO_PURGE
-- Performing Test HAVE_PSIO_PURGE - Failed
-- Found PSI3:
-- 
<--->PSI3_LIBRARIES=/usr/lib/libPSI_dpd.a;/usr/lib/libPSI_chkpt.a;/usr/lib/libPSI_iwl.a;/usr/lib/libPSI_qt.a;/usr/lib/libPSI_ciomr.a;/usr/lib/libPSI_psio.a
-- <--->PSI3_INCLUDE_DIR=/usr/include
-- Found TiledArray:
-- <--->TiledArray_INCLUDE_DIR=/usr/include;/usr/include/TiledArray/external
-- <--->TiledArray_LIBRARIES=tiledarray
-- Performing Test TILEDARRAY_COMPILES
CMake Error in 
/build/mpqc3-0.0~git20170114/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CMakeLists.txt:
   Imported target "tiledarray" includes non-existent path

 "/usr/include/x86_64-linux-gnu/mpich"

   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

   * The path was deleted, renamed, or moved to another location.

   * An install or uninstall procedure did not complete successfully.

   * The installation package was faulty and references files it does not
   provide.



CMake Error in 
/build/mpqc3-0.0~git20170114/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CMakeLists.txt:
   Imported target "tiledarray" includes non-existent path

 "/usr/include/x86_64-linux-gnu/mpich"

   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

   * The path was deleted, renamed, or moved to another location.

   * An install or uninstall procedure did not complete successfully.

   * The installation package was faulty and references files it does not
   provide.

...


Any further hint?

Kind regards

Andreas.
  


--
Alastair McKinstry, , , 
@amckinstry:matrix.org
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#924575: systemd-networkd doesn't process IPv6 RA properly

[Johan Wassberg]

> On 15 Mar 2019, at 08:37, Johan Wassberg  wrote:
> 
>> (would be great if you cant test this version and report back)
> 
> Will see what we can accomplish in the lab!

systemd(-networkd) 241-1~bpo9+1 from stretch-backports seems to work
better.
The expiration is now present in the output from `ip -6 r` and the
route is discarded when the timer runs out:
```
2001:dead:5:1219::/64 dev ens33 proto ra metric 1024  expires 2591574sec pref 
medium
fe80::/64 dev ens33 proto kernel metric 256  pref medium
default via fe80::209:fff:fe09:5 dev ens33 proto ra metric 1024  expires 
1374sec mtu 1500 pref medium
```

But both the new version of systemd-networkd and the default network
service "networking" (not sure of the official name is) will add more
then one default route if the router advertise this.
Is this a feature or a bug?

It is not possible to and another default route via `ip -6 route`:
```
# ip -6 route add default via default via fe80::dead:beef:dead:beef dev ens33
RTNETLINK answers: File exists
```

Still curious, is systemd-networkd in stretch-backports considered stable?

--
jocar


signature.asc
Description: Message signed with OpenPGP

Bug#924929: unblock: mmdebstrap/0.4.1-2

[Johannes 'josch' Schauer]

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

Please unblock package mmdebstrap

The mmdebstrap autopkgtest caused problems on Debian CI. See #924854.

Attached there is a minimal patch that just marks the autopkgtest as flaky.

unblock mmdebstrap/0.4.1-1
diff -Nru mmdebstrap-0.4.1/debian/changelog mmdebstrap-0.4.1/debian/changelog
--- mmdebstrap-0.4.1/debian/changelog   2019-03-01 14:53:42.0 +0100
+++ mmdebstrap-0.4.1/debian/changelog   2019-03-18 14:46:01.0 +0100
@@ -1,3 +1,9 @@
+mmdebstrap (0.4.1-2) unstable; urgency=medium
+
+  * Mark autopkgtest as flaky (closes: #924854)
+
+ -- Johannes 'josch' Schauer   Mon, 18 Mar 2019 14:46:01 
+0100
+
 mmdebstrap (0.4.1-1) unstable; urgency=medium
 
   * new upstream release
diff -Nru mmdebstrap-0.4.1/debian/tests/control 
mmdebstrap-0.4.1/debian/tests/control
--- mmdebstrap-0.4.1/debian/tests/control   2019-02-24 00:48:41.0 
+0100
+++ mmdebstrap-0.4.1/debian/tests/control   2019-03-18 14:45:02.0 
+0100
@@ -1,3 +1,3 @@
 Tests: testsuite
 Depends: mmdebstrap, arch-test, fakechroot, fakeroot, mount, uidmap, proot, 
qemu-user, qemu-user-static, binfmt-support, dpkg-dev, grep-dctrl, curl, 
python3, sudo, debootstrap
-Restrictions: needs-root, allow-stderr
+Restrictions: needs-root, allow-stderr, flaky

Bug#799325: weston: won't start despite having an active logind session

[Paul Menzel]

Control: found -1 5.0.0
Control: forwarded -1 https://gitlab.freedesktop.org/wayland/weston/issues/204


Dear Hector, dear Ben,


On 06/02/16 13:30, Hector Oron wrote:

> On Thu, Sep 17, 2015 at 02:42:59PM -0700, Ben Longbons wrote:
> 
>> $ weston-launch
>> weston-launch: Permission denied. You should either:
>>  - enable systemd session support for weston-launch.
>>  - or add yourself to the 'weston-launch' group.
> 
> Thanks for the report, I have been testing with 1.11.0 version and
> the issue is gone on my system. Could you please re-test and update
> the bug report?

As the bug report title talks about Weston and not `weston-launch`,
I am following up, saying that `weston --modules systemd-notify.so`
does not work on a current Debian Sid/unstable system run from a
tty.

[10:24:41.689] fatal: drm backend should be run using weston-launch binary, 
or your system should provide the logind D-Bus API.
[10:24:41.689] fatal: failed to create compositor backend

It looks like `libdbus-1-dev` [1] is missing as a build dependency,
so that support for systemd-login is *not* detected.

After installing the development package, the configure output
contains the line below.

systemd-login support   yes

Can you please check the package build logs?

Building with `CFLAGS=-O0 -g` I then verified, that
`launcher_logind_iface` is a member of the the array `ifaces`.


Kind regards,

Paul


[1]: 
https://salsa.debian.org/xorg-team/wayland/weston/blob/debian-unstable/debian/control
[2]: https://packages.debian.org/search?keywords=libdbus-1-dev



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#878843: util-linux: fsck on btrfs /home hangs, stalling boot

[Thierry fa...@linux.ibm.com]

On Wed, 18 Oct 2017 08:42:32 -0400 Phil Susi  wrote:
> On 10/18/2017 3:54 AM, Bernhard Schmidt wrote:
> > Accessing /home leads to a blocked process. The reason is that (for
> > numerous years, due to reasons I don't remember) I had
> > x-systemd.automount in my fstab for /home
> 
> That makes sense.  Now I wonder why is fsck trying to open /home?  You
> run it on the block device; it should not know or care that the
> filesystem is normally mounted in /home.
> 
> 
Hello,
As this bug has not been updated for more than a year do we expect any
update or do we consider it is irrelevant ?
Thanks for your update