Bug#972028: python-acora: diff for NMU version 2.2-1.3

[Stefano Rivera]

Control: tags 972028 + patch
Control: tags 972028 + pending

Dear maintainer,

I've prepared an NMU for python-acora (versioned as 2.2-1.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

SR
diff -Nru python-acora-2.2/debian/changelog python-acora-2.2/debian/changelog
--- python-acora-2.2/debian/changelog	2019-12-22 20:03:28.0 -0800
+++ python-acora-2.2/debian/changelog	2020-10-15 22:32:00.0 -0700
@@ -1,3 +1,11 @@
+python-acora (2.2-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Delete generated C before build, and in clean, to ensure regeneration with
+cython. Fixes FTBFS with Python 3.9. (Closes: #972028)
+
+ -- Stefano Rivera   Thu, 15 Oct 2020 22:32:00 -0700
+
 python-acora (2.2-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-acora-2.2/debian/clean python-acora-2.2/debian/clean
--- python-acora-2.2/debian/clean	1969-12-31 16:00:00.0 -0800
+++ python-acora-2.2/debian/clean	2020-10-15 22:29:55.0 -0700
@@ -0,0 +1 @@
+acora/*.c
diff -Nru python-acora-2.2/debian/rules python-acora-2.2/debian/rules
--- python-acora-2.2/debian/rules	2019-12-22 20:03:23.0 -0800
+++ python-acora-2.2/debian/rules	2020-10-15 22:29:46.0 -0700
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME:= acora
+export PYBUILD_BEFORE_BUILD := rm -f $(wildcard acora/*.c)
 export PYBUILD_BEFORE_TEST := cp -a test.py README.rst {build_dir}/
 export PYBUILD_TEST_ARGS   := {interpreter} {build_dir}/test.py
 export PYBUILD_AFTER_TEST  := rm -f {build_dir}/test.py {build_dir}/README.rst

Bug#951402: FTBFS: override for vtkvmtkPolyBallLine does not override

[Drew Parsons]

Package: vmtk
Followup-For: Bug #951402


Upstream says VTK would need to be upgraded to a more recent version.

Bug#972317: FTBFS on ppc64el

[Stéphane Glondu]

Package: src:llvm-toolchain-9
Version: 1:9.0.1-14
Severity: serious
Tags: ftbfs

Dear Maintainer,

Your package FTBFS on ppc64el:

  https://buildd.debian.org/status/package.php?p=llvm-toolchain-9

The rebuild was triggered by the update of OCaml from 4.08.1 to
4.11.1, but the error looks independent (I might be wrong).

The build log ends with:
> clang-9: error: unable to execute command: Segmentation fault
> clang-9: error: clang frontend command failed due to signal (use -v to 
> see invocation)
> clang version 9.0.1-14+b1 
> Target: powerpc64le-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /<>/build-llvm/tools/clang/stage2-bins/bin
> clang-9: note: diagnostic msg: PLEASE submit a bug report to 
> https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, 
> and associated run script.
> clang-9: note: diagnostic msg: 
> 
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-9: note: diagnostic msg: /tmp/testCXXCompiler-2f55c9.cpp
> clang-9: note: diagnostic msg: /tmp/testCXXCompiler-2f55c9.sh
> clang-9: note: diagnostic msg: 
> 
> 
> gmake[3]: *** [CMakeFiles/cmTC_2f83f.dir/build.make:85: 
> CMakeFiles/cmTC_2f83f.dir/testCXXCompiler.cxx.o] Error 254
> gmake[3]: Leaving directory 
> '/<>/libcxxabi/build/CMakeFiles/CMakeTmp'
> gmake[2]: *** [Makefile:140: cmTC_2f83f/fast] Error 2
> gmake[2]: Leaving directory 
> '/<>/libcxxabi/build/CMakeFiles/CMakeTmp'
> 
> 
> 
>   
> 
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:21 (project)
> 
> 
> -- Configuring incomplete, errors occurred!
> See also "/<>/libcxxabi/build/CMakeFiles/CMakeOutput.log".
> See also "/<>/libcxxabi/build/CMakeFiles/CMakeError.log".
> make[1]: *** [debian/rules:438: debian-libcxx-build] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:282: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2


Cheers,

-- 
Stéphane

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

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

Bug#972318: FTBFS on ppc64el

[Stéphane Glondu]

Package: src:llvm-toolchain-10
Version: 1:10.0.1-6
Severity: serious
Tags: ftbfs

Dear Maintainer,

Your package FTBFS on ppc64el:

  https://buildd.debian.org/status/package.php?p=llvm-toolchain-10

The rebuild was triggered by the update of OCaml from 4.08.1 to
4.11.1, but the error looks independent (I might be wrong).

The build log ends with:
> ar ruv libFuzzer.a Fuzzer*.o
> -g -O2 -fdebug-prefix-map=/<>/build-llvm=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2
> Segmentation fault
> ar: `u' modifier ignored since `D' is the default (see `U')
> ar: creating libFuzzer.a
> ar: Fuzzer*.o: No such file or directory
> make[1]: *** [debian/rules:420: debian-libfuzzer-build] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:286: binary-arch] Error 2
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
> status 2


Cheers,

-- 
Stéphane

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

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

Bug#972316: metacity-common: conffile not removed: /etc/sgml/metacity-common.cat

[Paul Wise]

Package: metacity-common
Version: 1:3.38.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=metacity-common ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete
metacity-common: obsolete-conffile /etc/sgml/metacity-common.cat
 /etc/sgml/metacity-common.cat 60e970c8e644a699cb8b40b12fe7fd93 obsolete

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages metacity-common depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1

metacity-common recommends no packages.

metacity-common suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#972207: pymongo: diff for NMU version 3.10.0-2.1

[Stefano Rivera]

Control: tags 972207 + patch
Control: tags 972207 + pending

Dear maintainer,

I've prepared an NMU for pymongo (versioned as 3.10.0-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards,

SR
diff -Nru pymongo-3.10.0/debian/changelog pymongo-3.10.0/debian/changelog
--- pymongo-3.10.0/debian/changelog	2020-03-28 22:06:09.0 -0700
+++ pymongo-3.10.0/debian/changelog	2020-10-15 21:59:45.0 -0700
@@ -1,3 +1,10 @@
+pymongo (3.10.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix test failure on Python 3.9 (Closes: #972207)
+
+ -- Stefano Rivera   Thu, 15 Oct 2020 21:59:45 -0700
+
 pymongo (3.10.0-2) unstable; urgency=medium
 
   * debian/patches/da778c501761f9c7fa0f2f1538e5d569d67ad044.patch
diff -Nru pymongo-3.10.0/debian/patches/fcb6a8ecbc98fceca138d74fb09b516b172bb4e0.patch pymongo-3.10.0/debian/patches/fcb6a8ecbc98fceca138d74fb09b516b172bb4e0.patch
--- pymongo-3.10.0/debian/patches/fcb6a8ecbc98fceca138d74fb09b516b172bb4e0.patch	1969-12-31 16:00:00.0 -0800
+++ pymongo-3.10.0/debian/patches/fcb6a8ecbc98fceca138d74fb09b516b172bb4e0.patch	2020-10-15 21:58:50.0 -0700
@@ -0,0 +1,37 @@
+From: Shane Harvey 
+Date: Thu, 10 Sep 2020 13:39:34 -0700
+Subject: PYTHON-2262 Test Python 3.9 in Evergreen
+
+Bug-Debian: https://bugs.debian.org/972207
+Bug-Upstream: https://jira.mongodb.org/browse/PYTHON-2262
+Origin: upstream, https://github.com/mongodb/mongo-python-driver/commit/fcb6a8ecbc98fceca138d74fb09b516b172bb4e0
+---
+ setup.py  | 1 +
+ test/test_custom_types.py | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setup.py b/setup.py
+index 7c0110f..1ddec32 100755
+--- a/setup.py
 b/setup.py
+@@ -385,6 +385,7 @@ setup(
+ "Programming Language :: Python :: 3.6",
+ "Programming Language :: Python :: 3.7",
+ "Programming Language :: Python :: 3.8",
++"Programming Language :: Python :: 3.9",
+ "Programming Language :: Python :: Implementation :: CPython",
+ "Programming Language :: Python :: Implementation :: PyPy",
+ "Topic :: Database"],
+diff --git a/test/test_custom_types.py b/test/test_custom_types.py
+index ba0bb0c..685a51d 100644
+--- a/test/test_custom_types.py
 b/test/test_custom_types.py
+@@ -255,7 +255,7 @@ class TestBSONFallbackEncoder(unittest.TestCase):
+ 
+ class TestBSONTypeEnDeCodecs(unittest.TestCase):
+ def test_instantiation(self):
+-msg = "Can't instantiate abstract class .* with abstract methods .*"
++msg = "Can't instantiate abstract class"
+ def run_test(base, attrs, fail):
+ codec = type('testcodec', (base,), attrs)
+ if fail:
diff -Nru pymongo-3.10.0/debian/patches/series pymongo-3.10.0/debian/patches/series
--- pymongo-3.10.0/debian/patches/series	2020-03-28 22:06:09.0 -0700
+++ pymongo-3.10.0/debian/patches/series	2020-10-15 21:58:50.0 -0700
@@ -1 +1,2 @@
 da778c501761f9c7fa0f2f1538e5d569d67ad044.patch
+fcb6a8ecbc98fceca138d74fb09b516b172bb4e0.patch

Bug#972315: sysvinit: build depend on libcrypt-dev explicitly

[Helmut Grohne]

Source: sysvinit
Version: 2.96-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sysvinit links -lcrypt. This library got recently split out of
libc6-dev. It still carries a transitional dependency, but for
bootstrapping we have to disable the dependency. Thus when building
sysvinit, it lacks -lcrypt. Please depend on libcrypt-dev explicitly to
enure that it always is there.

Helmut
diff --minimal -Nru sysvinit-2.96/debian/changelog 
sysvinit-2.96/debian/changelog
--- sysvinit-2.96/debian/changelog  2020-09-10 17:37:30.0 +0200
+++ sysvinit-2.96/debian/changelog  2020-10-16 06:38:37.0 +0200
@@ -1,3 +1,10 @@
+sysvinit (2.96-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on libcrypt-dev explicitly. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 16 Oct 2020 06:38:37 +0200
+
 sysvinit (2.96-5) unstable; urgency=low
 
   * Team upload.
diff --minimal -Nru sysvinit-2.96/debian/control sysvinit-2.96/debian/control
--- sysvinit-2.96/debian/control2020-09-10 17:36:17.0 +0200
+++ sysvinit-2.96/debian/control2020-10-16 06:38:34.0 +0200
@@ -9,6 +9,7 @@
  Vincenzo (KatolaZ) Nicosia ,
 Build-Depends:
  debhelper-compat (= 12),
+ libcrypt-dev,
  libselinux1-dev [linux-any],
  po-debconf,
 Rules-Requires-Root: no

Bug#972296: phpmyadmin: missing dependency (php-twig >= 2.9)

[Heiko Richter]

Package: phpmyadmin
Version: 4:4.9.5+dfsg1-2~bpo10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

   I tried to install this package:
apt-cache policy phpmyadmin
phpmyadmin:
  Installed: (none)
  Candidate: 4:4.9.5+dfsg1-2~bpo10+1
  Version table:
 4:4.9.5+dfsg1-2~bpo10+1 100
100 http://deb.debian.org/debian buster-backports/main amd64 
Packages

   Install failed with a missing dependency:
apt install phpmyadmin
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 phpmyadmin : Depends: php-twig (>= 2.9) but 2.6.2-2 is to be installed
E: Unable to correct problems, you have held broken packages.

   There is, however, a dependency to package php-twig >= 2.9. Thw freshest 
version of this package available in Buster doesn't satisfy this dependency:
apt-cache policy php-twig
php-twig:
  Installed: (none)
  Candidate: 2.6.2-2
  Version table:
 2.13.1-1~bpo10+1 100
100 http://deb.debian.org/debian buster-backports/main amd64 
Packages
 2.6.2-2 500
500 http://deb.debian.org/debian buster/main amd64 Packages

   Package depencies should be checked. Is it really necessary to have php-twig 
in version 2.9? One should think this outdated version of phpMyAdmin can work 
with the php-twig package included in Buster.

*** End of the template - remove these template lines ***


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

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

Versions of packages phpmyadmin depends on:
ii  dbconfig-common 2.0.11+deb10u1
ii  debconf [debconf-2.0]   1.5.71
pn  libjs-openlayers
pn  libjs-sphinxdoc 
pn  php 
ii  php-common  2:76+0~20200511.26+debian10~1.gbpc9beb6
pn  php-google-recaptcha
ii  php-json2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
ii  php-mbstring2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
ii  php-mysql   2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
pn  php-phpmyadmin-motranslator 
pn  php-phpmyadmin-shapefile
pn  php-phpmyadmin-sql-parser   
pn  php-phpseclib   
pn  php-psr-container   
pn  php-symfony-expression-languag  
pn  php-twig
pn  php-twig-extensions 
ii  php-xml 2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
ii  php7.4-cli [php-cli]7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  php7.4-json [php-json]  7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  php7.4-mbstring [php-mbstring]  7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  php7.4-xml [php-xml]7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  sensible-utils  0.0.12
ii  ucf 3.0038+nmu1

Versions of packages phpmyadmin recommends:
ii  apache2 [httpd] 2.4.46-2~20200810.12+debian10
ii  php-bz2 2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
ii  php-curl2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
ii  php-gd  2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
pn  php-tcpdf   
ii  php-zip 2:7.4+76+0~20200511.26+debian10~1.gbpc9beb6
ii  php7.4-bz2 [php-bz2]7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  php7.4-curl [php-curl]  7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  php7.4-gd [php-gd]  7.4.11-1+0~20201008.26+debian10~1.gbpcf3106
ii  php7.4-zip [php-zip]7.4.11-1+0~20201008.26+debian10~1.gbpcf3106

Versions of packages phpmyadmin suggests:
ii  mariadb-server-10.3 [virtual-m  1:10.3.23-0+deb10u1
pn  php-bacon-qr-code   
pn  php-gd2 
pn  php-pragmarx-google2fa  
pn  php-recode  
pn  

Bug#972314: df: shows udev pseudo-filesystem by default but pseudo-filesystems should be hidden by default

[Paul Wise]

Package: coreutils
Version: 8.30-3
Severity: normal
File: /bin/df
User: coreut...@packages.debian.org
Usertags: df
Control: found -1 8.32-4+b1

df is supposed to hide pseudo-filesystems by default but it seems to
show the udev pseudo-filesystem by default. Presumably the list of
pseudo-filesystem types needs to be synced from the Linux kernel.

$ df | head -n2
Filesystem Size  Used Avail Use% Mounted on
udev   3.8G 0  3.8G   0% /dev

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-8
ii  libattr1 1:2.4.48-5
ii  libc62.31-3
ii  libgmp10 2:6.2.0+dfsg-6
ii  libselinux1  3.1-2+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#896458: RFH: SWI-Prolog in Debian

[Brett Gilio]

Hello all. If there is still interest in needing co-maintenance on this
package, I would be willing to help.

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#920740: Should crda be shipped in buster?

[Ryutaroh Matsumoto]

When ifconfig and wpasupplicant are used for configuring a
wireless interface, crda seems the only way to choose a regulatory domain.

One cannot do "wpa-country JP" in /etc/network/interface

Best regards, Ryutaroh

Bug#954289: openvpn: Incomplete handling of interrupted credentials prompt with auth-user-pass

[Tomáš Szaniszlo]

Hello,

I have checked that 2.5~rc2-1 still seems to be affected. If you have some
suggestions on what to try, let me know. I have managed to find a minimal
"working" example of ovpn file for this:

tls-client
dev tun
auth-user-pass
pull



I have been testing this using gnome-terminal with su - shell. I have just
tried xterm instead of gnome-terminal and ssh root@localhost instead of su
- in the unlikely case it would be somehow related to the terminal
application or su, but the result was still the same.

TomaS

On Wed, Sep 30, 2020 at 9:20 PM Bernhard Schmidt  wrote:

> Hi,
>
> > thanks for the info. Just to let you know, I tried this with a recent
> > upgrade of openvpn to 2.5~beta3-1 (if that's the update you mentioned),
> > but the issue still seems to persist.
>
> Hrm, that's weird, I can reproduce this issue with 2.4.7 and 2.4.9, but
> not with the 2.5 series. When I press ctrl-c during the credentials
> prompt my terminal is fine afterwards.
>
> Bernhard
>

Bug#919274: Zeitgeist package is being actively maintained

[crvi c]

I don't understand.

Zeitgeist package is being maintained actively at:

https://salsa.debian.org/debian/zeitgeist

There was no release for the past 8 months, so no activity. A new upstream
release 1.0.3 was made today. So, I've opened:

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

So, why is zeitgeist in WNPP state ?

Please clarify.

Thanks!

Bug#972312: GNOME Activity Journal GTK3 version using zeitgeist-1.0.3

[crvi c]

Bug#972313: wpasupplicant: should recommend wireless-regdb

[Ryutaroh Matsumoto]

Package: wpasupplicant
Version: 2:2.9.0-15
Severity: normal

Dear Maintainer,

Configuration item "country=GB" or something like that fails
when wireless-regdb is not installed.
wpa_supplicant should recommend/depend on wireless-regdb.

Best regards, Ryutaroh Matsumoto

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.8.0-2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wpasupplicant depends on:
ii  adduser3.118
ii  libc6  2.31-3
ii  libdbus-1-31.12.20-1
ii  libnl-3-2003.4.0-1+b1
ii  libnl-genl-3-200   3.4.0-1+b1
ii  libnl-route-3-200  3.4.0-1+b1
ii  libpcsclite1   1.9.0-1
ii  libreadline8   8.0-4
ii  libssl1.1  1.1.1g-1
ii  lsb-base   11.1.0

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#971428: xloadimage: -rotate 0 exhausts memory

[Bernhard Übelacker]

Dear Maintainer,
in options.c:792 the modulus of the rotating degrees is checked to
be 0. But this is not triggered if degrees is already zero.
Attached patch should avoid this issue and make xloadimage ignore
the rotate request.

Kind regards,
Bernhard


# Bullseye/testing amd64 qemu VM 2020-10-15


apt update
apt dist-upgrade


apt install systemd-coredump mc htop fakeroot quilt lightdm xserver-xorg 
openbox xterm gdb xloadimage xloadimage-dbgsym
apt build-dep xloadimage


reboot



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




export DISPLAY=:0
ulimit -S -v 1000
cp /usr/share/obconf/video-display.png . -a
xloadimage -rotate 0 video-display.png




benutzer@debian:~$ ulimit -S -v 100
benutzer@debian:~$ xloadimage -rotate 0 video-display.png 
video-display.png is 124x128 PNG image, color type RGB_ALPHA, 8 bit
  Rotating image by 0 degrees...

Memory has been exhausted; operation cannot continue (sorry).







gdb -q --args xloadimage -rotate 0 video-display.png
set width 0
set pagination off
directory /home/benutzer/source/xloadimage/xloadimage-4.1
run


(gdb) bt
#0  __GI___libc_malloc (bytes=47616) at malloc.c:3031
#1  0x55565772 in lmalloc (size=) at new.c:218
#2  0x555659b4 in newTrueImage (width=, height=124) at 
new.c:184
#3  0x5556dc03 in rotate (simage=0x5562d6c0, degrees=4290703186, 
verbose=1) at rotate.c:110
#4  0x55575b2b in doProcessOnImage (image=0x5562d6c0, 
option=, verbose=) at xloadimage.c:110
#5  0x55575c40 in processImage (image=0x5562d6c0, 
global_options=, image_options=) at 
xloadimage.c:164
#6  0x9de6 in main (argc=4, argv=0x7fffe5a8) at xloadimage.c:417



Description: Fix memory exhaustion when rotating by zero degrees

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/971428
Forwarded: no
Last-Update: 2020-10-15

Index: xloadimage-4.1/options.c
===
--- xloadimage-4.1.orig/options.c
+++ xloadimage-4.1/options.c
@@ -789,7 +789,7 @@ void processOptions(argc, argv, rglobal,
   if (++a >= argc)
 	optionUsage(ROTATE);
   newopt->info.rotate= getInteger(ROTATE, argv[a]);
-  if (newopt->info.rotate % 90) {
+  if (newopt->info.rotate % 90 || newopt->info.rotate == 0) {
 	fprintf(stderr, "Argument to %s must be a multiple of 90 (ignored)\n",
 		optionName(ROTATE));
 	newopt->type= OPT_IGNORE;

Bug#972213: boost1.71: Please indicate some way which python versions you support

[Drew Parsons]

Source: boost1.71
Followup-For: Bug #972213
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Would it make sense to use the Built-Using [1] header?
e.g.
  Built-Using: python3.8 python3.9

dh_python3 knows if the module includes extensions
(*_python*.so.) and could inject the pythons into Built-Using.

dh_golang does something like this for the Go packages. There's a
nuance which I don't fully understand about the intended use of
Built-Using, which means it's not really the proper solution for the
Go packages.  I think that's related to the fact that Go applications
are statically linked.  The Python extensions are dynamically linked
so maybe Built-Using could work fine.

[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using

Bug#972312: zeitgeist: Upgrade to zeitgeist-1.0.3

[crvi]

Package: zeitgeist
Version: 1.0.2-3
Severity: normal
X-Debbugs-Cc: crvi...@gmail.com

Dear Maintainer,

Please do upgrade zeitgeist from current 1.0.2 to 1.0.3.

It is required for GNOME Activity Journal to work. GNOME Activity Journal has
been ported to GTK3. Hence usable shortly.

For more details:

https://discourse.gnome.org/t/zeitgeist-gnome-activity-journal-1-0/4521



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

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zeitgeist depends on:
ii  zeitgeist-core 1.0.2-3
ii  zeitgeist-datahub  1.0.2-3

zeitgeist recommends no packages.

zeitgeist suggests no packages.

-- no debconf information

Bug#972311: crda: Could dpkg-reconfigure crda set a regulatory domain?

[Ryutaroh Matsumoto]

Package: crda
Version: 4.14+git20191112.9856751-1
Severity: wishlist

Dear Maintainer,

It would be more user-friendly if user's regulatory domain can be set
by dpke-reconfigure crda.

Making suitable debian/config and debian/templates should enable the above.

Best regards, Ryutaroh Matsumoto

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.8.0-2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages crda depends on:
ii  iw5.8-1
ii  libc6 2.31-3
ii  libnl-3-200   3.4.0-1+b1
ii  libnl-genl-3-200  3.4.0-1+b1
ii  libssl1.1 1.1.1g-1
ii  wireless-regdb2020.04.29-2

crda recommends no packages.

crda suggests no packages.

-- no debconf information

Bug#972310: buster-pu: package puma/3.12.0-2+deb10u2

[Daniel Leidert]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

There are several security advisories open for the puma version in Buster:

  CVE-2020-5247
  CVE-2020-5249
  CVE-2020-11076
  CVE-2020-11077

This upload fixes all these issues with patches taken from upstream's git
repository. The added patches contain references to the commits used.
Furthermore the upload contains a two-liner to add patch headers to an
existing patch.

A few new tests from upstream are added as well and a few other have been
ifixed to apply to the fixed sources. Non-necessary changes have been omitted.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [pending] the issue is verified as fixed in unstable

Unstable contains the 4.x series of puma while buster contains the 3.12 series.
The upload of puma 4.3.6 will follow within one or two days of this report.

Please don't hesitate to contact me if any questions arise.

Regards, Daniel

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl+I6K0ACgkQS80FZ8KW
0F1jSg//XplFcjLWUESWhyT6UWng0bRxafeQvBen5rhi35WCpQdkkGR5VVH7WiEQ
cPLXjVifn66vJtP7/BKpqIWKJkZnotdNRtNXPslYkRb6WvQqTPUguPKQUM7fxOw3
qkKJN0bY49lPnWObiw+CFcXlZQ+lwwbKh7/Ud4MBNoHDd5nWRLwFzs2QndARR2u0
i7nv31ihaD85evcSX6MWKtqXLUzGY4dtp7RR0ecyzcQmyxwT8GEcNxqWBzzVqisk
CkRwvHZESGM+eqcTiqIRFmvMEj+0H4foo5SxGPq/WKlH0/ENvt2VwnDKswyavc5q
YuC1ZUB+hI5uJLJtQ3/ES3FrNgPdH9hjFutG3qzBWi1+M76rrSpT281dr0DYe33R
ycDk2+PDbGpAg13j819MXWSDfR91nYDZ0TOWq1Kx+s2xQ5ObIw/KtvX/K93Vjwb4
SyPrYvqLoeZyAm+erNjyx+BhkrNnzQmkCVgNAD/9N9tHmN1DIOpH4CNNc1zCQfWK
vXmK8ZLuKxGQWNmOMy0JHnDxlHNy1XDvJ8tJOdmjHg6ylncueepFhwQu5nUDv8rs
eW+ICHejvc/W/tBO9TOyB2AE6yMLafAyzMH9qHn/mZPkcR0+s1F3Pu1A96fnz2vn
hMDVrBeoLOD/UUuLe6yR5Reehewmfk3HxoTIFKipB9T+imiTLbw=
=llit
-END PGP SIGNATURE-
diff -Nru puma-3.12.0/debian/changelog puma-3.12.0/debian/changelog
--- puma-3.12.0/debian/changelog2020-03-04 00:15:43.0 +0100
+++ puma-3.12.0/debian/changelog2020-10-15 23:39:36.0 +0200
@@ -1,3 +1,23 @@
+puma (3.12.0-2+deb10u2) buster; urgency=medium
+
+  * Team upload.
+  * d/patches/0009-disable-tests-failing-in-single-cpu.patch: Add author and
+bug tracker information.
+  * d/patches/CVE-2020-5247.patch: Add patch to fix CVE-2020-5247.
+- Fix header value could inject their own HTTP response (closes: #952766).
+  * d/patches/CVE-2020-5249.patch: Add patch to fix CVE-2020-5249.
+- Fix splitting newlines in headers and another vector for HTTP injection
+  (closes: #953122).
+  * d/patches/CVE-2020-11076.patch: Add patch to fix CVE-2020-11076.
+- Better handle client input to fix HTTP Smuggling via Transfer-Encoding
+  header (closes: #972102).
+  * d/patches/CVE-2020-11077.patch: Add patch to fix CVE-2020-11077.
+- Reduce ambiguity of headers to fix HTTP Smuggling via Transfer-Encoding
+  header (closes: #972102).
+  * d/patches/series: Enable new patches.
+
+ -- Daniel Leidert   Thu, 15 Oct 2020 23:39:36 +0200
+
 puma (3.12.0-2+deb10u1) buster; urgency=medium
 
   * Team upload.
diff -Nru 
puma-3.12.0/debian/patches/0009-disable-tests-failing-in-single-cpu.patch 
puma-3.12.0/debian/patches/0009-disable-tests-failing-in-single-cpu.patch
--- puma-3.12.0/debian/patches/0009-disable-tests-failing-in-single-cpu.patch   
2020-03-04 00:15:43.0 +0100
+++ puma-3.12.0/debian/patches/0009-disable-tests-failing-in-single-cpu.patch   
2020-10-15 23:39:36.0 +0200
@@ -1,9 +1,19 @@
+From: Pirate Praveen 
+Date: Sun, 10 Feb 2019 18:56:23 +0530
+Subject: disable-tests-failing-in-single-cpu
+
 Disable test failing on single cpu
-https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921931
 
+Bug-Debian: https://bugs.debian.org/921931
+---
+ test/test_pumactl.rb | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/test_pumactl.rb b/test/test_pumactl.rb
+index 813ec32..11466b2 100644
 --- a/test/test_pumactl.rb
 +++ b/test/test_pumactl.rb
-@@ -33,7 +33,7 @@
+@@ -33,7 +33,7 @@ class TestPumaControlCli < Minitest::Test
  
def test_control_url
  skip if Puma.jruby? || Puma.windows?
diff -Nru puma-3.12.0/debian/patches/CVE-2020-11076.patch 
puma-3.12.0/debian/patches/CVE-2020-11076.patch
--- puma-3.12.0/debian/patches/CVE-2020-11076.patch 1970-01-01 
01:00:00.0 +0100
+++ 

Bug#972309: libkf5kgeomap: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: libkf5kgeomap
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
libkf5kgeomap fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/libkf5kgeomap_20.04.3-1_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can be triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining libkf5kgeomap!


live well,
  vagrant
From efe57fcf0bd79025ba8e0620ebf9b1e7a25c10d2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Oct 2020 00:18:39 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 89aae6a..1aee045 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+# Disable fixfilepath as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
 l10npkgs_firstversion_ok := 4:16.04.3-7~
 include /usr/share/pkg-kde-tools/qt-kde-team/2/l10n-packages.mk
 
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972308: kookbook: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: kookbook
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
kookbook fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/kookbook_0.2.1-1_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can be triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining kookbook!


live well,
  vagrant

From 91638d097b1f535450a283647f3ca42618d3ee95 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Oct 2020 00:11:55 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index e31c6bd..747b7d3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,8 @@
 #!/usr/bin/make -f
 
 # Enable additional hardening options.
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+# Disable fixfilepath as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 %:
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972307: Crashes when trying to enter a package's version

[Daniel Leidert]

Package: reportbug
Version: 7.7.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm trying to write a buster-pu report for release.debian.org and reportbug
crashes when I enter the package's version:

[..]
Choose the request type: 3
Please enter the name of the package: puma
Checking status database...
Latest version seems to be 3.12.0-2+deb10u1, is this the proper one ? [Y|n|?]? n
Please enter the version of the package: '3.12.0-2+deb10u2'
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2302, in 
main()
  File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1709, in user_interface
res = special_prompts(package, bts, ui, fromaddr,
  File "/usr/bin/reportbug", line 531, in special_prompts
return pkgprompts(package, bts, ui, fromaddr, timeout, online, http_proxy)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 613, in 
handle_debian_release
body = textwrap.dedent("""\
TypeError: not all arguments converted during string formatting

Regards, Daniel

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt2.1.10
ii  python33.8.6-1
ii  python3-reportbug  7.7.0
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums3.0.0
pn  dlocate
ii  emacs-bin-common   1:26.3+1-2
ii  exim4-daemon-light [mail-transport-agent]  4.94-8
ii  file   1:5.38-5
ii  gnupg  2.2.20-1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-2

Versions of packages python3-reportbug depends on:
ii  apt2.1.10
ii  file   1:5.38-5
ii  python33.8.6-1
ii  python3-apt2.1.3
ii  python3-debian 0.1.38
ii  python3-debianbts  3.0.2
ii  python3-requests   2.23.0+dfsg-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl+I5T8ACgkQS80FZ8KW
0F1jYQ/+IS6du8vLT9rThcXNEus8lNQTVnEga6PgAT+tCAJv6ic14VOAIkyISHXb
FKfo82Zb7+tt9viUdo1zRZVju51rcTAgT8+Bo2AsA8Ri9ZGy74AtQZuZrOjwtHaK
EI9lw/4qnKpFSrYNvMJbAgpJuNQv4cC8F6oeo6PALH5THTX0DmQ5ekVoI5HCDXL5
kl21bVMKIpO52h8zM94ZpcHuR45afFBjJlGryVm3ltK6li7bDRxImtf4PHtBkXJF
mNDbbzUSug9ysOSDLbCoGotHPldrwDcuHHWk9t+Cs4Cg7ncWWm8+1iiFQYT2jTCg
JAYLJ1hoFz6Q2PNKj6Zbl/B1yXjD1NicrV333Ju6GHbjAebn/HOWO9aIT+5fonFe
InNJ4DFZx+4PDlW8HKXNAaKF3W6KecGmtztpMKjjvYzzoIG9YrIBmCWOdFuMcKDs
/0qbXifmrPAaCyPvf648lA854/o6u0uqyfv1VgsYkPlUW7odwUD+RxjJCeuXLPGg
cmoAH81V6Sp+PpBJPzT4PAfiSPPHbkv/Tnd9x88nstuz/4n/ZhqrB1flsXUzg/mp
zUVOgwI395DZAThPrVHtjWQLf6qfo07zVXKRze4LU5HQBNkQaPniNeWh5TMcoUvf
L7iRSkaAMxXk5bhsG+g6+Rw4bfYdegYy2rm+h/gUdKSDpvrVNB0=
=RZsS
-END PGP SIGNATURE-

Bug#972306: analitza: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: analitza
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
analitza fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/analitza_20.08.0-1_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining analitza!


live well,
  vagrant
From 42f35de749a9eaf462a85eff7d26aa2150054a49 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Oct 2020 00:08:52 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 38d755d..377deae 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,8 @@
 #export DH_VERBOSE = 1
 
 # see FEATURE AREAS in dpkg-buildflags(1)
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+# Disable fixfilepath as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
 
 # see ENVIRONMENT in dpkg-buildflags(1)
 # package maintainers to append CFLAGS
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972305: catch2: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: catch2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
catch2 fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/catch2_2.13.0-1_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can be triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining catch2!


live well,
  vagrant
From 547b3e3517cb29ad1ea51d4fb3c2882291d800b4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Oct 2020 00:05:44 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 02eac5b9..b6ccb202 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+# Disable fixfilepath, as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
+
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 ENABLE_TESTING = ON
 else
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972304: cgreen: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: cgreen
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
cgreen fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/cgreen_1.3.0-1_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining cgreen!


live well,
  vagrant
From d2699a2c641657cb3cbb4fa129450e41a850d5d4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 16 Oct 2020 00:02:26 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 712d026..f08d39b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,8 @@
 #!/usr/bin/make -f
 
 DPKG_EXPORT_BUILDFLAGS = 1
-export DEB_BUILD_MAINT_OPTIONS := hardening=+all
+# Disable fixfilepath as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS := hardening=+all reproducible=-fixfilepath
 export DEB_CFLAGS_MAINT_APPEND := -Wall -D_FORTIFY_SOURCE=2 -O1
 SRC	:= $(CURDIR)
 BUILD	:= $(SRC)/build
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972303: fuzzylite: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: fuzzylite
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
fuzzylite fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/fuzzylite_6.0+dfsg-2_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining fuzzylite!


live well,
  vagrant
From c9e33b51a8a2c0f75aa853f470c34f3e3233ff35 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:59:23 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 628231b..54a0327 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+# Disable fixfilepath as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS=hardening=+all reproducible=-fixfilepath
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972302: grantlee5: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: grantlee5
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
grantlee5 fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/grantlee5_5.2.0-2_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining grantlee5!


live well,
  vagrant
From e9685403f92d54948eaa427ba36ac1ad3fa2bb5d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:56:07 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 1325d43..ee58c88 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,8 @@
 
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+# Disable fixfilepath, as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS = reproducible=-fixfilepath
 
 testsuite_failing_archs := hppa ia64 sparc64
 ifneq (,$(filter $(DEB_HOST_ARCH),$(testsuite_failing_archs)))
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972301: ignition-common: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: ignition-common
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
ignition-common fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/ignition-common_3.5.0+dfsg1-4_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining ignition-common!


live well,
  vagrant
From 9d1ce94b9fd5ac43e38ef9d16ef442b18a39123a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:50:38 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 2871497..2129a31 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,8 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
+# Disable fixfilepath as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow reproducible=-fixfilepath
 BUILDHOME = $(CURDIR)/debian/build
 
 override_dh_auto_configure:
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972216: nmap: New NPSL 0.92 license likely non-free

[Hilko Bengen]

control: severity -1 normal

Hi Göran,

thanks for your bug report. I think that the issue is less serious than
it seems at first glance (see below). At the moment, I'm inclined to
update debian/copyright (which must be done anyway), close the issue,
and be done with this.

The alternatives would be to move NMAP to non-free or drop it from
Debian altogether. Or one could try to get into discussions with the
fine folks at Insecure.Com LLC on how to properly write free(ish)
software licenses. I have neither the time nor the energy to do the
latter.

> The latest nmap is under a new license that seems to go against
> DFSG § 1 (Free Redistribution) seems to be intended to go against
> DFSG § 6 (No Discrimination Against Fields of Endeavor), and it
> could also be argued that it goes against DFSG § 9 (License Must
> Not Contaminate Other Software).

While I agree that the license is problematic, this is not entirely new.
Even back in version 5 there was very similar bizarre language (in
main.cc) about somebody's opinions on how the well-established term
"derivative work" is supposed to include merely running a program and
parsing its output.

Every attempt at redefining what "derivative work" means is clumsy at
best, especially while referring to the GPL; however, I don't see any
problems with DFSG§1 or DFSG§6. The annotations are little more than the
expression of the license author's opinion. Sentences that include "The
idea here is…", "To avoid any misunderstandings…", or "we consider…" are
not something that a licensee can reasonably be expected to agree to in
order to accept a software license.

Cheers,
-Hilko

Bug#972300: keditbookmarks: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: keditbookmarks
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
keditbookmarks fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/keditbookmarks_20.04.0-1_unstable_fixfilepath.log


While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html


I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining keditbookmarks!


live well,
  vagrant

From 9b1cf46b595b17be5da9ec9fd5a7fa2b7c72d523 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:45:04 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 4f64a3a..b240019 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 # see FEATURE AREAS in dpkg-buildflags(1)
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
 
 # see ENVIRONMENT in dpkg-buildflags(1)
 # package maintainers to append CFLAGS
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972299: massif-visualizer: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: massif-visualizer
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
massif-visualizer fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/massif-visualizer_0.7.0-1_unstable_fixfilepath.log

While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html

I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.

Thanks for maintaining massif-visualizer!

live well,
  vagrant

From b13b449225a5b0a61470cbd03184bedd6235dce6 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:39:37 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index dc1384d..d5dae93 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+# Disable fixfilepath feature, as it triggers build failures.
+export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
 export DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed
 
 %:
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972298: okteta: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: okteta
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
okteta fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/okteta_0.26.4-1_unstable_fixfilepath.log

While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html

I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.

Thanks for maintaining okteta!

live well,
  vagrant

From f31c64a3960214e4b35f0d7b08bdcb53d81de2b3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:35:14 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index c948de6..a5d0afc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
 
 TESTS_HOME=$(CURDIR)/debian/tests.home
 
+# Disable fixfilepath, as it causes build failures.
+export DEB_BUILD_MAINT_OPTIONS = reproducible=-fixfilepath
+
 l10npkgs_firstversion_ok := 4:16.04.3-7~
 include /usr/share/pkg-kde-tools/qt-kde-team/2/l10n-packages.mk
 
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972297: scram: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: scram
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
scram fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/scram_0.16.2-1_unstable_fixfilepath.log

While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html

I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.

Thanks for maintaining scram!

live well,
  vagrant

From b36a07c9a62491c4ebef648318e5f919c04017b7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:31:33 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 0ae598f..b1fe31b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+# Disable fixfilepath as it triggers a build failure.
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
 export DEB_LDFLAGS_MAINT_PREPEND = -Wl,-z,defs -Wl,--as-needed
 export QT_SELECT=qt5
 
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972295: tellico: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: tellico
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
tellico fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/tellico_3.3.3-1_unstable_fixfilepath.log

While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment. It
is also used in the tests.reproducible-builds.org infrastructure when
testing unstable and experimental.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html

I have not identified the exact cause of this issue, but a common
trigger is test suites expecting __FILE__ to resolve to an absolute
path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.


Thanks for maintaining tellico!


live well,
  vagrant
From d2683514e75a42ae533bf637e9d5abf59192b684 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:21:06 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index 6b1873a..70cbdcb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,6 +5,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+# The fixfilepath feature causes a build failure, disable it.
+export DEB_BUILD_MAINT_OPTIONS = reproducible=-fixfilepath
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-undefined -Wl,--as-needed
 # do not use kdeinit for kio
 export KDE_FORK_SLAVES=1
-- 
2.28.0



signature.asc
Description: PGP signature

Bug#972293: linux-image-5.8.0-1-amd64: kernel seems to break pulseaudio HDMI sound

[Wesley Schwengle]

On 2020-10-15 19:13, Wesley Schwengle wrote:


When booting with the linux-image-5.8.0-2-amd64 kernel I don't have
sound on my HDMI output. The pulseaudio config hasn't changed yet it
suddenly stopped working after a reboot.

When booting linux-image-5.8.0-1-amd64, the whole setup works again
without fail.

linux-image-5.8.0-1-amd64:
   Installed: 5.8.7-1
   Candidate: 5.8.7-1
   Version table:
  *** 5.8.7-1 100
 100 /var/lib/dpkg/status

linux-image-5.8.0-2-amd64:
   Installed: 5.8.10-1
   Candidate: 5.8.10-1
   Version table:
  *** 5.8.10-1 500
 500 http://deb.debian.org/debian testing/main amd64 Packages
 100 /var/lib/dpkg/status



The issue seems to be fixed in sid:

linux-image-5.8.0-3-amd64:
  Installed: 5.8.14-1
  Candidate: 5.8.14-1
  Version table:
 *** 5.8.14-1 300
300 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

This works

Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Vagrant Cascadian]

Package: openorienteering-mapper
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
openorienteering-mapper fails to build from source:

  
http://qa-logs.debian.net/2020/09/26.fixfilepath/openorienteering-mapper_0.9.3-1_unstable_fixfilepath.log

While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment.

More information about this issue is available at:

  
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html

I have not identified the exact cause of this issue for
openorienteering-mapper, but a common triggering issue is test suites
expectinfg __FILE__ to resolve to an absolute path.

The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.

Thanks for maintaining openorienteering-mapper!


live well,
  vagrant

From f25c2a9a1ebb440eaa6a470f193ed9acca5a90a2 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Oct 2020 23:06:08 +
Subject: [PATCH] debian/rules: Disable fixfilepath feature, as it triggers
 build failures when enabled.

https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index f1e73000..9c412c76 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,7 @@ include /usr/share/dpkg/default.mk
 
 # see FEATURE AREAS in dpkg-buildflags(1)
 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = reproducible=-fixfilepath
 
 # see ENVIRONMENT in dpkg-buildflags(1)
 # package maintainers to append CFLAGS
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#972293: linux-image-5.8.0-1-amd64: kernel seems to break pulseaudio HDMI sound

[Wesley Schwengle]

Package: src:linux
Version: 5.8.7-1
Severity: important

Dear Maintainer,

When booting with the linux-image-5.8.0-2-amd64 kernel I don't have
sound on my HDMI output. The pulseaudio config hasn't changed yet it
suddenly stopped working after a reboot.

When booting linux-image-5.8.0-1-amd64, the whole setup works again
without fail.

linux-image-5.8.0-1-amd64:
  Installed: 5.8.7-1
  Candidate: 5.8.7-1
  Version table:
 *** 5.8.7-1 100
100 /var/lib/dpkg/status

linux-image-5.8.0-2-amd64:
  Installed: 5.8.10-1
  Candidate: 5.8.10-1
  Version table:
 *** 5.8.10-1 500
500 http://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


-- Package-specific info:
** Version:
Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 
(2020-09-05)

** Command line:
BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/neptune--vg-root ro quiet

** Not tainted

** Kernel log:
[   22.358969] iwlwifi :01:00.0: loaded firmware version 36.79ff3ccf.0 
8265-36.ucode op_mode iwlmvm
[   22.358983] iwlwifi :01:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[   22.439723] audit: type=1400 audit(1602802327.623:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/haveged" pid=597 
comm="apparmor_parser"
[   22.439725] audit: type=1400 audit(1602802327.623:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=595 comm="apparmor_parser"
[   22.439727] audit: type=1400 audit(1602802327.623:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=598 
comm="apparmor_parser"
[   22.439729] audit: type=1400 audit(1602802327.623:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=598 comm="apparmor_parser"
[   22.439795] audit: type=1400 audit(1602802327.623:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libvirtd" pid=593 
comm="apparmor_parser"
[   22.439797] audit: type=1400 audit(1602802327.623:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libvirtd//qemu_bridge_helper" pid=593 comm="apparmor_parser"
[   22.439816] audit: type=1400 audit(1602802327.623:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=599 
comm="apparmor_parser"
[   22.440324] audit: type=1400 audit(1602802327.623:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="postgresql_akonadi" pid=601 
comm="apparmor_parser"
[   22.442026] audit: type=1400 audit(1602802327.627:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="mariadbd_akonadi" pid=600 
comm="apparmor_parser"
[   22.442752] audit: type=1400 audit(1602802327.627:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session" pid=594 
comm="apparmor_parser"
[   22.454588] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[   22.460583] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   22.479816] iwlwifi :01:00.0: Detected Intel(R) Dual Band Wireless AC 
8265, REV=0x230
[   22.485123] uvcvideo: Found UVC 1.00 device Integrated_Webcam_HD (0c45:6717)
[   22.488069] iwlwifi :01:00.0: Applying debug destination EXTERNAL_DRAM
[   22.488351] iwlwifi :01:00.0: Allocated 0x0040 bytes for firmware 
monitor.
[   22.493796] uvcvideo 1-11:1.0: Entity type for entity Extension 4 was not 
initialized!
[   22.493798] uvcvideo 1-11:1.0: Entity type for entity Extension 3 was not 
initialized!
[   22.493799] uvcvideo 1-11:1.0: Entity type for entity Processing 2 was not 
initialized!
[   22.493800] uvcvideo 1-11:1.0: Entity type for entity Camera 1 was not 
initialized!
[   22.493852] input: Integrated_Webcam_HD: Integrate as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11:1.0/input/input30
[   22.493907] usbcore: registered new interface driver uvcvideo
[   22.493907] USB Video Class driver (1.1.1)
[   22.536119] Bluetooth: Core ver 2.22
[   22.536128] NET: Registered protocol family 31
[   22.536129] Bluetooth: HCI device and connection manager initialized
[   22.536132] Bluetooth: HCI socket layer initialized
[   22.536134] Bluetooth: L2CAP socket layer initialized
[   22.536136] Bluetooth: SCO socket layer initialized
[   22.536369] dell_laptop: Using i8042 filter function for receiving events
[   22.536372] intel_rapl_common: Found RAPL domain package
[   22.536374] intel_rapl_common: Found RAPL domain core
[   22.536375] intel_rapl_common: Found RAPL domain uncore
[   22.536375] intel_rapl_common: Found RAPL domain dram
[   22.542568] iwlwifi :01:00.0: base HW address: f8:63:3f:c8:77:15
[   22.610828] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3254: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:line
[   

Bug#972292: qemu-system: Can't open a separate graphics windows like sdl or gtk

[Dramon Conte]

Package: qemu-system
Version: 1:5.1+dfsg-4
Severity: normal
X-Debbugs-Cc: draco...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After upgrading this version I was unable to open a separate graphics windows, 
even with -display sdl or -display gtk options. I only get a VNC link.
 

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

I always used qemu to test built boot images and this is now tedious to have
to connect to a vnc viewer to see a virtual machine.  

   * What was the outcome of this action?

A VNC socket.

   * What outcome did you expect instead?

A separate graphics windows.

I need open a separ
*** End of the template - remove these template lines ***


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

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

Versions of packages qemu-system depends on:
ii  qemu-system-arm1:5.1+dfsg-4
ii  qemu-system-mips   1:5.1+dfsg-4
ii  qemu-system-misc   1:5.1+dfsg-4
ii  qemu-system-ppc1:5.1+dfsg-4
ii  qemu-system-sparc  1:5.1+dfsg-4
ii  qemu-system-x861:5.1+dfsg-4

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Bug#935127: bash: please make the build reproducible

[Chris Lamb]

Hi Matthias Klose,

> >> Bash is one of the few remaining packages in the 'Essential' package
> >> set that remains unreproducible, and this patch has been in the BTS
> >> for over a year now.
> >
> > So, there are now only two packages in the Essential set that are
> > unreproducible. I plan to work on the other package (Perl) shortly,
> > but having Bash fixed in the archive itself would be very welcome
> > and motivating withal.
>
> really?  No libgcc in the essential set? yes, it would be motivating if you
> would address the GCC issues upstream and not keeping a set of local patches.

Unfortunately I don't understand the hostility of this reply or how
it is relevant to Bash. Perhaps we are talking at cross-purposes. I am
using this page:

  
https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_essential.html

… which does not list GCC. I was also not aware that I was keeping
a set of local patches.

However, thank you for resolving this bug in your latest upload; really
really appreciated.


Kind regards,

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

Bug#875847: Patch to fix ".qhc files not reproducible"

[Vagrant Cascadian]

control: tags 875847 +patch

On 2020-10-15, Kai Pastor, DG0YT wrote:
> This patch fixes the creation of the offending timestamp, by clamping to 
> SOURCE_DATE_EPOCH as specified.
>
> I also left a link to this Debian bug in Qt's code review for the 
> offending change.
>
> Best regards,
> Kai
> Clamp registered collection time-stamp to SOURCE_DATE_EPOCH if set.
> --- a/src/assistant/help/qhelpcollectionhandler.cpp
> +++ b/src/assistant/help/qhelpcollectionhandler.cpp
> @@ -2197,7 +2197,14 @@
>  m_query->addBindValue(fileName);
>  const QFileInfo fi(absoluteDocPath(fileName));
>  m_query->addBindValue(fi.size());
> -m_query->addBindValue(fi.lastModified().toString(Qt::ISODate));
> +QDateTime last_modified = fi.lastModified();
> +if (qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))
> +{
> +qint64 source_date_epoch = 
> qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH");
> +if (source_date_epoch < last_modified.toSecsSinceEpoch())
> +
> last_modified.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
> +}
> +m_query->addBindValue(last_modified.toString(Qt::ISODate));
>  if (!m_query->exec())
>  return false;
>  


signature.asc
Description: PGP signature

Bug#972241: FTBFS on amd64 and i386 (error: guestfs_launch failed)

[Hilko Bengen]

control: tag -1 confirmed 
control: tag -1 pending

* Stéphane Glondu:

> Package: src:libguestfs
> Version: 1:1.42.0-9
> Severity: serious
> Tags: ftbfs
>
> Dear Maintainer,
>
> Your package FTBFS on amd64 and i386:
>
>   https://buildd.debian.org/status/package.php?p=libguestfs=sid
>
> The rebuild was triggered by the update of OCaml from 4.08.1 to
> 4.11.1, but the error looks independent (I might be wrong).

Yes, This is unrelated to the OCaml update. I had noticed the build
failure. I'm working to fix the issue properly and prepare a patch for
upstream.

Cheers,
-Hilko

Bug#972291: python-py2bit: Mistake in the Architecture: field

[Adrian Bunk]

Source: python-py2bit
Version: 0.3.0-5
Severity: serious
Control: block 969757 by -1

python-py2bit (0.3.0-5) unstable; urgency=medium
...
  * Restrict architectures to those where build time test is passing
Closes: #969757
...


The list of "build time test is passing" architectures are exactly
the little endian architectures.

A serious problem is that any-ppc64 should be replaced with ppc64el.
any-ppc64 includes ppc64 (big endian, FTBFS), but it does not include
ppc64el (little endian, release architecture, tests passed before).

A minor issue is that m68k should be removed from Architecture,
it is big endian and expected to be broken but built with nocheck.

Bug#972290: octave-control: __lti_input_idx__ undefined

[kovacs istvan]

Package: octave-control
Version: 3.1.0-3
Severity: important

When I try to use the tf() function, it fails:

octave:1> tf()
error: '__lti_input_idx__' undefined near line 211 column 30
error: called from
    tf at line 211 column 28

I have tried:
- reinstalling octave
- apt install octave-*
- download the 3.2 version of this package from 
https://octave.sourceforge.io/packages.php

this error persisted.

I have no idea, where this function could be defined?

Best regards,

Zoltan Krajcsovics

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

Kernel: Linux 4.19.0-11-amd64 (SMP w/12 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages octave-control depends on:
ii  libblas3 [libblas.so.3]    3.8.0-2
ii  libc6  2.28-10
ii  libgcc1    1:8.3.0-6
ii  libgfortran5   8.3.0-6
ii  libgomp1   8.3.0-6
ii  liblapack3 [liblapack.so.3]    3.8.0-2
ii  liboctave6 4.4.1-5
ii  libopenblas-base [liblapack.so.3]  0.3.5+ds-3
ii  libquadmath0   8.3.0-6
ii  libslicot0 5.0+20101122-4
ii  libstdc++6 8.3.0-6
ii  octave 4.4.1-5

octave-control recommends no packages.

octave-control suggests no packages.

-- no debconf information

Bug#967954: [Pkg-rust-maintainers] Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

On Thu 2020-10-15 16:44:00 -0400, Daniel Kahn Gillmor wrote:
> Are there design constraints or goals that this approach doesn't solve?

Hm, Guillem pointed me toward https://bugs.debian.org/901827 which
identifies non-contiguous ranges of dependencies due to "transitive
dependencies on multiple versions of the same package"

I don't really understand the distinction (still!), but it seems to me
like this is probably not the general case.  Rather, it's a corner case
that seems to be driving all the rest of the complexity here.

It's also pretty troubling that mdbook (the example in #901827) includes
three different versions of slab and two different versions of mio.  Is
this really a desirable outcome?

I'm looking for ways to reduce the overall complexity of the system.
Seems to me like right now we have a choice between (a) making it
impossible to package crates with snarled dependency trees like mdbook,
or (b) making it hard (but not impossible) to maintain pretty much all
other crates that have more straightforward dependency trees, or (c)
implementing ranged dependencies in dpkg.

At the moment, we seem to be going with (b), which i'm not very fond of
because i tend to work on those particular kinds of packages.

 --dkg



signature.asc
Description: PGP signature

Bug#961434: baresip-core: stack smashing detected with evdev module

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce a stack smashing using the evdev module and as far
as I see it is triggered because of the wrong memory size given to
an ioctl in [1] giving the backtrace in [3].

A brief read of [2] suggests to give instead of EV_MAX the size in bytes
really available. And a package built with attached patch does not
show the stack smashing anymore.

This stack smashing can also be seen in the current testing version.

Kind regards,
Bernhard


[1] https://github.com/baresip/baresip/blob/master/modules/evdev/print.c#L49

[2] 
https://stackoverflow.com/questions/14273129/smashed-stack-when-iterating-over-int-pointers

[3]
(gdb) bt
#0  0x77714427 in ioctl () at ../sysdeps/unix/syscall-template.S:78
#1  0x77fc4adf in print_events (fd=) at 
modules/evdev/print.c:49
#2  0x77fc492a in evdev_alloc (stp=0x77fca198 , 
dev=0x77fca100  "/dev/input/event0") at 
modules/evdev/evdev.c:251
#3  module_init () at modules/evdev/evdev.c:325
#4  0x77f93f82 in mod_load (mp=mp@entry=0x7fffd0d8, 
name=name@entry=0x7fffd0e0 "/usr/lib/baresip/modules/evdev.so") at 
src/mod/mod.c:137
#5  0x5556ce86 in load_module (modp=modp@entry=0x0, modpath=, name=0x7fffe120) at src/module.c:88
#6  0x5556cf9e in module_handler (val=, arg=) at src/module.c:105
#7  0x77f94811 in conf_apply (conf=conf@entry=0x555ac760, 
name=name@entry=0x555790c2 "module", ch=ch@entry=0x5556cf90 
, arg=arg@entry=0x7fffe380) at src/conf/conf.c:285
#8  0x5556d0c1 in module_init (conf=0x555ac760) at src/module.c:151
#9  0x55569950 in conf_modules () at src/conf.c:385
#10 0xf467 in main (argc=, argv=) at 
src/main.c:242
Description: Use right size for ioctl

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/961434
Forwarded: no
Last-Update: 2020-10-15

--- baresip-0.6.1.orig/modules/evdev/print.c
+++ baresip-0.6.1/modules/evdev/print.c
@@ -46,7 +46,7 @@ void print_events(int fd)
 	int i;
 
 	memset(evtype_bitmask, 0, sizeof(evtype_bitmask));
-	if (ioctl(fd, EVIOCGBIT(0, EV_MAX), evtype_bitmask) < 0) {
+	if (ioctl(fd, EVIOCGBIT(0, sizeof(evtype_bitmask)), evtype_bitmask) < 0) {
 		warning("evdev: ioctl EVIOCGBIT (%m)\n", errno);
 		return;
 	}


# Unstable amd64 qemu VM 2020-10-14


apt update
apt dist-upgrade


apt install systemd-coredump mc htop fakeroot gdb rr baresip 
baresip-core-dbgsym libre0-dbgsym
apt build-dep libre0
apt build-dep baresip
echo 1 > /proc/sys/kernel/perf_event_paranoid




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

mkdir /home/benutzer/source/baresip-core/orig -p
cd/home/benutzer/source/baresip-core/orig
apt source baresip-core
cd



mc -e /home/benutzer/.baresip/accounts
# configure account



baresip
d
sip:...@fritz.box



benutzer@debian:~$ baresip
baresip v1.0.0 Copyright (C) 2010 - 2020 Alfred E. Heggestad et al.
Local network address:  IPv4=ens4|10.0.2.15  IPv6=ens4|fec0::5054:ff:fe12:3456
aucodec: PCMU/8000/1
aucodec: PCMA/8000/1
ausrc: alsa
auplay: alsa
medianat: stun
medianat: turn
medianat: ice
Populated 1 account
Populated 3 contacts
Populated 2 audio codecs
Populated 0 audio filters
Populated 0 video codecs
Populated 0 video filters
baresip is ready.
>sip:...@fritz.box
ua: using best effort AF: af=AF_INET
call: connecting to 'sip:...@fritz.box'..
*** stack smashing detected ***: terminated
Abgebrochen (Speicherabzug geschrieben)



root@debian:~# journalctl -e
...
Okt 14 17:49:57 debian systemd[1]: Started Process Core Dump (PID 11453/UID 0).
Okt 14 17:49:58 debian systemd-coredump[11454]: Process 11451 (baresip) of user 
1000 dumped core.

Stack trace of thread 11451:
#0  0x7f7c802e8c41 
__GI_raise (libc.so.6 + 0x3bc41)
#1  0x7f7c802d2537 
__GI_abort (libc.so.6 + 0x25537)
#2  0x7f7c8032b6c8 
__libc_message (libc.so.6 + 0x7e6c8)
#3  0x7f7c803ba5b2 
__GI___fortify_fail (libc.so.6 + 0x10d5b2)
#4  0x7f7c803ba590 
__stack_chk_fail (libc.so.6 + 0x10d590)
#5  0x55ccf95ed3da 
call_connect (baresip + 0x143da)
#6  0x55ccf95fb35c 
ua_connect (baresip + 0x2235c)
#7  0x7f7c7fdb9e1f n/a 
(menu.so + 0x4e1f)
#8  0x55ccf95efaa6 n/a 
(baresip + 0x16aa6)
#9  0x7f7c8067348a n/a 
(stdio.so + 0x148a)
#10 0x7f7c8063f2dc n/a 
(libre.so.0 + 0x562dc)
   

Bug#972215: [Pkg-xmpp-devel] Bug#972215: gajim: Cannot connect to host with untrusted certificate

[Colomban Wendling]

Hi,

Le 14/10/2020 à 23:58, Martin a écrit :
> On 2020-10-14 19:06, Colomban Wendling wrote:
>> What I get is a popup telling me the certificate authority is unknown
>> (which is expected here, it's self-signed), and allowing me to see the
>> cert and to add it to the list of trusted certificates.  However, doing
>> so does not work, and the dialog pops up again and again and again,
>> effectively preventing any connection to that account.
>>
>> This actually renders Gajim unusable for me as I cannot connect to any
>> of my accounts.
> 
> I'm not aware of that issue, but I use letsencrypt for my
> servers. I wonder, whether this is related to
> "ignore_ssl_errors no longer works with Gajim 1.2.2"
> (https://dev.gajim.org/gajim/gajim/-/issues/10237)?
> 
> However, there the certificate is not only self-signed, but also
> erroneous (wrong host or outdated). Could you comment here,
> whether this is the case with your certificates?

I checked with the server maintainer, and indeed the domains I use did
not appear in the CN or SAN of the cert the server presented my client.
 I don't think this should have prevented me from manually validating
its use (as I actually did check it in person, so I am positive that's
the right cert no matter what its metadata say), but it indeed wasn't
state-of-the-art.

I see on that linked report someone saying:

> Gajim supports self signed certificates, but what you sign must be
> correct. Otherwise you can just use no certificate at all.

I cannot second that kind of reasoning: yes, maybe it could be made
harder to accept an "invalid" certificate to lower the risk of a naive
user blindly clicking through in case of a MiM attack, but there is no
world where untrusted encryption is worse than clear communication.
Again in my case I checked the certificate is actually the right one
with a fully trusted side channel, so the metadata don't matter.

> If your certificate is correct, but it still does not work, you
> might like to try that, given you have root accesss:
> 
> Add the self-signed certificate to the system, IIRC, by storing
> the certificate file under /usr/local/share/ca-certificates/ and
> run update-ca-certificates. Then restart Gajim. Does that help?

I had to manually add it to /etc/ssl/certs/ca-certificates.crt, but I
finally got it in.  This changed the error, now telling me "the
certificate does not match the expected identity of the site" -- which
is fair, yet I still don't think it should be a hard, unrecoverable error.

Anyway, the cert has now been updated to present the proper CN for the
domains I use, so I can connect again to my accounts with Gajim (after
validating the self-signed cert twice for some reason).  But I hardly
think a missing CN/SAN is a good reason to prevent any encrypted
communication.  Any encryption is better than none in all cases -- even
if encrypting for a MiM.  I'm saddened by this whole misconception that
encryption and signatures are the same thing and that the former is
useless without the latter.

And in any case, regardless of the above, the UI should be fixed not to
lead to a infinite loop of dialogs, and to properly reflect what the
actual problem is.

Regards,
Colomban

Bug#972286: coreutils: Crash when using globs on a path with non-latin characters

[ಚಿರಾಗ್ ನಟರಾಜ್]

15/10/20 17:29 ನಲ್ಲಿ, Michael Stone  ಬರೆದರು:
> 
> On Thu, Oct 15, 2020 at 04:28:35PM -0400, you wrote:
> >Steps to reproduce:
> >
> >1. mkdir ~/ಇಳಿಕೆಗಳು
> >2. touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
> >3. ls ~/ಇಳಿಕೆಗಳು/*.txt crashes immediately
> >
> >By contrast:
> >
> >1. cd ~/ಇಳಿಕೆಗಳು/ && ls *.txt succeeds
> >2. ls ಇಳಿಕೆಗಳು/*.txt succeeds
> >
> >Similarly, `cp ~/ಇಳಿಕೆಗಳು/*.txt .` crashes, but `cp ಇಳಿಕೆಗಳು/*.txt .` works, 
> >as does `cd ಇಳಿಕೆಗಳು && cp *.txt ~`.
> >
> >Please let me know if you need more information.
> 
> coreutils doesn't have anything to do with expanding a shell wildcard,
> the bug needs to be assigned to whatever shell you're using.

Got it, I'll submit this to bash (verified that it's a shell problem by testing 
with a different shell).


publickey - debbugs@chiraag.me.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature

Bug#972286: coreutils: Crash when using globs on a path with non-latin characters

[Michael Stone]

On Thu, Oct 15, 2020 at 04:28:35PM -0400, you wrote:

Steps to reproduce:

1. mkdir ~/ಇಳಿಕೆಗಳು
2. touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
3. ls ~/ಇಳಿಕೆಗಳು/*.txt crashes immediately

By contrast:

1. cd ~/ಇಳಿಕೆಗಳು/ && ls *.txt succeeds
2. ls ಇಳಿಕೆಗಳು/*.txt succeeds

Similarly, `cp ~/ಇಳಿಕೆಗಳು/*.txt .` crashes, but `cp ಇಳಿಕೆಗಳು/*.txt .` works, as does 
`cd ಇಳಿಕೆಗಳು && cp *.txt ~`.

Please let me know if you need more information.


coreutils doesn't have anything to do with expanding a shell wildcard, 
the bug needs to be assigned to whatever shell you're using.

Bug#972286: Clarification

[ಚಿರಾಗ್ ನಟರಾಜ್]

It seems that the key part is including the ~ character along with non-latin 
elements of the path.

The following work:

1. ls ${HOME}/ಇಳಿಕೆಗಳು/*.txt
2. ls /home/$(whoami)/ಇಳಿಕೆಗಳು/*.txt
3. ls ~/.config/*rc

While `ls ~/ಇಳಿಕೆಗಳು/*.txt` does not.

- Chiraag
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Pronouns: he/him/his


publickey - debbugs@chiraag.me.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature

Bug#971428: xloadimage: -rotate 0 exhausts memory

[Thorsten Glaser]

Bernhard Übelacker dixit:

>in options.c:792 the modulus of the rotating degrees is checked to
>be 0. But this is not triggered if degrees is already zero.
>Attached patch should avoid this issue and make xloadimage ignore
>the rotate request.

I’d probably do that for multiples of 360.

Nik, should I team-upload and add myself to Uploaders
(after you told me some time ago IRL I could join)
or do you prefer to do this yourself?

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#971760: systemd: Error messages about XDG autostart after logging in as root

[Michael Biebl]

Am 06.10.20 um 23:36 schrieb Kurt Roeckx:
> On Tue, Oct 06, 2020 at 10:57:12PM +0200, Michael Biebl wrote:
>> Am 06.10.20 um 22:53 schrieb Kurt Roeckx:
>>
>>> What I all mentioned in my initial email:
>>> - It gets logged to the kernel and console.
>>
>> I can't reproduce that. Do you have some custom syslog configuration?
> 
> I only seem to get it the first time I log in as root.

I still have trouble reproducing the issue of getting those log messages
on the console.
What kind of syslogger are you using? Can you share the complete syslog
config?



signature.asc
Description: OpenPGP digital signature

Bug#972255: transition: postgresql-common/221

[Christoph Berg]

Re: Sebastian Ramacher
> > autopkgtest for omnidb/2.17.0+ds-2: amd64: Regression ♻ (reference ♻), 
> > arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> > Regression ♻ (reference ♻)
> 
> The autopkgtests for omnidb 2.17.0+ds-4 also fails:
> https://ci.debian.net/data/autopkgtest/testing/amd64/o/omnidb/7482609/log.gz
> The tests is using postgresql-common from testing. Is that missing a
> tighter dependency somewhere?

Right, sorry for missing that. Fix uploaded as 2.17.0+ds-5.

Christoph

Bug#971977: debian-policy: debian/changelog date syntax description inconsistent/ambiguous wrt. to day of month

[Guillem Jover]

Hi!

On Mon, 2020-10-12 at 11:35:22 +0200, Axel Beckert wrote:
> Guillem Jover wrote:
> > Right. I've clarified this now locally for deb-changelog(5) as follows:
> >   +Is a one- or two-digit day of the month (B<01>-B<31>), where the heading
>   ^^^
> >   +zero is optional, but conventionally does not get omitted.
> [...]
> >Any line that consists entirely (i.e., no leading whitespace) of B<#>
>^^^
> >or B style comments or RCS keywords.
> 
> You once use "heading" and once "leading". Is this on purpose? At
> least for "whitespace" the term "leading whitespace" seems to be the
> common one, so I'm not sure if "heading zero" is really a proper
> term. (But then again, English is not my mother tongue and I might be
> wrong here.)

Ah, thanks! I did actually doubt about that word usage, but didn't
notice the other instance after a very brief scan. :) I've amended this
now locally.

Thanks,
Guillem

Bug#969588: sqv: Cannot use ASCII armored key as keyring?

[Guillem Jover]

Hi!

On Thu, 2020-10-15 at 11:40:59 -0400, Daniel Kahn Gillmor wrote:
> On Sat 2020-09-05 17:09:06 +0200, Guillem Jover wrote:
> > I was trying out sqv, to potentially add native support for it into
> > dpkg-dev, but either it does not work as expected or I'm confused by
> > the docs. :)
> >
> >   $ apt source libbsd
> >   $ sqv -v --keyring libbsd-0.10.0/debian/upstream/signing-key.asc \
> > libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz  
> >   Missing key 4F3E74F436050C10F5696574B972BF3EA4AE57A3, which is needed to 
> > verify signature.
> >   0 of 1 signatures are valid (threshold is: 1).
> >   $ sqv -v --keyring /usr/share/keyrings/debian-keyring.gpg \
> > libbsd_0.10.0.orig.tar.xz.asc libbsd_0.10.0.orig.tar.xz
> >   4F3E74F436050C10F5696574B972BF3EA4AE57A3
> >   1 of 1 signatures are valid (threshold is: 1).
> 
> I forwarded this to upstream at
> https://gitlab.com/sequoia-pgp/sequoia/-/issues/585, and Justus there
> suggests that the problem is that the OpenPGP certificate in
> libbsd-0.10.0/debian/upstream/signing-key.asc is not up-to-date.  With a
> refreshed version of the certificate, it appears to work.

I was also embarrassed for a moment, :) then realized this should have
failed with GnuPG, and rechecking the signing-key.asc recalled it
contains the two certificates concatenated one after the other, which
GnuPG seems to be able to import correctly.

> So i don't think this is a bug in sqv, and i'm closing the ticket.  Feel
> free to reopen if you think that there is still a problem!

I guess that depends on whether sqv is supposed to support
concatenated certificates, or whether they need to be in a single
ASCII armored block?

I'm not sure how prevalent this is in the archive, but I expect other
instances to exist there. ISTR concatenation being documented
somewhere as a way to add new certificates.

Thanks,
Guillem

Bug#911189: gpgme-json packaging

[Daniel Kahn Gillmor]

On Thu 2020-10-01 14:05:59 +0200, Sascha Wilde wrote:
> so far I haven't received any reply to either my pull request or my
> questions in the bug report issue from Fri, 11 Sep 2020 15:38:13 +0200.
>
> I would still appreciate input on my work, especially if there is
> anything I need to do to make the changes acceptable for the Debian
> package.

Hi Sascha--

thanks for this, and sorry for my delay in responding to you.  It's on
my queue, and i'll try to look at it soon.

If anyone else on the debian GnuPG packaging team wants to take a look
and give feedback, i'd appreciate it too!

 --dkg

Bug#972255: transition: postgresql-common/221

[Christoph Berg]

Re: Sebastian Ramacher
> Removal hint added. Could you please file an RC bug against
> postgresql-multicorn so that once removed from testing britney doesn't
> try to migrate?

Thanks.

Bug: #972285

Christoph

Bug#969713: GNOME Activity Journal 1.0

[crvi c]

Just a FYI.

GNOME activity journal ( zeitgeist gui ) port to python3 is complete.

For more details please refer:

https://discourse.gnome.org/t/zeitgeist-gnome-activity-journal-1-0/4521/

Bug#961985: Fix available on Salsa.

[Aloïs Micard]

Hello there!

A fix has been made and pushed to Salsa [1]. It is waiting
for upload on the archive.


Cheers,

[1] 
https://salsa.debian.org/go-team/packages/hub/-/commit/7edbf77ae324ec26a7d297ff84d0d301faf6cbae


--
Aloïs Micard (creekorful) 

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Bug#972185: libre0: stack smashing detected in v1.1.0

[Bernhard Übelacker]

Hello Kevin,
I don't know the details, but I guess there will no automatic
rebuild of baresip triggered on migration.
As far as I see [1], the only users of libre0 are
baresip and librem0, so I guess both might need a rebuild.
Maybe someone with more shared library packaging knowledge
might give some pointers what steps need to be taken now?

Kind regards,
Bernhard

[1] `apt-cache rdepends libre0` in an unstable VM.

Bug#967954: [Pkg-rust-maintainers] Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

On Thu 2020-10-15 14:51:45 -0400, Daniel Kahn Gillmor wrote:
> On Wed 2020-08-12 13:59:05 +0100, peter green wrote:
>> The proper fix IMO would be to add support for version ranges to
>> dependencies in dpkg
>
> I agree that this seems promising -- we'd then need to have debcargo
> unwind a bunch of its extensive Provides: tags to take advantage of it,
> but that doesn't sound too ugly.  it's possible that introducing ranges
> into build-dependencies would be a problem for dpkg for other reasons
> though.  I'm Cc'ing Guillem here to see whether he has any thoughts on
> the matter.

(sorry for replying to myself here)

Thinking this through further, I think cargo dependency ranges like

   foo = ">=0.4, < 0.6"

do actually already do work in dpkg.  You represent them as:

 Build-Depends:
   librust-foo-dev (>= 0.4),
   librust-foo-dev (<< 0.6)

That would be the easy/simple way to go, so then of course the question
is: why does debcargo use these elaborate Provides: renaming schemes
instead of the simple conjunction described above?

I think the answer is because debcargo wants to be able to explicitly
support a named older version of the library in parallel with the
"latest and greatest" -- a "pinned" line of the package.  so that
librust-foo-dev (maybe version 0.6) can be co-installed with the pinned
librust-foo-0.4-dev (version 0.4.2), and still have that
build-dependency be satisfied.

If there's some other reason, maybe Ximin (in Cc) can clarify it. i
think he understands debcargo's design choices and constraints better
than anyone.

However, this approach isn't going to work on the standard buildd
network, anyway, because the first element of the disjunction generated
by debcargo is likely to be 0.5:

 Build-Depends:
   librust-foo-0.5-dev | librust-foo-0.4-dev

and sbuild will ignore the latter element of the disjunction, and the
package would FTBFS anyway because the BD is uninstallable.  So that
doesn't seem to solve the problem anyway, except in the lucky case where
the highest element of the range happens to also be the one "pinned" in
the current release.

  ---

Looking at other solutions, we also have versioned Provides: fields
available these days.  so if we want to keep rust-foo 0.4 "pinned" in
debian while also tracking the latest-and-greatest rust-foo, then
src:rust-foo-0.4 would produce a librust-foo-0.4-dev binary package
with:

 Provides: librust-foo-dev = 0.4.2-1

then the conjunctive, versioned Depends would be able to figure out how
to satisfy it.

I think this handles the case we're talking about here.

It seems like it could also enable cutting down on the number of
Provides: generated by non-pinned crate packages, once all of the
depending packages had converted to the simpler form.

Are there design constraints or goals that this approach doesn't solve?

Sorry that i'm still (years into the rust debian packagingn process)
trying to get my head around this problem space.  I appreciate folks
bearing with me on this.

(thanks to folks on the #debian-dpkg channel for helping me think this
through).

--dkg


signature.asc
Description: PGP signature

Bug#972288: openjdk-11 FTBFS with gcc-10

[Helmut Grohne]

Source: openjdk-11
Version: 11.0.8+10-1.1
Severity: serious
Tags: ftbfs

openjdk-11 fails to build from source due to gcc-10 defaulting to
-fno-commons.

https://tests.reproducible-builds.org/debian/rbuild/bullseye/amd64/openjdk-11_11.0.8+10-1.1.rbuild.log.gz
| /usr/bin/ld: 
/build/openjdk-11-11.0.8+10/build/support/native/java.base/libjava/childproc.o:./make/./src/java.base/unix/native/libjava/childproc.h:121:
 multiple definition of `parentPathv'; 
/build/openjdk-11-11.0.8+10/build/support/native/java.base/libjava/ProcessImpl_md.o:./make/./src/java.base/unix/native/libjava/childproc.h:121:
 first defined here

http://crossqa.debian.net/build/openjdk-11_11.0.8+10-1_armel_20200930210757.log
| ( /bin/rm -f 
/<>/build/buildjdk/support/native/java.base/libjava/BUILD_LIBJAVA_link.log
 && /usr/bin/x86_64-linux-gnu-gcc -Wl,--hash-style=both -Wl,-z,defs 
-Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-O1 
-L/<>/build/buildjdk/support/modules_libs/java.base 
-L/<>/build/buildjdk/support/modules_libs/java.base/server -shared 
-Wl,--exclude-libs,ALL -Wl,-z,origin -Wl,-rpath,\$ORIGIN -Wl,-soname=libjava.so 
-o /<>/build/buildjdk/support/modules_libs/java.base/libjava.so 
@/<>/build/buildjdk/support/native/java.base/libjava/_BUILD_LIBJAVA_objectfilenames.txt
 /<>/build/buildjdk/support/native/java.base/libfdlibm.a -ljvm 
-lverify -ldl > >(/usr/bin/tee -a 
/<>/build/buildjdk/support/native/java.base/libjava/BUILD_LIBJAVA_link.log)
 2> >(/usr/bin/tee -a 
/<>/build/buildjdk/support/native/java.base/libjava/BUILD_LIBJAVA_link.log
 >&2) || ( exitcode=$? && /bin/cp 
/<>/build/buildjdk/support/native/java.base/libjava/BUILD_LIBJAVA_link.log
 
/<>/build/make-support/failure-logs/buildjdk_support_native_java.base_libjava_BUILD_LIBJAVA_link.log
 && /bin/cp 
/<>/build/buildjdk/support/native/java.base/libjava/BUILD_LIBJAVA_link.cmdline
 
/<>/build/make-support/failure-logs/buildjdk_support_native_java.base_libjava_BUILD_LIBJAVA_link.cmdline
 && exit $exitcode ) ) ; 
| /usr/bin/ld: 
/<>/build/buildjdk/support/native/java.base/libjava/childproc.o:/<>/src/java.base/unix/native/libjava/childproc.h:121:
 multiple definition of `parentPathv'; 
/<>/build/buildjdk/support/native/java.base/libjava/ProcessImpl_md.o:/<>/src/java.base/unix/native/libjava/childproc.h:121:
 first defined here
| collect2: error: ld returned 1 exit status
| gmake[5]: *** [CoreLibraries.gmk:101: 
/<>/build/buildjdk/support/modules_libs/java.base/libjava.so] 
Error 1

Helmut

Bug#972287: libcoverart FTCBFS: does not build IMPORT_EXECUTABLES

[Helmut Grohne]

Source: libcoverart
Version: 1.0.0+git20150706-9
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libcoverart fails to cross build from source, because it does not pass
previously built IMPORT_EXECUTABLES to cmake. This is necessary when
performing cross compilation. It's a separate cmake invocation with a
native toolchain and produces the make-c-interface program. Just adding
that pass does not exactly work though. libcoverart uses neon and neon
is not coinstallable, so we cannot provide it to the native build pass.
Thus my patch adds an option BUILD_IMPORT_EXECUTABLES_ONLY that
basically disables everything but make-c-interface. Building that tool
requires libxml2-dev (for the build architecture!), which was previously
missing from Build-Depends. The attached patch makes libcoverart cross
buildable. Please consider applying it.

Helmut
diff --minimal -Nru libcoverart-1.0.0+git20150706/debian/changelog 
libcoverart-1.0.0+git20150706/debian/changelog
--- libcoverart-1.0.0+git20150706/debian/changelog  2020-09-27 
21:27:04.0 +0200
+++ libcoverart-1.0.0+git20150706/debian/changelog  2020-10-15 
17:49:18.0 +0200
@@ -1,3 +1,10 @@
+libcoverart (1.0.0+git20150706-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build IMPORT_EXECUTABLES. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 15 Oct 2020 17:49:18 +0200
+
 libcoverart (1.0.0+git20150706-9) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru libcoverart-1.0.0+git20150706/debian/control 
libcoverart-1.0.0+git20150706/debian/control
--- libcoverart-1.0.0+git20150706/debian/control2020-09-27 
21:25:21.0 +0200
+++ libcoverart-1.0.0+git20150706/debian/control2020-10-15 
17:49:18.0 +0200
@@ -7,7 +7,8 @@
  debhelper-compat (= 13),
  cmake,
  libneon27-gnutls-dev | libneon-dev,
- libjansson-dev
+ libjansson-dev,
+ libxml2-dev:native,
 Build-Depends-Indep:
  doxygen,
  graphviz
diff --minimal -Nru libcoverart-1.0.0+git20150706/debian/patches/cross.patch 
libcoverart-1.0.0+git20150706/debian/patches/cross.patch
--- libcoverart-1.0.0+git20150706/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ libcoverart-1.0.0+git20150706/debian/patches/cross.patch2020-10-15 
17:49:18.0 +0200
@@ -0,0 +1,41 @@
+--- libcoverart-1.0.0+git20150706.orig/CMakeLists.txt
 libcoverart-1.0.0+git20150706/CMakeLists.txt
+@@ -30,8 +30,10 @@
+ SET(coverartc_SOVERSION ${coverartc_SOVERSION_MAJOR})
+ 
+ SET(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
+-FIND_PACKAGE(Neon REQUIRED)
+-FIND_PACKAGE(Jansson REQUIRED)
++IF(NOT BUILD_IMPORT_EXECUTABLES_ONLY)
++  FIND_PACKAGE(Neon REQUIRED)
++  FIND_PACKAGE(Jansson REQUIRED)
++ENDIF()
+ IF(NOT CMAKE_CROSSCOMPILING)
+   FIND_PACKAGE(LibXml2 REQUIRED)
+ ENDIF(NOT CMAKE_CROSSCOMPILING)
+@@ -52,8 +54,10 @@
+ INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/libcoverartcc.pc 
${CMAKE_CURRENT_BINARY_DIR}/libcoverart.pc DESTINATION 
${LIB_INSTALL_DIR}/pkgconfig)
+ 
+ ADD_SUBDIRECTORY(src)
+-ADD_SUBDIRECTORY(tests)
+-ADD_SUBDIRECTORY(examples)
++IF(NOT BUILD_IMPORT_EXECUTABLES_ONLY)
++  ADD_SUBDIRECTORY(tests)
++  ADD_SUBDIRECTORY(examples)
++ENDIF()
+ 
+ ADD_CUSTOM_TARGET(docs
+   doxygen
+--- libcoverart-1.0.0+git20150706.orig/src/CMakeLists.txt
 libcoverart-1.0.0+git20150706/src/CMakeLists.txt
+@@ -32,6 +32,10 @@
+   EXPORT(TARGETS make-c-interface FILE 
${CMAKE_BINARY_DIR}/ImportExecutables.cmake )
+ ENDIF(NOT CMAKE_CROSSCOMPILING)
+ 
++IF(BUILD_IMPORT_EXECUTABLES_ONLY)
++  RETURN()
++ENDIF()
++
+ FILE(GLOB INC_FILES *.inc)
+ ADD_CUSTOM_COMMAND(
+   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/caa_c.cc 
${CMAKE_CURRENT_BINARY_DIR}/caa_c.h 
${CMAKE_CURRENT_BINARY_DIR}/../include/coverart/caa_c.h
diff --minimal -Nru libcoverart-1.0.0+git20150706/debian/patches/series 
libcoverart-1.0.0+git20150706/debian/patches/series
--- libcoverart-1.0.0+git20150706/debian/patches/series 2020-09-27 
21:23:09.0 +0200
+++ libcoverart-1.0.0+git20150706/debian/patches/series 2020-10-15 
17:49:18.0 +0200
@@ -3,3 +3,4 @@
 0003-gcc-5.patch
 0004-Use-const-when-catching-exceptions.patch
 0005-Fix-build-with-cmake-3.18.patch
+cross.patch
diff --minimal -Nru libcoverart-1.0.0+git20150706/debian/rules 
libcoverart-1.0.0+git20150706/debian/rules
--- libcoverart-1.0.0+git20150706/debian/rules  2020-09-27 21:26:42.0 
+0200
+++ libcoverart-1.0.0+git20150706/debian/rules  2020-10-15 17:49:18.0 
+0200
@@ -2,11 +2,22 @@
 
 include /usr/share/dpkg/architecture.mk
 
+FOR_BUILD = dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c
+
 %:
dh $@
 
+ifeq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+execute_after_dh_auto_clean::
+   $(FOR_BUILD) dh_auto_clean
+endif
+
 override_dh_auto_configure:
-   dh_auto_configure -- -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH)
+ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+   $(FOR_BUILD) dh_auto_configure -- -DBUILD_IMPORT_EXECUTABLES_ONLY=TRUE
+   

Bug#972289: linuxlogo FTCBFS: does not export CROSS

[Helmut Grohne]

Source: linuxlogo
Version: 5.11-9
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

linuxlogo fails to corss build from source. The build system needs a
variable CROSS to be exported for cross compilation. Please consider
applying the attached patch to fix that.

Helmut
diff --minimal -Nru linuxlogo-5.11/debian/changelog 
linuxlogo-5.11/debian/changelog
--- linuxlogo-5.11/debian/changelog 2016-09-20 13:08:48.0 +0200
+++ linuxlogo-5.11/debian/changelog 2020-10-15 21:29:59.0 +0200
@@ -1,3 +1,10 @@
+linuxlogo (5.11-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export a suitable CROSS variable. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 15 Oct 2020 21:29:59 +0200
+
 linuxlogo (5.11-9) unstable; urgency=medium
 
   * Changed maintainer's email
diff --minimal -Nru linuxlogo-5.11/debian/rules linuxlogo-5.11/debian/rules
--- linuxlogo-5.11/debian/rules 2016-09-20 13:08:48.0 +0200
+++ linuxlogo-5.11/debian/rules 2020-10-15 21:29:32.0 +0200
@@ -1,8 +1,11 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow
 export CFLAGS=$(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags 
--get CPPFLAGS)
+export CROSS=$(DEB_HOST_GNU_TYPE)-
 
 %:
find ./logos -type f | LC_ALL=C sort > logo_config 

Bug#972273: gbp import-orig does not sign commits with GPG

[William Desportes]

Package: git-buildpackage
Version: 0.9.19
Severity: normal

When I import using the command "gbp import-orig --uscan" none of the created 
commits are GPG signed.

My global GPG signature is enabled and using the git command line everything 
goes well for me.

Expected: create commits that are GPG signed for merges, upstream commits and 
pristine tar commits
Actual: creates commits without a GPG signature, I need to amend them to add a 
signature.

Thanks

Bug#972255: transition: postgresql-common/221

[Sebastian Ramacher]

On 2020-10-15 12:34:43 +0200, Christoph Berg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I think I have put everything in place that needs to be done to have
> postgresql-common/221 migrate to testing, which makes the switch from
> PostgreSQL 12 to 13 as the "supported" version concerning extension
> module packages.
> 
> In the first round of extension I uploaded everything that was listed
> as regression on the postgresql-common excuses page.
> 
> https://qa.debian.org/excuses.php?package=postgresql-common
> 
> Remaining issues listed there are:
> 
> autopkgtest for check-postgres/2.25.0-1: amd64: Pass, arm64: Pass, armhf: 
> Regression ♻ (reference ♻), i386: Pass
> 
> -> The testsuite is flaky and the armhf problem hopefully goes away by
> retrying (I already clicked the button). In any case, the regression
> is test-only.
> 
> autopkgtest for gvmd/9.0.1-4: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> 
> -> Fixed in -4.1 in unstable
> 
> autopkgtest for osm2pgrouting/2.3.6-1: amd64: Regression ♻ (reference ♻), 
> arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> 
> -> I believe I fixed that in -2 in unstable, but debci is currently
> still picking up the old postgis packages from unstable for the test.
> In any case, the regression is test-only.
> 
> autopkgtest for omnidb/2.17.0+ds-2: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)

The autopkgtests for omnidb 2.17.0+ds-4 also fails:
https://ci.debian.net/data/autopkgtest/testing/amd64/o/omnidb/7482609/log.gz
The tests is using postgresql-common from testing. Is that missing a
tighter dependency somewhere?

Cheers

> autopkgtest for pg-checksums/1.0-3: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> autopkgtest for pgtap/1.1.0-2: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> 
> -> I added Breaks: for these in the last postgresql-common upload, the
> issues are all fixed in unstable. (But the packages can only
> transition along with postgresql-common.)
> 
> autopkgtest for postgresql-multicorn/1.4.0-2: amd64: Regression ♻ (reference 
> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), 
> i386: Regression ♻ (reference ♻)
> 
> -> The only real problem, upstream has not yet released a fix for PG13
> yet. Please remove postgresql-multicorn/1.4.0-2 from testing so we can
> proceed.
> 
> (I have probably missed a few "not built on buildd" blockers on some of
> the extension packages. Please schedule binnmus there, thanks.)
> 
> So, in summary: please
> * remove postgresql-multicorn/1.4.0-2 from testing
> * unblock postgresql-common/221
> 
> Thanks,
> Christoph
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972286: coreutils: Crash when using globs on a path with non-latin characters

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: coreutils
Version: 8.32-4+b1
Severity: important
Tags: l10n
X-Debbugs-Cc: debb...@chiraag.me

Dear Maintainer,

Steps to reproduce:

1. mkdir ~/ಇಳಿಕೆಗಳು
2. touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
3. ls ~/ಇಳಿಕೆಗಳು/*.txt crashes immediately

By contrast:

1. cd ~/ಇಳಿಕೆಗಳು/ && ls *.txt succeeds
2. ls ಇಳಿಕೆಗಳು/*.txt succeeds

Similarly, `cp ~/ಇಳಿಕೆಗಳು/*.txt .` crashes, but `cp ಇಳಿಕೆಗಳು/*.txt .` works, as 
does `cd ಇಳಿಕೆಗಳು && cp *.txt ~`.

Please let me know if you need more information.

- Chiraag

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-8
ii  libattr1 1:2.4.48-5
ii  libc62.31-4
ii  libgmp10 2:6.2.0+dfsg-6
ii  libselinux1  3.1-2+b1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#968912: transition: perl 5.32

[Sebastian Ramacher]

On 2020-10-15 18:27:08 +0100, Niko Tyni wrote:
> On Sun, Aug 23, 2020 at 07:25:19PM +0100, Dominic Hargreaves wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-p...@lists.debian.org
> > 
> > Hi, perl 5.32 has been in experimental since June and I think it's going
> > to be ready for sid/bullseye within the next month or so - this is the
> > version we expect to ship with bullseye (given the freeze in January).
> > 
> > The main blockers at present are the perl-tk update (I've just
> > pinged #960863) and, indirectly, the ipv6-only build related problems
> > described in #964902.
> 
> These are resolved now, and all known regressions found in our test
> rebuilds are marked as blocking this bug.
> 
> The libpod-parser-perl dependencies are trivial to add.
> 
> There's no fix for libdata-alias-perl, and I expect we'll need to remove
> it from testing. It's just an optional dependency for other packages
> AFAICS, so I don't expect much fallout (as long as the build dependencies
> are relaxed in libio-stream-perl and libmethod-signatures-perl first.)
> 
> Could we raise the remaining bugs to 'serious' now? Do you have any
> guesstimate on the timing for a transition slot?

There is some overlap with the currently ongoing ocaml transition. So
let's wait until that one is done.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972285: Needs porting to PostgreSQL 13

[Christoph Berg]

Package: postgresql-12-python3-multicorn
Version: 1.4.0-2
Severity: serious

Multicorn needs to be ported to PostgreSQL 13, but unfortunately
upstream isn't ready yet:

https://github.com/Segfault-Inc/Multicorn/issues/261
https://github.com/Segfault-Inc/Multicorn/pull/260

This bug is to keep Multicorn out of testing until this has been
resolved. (See also #972255.)

Christoph

Bug#972284: youtube-dl: [download] Unable to resume, does not download any format

[Thorsten Glaser]

Package: youtube-dl
Version: 2020.09.14-1
Severity: important
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de

This is playable from the website.

tglase@tglase-nb:/tmp $ youtube-dl -F 
https://www.youtube.com/watch?v=umTVO7IUUJ0 
[youtube] umTVO7IUUJ0: Downloading webpage
[info] Available formats for umTVO7IUUJ0:
format code  extension  resolution note
140  m4aaudio only tiny  144k , m4a_dash container, 
mp4a.40.2@128k (48000Hz)
160  mp4256x144144p  121k , avc1.4d400c, 30fps, video only
133  mp4426x240240p  255k , avc1.4d4015, 30fps, video only
134  mp4640x360360p  625k , avc1.4d401e, 30fps, video only
135  mp4854x480480p  803k , avc1.4d401f, 30fps, video only
136  mp41280x720   720p 1275k , avc1.4d401f, 30fps, video only
386  mp4unknowntiny 
387  mp4unknowntiny  (best)
tglase@tglase-nb:/tmp $ youtube-dl -f 136+140 
https://www.youtube.com/watch?v=umTVO7IUUJ0 
[youtube] umTVO7IUUJ0: Downloading webpage
[download] Unable to resume


ERROR: Did not get any data blocks
1|tglase@tglase-nb:/tmp $ youtube-dl 
https://www.youtube.com/watch?v=umTVO7IUUJ0
[youtube] umTVO7IUUJ0: Downloading webpage
[download] Unable to resume


ERROR: Did not get any data blocks


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages youtube-dl depends on:
ii  python33.8.2-3
ii  python3-pkg-resources  50.3.0-1

Versions of packages youtube-dl recommends:
ii  ca-bundle [ca-certificates]  20190604
ii  curl 7.72.0-1
ii  ffmpeg   7:4.3.1-4
ii  mplayer  2:1.3.0-8+b9
pn  python3-pyxattr  
pn  rtmpdump 
ii  wget 1.20.3-1+b3

Versions of packages youtube-dl suggests:
ii  libfribidi-bin  1.0.8-2
pn  phantomjs   

-- no debconf information

Bug#972213: boost1.71: Please indicate some way which python versions you support

[Alastair McKinstry]

On 15/10/2020 08:13, Giovanni Mascellani wrote:


Hi,

Il 14/10/20 15:52, Alastair McKinstry ha scritto:

I maintain the package "ecflow" which uses libboost-python-dev. Now
with the transition to python3.9, ecflow will support (where
possible) multiple python versions. Currently it supports python3.8
but not python3.9 ; this may be fixed in a binNMU or next version,
but I cannot tell whether my failure to build python3.9 support for
ecflow is due to missing py3.9 support in boost, or a bug in my
packaging.

BTW, a binNMU was just requested to add Python 3.9 support.


Can some mechanism be added to enable tracability ?

In general, Boost supports all the Python versions currently supported
by the Python team, except that someone has to file a binNMU for them to
appear once a new Python version is packaged. To check which Python
versions are supported by a specific package version, it is enough to
check the content of the libboost-python1.71.0 package (replace 1.71.0
with future versions where applicable):

$ dpkg -L libboost-python1.71.0 | grep libboost_python
/usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0
/usr/lib/x86_64-linux-gnu/libboost_python39.so.1.71.0

(until yesterday you did not have the python39 variant)

Does this answer your question?

Giovanni.


Not really. This is probably better discussed on debian-python.

The point was that there is a lack of a good mechanism to see which 
packages provide py39 support, etc.


In principle my package ecflow just needs a rebuild after the boost is 
rebuilt, but tracking if this actually works, or add a particular 
dependency to enable automatic rebuild/tracking.


Alastair

--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#972255: transition: postgresql-common/221

[Sebastian Ramacher]

Hi Christoph

On 2020-10-15 12:34:43 +0200, Christoph Berg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I think I have put everything in place that needs to be done to have
> postgresql-common/221 migrate to testing, which makes the switch from
> PostgreSQL 12 to 13 as the "supported" version concerning extension
> module packages.
> 
> In the first round of extension I uploaded everything that was listed
> as regression on the postgresql-common excuses page.
> 
> https://qa.debian.org/excuses.php?package=postgresql-common
> 
> Remaining issues listed there are:
> 
> autopkgtest for check-postgres/2.25.0-1: amd64: Pass, arm64: Pass, armhf: 
> Regression ♻ (reference ♻), i386: Pass
> 
> -> The testsuite is flaky and the armhf problem hopefully goes away by
> retrying (I already clicked the button). In any case, the regression
> is test-only.
> 
> autopkgtest for gvmd/9.0.1-4: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> 
> -> Fixed in -4.1 in unstable
> 
> autopkgtest for osm2pgrouting/2.3.6-1: amd64: Regression ♻ (reference ♻), 
> arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> 
> -> I believe I fixed that in -2 in unstable, but debci is currently
> still picking up the old postgis packages from unstable for the test.
> In any case, the regression is test-only.
> 
> autopkgtest for omnidb/2.17.0+ds-2: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> autopkgtest for pg-checksums/1.0-3: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> autopkgtest for pgtap/1.1.0-2: amd64: Regression ♻ (reference ♻), arm64: 
> Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻)
> 
> -> I added Breaks: for these in the last postgresql-common upload, the
> issues are all fixed in unstable. (But the packages can only
> transition along with postgresql-common.)
> 
> autopkgtest for postgresql-multicorn/1.4.0-2: amd64: Regression ♻ (reference 
> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), 
> i386: Regression ♻ (reference ♻)
> 
> -> The only real problem, upstream has not yet released a fix for PG13
> yet. Please remove postgresql-multicorn/1.4.0-2 from testing so we can
> proceed.
> 
> (I have probably missed a few "not built on buildd" blockers on some of
> the extension packages. Please schedule binnmus there, thanks.)
> 
> So, in summary: please
> * remove postgresql-multicorn/1.4.0-2 from testing

Removal hint added. Could you please file an RC bug against
postgresql-multicorn so that once removed from testing britney doesn't
try to migrate?

Cheers

> * unblock postgresql-common/221
> 
> Thanks,
> Christoph
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#972283: graphite-web: saving graphs in dashboard is broken (targets are html escaped)

[Philip J Freeman]

Package: graphite-web
Version: 1.1.4-3+deb10u1.1
Severity: important
Tags: patch

Dear Maintainer,

 Saving and recalling user graphs doesn't work. This has been fixed upstream:

https://github.com/graphite-project/graphite-web/pull/2587

 I was able to rebuild the package with the two patches in above PR to fix
locally.

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

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

Versions of packages graphite-web depends on:
ii  adduser 3.118
ii  python  2.7.16-1
ii  python3 3.7.3-1
ii  python3-cairo   1.16.2-1+b1
ii  python3-cairocffi   0.7.2-2.2
ii  python3-django  1:1.11.29-1~deb10u1
ii  python3-django-tagging  1:0.4.5-1
ii  python3-pyparsing   2.2.0+dfsg1-2
ii  python3-simplejson  3.16.0-1
ii  python3-six 1.12.0-1
ii  python3-tz  2019.1-1
ii  python3-urllib3 1.24.1-1
ii  python3-whisper 1.1.4-2

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
ii  graphite-carbon  1.1.4-2
ii  libapache2-mod-wsgi-py3  4.6.5-1
pn  python3-ldap 
pn  python3-memcache 
pn  python3-mysqldb  

-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]

-- no debconf information
>From 0a3e6348d25f289982ae30958375b85cdf219be3 Mon Sep 17 00:00:00 2001
From: Pierce Lopez 
Date: Tue, 14 Apr 2020 02:45:03 -0400
Subject: [PATCH] composer: fix user saved graphs target escaping

saved graphs targets were html-escaped in the json response
to fix an XSS vulnerability in graphite-project/graphite-web#1662

... but that was not really the right place to escape the graph targets,
it broke targets using quotes: #1801 #2334

so effectively revert the original fix, and instead html-escape the
targets just before rendering them in the GraphDataWindow Ext.ListView

also skip the `str()` around `graph.url`, it's already a string,
in both python2 and python3
---
 webapp/content/js/composer_widgets.js |  9 -
 webapp/graphite/browser/views.py  | 29 ++-
 2 files changed, 10 insertions(+), 28 deletions(-)

diff --git a/webapp/content/js/composer_widgets.js 
b/webapp/content/js/composer_widgets.js
index e1ce36c7..ac7cc3b8 100644
--- a/webapp/content/js/composer_widgets.js
+++ b/webapp/content/js/composer_widgets.js
@@ -515,7 +515,14 @@ var GraphDataWindow = {
   hideHeaders: true,
   width: 385,
   height: 140,
-  columns: [ {header: 'Graph Targets', width: 1.0, dataIndex: 'value'} ],
+  columns: [
+{
+  header: 'Graph Targets',
+  width: 1.0,
+  dataIndex: 'value',
+  tpl: '{value:htmlEncode}'
+}
+  ],
   listeners: {
 contextmenu: this.targetContextMenu,
 afterrender: this.targetChanged,
diff --git a/webapp/graphite/browser/views.py b/webapp/graphite/browser/views.py
index 3bc9dc9c..223a76af 100644
--- a/webapp/graphite/browser/views.py
+++ b/webapp/graphite/browser/views.py
@@ -24,7 +24,6 @@ from graphite.user_util import getProfile, 
getProfileByUsername
 from graphite.util import json
 from graphite.logger import log
 from hashlib import md5
-from six.moves.urllib.parse import urlencode, urlparse, parse_qsl
 
 
 def header(request):
@@ -138,19 +137,7 @@ def myGraphLookup(request):
   else:
 m = md5()
 m.update(name.encode('utf-8'))
-
-# Sanitize target
-urlEscaped = str(graph.url)
-graphUrl = urlparse(urlEscaped)
-graphUrlParams = {}
-graphUrlParams['target'] = []
-for param in parse_qsl(graphUrl.query):
-  if param[0] != 'target':
-graphUrlParams[param[0]] = param[1]
-  else:
-graphUrlParams[param[0]].append(escape(param[1]))
-urlEscaped = graphUrl._replace(query=urlencode(graphUrlParams, 
True)).geturl()
-node.update( { 'id' : str(userpath_prefix + m.hexdigest()), 'graphUrl' 
: urlEscaped } )
+node.update( { 'id' : str(userpath_prefix + m.hexdigest()), 'graphUrl' 
: graph.url } )
 node.update(leafNode)
 
   nodes.append(node)
@@ -237,22 +224,10 @@ def userGraphLookup(request):
   m = md5()
   m.update(nodeName.encode('utf-8'))
 
-  # Sanitize target
-  urlEscaped = str(graph.url)
-  graphUrl = urlparse(urlEscaped)
-  graphUrlParams = {}
-  graphUrlParams['target'] = []
-  for param in parse_qsl(graphUrl.query):
-if param[0] != 'target':
-  graphUrlParams[param[0]] = param[1]
-else:
-  

Bug#972282: libllvm10: libllvm has different version, i386 is newer, then amd64, due to synaptic.

[Stefan_Schröder]

Package: libllvm10
Version: 1:10.0.1-6
Severity: minor
X-Debbugs-Cc: stefan_schroe...@kabelmail.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

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

Versions of packages libllvm10 depends on:
ii  libc6   2.31-3
ii  libedit23.1-20191231-1
ii  libffi7 3.3-4
ii  libgcc-s1   10.2.0-13
ii  libstdc++6  10.2.0-13
ii  libtinfo6   6.2+20200918-1
ii  libz3-4 4.8.9-1
ii  zlib1g  1:1.2.11.dfsg-2

libllvm10 recommends no packages.

libllvm10 suggests no packages.

-- no debconf information

Bug#972281: linux-source-5.8: Fails to compile with no LKMs if no Module.symvers

[John Talbut]

Package: linux-source-5.8
Version: 5.8.10-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the
past)

When compiling a static kernel (i.e. with no LKMs), which I have done
many times before, deb-pkg fails after the compiling has finished unless
the file Module.symvers is present in the source directory.  It does not
matter if the file is empty, which it will be if no modules are being used.

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

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

Versions of packages linux-source-5.8 depends on:
ii  binutils  2.35.1-1
ii  xz-utils  5.2.4-1+b1

Versions of packages linux-source-5.8 recommends:
ii  bc1.07.1-2+b2
ii  bison 2:3.7.2+dfsg-1
ii  flex  2.6.4-8
ii  gcc   4:10.2.0-1
ii  libc6-dev [libc-dev]  2.31-3
pn  linux-config-5.8  
ii  make  4.3-4

Versions of packages linux-source-5.8 suggests:
ii  libncurses-dev [ncurses-dev]  6.2+20200918-1
pn  pkg-config
pn  qtbase5-dev   

-- no debconf information

Bug#967954: [Pkg-rust-maintainers] Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

On Thu 2020-10-15 14:51:45 -0400, Daniel Kahn Gillmor wrote:
> Judging by a conversation on #debian-buildd, that seems to be correct
> (though there are of course many other ways for non-determinism to
> potentially sneak in, not least of which are different versions of
> build-deps).

another commentator on #debian-buildd noted that alternative
build-depends are considered for backports.  So maybe there are grounds
for considering alternative build-deps on buildd infra elsewhere if we
carve the exception with a clear enough line?

I don't know how to do that, though.

  --dkg


signature.asc
Description: PGP signature

Bug#972198: marked as done (ecflow b-d's on python3-all-dev, but only builds for the default python3 version)

[Alastair McKinstry]

Hi

boost-python was updated overnight, so I did a rebuild of ecflow and it 
now supports both py3.8 and py3.9


Alastair

On 14/10/2020 17:51, Debian Bug Tracking System wrote:

Your message dated Wed, 14 Oct 2020 16:48:58 +
with message-id 
and subject line Bug#972198: fixed in ecflow 5.5.3-2
has caused the Debian Bug report #972198,
regarding ecflow b-d's on python3-all-dev, but only builds for the default 
python3 version
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)



--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#966373: general: Higher version for uploads to stable and oldstable distributions

[Javier Serrano Polo]

On Sat, 10 Oct 2020 09:00:48 +0100 "Adam D. Barratt"  wrote:
> This has nothing specifically to do with updates to stable, and
> changing the versioning used for source updates to stable will not
> change it. If stable released with version 1.0-1 of package foo, then
> it is entirely feasible that a binNMU will be required at some point,
> and that will be versioned as 1.0-1+b1.

Please make up your mind. If you are not interested in knowing the
problem with 1-1+b1foo1 and 1-1+b1foo1+b1, then stop with the
"ugliness" stuff.

> It also conflicts with your original claims that you were trying to
> avoid having a stable update - which would be a source change

When did I say such a thing?
 
> There are two choices for the derivative when making source changes.

There are two patterns:

   1. binNMU
   2. stable update

Thus, there are three choices:

   1. Before binNMU (case 1.0-1deriv1).
   2. After stable update (case 1.0-1+deriv1).
   3. Between binNMU and stable update. This is what I am asking for.

Would you agree to preserve this third choice if it is currently
feasible?

smime.p7s
Description: S/MIME cryptographic signature

Bug#967954: [Pkg-rust-maintainers] Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

On Wed 2020-08-12 13:59:05 +0100, peter green wrote:
> It has been said in the past by the release team that the current
> autobuilder behaviour of only considering the first option for a
> build-dependency is by design to improve the determinism of the
> autobuilding process. I don't think you will persuade them to change
> it.

Judging by a conversation on #debian-buildd, that seems to be correct
(though there are of course many other ways for non-determinism to
potentially sneak in, not least of which are different versions of
build-deps).

> The proper fix IMO would be to add support for version ranges to
> dependencies in dpkg

I agree that this seems promising -- we'd then need to have debcargo
unwind a bunch of its extensive Provides: tags to take advantage of it,
but that doesn't sound too ugly.  it's possible that introducing ranges
into build-dependencies would be a problem for dpkg for other reasons
though.  I'm Cc'ing Guillem here to see whether he has any thoughts on
the matter.

For the purposes of resolving #967954, we really only need to worry
about ranged dependencies in the build-depends, not in any of the other
dependency fields (though obviously if it's simpler to do ranges across
all of them then that's fine too).

> but even if you can get the dpkg developers to agree to do that it
> would not be a quick solution as any change to dependency metadata
> takes a long time to trickle down to the many tools used in Debian.

I don't care so much about how long it takes as long as we're moving in
the right direction.  If it takes two years, the best to start doing
this change is two years ago.  the second best time is the present :P

 --dkg


signature.asc
Description: PGP signature

Bug#972280: Libreoffice: when adwaita-dark controls used, buttons are not visible anymore

[Pavlos Ponos]

Here comes the screenshot:

[image: image.png]


-- 
*Pavlos Ponos*

Visit my Linkedin  profile and my
blog 



*Privacy isn't about hiding bad things. It's about protecting what defines
us as human beings.*

* Protect yourself by using TOR browser ,
OpenPGP encryption , Jitsi Meet
 & Signal  Save your money
by using a Linux distro  & an open-source Office
suite *



On Thu, Oct 15, 2020 at 9:51 PM Pavlos Ponos  wrote:

> Package: libreoffice
> Version: 1:7.0.2-2
> Severity: important
> X-Debbugs-Cc: pavlos.po...@gmail.com
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.8.0-2-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>
> Hello,
>
> When using adwaita-dark controls, buttons for text formatting are not
> visible anymore. When switching back to debian's default, everyt>
>
> Please consider adjusting buttons when black themes used, otherwise it's
> almost impossible to find the button you are looking for.
>
> Screenshot to follow.
>
> Thanks.
> Pavlos Ponos
>
>
> Versions of packages libreoffice depends on:
> ii  libreoffice-base1:7.0.2-2
> ii  libreoffice-calc1:7.0.2-2
> ii  libreoffice-core1:7.0.2-2
> ii  libreoffice-draw1:7.0.2-2
> ii  libreoffice-impress 1:7.0.2-2
> ii  libreoffice-math1:7.0.2-2
> ii  libreoffice-report-builder-bin  1:7.0.2-2
> ii  libreoffice-writer  1:7.0.2-2
> ii  python3-uno 1:7.0.2-2
>
> Versions of packages libreoffice recommends:
> ii  fonts-crosextra-caladea 20130214-2
> ii  fonts-crosextra-carlito 20130920-1
> ii  fonts-dejavu2.37-2
> ii  fonts-liberation1:1.07.4-11
> ii  fonts-liberation2   2.1.1-1
> ii  fonts-linuxlibertine5.3.0-4
> pn  fonts-noto-core 
> pn  fonts-noto-extra
> pn  fonts-noto-mono 
> pn  fonts-noto-ui-core  
> ii  fonts-sil-gentium-basic 1.102-1
> ii  libreoffice-java-common 1:7.0.2-2
> ii  libreoffice-nlpsolver   0.9+LibO7.0.2-2
> ii  libreoffice-report-builder  1:7.0.2-2
> ii  libreoffice-script-provider-bsh 1:7.0.2-2
> ii  libreoffice-script-provider-js  1:7.0.2-2
> ii  libreoffice-script-provider-python  1:7.0.2-2
> ii  libreoffice-sdbc-mysql  1:7.0.2-2
> ii  libreoffice-sdbc-postgresql 1:7.0.2-2
> ii  libreoffice-wiki-publisher  1.2.0+LibO7.0.2-2
>
> Versions of packages libreoffice suggests:
> pn  cups-bsd
> ii  default-jre [java8-runtime] 2:1.11-72
> ii  firefox-esr 78.3.0esr-2
> ii  ghostscript 9.52.1~dfsg-1
> ii  gnupg   2.2.20-1
> pn  gpa 
> ii  gstreamer1.0-libav  1.18.0-1
> ii  gstreamer1.0-plugins-bad1.18.0-2+b1
> ii  gstreamer1.0-plugins-base   1.18.0-2
> ii  gstreamer1.0-plugins-good   1.18.0-1
> ii  gstreamer1.0-plugins-ugly   1.18.0-1
> ii  hunspell-el [hunspell-dictionary]   1:7.0.1-1
> ii  hunspell-en-us [hunspell-dictionary]1:2019.10.06-1
> ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
> pn  imagemagick | graphicsmagick-imagemagick-compat 
> ii  libgl1  1.3.2-1
> pn  libofficebean-java  
> pn  libreoffice-gnome | libreoffice-plasma  
> pn  libreoffice-grammarcheck
> ii  libreoffice-help-en-us [libreoffice-help]   1:7.0.2-2
> pn  libreoffice-l10n
> pn  libreoffice-librelogo   
> pn  libsane1
> ii  libxrender1 1:0.9.10-1
> pn  myspell-dictionary  
> ii  mythes-en-us [mythes-thesaurus] 1:7.0.1-1
> pn  openclipart2-libreoffice | openclipart-libreoffice  

Bug#954794: New packages must not declare themselves Essential

[Jonathan Nieder]

Javier Serrano Polo wrote:
> On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder 
> wrote:

>> Even so, some *rough* consensus on the plan is very useful for
>> helping people evaluate that first step.
>
> Here is a rough plan:
>
>1. Policy: Packages should declare all their dependencies, even
>   essential ones.

I agree: this is the right first step.

More specifically, it's the right first three steps.

https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies
currently says

Packages are not required to declare any dependencies they
have on other packages which are marked Essential (see below),
and should not do so unless they depend on a particular
version of that package.[4]

[4] [...] If packages add unnecessary dependencies on packages
in this set, the chances that there will be an unresolvable
dependency loop caused by forcing these Essential packages to
be configured first before they need to be is greatly
increased.

I'd propose that as a first step we change that to

Packages are not required to declare any dependencies they
have on other packages which are marked Essential (see below),
but are permitted to do so even if they do not depend on a
particular version of that package.[4]

[4] Functionality is rarely ever removed from the Essential
set, but packages have been removed from the Essential set
when the functionality moved to a different package. So when
depending on these packages for such functionality, it is
recommended to depend on an appropriate virtual package
instead.

Future versions of Debian policy may encourage and then
require including explicit dependencies even for essential
functionality. This is helpful to users putting together
ultra-minimal systems (though Debian does not support omitting
Essential functionality out of the box), and it means less
work is required in case the moment comes to remove some
functionality from the Essential set in the future.

(The next two steps would be to change that from "are permitted" to
"should", and then to "must".)

What do you think?

Thanks,
Jonathan

[4] "Essential is needed in part to avoid unresolvable dependency loops
on upgrade. If packages add unnecessary dependencies on packages in
this set, the chances that there will be an unresolvable dependency
loop caused by forcing these Essential packages to be configured first
before they need to be is greatly increased. It also increases the
chances that frontends will be unable to calculate an upgrade path,
even if one exists.

"Also, functionality is rarely ever removed from the Essential set, but
packages have been removed from the Essential set when the
functionality moved to a different package. So depending on these
packages just in case they stop being essential does way more harm
than good."

Bug#972280: Libreoffice: when adwaita-dark controls used, buttons are not visible anymore

[Pavlos Ponos]

Package: libreoffice
Version: 1:7.0.2-2
Severity: important
X-Debbugs-Cc: pavlos.po...@gmail.com



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

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


Hello,

When using adwaita-dark controls, buttons for text formatting are not visible 
anymore. When switching back to debian's default, everyt>

Please consider adjusting buttons when black themes used, otherwise it's almost 
impossible to find the button you are looking for.

Screenshot to follow.

Thanks.
Pavlos Ponos


Versions of packages libreoffice depends on:
ii  libreoffice-base1:7.0.2-2
ii  libreoffice-calc1:7.0.2-2
ii  libreoffice-core1:7.0.2-2
ii  libreoffice-draw1:7.0.2-2
ii  libreoffice-impress 1:7.0.2-2
ii  libreoffice-math1:7.0.2-2
ii  libreoffice-report-builder-bin  1:7.0.2-2
ii  libreoffice-writer  1:7.0.2-2
ii  python3-uno 1:7.0.2-2

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.1-1
ii  fonts-linuxlibertine5.3.0-4
pn  fonts-noto-core 
pn  fonts-noto-extra
pn  fonts-noto-mono 
pn  fonts-noto-ui-core  
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:7.0.2-2
ii  libreoffice-nlpsolver   0.9+LibO7.0.2-2
ii  libreoffice-report-builder  1:7.0.2-2
ii  libreoffice-script-provider-bsh 1:7.0.2-2
ii  libreoffice-script-provider-js  1:7.0.2-2
ii  libreoffice-script-provider-python  1:7.0.2-2
ii  libreoffice-sdbc-mysql  1:7.0.2-2
ii  libreoffice-sdbc-postgresql 1:7.0.2-2
ii  libreoffice-wiki-publisher  1.2.0+LibO7.0.2-2

Versions of packages libreoffice suggests:
pn  cups-bsd
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox-esr 78.3.0esr-2
ii  ghostscript 9.52.1~dfsg-1
ii  gnupg   2.2.20-1
pn  gpa 
ii  gstreamer1.0-libav  1.18.0-1
ii  gstreamer1.0-plugins-bad1.18.0-2+b1
ii  gstreamer1.0-plugins-base   1.18.0-2
ii  gstreamer1.0-plugins-good   1.18.0-1
ii  gstreamer1.0-plugins-ugly   1.18.0-1
ii  hunspell-el [hunspell-dictionary]   1:7.0.1-1
ii  hunspell-en-us [hunspell-dictionary]1:2019.10.06-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
pn  imagemagick | graphicsmagick-imagemagick-compat 
ii  libgl1  1.3.2-1
pn  libofficebean-java  
pn  libreoffice-gnome | libreoffice-plasma  
pn  libreoffice-grammarcheck
ii  libreoffice-help-en-us [libreoffice-help]   1:7.0.2-2
pn  libreoffice-l10n
pn  libreoffice-librelogo   
pn  libsane1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:7.0.1-1
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-11-jre [java8-runtime]  11.0.8+10-1
ii  openjdk-14-jre [java8-runtime]  14.0.2+12-1.1
pn  pstoedit
ii  thunderbird 1:68.12.0-1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.2-2
ii  libboost-locale1.71.0   1.71.0-6+b2
ii  libc6   2.31-3
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-2+b1
ii  libcups22.3.3-3
ii  libcurl3-gnutls 7.72.0-1
ii  libdbus-1-3 1.12.20-1
ii  libdconf1   0.38.0-1
ii  libeot0 0.01-5+b1

Bug#972279: RM: postgresql-12-postgis-3-scripts postgresql-12-postgis-3 -- NBS; postgresql-13 transition

[Christoph Berg]

Package: ftp.debian.org
Severity: normal

Hi,

please decruft on unstable:

postgresql-12-postgis-3-scripts
postgresql-12-postgis-3

and on experimental:

postgresql-12-postgis-3-scripts

Thanks,
Christoph

Bug#954794: New packages must not declare themselves Essential

[Javier Serrano Polo]

On Wed, 07 Oct 2020 18:43:22 -0400 Sam Hartman 
wrote:
> C) I'd support non-normative documentation that we don't expect to
> approve new essential packages in the future in policy.

Worthless documentation, I think.

> A) I do support reducing the essential set over time

Fine, then you should choose one essential package and remove it from
the set for bullseye or bookworm.

smime.p7s
Description: S/MIME cryptographic signature

Bug#972278: transition: qtbase-opensource-src

[Dmitry Shachnev]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 957436 972154 972155 972156 972157 972158 972160 972175 
972176 972177 972178 972179

Dear Release team,

We the Qt maintainers would like to request a transition for Qt 5.15.1.
There are currently some blockers, but I hope we will get them sorted out
within a couple of weeks.

In the mean time, please set up a tracker.

Here is the ben file that is based on one from the previous transition:
https://salsa.debian.org/release-team/transition-data/-/blob/master/old/qtbase-abi-5-15-1.ben

title = "qtbase-opensource-src and qtdeclarative-opensource-src";
is_affected = .depends ~ "qtdeclarative-abi-5-14-2" | .depends ~ 
"qtdeclarative-abi-5-15-1" | .depends ~ "qtbase-abi-5-14-2" | .depends ~ 
"qtbase-abi-5-15-1";
is_good = .depends ~ "qtbase-abi-5-15-1" | .depends ~ 
"qtdeclarative-abi-5-15-1";
is_bad = .depends ~ "qtbase-abi-5-14-2" | .depends ~ "qtdeclarative-abi-5-14-2";

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#967954: debcargo: generated ranged build-deps result in "BD-uninstallable" on debian buildd network

[Daniel Kahn Gillmor]

Just to clarify why this is a concern:

 - this behavior on the buildds is deliberate.  It's an explicit
   feature of sbuild.

 - it is intended to ensure more-deterministic builds

 - it is also mentioned in debian-policy, in the first footnote of §7.1:

>While Build-Depends, Build-Depends-Indep and Build-Depends-Arch
>permit the use of alternative dependencies, these are not normally
>used by the Debian autobuilders. To avoid inconsistency between
>repeated builds of a package, the autobuilders will default to
>selecting the first alternative, after reducing any
>architecture-specific restrictions for the build architecture in
>question. While this may limit the usefulness of alternatives in a
>single release, they can still be used to provide flexibility in
>building the same package across multiple distributions or releases,
>where a particular dependency is met by differently named packages.

So in practice, any Cargo.toml dependency range that has an upper bound
will be converted by debcargo to a disjunction in the Build-Depends.
This disjunction will be interpreted by sbuild as "the most recent
version before the upper bound".

This results in unnecessary FTBFS when the build-dep is in debian, but
the most recent version before the upper bound is not yet in debian.

I will probably be working around this by patching Cargo.toml files so
that the generated disjunction targets the version of the dependency
that is in debian unstable, but it's an ugly thing to need to do.

I'm at a loss for how to address this, or what debcargo *should* do to
make the situation better. ☹

--dkg


signature.asc
Description: PGP signature

Bug#935115: passing variable assignments to functions (was Re: Bug#935115: bash: [regression] passing variable assignments to functions broken in POSIX mode, violating POSIX)

[Usama Makhzoum]

looks like it has been fixed, i can't reproduce in either unstable, 
testing or stable by the moment of now.

Bug#972277: sensors-applet: Install the gnome-panel module in multi-arch location

[Dmitry Shachnev]

Package: sensors-applet
Version: 3.0.0+git6-0.4
Severity: serious
Justification: fails to build from source with gnome-panel 3.38
Tags: ftbfs patch pending

Dear Maintainer,

In gnome-panel 3.37.1, I enabled multi-arch support [1]. So the modules are
now installed into multi-arch location. Today the new stable release (3.38.0)
was released, and I uploaded it to unstable.

I added Breaks against some packages, including sensors-applet, so a new
upload will be needed to let gnome-panel migrate to testing.

I have uploaded the attached patch to DELAYED/2 queue. I have already done
some NMUs for this package, so I hope you won't mind another one.

[1]: 
https://tracker.debian.org/news/1145753/accepted-gnome-panel-3371-1-source-into-experimental/

--
Dmitry Shachnev
diff -Nru sensors-applet-3.0.0+git6/debian/changelog sensors-applet-3.0.0+git6/debian/changelog
--- sensors-applet-3.0.0+git6/debian/changelog	2020-06-05 13:18:41.0 +0300
+++ sensors-applet-3.0.0+git6/debian/changelog	2020-10-15 20:44:32.0 +0300
@@ -1,3 +1,11 @@
+sensors-applet (3.0.0+git6-0.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install libsensors-applet.so in multi-arch location, for compatibility
+with gnome-panel 3.38 (closes: #-1).
+
+ -- Dmitry Shachnev   Thu, 15 Oct 2020 20:44:32 +0300
+
 sensors-applet (3.0.0+git6-0.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sensors-applet-3.0.0+git6/debian/sensors-applet.install sensors-applet-3.0.0+git6/debian/sensors-applet.install
--- sensors-applet-3.0.0+git6/debian/sensors-applet.install	2020-06-05 13:18:41.0 +0300
+++ sensors-applet-3.0.0+git6/debian/sensors-applet.install	2020-10-15 20:44:32.0 +0300
@@ -1,3 +1,3 @@
-usr/lib/gnome-panel/modules/libsensors-applet.so
+usr/lib/*/gnome-panel/modules/libsensors-applet.so
 usr/lib/*/sensors-applet/plugins/*.so
 usr/share


signature.asc
Description: PGP signature

Bug#972276: RFS: olive-editor/20200620-1 -- Professional open-source NLE video editor

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "olive-editor":

 * Package name: olive-editor
   Version : 20200620-1
   Upstream Author : Olive Team
 * URL : https://www.olivevideoeditor.org/
 * License : GPL-3+, MIT
 * Vcs : 
https://salsa.debian.org/multimedia-team/olive-editor

   Section : video

It builds those binary packages:

  olive-editor - Professional open-source NLE video editor

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


  https://mentors.debian.net/package/olive-editor/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/o/olive-editor/olive-editor_20200620-1.dsc


Changes since the last upload:

 olive-editor (20200620-1) unstable; urgency=medium
 .
   * New upstream version.

Regards,
--
  Gürkan Myczko

Bug#972174: s3fs segfault

[Noah Meyerhans]

The relevant stack trace seems to be

(gdb) bt
#0  tcache_get (tc_idx=19) at malloc.c:2934
#1  __GI___libc_malloc (bytes=328) at malloc.c:3042
#2  0x7f30c226cfd8 in operator new(unsigned long) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x55fffc60472e in FdManager::Open (this=0x55fffc62fa60 
, path=path@entry=0x7f30882b5000 
"/noahm/files_encryption/OC_DEFAULT_MODULE/noahm.publicKey", 
pmeta=pmeta@entry=0x7f30ad7f9800, size=800, time=1602314388, 
force_tmpfile=force_tmpfile@entry=false, is_create=true, no_fd_lock_wait=false) 
at /usr/include/c++/8/bits/basic_string.h:2290
#4  0x55fffc5c0e34 in s3fs_open (path=0x7f30882b5000 
"/noahm/files_encryption/OC_DEFAULT_MODULE/noahm.publicKey", fi=0x7f30ad7f9ab0) 
at fdcache.h:208
#5  0x7f30c286d910 in fuse_fs_open () from 
/lib/x86_64-linux-gnu/libfuse.so.2
#6  0x7f30c286da16 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#7  0x7f30c2877dc4 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#8  0x7f30c28770b8 in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#9  0x7f30c2873d5c in ?? () from /lib/x86_64-linux-gnu/libfuse.so.2
#10 0x7f30c2021fa3 in start_thread (arg=) at 
pthread_create.c:486
#11 0x7f30c1f524cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

The code around s3fs_open has changed quite a bit since the version in
buster was released.  I'll work on testing a backport of the bullseye
version on buster to test this.  Given the amount of code churn, I'm
skeptical that we'll be able to isolate an easily backportable fix, but
we'll see.

noah

Bug#972218: depends on liblocale-codes-perl

[Niko Tyni]

On Thu, Oct 15, 2020 at 07:05:04PM +0200, Jeff wrote:
> On 15/10/2020 12:52, Niko Tyni wrote:
> > So it should only happen for systems upgraded from stretch. A
> > workaround for gscan2pdf could be to declare a versioned dependency on
> > liblocale-codes-perl (>= 3.60) or something like that so it wouldn't be
> > satisfied by the old perl-modules-5.24.
> > 
> > Not sure if we should make perl in sid/bullseye Break perl-modules-5.24.
> > I'd prefer to keep them coinstallable but I can't see any other generic
> > fix.
> 
> If you don't have a generic fix in time for the next gscan2pdf release
> in around ten days, I'll use your workaround. Thanks for the suggestion.
> 
> Would you like me to duplicate the bug so that it doesn't get forgotten?

Sure, please do. Thanks for bringing this up.
-- 
Niko

Bug#968912: transition: perl 5.32

[Niko Tyni]

On Sun, Aug 23, 2020 at 07:25:19PM +0100, Dominic Hargreaves wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-p...@lists.debian.org
> 
> Hi, perl 5.32 has been in experimental since June and I think it's going
> to be ready for sid/bullseye within the next month or so - this is the
> version we expect to ship with bullseye (given the freeze in January).
> 
> The main blockers at present are the perl-tk update (I've just
> pinged #960863) and, indirectly, the ipv6-only build related problems
> described in #964902.

These are resolved now, and all known regressions found in our test
rebuilds are marked as blocking this bug.

The libpod-parser-perl dependencies are trivial to add.

There's no fix for libdata-alias-perl, and I expect we'll need to remove
it from testing. It's just an optional dependency for other packages
AFAICS, so I don't expect much fallout (as long as the build dependencies
are relaxed in libio-stream-perl and libmethod-signatures-perl first.)

Could we raise the remaining bugs to 'serious' now? Do you have any
guesstimate on the timing for a transition slot?

Thanks for your work,
-- 
Niko Tyni   nt...@debian.org

Bug#942290: libbpfcc: libbcc_bpf.so: needs to link with -lelf

[Ritesh Raj Sarraf]

Dear Vasudev,

If you have some spare cycles for bpfcc, it could use your help.

Thanks,
Ritesh

On Thu, 2020-10-15 at 08:50 +0800, Paul Wise wrote:
> Package: libbpfcc
> Version: 0.16.0-2+b1
> Followup-For: Bug #942290
> Control: retitle -1 libbpfcc: libbcc_bpf.so: needs to link with -lelf
> and -lz
> 
> The same issue now also applies to libz:
> 
> $ lib=/usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.16.0
> $ link=/lib/x86_64-linux-gnu/libz.so.1.2.11
> $ pkg="$(dpkg-query --search "$lib" | sed s/:.*//)"
> $ src="$(grep-aptavail --no-field-names --show-field Source:Package
> --field Package --exact-match --pattern "$pkg" | sed 's/ .*//')"
> $ first="$(printf '%s' "$src" | head --bytes 1)"
> 
> $ adequate "$pkg" | grep -v elf
> libbpfcc: undefined-symbol /usr/lib/x86_64-linux-
> gnu/libbcc_bpf.so.0.16.0 => gzclose
> libbpfcc: undefined-symbol /usr/lib/x86_64-linux-
> gnu/libbcc_bpf.so.0.16.0 => gzgets
> libbpfcc: undefined-symbol /usr/lib/x86_64-linux-
> gnu/libbcc_bpf.so.0.16.0 => gzopen
> 
> $ lddtree "$lib"
> libbcc_bpf.so.0.16.0 => /usr/lib/x86_64-linux-
> gnu/libbcc_bpf.so.0.16.0 (interpreter => none)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-
> 64.so.2
> 
> $ symtree "$lib" 
> /usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.16.0
> libc.so.6 =>
> socket,__xpg_basename,fopen,strncmp,perror,__isoc99_sscanf,epoll_wait
> ,ftell,strncpy,time,__stack_chk_fail,unlink,mkdir,realloc,getpid,strd
> up,strtol,mmap,feof,fgets,calloc,strlen,send,memset,dirname,strstr,rm
> dir,__errno_location,bind,fseek,read,getpagesize,getsockopt,dup3,poll
> ,__fprintf_chk,recv,__isoc99_fscanf,memcpy,memcpy,fclose,fmemopen,fme
> mopen,setsockopt,malloc,__ctype_b_loc,stderr,ioctl,munmap,__snprintf_
> chk,__memset_chk,setrlimit,if_nametoindex,strtoull,__getdelim,if_inde
> xtoname,fwrite,fread,epoll_ctl,geteuid,statfs,__memcpy_chk,close,open
> ,strchr,getsockname,epoll_create1,__vfprintf_chk,qsort,accept,__strcp
> y_chk,__cxa_finalize,syscall,__xpg_strerror_r,__sprintf_chk,getrlimit
> ,memmove,uname,access,strcmp,strerror,write,snprintf,sysconf,realloca
> rray,free
> WEAK =>
> _ITM_deregisterTMCloneTable,__gmon_start__,_ITM_registerTMCloneTable
> UNRESOLVED =>
> gelf_getshdr,gzclose,elf_rawdata,gzgets,elf_getscn,elf_begin,gelf_get
> rel,elf_memory,elf_end,elf_strptr,elf_nextscn,gzopen,gelf_getehdr,elf
> _version,elf_getdata,gelf_getclass,gelf_getsym
> 
> $ objdump -T "$link" | grep -E " ($(symtree "$lib" | sed -n
> 's/UNRESOLVED => //p' | tr , '|'))$"
> 000127c0 gDF .text0160  Baseg
> zgets
> 0000 gDF .text0023  Baseg
> zclose
> 00011480 gDF .text000d  Baseg
> zopen
> 
> $ w3m -dump https://qa.debian.org/bls/packages/"$first"/"$src".html |
> grep -A2 symbol
>   • W shlibs-symbol-not-found (amd64, ppc64, ppc64el)
> 
> Found 3 issues.
> 
> $ chronic getbuildlog "$src" last
> $ grep 'dpkg-shlibdeps: warning: symbol .* used by .* found in none
> of the libraries' ./*.log | grep -v elf
> ./bpfcc_0.16.0-2+b1_amd64.log:dpkg-shlibdeps: warning: symbol gzopen
> used by debian/libbpfcc/usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.16.0 
> found in none of the libraries
> ./bpfcc_0.16.0-2+b1_amd64.log:dpkg-shlibdeps: warning: symbol gzclose
> used by debian/libbpfcc/usr/lib/x86_64-linux-gnu/libbcc_bpf.so.0.16.0 
> found in none of the libraries
> ./bpfcc_0.16.0-2+b1_ppc64el.log:dpkg-shlibdeps: warning: symbol
> gzgets used by debian/libbpfcc/usr/lib/powerpc64le-linux-
> gnu/libbcc_bpf.so.0.16.0 found in none of the libraries
> ./bpfcc_0.16.0-2+b1_ppc64el.log:dpkg-shlibdeps: warning: symbol
> gzclose used by debian/libbpfcc/usr/lib/powerpc64le-linux-
> gnu/libbcc_bpf.so.0.16.0 found in none of the libraries
> ./bpfcc_0.16.0-2+b1_ppc64.log:dpkg-shlibdeps: warning: symbol gzgets
> used by debian/libbpfcc/usr/lib/powerpc64-linux-
> gnu/libbcc_bpf.so.0.16.0 found in none of the libraries
> ./bpfcc_0.16.0-2+b1_ppc64.log:dpkg-shlibdeps: warning: symbol gzclose
> used by debian/libbpfcc/usr/lib/powerpc64-linux-
> gnu/libbcc_bpf.so.0.16.0 found in none of the libraries
> ./bpfcc_0.16.0-2+b1_ppc64.log:dpkg-shlibdeps: warning: symbol gzopen
> used by debian/libbpfcc/usr/lib/powerpc64-linux-
> gnu/libbcc_bpf.so.0.16.0 found in none of the libraries
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800,
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700,
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-
> experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
> LANGUAGE=en_AU:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libbpfcc 

