Bug#961485: r-cran-sp: autopkgtest regression

[Graham Inggs]

Source: r-cran-sp
Version: 1:1.4-2-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 1:1.4-2-1, r-cran-sp has been failing its own
autopkgtests [1].  This now prevents the migration of r-base.
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/r/r-cran-sp/unstable/amd64/


autopkgtest [09:03:38]: test run-unit-test: [---
Test base passed
--- fail1.Rout.save_ 2020-05-24 09:03:40.508583188 +
+++ fail1.Rout_ 2020-05-24 09:03:40.512583197 +
@@ -208,10 +208,8 @@
 Error in CRS("+proj=latlon +ellps=WGS84") :
   northings must follow eastings: +proj=latlon +ellps=WGS84
 > try(CRS("+proj=lonlat +ellps=WGS84"))
-CRS arguments: +proj=longlat +ellps=WGS84 +no_defs
-Warning messages:
-1: In CRS("+proj=lonlat +ellps=WGS84") :
+CRS arguments: +proj=longlat +ellps=WGS84
+Warning message:
+In CRS("+proj=lonlat +ellps=WGS84") :
   'lonlat' changed to 'longlat': +proj=longlat +ellps=WGS84
-2: In showSRID(uprojargs, format = "PROJ", multiline = "NO") :
-  Discarded datum Unknown based on WGS84 ellipsoid in CRS definition
 >
autopkgtest [09:03:40]: test run-unit-test: ---]
autopkgtest [09:03:40]: test run-unit-test:  - - - - - - - - - -
results - - - - - - - - - -
run-unit-testFAIL non-zero exit status 1

Bug#961486: perl6-zef FTBFS: Failed to create directory '/sbuild-nonexistent/.raku/precomp'

[Adrian Bunk]

Source: perl6-zef
Version: 0.8.4-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=perl6-zef=all=0.8.4-1=1590249709=0

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
prove6 -l
===SORRY!=== Error while compiling /usr/bin/prove6
Failed to create directory '/sbuild-nonexistent/.raku/precomp' with mode 
'0o777': Failed to mkdir: Permission denied
at /usr/bin/prove6:3
Actually thrown at:
  in any statement_control at /usr/lib/perl6/lib/Perl6/Grammar.moarvm line 1

make[1]: *** [debian/rules:13: override_dh_auto_test] Error 1

Bug#961488: libsqlite3-0_3.32.0-1_amd64.deb trying to overwrite /usr/share/doc/libsqlite3-0/changelog.gz

[Arnaldo Pirrone]

Package: libsqlite3-0
Version: 3.31.1-5
Severity: grave

Hi,
This package is trying to overwrite /usr/share/doc/libsqlite3-0/changelog.gz.
It cannot be installed at the current time.



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

Kernel: Linux 5.6.14-xanmod1 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsqlite3-0 depends on:
ii  libc6  2.30-8

libsqlite3-0 recommends no packages.

libsqlite3-0 suggests no packages.

-- no debconf information

Bug#961489: debci: The sqlite db is exposed by default when data/ is served via http

[Sebastien Delafond]

Source: debci
Version: 2.12.2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