Bug#935127: bash: please make the build reproducible

[Matthias Klose]

On 10/15/20 6:58 PM, Chris Lamb wrote:
> Hi Bash maintainers,
> 
>> Bash is one of the few remaining packages in the 'Essential' package
>> set that remains unreproducible, and this patch has been in the BTS
>> for over a year now.
> 
> So, there are now only two packages in the Essential set that are
> unreproducible. I plan to work on the other package (Perl) shortly,
> but having Bash fixed in the archive itself would be very welcome
> and motivating withal.

really?  No libgcc in the essential set? yes, it would be motivating if you
would address the GCC issues upstream and not keeping a set of local patches.

Bug#972275: libio-stream-perl: build-depends on libdata-alias-perl, incompatible with Perl 5.32

[Niko Tyni]

Source: libio-stream-perl
Version: 2.0.3-1
Severity: important
Tags: bullseye sid
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition
Control: block 968912 with -1

This package Recommends and Build-Depends-Indep on libdata-alias-perl, which
is broken with Perl 5.32 (#971969) and doesn't seem to be getting fixed.

The build dependency looks like it's optional, could we please drop it
so the relevant tests are just skipped?

Given the binary relation is just a recommendation, any packages using
the IO::Stream functionality provided by Data::Alias would
presumedly be marked as depending on both libio-stream-perl and
libdata-alias-perl. I don't see any such packages in sid so no other
packages should be affected AFAICS.
-- 
Niko Tyni   nt...@debian.org

Bug#972274: libmethod-signatures-perl: build-depends on libdata-alias-perl, incompatible with Perl 5.32

[Niko Tyni]

Source: libmethod-signatures-perl
Version: 20170211-1
Severity: important
Tags: bullseye sid
User: debian-p...@lists.debian.org
Usertags: perl-5.32-transition
Control: block 968912 with -1

This package Recommends and Build-Depends-Indep on libdata-alias-perl, which
is broken with Perl 5.32 (#971969) and doesn't seem to be getting fixed.

The build dependency looks like it's optional, could we please drop it
so the relevant tests are just skipped?

Given the binary relation is just a recommendation, any packages using
the Method::Signatures functionality provided by Data::Alias would
presumedly be marked as depending on both libmethod-signatures-perl and
libdata-alias-perl. I don't see any such packages in sid so no other
packages should be affected AFAICS.
-- 
Niko Tyni   nt...@debian.org

Bug#972218: depends on liblocale-codes-perl

[Jeff]

On 15/10/2020 12:52, Niko Tyni wrote:
> So it should only happen for systems upgraded from stretch. A
> workaround for gscan2pdf could be to declare a versioned dependency on
> liblocale-codes-perl (>= 3.60) or something like that so it wouldn't be
> satisfied by the old perl-modules-5.24.
> 
> Not sure if we should make perl in sid/bullseye Break perl-modules-5.24.
> I'd prefer to keep them coinstallable but I can't see any other generic
> fix.

If you don't have a generic fix in time for the next gscan2pdf release
in around ten days, I'll use your workaround. Thanks for the suggestion.

Would you like me to duplicate the bug so that it doesn't get forgotten?



signature.asc
Description: OpenPGP digital signature

Bug#935127: bash: please make the build reproducible

[Chris Lamb]

Hi Bash maintainers,

> Bash is one of the few remaining packages in the 'Essential' package
> set that remains unreproducible, and this patch has been in the BTS
> for over a year now.

So, there are now only two packages in the Essential set that are
unreproducible. I plan to work on the other package (Perl) shortly,
but having Bash fixed in the archive itself would be very welcome
and motivating withal.


Kind regards,

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

Bug#956591: gpick: please make the build reproducible

[Chris Lamb]

Hi Elías,

> > There hasn't seem to be any update on this bug in 149 days, in which
> > time the Reproducible Builds effort has come on a long way.
> > 
> > Would you consider applying this patch and uploading?
> > 
> I'd like to fix this bug. Could you please provide the entire workflow to
> reproduce this bug locally?. I was trying against salsa-ci reprotest but 
> it isn't the best way. I was also trying with the Newer method of reprotest
> and I've got a successfully message.

I don't actually use reprotest myself, so I can't help you specifically here. 
Probably best to contact the rb-gene...@lists.reproducible-builds.org mailing 
list.j


Regards,

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

Bug#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Gunnar Wolf]

Michael Biebl dijo [Wed, Oct 07, 2020 at 09:53:06PM +0200]:
> Forwarding this to the CTTE, just in case they have some input on this
> proposed plan.
> (...)
> A small update here:
> v246 provides a build switch -Dstandalone-binaries=true:
> (...)
> Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
> Those binaries do not link against libsystemd-shared and have minimal
> dependencies.
> (...)
> I like this approach and think we should do the same in Debian.
> Users, which have the full systemd package installed don't have any
> negative side effects, which could result from splitting out
> systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
> 
> Restricted/non-systemd environments, like containers, can use
> systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
> dependencies.
> (...)
> If there are no objections to this approach I would proceed and
> implement it like this:
> - Build systemd with -Dstandalone-binaries=true
> - Install the standalone binaries in binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles
> - Those binaries packages would only ship /bin/systemd-sysusers resp.
> /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd

This seems like a good solution for the issue in question, and does
not seem to have any ill effects. So, yes, I'd say go for it!

Regarding Wouter's point (having systemd Provide:
systemd-standalone-sysusers, systemd-standalone-tmpfiles), it looks
sensible, but it might break down in the future if many more such
cases are spotted. But, at least for now, it does make sense.


signature.asc
Description: PGP signature