When using sqlite storage, the debci.sqlite3 file is exposed in
https:///data, just by virtue of the this file being stored by
default in data/. Since it can contain private tokens (even though
they're hashed), this requires adding an extra nginx/apache rule to
prevent serving this file.

I am not sure about the proper resolution for this: should it simply be
documented? Should the DB file live elsewhere by default?

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/36 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#960503: xfonts-terminus: 50-enable-terminus.conf missing, fonts are not enabled

[Emanuele Rocca]

Hi Anton,

On 13/05 03:16, Anton Zinoviev wrote:
> On Wed, May 13, 2020 at 01:16:32PM +0200, Jochen Sprickerhof wrote:
> > Severity: grave
> > Justification: renders package unusable
> 
> Well, the package is not unusable.  It is usable by all X programs which 
> do not rely on fontconfig.

It might still be usable, but the upgrade does break things for people
who only have xfonts-terminus installed.

> On the other hand, programs which rely on fontconfig should probably use 
> the fonts in fonts-terminus-otb instead of the fonts in this package.  
> Practically, this means that most users should install 
> fonts-terminus-otb instead xfonts-terminus.

I think this should be explicitly communicated to users via NEWS.Debian.

Bug#961490: fwupd: version in stable too old, no updates possible

[Steffen Schreiber]

Package: fwupd
Version: 1.2.5-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The version 1.2.5 of fwupd currently in Debian stable is useless and not able
to perform any firmware updates.
Whem trying to update via command line:

> fwupdmgr refresh && fwupdmgr get-updates

I get the following output:

 Metadaten werden abgerufen https://cdn.fwupd.org/downloads/firmware.xml.gz
 Herunterladen …  [***]
 Signatur wird abgerufen https://cdn.fwupd.org/downloads/firmware.xml.gz.asc

 Not compatible with org.freedesktop.fwupd version 1.2.5, requires >= 1.2.7

The "refresh" part still works, but the new firmware info requires a newer
version of fwupd than available in stable, so the "get-update" part fails.

I'm not sure how to best handle this situation. It's very unfortunate that
fwupd obviously breaks compatibility with older clients here...
Maybe a new version in backports would be possible?

Regards,
Steffen



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

Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libarchive13   3.3.3-4+deb10u1
ii  libc6  2.28-10
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.2.5-2
ii  libgcab-1.0-0  1.2-3~deb10u1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgnutls303.6.7-4+deb10u3
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6
ii  libgudev-1.0-0 232-2
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-25
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.27.2-3
ii  libxmlb1   0.1.6-2
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt   0.7-2
ii  fwupd-amd64-signed [fwupd-signed]  1.2.5+2
ii  python33.7.3-1
ii  tpm2-abrmd 2.1.0-1
ii  tpm2-tools 3.1.3-2

fwupd suggests no packages.

-- no debconf information

Bug#961205: winetricks: cannot isntall font the download of PowerPointViwer.exe hans with server down

[Thierry Vilmart]

OK we can use the old url that still works.


I would recommend to install the official microsoft Powerpoint viewer
using wine.
And then winetricks would find it in the installed wine folder.

Maybe winetricks will need changes.

https://www.microsoft.com/en-us/download/details.aspx?id=56523

Why is it not possible?

For licensing it is better not to ship the exe as part of the debian
package.

Regards
Thierry



lör 2020-05-23 klockan 15:18 +0200 skrev Bernhard Übelacker:
> Dear Maintainer,
> if a targetted fix for buster would be desired, following
> upstream commits seem to be the last changes to the
> download URL in question.
>   https://github.com/Winetricks/winetricks/commit/ac51cdb pptfonts:
> use a helper function
>   https://github.com/Winetricks/winetricks/commit/76f5fdf calibri,
> cambria, candara, consolas, constantia, corbel, meiryo: update URL
> 
> Upstream issue:
>   https://github.com/Winetricks/winetricks/issues/1540
> 
> The version 0.0+20200412-1 in unstable seems to be affected too.
> 
> Kind regards,
> Bernhard

Bug#961419: [R-pkg-team] Bug#961419: r-cran-sjlabelled: autopkgtest failure

[Graham Inggs]

Control: affects -1 + src:r-cran-ggeffects
Control: affects -1 + src:r-cran-sjmisc
Control: affects -1 + src:r-cran-sjplot

I think this is also the cause of the autopkgtest failures in
r-cran-ggeffects [1], r-cran-sjmisc [2] and r-cran-sjplot [3].

[1] https://ci.debian.net/packages/r/r-cran-ggeffects/unstable/amd64/
[2] https://ci.debian.net/packages/r/r-cran-sjmisc/unstable/amd64/
[3] https://ci.debian.net/packages/r/r-cran-sjplot/unstable/amd64/

Bug#961491: CVE-2020-10936: Security flaws in setuid wrappers

[Stefan Hornburg (Racke)]

package: sympa
severity: critical
tags: upstream security patch

Security advisory: https://sympa-community.github.io/security/2020-002.html

Excerpt:

--snip--
A vulnerability has been discovered in Sympa web interface by which attacker 
can execute arbitrary code with root
privileges.

Sympa uses two sorts of setuid wrappers:

FastCGI wrappers
newaliases wrapper

The FastCGI wrappers (wwsympa-wrapper.fcgi and sympa_soap_server-wrapper.fcgi) 
were used to make the web interface
running under privileges of a dedicated user.

The newaliases wrapper (sympa_newaliases-wrapper) allows Sympa to update the 
alias database with root privileges.

Since these setuid wrappers did not clear environment variables, if environment 
variables like PERL5LIB were injected,
forged code might be loaded and executed under privileges of setuid-ed users.
--snap--

Affects all versions of Sympa. Patch is attached.

The following change should also be considered to switch off installation as 
setuid, which is not needed in most cases:
https://github.com/sympa-community/sympa/pull/944/commits/bc9579c7abddc77c92ad51897bd16aba12383d5f

See also 
https://github.com/sympa-community/sympa/issues/943#issuecomment-633278517 
which claims that the patch
is incomplete.

CVE is not yet published.

Regards
Racke

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.
commit 3f8449c647e5ab32cf6f8837cb600c1756b6189c
Author: IKEDA Soji 
Date:   Fri Mar 27 21:28:18 2020 +0900

Sympa SA 2020-002 (candidate): Setuid wrappers should clear environment variables to avoid exploits.

diff --git a/src/cgi/sympa_soap_server-wrapper.fcgi.c b/src/cgi/sympa_soap_server-wrapper.fcgi.c
index f4c6a66..435d40c 100644
--- a/src/cgi/sympa_soap_server-wrapper.fcgi.c
+++ b/src/cgi/sympa_soap_server-wrapper.fcgi.c
@@ -6,6 +6,9 @@
   Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
   2006, 2007, 2008, 2009, 2010, 2011 Comite Reseau des Universites
   Copyright (c) 2011, 2012, 2013, 2014, 2015, 2016, 2017 GIP RENATER
+  Copyright 2020 The Sympa Community. See the AUTHORS.md
+  file at the top-level directory of this distribution and at
+  .
  
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -24,8 +27,10 @@
 #include 
 
 int main(int argn, char **argv, char **envp) {
+char *myenvp[] = { "IFS= \t\n", "PATH=/bin:/usr/bin", NULL };
+
 setreuid(geteuid(),geteuid());
 setregid(getegid(),getegid());
 argv[0] = SYMPASOAP;
-return execve(SYMPASOAP,argv,envp);
+return execve(SYMPASOAP, argv, myenvp);
 }
diff --git a/src/cgi/wwsympa-wrapper.fcgi.c b/src/cgi/wwsympa-wrapper.fcgi.c
index c66c7f8..34198ec 100644
--- a/src/cgi/wwsympa-wrapper.fcgi.c
+++ b/src/cgi/wwsympa-wrapper.fcgi.c
@@ -6,6 +6,9 @@
   Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
   2006, 2007, 2008, 2009, 2010, 2011 Comite Reseau des Universites
   Copyright (c) 2011, 2012, 2013, 2014, 2015, 2016, 2017 GIP RENATER
+  Copyright 2020 The Sympa Community. See the AUTHORS.md
+  file at the top-level directory of this distribution and at
+  .
  
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -24,8 +27,10 @@
 #include 
 
 int main(int argn, char **argv, char **envp) {
+char *myenvp[] = { "IFS= \t\n", "PATH=/bin:/usr/bin", NULL };
+
 setreuid(geteuid(),geteuid()); // Added to fix the segfault
 setregid(getegid(),getegid()); // Added to fix the segfault
 argv[0] = WWSYMPA;
-return execve(WWSYMPA,argv,envp);
+return execve(WWSYMPA, argv, myenvp);
 }
diff --git a/src/libexec/sympa_newaliases-wrapper.c b/src/libexec/sympa_newaliases-wrapper.c
index a399218..a1e5935 100644
--- a/src/libexec/sympa_newaliases-wrapper.c
+++ b/src/libexec/sympa_newaliases-wrapper.c
@@ -6,6 +6,9 @@
   Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
   2006, 2007, 2008, 2009, 2010, 2011 Comite Reseau des Universites
   Copyright (c) 2011, 2012, 2013, 2014, 2015, 2016, 2017 GIP RENATER
+  Copyright 2020 The Sympa Community. See the AUTHORS.md
+  file at the top-level directory of this distribution and at
+  .
 
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -24,8 +27,10 @@
 #include 
 
 int main(int argn, char **argv, char **envp) {
+char *myenvp[] = { "IFS= \t\n", "PATH=/bin:/usr/bin", NULL };
+
 setreuid(geteuid(),geteuid());
 setregid(getegid(),getegid());
 argv[0] = SYMPA_NEWALIASES;
-return execve(SYMPA_NEWALIASES, argv, envp);
+return execve(SYMPA_NEWALIASES, argv, myenvp);
 }

Bug#955211: release.debian.org: Transition r-base for 4.0.0

[Graham Inggs]

Hi All

Thanks everyone for doing all the hundreds of uploads that were needed
for this combined transition.
All rebuilds for r-api-bioc3.11 are done [1] and there's one
outstanding FTBFS on a release architecture for r-api-4.0 [2].

Now there are a handful of autopkgtest regressions [3] that need to be
resolved before migration can happen.

As usual, please avoid uploads unrelated to this transition, they
would likely delay it and require supplementary work from the release
managers.

Regards
Graham


[1] https://release.debian.org/transitions/html/r-api-bioc-3.11.html
[2] https://release.debian.org/transitions/html/r-api-4.0.html
[3] https://qa.debian.org/excuses.php?package=r-base

Bug#961483: vlc-plugin-bittorrent: vlc crashes (SIGSEGV) on quit via Ctrl+q or Quit menu item

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/johang/vlc-bittorrent/issues/38
Control: tags -1 upstream

Thank you for letting us know.  I passed it on to upstream.

-- 
Happy hacking
Petter Reinholdtsen

Bug#961487: node-code: Remove this package and replace it by node-hapi-code

[Xavier Guimard]

Package: node-code
Version: 6.0.0-3
Severity: important

Hi,

node-code is useless and has a name that could be ambiguous. Upstream
name is now @hapi/code.

I think we should remove this package. If a package needs @hapi/code,
we could package it later.

Bug#961459: linux-signed-arm64: option that might support raspberry pi 4 usb

[Bjørn Mork]

Rob Browning  writes:

> If I get a chance and figure out how, I can try to build a local kernel
> with that option and test it, or I could fairly quickly test any version
> uploaded somewhere like experimental.

I have done this, and verified that the USB ports work if
CONFIG_PCIE_BRCMSTB is enabled.  See

https://bugs.debian.org/960129



Bjørn

Bug#958917: openmw: random crashes

[Adrian Bunk]

On Wed, May 06, 2020 at 07:03:16AM -0500, bret curtis wrote:
> Hello,
> 
> yes this is a known issue and someone needs to trigger a rebuild once OSG
> 3.6.5 gets out of experimental.
> 
> This is related to bug #945875
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945875
> 
> Again, this is pretty urgent because it also effect Ubuntu 20.04, a LTS
> where they are shipping a busted OSG 3.6.4
> 
> Does anyone with contacts with Ubuntu known of a way to get a package (OSG)
> backported into a LTS release?

Unfortunately a package update that requires a library transition due to 
a changed soname is pretty impossible in any stable release of a distribution.

> Cheers,
> Bret

cu
Adrian

Bug#929825: Tuxpaint

[Jonathan Carter]

This would also fix #942889 - since the latest Tuxpaint now relies on
imagemagick 7.

Bug#961494: bowtie2: please make the build reproducible

[Chris Lamb]

Source: bowtie2
Version: 2.4.1-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
bowtie2 could not be built reproducibly.

Whilst you do patch out -fdebug-prefix-map in debian/patches/reproducible.patch,
you al

Patch attached.

  [0] https://reproducible-builds.org/


Regards,

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

Bug#959577: uwsgi-plugin-php: FTBFS: make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1

[Alexandre Rossi]

tag 959577 patch
thanks

Hi,

> Relevant part (hopefully):
> >  debian/rules build
> > dh build --with uwsgi
> > dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
> >dh_update_autotools_config
> >debian/rules override_dh_auto_build
> > make[1]: Entering directory '/<>'
> > uwsgi --build-plugin /usr/src/uwsgi/plugins/php
> > make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1

The following patch fixes the problem.

Thanks,

Alex


commit f3fc84b5e9c73d3cda24306df62cb334cb5d33f7 (HEAD -> master)
Author: Alexandre Rossi 
Date:   Mon May 25 12:27:32 2020 +0200

enable build with python3 (Closes: #959577)

diff --git a/debian/control b/debian/control
index 5e6a58a..22d9309 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  libphp-embed | libphp5-embed,
  uwsgi-dev,
  uwsgi-src,
+ python3-distutils,
 Standards-Version: 4.4.0
 Homepage: https://uwsgi-docs.readthedocs.io/en/latest/
 Vcs-Git: https://salsa.debian.org/uwsgi-team/uwsgi-plugin-php.git
diff --git a/debian/rules b/debian/rules
index a426234..885381e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,7 +26,7 @@ OUR_BINARY_VERSION = $(subst 
-,+,$(UWSGI_VERSION))+$(DEB_VERSION)
dh $@ --with uwsgi

 override_dh_auto_build:
-   uwsgi --build-plugin /usr/src/uwsgi/plugins/php
+   PYTHON=python3 uwsgi --build-plugin /usr/src/uwsgi/plugins/php
help2man \
--name 'fast (pure C), self-healing, developer-friendly WSGI 
server' \
--section 1 \

Bug#961503: qtqr: When you try to read the QR Code while using the camera, it crashes.

[KenichiroMATOHARA]

Package: qtqr
Version: 2.0~bzr33-2
Severity: normal

Dear Maintainer,

When I try to read the QR code with the 'Decode from Webcam' button on Qtqr
while using the webcam for video meetings, etc., it crashes.

It would be nice if it would display an error and not crash.

```
$ qtqr
QPixmap::scaled: Pixmap is a null pixmap
libv4l2: error setting pixformat: Device or resource busy
libv4l2: error setting pixformat: Device or resource busy
libv4l2: error setting pixformat: Device or resource busy
libv4l2: error setting pixformat: Device or resource busy
WARNING: no compatible input to output format
...trying again with output disabled
libv4l2: error setting pixformat: Device or resource busy
libv4l2: error setting pixformat: Device or resource busy
Traceback (most recent call last):
  File "/usr/bin/qtqr", line 834, in decodeWebcam
qr.decode_webcam(device=device)
  File "/usr/lib/python3/dist-packages/qrtools.py", line 240, in decode_webcam
proc.init(device)
zbar.UnsupportedError: 
Aborted
```



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

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

Versions of packages qtqr depends on:
ii  python3  3.8.2-3
ii  python3-pyqt55.14.2+dfsg-1+b1
ii  python3-qrtools  2.0~bzr33-2

qtqr recommends no packages.

qtqr suggests no packages.

-- no debconf information

Bug#961504: python3-flake8: missing flake8 executable

[Daniel Gomez]

Package: python3-flake8
Version: 3.7.9-2
Severity: normal

Dear Maintainer,

After installing python3-flake8 package:
apt-get install python3-flake8

/usr/bin/flake8 executable is missing. Therefore, user cannot execute flake8
command as it is done in python3-autopep8 where the /usr/bin/autopep8 is
available.

Here the flake8 installed files:
dpkg -L python3-flake8

```
/.
/usr
/usr/lib
/usr/lib/python3
/usr/lib/python3/dist-packages
/usr/lib/python3/dist-packages/flake8
/usr/lib/python3/dist-packages/flake8/__init__.py
/usr/lib/python3/dist-packages/flake8/__main__.py
/usr/lib/python3/dist-packages/flake8/api
/usr/lib/python3/dist-packages/flake8/api/__init__.py
/usr/lib/python3/dist-packages/flake8/api/legacy.py
/usr/lib/python3/dist-packages/flake8/checker.py
/usr/lib/python3/dist-packages/flake8/defaults.py
/usr/lib/python3/dist-packages/flake8/exceptions.py
/usr/lib/python3/dist-packages/flake8/formatting
/usr/lib/python3/dist-packages/flake8/formatting/__init__.py
/usr/lib/python3/dist-packages/flake8/formatting/base.py
/usr/lib/python3/dist-packages/flake8/formatting/default.py
/usr/lib/python3/dist-packages/flake8/main
/usr/lib/python3/dist-packages/flake8/main/__init__.py
/usr/lib/python3/dist-packages/flake8/main/application.py
/usr/lib/python3/dist-packages/flake8/main/cli.py
/usr/lib/python3/dist-packages/flake8/main/debug.py
/usr/lib/python3/dist-packages/flake8/main/git.py
/usr/lib/python3/dist-packages/flake8/main/mercurial.py
/usr/lib/python3/dist-packages/flake8/main/options.py
/usr/lib/python3/dist-packages/flake8/main/setuptools_command.py
/usr/lib/python3/dist-packages/flake8/main/vcs.py
/usr/lib/python3/dist-packages/flake8/options
/usr/lib/python3/dist-packages/flake8/options/__init__.py
/usr/lib/python3/dist-packages/flake8/options/aggregator.py
/usr/lib/python3/dist-packages/flake8/options/config.py
/usr/lib/python3/dist-packages/flake8/options/manager.py
/usr/lib/python3/dist-packages/flake8/plugins
/usr/lib/python3/dist-packages/flake8/plugins/__init__.py
/usr/lib/python3/dist-packages/flake8/plugins/manager.py
/usr/lib/python3/dist-packages/flake8/plugins/pyflakes.py
/usr/lib/python3/dist-packages/flake8/processor.py
/usr/lib/python3/dist-packages/flake8/statistics.py
/usr/lib/python3/dist-packages/flake8/style_guide.py
/usr/lib/python3/dist-packages/flake8/utils.py
/usr/lib/python3/dist-packages/flake8-3.7.9.egg-info
/usr/lib/python3/dist-packages/flake8-3.7.9.egg-info/PKG-INFO
/usr/lib/python3/dist-packages/flake8-3.7.9.egg-info/dependency_links.txt
/usr/lib/python3/dist-packages/flake8-3.7.9.egg-info/entry_points.txt
/usr/lib/python3/dist-packages/flake8-3.7.9.egg-info/requires.txt
/usr/lib/python3/dist-packages/flake8-3.7.9.egg-info/top_level.txt
/usr/share
/usr/share/doc
/usr/share/doc/python3-flake8
/usr/share/doc/python3-flake8/changelog.Debian.gz
/usr/share/doc/python3-flake8/changelog.gz
/usr/share/doc/python3-flake8/copyright
```

I would expect the python3-flake8 package contains this file: /usr/bin/flake8,
with this content:

```
#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT: 'flake8==3.8.2','console_scripts','flake8'
__requires__ = 'flake8==3.8.2'
import re
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(
load_entry_point('flake8==3.8.2', 'console_scripts', 'flake8')()
)
```

Could it be possible to add the executable /usr/bin/flake8 to the
python3-flake8 package as it is done in the python3-autopep8?

Thanks!





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

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

Versions of packages python3-flake8 depends on:
ii  python3  3.8.2-3
ii  python3-entrypoints  0.3-3
ii  python3-mccabe   0.6.1-3
ii  python3-pycodestyle  2.5.0-3
ii  python3-pyflakes 2.1.1-2
ii  python3-setuptools   44.0.0-1

python3-flake8 recommends no packages.

python3-flake8 suggests no packages.

-- no debconf information

Bug#961492: routine-update removes required dependencies

[Adrian Bunk]

Package: routine-update
Version: 0.0.2
Severity: grave

https://salsa.debian.org/r-pkg-team/r-cran-nozzle.r1/-/commit/7d7b872597ffa83f453db4d3b43c0e66d49bd479
https://salsa.debian.org/r-pkg-team/r-cran-fontliberation/-/commit/952ff2238ad81e9da18899dcd871ecc5454dd0c8

These were causing RC bugs during the R transition,
I hope there are not more such breakages that were
not yet found.

Bug#961497: Please install registries.conf from samples directory

[Laurent Bigonville]

Package: buildah
Version: 1.11.6-1
Severity: important

Hi,

I think that the registries.conf file from the the samples directory
should be installed to /etc/containers/

Without that buildah is not working out of the box here

Kind regards,

Laurent Bigonville

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

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

Versions of packages buildah depends on:
ii  libc6   2.30-8
ii  libdevmapper1.02.1  2:1.02.167-1+b1
ii  libglib2.0-02.64.2-1
ii  libgpgme11  1.13.1-7+b1
ii  libostree-1-1   2020.3-1
ii  libseccomp2 2.4.3-1+b1
ii  libselinux1 3.1~rc1-1
ii  uidmap  1:4.8.1-1

Versions of packages buildah recommends:
ii  crun0.13+dfsg-1
ii  fuse-overlayfs  1.0.0-1
ii  runc1.0.0~rc10+dfsg2-1

Versions of packages buildah suggests:
pn  containers-storage  

-- no debconf information

Bug#961362: fonts-terminus-otb: In rxvt-unicode, M and m characters missing the left vertical stroke

[Anton Zinoviev]

On Sat, May 23, 2020 at 08:42:59AM -0700, Ian Zimmerman wrote:
> 
> The PCF format font (which I assume is generated from the same source) 
> has no such problem.

I suppose this is not a font problem but a problem of the rendering 
engine.  The rendering engine of the OTB fonts is more sofisticated than 
the rendering engine of the PCF fonts.  It can render the fonts in 
arbitrary font sizes (including non-integer sizes).

But as usually, with sofistication come problems, undebugged cases, etc.
 
> Specifically, I use the 12 size font.

How about 13 size?  Or maybe something like 12.1, 12.2, 12.3 or 12.4
(or 12,1, 12,2, 12,3 and 12,4 in locales with decimal comma)?

Anton Zinoviev

Bug#961498: r-cran-sjplot: missing test dependency on r-cran-haven

[Adrian Bunk]

Source: r-cran-sjplot
Version: 2.8.3-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-sjplot/5625656/log.gz

...
> library(testthat)
> library(sjPlot)
> 
> if (length(strsplit(packageDescription("sjPlot")$Version, "\\.")[[1]]) > 3) {
+   Sys.setenv("RunAllsjPlotTests" = "yes")
+ }
> 
> test_check("sjPlot")
── 1. Error: (unknown) (@test-plot_model_std.R#15)  
Package 'haven' required for this function. Please install it.
Backtrace:
 1. sjmisc::to_factor(efc, e42dep, c172code, c161sex)
 2. sjmisc:::to_fac_helper(.dat[[i]], add.non.labelled, ref.lvl)
 5. sjlabelled::set_labels(...)
 6. sjlabelled:::set_labels_helper(...)

══ testthat results  ═══
[ OK: 2 | SKIPPED: 0 | WARNINGS: 12 | FAILED: 1 ]
...


r-cran-sjlabelled no longer depends on r-cran-haven.

Bug#961499: r-cran-sjmisc: missing test dependency on r-cran-haven

[Adrian Bunk]

Source: r-cran-sjmisc
Version: 2.8.4-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-sjmisc/5633123/log.gz

...
── 1. Error: (unknown) (@test-frq_whitespace.R#10)  
Package 'haven' required for this function. Please install it.
Backtrace:
 1. sjmisc::rec(dat, y.char, suffix = "_r", as.num = TRUE, rec = "Category1 = 1 
[Label 1]; Category2 = 2 [Label 2]; Category3 = 3 [Label 3];")
 2. sjmisc:::rec.default(...)
 3. sjmisc:::rec_core_fun(...)
 4. sjmisc:::rec_helper(...)
 7. sjlabelled::set_labels(x = new_var, labels = val_lab)
 8. sjlabelled:::set_labels_helper(...)
...


r-cran-sjlabelled no longer depends on r-cran-haven.

Bug#961500: r-cran-ggeffects: missing test dependency on r-cran-haven

[Adrian Bunk]

Source: r-cran-ggeffects
Version: 0.14.3-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-ggeffects/5631066/log.gz

...
> test_check("ggeffects")
── 1. Error: ggpredict, contrasts-3 (@test-contrasts.R#31)  
Package 'haven' required for this function. Please install it.
Backtrace:
 1. ggeffects::ggpredict(m, c("c12hour", "c82cop1"))
 2. ggeffects:::ggpredict_helper(...)
 3. ggeffects:::.post_processing_predictions(...)
 4. ggeffects:::.add_labels_to_groupvariable(...)
 5. sjlabelled::set_labels(mydf$group, labels = grp.lbl)
 6. sjlabelled:::set_labels_helper(...)
...


r-cran-sjlabelled no longer depends on r-cran-haven.

Bug#961492: Any Perl programmer able to fix dh-update-R (Was: Bug#961492: routine-update removes required dependencies)

[Andreas Tille]

Hi,

On Mon, May 25, 2020 at 11:21:48AM +0200, Andreas Tille wrote:
> The issue is actually not causes by routine-update but rather
> by dh-update-R that regenerates all Depends automatically but
> does not respect non-R dependencies we injected for instance
> to provide JS files.

As a workaround I'm usially adding a comment

   # do not delete this

but that's for sure no acceptable solution.  Gordon (or somebody else)
do you have some spare cycles to make sure dh-update-R will rewrite only
the R Dependencies and leave other Depends we added manually alone?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#961495: properties-cpp: please make the build reproducible

[Chris Lamb]

Source: properties-cpp
Version: 0.0.2-3
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
properties-cpp could not be built reproducibly.

This was because doxygen was taking build-related log files (eg.
link.txt, GMock.cfg.txt) and then processing them like a manual page.
This was installed to /usr/share/man3 (hence the "minor" severity over
"wishlist") and this file varied on the absolute build path.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `- --- a/debian/patches/1002_reproducible-builds.patch 2020-05-25 
10:35:33.971753740 +0100
--- b/debian/patches/1002_reproducible-builds.patch 2020-05-25 
10:45:04.531334933 +0100
@@ -2,8 +2,8 @@
 Author: Chris Lamb 
 Last-Update: 2017-12-02
 
 properties-cpp-0.0.1~bzr17+repack1.orig/doc/Doxyfile.in
-+++ properties-cpp-0.0.1~bzr17+repack1/doc/Doxyfile.in
+--- properties-cpp-0.0.2.orig/doc/Doxyfile.in
 properties-cpp-0.0.2/doc/Doxyfile.in
 @@ -119,7 +119,7 @@ INLINE_INHERITED_MEMB  = NO
  # path before files name in the file list and in the header files. If set
  # to NO the shortest path that makes the file name unique will be used.
@@ -18,7 +18,7 @@
  # for example use the pattern */test/*
  
 -EXCLUDE_PATTERNS   =
-+EXCLUDE_PATTERNS   = */DartConfiguration.tcl
++EXCLUDE_PATTERNS   = */DartConfiguration.tcl */link.txt */GMock-cfgcmd.txt
  
  # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
  # (namespaces, classes, functions, etc.) that should be excluded from the
--- a/doc/Doxyfile.in   2020-05-25 10:35:33.971753740 +0100
--- b/doc/Doxyfile.in   2020-05-25 10:45:20.371533564 +0100
@@ -714,7 +714,7 @@
 # against the file with absolute path, so to exclude all test directories
 # for example use the pattern */test/*
 
-EXCLUDE_PATTERNS   = */DartConfiguration.tcl
+EXCLUDE_PATTERNS   = */DartConfiguration.tcl */link.txt */GMock-cfgcmd.txt
 
 # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
 # (namespaces, classes, functions, etc.) that should be excluded from the

Bug#961497: Please install registries.conf from samples directory

[Dmitry Smirnov]

On Monday, 25 May 2020 7:58:47 PM AEST Laurent Bigonville wrote:
> I think that the registries.conf file from the the samples directory
> should be installed to /etc/containers/
> 
> Without that buildah is not working out of the box here

I build my own containers and Buildah works perfectly without 
"registries.conf". Therefore my judgment on the matter is "wontfix".

Copying the provided file manually to "/etc/containers/" is easy and it 
encourages user to review "registries.conf" for explicitly allowed sources.

I do not wish to encourage people to blindly pull from "docker.io" by 
default.

-- 
All the best,
 Dmitry Smirnov.

---

For every problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken


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

Bug#916993: Bug#939721: ITP: intellij-community-idea -- Jars needed by kotlin built from intellij-community

[Andrej Shadura]

On Tue, 4 Feb 2020 10:17:23 +0100 Salvatore Bonaccorso
 wrote:
> On Sun, Sep 08, 2019 at 10:15:06AM +0400, Saif Abdul Cassim wrote:
> > Package: wnpp
> > Owner: Saif Abdul Cassim 
> > Severity: wishlist

> > IntelliJ IDEA Community Edition source code is available from
> > github.com/JetBrains/intellij-community by either cloning or downloading a
> > zip file (based on a branch) into . The default is the *master*
> > branch.

> > This package packages the jars that are needed from itnellij-community for
> > Kotlin 1.3.30 which I am working on.
> > 
> > I plan to maintain this package with the debian java maintainers team. This
> > package is needed for kotlin.

> There is as well the RFP bug as http://bugs.debian.org/747616, this is
> the same?

Thanks for the pointer. The source code is the same, but the packaging
effort is different. This ITP is focused on support libraries only, the
rest of IDEA still needs major work the other RFP is about.

-- 
Cheers,
  Andrej

Bug#868563: apparmor-profiles: Apparmor profiles for postfix programs have incorrect path

[intrigeri]

Control: tag -1 + fixed-upstream

intrigeri (2018-12-16):
> Julian Andres Klode:
>> It needs some more changes, I'll try to get them fixed up
>> this weekend, so I can roll out my server in enforced mode.
>
> Did your https://gitlab.com/apparmor/apparmor/merge_requests/284 fix
> all the incorrect paths this bug was about?
>
> (I'd like to update this bug's metadata accordingly :)

I'll optimistically assume this is indeed fixed in the upstream master
branch, and will be part of the AppArmor 3.0 release.

If that's incorrect, please let me know :)

Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package

[Jonas Smedegaard]

Quoting Lev Lamberov (2020-05-25 12:19:07)
> I've just got some news from Jan Wielemaker. The next stable release 
> of swi-prolog, branch 8.2, is almost ready. How are your experiments 
> with depending on swi-prolog virtual packages going? I would like to 
> package the current latest version and upload it into unstable for 
> testing it with more installations, just to make sure there are no 
> serious bugs and blockers for the release of 8.2 branch.

Sorry, I have not played with it at all, yet.

Hope to find/make time for it later today.  Will let you know when I do!


 - 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#934869: [pkg-apparmor] Bug#934869: /etc/apparmor.d/usr.sbin.dnsmasq: profile doesn’t allow dnsmasq-base DNSSEC files

[intrigeri]

Control: forwarded -1 https://gitlab.com/apparmor/apparmor/-/merge_requests/547

Hi,

James Rowe (2019-08-16):
>   If DNSSEC validation is enabled in the dnsmasq config file then the
> /usr/share/dnsmasq-base/trust-anchors.conf should be read by dnsmasq.
> However, the profile doesn’t allow access to it.
>
>   The following simple patch enables reading the DNS setup from
> dnsmasq-base:

Thank you.

I've forwarded this as a merge request upstream:
https://gitlab.com/apparmor/apparmor/-/merge_requests/547

I expect the fix will be part of the upstream 3.0 release.

Next time, please consider submitting your fixes directly there:
taking me off the critical path would surely speed up the process
considerably :)

Bug#959577: [pkg-uWSGI-devel] Bug#959577: uwsgi-plugin-php: FTBFS: make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1

[Jonas Smedegaard]

Quoting Alexandre Rossi (2020-05-25 12:40:44)
> The following patch fixes the problem.

> --- a/debian/control
> +++ b/debian/control
> @@ -10,6 +10,7 @@ Build-Depends:
>   libphp-embed | libphp5-embed,
>   uwsgi-dev,
>   uwsgi-src,
> + python3-distutils,


> --- a/debian/rules
> +++ b/debian/rules
> @@ -26,7 +26,7 @@ OUR_BINARY_VERSION = $(subst 
> -,+,$(UWSGI_VERSION))+$(DEB_VERSION)
> dh $@ --with uwsgi
> 
>  override_dh_auto_build:
> -   uwsgi --build-plugin /usr/src/uwsgi/plugins/php
> +   PYTHON=python3 uwsgi --build-plugin /usr/src/uwsgi/plugins/php


Thanks, Alex!

Better to fix this centrally in uwsgi, however, so I will do that. Quite 
helpful to be clued in on the cause of the problem.  Thanks again!


 - 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#961505: failed mips64el build of flint 2.5.2-22

[Thibaut Paumard]

Package: src:flint
Version: 2.5.2-22
Severity: serious
Tags: ftbfs
Thanks

Hi,

I wanted to check whether the recent upload actually fixed
953437: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953437

I realized that it failed to build.

Regards, Thibaut.


 Message transféré 
Sujet : failed mips64el build of flint 2.5.2-22
Date : Tue, 19 May 2020 20:45:33 -
De : Debian buildds 
Pour : dispa...@tracker.debian.org

 * Source package: flint
 * Version: 2.5.2-22
 * Architecture: mips64el
 * State: failed
 * Suite: sid
 * Builder: mipsel-aql-02.debian.org
 * Build log:
https://buildd.debian.org/status/fetch.php?pkg=flint=mips64el=2.5.2-22=1589921133=log

Please note that these notifications do not necessarily mean bug reports
in your package but could also be caused by other packages, temporary
uninstallabilities and arch-specific breakages.  A look at the build log
despite this disclaimer would be appreciated however.





signature.asc
Description: OpenPGP digital signature

Bug#926896: sysvinit-utils: pidof is unreliable

[Thorsten Glaser]

On Mon, 25 May 2020, Костик Покотиленко wrote:

> Should the fix be expected for Buster?

Definitely not.

If there is a fix, then you can hope for bullseye.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#955865: lxsession: unnecessarily Build-Depends on deprecated dbus-glib

[Kentaro Hayashi]

FYI:

It seems that this bug is already fixed in upstream
https://git.lxde.org/gitweb/?p=debian/lxsession.git;a=commit;h=612ac4cd55214a280638f1bf062e40e2d6f1ff7a

Bug#961020: Updated debdiff for libexif/0.6.21-2+deb9u2

[Hugh McMaster]

I've updated the debdiff for this release to include the changelog
entries for the sponsored upload.


libexif_0.6.21-2+deb9u3.debdiff
Description: Binary data

Bug#961020: Updated debdiff for libexif/0.6.21-2+deb9u2

[Hugh McMaster]

On Mon, 25 May 2020 at 22:18, Hugh McMaster wrote:
>
> I've updated the debdiff for this release to include the changelog
> entries for the sponsored upload.

Apologies. This is the correct debdiff.


libexif_0.6.21-2+deb9u2.debdiff
Description: Binary data

Bug#961494: bowtie2: please make the build reproducible

[Chris Lamb]

Hi,

> […]

This should have read:

  Whilst you do patch out -fdebug-prefix-map in
  debian/patches/reproducible.patch, you also need to filter
  -ffile-prefix-map.


Regards,

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

Bug#961141: antimony: error while loading shared libraries: libboost_python36.so.1.67.0

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information and found that
version 0.9.3-1+b1 got built against
libboost-python1.67.0 in version 1.67.0-10.

Up to 1.67.0-11 this package provided both, a lib *python36* and *python37*.
Since 1.67.0-12 it looks like there is just a *python37* lib.

A local rebuild got linked to *python37*, therefore
a binNMU might be enough for buster?


Other packages, depending on libboost-python1.67.0,
might be affected too.

Kind regards,
Bernhard

# Buster/stable amd64 qemu VM 2020-05-25

apt update
apt dist-upgrade


apt install systemd-coredump antimony fakeroot



root@debian:~# dpkg -l | grep libboost
ii  libboost-python1.67.0 1.67.0-13+deb10u1amd64
Boost.Python Library


root@debian:~# ldd /usr/bin/antimony
...
libboost_python36.so.1.67.0 => not found
...



https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914513




https://buildd.debian.org/status/logs.php?pkg=boost1.67=amd64

https://buildd.debian.org/status/fetch.php?pkg=boost1.67=amd64=1.67.0-11=1543612644=0
-rw-r--r-- root/root288264 2018-11-30 17:12 
./usr/lib/x86_64-linux-gnu/libboost_python27.so.1.67.0
-rw-r--r-- root/root280072 2018-11-30 17:12 
./usr/lib/x86_64-linux-gnu/libboost_python36.so.1.67.0
-rw-r--r-- root/root280072 2018-11-30 17:12 
./usr/lib/x86_64-linux-gnu/libboost_python37.so.1.67.0

https://buildd.debian.org/status/fetch.php?pkg=boost1.67=amd64=1.67.0-12=1548248464=0
-rw-r--r-- root/root288264 2019-01-23 11:14 
./usr/lib/x86_64-linux-gnu/libboost_python27.so.1.67.0
-rw-r--r-- root/root280072 2019-01-23 11:14 
./usr/lib/x86_64-linux-gnu/libboost_python37.so.1.67.0





https://buildd.debian.org/status/fetch.php?pkg=antimony=amd64=0.9.3-1%2Bb1=1542484831=0
Setting up libboost-python1.67.0 (1.67.0-10) ...




apt build-dep antimony

mkdir /home/benutzer/source/antimony/orig -p
cd/home/benutzer/source/antimony/orig
apt source antimony
cd

cd /home/benutzer/source/antimony
cp -a orig try1
cd try1/antimony-0.9.3
dpkg-buildpackage

dpkg -i /home/benutzer/source/antimony/try1/antimony_0.9.3-1_amd64.deb

Bug#959762: UDD/dmd: fails to load when debci data is missing

[Jonas Smedegaard]

Quoting Rebecca N. Palmer (2020-05-25 10:57:02)
> Control: retitle -1 UDD/dmd: fails to load when debci data is missing
> 
> The problem isn't the number of packages, but some specific packages 
> that can't be displayed even when they are the only package requested:
> https://udd.debian.org/dmd/?email1node-file-entry-cache==html#todo
> 
> These packages appear to be the ones that have a debci result (any 
> result) in testing but no debci data in unstable:
> https://ci.debian.net/packages/n/node-file-entry-cache/
> 
> Known examples:
> acpi-call node-housekeeping node-chainsaw node-file-entry-cache
> 
> As a workaround, you can exclude packages like this:
> 
> https://udd.debian.org/dmd/?email1=dr%40jones.dkeyes.js+node-eslint-plugin-node+node-eslint-plugin-requirejs++node-eslint-utils+node-esquery+node-ignore+node-leche+node-file-entry-cache+node-proxyquire+python-asynctest+pd-zexy+python-m2r+=html#todo
> 
> These packages can be identified from the CI column of DDPO, which does 
> work for such package sets:
> 
> https://qa.debian.org/developer.php?email=dr%40jones.dk

ThanksyouThankyouThankyou!

I hereby owe you a /virtual/real beverage of your choosing.


 - 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#709932: Upcoming changes to Lintian's exit status; new --fail-on option

[Felix Lechner]

Hi,

> [Lintian] Currently ... exits with "1" if policy violations ... are detected.

This behavior will soon be reversed. Lintian will exit with status 1
on program errors (thus enabling the use of 'die') and with status 2
on policy violations.

> It would be nice if lintian had an option to exit with a status != 0
> only if there are internal errors.

You will soon have some control via the upcoming '--fail-on'
command-line option. More information may be available here:

https://salsa.debian.org/lintian/lintian/-/merge_requests/311

Please also look out for a more widely disseminated announcement of
these changes, probably on debian-devel.

Kind regards
Felix Lechner

Bug#961128: apt-transport-https: https fails with segmentation fault

[Bernhard Übelacker]

Am 25.05.20 um 12:38 schrieb meht...@protonmail.com:
> While trying to get the core file I renamed "https" to "https.bin" and
> created a shell script "https" which had "ulimit -c unlimited; 
> /path/https.bin $@"
> or something like that..

Another way to receive core files might have been to install
a package providing the virtual package core-dump-handler
like systemd-coredump or corekeeper.

Kind regards,
Bernhard

Bug#959762: Loading big dashboard page

[Andrej Shadura]

On Mon, May 25, 2020 at 08:07:28AM +0200, Jonas Smedegaard wrote:
> For almost a month now, I have been unable to load my dashboard page 
> https://udd.debian.org/dmd/?d...@jones.dk - probably because I am involved 
> in too many packages (which makes it _more_ relevant to get an overview 
> like the dashboard page).
> 
> Do anyone know what else I can do besides reporting it (see 
> http://bugs.debian.org/959762)?

Interestingly, my dashboard doesn’t work either (I haven’t checked it for
a couple of weeks so I can’t tell when this started being so).

-- 
Cheers,
  Andrej

Bug#961432: RFP: picom -- lightweight compositor for X11

[Lev Lamberov]

Hi Nikos,

Вс 24 мая 2020 @ 19:24 Nikos Tsipinakis :

> My initial thought was that the compton maintainer should be the one to take
> this over, but it looks like[1] compton was orphaned as its maintainer moved 
> on
> to wayland.
>
> In which case, I'm interested in packaging this.

Looks like picom changed significantly after forking from compton, so
they even changed the name, in which case I believe that it should be a
separate package.

By the way, I can help with it to some extent, like sponsoring uploads.

Cheers!
Lev

Bug#932345: profile-sync-daemon: Debian specific error "I require modinfo but it's not installed"

[Shengjing Zhu]

Control: forward -1
https://github.com/graysky2/profile-sync-daemon/commit/25d6e40c8cb7d126e5cc4a05263133158156a2f7
Control: tags -1 + fixed-upstream

It has been fixed upstream.

-- 
Shengjing Zhu

Bug#961493: vim-scripts: please update bufexplorer 7.4.21.

[YABUKI Yukiharu]

Package: vim-scripts
Version: 20180807
Severity: wishlist

Dear Maintainer,

You may know new upstream release.

please update one. see:
https://www.vim.org/scripts/script.php?script_id=42


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

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

vim-scripts depends on no packages.

Versions of packages vim-scripts recommends:
ii  vim2:8.2.0716-3
ii  vim-addon-manager  0.5.10
ii  vim-gtk3 [vim] 2:8.2.0716-3
ii  vim-nox [vim]  2:8.2.0716-3

Versions of packages vim-scripts suggests:
pn  libtemplate-perl 
pn  perlsgml 
ii  universal-ctags [ctags]  0+git20191013-1

-- no debconf information

Bug#747616: RFP: intellij-idea -- An integrated development environment for Java and other Java VM languages

[Andrej Shadura]

Control: block -1 916993

This RFP is about packaging a full-blown IDE, but it builds from the
same source as the intellij-community-idea source package we’re about to
upload. However, the current packaging effort is only focused on
packaging the support libraries IDEA comes with, which are reverse
dependencies of other packages such as the Kotlin compiler. When the
Kotlin compiler itself and Gradle 5 are in Debian, this RFP can be
revisited and addressed properly.

This should *not* be closed when #916993/#939721 is done.

-- 
Cheers,
  Andrej

Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package

[Lev Lamberov]

Hi Jonas,

I've just got some news from Jan Wielemaker. The next stable release of
swi-prolog, branch 8.2, is almost ready. How are your experiments with
depending on swi-prolog virtual packages going? I would like to package
the current latest version and upload it into unstable for testing it
with more installations, just to make sure there are no serious bugs and
blockers for the release of 8.2 branch.

Cheers!
Lev

Bug#961128: apt-transport-https: https fails with segmentation fault

[mehturt]

‐‐‐ Original Message ‐‐‐
On Saturday, May 23, 2020 5:22 PM, Bernhard Übelacker  
wrote:

> Dear Maintainer, hello Mehturt,
> I guess the missing debug information is contained in libcurl3-dbg [1].
>
> I tried to find out to which line this address in Mehturt's backtrace
> points to and came to this location:
>
> (gdb) bt
> #0 0x777cd4d7 in Curl_close (data=0x5579f6c0) at url.c:399
> #1 0x874b in HttpsMethod::~HttpsMethod (this=0x7fffe470, 
> __in_chrg=) at ./methods/https.cc:538
> #2 main (argv=) at ./methods/https.cc:546
>
> https://sources.debian.org/src/curl/7.52.1-5+deb9u10/lib/url.c/#L399
> https://sources.debian.org/src/apt/1.4.10/methods/https.cc/#L538
>
> In my opinion the instruction "mov 0x60(%rbx),%rdi" is executed, for Mehturt,
> while $rbx contains no valid pointer.
>
> The crash did not show up in my test VM. Attached an example debug session
> to debug to this location.
>
> @Mehturt: maybe you can still install libcurl3-dbg and inspect the core again.
> (Maybe adding a "display/i $pc" and "print/x $rbx", before any "bt full")


Thank you Bernhard,
indeed after installing libcurl3-dbg the backtrace looks similar to yours.

(gdb) display/i $pc
1: x/i $pc
=> 0x7f0d6c04f4d7 :  mov0x60(%rbx),%rdi
(gdb) print/x $rbx
$1 = 0xaf7e8480
(gdb) bt full
#0  Curl_close (data=0xaf7e8480) at url.c:399
m = 
#1  0x5638ad9bf74b in HttpsMethod::~HttpsMethod (this=0x7ffe4abe9690, 
__in_chrg=) at ./methods/https.cc:538
No locals.
#2  main (argv=) at ./methods/https.cc:546
Binary = "https.bin+https"

m.

Bug#961419: Description file of r-cran-sjlabelled seems to specify wrong depencency from haven (Was: Bug#961498: r-cran-sjplot: missing test dependency on r-cran-haven)

[Andreas Tille]

Hi,

there is a series of build failures connected to missing r-cran-haven.
Formerly r-cran-sjlabelled dependend from r-cran-haven - and IMHO that
should remain that way:

r-cran-sjlabelled(master) $ grep haven R/* | grep -i required
R/as_label.R:stop("Package 'haven' required for this function. Please 
install it.")
R/get_na.R:stop("Package 'haven' required for this function. Please install 
it.")
R/read.R:stop("Package 'haven' required for this function. Please install 
it.")
R/read.R:stop("Package 'haven' required for this function. Please install 
it.")
R/read.R:stop("Package 'haven' required for this function. Please install 
it.")
R/remove_labels.R:  stop("Package 'haven' required for this function. 
Please install it.")
R/remove_labels.R:stop("Package 'haven' required for this function. Please 
install it.")
R/set_labels.R:  stop("Package 'haven' required for this function. 
Please install it.")
R/set_na.R:stop("Package 'haven' required for this function. Please install 
it.")
R/write.R:stop("Package 'haven' required for this function. Please install 
it.")
R/zap_labels.R:stop("Package 'haven' required for this function. Please 
install it.")


I think it is just wrong that DESCRIPTION of sjlabelled just

   Suggests: haven (>= 1.1.2)

I don't understand the difference between Depends and Imports in R
DESCRIPTION files but both are translated to Debian Depends - and this
should be used here.

Kind regards

 Andreas.

On Mon, May 25, 2020 at 01:10:10PM +0300, Adrian Bunk wrote:
> Source: r-cran-sjplot
> Version: 2.8.3-2
> Severity: serious
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-sjplot/5625656/log.gz
> 
> ...
> > library(testthat)
> > library(sjPlot)
> > 
> > if (length(strsplit(packageDescription("sjPlot")$Version, "\\.")[[1]]) > 3) 
> > {
> +   Sys.setenv("RunAllsjPlotTests" = "yes")
> + }
> > 
> > test_check("sjPlot")
> ── 1. Error: (unknown) (@test-plot_model_std.R#15)  
> 
> Package 'haven' required for this function. Please install it.
> Backtrace:
>  1. sjmisc::to_factor(efc, e42dep, c172code, c161sex)
>  2. sjmisc:::to_fac_helper(.dat[[i]], add.non.labelled, ref.lvl)
>  5. sjlabelled::set_labels(...)
>  6. sjlabelled:::set_labels_helper(...)
> 
> ══ testthat results  
> ═══
> [ OK: 2 | SKIPPED: 0 | WARNINGS: 12 | FAILED: 1 ]
> ...
> 
> 
> r-cran-sjlabelled no longer depends on r-cran-haven.
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

-- 
http://fam-tille.de

Bug#961497: Please install registries.conf from samples directory

[Laurent Bigonville]

Le 25/05/20 à 12:20, Dmitry Smirnov a écrit :

On Monday, 25 May 2020 7:58:47 PM AEST Laurent Bigonville wrote:

I think that the registries.conf file from the the samples directory
should be installed to /etc/containers/

Without that buildah is not working out of the box here

I build my own containers and Buildah works perfectly without
"registries.conf". Therefore my judgment on the matter is "wontfix".

Copying the provided file manually to "/etc/containers/" is easy and it
encourages user to review "registries.conf" for explicitly allowed sources.


I kinda disagree here as buildah build-using-dockerfile is definitely 
not working out of the box for me.



I do not wish to encourage people to blindly pull from "docker.io" by
default.


This is still the industry standard today and a default that a user 
might expect

Bug#959811: [pkg-apparmor] Bug#959811: apparmor: Failed to start Load AppArmor profiles

[intrigeri]

Control: tag -1 + moreinfo

Hi marco,

Marco (2020-05-05):
> I was getting an error message when starting apparmor:
>
> # systemctl status apparmor.service
>
> ● apparmor.service - Load AppArmor profiles
>  Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
> preset: enabled)
>  Active: failed (Result: exit-code) since Tue 2020-05-05 13:02:26 -03; 
> 2min 3s ago
>Docs: man:apparmor(7)
>  https://gitlab.com/apparmor/apparmor/wikis/home/
>Main PID: 6936 (code=exited, status=1/FAILURE)
>
> systemd[1]: Starting Load AppArmor profiles...
> apparmor.systemd[6936]: Restarting AppArmor
> apparmor.systemd[6936]: Reloading AppArmor profiles
> apparmor.systemd[6955]: AppArmor parser error for /etc/apparmor.d in 
> /etc/apparmor.d/abstractions/authentication at line 49: Could not open 
> 'abstractions/smbpass'
> apparmor.systemd[7039]: AppArmor parser error for 
> /etc/apparmor.d/usr.sbin.cupsd in /etc/apparmor.d/abstractions/authentication 
> at line 49: Could not open 'abstractions/sm>
> apparmor.systemd[6936]: Error: At least one profile failed to load
> systemd[1]: apparmor.service: Main process exited, code=exited, 
> status=1/FAILURE
> systemd[1]: apparmor.service: Failed with result 'exit-code'.
> systemd[1]: Failed to start Load AppArmor profiles.

Thank you for reporting this. I cannot reproduce this problem here, so
I'll need some more information from you.

Could you please try to load a profile that uses
abstractions/authentication, for example this one (included in the
cups-daemon package):

  sudo apparmor_parser --verbose -r /etc/apparmor.d/usr.sbin.cupsd

This should be sufficient to trigger the bug and should display
more information about the problem.

Also, I suspect the problem comes from a conflict between
the default abstractions/smbpass rules, and another rule coming from
somewhere else, such as a local addition. So:

 - Did you add/modify any file in /etc/apparmor.d/tunables/*.d?

 - What's the output of this command:

 sudo rgrep samba /etc/apparmor.d/local/

Cheers!

Bug#954655: apparmor autopkgtest doesn't work nice on ci.d.n infrastructure

[intrigeri]

Hi,

Paul Gevers (2020-03-22):
> I'm not sure what's going on, but I wanted to at least inform you that
> the apparmor autopkgtest is not working smoothly on the ci.debian.net
> infrastructure. Something in the test is very often preventing
> autopkgtest (the binary) from stopping and cleaning up the lxc container
> within the 600 seconds it gets to do that, which leads to a tmpfail for
> the apparmor autopkgtest and a still running lxc container on the
> worker. Obviously there's a bug somewhere in either lxc and/or
> autopkgtest, as you shouldn't be able to break the infrastructure in
> this way, but maybe you have a clue what could be the cause of this and
> help us to fix the underlying issue. Your autopkgtest itself normally
> passes before causing the issue.

Thanks for letting me know — sorry for the delay in answering.

I don't really have a clue at this stage.

My approach would be to first figure out which one, among the 2 tests
(compile-policy and test-installed), is causing the breakage.
And if the problem lies in compile-policy, I'd like to check
if the problem comes from a specific Depends of that test.

Ideally I would do that without doing uploads to sid merely for
bisection purposes. I'm willing to do test uploads to experimental.

In the debci self-service interface, it seems I could force debci to
install all packages built from src:apparmor from experimental,
which looks like what I need.

Now, to run those tests, I would need apparmor to be temporarily
removed from the blacklist, and some coordination so that a ci.d.n
maintainer can clean up whatever mess the tests create while the
package is temporarily un-blacklisted.

I would be happy to book some time to work on this in
a coordinated manner.

Does this approach make sense to you?
Is there a better way for me to investigate?

> One thing that may be required in your test if the test itself doesn't
> get updated is to mark it as isolation-machine

I agree this would be a better outcome than fully disabling all
testing of this package on debci (which is, understandably, the
current situation).

> although I'd like to understand the issue a bit better to know
> for sure.

Same!

Bug#961494: bowtie2: please make the build reproducible

[Chris Lamb]

Hi,

> […]

This should have read:

  Whilst you do patch out -fdebug-prefix-map in
  debian/patches/reproducible.patch, you also need to filter
  -ffile-prefix-map.


Regards,

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

Bug#961494: bowtie2: please make the build reproducible

[Chris Lamb]

Hi,

> […]

This should have read:

  Whilst you do patch out -fdebug-prefix-map in
  debian/patches/reproducible.patch, you also need to filter
  -ffile-prefix-map.


Regards,

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

Bug#961501: remmina is calling home for update notifications

[Christoph Berg]

Package: remmina
Version: 1.4.3+dfsg-2
Severity: grave

Hi,

this is the second time I've gotten an "What's new in Remmina" popup
window out of the blue (i.e. not while actually using it, it's just
sitting in the background at the moment). I suspect it is calling
home, which would be a gross privacy violation. It's not remmina
upstream's business if I have the program running or not. Note that
the "Send usage statistics silder" is disabled in the screenshot.

Please disable that logic in the default install.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages remmina depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.16-2
ii  libavahi-client3 0.8-1
ii  libavahi-common3 0.8-1
ii  libavahi-ui-gtk3-0   0.8-1
ii  libayatana-appindicator3-1   0.5.4-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libgcrypt20  1.8.5-5
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-8
ii  libsodium23  1.0.18-1
ii  libsoup2.4-1 2.70.0-1
ii  libssh-4 0.9.4-1
ii  libssl1.11.1.1g-1
ii  libvte-2.91-00.60.2-1
ii  remmina-common   1.4.3+dfsg-2

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 1.4.3+dfsg-2
pn  remmina-plugin-secret  
ii  remmina-plugin-vnc 1.4.3+dfsg-2

Versions of packages remmina suggests:
pn  remmina-plugin-exec 
pn  remmina-plugin-kwallet  
pn  remmina-plugin-nx   
pn  remmina-plugin-spice
pn  remmina-plugin-www  
pn  remmina-plugin-xdmcp

-- no debconf information

Christoph

Bug#926896: sysvinit-utils: pidof is unreliable

[Костик Покотиленко]

Hi.

Is the any thoughts on resolution?
Should the fix be expected for Buster?

Bug#959724: codespell: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode

[Vincent Lefevre]

Version: 1.17.1-1

I could check that this bug is now fixed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#959915: redundant freshclam profile since it's shipped in-package

[intrigeri]

Control: tag -1 + pending

Hi John & others,

John Scott (2020-05-06):
> An experimental freshclam profile is provided at 
>  /usr/share/apparmor/extra-profiles/usr.bin.freshclam, but clamav-freshclam
> provides its own more recent one in enforce mode at /etc/aa.d/ and has been
> for a while.

Indeed, good catch!

FTR, here's the profile shipped in the clamav-freshclam package:
https://salsa.debian.org/clamav-team/clamav/-/blob/unstable/debian/usr.bin.freshclam
It has been updated a few times in the last few years.

And here's the upstream one from the AppArmor project:
https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/apparmor/profiles/extras/usr.bin.freshclam
It has been updated once in the last 10 years.

I would love to see cross-distro collaboration on this profile, but
our current infrastructure & processes are not ready for that yet,
and I lack time/energy to push this forward myself.
So for the time being:

> Please remove this one.

This makes sense to me:
/usr/share/apparmor/extra-profiles/usr.bin.freshclam
gives no benefit to Debian users and instead it can cause confusion.

The next upload won't include
/usr/share/apparmor/extra-profiles/usr.bin.freshclam

Cheers!

Bug#961492: routine-update removes required dependencies

[Andreas Tille]

Control: reassign -1 dh-r
Control: retitle -1 dh-update-R removes non-R dependencies"

On Mon, May 25, 2020 at 12:02:58PM +0300, Adrian Bunk wrote:
> Package: routine-update
> Version: 0.0.2
> Severity: grave
> 
> https://salsa.debian.org/r-pkg-team/r-cran-nozzle.r1/-/commit/7d7b872597ffa83f453db4d3b43c0e66d49bd479
> https://salsa.debian.org/r-pkg-team/r-cran-fontliberation/-/commit/952ff2238ad81e9da18899dcd871ecc5454dd0c8
> 
> These were causing RC bugs during the R transition,
> I hope there are not more such breakages that were
> not yet found.

The issue is actually not causes by routine-update but rather
by dh-update-R that regenerates all Depends automatically but
does not respect non-R dependencies we injected for instance
to provide JS files.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

[Holger Wansing]

Hi,

"McIntyre, Vincent (CASS, Marsfield)"  wrote:
> Hi
> 
> I thought this would have been fixed by this commit
> 
> https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22
> 
> which will be available in the 'daily' build of the installer.
> I don't know what the prospects are for having this applied to
> the 'stable' installer.

This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to 
/boot
getting a size between 512 and 768MB (depending on disc size).

@Tobias: you can try a daily build from 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/
to confirm it works for you for installation of bullseye.

I was not aware of this bug, so did not close it...

Should this be considered for backporting to stable?


Holger


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

Bug#961345: cups: daemon crashes with invalid free()

[Bernhard Übelacker]

Hello Peter,
I am not involved in packaging cups, just trying to help
to collect some information.

If possible you could install the package systemd-coredump.
Then in the journal might then appear additional information
where the problem occoured, that could help identifying the issue.

Kind regards,
Bernhard

Bug#961128: apt-transport-https: https fails with segmentation fault

[David Kalnischkies]

On Mon, May 25, 2020 at 07:08:28AM +, meht...@protonmail.com wrote:
> #2  main (argv=) at ./methods/https.cc:546
> Binary = "https.bin+https"

I am curious, what is this "https.bin" file? Or rather, what is with
"https"…

You see, the method we ship(ped) in apt-transport-https should be in
`/usr/lib/apt/methods/https`. We do not and never did ship a
`/usr/lib/apt/methods/https.bin` (which is the file the core was
produced for now that I look again & why this variable has this
seemingly weird content).

$ ls -l /usr/lib/apt/methods/https*
$ file /usr/lib/apt/methods/https*


Looks for me like you have some script (or at least a symlink) in
`/usr/lib/apt/methods/https` which invokes `https.bin`.

Do you remember how you got that setup? Is a dpkg-divert involved or
is that "fixed" by a --reinstall as dpkg does not preserve modifications
to non-config files belonging to packages (if not diverted).


Could be that the "https.bin" file is not even the version a-t-https
ships. Or it could just not be prepared to be renamed (I vaguely
remember something about that) as we use the name of the binary to
choose how to act.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#949789: Please provide a makefile snippet with common variables used during building perl modules

[Dominic Hargreaves]

On Tue, Feb 04, 2020 at 07:36:34PM +0100, gregor herrmann wrote:
> > The specific usage in
> > libcdb-file-perl (removing a file installed to vendorarch after the
> > build) could be circumvented with a wildcard afaics, but I don't think
> > that works for the general case.
> 
> Ack.
>  
> > I guess this can't be provided by debhelper perl_* build systems because
> > the vendorarch path needs to be available to the top level make and the dh
> > subprocesses can't affect that.
> 
> Makes sense.
>  
> > So I'm OK with centralizing this somehow in perl-xs-dev (aka. libperl-dev).
> 
> Hm, perl-xs-dev is only needed for arch:any packages but we might
> want to add other variables which are (also) used in arch:all
> packages as well.

I don't think it hurts to ask packages needing this to build-dep on
libperl-dev if they need access to this variable. I don't think we should
ship such a file in a non-dev package, unless we have a clear and
reasonable runtime use for it (my worry is that people will start
using it for the wrong thing otherwise, which will make it harder to
change later).

On Fri, Feb 21, 2020 at 12:06:06PM +0100, gregor herrmann wrote:
> PERL_CURRENT := $(shell perl -MConfig -e 'print 
> "$$Config{revision}.$$Config{patchlevel}.$$Config{subversion}"')
> PERL_NEXT:= $(shell perl -MConfig -e 'print 
> "$$Config{revision}.$$Config{patchlevel}." . ($$Config{subversion} + 1)')
> 
> That might be a good candidate (maybe as PERL_VERSION-*).
> 
> Similar:
> PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
> 
> 
> ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
> INDEPLIB := $(shell perl -MConfig -e 'print $$Config{vendorlib}')
> 
> That's what started the discussion; I guess we might just use the
> "real" names, so maybe PERL_CONFIG_VENDORARCH etc.
> Maybe it would make sense to just expose all %Config keys?

My concern about doing that is that (similar to my point above) it
exposes a much wider interface, that we might not want to maintain.
I'd rather expose a small number of known requirements (in a
predictable namespace like you suggest); we can easily add more later.

We should mention in the documentation that users should file a bug
against perl if they think that more variables should be added.

Cheers
Dominic

Bug#961454: dahdi-dkms: Cannot compile using DKMS on kernel 5.4 backport and latter

[Patrick ZAJDA]

Le 24/05/2020 à 21:02, Geert Stappers a écrit :

To me it looks a generic DKMS thing.

So I should have reported it as a DKMS issue instead?

P.S.
What is behind  http://ix.io ?
As in "What source code runs at the ix.io  server?"


If it is better: http://paste.debian.net/1148681/ 



The code of ix.io should be free but is still not and yes, we don't know 
the author. It is specified on the main page.


--
Patrick ZAJDA

Bug#961501: remmina is calling home for update notifications

[Antenore Gatta]

Hi Christoph,

Upstream developer…

I think it's a bit exaggerated to say that is a privacy violation.

We just get a plain text file from https://remmina.org (e.g. https://
remmina.org/news/remmina_news.php?ver=1.4.5) with the new changelog.

Remmina on a regular basis verify if there's a new file or if the file of the 
version requested (the PHP parameter) has been changed/updated. 

We do this to notify users about new versions, especially when there are 
important bugs that have been fixed.

Libreoffice does something similar for instance and other software, in Debian, 
as well.

I understand it may be quite annoying and we can add an opt-out option, would 
that be enough?

Please consider that for a small project like Remmina is quite important to 
keep a channel opened with our users, otherwise we keep receiving and 
answering to the same issues again again, because usual people do not do the 
effort of searching through our bug tracking system.

We do not track people and the stats is a completely separated system, that is 
only opt-in.

So, let's find a solution that makes everybody happy.

Regards
Antenore

Bug#961514: buster-pu: package lirc/0.10.1-6.2~deb10u1

[Andreas Beckmann]

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

Hi,

I'd like to update lirc in buster to fix the conffile management
(conffiles were installed in dummy locations but not copied to the
proper locations). Now they are handled as proper conffiles.
I've tested several upgrade scenarios before uploading these changes to
sid.
This may cause dpkg prompting due to modified conffiles on upgrades, but
only if there are actually user modifications (i.e. the existing
configuration files (if any) do not match anything known to be shipped
in the past).
In order to get a clean upgrade path to bullseye, we need to be careful
with the version numbers (in .preinst and .maintscript). Therefore this
is a rebuild of the package in sid, but the two patches added in
unrelated uploads to sid are not relevant for Debian buster and are
disabled in the series file.

The package is already uploaded.


Andreas
diff -Nru lirc-0.10.1/debian/changelog lirc-0.10.1/debian/changelog
--- lirc-0.10.1/debian/changelog2019-04-06 15:12:52.0 +0200
+++ lirc-0.10.1/debian/changelog2020-05-25 15:09:59.0 +0200
@@ -1,3 +1,39 @@
+lirc (0.10.1-6.2~deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for buster.
+  * Disable patches for Raspbian (0.10.1-6) and python3.8 (0.10.1-6.1).
+
+ -- Andreas Beckmann   Mon, 25 May 2020 15:09:59 +0200
+
+lirc (0.10.1-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert "Revert "Do not install conffiles in a dummy location""
+(0.10.1-5.2).  (Closes: #932779, #851618)
+  * d/lirc.maintscript: rm_conffile /etc/lirc/*.dist because they are most
+likely unmodified, don't mv_conffile them to =~ s/\.dist// to avoid
+clashes with existing and possibly modified configuration files.
+  * d/lirc.preinst: Remove unmodified configuration files that are unknown to
+dpkg to avoid prompting when replacing them with conffiles.
+
+ -- Andreas Beckmann   Thu, 14 May 2020 11:46:53 +0200
+
+lirc (0.10.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix time.clock usage. Closes: #949835.
+
+ -- Matthias Klose   Fri, 13 Mar 2020 08:55:53 +0100
+
+lirc (0.10.1-6) unstable; urgency=medium
+
+  * Team upload
+  * debian/patches/lirc-gpio-ir-0.10.patch:
+- fix for kernel 4.19 (Closes: #931078, 930485).
+
+ -- Gianfranco Costamagna   Thu, 04 Jul 2019 
16:43:06 +0200
+
 lirc (0.10.1-5.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lirc-0.10.1/debian/lirc.maintscript 
lirc-0.10.1/debian/lirc.maintscript
--- lirc-0.10.1/debian/lirc.maintscript 1970-01-01 01:00:00.0 +0100
+++ lirc-0.10.1/debian/lirc.maintscript 2020-05-25 15:09:59.0 +0200
@@ -0,0 +1,4 @@
+rm_conffile /etc/lirc/lircd.conf.dist 0.10.1-6.2~
+rm_conffile /etc/lirc/lircmd.conf.dist 0.10.1-6.2~
+rm_conffile /etc/lirc/irexec.lircrc.dist 0.10.1-6.2~
+rm_conffile /etc/lirc/lirc_options.conf.dist 0.10.1-6.2~
diff -Nru lirc-0.10.1/debian/lirc.preinst lirc-0.10.1/debian/lirc.preinst
--- lirc-0.10.1/debian/lirc.preinst 1970-01-01 01:00:00.0 +0100
+++ lirc-0.10.1/debian/lirc.preinst 2020-05-25 15:09:59.0 +0200
@@ -0,0 +1,40 @@
+#!/bin/sh
+set -e
+
+md5sums_shipped="
+92df549c82f58ea28b605e5045984e04  /etc/lirc/irexec.lircrc
+d2664e84bab19f7f36628d1de3f273dd  /etc/lirc/lirc_options.conf #stretch
+6599e8ea08b5f4bf19409666cae22441  /etc/lirc/lirc_options.conf #buster
+810233d6f1bb15b64468beb95e4c670e  /etc/lirc/lircd.conf
+eca53bdc53bd5edc63cf06a4cff16b0d  /etc/lirc/lircmd.conf
+"
+
+if dpkg --compare-versions "$2" lt-nl "0.10.1-6.2~"
+then
+   # * configuration files unknown to dpkg and identical to a known
+   #   shipped version can be deleted to avoid prompting when replacing
+   #   them with proper conffiles
+   # * we must not remove conffiles still known to dpkg as "(obsolete)",
+   #   otherwise dpkg will remember their deletion
+   conffiles="$(dpkg-query -f '${Conffiles}' -W lirc)"
+   for conffile in /etc/lirc/lircd.conf /etc/lirc/lircmd.conf 
/etc/lirc/irexec.lircrc /etc/lirc/lirc_options.conf
+   do
+   test -f "$conffile" || continue
+   if [ -n "$(echo "$conffiles" | grep " $conffile ")" ]
+   then
+   echo "Keeping conffile $conffile which is known to 
dpkg."
+   continue
+   fi
+   case "$md5sums_shipped" in
+   *"$(md5sum "$conffile")"*)
+   echo "Removing unmodified configuration file 
$conffile which is unknown to dpkg."
+   rm "$conffile"
+   ;;
+   *)
+   echo "Keeping modified configuration file 
$conffile which is unknown to dpkg."
+   ;;
+   esac
+   done
+fi
+
+#DEBHELPER#
diff -Nru 

Bug#961473: libreoffice-kde5: The libreoffice templates in /usr/share/templates are set to Letter page size

[Rene Engelhard]

reassign 961473 libreoffice-kde5,libreoffice-plasma
severity 961473 minor
tag 961473 + upstream
thanks

Hi,

On Sun, May 24, 2020 at 11:43:31PM +0200, Steve Russell wrote:
> Package: libreoffice-kde5
> Version: 1:6.1.5-3+deb10u6

Even if it was a bug, we for sure won't change the default in a stable
release (and all this stuff moved to libreoffice-plasma in newer
releases anyway.)

> When I create a new LibreOffice Writer document using the Create New function 
> in Dolphin, the
> new document has the page size set to Letter. When I attempt to print this 
> document it fails
> because my printer does not have Letter size paper.

And you can't just set it to A4? This is a *template*, not necessarily
something you can just use? That's the sense of a template, to edit it.

And I'd argue it is minor, and not normal.

> I would expect that the installer should detect whether my localization 
> settings are using Letter
> or A4 and install the appropriate template for this paper size.

There is no installer. (Well, the installer isn't involved here.)

These files are contained *in the package* (libreoffice-common, even
language-independent, and you can*t just have multiple versions there.)
and just installs from upstream:

# install files for "create new" ...
mkdir -p $(PKGDIR)-plasma/usr/share/templates/.source
for i in $(SOURCE_TREE)/extras/source/shellnew/*; do \
cp $$i $(PKGDIR)-plasma/usr/share/templates/.source/`basename 
$$i`; \
done


Hovever you do it so you do it wrong, although I agree with you that A4 would
be a far more sensible default...

(The other alternative would be to remove that Create New... support,
people should just use File->New in LibreOffice, imho)

Regards,

Rene

Bug#961419: AW: Description file of r-cran-sjlabelled seems to specify wrong depencency from haven (Was: Bug#961498: r-cran-sjplot: missing test dependency on r-cran-haven)

[Daniel Lüdecke]

Suggesting the package 'haven' is correct, because it's only used conditionally 
now. That change was intentional, to reduce package dependencies. See also 
current sjlablled on CRAN 
(https://cran.r-project.org/web/packages/sjlabelled/index.html).

Best
Daniel

-Ursprüngliche Nachricht-
Von: Andreas Tille [mailto:andr...@an3as.eu] 
Gesendet: Montag, 25. Mai 2020 13:10
An: Adrian Bunk ; 961...@bugs.debian.org; 
961...@bugs.debian.org; debia...@lists.debian.org; Daniel Lüdecke 

Betreff: Description file of r-cran-sjlabelled seems to specify wrong 
depencency from haven (Was: Bug#961498: r-cran-sjplot: missing test dependency 
on r-cran-haven)

Hi,

there is a series of build failures connected to missing r-cran-haven.
Formerly r-cran-sjlabelled dependend from r-cran-haven - and IMHO that should 
remain that way:

r-cran-sjlabelled(master) $ grep haven R/* | grep -i required
R/as_label.R:stop("Package 'haven' required for this function. Please 
install it.")
R/get_na.R:stop("Package 'haven' required for this function. Please install 
it.")
R/read.R:stop("Package 'haven' required for this function. Please install 
it.")
R/read.R:stop("Package 'haven' required for this function. Please install 
it.")
R/read.R:stop("Package 'haven' required for this function. Please install 
it.")
R/remove_labels.R:  stop("Package 'haven' required for this function. 
Please install it.")
R/remove_labels.R:stop("Package 'haven' required for this function. Please 
install it.")
R/set_labels.R:  stop("Package 'haven' required for this function. 
Please install it.")
R/set_na.R:stop("Package 'haven' required for this function. Please install 
it.")
R/write.R:stop("Package 'haven' required for this function. Please install 
it.")
R/zap_labels.R:stop("Package 'haven' required for this function. Please 
install it.")


I think it is just wrong that DESCRIPTION of sjlabelled just

   Suggests: haven (>= 1.1.2)

I don't understand the difference between Depends and Imports in R DESCRIPTION 
files but both are translated to Debian Depends - and this should be used here.

Kind regards

 Andreas.

On Mon, May 25, 2020 at 01:10:10PM +0300, Adrian Bunk wrote:
> Source: r-cran-sjplot
> Version: 2.8.3-2
> Severity: serious
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-sjplot/5
> 625656/log.gz
> 
> ...
> > library(testthat)
> > library(sjPlot)
> > 
> > if (length(strsplit(packageDescription("sjPlot")$Version, 
> > "\\.")[[1]]) > 3) {
> +   Sys.setenv("RunAllsjPlotTests" = "yes") }
> > 
> > test_check("sjPlot")
> ── 1. Error: (unknown) (@test-plot_model_std.R#15)  
>  Package 'haven' required for this function. 
> Please install it.
> Backtrace:
>  1. sjmisc::to_factor(efc, e42dep, c172code, c161sex)  2. 
> sjmisc:::to_fac_helper(.dat[[i]], add.non.labelled, ref.lvl)  5. 
> sjlabelled::set_labels(...)  6. sjlabelled:::set_labels_helper(...)
> 
> ══ testthat results  
> ═══
> [ OK: 2 | SKIPPED: 0 | WARNINGS: 12 | FAILED: 1 ] ...
> 
> 
> r-cran-sjlabelled no longer depends on r-cran-haven.
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

--
http://fam-tille.de

--

_

Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; 
Gerichtsstand: Hamburg | www.uke.de
Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Joachim Prölß, 
Prof. Dr. Blanche Schwappach-Pignataro, Marya Verdel
_

SAVE PAPER - THINK BEFORE PRINTING

Bug#961511: xen-utils-common: Protect xenstored/xenconsoled against OOM

[Samuel Thibault]

Samuel Thibault, le lun. 25 mai 2020 15:11:44 +0200, a ecrit:
> I'm currently using a hack such as
> 
> for i in $(pgrep xenconsoled) ; do
> echo -1000 > /proc/$i/oom_score_adj
> done
> 
> in /etc/init.d/xen, but there are cleaner ways to do this :)

For instance, using choom:

start-stop-daemon --start --quiet --pidfile "$XENCONSOLED_PIDFILE" 
--exec /usr/bin/choom -- \
-n -1000 "$XENCONSOLED" $XENCONSOLED_ARGS --pid-file 
"$XENCONSOLED_PIDFILE" \

Samuel

Bug#960448:

[Andreas Hasenack]

In Ubuntu, it returns both maintainers:
$ sed -ne 's/Maintainer:\s\+//p' debian/control
Ubuntu Developers 
XSBC-Original-Debian OpenLDAP Maintainers



I suggest adding a ^:
$ sed -ne 's/^Maintainer:\s\+//p' debian/control
Ubuntu Developers 

Bug#961504: python3-flake8: missing flake8 executable

[Daniel Gomez]

Hi Simon,

On Mon, 25 May 2020 at 15:10, Simon McVittie  wrote:
>
> On Mon, 25 May 2020 at 14:02:22 +0200, Daniel Gomez wrote:
> > After installing python3-flake8 package:
> > apt-get install python3-flake8
> >
> > /usr/bin/flake8 executable is missing.
>
> That's in the flake8 package. python3-flake8 is just the library part;
> it's similar to the relationship between executables and libraries written
> in C/C++, such as apt and libapt-pkg6.0.
>
> smcv

Thanks for the explanation and support. I missed that package:

```
$ dpkg -L flake8 | grep bin
/usr/bin
/usr/bin/flake8
```

Bug#959604: [pkg-uWSGI-devel] Bug#959604: uwsgi-plugin-luajit: FTBFS: make[1]: *** [debian/rules:29: override_dh_auto_build] Error 1

[Jonas Smedegaard]

control: reassign -1 src:uwsgi
control: forcemerge -1 959577

Quoting Lucas Nussbaum (2020-05-03 15:03:01)
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This has been fixed in uwsgi.

Thanks for reporting!

 - 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#961520: whipper: Missing dependency on python3-ruamel.yaml

[韓達耐]

Package: whipper
Version: 0.9.0-1+b1
Severity: important

Hi

The package "whipper" can only run the command "cd rip" if package 
python3-ruamel.yaml is installed.
If not, the following error is displayed:

 $ whipper cd rip --offset 6
Traceback (most recent call last):
  File "/usr/bin/whipper", line 11, in 
load_entry_point('whipper==0.0.0', 'console_scripts', 'whipper')()
  File "/usr/lib/python3/dist-packages/whipper/command/main.py", line 42, in 
main
cmd = Whipper(sys.argv[1:], os.path.basename(sys.argv[0]), None)
  File "/usr/lib/python3/dist-packages/whipper/command/basecommand.py", line 
114, in __init__
self.cmd = self.subcommands[self.options.remainder[0]](
  File "/usr/lib/python3/dist-packages/whipper/command/basecommand.py", line 
114, in __init__
self.cmd = self.subcommands[self.options.remainder[0]](
  File "/usr/lib/python3/dist-packages/whipper/command/basecommand.py", line 
60, in __init__
self.add_arguments()
  File "/usr/lib/python3/dist-packages/whipper/command/cd.py", line 236, in 
add_arguments
loggers = list(result.getLoggers())
  File "/usr/lib/python3/dist-packages/whipper/result/result.py", line 162, in 
getLoggers
plugin_class = entrypoint.load()
  File "/usr/lib/python3/dist-packages/whipper/result/result.py", line 148, in 
load
from whipper.result import logger
  File "/usr/lib/python3/dist-packages/whipper/result/logger.py", line 4, in 

import ruamel.yaml as yaml
ModuleNotFoundError: No module named 'ruamel'


In order to fix this, please add a dependency on python3-ruamel.yaml in 
debian/control.

Thanks.


-- 
Danai


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

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

Versions of packages whipper depends on:
ii  cd-paranoia 10.2+2.0.0-1+b1
ii  libc6   2.30-8
ii  libsndfile1 1.0.28-7
ii  python3 3.8.2-3
ii  python3-cdio2.1.0-1+b1
ii  python3-gi  3.36.0-3
ii  python3-musicbrainzngs  0.7.1-2
ii  python3-mutagen 1.44.0-1
ii  python3-requests2.23.0+dfsg-2

whipper recommends no packages.

whipper suggests no packages.

-- no debconf information

Bug#961494: bowtie2: please make the build reproducible

[Andreas Tille]

Hi Chris,

On Mon, May 25, 2020 at 10:49:28AM +0100, Chris Lamb wrote:
> This should have read:
> 
>   Whilst you do patch out -fdebug-prefix-map in
>   debian/patches/reproducible.patch, you also need to filter
>   -ffile-prefix-map.

I've tried this in Git[1] but the resulting bowtie2 package fails the
autopkgtest in my pbuilder environment.  I remember issues with
autopkgtest in pbuilder before and I suspect this might be the case
here as well.  However, before I really upload I'd invite others to
have a look.

Kind regards

   Andreas.


[1] 
https://salsa.debian.org/med-team/bowtie2/-/commit/97052bc2de1b271f368dd8415cfafde5356e2fe8

-- 
http://fam-tille.de

Bug#961509: libxine2-bin: missing Breaks+Replaces: libxine2-doc (<< 1.2.10)

[Andreas Beckmann]

Package: libxine2-bin
Version: 1.2.10-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libxine2-bin_1.2.10-2_amd64.deb ...
  Unpacking libxine2-bin (1.2.10-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libxine2-bin_1.2.10-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/man/man5/xine.5.gz', which is also in 
package libxine2-doc 1.2.9-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libxine2-bin_1.2.10-2_amd64.deb


cheers,

Andreas


libxine2-doc=1.2.9-1_libxine2-bin=1.2.10-2.log.gz
Description: application/gzip

Bug#961454: dahdi-dkms: Cannot compile using DKMS on kernel 5.4 backport and latter

[Geert Stappers]

On Mon, May 25, 2020 at 11:15:35AM +0200, Patrick ZAJDA wrote:
> Le 24/05/2020 à 21:02, Geert Stappers a écrit :

> > Among other lines
> >  sh: 0: Can't open
> > /usr/src/linux-headers-5.5.0-0.bpo.2-common/scripts/mkmakefile
> >
> > > It looks like there is an incompatibility with kernel 5.4 and 5.5
> > > which prevents the compilation of DAHDI kernel modules.
> > To me it looks a generic DKMS thing.
> So I should have reported it as a DKMS issue instead?

Maybe.  Read
> >  Can't open /usr/src/linux-headers-5.5.0-0.bpo.2-common/scripts/mkmakefile
as "file not found"

Advice:  Find out what should provide the missing file.


Regards
Geert Stappers

P.S.
My appology for adding noise.
I did now learn that I should have put it in a separate message.
-- 
Silence is hard to parse

Bug#952788: Package Debian version 0.4.13 of source

[Leandro Cunha]

If have upload permission for this package I send a nmu to close this bug
report. My job was to preserve the source code by following Debian policies
and doing a QA to ensure that this package can be packaged and installed
properly. This package is in testing with version 4.11 with source code in
version 4.10.

drawing (0.4.13+nmu1) unstable; urgency=medium

  * Non-maintainer upload (Closes: #952788).

 -- Leandro Cunha   Mon, 25 May 2020 10:51:56
-0300

drawing (0.4.13) unstable; urgency=low

  * Disable a broken feature concerning the save dialog (sandboxed package
formats only) (#202)
  * Remove dead code
  * Update polish and german translations
  * Fix minor issue with the selection

 -- Romain F. T.   Sat, 07 Mar 2020 20:00:00 +0100

drawing (0.4.12) unstable; urgency=low

  * The preferences dialog now looks better with Cinnamon, Xfce and MATE
  * Syntax has been updated to python3.8 (#190)
  * The "save" dialog opens by default in the user's images directory
  * Closing a tab doesn't produce minors errors anymore (#193, it was
introduced by 0.4.11)
  * The app.quit action asks confirmation if modifications are not saved
(#191)

 -- Romain F. T.   Sun, 16 Feb 2020 20:00:00 +0100

drawing (0.4.11) unstable; urgency=low

  * Fix the sensitivity of the "delete" action during the selection editing
  * Close tabs with middle-click (#164 @raggesilver)
  * Support color-picking with the alpha channel
  * Add an "outline" option to the text tool
  * Geometrically correct ellipses (circle tool)
  * Rounded rectangle option (rectangle tool)
  * Update translations
  * Rewrite preferences window to include help labels
  * Transparency replacement options

 -- Romain F. T.   Sun, 16 Feb 2020 20:00:00 +0100

drawing (0.4.10) unstable; urgency=low

  * Fix the "rotate" tool where buttons were inverted
  * Change tools icons alignment with Adapta theme
  * Update translations

 -- Romain F. T.   Thu, 20 Dec 2019 20:00:00 +0100

drawing (0.4.9) unstable; urgency=low

  * Remove GTK warning at the initialisation of the window
  * Replace transparency with white (instead of black) when saving a JPG or
a BMP file
  * Fix the color picker tool

 -- Romain F. T.   Thu, 20 Nov 2019 20:00:00 +0100

drawing (0.4.8) unstable; urgency=low

  * Add a "New image with custom size" action
  * Better "File" menu (in the menubar)
  * More usable "Windows" menu (in the menubar)
  * Fix the units inside the spinbuttons on systems without Cantarell
  * Improve the preferences window UI
  * Do not close saved but non-blank images when opening a new image
  * Fix the toolbar style
  * Open or import images with drag-and-drop
  * Add tooltips on color buttons for colorblind users

 -- Romain F. T.   Thu, 5 Nov 2019 20:00:00 +0100

drawing (0.4.7) unstable; urgency=low

  * Version bump

 -- Romain F. T.   Thu, 10 Oct 2019 20:34:00 +0100

drawing (0.4.6) unstable; urgency=low

  * Bug fixes
  * New translations

 -- Romain F. T.   Mon, 22 Jul 2019 00:18:12 +0100

Bug#949789: Please provide a makefile snippet with common variables used during building perl modules

[gregor herrmann]

On Mon, 25 May 2020 11:40:15 +0100, Dominic Hargreaves wrote:

> > > So I'm OK with centralizing this somehow in perl-xs-dev (aka. 
> > > libperl-dev).
> > Hm, perl-xs-dev is only needed for arch:any packages but we might
> > want to add other variables which are (also) used in arch:all
> > packages as well.
> I don't think it hurts to ask packages needing this to build-dep on
> libperl-dev if they need access to this variable. I don't think we should
> ship such a file in a non-dev package, unless we have a clear and
> reasonable runtime use for it (my worry is that people will start
> using it for the wrong thing otherwise, which will make it harder to
> change later).

Having the makefile in a dev package, and having to explicitly
build-depend on it makes sense to me.

What makes me a bit uneasy is maybe a bikeshed thing: The name and
semantics of the package to put it in. libperl-dev is for embedding
perl; perl-xs-dev was invented for (cross-compiling support of)
arch:any/XS packages; now we are talking about (a) generic (arch:any +
arch:all) packaging support file(s) - and creating yet another package
just for one file is overkill as well.

(Sorry, that was just thinking out aloud …)
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Element Of Crime: Alle vier Minuten


signature.asc
Description: Digital Signature

Bug#932779: lirc: Fails to install due to missing /etc/lirc/lirc_options.conf

[Andreas Beckmann]

Followup-For: Bug #932779
Control: tag -1 pending
Control: block -1 with 961514

buster-pu request: https://bugs.debian.org/961514


Andreas

Bug#956495: htpdate systemd service start failure still present in testing

[MichaIng]

Package: htpdate
Version: 1.2.2-3

Hi guys,

the issue has btw not been solved from what I can see and test, but is 
still present on Buster backports as well as on Bullseye and Sid.


The reason is "InaccessibleDirectories" option in the systemd unit 
"/lib/systemd/system/htpdate.service". For security hardening it contains:

-
InaccessibleDirectories=/boot /home /media /mnt /root /opt /srv
-

All these directories must exist, otherwise systemd fails to mount them 
inaccessible for the service, producing the reported error. This could 
hence be also seen as systemd issue, although the question is how to 
better deal with such case:


1. Pre-create the directories, if they do not exist? However could be 
confusing when a systemd unit creates directories unexpectedly and could 
even cause issues if those places are (about to be) used for files or it 
is a R/O path.


2. Ignore directories that do not exist? However could break the 
security intention when e.g. the dir is created after the service has 
been started and data is stored inside then that was wanted to be 
inaccessible for the service.


3. Use another mount method that does not require the dir to exist 
before? Not sure if possible, at least "mount" command as well requires 
the mountpoint dir to exist.


So finally it is probably indeed best to fail and let the admin decide 
how to solve it. The error message has been slightly enhanced with new 
systemd version (Buster backports+):

-
May 25 14:31:26 VM-Buster systemd[216]: htpdate.service: Failed to set 
up mount namespacing: /run/systemd/unit-root/media: No such file

or directory
-
However could still be more clear, not sure how fast one usually derives 
from this that "/media" dir is missing.


Since all listed directories are "required" to fulfil current FHS 
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s02.html) IMO it 
is okay that htpdate expects them and the issue could be forwarded to 
systemd to either handle such cases more gracefully or make the error 
output bulletproof understandable.


Best regards,

Micha

Bug#961516: linux: please enable VBOXSF_FS on amd64 and i386

[Gianfranco Costamagna]

Source: linux
Version: 5.6.14-1
Severity: normal

Hello, can you please enable vboxsf kernel module build now that it is mainline?
it will allow me to relax dependencies on virtualbox package on the dkms builds.

Bug#961518: ITP: vitrage-tempest-plugin -- OpenStack Integration Test Suite - Vitrage plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: vitrage-tempest-plugin
  Version : 4.0.0
  Upstream Author : OpenStack Foundation 
* URL : https://opendev.org/openstack/vitrage-tempest-plugin
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack Integration Test Suite - Vitrage plugin

 Tempest is a set of integration tests to be run against a live Openstack
 cluster in order to make sure that all components are working as expected.
 Tempest will start and stop virtual machine in order to check that your
 cloud is working as expected.
 .
 This package contains the Vitrage plugin.

Bug#961494: bowtie2: please make the build reproducible

[Nilesh Patra]

On Mon, 25 May 2020 at 20:10, Andreas Tille  wrote:

> Hi Chris,
>
> On Mon, May 25, 2020 at 10:49:28AM +0100, Chris Lamb wrote:
> > This should have read:
> >
> >   Whilst you do patch out -fdebug-prefix-map in
> >   debian/patches/reproducible.patch, you also need to filter
> >   -ffile-prefix-map.
>
> I've tried this in Git[1] but the resulting bowtie2 package fails the
> autopkgtest in my pbuilder environment.  I remember issues with
> autopkgtest in pbuilder before and I suspect this might be the case
> here as well.  However, before I really upload I'd invite others to
> have a look.
>

I can confirm that this passes for me.

autopkgtest [20:46:44]: test binary-run: [---
autopkgtest [20:46:45]: test binary-run: ---]
autopkgtest [20:46:45]: test binary-run:  - - - - - - - - - - results - - -
- - - - - - -
binary-run   PASS
autopkgtest [20:46:45]:  summary
check-wo-arguments   PASS
indexing-ref-genome  PASS
binary-run   PASS

Just maybe, this is a false positive again, at your end.

[1]
> https://salsa.debian.org/med-team/bowtie2/-/commit/97052bc2de1b271f368dd8415cfafde5356e2fe8


Kind regards,
Nilesh

Bug#960302: [Pkg-roundcube-maintainers] Bug#960302: imap retry must be tunable

[Matus UHLAR - fantomas]

On 24.05.20 01:34, Sandro Knauß wrote:

Could you please have a look at this regression report?  You authored
the patch and my PHP-fu is failing me :-P  It should definitely not
retry the very same incorrect credentials.  Even on systems without
anti-bruteforce logic that locks the user out, Roundcube still takes 5
times longer to complain a about a failed login — which is not
negligible when an expensive PBKDF is used for credential verification.


ACK


I think it's rather unfortunate that
debian/patches/retry_to_reach_imap_server.patch was AFAICT never submitted
upstream and landed into stable through -p-u. I dunno whether
program/lib/Roundcube/rcube_imap.php:connect() has access to the IMAP state
machine to determine whether a greeting was seen (AFAICT your intention was
to retry on missing greeting lines, not on NO/BYE greeting conditions let
alone failed authentication attempts) or to another interface returning
whether the error is transient or not. Either way it'd be good to have
upstream's blessing before adopting such patches to Debian :-)


Well I tried several times to reach upstream and they are often not answering.
Never the less I created a pull request with an updated version, that does no
retry for unrecoverable failures like authentication failure, no password,
configuration failure. That should improve the situation already in this issue.

@Matus UHLAR: please try the patch attached to the pull request if this fixes
your issue:
https://github.com/roundcube/roundcubemail/pull/7402


this patch works properly when invalid password is entered.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Enter any 12-digit prime number to continue.

Bug#960886: dnetc does not need restarting after log rotate

[tony mancill]

On Sun, May 17, 2020 at 02:02:37PM -0700, Stephen Gildea wrote:
> But it turns out that dnetc re-opens the log file each time it writes,
> so no reload or restart is necessary, and we can just get rid of the
> postrotate action entirely.  Here's the patch:
> 
> --- debian/distributed-net.logrotate_2.9112.521-12009-03-14 
> 21:49:18.0 -0700
> +++ debian/distributed-net.logrotate  2020-05-17 09:29:05.284103866 -0700
> @@ -2,8 +2,5 @@
>   weekly
>   rotate 5
>   create 640 daemon adm
> - postrotate
> - invoke-rc.d distributed-net reload >/dev/null
> - endscript
>   compress
>  }

Hi Stephen,

Thank you for the bug report and the patch.

James, any concern with me uploading an updated package with this
change?

Thanks,
tony

Bug#955856: xfce4-verve-plugin: unnecessarily Build-Depends on deprecated

[Kentaro Hayashi]

 dbus-glib
Message-Id: <20200525213337.e98e25c98f3f907b902bc...@clear-code.com>
In-Reply-To: <20200405124058.gm119...@espresso.pseudorandom.co.uk>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've send MR for this issue.
https://salsa.debian.org/xfce-team/goodies/xfce4-verve-plugin/-/merge_requests/1

Bug#960867: Solved installing the Debian testing version

[Davide Lombardo]

Ok I solved installing the Debian testing version with the following shell 
commands:

$ wget 
http://ftp.de.debian.org/debian/pool/main/f/fs-uae/fs-uae-launcher_3.0.5+dfsg-1_all.deb
 

# dpkg -i ./fs-uae-launcher_3.0.5+dfsg-1_all.deb 

# apt-get install --fix-broken

Bug#961506: [Pkg-javascript-devel] Bug#961506: vows: unmaintained in Debian

[Jonas Smedegaard]

Quoting Xavier (2020-05-25 15:31:54)
> Le 25/05/2020 à 15:08, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-05-25 14:53:50)
> >> Le 25/05/2020 à 14:41, Jonas Smedegaard a écrit :
> >>> node-vows is not really maintained in Debian, and largely 
> >>> unmaintained upstream.
> >>>
> >>> Either someone in the JavaScript team take over from me in looking 
> >>> after it, or it should be dropped from Debian.
> >>>
> >>> As is, I I consider it unsuitable for inclusion in a stable release 
> >>> of Debian.
> > 
> >> dak result:
> >>
> >> Checking reverse dependencies...
> >> # Broken Build-Depends:
> >> d3: node-vows
> >> ltx: node-vows
> >> node-async-stacktrace: node-vows
> >> node-clean-css: node-vows
> >> node-databank: node-vows
> >> node-errs: node-vows
> >> node-expat: node-vows (>= 0.8.1)
> >> node-lcov-parse: node-vows
> >> node-tough-cookie: node-vows
> >> queue-async: node-vows
> >> science.js: node-vows
> >> smash: node-vows (>= 0.7)
> >>
> >> Dependency problem found.
> > 
> > Yes.  It is my understanding that simply filing an RC bugreport and 
> > waiting long enough, those dependencies should automatically get 
> > notified that this package is no longer suitable for testing.
> > 
> > 
> >> Two options:
> >>  * update vows to last published version (0.8.3, 11 months ago)
> >>  * remove/change test of the listed packages
> > 
> > Feel fee to volunteer keeping it alive, just make sure to remove me as 
> > uploader.
> 
> Proposition:
>  * /me updates vows and closes the relevant bug
>  * eyes.js bug stays opened
>  * /me opens a bug against vows (upstream) to remove this dependency
>   (that looks really unmaintained)

Fine by me, as long as you remove me as uploader.

 - 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#961496: rinse: fails to extract rpms

[Ole-Morten Duesund]

Package: rinse
Version: 3.5
Severity: normal
Tags: newcomer

Hi,

rinse doesn't work with cpio 2.13+dfsg-2 (at least).

This cpio version doesn't support --extract-over-symlinks which makes
the unpacking command in rinse die with "failed to extract"

I don't know exactly why, or if, --extract-over-symlinks isn't
available. But it completely breaks rinse.

- Ole-Morten Duesund

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

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

Versions of packages rinse depends on:
ii  cpio   2.13+dfsg-2
ii  libterm-size-perl  0.209-1+b2
ii  libwww-perl6.44-1
ii  perl   5.30.2-1
ii  rpm4.14.2.1+dfsg1-1.1+b1
ii  rpm2cpio   4.14.2.1+dfsg1-1.1+b1
ii  wget   1.20.3-1+b2

rinse recommends no packages.

rinse suggests no packages.

-- no debconf information

Bug#961128: apt-transport-https: https fails with segmentation fault

[mehturt]

‐‐‐ Original Message ‐‐‐
On Monday, May 25, 2020 11:32 AM, David Kalnischkies  
wrote:

> On Mon, May 25, 2020 at 07:08:28AM +, meht...@protonmail.com wrote:
>
> > #2 main (argv=) at ./methods/https.cc:546
> > Binary = "https.bin+https"
>
> I am curious, what is this "https.bin" file? Or rather, what is with
> "https"…
>
> You see, the method we ship(ped) in apt-transport-https should be in
> `/usr/lib/apt/methods/https`. We do not and never did ship a
> `/usr/lib/apt/methods/https.bin` (which is the file the core was
> produced for now that I look again & why this variable has this
> seemingly weird content).
>
> $ ls -l /usr/lib/apt/methods/https*
> $ file /usr/lib/apt/methods/https*
>
> Looks for me like you have some script (or at least a symlink) in
> `/usr/lib/apt/methods/https` which invokes `https.bin`.


While trying to get the core file I renamed "https" to "https.bin" and
created a shell script "https" which had "ulimit -c unlimited; /path/https.bin 
$@"
or something like that..

Sorry if that caused confusion.
m.

Bug#961473: libreoffice-kde5: The libreoffice templates in /usr/share/templates are set to Letter page size

[Rene Engelhard]

Hi,

On Mon, May 25, 2020 at 04:36:43PM +0200, Rene Engelhard wrote:
> These files are contained *in the package* (libreoffice-common, even
> language-independent, and you can*t just have multiple versions there.)
> and just installs from upstream:

Sorry, libreoffice-kde5/libreoffice-plasma obviously, but still language
or country-independent.

Regards,

Rene

Bug#955847: gthumb: unnecessarily Build-Depends on deprecated dbus-glib

[Kentaro Hayashi]

Hi,

I've send MR to fix this issue:
https://salsa.debian.org/debian/gthumb/-/merge_requests/1

Bug#961508: ifupdown: RTNETLINK answers: File exists

[ael]

Package: ifupdown
Version: 0.8.35
Severity: normal

There seem to be so many open bugs for ifupdown that it is not clear
whether there is any point in reporting this, but perhaps it may help
others.

I have encountered the unhelpful error  message "RTNETLINK answers: File
exists" on more than one machine but only on rare occasions.
I seem now to discovered what is happening.

I normally use ethernet, but occasionly wifi. The problem seems to be
when I mistakely "ifup" on one interface, take it down, and then
try to use (ifup) on the other interface.

It looks as if ifdown is failing to clear a broadcast address, and
trying to set up the new broadcast address gives this mysterious
messages passed up from ip.

The failure hapens when ip is called as in:
ip addr add 192.168.0.7/255.255.255.0 broadcast 192.168.0.255 dev eth0 label 
eth0

Deleting this manually with ip  as:-
ip addr del 192.168.0.7/255.255.255.0 broadcast 192.168.0.255   dev eth0 label 
eth0

and then rerunning ifup clears the problem.

I have yet to look at the source, but I guess this should be simple to
fix.


-- Package-specific info:
--- /etc/network/interfaces:
cat: /etc/network/interfaces: Permission denied

/usr/share/bug/ifupdown: 20: cannot open /etc/network/interfaces: Permission 
denied
--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 1015 Apr 13  2015 avahi-autoipd
lrwxrwxrwx 1 root root   32 May 19 13:29 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 8
lrwxrwxrwx 1 root root   23 May  7 19:47 avahi-daemon -> ../if-up.d/avahi-daemon
-rwxr-xr-x 1 root root  138 Sep 21  2018 chrony
-rwxr-xr-x 1 root root 1409 Mar 24  2016 wireless-tools
lrwxrwxrwx 1 root root   32 May 19 13:29 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 12
-rwxr-xr-x 1 root root  344 Apr 28  2012 ethtool
-rwxr-xr-x 1 root root 4191 Sep 15  2018 wireless-tools
lrwxrwxrwx 1 root root   32 May 19 13:29 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 32
-rwxr-xr-x 1 root root  923 Apr 13  2015 avahi-autoipd
-rwxr-xr-x 1 root root  484 Mar  6  2013 avahi-daemon
-rwxr-xr-x 1 root root  290 Dec 21  2016 chrony
-rwxr-xr-x 1 root root  138 Sep 21  2018 chrony.dpkg-dist
-rwxr-xr-x 1 root root 1685 Sep 22  2014 ethtool
-rwxr-xr-x 1 root root 4937 Aug 22  2019 mountnfs
-rwxr-xr-x 1 root root  336 Jul 31  2010 slrn
lrwxrwxrwx 1 root root   32 May 19 13:29 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


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

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

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  5.6.0-1
ii  libc6 2.30-8
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.1+b2

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-2+4.1+deb10u1
pn  rdnssd  

-- Configuration Files:
/etc/default/networking changed:
CONFIGURE_INTERFACES=no


-- no debconf information

Bug#959487: libpng built without VSX support on ppc64le

[Gianfranco Costamagna]

control: close -1
Hello, answering inline
On Sat, 2 May 2020 16:32:27 -0500 (CDT) Timothy Pearson 
 wrote:
> Package: libpng16-16:ppc64le
> Version: 1.6.36-6
> 
> libpng is built without VSX support on POWER systems.  This breaks 
> assumptions in other software, such as node optipng (log below).
> 
> I can work around it with this, but it is not ideal:
> CFLAGS="-DPNG_POWERPC_VSX_OPT=0" npm install optipng-bin
> 
> npm install optipng-bin
> npm WARN npm npm does not support Node.js v10.15.2
> npm WARN npm You should probably upgrade to a newer version of node as we
> npm WARN npm can't make any promises that npm will work with this version.
> npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 
> 8, 9.
> npm WARN npm You can find the latest version at https:/nodejs.org/
> 
> > optipng-bin@6.0.0 postinstall 
> > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin
> > node lib/install.js
> 
>   ⚠ Command failed: 
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng
>  --version
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  1: 
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  @@8�@@@�: not found
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  2: 
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  d: not found
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  1: 
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  ELF: not found
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  1: 
> /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng:
>  Syntax error: ";" unexpected
> 

bad thing to run binaries built for amd64 and i386 on ppc64el, this is an 
optipng upstream issue

> 
>   ⚠ optipng pre-build test failed
>   ℹ compiling from source
>   ✖ Error: Command failed: /bin/sh -c make install
> pngrtran.c:99:1: warning: ‘png_rtran_ok’ defined but not used 
> [-Wunused-function]
>  png_rtran_ok(png_structrp png_ptr, int need_IHDR)
>  ^~~~
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: `u' modifier ignored since `D' is the default (see `U')
> pngxmem.c: In function ‘pngx_malloc_rows_extended’:
> pngxmem.c:38:34: warning: comparison is always false due to limited range of 
> data type [-Wtype-limits]
> (pngx_alloc_size_t)height > (pngx_alloc_size_t)(-1) / 
> sizeof(png_bytep))
>   ^
> ar: `u' modifier ignored since `D' is the default (see `U')
> /usr/bin/ld: ../libpng/libpng.a(pngrutil.o): in function 
> `png_read_filter_row':
> pngrutil.c:(.text+0x29c0): undefined reference to 
> `png_init_filter_functions_vsx'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:100: optipng] Error 1
> make: *** [Makefile:14: install] Error 2
> 
> cd src/optipng && \
> make install && \
> cd ../..
> make[1]: Entering directory 
> '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/optipng'
> cd ../libpng && \
> make -f Makefile PNGLIBCONF_H_PREBUILT=pnglibconf.h.optipng && \
> cd ../optipng
> make[2]: Entering directory 
> '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/libpng'
> cp pnglibconf.h.optipng pnglibconf.h
> gcc -c -I../zlib  -O2 -Wall -Wextra -o png.o png.c
> gcc -c -I../zlib  -O2 -Wall -Wextra -o pngerror.o pngerror.c
> gcc -c -I../zlib  -O2 -Wall -Wextra -o pngget.o pngget.c
> gcc -c -I../zlib  -O2 -Wall -Wextra -o pngmem.o pngmem.c
> gcc -c -I../zlib  -O2 -Wall -Wextra -o pngpread.o pngpread.c


as you can see you are trying to build libpng by yourself, not using the system 
version.

steps to reproduce:
git clone https://github.com/imagemin/optipng-bin
cd optipng-bin
look for lib/install.js and see how the installation is done:
basically, extracts a tarball with lots of embedded stuff (including libpng) 
and run make
tar xvf vendor/source/optipng.tar.gz 
cd optipng-0.7.7/
./configure --with-system-zlib --prefix=foo --bindir=bar
make 

here I see two errors:
1) libpng configure is not run:
edit configure and change
with_preconfigured_libpng=1
to
with_preconfigured_libpng=0

so you run a fresh libpng configure script, detecting correctly what is needed 
for your platform.
make will fail because of a library being misnamed misplaced
cp ../optipng-0.7.7/src/libpng/.libs/libpng16.a 
../optipng-0.7.7/src/libpng/libpng.a
make will succeed

2) use system libpng (the version you are blaming currently :p)
~/optipng-bin$ tar xvf vendor/source/optipng.tar
~/optipng-bin$ cd optipng-0.7.7/
~/optipng-bin/optipng-0.7.7$ 

Bug#961510: clang -sanitize=fuzzer crashes on FMV from shared library

[David Kalnischkies]

Package: clang
Version: 1:9.0-49.1
Severity: normal


Hi,

(I guess that is either me doing something wrong or an upstream bug,
but I can't test non-debian clang versions and have no account for
reporting upstream anyhow nor a good idea where it belongs, so I would
appreciate if you could test this and/or pass on)


Given a shared library with function multi-versioning I want to fuzz
with libFuzzer, the compilation seems fine (expect a strange unused
warning), but the fuzzer crashes instantly:

$ CXX=clang++ ../reproducer.sh
| + clang++ -Wall -Wextra -fsanitize=fuzzer-no-link -fPIC -c foobar.cc
| foobar.cc:3:46: warning: unused function 'bar_impl' [-Wunused-function]
| __attribute__((target("sse4.2"))) static int bar_impl() { return 1; }
|  ^
| 1 warning generated.
| + clang++ -Wall -Wextra -shared -o libfoobar.so foobar.o
| + clang++ -Wall -Wextra -fsanitize=fuzzer fuzzer.cc -L. -lfoobar -o fuzzer
| + LD_LIBRARY_PATH=. ./fuzzer
| Segmentation fault (core dumped)


The backtrace is:
| #0  0x1036 in ?? ()
| #1  0x7f9dce37983f in bar_impl() [clone .resolver] () from ./libfoobar.so
| #2  0x7f9dce5893da in elf_machine_rela (skip_ifunc=, 
reloc_addr_arg=0x7f9dce37bfd8, version=, sym=, 
reloc=0x7f9dce37, map=0x7f9dce54a4f0) at ../sysdeps/x86_64/dl-machine.h:330
| #3  elf_dynamic_do_Rela (skip_ifunc=, lazy=, 
nrelative=, relsize=, reladdr=, 
map=0x7f9dce54a4f0) at do-rel.h:137
| #4  _dl_relocate_object (l=l@entry=0x7f9dce54a4f0, scope=, 
reloc_mode=, consider_profiling=, 
consider_profiling@entry=0) at dl-reloc.c:254
| #5  0x7f9dce580d0a in dl_main (phdr=, phnum=, user_entry=, auxv=) at rtld.c:2259
| #6  0x7f9dce5957cf in _dl_sysdep_start 
(start_argptr=start_argptr@entry=0x7fff3a3edc00, 
dl_main=dl_main@entry=0x7f9dce57f3a0 ) at ../elf/dl-sysdep.c:253
| #7  0x7f9dce57ef04 in _dl_start_final (arg=0x7fff3a3edc00) at rtld.c:447
| #8  _dl_start (arg=0x7fff3a3edc00) at rtld.c:537
| #9  0x7f9dce57e098 in _start () from /lib64/ld-linux-x86-64.so.2
| #10 0x0001 in ?? ()
| #11 0x7fff3a3ef527 in ?? ()
| #12 0x in ?? ()


The crash happens with clang versions 9 (1:9.0.1-12), 10 (1:10.0.0-4) &
11 (1:11~++20200411120955+c65e6079fc9-1~exp1). Note that bar_impl() or
bar() is not even called in the fuzzer.


clang-11 has gained the option -fsanitize-coverage-blacklist which
I found and tried on a whim and gives me the expected result:

$ cat ../blacklist.txt
| fun:*.resolver
$ CXX=clang++-11 CXXFLAGS="-fsanitize-coverage-blacklist=../blacklist.txt" 
../reproducer.sh
| + clang++-11 -fsanitize-coverage-blacklist=../blacklist.txt -Wall -Wextra 
-fsanitize=fuzzer-no-link -fPIC -c foobar.cc
| foobar.cc:3:46: warning: unused function 'bar_impl' [-Wunused-function]
| __attribute__((target("sse4.2"))) static int bar_impl() { return 1; }
|  ^
| 1 warning generated.
| + clang++-11 -fsanitize-coverage-blacklist=../blacklist.txt -Wall -Wextra 
-shared -o libfoobar.so foobar.o
| + clang++-11 -fsanitize-coverage-blacklist=../blacklist.txt -Wall -Wextra 
-fsanitize=fuzzer fuzzer.cc -L. -lfoobar -o fuzzer
| + LD_LIBRARY_PATH=. ./fuzzer
[…]
| fuzzer: fuzzer.cc:8: int LLVMFuzzerTestOneInput(const uint8_t *, size_t): 
Assertion `foo() == 2' failed.
[…]

(The existing -fsanitize-blacklist option did not have an effect.)


Attached is the reproducer.sh script I was using here.


Best regards

David Kalnischkies


reproducer.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

Bug#961506: [Pkg-javascript-devel] Bug#961506: vows: unmaintained in Debian

[Xavier]

Le 25/05/2020 à 14:41, Jonas Smedegaard a écrit :
> Source: vows
> Version: 0.8.1-3
> Severity: grave
> Justification: renders package unusable
>
> node-vows is not really maintained in Debian, and largely unmaintained 
> upstream.
> 
> Either someone in the JavaScript team take over from me in looking after it,
> or it should be dropped from Debian.
> 
> As is, I I consider it unsuitable for inclusion in a stable release of Debian.
> 
>  - Jonas
> 
>

dak result:

Checking reverse dependencies...
# Broken Build-Depends:
d3: node-vows
ltx: node-vows
node-async-stacktrace: node-vows
node-clean-css: node-vows
node-databank: node-vows
node-errs: node-vows
node-expat: node-vows (>= 0.8.1)
node-lcov-parse: node-vows
node-tough-cookie: node-vows
queue-async: node-vows
science.js: node-vows
smash: node-vows (>= 0.7)

Dependency problem found.

Two options:
 * update vows to last published version (0.8.3, 11 months ago)
 * remove/change test of the listed packages

Bug#961504: python3-flake8: missing flake8 executable

[Simon McVittie]

On Mon, 25 May 2020 at 14:02:22 +0200, Daniel Gomez wrote:
> After installing python3-flake8 package:
> apt-get install python3-flake8
> 
> /usr/bin/flake8 executable is missing.

That's in the flake8 package. python3-flake8 is just the library part;
it's similar to the relationship between executables and libraries written
in C/C++, such as apt and libapt-pkg6.0.

smcv

Bug#961506: [Pkg-javascript-devel] Bug#961506: vows: unmaintained in Debian

[Jonas Smedegaard]

Quoting Xavier (2020-05-25 14:53:50)
> Le 25/05/2020 à 14:41, Jonas Smedegaard a écrit :
> > node-vows is not really maintained in Debian, and largely 
> > unmaintained upstream.
> > 
> > Either someone in the JavaScript team take over from me in looking 
> > after it, or it should be dropped from Debian.
> > 
> > As is, I I consider it unsuitable for inclusion in a stable release 
> > of Debian.

> dak result:
> 
> Checking reverse dependencies...
> # Broken Build-Depends:
> d3: node-vows
> ltx: node-vows
> node-async-stacktrace: node-vows
> node-clean-css: node-vows
> node-databank: node-vows
> node-errs: node-vows
> node-expat: node-vows (>= 0.8.1)
> node-lcov-parse: node-vows
> node-tough-cookie: node-vows
> queue-async: node-vows
> science.js: node-vows
> smash: node-vows (>= 0.7)
> 
> Dependency problem found.

Yes.  It is my understanding that simply filing an RC bugreport and 
waiting long enough, those dependencies should automatically get 
notified that this package is no longer suitable for testing.


> Two options:
>  * update vows to last published version (0.8.3, 11 months ago)
>  * remove/change test of the listed packages

Feel fee to volunteer keeping it alive, just make sure to remove me as 
uploader.

 - 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