date:20211013

Hi,

intrig...@debian.org (2020-10-25):
> Any objection to removing the package from testing & sid?

I've requested the removal of this package from sid: #996441.

Cheers!

Bug#996441: RM: libclutter-perl -- ROM; Deprecated upstream

Package: ftp.debian.org
Severity: normal

Hi,

The Perl bindings for Clutter have been deprecated upstream in December 2020.
For this reason, this package has not been in testing since November 2020,
and was not included in Bullseye.

Nobody objected, since I proposed it on 2020-10-25, to removing
the package from sid.

This is a leaf package with tiny popcon scores.

For details, see https://bugs.debian.org/972888

Thanks for your valuable work!

Bug#912178: muttprint: Please add homepage link to d/control

2021-10-13 Thread Petter Reinholdtsen



Control: tags -1 +patch

As the homepage link is still missing, perhaps a patch is needed to
solve this issue?  Also include a d/upstream/metadata file with some key
values.

diff --git a/debian/control b/debian/control
index 0806f4d..81c84d3 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Priority: optional
 Maintainer: Rene Engelhard 
 Build-Depends: debhelper (>= 9), imagemagick, ghostscript, docbook-utils, 
sharutils, dh-autoreconf, automake, autoconf, docbook
 Standards-Version: 3.6.2
+Homepage: http://muttprint.sourceforge.net/
 
 Package: muttprint
 Architecture: all
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..f05c737
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,6 @@
+Archive: SourceForge
+Contact: Lukas Ruf 
+CPE: cpe:/a:lukas_ruf:muttprint
+Bug-Database: https://sourceforge.net/p/muttprint/bugs/
+Repository: https://sourceforge.net/projects/muttprint/
+Repository-Browse: https://sourceforge.net/p/muttprint/code/HEAD/tree/

Rene, do you need a co-maintainer for this package?  I might be able to
help out a bit.  If so, what about maintaining it using gbp-buildpackage
under https://salsa.debian.org/debian >?

-- 
Happy hacking
Petter Reinholdtsen

Bug#996415: mark libnghttp2-dev Multi-Arch: same

2021-10-13 Thread Andrei POPESCU

Control: reassign -1 src:nghttp2 1.43.0-1

On Mi, 13 oct 21, 21:42:19, Helmut Grohne wrote:
> Source: libnghttp2-dev
> Version: 1.43.0-1

You probably meant "source of libnghttp2-dev" here, which is not 
supported by the BTS.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#996440: O: metche -- configuration monitor to ease collective administration

Package: wnpp
Severity: normal
Control: affects -1 src:metche

I intend to orphan the metche package.

The package description is:
 metche monitors changes made to a "system state" composed of:
- a "watched" directory (typically: /etc)
- one or more user maintained changelog files
  (e.g. /root/Changelog)
- the state of Debian packages and versions (using apt-show-versions)
 by periodically:
- saving backups of the corresponding files
- emailing the changes in the system state to your administrators'
  mailing list

For context and details, see https://bugs.debian.org/913719.

Cheers!

Bug#948701: Acknowledgement (ITP: libsqlitecpp -- smart and easy to use C++ SQLite3 wrapper)

2021-10-13 Thread Eduard Bloch

Control: retitle 948701 RFP: libsqlitecpp -- smart and easy to use C++ SQLite3 
wrapper

I lost the requirement for that package as of now, but it's still a
potentially good addition to Debian, IMHO.

Whoever cares, feel free to take over. The pre-packaged version at
https://github.com/Code7R/SQLiteCpp/tree/debian/sid might need an
update.

Bug#994495: filezilla/libfilezilla maintinance (Was: RFS: filezilla/3.55.1-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client)

2021-10-13 Thread Peter Michael Green

BTW Bastain, mails sent to n...@bugs.debian.org don't get automatically 
sent to bug submitters.


Bastian Germann Wrote:


Which team is that? I see Adrien Cunin as maintainer.


Good question!

It seems like for nearly two years, all of the uploads to filezilla and 
libfilezilla have been "team uploads"
despite Adrian Cunin being listed as the sole maintainer . Most of these 
uploads seem to have been

prepared by Phil Wyett and sponsorred by Gianfranco Costamagna.

The maintinance status of these packages needs to be clarified!

Bug#913719: Don't include metche in Buster

Hi,

intrig...@debian.org (2018-11-14):
> Unless upstream and package maintenance are taken over by July 2019,
> I'll orphan the package or request it to be removed from sid (I'm
> undecided yet, opinions welcome).

I'm going to orphan this package.

Cheers!

Bug#995907: 995907: patch

2021-10-13 Thread Andrius Merkys

Control: tags -1 + patch
Control: severity -1 important
X-Debbugs-CC: m...@debian.org

Dear Maintainer,

Please find attached a patch to fix libexpat1-dev in unstable. The patch
substitutes ${_IMPORT_PREFIX} (which is evaluated to '/usr/lib' in the
current layout) with hard-coded '/lib'.

I am raising the importance of this bug as it causes FTBFS in packages
using CMake to locate expat via 'find_package(expat ...)'.
Interestingly, the archive does not seem to contain such packages so far
[1].

[1] https://codesearch.debian.net/search?q=find_package%28expat&literal=1

Andrius
Description: libexpat.so.X.Y.Z is installed in /lib/${DEB_HOST_MULTIARCH}
 instead of /usr/lib/${DEB_HOST_MULTIARCH}, thus the path of the shared library
 is not relative to the location of this cmake file (Closes: #995907)
Author: Andrius Merkys 
Forwarded: not-needed
--- a/expat/cmake/autotools/expat-noconfig__linux.cmake.in
+++ b/expat/cmake/autotools/expat-noconfig__linux.cmake.in
@@ -8,12 +8,12 @@
 # Import target "expat::expat" for configuration ""
 set_property(TARGET expat::expat APPEND PROPERTY IMPORTED_CONFIGURATIONS NOCONFIG)
 set_target_properties(expat::expat PROPERTIES
-  IMPORTED_LOCATION_NOCONFIG "${_IMPORT_PREFIX}/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@"
+  IMPORTED_LOCATION_NOCONFIG "/lib/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@"
   IMPORTED_SONAME_NOCONFIG "libexpat.so.@SO_MAJOR@"
   )
 
 list(APPEND _IMPORT_CHECK_TARGETS expat::expat )
-list(APPEND _IMPORT_CHECK_FILES_FOR_expat::expat "${_IMPORT_PREFIX}/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@" )
+list(APPEND _IMPORT_CHECK_FILES_FOR_expat::expat "/lib/@LIBDIR_BASENAME@/libexpat.so.@SO_MAJOR@.@SO_MINOR@.@SO_PATCH@" )
 
 # Commands beyond this point should not need to know the version.
 set(CMAKE_IMPORT_FILE_VERSION)

Bug#996439: O: trayer -- Lightweight GTK2-based systray for UNIX desktop

2021-10-13 Thread HIGUCHI Daisuke (VDR dai)

Package: wnpp
Severity: normal
Control: affects -1 src:trayer

I intend to orphan the trayer package.

The package decription is:
 trayer is a small program designed to provide systray functionality
 present in GNOME/KDE desktop environments for window managers which
 do not support that function. System tray is a place, where various
 applications put their icons, so they are always visible presenting
 status of applications and allowing user to control programs.

It works and the packaging is in a good shape but it's stalled upstream
and depends obsoleted GTK+2.  I'm also not planning to use it anymore.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#996438: Post install fails when run as non-root user and does not respect PKG_ROOT

2021-10-13 Thread Glenn Washburn

Package: initramfs-tools
Version: 0.140

When run as a non-root user, such as when installing a package which
triggers this post install to a different root, the post install will
fail. This is in part due to update-initramfs needing privileges to
succeed. The simple fix would be to exit the script early if not run as
root. The proper fix involves respecting PKG_ROOT, which probably would
require an update to update-initramfs to allow specifying an alternate
fs root. Unfortunately, chroot can't be used here because it also
requires privileges.

Glenn

Bug#996437: elixir-lang: FTBFS with Erlang 24.1 (one test fails)

2021-10-13 Thread Sergei Golovan

Source: elixir-lang
Version: 1.12.2.dfsg-2
Severity: important
Tags: ftbfs patch upstream

Dear Maintainer,

Currently, elixir-lang fails to build from the source in unstable,
because one of its tests fails. See the result [1] from the autopkgtest for
details.

The problem is not in Elixir itself, but in the test which relies on a
specific error message from calling a non-existing function. When
building with Erlang 24.1, the error message has changed, so test fails.

The attached patch adapts this test to the current error message. Also,
I've bumped the build dependencies to Erlang 24.1 (with the new test
elixir-land will FTBFS with the older Erlang).

If you think it's appropriate, I could do NMU with the proposed changes.

Cheers!

[1] 
https://ci.debian.net/data/autopkgtest/testing/amd64/e/elixir-lang/15916413/log.gz

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental'), 
(1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 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 /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru elixir-lang-1.12.2.dfsg/debian/changelog 
elixir-lang-1.12.2.dfsg/debian/changelog
--- elixir-lang-1.12.2.dfsg/debian/changelog2021-08-24 16:41:05.0 
+0300
+++ elixir-lang-1.12.2.dfsg/debian/changelog2021-10-12 14:42:36.0 
+0300
@@ -1,3 +1,9 @@
+elixir-lang (1.12.2.dfsg-2.1) unstable; urgency=medium
+
+  * Fix a test to build with erlang 24.1.
+
+ -- Sergei Golovan   Tue, 12 Oct 2021 14:42:36 +0300
+
 elixir-lang (1.12.2.dfsg-2) unstable; urgency=medium
 
   * Fix debian/watch
diff -Nru elixir-lang-1.12.2.dfsg/debian/control 
elixir-lang-1.12.2.dfsg/debian/control
--- elixir-lang-1.12.2.dfsg/debian/control  2021-08-24 16:41:05.0 
+0300
+++ elixir-lang-1.12.2.dfsg/debian/control  2021-10-12 14:42:36.0 
+0300
@@ -3,12 +3,12 @@
 Priority: optional
 Maintainer: Evgeny Golyshev 
 Build-Depends: debhelper-compat (= 13),
-   erlang-crypto (>= 1:22),
-   erlang-dev (>= 1:22),
-   erlang-dialyzer (>= 1:22),
-   erlang-eunit (>= 1:22),
-   erlang-parsetools (>= 1:22),
-   erlang-src (>= 1:22),
+   erlang-crypto (>= 1:24.1),
+   erlang-dev (>= 1:24.1),
+   erlang-dialyzer (>= 1:24.1),
+   erlang-eunit (>= 1:24.1),
+   erlang-parsetools (>= 1:24.1),
+   erlang-src (>= 1:24.1),
git,
rebar
 Standards-Version: 4.6.0
diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch 
elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch
--- elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch1970-01-01 
03:00:00.0 +0300
+++ elixir-lang-1.12.2.dfsg/debian/patches/erlang-24.1.patch2021-10-12 
14:42:36.0 +0300
@@ -0,0 +1,15 @@
+Author: Sergei Golovan 
+Description: Patch adapts the asserted error message to Erlang 24.1
+Last-Modified: Tue, 12 Oct 2021 14:48:53 +0300
+
+--- a/lib/elixir/test/elixir/exception_test.exs
 b/lib/elixir/test/elixir/exception_test.exs
+@@ -474,6 +474,8 @@
+  function :erlang.gt_cookie/0 is undefined or private. Did you 
mean one of:
+ 
+* get_cookie/0
++   * get_cookie/1
++   * set_cookie/1
+* set_cookie/2
+  """
+ end
diff -Nru elixir-lang-1.12.2.dfsg/debian/patches/series 
elixir-lang-1.12.2.dfsg/debian/patches/series
--- elixir-lang-1.12.2.dfsg/debian/patches/series   2021-08-24 
16:41:05.0 +0300
+++ elixir-lang-1.12.2.dfsg/debian/patches/series   2021-10-12 
14:42:36.0 +0300
@@ -1,2 +1,3 @@
 remove-utf8-warning.patch
 remove_rebar3_related_tests.patch
+erlang-24.1.patch

Bug#732713: dh-python testsuite fails (wrong assumptions about symlink handling)

2021-10-13 Thread Stefano Rivera

Control: retitle -1 test t201 fails: has wrong assumptions about symlink 
handling
Control: severity -1 minor

Given the death of Python 2.7, demoting the test20* issues.

Going to re-enable the build-time test site without them.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#996436: Hide ldconfig error which occurs when postinst is run by non-root

2021-10-13 Thread Glenn Washburn

Package: libc-bin
Version: 2.31-12

The post install script fails when trigger as a non-root user (such as
when using dpkg to install a package to a different root from a
non-root account). This seems to be because ldconfig --verbose returns
an error because it needs root privileges to work, showing this error:

  /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~:
  Permission denied

Appending ||: to the end of this command will occlude the error and
allow the post install script to succeed.

Glenn

Bug#996435: Post install should account for PKG_ROOT

2021-10-13 Thread Glenn Washburn

Package: ntfs-3g:amd64
Version: 1:2017.3.23AR.3-4+deb11u1

The postinst should do:
  chmod 4755 $DPKG_ROOT/bin/ntfs-3g

Instead of 
  chmod 4755 /bin/ntfs-3g

Otherwise, when $DPKG_ROOT is set the post install script will likely
fail.

Glenn

Bug#996434: qemu-system-gui: gui randomly freezes even before booting under remote X

2021-10-13 Thread Marc Lehmann

Package: qemu-system-gui
Version: 1:5.2+dfsg-11+deb11u1
Severity: normal

Dear Maintainer,

when running with ssh -X forwarding, qemu now randomly hangs within the
first few seconds. Sometimes the screen is empty with blinking cursor,
sometimes there is a partial or full SEABIOS message, sometimes it gets to
the grub welcome message, but without fail, it hangs within the first few
seconds of startup.

the buster version works absolutely reliably with x forwarding.

I have seen this both with my own hosts, as well as with the hetzner
buster/bullseye rescue systems, so its unlikely to be my system
configuration.

Aimple way to reproduce this for me is:

   kvm -snapshot -hda /dev/sda -m 4096

Which normally is a simple way to see if my system is gonna boot.

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 qemu-system-gui depends on:
ii  libc6 2.31-13+deb11u2
ii  libcairo2 1.16.0-5
ii  libepoxy0 1.5.5-1
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libpixman-1-0 0.40.0-1
ii  libpulse0 14.2-2
ii  libvte-2.91-0 0.62.3-1
ii  libx11-6  2:1.7.2-1
ii  qemu-system-arm   1:5.2+dfsg-11+deb11u1
ii  qemu-system-mips  1:5.2+dfsg-11+deb11u1
ii  qemu-system-misc [qemu-system-s390x]  1:5.2+dfsg-11+deb11u1
ii  qemu-system-ppc   1:5.2+dfsg-11+deb11u1
ii  qemu-system-sparc 1:5.2+dfsg-11+deb11u1
ii  qemu-system-x86   1:5.2+dfsg-11+deb11u1

qemu-system-gui recommends no packages.

qemu-system-gui suggests no packages.

-- no debconf information

Bug#992322: Please consider this new package

2021-10-13 Thread Yadd

Control: severity -1 important

Hi,

minipass-* family is now needed to upgrade node-jsdom which is needed to
upgrade node-cheerio and is a reverse dependency of some important
packages: node-jest, node-babel7, node-sinon,...

Cheers,
Yadd

Bug#996433: transmission-daemon: Transmission fails to send mail using exim4

2021-10-13 Thread Sandro Tosi

control: tags -1 +moreinfo

> It seems that this bug is caused by this change in Transmission: 
> https://github.com/transmission/transmission/pull/795
> After changing my
> /etc/systemd/system/multi-user.target.wants/transmission-daemon.service
> to read "NoNewPrivileges=false" instead of true and reloading the
> service and daemon, I find that transmission is properly sending emails
> again.

this is weird: that PR is included in the 3.00 release provided in
debian, and infact the file
/lib/systemd/system/transmission-daemon.service includes the PR
change; how did you get that outdated file in /etc/systemd/system/ ?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31

2021-10-13 Thread Otto Kekäläinen

Hello!

On Tue, Oct 12, 2021 at 4:51 AM Yves-Alexis Perez  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Mon, 2021-10-11 at 11:27 +0200, Jan Korbel wrote:
> > Maybe this: https://bugs.freebsd.org/bugzilla//show_bug.cgi?id=257728
>
> If I read the bug correctly, it points to
> https://jira.mariadb.org/projects/MDEV/issues/MDEV-26537 and the commit
> https://github.com/MariaDB/server/commit/d09426f9e60fd93296464ec9eb5f9d85566437d3
>
> I'm not sure I can rebuild the mariadb package myselve but I can surely test a
> package if someone builds it.

I added this patch to the packaging in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2a8f83531a2ff22a31c61b8bef28dabf77b25b78
and once the CI completes (if it runs without errors) you will be able
to download the packages from the build artifacts published at
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/pipelines/302326
in step "build".

Bug#996433: transmission-daemon: Transmission fails to send mail using exim4

2021-10-13 Thread John Hundley

Package: transmission-daemon
Version: 3.00-1
Severity: normal

Dear Maintainer,
After upgrading to Debian 11, I found that Transmission stopped sending
me emails about finished torrents. I did a bunch of troubleshooting and
ensured that Transmission is properly executing the completed torrent
script. I also saw that Exim still otherwise works, and can even send
email as the debian-transmission user after su-ing to this user. I even
did a fresh debian install on another machine and did the bare minimum
configuration to get both exim4 and transmission set up on it; I
witnessed the same exact error.

My smaller test script is a simple one-liner:
echo "Torrent Completed: $TR_TORRENT_NAME" | mail -s "Torrent Completed" 
jthund...@jthundley.com > /etc/transmission-daemon/mailout 2> 
/etc/transmission-daemon/mailerr

mailout is empty while mailerr is:
mail: cannot send message: Process exited with a non-zero status
mail: Cannot open file /var/lib/transmission-daemon/dead.letter: Permission 
denied

It seems that this bug is caused by this change in Transmission: 
https://github.com/transmission/transmission/pull/795
After changing my
/etc/systemd/system/multi-user.target.wants/transmission-daemon.service
to read "NoNewPrivileges=false" instead of true and reloading the
service and daemon, I find that transmission is properly sending emails
again.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
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 transmission-daemon depends on:
ii  adduser  3.118
ii  libc62.31-13+deb11u2
ii  libcurl4 7.74.0-1.3+b1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libminiupnpc17   2.2.1-1
ii  libnatpmp1   20150609-7.1
ii  libssl1.11.1.1k-1+deb11u1
ii  libsystemd0  247.3-6
ii  lsb-base 11.1.0
ii  transmission-common  3.00-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages transmission-daemon recommends:
ii  transmission-cli  3.00-1

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/transmission-daemon/settings.json [Errno 13] Permission denied: 
'/etc/transmission-daemon/settings.json'

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "en_DK.UTF-8",
LC_MEASUREMENT = "en_US.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#996389: [debian-mysql] Bug#996389: mariadb-server: FATAL ERROR: Upgrade failed

2021-10-13 Thread Otto Kekäläinen

Hello!

This is not a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995066, right?
Does the same fix
(https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/11)
however apply to this too?

Bug#992130: ldap-utils: [ldapsearch] wrong default location of -T in man page

2021-10-13 Thread Ryan Tandy


Control: tag -1 fixed-upstream

https://git.openldap.org/openldap/openldap/-/commit/f7d558a44912329019eaa5a2400fa0a460f48f10

Bug#996432: ITS: newlib

2021-10-13 Thread John Scott

Source: newlib
Version: 3.3.0-1.1
Severity: important
X-Debbugs-Cc: debian-toolch...@lists.debian.org, 
pkg-electronics-de...@alioth-lists.debian.net, m...@qa.debian.org

The Newlib package is, in my opinion, currently in a poor state of
affairs.
 * The upstream release 4.1.0 has yet to be packaged.
 * It currently uses an obsolete Debhelper compatibility level, which
puts it at risk of being removed in the Bookworm release cycle
(#965746).
 * Ports to new systems, such as riscv64-unknown-elf, are wanted
(#980918).
 * There is at least one credible security issue which hasn't been
addressed (#984446).

I believe this package is eligible for salvaging based on these facts:
 * My previous NMU of Newlib went unacknowledged.
 * The maintainers have been unresponsive to my attempts at contact.
 * There has been no visible work on the package for 18 months.

Here is my game plan for Newlib, which I have alluded to on the pkg-
electronics-devel list and not gotten any pushback on:
 * It provides multiple benefits, including avoiding the bootstrap
problem and enabling running of the GCC test suite, for the GCC
packages for various ports to also be responsible for building Newlib.
This can be done using a combined tree; an initial upload of gcc-sh-elf
is imminent which will demonstrate this technique.

 * I will accordingly make gcc-arm-none-eabi responsible for building
its own Newlib port by preparing a merge request soon.

 * libnewlib-dev is a misnomer; this package should really be called
libnewlib-arm-none-eabi-dev. I will turn libnewlib-dev into a
transitional package.

 * Only after the dust has settled will I upload Newlib 4.1.0. The
"downstream consumers" (gcc-sh-elf, gcc-arm-none-eabi, gcc-riscv64-
none-elf) will be able to migrate to this version at their own pace
whenever they get rebuilt.

 * In the end, I plan for the Newlib source package to provide only two
binaries: newlib-source, and libnewlib-doc.

I expect that my work will be most welcome within the Electronics Team,
but if they'd prefer, I could also maintain this under my own
namespace. In any case, I'm not a project member and will require
sponsorship, so I will not be able to upload this package on my own.

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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



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

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

On Thu, 14 Oct 2021 at 00:33:44 +0100, Christian Rauch wrote:
> I am not familiar with the processes and timelines in Debian. It appears
> that "libdecor-0" is stuck in this queue for 2 months and other packages
> are waiting for far longer.

Yes, it's waiting for legal checks from the archive administrators.

> Is there a timeline for when packages are scheduled for upload to the
> respective package archives (e.g. experimental in this case)

There is no fixed timeline, we just have to wait for someone with the
right permissions to get round to reviewing it.

smcv

Bug#996431: r-cran-cairo: Unable to open device: Graphics API version mismatch

2021-10-13 Thread Rob Moss

Package: r-cran-cairo
Version: 1.5-12.2-1
Severity: important
X-Debbugs-Cc: robm@gmail.com

Dear Maintainer,

I recently ran an R plotting script for the first time in about 6 months.

This script uses the r-cran-cairo package to save the plot as a PDF file, and I 
expected it to produce a PDF file as per usual.

But when the script called the CairoPDF() function, the script terminated with 
the following error message:

Graphics API version mismatch
Calls:  -> CairoPDF -> Cairo
Execution halted

I managed to run the script successfully by building and installing the package 
from within R using the following command:

install.packages('Cairo')

So I suspect the r-cran-cairo package needs to be recompiled against the 
current libcairo2 package.

All the best,
Rob


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (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 r-cran-cairo depends on:
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libfreetype6 2.10.4+dfsg-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  libx11-6 2:1.7.2-2+b1
ii  r-base-core [r-api-4.0]  4.1.1-2

r-cran-cairo recommends no packages.

Versions of packages r-cran-cairo suggests:
ii  r-cran-png  0.1-7-4

-- no debconf information

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

2021-10-13 Thread Christian Rauch

Simon, thank you for uploading the package to the ftp.

I am not familiar with the processes and timelines in Debian. It appears
that "libdecor-0" is stuck in this queue for 2 months and other packages
are waiting for far longer.

Is there a timeline for when packages are scheduled for upload to the
respective package archives (e.g. experimental in this case) or what
unresolved issues are blocking the upload?

Best,
Christian

Am 11.08.21 um 17:24 schrieb Simon McVittie:
> Control: tags -1 + pending
> Control: forwarded -1 https://ftp-master.debian.org/new.html
>
> On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
>> "libdecor" is a library that can be used by Wayland clients to implement
>> client-side window decorations.
>
> Initial package uploaded to NEW, now waiting for ftp team processing.
>
> I made some more packaging improvements before uploading:
> https://salsa.debian.org/sdl-team/libdecor-0/-/commits/debian/latest/
>
> smcv
>

Bug#996430: qpdfview: PDF plugins mention DjVu in their short description

2021-10-13 Thread Thomas Vincent

Source: qpdfview
Severity: minor

Dear Maintainer,

Both binary packages qpdfview-pdf-mupdf-plugin and qpdfview-pdf-poppler-plugin
are described as DjVu plugins in their short descriptions.

However, since they add support for PDF and not DjVu, I believe their short 
descriptions should be
'tabbed document viewer - PDF plugin' instead of 'tabbed document viewer - DjVu 
plugin'.

Thanks for maintaining qpdfview!
Thomas

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

Kernel: Linux 5.10.0-9-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#994275: Draft resolution for reverting changes in debianutils

2021-10-13 Thread David Bremner

Sean Whitton  writes:

> 1. Offer advice:

>The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.

Is it really advice if we say "must"?

> 2. Overrule maintainer of debianutils:
>
>The which(1) program must not print any deprecation warnings.

I remain to be convinced on this point. If I understand the issue
correctly the problem is with autopkgtests failing because they were not
expecting output on stderr. I don't think people are really entitled to
expect which(1) to never print to stderr. Even when debian-policy
recommended 'which' it apparently recommended redirecting stderr.

I also don't see failures of autopkgtests as directly impacting users in
the same way a failure to build or a failure to install does.

I understand that people find the message annoying, and perhaps not that
useful, but I don't think that rises the level justifying overriding a
maintainer.

Bug#996429: mpv: -ao pcm generates a bad wav file

2021-10-13 Thread Jean-Philippe MENGUAL

Package: mpv
Version: 0.33.1-1+b2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

After an upgrade of the mpv

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

mpv -vo null -cache 128 -ao=pcm https://cogecomedia.leanstream.co/CHMPFM-MP3

   * What was the outcome of this action?

A wav file with a not audible sound 

   * What outcome did you expect instead?

So far the sound resulting from this command was perfect

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

Best regards


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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages mpv depends on:
ii  libarchive13  3.4.3-2+b1
ii  libasound21.2.5.1-1
ii  libass9   1:0.15.2-1
ii  libavcodec58  7:4.4-6+b2
ii  libavdevice58 7:4.4-6+b2
ii  libavfilter7  7:4.4-6+b2
ii  libavformat58 7:4.4-6+b2
ii  libavutil56   7:4.4-6+b2
ii  libbluray21:1.3.0-3
ii  libc6 2.32-4
ii  libcaca0  0.99.beta19-2.2
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio-paranoia2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-2
ii  libdrm2   2.4.107-8
ii  libdvdnav46.1.1-1
ii  libegl1   1.3.4-2+b1
ii  libgbm1   21.2.3-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.19~dfsg-2
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  liblua5.2-0   5.2.4-1.1+b3
ii  libmujs1  1.1.3-2
ii  libplacebo120 3.120.3-2
ii  libpulse0 15.0+dfsg1-2
ii  libsdl2-2.0-0 2.0.16+dfsg1-4
ii  libsixel1 1.8.6-2
ii  libswresample37:4.4-6+b2
ii  libswscale5   7:4.4-6+b2
ii  libuchardet0  0.0.7-1
ii  libva-drm22.13.0-1
ii  libva-wayland22.13.0-1
ii  libva-x11-2   2.13.0-1
ii  libva22.13.0-1
ii  libvdpau1 1.4-3
ii  libvulkan11.2.189.0-2
ii  libwayland-client01.19.0-2+b1
ii  libwayland-cursor01.19.0-2+b1
ii  libwayland-egl1   1.19.0-2+b1
ii  libx11-6  2:1.7.2-2+b1
ii  libxext6  2:1.3.4-1
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 1.0.3-2
ii  libxrandr22:1.5.2-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1
ii  libzimg2  3.0.3+ds1-1+b1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages mpv recommends:
ii  xdg-utils   1.1.3-4.1
pn  youtube-dl  

mpv suggests no packages.

-- no debconf information

Bug#996390: libzydis-dev: description says that "all" x86 extensions are supported

2021-10-13 Thread Andrea Pappacoda

Hi, I agree that the description should be changed, especially after 
the discussion we had in upstream's issue ticket. Unfortunately I'm not 
at all familiar with advanced instructions sets, so I wouldn't be able 
to determine an appropriate description that mentions the precise list 
of supported extensions.


Even if this is not a perfect solution, I think I could reword the 
sentence to something like "It supports all x64 and AMD64 instructions 
and many vendor extensions", or maybe entirely remove "and extensions" 
(I think that "instructions" means the standard x86/AMD64 instruction 
set and "extensions" refers to all the various extra instructions added 
by the various vendors, right?)


Thanks again for your help.

Bug#979095: Legally problematic GPL-3+ readline dependency

2021-10-13 Thread Bastian Germann

On Sun, 03 Jan 2021 14:17:05 +0530 Ritesh Raj Sarraf  wrote:

On Sat, 2021-01-02 at 18:36 +0100, Bastian Germann wrote:
> This package depends on libreadline8 which is GPL-3+ licensed.
> According 
> to debian/copyright parts of your package are GPL-2-only licensed. If
> that is also (transitively) the case for the binaries that link with 
> libreadline.so.8 it might be legally problematic (see 
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
> 

multipath-tools is mixed bag of licenses. The last time I checked on
it, the results weren't optimum.

https://www.redhat.com/archives/dm-devel/2016-July/msg00508.html

As you noted there, libmultipath/prioritizers/ontap.c is GPL-2-only 
licensed, amongst other files in libmultipath. So libmultipath is 
GPL-2-only.

multipathd links with libreadline (GPL-3+) and libmultipath 
(GPL-2-only). Even though the effective license of multipathd alone 
seems to be LGPL-2.0, linking with both of these licenses is not okay.

Bug#996418: xrdp: sets hard-coded PATH for X11 session

Hi Simon,

>You might be imagining that dbus-update-activation-environment is forcing
>particular environment variables for your GUI session, but it's the other

yes, this is what I thought at first.

>way round: its purpose is to receive environment variables (usually from
>your GUI session) and copy them to non-GUI processes elsewhere in the
>process hierarchy (specifically, dbus-daemon's children).

Ah, thanks for the added explanation.

>https://codesearch.debian.net/search?q=%5B%5Erl%5D%2Fsbin%3A%2Fbin%3A%2Fusr%2Fbin%3A%2Fusr%2Flocal%2Fbin&literal=0
>
>and sure enough, the path you didn't want is hard-coded in xrdp:

Oh, codesearch isn’t something that occurred to me ☻

I did arrive at the same conclusion by tracing which processes had
that string in their environment and where it could have come from
in the meantime, though (see my second mail).

>* xrdp sets this PATH
>* nothing overwrites it with a value that is more to your liking
>* Xsession inherits this PATH from xrdp

Yes, exactly. And it’s the “nothing overwrites it” part that was
the bug, and I even figured out *that* as well (xrdp, in contrast
to e.g. su or kdm, doesn’t use pam_env).

>If xrdp is acting as a login entry point, then it's the equivalent of
>a display manager like xdm/gdm/etc.; so I would have expected it to
>invoke the PAM stack, including pam_env.so to read /etc/environment,
>like display managers do.

Heh yeah. It is. And I’m nowhere even near a GUI expert, I figured
that out while debugging this issue and gave the possible fix a shot.
Great to hear it confirmed from someone who’s actually versed in the
entire modern desktop thing. (And a good learning experience.)

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#996428: libfido2: FTBFS on hppa and ia64 - stack protector check

2021-10-13 Thread John David Anglin

Source: libfido2
Version: 1.6.0-2
Severity: normal

Dear Maintainer,

The check for -fstack-protector-all is successful:

-- The C compiler identification is GNU 10.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Performing Test HAVE_SHORTEN_64_TO_32
-- Performing Test HAVE_SHORTEN_64_TO_32 - Failed
-- Performing Test HAVE_STACK_PROTECTOR_ALL
-- Performing Test HAVE_STACK_PROTECTOR_ALL - Success

But this option causes a warning and the build fails because of the
-Werror option.  Possibly, the -Werror option needs to be used in
the HAVE_STACK_PROTECTOR_ALL check.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#996107: budgie-desktop: compatibility with mutter 41

On Wed, 13 Oct 2021 at 22:26:52 +0100, David Mohammed wrote:
>   will gnome-desktop be bumped in experimental to 41.0?
> (https://gitlab.gnome.org/GNOME/gnome-desktop/-/tags)
> 
> Currently budgie-desktop for mutter-9 will not build with 40.4 that is in sid

I think it can probably even go straight to unstable. If that turns out to
be a problem for some reason, then I'll upload to experimental instead.
I'll try to get that uploaded today.

smcv

Bug#996427: node-mermaid: ships a copy of /usr/share/nodejs/crypto-random-string/*, already in node-crypto-random-string

Package: node-mermaid
Version: 8.13.2+ds+~cs30.13.21-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Preparing to unpack .../node-mermaid_8.13.2+ds+~cs30.13.21-1_all.deb ...
  Unpacking node-mermaid (8.13.2+ds+~cs30.13.21-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-mermaid_8.13.2+ds+~cs30.13.21-1_all.deb (--unpack):
   trying to overwrite '/usr/share/nodejs/crypto-random-string/index.d.ts', 
which is also in package node-crypto-random-string 3.3.0-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/node-mermaid_8.13.2+ds+~cs30.13.21-1_all.deb


cheers,

Andreas


node-crypto-random-string=3.3.0-1_node-mermaid=8.13.2+ds+~cs30.13.21-1.log.gz
Description: application/gzip

Bug#993294: RM: libidn11-java [all] -- NBS; needs manual cruft removal

2021-10-13 Thread Simon Josefsson

Hi.  What is the progress on this?  As far as I can tell, it is
blocking the 'libidn' package from ever entering testing:
https://tracker.debian.org/pkg/libidn

"Issues preventing migration:
missing build on all"

/Simon



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

Bug#996418: xrdp: sets hard-coded PATH for X11 session

Control: retitle -1 xrdp: sets hard-coded PATH for X11 session
Control: reassign -1 xrdp

[some lines in the quoted message have been reshuffled here to turn it
into a more concise bug report for xrdp; xrdp maintainers, please see
the original bug if more info is required]

On Wed, 13 Oct 2021 at 22:32:24 +0200, Thorsten Glaser wrote:
> dbus-update-activation-environment: sets wrong PATH since March 2021
>
> Hi, not sure which package is actually at fault here, but here we go.
> Please reassign (and notify the target package maintainers) as needed.
...
> I would have expected a user X11 session to use this:
> /etc/environment:PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
> 
> Instead we're getting a PATH set that nowhere even is configured:
...
> dbus-update-activation-environment: setting 
> PATH=/sbin:/bin:/usr/bin:/usr/local/bin
...
> This machine is a regular desktop but also has xrdp+xorgxrdp installed
> so I can use it while working remotely. The xrdp sessions log to
> ~/.xsession-errors which is where I could spot the first possible cause
> for this error.

You might be imagining that dbus-update-activation-environment is forcing
particular environment variables for your GUI session, but it's the other
way round: its purpose is to receive environment variables (usually from
your GUI session) and copy them to non-GUI processes elsewhere in the
process hierarchy (specifically, dbus-daemon's children).

If dbus-update-activation-environment is setting a PATH that you
consider to be wrong, then this is either misconfiguration, or a bug
in its caller. d-u-a-e is a mechanism rather than part of a policy:
it is not configurable, and does not hard-code a PATH itself.

> Specifically, the presence of /sbin without /usr/sbin in the "bad"
> PATH causes questions

That seemed odd to me too, and perhaps distinctive enough to identify
a root cause from. So I tried codesearch, with some adjustment to eliminate
false positives:

https://codesearch.debian.net/search?q=%5B%5Erl%5D%2Fsbin%3A%2Fbin%3A%2Fusr%2Fbin%3A%2Fusr%2Flocal%2Fbin&literal=0

and sure enough, the path you didn't want is hard-coded in xrdp:

g_setenv("PATH", "/sbin:/bin:/usr/bin:/usr/local/bin", 1);

I think the chain of events here is:

* xrdp sets this PATH
* nothing overwrites it with a value that is more to your liking
* Xsession inherits this PATH from xrdp
* /etc/X11/Xsession.d/95dbus_update-activation-env inherits this PATH
  from Xsession
* dbus-update-activation-environment uploads it to dbus-daemon, while
  logging a message
* /etc/X11/Xsession.d/99x11-common_start starts the "outermost" process
  in your GUI session (whatever its equivalent of gnome-session is)
* your GUI programs also inherit this PATH

If xrdp is acting as a login entry point, then it's the equivalent of
a display manager like xdm/gdm/etc.; so I would have expected it to
invoke the PAM stack, including pam_env.so to read /etc/environment,
like display managers do.

smcv

Bug#996107: budgie-desktop: compatibility with mutter 41

2021-10-13 Thread David Mohammed

Hi Simon,

  will gnome-desktop be bumped in experimental to 41.0?
(https://gitlab.gnome.org/GNOME/gnome-desktop/-/tags)

Currently budgie-desktop for mutter-9 will not build with 40.4 that is in sid

TIA

Davivd

On Mon, 11 Oct 2021 at 19:14, Simon McVittie  wrote:
>
> On Mon, 11 Oct 2021 at 13:20:31 +0100, David Mohammed wrote:
> > On Mon, 11 Oct 2021 at 11:27, Simon McVittie  wrote:
> > > Please test budgie-desktop against mutter 41 (libmutter-9), and initially
> > > upload to experimental.
> >
> > I can do it ... but it will have to wait until the weekend at a
> > minimum since I am preparing for Ubuntu 21.10 release this week.  Hope
> > thats ok.
>
> No problem, whenever you have time to work on this is fine! I wanted
> to get a bug open so we could keep track of what the blockers are for
> finishing GNOME 41 packaging.
>
> Thanks,
> smcv

Bug#996426: irpas: FTBFS due to RPC removal from glibc

Source: irpas
Version: 0.10-8
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)

Hi,

irpas no longer builds in sid since glibc has dropped the rpc headers.
They are now provided by libtirpc-dev (and you may need
-I/usr/include/tirpc to find them).

>From the attached log:

make[1]: Entering directory '/build/irpas-0.10'
gcc -g -O2 -ffile-prefix-map=/build/irpas-0.10=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wall -g -Wunused -Wmissing-prototypes -I. 
-Wdate-time -D_FORTIFY_SOURCE=2 -c cdp.c
cdp.c:14:10: fatal error: rpc/types.h: No such file or directory
   14 | #include 
  |  ^
compilation terminated.
make[1]: *** [Makefile:56: cdp.o] Error 1


Andreas


irpas_0.10-8.log.gz
Description: application/gzip

Bug#996418: dbus-update-activation-environment: sets wrong PATH since March 2021

reassign 996418 xrdp
found 996418 0.9.15-1
retitle 996418 xrdp-sesman: fails to initialise environment properly
severity 996418 important
thanks

On Wed, 13 Oct 2021, Thorsten Glaser wrote:

(full quote below for the xrdp maintainers)

> Hi, not sure which package is actually at fault here, but here we go.
> Please reassign (and notify the target package maintainers) as needed.

Having looked at /proc/*/environ for the bogus string it seems to be
injected by xrdp-sesman. Comparing its PAM configuration to that of
su, kdm, etc. I found something obvious lacking (pam_env, which even
"man environment" on Debian points out is the thing loading it). And
the xrdp-sesman start script goes to larger pain to load the locale
(which I wrote probably preciely because this was missing); note I
did not and still do not know anything about PAM except roughly that
it exists ;-)

I just locally tested the following patch (fix this in the PAM config,
drop the locale-loading workaround), and it fixed my PATH for me:

--- a/debian/startwm.sh
+++ b/debian/startwm.sh
@@ -2,26 +2,6 @@
 # xrdp X session start script (c) 2015, 2017 mirabilos
 # published under The MirOS Licence
 
-if test -r /etc/default/locale; then
-   . /etc/default/locale
-   test -z "${LANG+x}" || export LANG
-   test -z "${LANGUAGE+x}" || export LANGUAGE
-   test -z "${LC_ADDRESS+x}" || export LC_ADDRESS
-   test -z "${LC_ALL+x}" || export LC_ALL
-   test -z "${LC_COLLATE+x}" || export LC_COLLATE
-   test -z "${LC_CTYPE+x}" || export LC_CTYPE
-   test -z "${LC_IDENTIFICATION+x}" || export LC_IDENTIFICATION
-   test -z "${LC_MEASUREMENT+x}" || export LC_MEASUREMENT
-   test -z "${LC_MESSAGES+x}" || export LC_MESSAGES
-   test -z "${LC_MONETARY+x}" || export LC_MONETARY
-   test -z "${LC_NAME+x}" || export LC_NAME
-   test -z "${LC_NUMERIC+x}" || export LC_NUMERIC
-   test -z "${LC_PAPER+x}" || export LC_PAPER
-   test -z "${LC_TELEPHONE+x}" || export LC_TELEPHONE
-   test -z "${LC_TIME+x}" || export LC_TIME
-   test -z "${LOCPATH+x}" || export LOCPATH
-fi
-
 if test -r /etc/profile; then
. /etc/profile
 fi
--- a/instfiles/pam.d/xrdp-sesman.debian
+++ b/instfiles/pam.d/xrdp-sesman.debian
@@ -1,4 +1,6 @@
 #%PAM-1.0
+auth required pam_env.so readenv=1
+auth required pam_env.so readenv=1 envfile=/etc/default/locale
 @include common-auth
 @include common-account
 @include common-session


Therefore, reassigning to xrdp (and pushing the fix to its packaging
repository). @xrdp team: this is one I think, after review/testing,
we might with to even fix in stable.

> This machine used to be an unstable machine but some time before the
> release I switched it to bullseye. The date range in question (February
> to March 2021) are when it still was on sid.
> 
> I have not yet noticed this because it only affects one command. The
> problem is that it picked up the "wrong" version of the command, the
> one from /usr/bin instead of the one from /usr/local/bin.
> 
> This machine is a regular desktop but also has xrdp+xorgxrdp installed
> so I can use it while working remotely. The xrdp sessions log to
> ~/.xsession-errors which is where I could spot the first possible cause
> for this error.
> 
> My ~/.xsession-errors contains, with some information snipped for
> legibility:
> 
> -cutting here may damage your screen surface-
> ⇒ Feb 25  2021, 16:22:09+0100 (CET), 2021-W08-4 (Thu) ⇐
> Xsession: X session started for tglase at Thu Feb 25 16:22:09 CET 2021
> WARNING: tempfile is deprecated; consider using mktemp instead.
> localuser:tglase being added to access control list
> localuser:boinc being added to access control list
> dbus-update-activation-environment: systemd --user not found, ignoring 
> --systemd argument
> […]
> dbus-update-activation-environment: setting 
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> […]
> Xsession: X session started for tglase at Fri Mar 12 19:11:35 CET 2021
> WARNING: tempfile is deprecated; consider using mktemp instead.
> localuser:tglase being added to access control list
> localuser:boinc being added to access control list
> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  140 (RANDR)
> […]
> dbus-update-activation-environment: setting 
> PATH=/sbin:/bin:/usr/bin:/usr/local/bin
> […]
> -cutting here may damage your screen surface-
> 
> From the top, these are:
> 
> - one line from my ~/.profile
> - 5 + 1 lines from the session start
> - 6 + 1 lines from the start of the next session
> 
> The lower session is definitely xrdp+xorgxrdp, as one of the xset
> calls from ~/.xsessionrc failed. The first call may very well be
> from kdm. These are the two oldest entries in that file.
> 
> There are *three* different PATH values set, apparently:
> 
> tglase@tglase:~ $ fgrep 'setting PATH=' .xsession-errors | sort | uniq -c
>   1 dbus-update-activation-environment: s

Bug#996425: hitch: FTBFS with OpenSSL 3.0

Source: hitch
Version: 1.7.1-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
hitch.c: In function init_dh:
hitch.c:318:2: error: PEM_read_bio_DHparams is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  318 |  dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
  |  ^~
In file included from /usr/include/openssl/ui.h:30,
 from /usr/include/openssl/engine.h:30,
 from hitch.c:42:
/usr/include/openssl/pem.h:469:1: note: declared here
  469 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, DHparams, DH)
  | ^~~
hitch.c:327:3: error: DH_free is deprecated: Since OpenSSL 3.0 
[-Werror=deprecated-declarations]
  327 |   DH_free(dh);
  |   ^~~
In file included from /usr/include/openssl/dsa.h:51,
 from /usr/include/openssl/x509.h:37,
 from hitch.c:40:
/usr/include/openssl/dh.h:200:28: note: declared here
  200 | OSSL_DEPRECATEDIN_3_0 void DH_free(DH *dh);
  |^~~
[...]

Removing the -Werror will turn those errors in warnings and should
allow building against and using OpenSSL 3.0. The functions are still
available but marked for removal in some future version.


Kurt

Bug#996424: haskell-blogliterately: FTBFS with OpenSSL 3.0

Source: haskell-blogliterately
Version: 0.8.7-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
[12 of 12] Compiling Text.BlogLiterately ( src/Text/BlogLiterately.hs, 
dist-ghc/build/Text/BlogLiterately.p_o )
Preprocessing executable 'BlogLiterately' for BlogLiterately-0.8.7..
Building executable 'BlogLiterately' for BlogLiterately-0.8.7..
[1 of 1] Compiling Main ( main/BlogLiterately.hs, 
dist-ghc/build/BlogLiterately/BlogLiterately-tmp/Main.o )
Linking dist-ghc/build/BlogLiterately/BlogLiterately ...
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsrsaFromPKey1_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsrsaFromPKey_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsdsaFromPKey1_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function
 
HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsdsaFromPKey_info:
 error: undefined reference to 'EVP_PKEY_base_id'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(Session.o):function
 HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziSession_zdwio_info: 
error: undefined reference to 'SSL_get_peer_certificate'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function
 HsOpenSSL_EVP_MD_size: error: undefined reference to 'EVP_MD_size'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function
 HsOpenSSL_EVP_CIPHER_CTX_block_size: error: undefined reference to 
'EVP_CIPHER_CTX_block_size'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function
 HsOpenSSL_EVP_CIPHER_iv_length: error: undefined reference to 
'EVP_CIPHER_iv_length'
collect2: error: ld returned 1 exit status
`x86_64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1


Kurt

Bug#996423: haproxy: FTBFS with OpenSSL 3.0

Source: haproxy
Version: 2.2.17-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
src/ssl_sock.c: In function â€˜ctx_set_TLSv13_funcâ€™:
src/ssl_sock.c:2178:5: error: missing binary operator before token "1"
 2178 | #if SSL_OP_NO_TLSv1_3
  | ^


Kurt

Bug#996163: tzdata: [INTL:fr] French templates translation

2021-10-13 Thread Aurelien Jarno

Hi,

On 2021-10-11 18:32, Jean-Pierre Giraud wrote:
> Package: tzdata
> Severity: wishlist
> Tags: patch l10n
> 
> Hi!
> 
> Please find attached the updated french templates translation, proofread
> by the debian-l10n-french mailing list contributors.
> 
> This file should be put as debian/po/fr.po in your package build tree.

Thanks for the translation, however it seems you forgot to attach the
file.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#996422: golang-github-mendersoftware-openssl: FTBFS with OpenSSL 3.0

Source: golang-github-mendersoftware-openssl
Version: 1.1.0-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
github.com/mendersoftware/openssl
# github.com/mendersoftware/openssl
src/github.com/mendersoftware/openssl/fips.go:31:7: could not determine kind of 
name for C.FIPS_mode_set
dh_auto_build: error: cd _build && go install -trimpath -v -p 1 
github.com/mendersoftware/openssl github.com/mendersoftware/openssl/utils 
returned exit code 2
make: *** [debian/rules:4: binary] Error 25

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html


Kurt

Bug#996421: globus-proxy-utils: FTBFS with OpenSSL 3.0

Source: globus-proxy-utils
Version: 7.2-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
make[4]: Entering directory '/<>/test'
FAIL: grid-proxy-utils-test.pl
FAIL: proxy-order-test.pl
=
   globus_proxy_utils 7.2: test/test-suite.log
=

# TOTAL: 2
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: grid-proxy-utils-test.pl
==

# PATH = 
../programs:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
# X509_CERT_DIR = /<>/test
1..33
ok 1 - create_proxy  
not ok 2 - grid-proxy-info  
#   Failed test 'grid-proxy-info  '
#   at ./grid-proxy-utils-test.pl line 38.
not ok 3 - grid-proxy-info type is RFC 3820 compliant impersonation proxy
#   Failed test 'grid-proxy-info type is RFC 3820 compliant impersonation proxy'
#   at ./grid-proxy-utils-test.pl line 41.
ok 4 - create_proxy -draft 
not ok 5 - grid-proxy-info -draft 
[...]


Kurt

Bug#996420: globus-gssapi-gsi: FTBFS with OpenSSL 3.0

Source: globus-gssapi-gsi
Version: 14.17-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Hi,

Your package is failing to build using OpenSSL 3.0 with the
following error:
FAIL: gssapi-thread-test-wrapper


1..1
Segmentation fault
FAIL gssapi-thread-test-wrapper (exit status: 1)

FAIL: import-cred-test.pl
=

1..3

ERROR: GSS Major Status: General failure


ERROR: GSS Minor Status Error Chain:
globus_gsi_gssapi: Unable to read credential for import
globus_gsi_gssapi: Error with GSI credential
globus_credential: Error reading proxy credential: Couldn't read PEM from bio
OpenSSL Error: ../crypto/bio/bio_lib.c:518: in library: BIO routines, function 
BIO_ctrl: unsupported method

not ok 1 - test_import_data
#   Failed test 'test_import_data'
#   at ./import-cred-test.pl line 23.

ERROR: GSS Major Status: General failure

[...]


Kurt

Bug#995961: libapache2-mpm-itk: Error "AH00052: child pid exit signal Segmentation fault" after update to apache 2.4.51-1~deb11u1

2021-10-13 Thread Steinar H. Gunderson

reassign 995961 apache2
found 995961 2.4.51-1~deb11u1
found 995961 2.4.51-1
thanks

On Tue, Oct 12, 2021 at 11:56:20AM +0200, Jean Weisbuch wrote:
> It has also been reported on the HTTPD bugtracker :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=65627

Given the analysis there, it doesn't really look like there's anything
mpm-itk can do, so I'm reassigning this to apache2.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#996419: gcc-11: Fails to compile the linux kernel on ARM.

2021-10-13 Thread Sebastian Andrzej Siewior

Package: gcc-11
Version: 11.2.0-9
Severity: important

The linux kernel has the following in its ARM Makefile:
$(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)

This means the switch "-march=armv7-a" is tested if supported by the
compiler and if so it is used, otherwise it uses the alternative
"-march=armv5t -Wa,-march=armv7-a".

On gcc-10 it evaluated to "-march=armv7-a".
On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to
compile errors:
| cccHPwDp.s:4372: Error: selected processor does not support `cpsid i' in ARM 
mode
| cccHPwDp.s:5145: Error: selected processor does not support `cpsid i' in ARM 
mode
| cccHPwDp.s:5393: Error: selected processor does not support `cpsie i' in ARM 
mode
| cccHPwDp.s:5530: Error: selected processor does not support `dsb ' in ARM mode
| cccHPwDp.s:6088: Error: selected processor does not support `cpsie i' in ARM 
mode
| cccHPwDp.s:7132: Error: architectural extension `mp' is not allowed for the 
current base architecture
| cccHPwDp.s:7133: Error: selected processor does not support `pldw [r4]' in 
ARM mode
| cccHPwDp.s:7136: Error: selected processor does not support `pld [r4]' in ARM 
mode
| cccHPwDp.s:7148: Error: selected processor does not support `ldrex r3,[r4]' 
in ARM mode
| cccHPwDp.s:7150: Error: selected processor does not support `strex 
r1,r2,[r4]' in ARM mode

This has been noticed in the gcc-11-arm-linux-gnueabihf package and
verified on a armhf porter box with the native gcc-11 package.

The test fails due to:
| $ arm-linux-gnueabihf-gcc-10 -o a.o a.c -march=armv7-a
| $ arm-linux-gnueabihf-gcc-11 -o a.o a.c -march=armv7-a
| cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU

Passing early -msoft-float to the compiler test solves the problem. This
option is passed later to the compile process.
Is this change intended?

Sebastian

Bug#996418: dbus-update-activation-environment: sets wrong PATH since March 2021

Package: dbus-x11
Version: 1.12.20-2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Hi, not sure which package is actually at fault here, but here we go.
Please reassign (and notify the target package maintainers) as needed.

This machine used to be an unstable machine but some time before the
release I switched it to bullseye. The date range in question (February
to March 2021) are when it still was on sid.

I have not yet noticed this because it only affects one command. The
problem is that it picked up the "wrong" version of the command, the
one from /usr/bin instead of the one from /usr/local/bin.

This machine is a regular desktop but also has xrdp+xorgxrdp installed
so I can use it while working remotely. The xrdp sessions log to
~/.xsession-errors which is where I could spot the first possible cause
for this error.

My ~/.xsession-errors contains, with some information snipped for
legibility:

-cutting here may damage your screen surface-
⇒ Feb 25  2021, 16:22:09+0100 (CET), 2021-W08-4 (Thu) ⇐
Xsession: X session started for tglase at Thu Feb 25 16:22:09 CET 2021
WARNING: tempfile is deprecated; consider using mktemp instead.
localuser:tglase being added to access control list
localuser:boinc being added to access control list
dbus-update-activation-environment: systemd --user not found, ignoring 
--systemd argument
[…]
dbus-update-activation-environment: setting 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
[…]
Xsession: X session started for tglase at Fri Mar 12 19:11:35 CET 2021
WARNING: tempfile is deprecated; consider using mktemp instead.
localuser:tglase being added to access control list
localuser:boinc being added to access control list
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
[…]
dbus-update-activation-environment: setting 
PATH=/sbin:/bin:/usr/bin:/usr/local/bin
[…]
-cutting here may damage your screen surface-

From the top, these are:

- one line from my ~/.profile
- 5 + 1 lines from the session start
- 6 + 1 lines from the start of the next session

The lower session is definitely xrdp+xorgxrdp, as one of the xset
calls from ~/.xsessionrc failed. The first call may very well be
from kdm. These are the two oldest entries in that file.

There are *three* different PATH values set, apparently:

tglase@tglase:~ $ fgrep 'setting PATH=' .xsession-errors | sort | uniq -c
  1 dbus-update-activation-environment: setting 
PATH=/home/tglase/.etc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 27 dbus-update-activation-environment: setting 
PATH=/sbin:/bin:/usr/bin:/usr/local/bin
  1 dbus-update-activation-environment: setting 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

The middle one is the one causing me trouble.

The first and the last one are okay and differ only by the first one
having one entry prepended, which my shell startup file (not .profile
but the actual interactive(!) shell startup file) sets. This was one
session in June I have no idea how I started it, looks like Xorg, not
xrdp+xorgxrdp though. (Normally, when starting services (such as a
login manager) I use a wrapper script around /etc/init.d/* that clears
all environment variables.)

So the questions are, (a) where does this bad environment variable
come from, and (b) why is it also set in my user X session, when
dbus-update-activation-environment runs as a separate thing, although
in the X session start process?

I would have expected a user X11 session to use this:
/etc/environment:PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"

Instead we're getting a PATH set that nowhere even is configured:

$ sudo fgrep -r /sbin:/bin:/usr/bin:/usr/local/bin /etc
/etc/init.d/edac:PATH=/sbin:/usr/sbin:/usr/local/sbin:/bin:/usr/bin:/usr/local/bin

Specifically, the presence of /sbin without /usr/sbin in the "bad"
PATH causes questions; as far as I know, this is not used anywhere
in Debian like that: either you get both sbins (admin account) or
(almost everywhere) neither, but not just one of them.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, 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 dbus-x11 depends on:
ii  dbus 1.12.20-2
ii  libc62.31-13+deb11u2
ii  libdbus-1-3  1.12.20-2
ii  libx11-6 2:1.7.2-1

dbus-x11 recommends no packages.

dbus-x11 suggests no packages.

-- no debconf information

Bug#995927: linux-image-amd64: since kernel 5.9 module e100 causes system-wide problems after suspend

2021-10-13 Thread Salvatore Bonaccorso

Control: tags -1 + moreinfo

Hi,

On Fri, Oct 08, 2021 at 12:03:01PM +0200, hikaru wrote:
> Package: linux-image-amd64
> Version: 5.10.46-5
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: hikaru.deb...@web.de
> 
> Dear Maintainers,
> 
> I own an old notebook with the following wired ethernet adapter:
> 
> 07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection 
> (rev 02)
>   Subsystem: Fujitsu Technology Solutions PRO/100 VE Network Connection
>   Flags: bus master, medium devsel, latency 64, IRQ 20
>   Memory at dc00 (32-bit, non-prefetchable) [size=4K]
>   I/O ports at 5000 [size=64]
>   Capabilities: [dc] Power Management version 2
>   Kernel driver in use: e100
>   Kernel modules: e100
> 
> Under Bullseye (kernel 5.10), after a suspend2RAM/resume cycle, e100 causes
> problems which seem to be related to "e100: use generic power management" [1],
> which wass introduced with kernel 5.9. In the comment it says:
> "Compile-tested only."
> 
> 
> The symptoms are not always consistent, but usually they are as follows:
> 
> 1. After resume, there is no network at all (not only via the wired adapter,
> but also via the intel wifi adapter), at least for several (5?) minutes.
> Network may or may not return after that time.
> 
> 2. During that time, certain interactions with the system just stall -
> especially those connected to network tasks (e.g. network-manager-gnome, ip).
> In case "ip a" is successful it will usually show that there is a
> network connection (ip adress obtained via dhcp), but no network activity is
> possible (e.g. ping).
> (I ruled out network manager as the culprit, by uninstalling it. The problems
> remained the same.)
> 
> 3. When performing a shutdown or reboot after such a suspend/resume cycle, the
> operating system and the HDD will shut down, but the computer will not
> actually power off/reboot. Instead it will stay on indefinitely while messages
> like these remain on the screen:
> 
> Okt 06 18:32:19 amilo systemd[1]: Reached target Reboot.
> Okt 06 18:32:19 amilo systemd[1]: Shutting down.
> Okt 06 18:32:19 amilo systemd[1]: Using hardware watchdog 'iTCO_wdt', version 
> 0, device /dev/watchdog
> Okt 06 18:32:19 amilo systemd[1]: Set hardware watchdog to 10min.
> Okt 06 18:32:19 amilo kernel: watchdog: watchdog0: watchdog did not stop!
> Okt 06 18:32:19 amilo systemd-shutdown[1]: Syncing filesystems and block 
> devices.
> Okt 06 18:32:19 amilo systemd-shutdown[1]: Sending SIGTERM to remaining 
> processes...
> Okt 06 18:32:19 amilo systemd-journald[213]: Journal stopped
> 
> 4. During that shutdown the kernel may or may not throw exceptions, of
> which I have a photo, but no easily accessible log.
> 
> 
> Buster (kernel 4.19, up to bpo kernel 5.8) does not exhibit this behavior.
> However, it does with bpo kernels 5.9 and 5.10.
> 
> The problems disappear (with kernels >= 5.9) when disabling the
> ethernet adapter in the BIOS or when blacklisting e100.
> 
> For sake of transparency, I opened a thread in the unofficial German
> debianforum.de, which led me to file this bug report. [2]
> 
> 
> [1] 
> https://github.com/torvalds/linux/commit/69a74aef8a18eef20fb0044b5e164af41b84db21
> [2] https://debianforum.de/forum/viewtopic.php?f=26&t=182239

Can you report the upstream directly to upstream people (and ideally
keep us in the loop)?

Regards,
Salvatore

Bug#995923: Forwarded upstream

2021-10-13 Thread Salvatore Bonaccorso

Control: tags -1 + moreinfo
Control: tags -1 - patch

Hi Diederik,

On Sun, Oct 10, 2021 at 10:01:26AM +0200, Diederik de Haas wrote:
> Control: forwarded -1 https://lore.kernel.org/all/4974503.Y8KB3sNASq@bagend/

Do I understand the discussion correctly that this was a problem
arised in the configuration, so there won't be something to change on
the kernel side?

Regards,
Salvatore

Bug#996398: libkdecorations2-5v5: experimental version is instalable and breaks unstable

2021-10-13 Thread Éric Valette

I do it everyday for years. Usually dependencies are correct and sufficient. I 
saw à similar bug did happen with unstable and testing.

I could reverse thé question: why was this package update alone in experimental 
?

13 oct. 2021 20:16:58 Patrick Franz :

> Hi Eric,
> 
> why did you upgrade this package ? You should never upgrade a package
> from experimental blindly.
> 
> 
> -- 
> Med vänliga hälsningar
> 
> Patrick Franz

Bug#996417: xset: handle absence of DPMS support in the X server more gracefully

Package: x11-xserver-utils
Version: 7.7+8
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de

My ~/.xsessionrc has:

xset dpms 0 0 0

With a regular X11 session, this works, but in an xrdp+xorgxrdp session,
it fails because the server lacks DPMS support. But then, once having
failed on the dpms keywords, it interprets the 0 as another argument,
instead of first parsing the "dpms [standby [suspend [off]]]" then exiting
as there are no further arguments:


server does not have extension for dpms option
xset:  unknown option 0

usage:  xset [-display host:dpy] option ...
To turn bell off:
-bb off   b 0
[…]


This is, of course, both suboptimal and avoidable by moving the parsing
of the dpms-related options to before the check for its presence.

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

Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, 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 x11-xserver-utils depends on:
ii  cpp  4:10.2.1-1
ii  libc62.31-13+deb11u2
ii  libice6  2:1.0.10-1
ii  libx11-6 2:1.7.2-1
ii  libxaw7  2:1.0.13-1.1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1.1
ii  libxi6   2:1.7.10-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxmuu1 2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.2.0-1
ii  libxxf86vm1  1:1.1.4-1+b2

x11-xserver-utils recommends no packages.

Versions of packages x11-xserver-utils suggests:
pn  cairo-5c
pn  nickle  
pn  xorg-docs-core  

-- no debconf information

Bug#990279: 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo map") breaks amdgpu on ppc64 machines?

2021-10-13 Thread Salvatore Bonaccorso

Hi,

On Mon, Oct 11, 2021 at 10:30:21AM +0200, Christian König wrote:
> Am 10.10.21 um 16:14 schrieb Xi Ruoyao:
> > On Sun, 2021-10-10 at 14:46 +0100, Nathaniel Filardo wrote:
> > > It occurs to me, quite belatedly, that it may be worth asking the
> > > author, reviewers, and signers of the change in question their
> > > thoughts on this bug report:
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D990279&data=04%7C01%7Cchristian.koenig%40amd.com%7C915628061dd746062c5408d98bf84df9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637694721282436279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=V4R4BPCHNQzx2bF6STDzfjW%2BQezZg89w8%2FEeRpuRVnM%3D&reserved=0
> > > 
> > > In particular, on ppc64 systems, Linux typically is configured to use
> > > a 64KiB page (i.e., shift 16) rather than 4KiB (shift 12) page.  It
> > > looks, however, that AMDGPU_GPU_PAGE_SIZE is always 4096, and so
> > > something (perhaps in userspace, even, eek?) is requesting
> > > 4KiB-but-not-64KiB alignment of this buffer.
> > Christian told me the buffer should be aligned to *CPU* page boundary,
> > or the page table in AMDGPU driver will be corrupted:
> 
> Yeah, that's indeed correct. And that intentionally breaks because otherwise
> we can corrupt the page tables and potentially cause much worse trouble.
> 
> Question is more why userspace isn't told the correct value in your branch.
> 
> > 
> > > the value of num_entries must always be a multiple of
> > > AMDGPU_GPU_PAGES_IN_CPU_PAGE or otherwise we corrupt the page tables.
> > > You need to identify the root cause of this, most likely start or last
> > > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
> > IMO f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
> > dev_info.gart_page_size" should be backported along with this, which
> > makes the kernel to provide the CPU page size to libdrm and mesa and
> > correct userspace behavior.  I'm not sure why only one is backported.
> 
> 
> Yes, exactly that sounds like the correct fix to me as well.

So, the 9a89a721b41b (" drm/amdgpu: check alignment on CPU page for bo
map") was backported to several stable series 4.14.229, 4.19.185,
5.4.110, 5.10.28 and 5.11.12 but not the
f4d3da72a76a9ce5f57bba64788931686a9dc333 "drm/amdgpu: Set a suitable
dev_info.gart_page_size".

What is confusely is that all of those backports reference as upstream
commit e3512fb67093fabdf27af303066627b921ee9bd8 and not
9a89a721b41b23c6da8f8a6dd0e382966a850dcf which might be in part source
of the confusion?

Can any of you request to backport
f4d3da72a76a9ce5f57bba64788931686a9dc333 as well for those stable
series where relevant?

Regards,
Salvatore

Bug#994275: Draft resolution for reverting changes in debianutils

2021-10-13 Thread Sean Whitton

Dear all,

We think we might have a consensus on the following resolution text.  We
could be wrong, as the judgement of consensus has been made by just a
few of us.  We agreed in our meeting today that I'll start a vote a week
from today unless a ctte member asks for a delay.  Thus, we expect to
close this bug approximately two weeks from today.

Many thanks to Simon for a previous draft of this text.

~=~=~=~=~

1. Offer advice:

   The debianutils package must continue to provide the which(1) program
   until a compatible utility is available in a package that is at least
   transitively essential in Debian 12.

   For the Debian 12 release, we expect which(1) to be in either an
   Essential package or a transitively Essential package (that is, a
   package that is depended on by an Essential package).

2. Overrule maintainer of debianutils:

   The which(1) program must not print any deprecation warnings.

3. Decline to overrule maintainer regarding use of alternatives:

   If another package takes over responsibility for which(1), then the
   debianutils maintainers and the other package's maintainers should
   coordinate to choose a suitable mechanism, which might be either
   versioned Depends/Breaks/Replaces, dpkg-divert, alternatives or
   something else.

4. Overrule maintainer of debianutils:

   The debianutils package must continue to provide the tempfile(1)
   program until a compatible utility is available in a package that is
   at least transitively essential in Debian 12.

   For the Debian 12 release, we expect tempfile(1) to be in either an
   Essential package or a transitively Essential package.

5. Overrule maintainer of debianutils:

   Programs in debianutils must not be moved to /usr until we have a
   project-wide consensus on going ahead with such a move, and any
   programs that have already been moved must be moved back.  In
   particular, this means debianutils must contain /bin/run-parts and
   /sbin/installkernel for the time being.

~=~=~=~=~

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#970208:

2021-10-13 Thread daivon1...@hotmail.com



Get Outlook for Android

Bug#996416: nodejs FTCBFS: missing Build-Depends

2021-10-13 Thread Helmut Grohne

Source: nodejs
Version: 12.22.7~dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: block -1 by 996415

Thank you for applying my last patch and to Bastien for improving upon
it. That route seemed broken to me when I submitted my patch, but diving
deeper into it, it actually looks correct to me. Terminology seems to
be:

gyp| debian
---+---
target | host
host   | build

Though you cannot use CC_target as most of the code only checks CC.

In any case, I see two major issues. One is mixing up CFLAGS between the
different compilers. Examples:

build | host  | issue
--+---+---
amd64 | arm64 | aarch64-linux-gnu-gcc -m64
amd64 | s390x | x86_64-linux-gnu-gcc -march=z196

The flags for the different compilers are simply merged and that doesn't
work. I've looked into how to unmess this and given up. No ideas, sorry.

As a notable data point, amd64 -> mips64el is different. Their compiler
flags happen to be compatible and we see a different failure. The amd64
linker fails finding a ton of libraries. That's actually a good sign. A
number of libraries are needed for both architectures but only requested
for one in Build-Depends. The solution is to duplicate them with a
:native annotation. I'm attaching a patch for this.

Do note that this patch will make nodejs cross-bd-uninstallable, because
libnghttp2-dev is needed for both architectures, but not marked
Multi-Arch: same. That's a separate problem reported as #996415. The
patch will not make nodejs natively bd-uninstallable, so it is safe to
apply it now.

Helmut
diff --minimal -Nru nodejs-12.22.7~dfsg/debian/changelog 
nodejs-12.22.7~dfsg/debian/changelog
--- nodejs-12.22.7~dfsg/debian/changelog2021-10-13 00:43:20.0 
+0200
+++ nodejs-12.22.7~dfsg/debian/changelog2021-10-13 18:24:43.0 
+0200
@@ -1,3 +1,10 @@
+nodejs (12.22.7~dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add native build dependencies for cross compiling. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 13 Oct 2021 18:24:43 +0200
+
 nodejs (12.22.7~dfsg-1) unstable; urgency=medium
 
   * New upstream version 12.22.7~dfsg
diff --minimal -Nru nodejs-12.22.7~dfsg/debian/control 
nodejs-12.22.7~dfsg/debian/control
--- nodejs-12.22.7~dfsg/debian/control  2021-10-12 23:44:40.0 +0200
+++ nodejs-12.22.7~dfsg/debian/control  2021-10-13 18:24:43.0 +0200
@@ -14,13 +14,19 @@
  gyp (>= 0.1~svn1773),
  jq,
  libbrotli-dev,
+ libbrotli-dev:native,
  libc-ares-dev (>= 1.14~),
+ libc-ares-dev:native,
  libhttp-parser-dev (>= 2.9.2~),
  libicu-dev (>= 64.0~),
+ libicu-dev:native,
  libkvm-dev [kfreebsd-any],
  libnghttp2-dev (>= 1.41.0~),
+ libnghttp2-dev:native,
  libssl-dev (>= 1.1.1~),
+ libssl-dev:native,
  libuv1-dev (>= 1.33.0~),
+ libuv1-dev:native,
  node-acorn (>= 6.2.1~),
  openssl (>= 1.1.1~),
  pkg-config,
@@ -29,6 +35,7 @@
  python3-distutils,
  procps,
  zlib1g-dev,
+ zlib1g-dev:native,
 Build-Depends-Indep: node-js-yaml,
  node-marked
 Standards-Version: 4.5.1

Bug#996415: mark libnghttp2-dev Multi-Arch: same

2021-10-13 Thread Helmut Grohne

Source: libnghttp2-dev
Version: 1.43.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:nodejs

nodejs will need to depend on libnghttp2-dev for both build and host
architecture simultaneously. That's very uncommon, but I see little ways
around that requirement. As a consequence, we'll need libnghttp2-dev to
become Multi-Arch: same and it actually is packaged in a way that
enables us just adding the header (as is pointed out by the multiarch
hinter). While at it, we can also mark nghttp2 Multi-Arch: foreign.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru nghttp2-1.43.0/debian/changelog 
nghttp2-1.43.0/debian/changelog
--- nghttp2-1.43.0/debian/changelog 2021-02-13 18:47:24.0 +0100
+++ nghttp2-1.43.0/debian/changelog 2021-10-13 21:31:29.0 +0200
@@ -1,3 +1,11 @@
+nghttp2 (1.43.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libnghttp2-dev Multi-Arch: same. (Closes: #-1)
+  * Mark nghttp2 Multi-Arch: foreign.
+
+ -- Helmut Grohne   Wed, 13 Oct 2021 21:31:29 +0200
+
 nghttp2 (1.43.0-1) unstable; urgency=medium
 
   * New upstream release 1.43.0
diff --minimal -Nru nghttp2-1.43.0/debian/control nghttp2-1.43.0/debian/control
--- nghttp2-1.43.0/debian/control   2021-02-13 18:47:24.0 +0100
+++ nghttp2-1.43.0/debian/control   2021-10-13 21:31:27.0 +0200
@@ -26,6 +26,7 @@
 
 Package: libnghttp2-dev
 Architecture: any
+Multi-Arch: same
 Section: libdevel
 Depends: libnghttp2-14 (= ${binary:Version}), pkg-config, ${misc:Depends}
 Suggests: libnghttp2-doc
@@ -109,6 +110,7 @@
 
 Package: nghttp2
 Architecture: all
+Multi-Arch: foreign
 Depends: nghttp2-client (>= ${binary:Version}),
  nghttp2-proxy (>= ${binary:Version}),
  nghttp2-server (>= ${binary:Version}),

Bug#996414: python-fastimport: autopkgtest regression: 2 failures + lots of RuntimeError: maximum recursion depth exceeded

Source: python-fastimport
Version: 0.9.14-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of python-fastimport the autopkgtest of
python-fastimport fails in testing when that autopkgtest is run with the
binary packages of python-fastimport from unstable. It passes when run
with only packages from testing. In tabular form:

   passfail
python-fastimport  from testing0.9.14-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=python-fastimport

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-fastimport/15927982/log.gz

  File "fastimport/commands.py", line 68, in __str__
return repr(self)
  File "fastimport/commands.py", line 71, in __repr__
return bytes(self).decode('utf8')
  File "fastimport/commands.py", line 68, in __str__
return repr(self)
  File "fastimport/commands.py", line 71, in __repr__
return bytes(self).decode('utf8')
  File "fastimport/commands.py", line 68, in __str__
return repr(self)
  File "fastimport/commands.py", line 71, in __repr__
return bytes(self).decode('utf8')
RuntimeError: maximum recursion depth exceeded

==
FAIL: test_filemodify_file_internal
(fastimport.tests.test_commands.TestFileModifyDisplay)
--
Traceback (most recent call last):
  File "fastimport/tests/test_commands.py", line 341, in
test_filemodify_file_internal
b'M 644 inline foo/bar\ndata 11\nhello world', bytes(c))
AssertionError: 'M 644 inline foo/bar\ndata 11\nhello world' != 'M 644
inline foo/bar'

==
FAIL: test_filemodify_symlink
(fastimport.tests.test_commands.TestFileModifyDisplay)
--
Traceback (most recent call last):
  File "fastimport/tests/test_commands.py", line 346, in
test_filemodify_symlink
b'M 12 inline foo/bar\ndata 3\nbaz', bytes(c))
AssertionError: 'M 12 inline foo/bar\ndata 3\nbaz' != 'M 12
inline foo/bar'

--
Ran 98 tests in 1.922s

FAILED (failures=2, errors=58)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996413: RFS: jgmenu/4.4.0-1 -- Simple X11 menu


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "jgmenu":

 * Package name: jgmenu
   Version : 4.4.0-1
   Upstream Author : Johan Malm
 * URL :https://jgmenu.github.io/
 * License : GPL-2, Expat, LGPL-2+, LGPL-3+, GPL-2+
 * Vcs :https://github.com/mati75/jgmenu
   Section : x11

It builds those binary packages:

  jgmenu - Simple X11 menu
  jgmenu-xfce4-panel-applet - xfce4-panel applet for jgmenu

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/j/jgmenu/jgmenu_4.4.0-1.dsc

Changes since the last upload:

 jgmenu (4.4.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Enable install lx plugin. (Closes: #983907)
   * Bump Standards Version to 4.6.0.
   * Change depends to python3:any.

Regards,
--
  Mateusz Łukasik

Bug#996412: RFS: gxkb/0.9.2-1 -- X11 keyboard indicator and switcher


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gxkb":

 * Package name: gxkb
   Version : 0.9.2-1
   Upstream Author : Dmitriy Poltavchenko
 * URL :https://zen-tools.github.io/gxkb
 * License : GPL-2+, PERMISSIVE, GAP, BSD-3-clause
 * Vcs :https://github.com/mati75/gxkb.git
   Section : x11

It builds those binary packages:

  gxkb - X11 keyboard indicator and switcher

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

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

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

  dget -xhttps://mentors.debian.net/debian/pool/main/g/gxkb/gxkb_0.9.2-1.dsc

Changes since the last upload:

 gxkb (0.9.2-1) unstable; urgency=medium
 .
   * New upstream release.
   * Bump Standards-Version to 4.6.0 (no changes needed)

Regards,
--
  Mateusz Łukasik

Bug#996411: RFS: audacious/4.0.5-2 [RC] -- small and fast audio player which supports lots of formats


Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "audacious":

 * Package name: audacious
   Version : 4.0.5-2
   Upstream Author : [fill in name and email of upstream]
 * URL :https://www.audacious-media-player.org/
 * License : ISC, CC0, BSD-3-clause, BSD-2-clause
 * Vcs :https://salsa.debian.org/multimedia-team/audacious
   Section : sound

It builds those binary packages:

  audacious - small and fast audio player which supports lots of formats
  audacious-dev - audacious development files
  libaudcore5 - audacious core engine library
  libaudgui5 - audacious media player (libaudgui shared library)
  libaudtag3 - audacious media player (libaudtag shared library)
  libaudqt2 - audacious media player (libaudqt shared library)

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/a/audacious/audacious_4.0.5-2.dsc

Changes since the last upload:

 audacious (4.0.5-2) unstable; urgency=medium
 .
   [ Jelmer Vernooĳ ]
   * Set upstream Repository/Repository-Browse fields.
 .
   [ Mateusz Łukasik ]
   * Merge requests for salsa:
 - Describe Qt and GTK options in audacious manpage
 - Fix some issues reported by lintian
   * d/control:
 - Bump Standards-Version to 4.6.0.
 - Bump dh version to 13.
   * Update symbols files - fix FTBFS with gcc-11. (Closes: #983974)

Regards,
--
  Mateusz Łukasik

Bug#996410: Subject: RFS: smplayer/21.8.0-1 -- Complete front-end for MPlayer and mpv


Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "smplayer":

 * Package name: smplayer
   Version : 21.8.0-1
   Upstream Author : Ricardo Villalba
 * URL :http://smplayer.sourceforge.net/
 * License : Expat, LGPL-2+, LGPL-2.1+, BSD-3-clause, GPL-2+, 
BSD-2-clause
 * Vcs :https://salsa.debian.org/multimedia-team/smplayer
   Section : video

It builds those binary packages:

  smplayer - Complete front-end for MPlayer and mpv
  smplayer-l10n - Complete front-end for MPlayer and mpv - translation files

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

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

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

  dget 
-xhttps://mentors.debian.net/debian/pool/main/s/smplayer/smplayer_21.8.0-1.dsc

Changes since the last upload:

 smplayer (21.8.0-1) unstable; urgency=medium
 .
   [ Debian Janitor ]
   * Remove obsolete field Name from debian/upstream/metadata (already present 
in
 machine-readable debian/copyright).
 .
   [ Mateusz Łukasik ]
   * New upstream release.
   * Bumped Standards-Version to 4.6.0, no changes needed

Regards,
--
  Mateusz Łukasik

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

On Wed, 13 Oct 2021 at 20:13:08 +0100, Simon McVittie wrote:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote yes > further discussion.

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the technic

Bug#996409: libstatgen breaks minimac4 autopkgtest: Segmentation fault

Source: libstatgen, minimac4
Control: found -1 libstatgen/1.0.15-1
Control: found -1 minimac4/1.0.2-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libstatgen the autopkgtest of minimac4 fails in
testing when that autopkgtest is run with the binary packages of
libstatgen from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
libstatgen from testing1.0.15-1
minimac4   from testing1.0.2-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of libstatgen to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=libstatgen

https://ci.debian.net/data/autopkgtest/testing/amd64/m/minimac4/15927915/log.gz

autopkgtest [21:29:13]: test run-sample-analysis: [---


 

  Minimac4 - Fast Imputation Based on State Space Reduction HMM
 

   (c) 2014 - Sayantan Das, Christian Fuchsberger, David Hinds
 Mary Kate Wing, Goncalo Abecasis

 Version: 1.0.2;
 Built: 2019-11-05 by Reproducible

 Command Line Options:
   Reference Haplotypes : --refHaps [refPanel.m3vcf.gz], --passOnly,
  --rsid, --referenceEstimates [ON],
  --mapFile [docs/geneticMapFile.b38.map.txt.gz]
  Target Haplotypes : --haps [targetStudy.vcf.gz]
  Output Parameters : --prefix [testRun], --estimate, --nobgzip,
  --vcfBuffer [200], --format [GT,DS],
  --allTypedSites, --meta, --memUsage
Chunking Parameters : --ChunkLengthMb [20.00], --ChunkOverlapMb
[3.00]
  Subset Parameters : --chr [], --start, --end, --window
   Approximation Parameters : --minimac3, --probThreshold [0.01],
  --diffThreshold [0.01], --topThreshold [0.01]
   Other Parameters : --log, --help, --cpus [5], --params
  PhoneHome : --noPhoneHome [ON], --phoneHomeThinning [50]


 URL = http://genome.sph.umich.edu/wiki/Minimac4
 Starting Main Imputation/Estimation Analysis ...

 Performing preliminary check on input parameters...

 --
 PRELIMINARY FILE CHECK

 --

 Checking GWAS haplotype file : targetStudy.vcf.gz

 Gathering variant information ...

Segmentation fault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996401: gnome-shell-extension-prefs: Gnome extensions app fails to open in Wayland but opens in X11

Control: tags -1 + moreinfo

On Wed, 13 Oct 2021 at 11:43:33 -0600, Justin Searle wrote:
> Sometime between the first Sid release of verion 40.* of this extension
> and the current version, it stopped working in Wayland.  It has been
> approximately 1 month since it stopped working.  When I first upgraded
> to 40.*, the new extensions app (since the split from tweaks) was working 
> fine.

This is working fine for me in GNOME 40 and 41 environments (specifically
gnome-shell 40.5+b1 and 41.0-1, with corresponding versions of
gnome-shell-extension-prefs).

Are all packages upgraded to their latest versions from either testing
or unstable? (Specifically, I'm aware of conflicts between libffi7
and libffi8 if libgjs0g and libgirepository-1.0-1 have not both been
upgraded; but they're indirect dependencies, so they don't appear in
your bug report.)

If you run gnome-extensions-app from a terminal, what output does it produce?

smcv

Bug#996407: diamond-aligner breaks proteinortho autopkgtest: diamond failed with code 256

Source: diamond-aligner, proteinortho
Control: found -1 diamond-aligner/2.0.12-1
Control: found -1 proteinortho/6.0.31+dfsg-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of diamond-aligner the autopkgtest of proteinortho
fails in testing when that autopkgtest is run with the binary packages
of diamond-aligner from unstable. It passes when run with only packages
from testing. In tabular form:

   passfail
diamond-alignerfrom testing2.0.12-1
proteinortho   from testing6.0.31+dfsg-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of diamond-aligner
to testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=diamond-aligner

https://ci.debian.net/data/autopkgtest/testing/amd64/p/proteinortho/15931264/log.gz

autopkgtest [02:08:50]: test run-unit-test: [---
*
[1;32mProteinortho[0m with PoFF version 6.0.31 - An orthology
detection tool
*
Detected 2 available CPU threads (adjust this with -cpus), Detected
'blastp+' version 2.11.0+
Checking input files.
Checking test/C.faa... ok
Checking test/C2.faa... ok
Checking test/E.faa... ok
Checking test/L.faa... ok
Checking test/M.faa... ok

[1;32m**Step 1**[0m
Generating indices anyway (forced).
Building database for 'test/C.faa'  (109 sequences)
Building database for 'test/E.faa'  (72 sequences)
Building database for 'test/L.faa'  (40 sequences)
Building database for 'test/M.faa'  (40 sequences)
Building database for 'test/C2.faa' (2 sequences)

[1;32m**Step 2**[0m using blastp+



Running blast analysis: 0% (0/10)


Running blast analysis: 10% (1/10)


Running blast analysis: 20% (2/10)


Running blast analysis: 30% (3/10)


Running blast analysis: 40% (4/10)


Running blast analysis: 50% (5/10)


Running blast analysis: 60% (6/10)


Running blast analysis: 70% (7/10)


Running blast analysis: 80% (8/10)


Running blast analysis: 100% (10/10)


Running blast analysis: 90% (9/10)


Running blast analysis: 100% (10/10)
[OUTPUT] -> written to test_blastp.blast-graph

[1;32m**Step 3**[0m
Clustering by similarity (Proteinortho mode) and 2 cpu core(s).
[OUTPUT] -> Orthologous groups are written to test_blastp.proteinortho.tsv
You can extract the fasta files of each orthology group with
proteinortho_grab_proteins.pl  -tofiles test_blastp.proteinortho.tsv
'test/C.faa' 'test/E.faa' 'test/L.faa' 'test/M.faa' 'test/C2.faa'
 (Careful: This will generate a file foreach line in the file
test_blastp.proteinortho.tsv).
[OUTPUT] -> Orthologous pairs are written to test_blastp.proteinortho-graph
[OUTPUT] -> Summary is written to test_blastp.proteinortho-graph.summary
[OUTPUT] -> Orthologous groups are written to test_blastp.proteinortho.html
[OUTPUT] -> You can extract a xml version of the output using :
proteinortho2xml.pl test_blastp.proteinortho.tsv
>test_blastp.proteinortho.tsv.xml


[1;32mAll finished.[0m
*
[1;32mProteinortho[0m with PoFF version 6.0.31 - An orthology
detection tool
*
Detected 2 available CPU threads (adjust this with -cpus), Detected
'blastp+' version 2.11.0+
Checking input files.
Checking test/C.faa... test/C.faa   109 genes   ok
Checking test/C2.faa... test/C2.faa 2 genes ok
Checking test/E.faa... test/E.faa   72 genesok
Checking test/L.faa... test/L.faa   40 genesok
Checking test/M.faa... test/M.faa   40 genesok

[1;32m**Step 1**[0m
Generating indices anyway (forced).
Building database for 'test/C.faa'  (109 sequences)
Building database for 'test/E.faa'  (72 sequences)
Building database for 'test/L.faa'  (40 sequences)
Building database for 'test/M.faa'  (40 sequences)
Building database for 'test/C2.faa' (2 sequences)

[1;32m**Step 2**[0m using blastp+ with : synteny



Running blast analysis: 0% (0/10)


Running blast analysis: 10% (1/10)


Running blast analysis: 20% (2/10)


Running blast analysis: 30% (3/10)


Running blast analysis: 40% (4/10)


Running blast analysis: 50% (5/10)


Running blast analysis: 60% (6/10)


Running blast analysis: 70% (7/10)


Running blast analysis: 80% (8/10)


Running blast analysis: 100% (10/10)


Running blast analysis: 90% (9/1

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

I'm calling for votes on the following resolution as formal advice from
the Technical Committee (Constitution §6.1.5). There are no non-accepted
amendments, so the options to vote on are "yes" or "further discussion".

begin text to be voted on

Summary
===

There are currently Debian 11 installations with both the merged-/usr and
non-merged-/usr filesystem layouts. All of these installations should
successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
Only after the release of Debian 12 can packages assume that all
installations will be merged-/usr.

Main points:

- We have recommended merged-/usr for Debian 12.
- Moving individual files is not merged-/usr.
- "Symlink farms" are not merged-/usr.
- Upgrading a non-merged-/usr system to Debian 12 needs to work.
- Upgrading a merged-/usr system to Debian 12 needs to work.
- Packages cannot assume all systems are merged-/usr until the Debian 13
development cycle begins.
- Upgrading via apt in the usual way should work.
- Testing and QA systems should be able to avoid this transition, but if
they do, they cannot be upgraded beyond Debian 12.
- A package building incorrectly on a non-merged-/usr system is a bug.
- A package building incorrectly on a merged-/usr system is a bug.
- Please stop moving individual packages' files from the root filesystem
into /usr, at least for now.

Definitions and current status
==

libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
such as lib64 on the amd64 architecture.

Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
/libQUAL that exists are symbolic links to the corresponding directories
below /usr. This results in aliasing between /bin and /usr/bin, and
so on.

In the merged-/usr layout, files whose canonical logical location is
in one of the affected directories on the root filesystem, such as
/bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
the corresponding path below /usr, such as /usr/bin/bash. Each file in
one of the affected directories is accessible via two paths: its canonical
logical location (such as /bin/bash or /usr/bin/env), and the other path
implied by the aliasing (such as /usr/bin/bash or /bin/env).

There are two supported categories of Debian 11 installation, which are
currently considered equally-supported:

- Merged-/usr installations. These were installed with debian-installer
from Debian 10 or later, or installed with debootstrap --merged-usr,
or converted from the non-merged-/usr layout by installing the usrmerge
package, or installed or converted by any similar procedure. They have
the merged-/usr layout.

- Non-merged-/usr installations. These were installed with debian-installer
from Debian 9 or earlier and subsequently upgraded without converting
to merged-/usr, or installed with debootstrap --no-merged-usr, or
converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
utility or any similar procedure. They have the traditional,
non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
those physical paths, and /usr/bin/bash and /bin/env do not exist.

Merged-/usr is not the only filesystem layout that has been proposed for
unifying the root filesystem with /usr. For avoidance of doubt, we do not
consider other filesystem layouts to be implementations of merged-/usr.
In particular, we do not consider these to be implementations of merged-/usr:

- all affected files physically located in /bin, /sbin, /lib and /libQUAL,
with /usr/bin as a symlink to /bin, etc. (this is the reverse of
merged-/usr, and was historically used in the hurd-i386 port)

- a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
historically had their canonical logical location on the root filesystem

- a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
symbolic links such as /bin/env -> /usr/bin/env for all files in the
affected directories, regardless of whether they historically had
their canonical logical location on the root filesystem

[1]:
https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential

Upgrade path from Debian 11 to Debian 12

The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
should only support the merged-/usr layout. This resolution describes
the implications of that decision in more detail.

Debian installations have traditionally had a straightforward upgrade
path between consecutive releases, and the technical committee expects
maintainers to continue this. In the case of #978636, the upgrades we
are interested in are:

- Upgrading from Debian 11 (stable release) to Debian 12 (stable release)

- Upgrading from Debian 11 (stable release) to testing/unstable during the
development cycle that

Bug#996408: libepoxy: autopkgtest failure: No such build data file as "'/tmp/autopkgtest-lxc.08f3y1bd/downtmp/build.XWR/src/meson-private/build.dat'".

Source: libepoxy
Version: 1.5.9-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package libepoxy, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report.

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

Paul

[1] https://qa.debian.org/excuses.php?package=libepoxy

https://ci.debian.net/data/autopkgtest/testing/amd64/libe/libepoxy/15268087/log.gz


autopkgtest [18:51:12]: test upstream-tests: [---

ERROR: No such build data file as
"'/tmp/autopkgtest-lxc.08f3y1bd/downtmp/build.XWR/src/meson-private/build.dat'".
autopkgtest [18:51:13]: test upstream-tests: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996406: python-pyramid breaks python-pyramid-chameleon autopkgtest: No module named 'pyramid.compat'

Source: python-pyramid, python-pyramid-chameleon
Control: found -1 python-pyramid/2.0+dfsg-1
Control: found -1 python-pyramid-chameleon/0.3-4
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of python-pyramid the autopkgtest of
python-pyramid-chameleon fails in testing when that autopkgtest is run
with the binary packages of python-pyramid from unstable. It passes when
run with only packages from testing. In tabular form:

  passfail
python-pyramidfrom testing2.0+dfsg-1
python-pyramid-chameleon  from testing0.3-4
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of python-pyramid to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=python-pyramid

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pyramid-chameleon/15940595/log.gz

Failure: ModuleNotFoundError (No module named 'pyramid.compat') ... ERROR
Failure: ModuleNotFoundError (No module named 'pyramid.compat') ... ERROR

==
ERROR: Failure: ModuleNotFoundError (No module named 'pyramid.compat')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in
loadTestsFromName
module = self.importer.importFromPath(
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.9/imp.py", line 234, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.9/imp.py", line 171, in load_source
module = _load(spec)
  File "", line 711, in _load
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in
_call_with_frames_removed
  File
"/usr/lib/python3/dist-packages/pyramid_chameleon/tests/test_text.py",
line 4, in 
from pyramid.compat import binary_type
ModuleNotFoundError: No module named 'pyramid.compat'

==
ERROR: Failure: ModuleNotFoundError (No module named 'pyramid.compat')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 416, in
loadTestsFromName
module = self.importer.importFromPath(
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.9/imp.py", line 234, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.9/imp.py", line 171, in load_source
module = _load(spec)
  File "", line 711, in _load
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in
_call_with_frames_removed
  File
"/usr/lib/python3/dist-packages/pyramid_chameleon/tests/test_zpt.py",
line 5, in 
from pyramid.compat import text_type
ModuleNotFoundError: No module named 'pyramid.compat'

--
Ran 32 tests in 0.155s

FAILED (errors=2)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996405: ITP: hed -- A command-line tool to easily manage you hosts file.

2021-10-13 Thread Arjen Wiersma

Package: wnpp
Severity: wishlist
Owner: Arjen Wiersma 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: hed
  Version : 0.1.4
  Upstream Author : Arjen Wiersma 
* URL : https://github.com/credmp/hed
* License : GPLv3
  Programming Lang: Rust
  Description : A command-line tool to easily manage you hosts file.

hed allows you to manipulate your hosts file from the command-line. By 
providing safe and easy commands you can add new hosts and aliases to your 
environment.

This tool was inspired by my students to whom I teach a Basic Cyber Security 
class. In this class we utilize Hack The Box as a learning platform and most 
students struggle with editing the hosts file when they get started. To make 
this easier for them I wrote a tool that gives them a safe means of adding and 
removing hosts in this file.

The tool is to be used as a regular user, it will elevate privileges when it 
requires it by calling sudo and respawning the process.

I personally maintain this package and it has wide usage among my university 
students. It has proven exceptionally useful when interacting with unknown 
networks such as Hack The Box or any network where DNS availability is limited. 
I have the resources to actively maintain the package.

Bug#996404: ruby-sassc-rails: FTBFS: ERROR: Test "ruby3.0" failed.

2021-10-13 Thread Antonio Terceiro

Source: ruby-sassc-rails
Version: 2.1.2-5+rebuild1633394876
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-sassc-rails/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -e gem\ \"sassc-rails\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-sassc-rails/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-sassc-rails/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.0 -w -I"test" 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb 
> "test/sassc_rails_test.rb" "test/test_helper.rb" -v
> /<>/test/sassc_rails_test.rb:125: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:126: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:127: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:128: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:129: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:130: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:131: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:132: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:133: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:134: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:135: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:136: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:137: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:138: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:139: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:140: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:144: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:145: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:147: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:149: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a space after `/' 
> operator
> /<>/test/sassc_rails_test.rb:150: warning: ambiguity between 
> regexp and two divisions: wrap regexp in parentheses or add a spac

Bug#996403: ruby-rails-controller-testing: FTBFS: ERROR: Test "ruby3.0" failed.

2021-10-13 Thread Antonio Terceiro

Source: ruby-rails-controller-testing
Version: 1.0.5-1+rebuild1633392495
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-rails-controller-testing/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -e gem\ \"rails-controller-testing\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-rails-controller-testing/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.0 -w -I"test" 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb 
> "test/controllers/assigns_test.rb" 
> "test/controllers/template_assertions_test.rb" 
> "test/helpers/template_assertions_test.rb" 
> "test/integration/template_assertions_test.rb" "test/test_helper.rb" -v
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:496:in
>  `materialize': Could not find racc-1.4.16 in any of the sources 
> (Bundler::GemNotFound)
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/definition.rb:234:in
>  `specs_for'
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/runtime.rb:18:in
>  `setup'
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler.rb:149:in 
> `setup'
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/setup.rb:20:in
>  `block in '
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/ui/shell.rb:136:in
>  `with_level'
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/ui/shell.rb:88:in
>  `silence'
>   from 
> /usr/share/rubygems-integration/all/gems/bundler-2.2.27/lib/bundler/setup.rb:20:in
>  `'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /<>/test/dummy/config/boot.rb:4:in `'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /<>/test/dummy/config/application.rb:1:in ` (required)>'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /<>/test/dummy/config/environment.rb:2:in ` (required)>'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /<>/test/test_helper.rb:4:in `'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /<>/test/controllers/assigns_test.rb:1:in ` (required)>'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb:17:in 
> `block in '
>   from 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb:5:in 
> `select'
>   from 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb:5:in 
> `'
> rake aborted!
> Command failed with status (1): [ruby -w -I"test" 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb 
> "test/controllers/assigns_test.rb" 
> "test/controllers/template_assertions_test.rb" 
> "test/helpers/template_assertions_test.rb" 
> "test/integration/template_assertions_test.rb" "test/test_helper.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed.


The full build log is available from:
http://qa-logs.debian.net/2021/10/13/ruby-rails-controller-testing_1.0.5-1+rebuild1633392495_amd64.log

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

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.


signature.asc
Descript

Bug#995842: notmuch-slurp-*debbug: Please add config key and code to tag slurped bugs (or document alternative solution)

2021-10-13 Thread Sean Whitton

Hello,

On Wed 06 Oct 2021 at 04:26PM -04, Nicholas D Steeves wrote:

> Package: mailscripts
> Version: 0.23-1
> Severity: wishlist
>
> At this time mailscripts does not tag slurped bugs.  Please consider
> adding a config key and code to tag slurped bugs, or document how
> to use $XDG_CONFIG_HOME/mailscripts/notmuch-slurp-debbug when setting
> up a post-new or post-insert hook.
>
> A minimal solution might be to recommend using a post-new or
> post-insert hook in notmuch-slurp-debbug(1).

Sounds useful.  Patches welcome.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-13 Thread Sean Whitton

Hello Simon,

On Tue 05 Oct 2021 at 07:48PM +01, Simon McVittie wrote:

> On Sun, 03 Oct 2021 at 16:52:15 -0700, Sean Whitton wrote:
>> On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:
>> > On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
>> >> (1) The reason for this, to put it a bit simplistically, is that we
>> >> don't require apt to perform the upgrade between stable releases in any
>> >> particular order, right?  Or are there other reasons distinct from this
>> >> one that I'm missing?  I think it would be good to state the thing about
>> >> apt (in better language than mine) in the text.
>> >
>> > I think that's the main reason. We have not traditionally mandated
>> > the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
>> > so the upgrade happens in whatever order apt chooses, which can vary
>> > between machines.
>> >
>> > Another reason why I think we want Debian 12 packages to be installable
>> > onto non-merged-/usr systems is that to be able to do our development work,
>> > they need to be installable onto testing/unstable systems, which (again)
>> > means that the upgrade order is undefined.
>>
>> Right, we're on the same page then, but would you agree with me that the
>> resolution should state this justification explicitly?
>
> I hope that
> 
> implements this to your satisfaction. If not, suggestions for better
> wording welcome - I would prefer not to be the only one writing this
> document!

Thanks, yes, this addresses my feedback.

I've pushed some wording tweaks.  Hope you don't mind me not filing a
MR -- seemed uncontroversial so thought I'd just push.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#991962: src: prefix should work also with experimental source only



Ok I got it. My apt config was missing the corresponding 'deb-src' for the
experimental release and so apt-cache does not found it.
I suspect that taking into account the 'Source:' field could not be a nicer
(less restrictive) solution.
Feel free to close this issue then.
Thanks!

Bug#996398: libkdecorations2-5v5: experimental version is instalable and breaks unstable

2021-10-13 Thread Patrick Franz

Hi Eric,

why did you upgrade this package ? You should never upgrade a package 
from experimental blindly.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#994289: fail2ban: On start and stop, emails go to root@localhost like it was on Debian 10, but also to nonexistant addresses set and escape:

2021-10-13 Thread Mike Gerber


Hi Olaf,

I can't confirm this on my systems, and I suspect that your mail command 
is something that doesn't understand "-E 'set escape'". Could you check 
what your mail command points to?


Here it is bsd-mailx:

# ls -l /usr/bin/mail lrwxrwxrwx 1 root root 22 Aug  4  2012 
/usr/bin/mail -> /etc/alternatives/mail

# ls -l /etc/alternatives/mail
lrwxrwxrwx 1 root root 18 Aug  4  2012 /etc/alternatives/mail -> 
/usr/bin/bsd-mailx


Cheers,
Mike

Bug#994951: rar: NMU 5.5.0-1.1

2021-10-13 Thread Martin Meredith

Had a quick look, and looks good to me.

Re: comment about unrar - there is unrar and unrar-nonfree packages using the 
alternatives mechanism already, so this could be provided as an alternative, 
but I doubt it’s worthwhile

> On 13 Oct 2021, at 18:36, Bastian Germann  wrote:
> 
> I am going to upload a new revision (debdiff enclosed).
> The maintainer is on LowThresholdNmu.
diff -Nru rar-5.5.0/debian/changelog rar-5.5.0/debian/changelog
--- rar-5.5.0/debian/changelog  2017-08-29 12:10:31.0 +0200
+++ rar-5.5.0/debian/changelog  2021-10-13 18:51:43.0 +0200
@@ -1,3 +1,15 @@
+rar (2:5.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP-5 copyright file with licenses fixed (Closes: #994951)
+  * Package unrar again for distribution permission compliance (Closes: 
#994956)
+  * Exclude txt files from compression so they are untouched
+  * Update Debian's manpage (Closes: #995001)
+  * Remove autobuild tag (Closes: #862028)
+  * d/watch: Make the package a MUT (download both origtars)
+
+ -- Bastian Germann   Wed, 13 Oct 2021 18:51:43 +0200
+
 rar (2:5.5.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru rar-5.5.0/debian/control rar-5.5.0/debian/control
--- rar-5.5.0/debian/control2017-05-04 04:52:05.0 +0200
+++ rar-5.5.0/debian/control2021-10-13 18:41:25.0 +0200
@@ -4,8 +4,7 @@
 Maintainer: Martin Meredith 
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.8
-Homepage: http://www.rarlabs.com/
-XS-Autobuild: yes
+Homepage: https://www.rarlabs.com/
 
 Package: rar
 Architecture: i386 amd64
diff -Nru rar-5.5.0/debian/copyright rar-5.5.0/debian/copyright
--- rar-5.5.0/debian/copyright  2017-05-04 04:52:05.0 +0200
+++ rar-5.5.0/debian/copyright  2021-10-13 18:51:43.0 +0200
@@ -1,150 +1,202 @@
-This package was debianized by Petr Cech  on
-Sat, 16 May 1998 11:35:01 +0200.
-Changes to Debian Package made by Martin Meredith 
-
-This package is Auto-Buildable
-
-It was downloaded from http://www.rarlab.com/rar/
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment: This package was debianized by Petr Cech  on
+ Sat, 16 May 1998 11:35:01 +0200.
+ Changes to Debian Package made by Martin Meredith 
+Upstream-Name: rar
+Upstream-Contact: https://www.win-rar.com/contact.html
+Source: http://www.rarlab.com/download.htm
+
+Files: *
+Copyright: Copyright (c) 1993-2017 Alexander Roshal 
+Comment: This software is shareware.
+License: RAR-EULA
+
+Files:
+ *default.sfx
+ *rar
 Copyright:
-Copyright (c) 1993-2006 Alexander Roshal 
-
-This software is shareware.
-
-  The RAR Archiver
-  EULA (End User License Agreement) for use and distribution
-
-
-  The RAR archiver is distributed as try before you buy. This means:
-
-   1. All copyrights to RAR are exclusively owned by the author
-  - Alexander Roshal.
-
-   2. Anyone may use this software during a test period of 40 days.
-  Following this test period of 40 days or less, if you wish to
-  continue to use RAR, you must purchase a license.
-
-   3. There are 2 basic types of licenses issued for RAR, these are:
- 
-  a.  A single computer usage license. The user purchases one license
-  to use RAR archiver on one computer.
-
-  Home users may use their single computer usage license on
-  all computers which are in property of the license owner.
-
-  Business users require one license per computer RAR is
-  installed on.
-
-  b.  A multiple usage license. The user purchases a number of usage
-  licenses for use, by the purchaser or the purchaser's employees
-  on the same number of computers.
-
-  In a network (server/client) environment you must purchase
-  a license copy for each separate client (workstation)
-  on which RAR is installed, used, or accessed. A separate
-  license copy for each client (workstation) is needed regardless
-  of whether the clients (workstations) will use RAR simultaneously
-  or at different times. If for example you wish to have
-  9 different clients (workstations) in your network with access
-  to RAR, you must purchase 9 license copies.
-
-  A user who purchased a RAR license, is granted a non-exclusive
-  right to use RAR on as many computers as defined by the licensing
-  terms above according to the number of licenses purchased,
-  for any legal purpose. The licensed RAR software may not be rented
-  or leased, but may be permanently transferred, in it's entirety,
-  if the person receiving it agrees to the terms of this license.
-  If the software is an update, the transfer must include the update
-  and all previous versions.  
-
-   4. Licensing for RAR on mobile devices (U3 stick, USB stick,
-  external harddrive):
-
-  In addition to the terms stated above following licensing terms
-  apply to the licensing of

Bug#996402: asterisk-modules: MP3 playback does not work due to incompatibility with mpg123

2021-10-13 Thread Jens Bürger

Package: asterisk-modules
Version: 1:16.16.1~dfsg-1
Severity: important
X-Debbugs-Cc: jbuer...@arcor.de

Dear Maintainer,



   * What led up to the situation?

Upgrading a system from buster to bullseye.

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

The system in question makes use of MP3Player and Playback in its dialplan to
playback MP3 files. After upgrading to bullseye, the same application/files 
being
played back only led to a terrible noise instead of the expected audio.

I found this solved issue at Asterisk:

https://issues.asterisk.org/jira/browse/ASTERISK-29635

Apparently, newer mpg123 versions (as the one currently part of the Debian repo)
have 32 bits default outpout, whereas Asterisk expects 16 bits. This can be
solved by adding a respective option to the call of mpg123.

This has been solved in Asterisk 16.21 by a little change to app_mp3.

Please consider applying the patch, because, currently, using the "stock" 
Asterisk
and mpg123 as provided in bullseye leads to non-working MP3 playback
functionalities in Asterisk.

Kind regards,
Jens



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

Kernel: Linux 5.10.0-9-amd64 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 asterisk-modules depends on:
ii  libasound21.2.4-1.1
ii  libc6 2.31-13+deb11u2
ii  libcurl4  7.74.0-1.3+b1
ii  libglib2.0-0  2.66.8-1
ii  libgmime-3.0-03.2.7-1
ii  libgsm1   1.0.18-2
ii  libical3  3.0.9-2
ii  libiksemel3   1.4-3+b2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libldap-2.4-2 2.4.57+dfsg-3
ii  liblua5.1-0   5.1.5-8.1+b3
ii  libneon27-gnutls  0.31.2-1
ii  libodbc1  2.3.6-0.1+b1
ii  libogg0   1.3.4-0.1
ii  libportaudio2 19.6.0-1.1
ii  libpq513.4-0+deb11u1
ii  libradcli41.2.11-1+b2
ii  libresample1  0.1.3-4+b2
ii  libsnmp40 5.9+dfsg-3+b1
ii  libspandsp2   0.0.6+dfsg-2
ii  libspeex1 1.2~rc1.2-1.1
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libsqlite3-0  3.34.1-3
ii  libsrtp2-12.3.0-5
ii  libssl1.1 1.1.1k-1+deb11u1
ii  libsybdb5 1.2.3-1
ii  libunbound8   1.13.1-1
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libxml2   2.9.10+dfsg-6.7
ii  zlib1g1:1.2.11.dfsg-2

asterisk-modules recommends no packages.

asterisk-modules suggests no packages.

-- no debconf information

Bug#944739: fail2ban must not email start stop actions by default

2021-10-13 Thread Mike Gerber


Control: found -1 0.11.2-2

Not sure what you mean with this bug. 
Could you please share more details?


Sergio probably meant these messages you get when you activate a 
banaction involving mails:




Date: Wed, 13 Oct 2021 19:30:01 +0200
From: Fail2Ban 
To: root@localhost
Subject: [Fail2Ban] recidive: started on mail.redacted.invalid

Hi,

The jail recidive has been started successfully.

Regards,

Fail2Ban



I haven't figured out yet why I get these because I just activated mail 
on ban. They sure are annoying and I don't see much of a point.

Bug#996399: manpages-(de|es|fr|pl)-dev: missing Breaks+Replaces: manpages-\1 (<< 4.11)

Followup-For: Bug #996399

Please note that *-pl* needs the epoch in the version:
manpages-pl-dev needs Breaks+Replaces: manpages-pl (<< 1:4.11)

Andreas

Bug#996401: gnome-shell-extension-prefs: Gnome extensions app fails to open in Wayland but opens in X11

2021-10-13 Thread Justin Searle

Package: gnome-shell-extension-prefs
Version: 40.5-1+b1
Severity: important
X-Debbugs-Cc: deb...@meeas.com

Dear Maintainer,

Sometime between the first Sid release of verion 40.* of this extension
and the current version, it stopped working in Wayland.  It has been
approximately 1 month since it stopped working.  When I first upgraded
to 40.*, the new extensions app (since the split from tweaks) was working fine.

Today I decided to dig into it.  Here is what I've tried: 

 - I am unable to test the experimental version 41.* on this machine because of 
 current critical bugs gnome-shell from the bug reports.

 - Running 'journalctl -f' reveals no messages when trying to start the 
 extensions app from gui or commandline

 - Trying to rule out user configs, I created a new user but extensions
   app still did not load

 - I switched from Wayland to X11 and extensions app works fine

 - Changed back to Wayland and extensions app failed to work again

If you can't recreate the issue on Wayland, I'm happy to try other
suggestions you may have.



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

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

Versions of packages gnome-shell-extension-prefs depends on:
ii  gir1.2-gtk-4.0  4.4.0+ds1-5
ii  gnome-shell 40.5-1+b1
ii  gnome-shell-common  40.5-1

Versions of packages gnome-shell-extension-prefs recommends:
ii  chrome-gnome-shell  10.1-5

gnome-shell-extension-prefs suggests no packages.

-- no debconf information

Bug#994055: cunit: FTBFS: format not a string literal and no format arguments [-Werror=format-security]

2021-10-13 Thread Sven Joachim

Control: tags -1 + patch

On 2021-09-10 19:37 +0200, Sven Joachim wrote:

> Source: cunit
> Version: 2.1-3-dfsg-2.3
> Severity: serious
> Tags: ftbfs bookworm sid
>
> Your package FTBFS with libncurses-dev 6.2+20210905-1, as several
> mvwprintw() calls now trigger format warnings from gcc which
> dpkg-buildflags turns into errors thanks to -Werror=format-security:
>
> ,
> | Curses.c: In function 'show_suite_level_help':
> | Curses.c:955:37: error: format not a string literal and no format arguments 
> [-Werror=format-security]
> |   955 |   mvwprintw(details_pad.pPad, 0, 0, szTemp);
> |   | ^~
> | Curses.c:959:37: error: format not a string literal and no format arguments 
> [-Werror=format-security]
> |   959 |   mvwprintw(details_pad.pPad, 2, 0, szTemp);
> |   | ^~
> | Curses.c: In function 'list_tests':
> | Curses.c:1071:37: error: format not a string literal and no format 
> arguments [-Werror=format-security]
> |  1071 |   mvwprintw(details_pad.pPad, 0, 0, szTemp);
> |   | ^~
> | Curses.c:1078:37: error: format not a string literal and no format 
> arguments [-Werror=format-security]
> |  1078 |   mvwprintw(details_pad.pPad, 1, 0, szTemp);
> |   | ^~
> | Curses.c: In function 'curses_set_options_run':
> | Curses.c:1161:39: error: format not a string literal and no format 
> arguments [-Werror=format-security]
> |  1161 | mvwprintw(details_pad.pPad, 2, 0, szTemp);
> |   |   ^~
> | cc1: some warnings being treated as errors
> `
>
> A full build log is at [1].
>
> See #993179 for the change in ncurses which lead to these new errors.
>
>
> 1. 
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cunit/15168126/log.gz

The attached patch fixes that by adding "%s" as penultimate argument to
the mvwprintw calls, it can be added to the series in debian/patches.

From 2bd9d8d7967e574ed7e76084025a2e29faf97532 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 13 Oct 2021 19:23:18 +0200
Subject: [PATCH] Fix string format errors with recent ncurses

---
 CUnit/Sources/Curses/Curses.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/CUnit/Sources/Curses/Curses.c b/CUnit/Sources/Curses/Curses.c
index 17eaa30..3876e67 100644
--- a/CUnit/Sources/Curses/Curses.c
+++ b/CUnit/Sources/Curses/Curses.c
@@ -952,11 +952,11 @@ static void show_suite_level_help(CU_pSuite pSuite)

   snprintf(szTemp, STRING_LENGTH,   _("Commands:  R - run all tests in suite %s"),
 pSuite->pName);
-  mvwprintw(details_pad.pPad, 0, 0, szTemp);
+  mvwprintw(details_pad.pPad, 0, 0, "%s", szTemp);
   mvwprintw(details_pad.pPad, 1, 0, _("   S - Select and run a test"));
   snprintf(szTemp, STRING_LENGTH,   _("   L - List all tests registered in suite %s"),
 pSuite->pName);
-  mvwprintw(details_pad.pPad, 2, 0, szTemp);
+  mvwprintw(details_pad.pPad, 2, 0, "%s", szTemp);
   mvwprintw(details_pad.pPad, 3, 0, _("   A - Activate or deactivate a test (toggle)"));
   mvwprintw(details_pad.pPad, 4, 0, _("   F - Show failures from last test run"));
   mvwprintw(details_pad.pPad, 5, 0, _("   M - Move up to main menu"));
@@ -1068,14 +1068,14 @@ static void list_tests(CU_pSuite pSuite)
   }

   snprintf(szTemp, STRING_LENGTH, "%s: %s", _("Suite"), pSuite->pName);
-  mvwprintw(details_pad.pPad, 0, 0, szTemp);
+  mvwprintw(details_pad.pPad, 0, 0, "%s", szTemp);

   snprintf(szTemp, STRING_LENGTH,
"%*s  %-*s%*s",
width[0], _("#"),
width[1], _("Test Name"),
width[2], _("Active?"));
-  mvwprintw(details_pad.pPad, 1, 0, szTemp);
+  mvwprintw(details_pad.pPad, 1, 0, "%s", szTemp);

   for (i = 0, pCurTest = pSuite->pTest ;
NULL != pCurTest ;
@@ -1158,7 +1158,7 @@ static STATUS curses_set_options_run(void)

 snprintf(szTemp, STRING_LENGTH,   _("   1 - Inactive suites/tests treated as runtime failures %s"),
   (CU_FALSE != CU_get_fail_on_inactive()) ? _("Yes") : _("No "));
-mvwprintw(details_pad.pPad, 2, 0, szTemp);
+mvwprintw(details_pad.pPad, 2, 0, "%s", szTemp);
 refresh_details_window();
 read_input_string(_("Enter number of option to change : "), szTemp, STRING_LENGTH);
 option_num = atol(szTemp);
--
2.33.0

Bug#996397:

2021-10-13 Thread Rich

Just to be clear, my actual problem is that things like:
rpm --eval '%{python_version}'
rpm --eval '%{__python}'

Do not do either what they do on recent RPM-based distros:
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly

Or on, say, older Debian:
2.7
/usr/bin/python

But instead just:
%{python_version}
%{__python}

I could be entirely off-base about why this is. I only spent so long on it.

But it certainly broke some expectations.

- Rich

Bug#996400: ITP: pyvkfft -- Python3 binding to the CUDA and OpenCL backends of VkFFT

2021-10-13 Thread Roland Mas

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pyvkfft
  Version : 2021.2.1
  Upstream Author : Vincent Favre-Nicolin 
* URL : https://github.com/vincefn/pyvkfft
* License : MIT
  Programming Lang: C++/Python
  Description : Python3 binding to the CUDA and OpenCL backends of VkFFT

pyvkfft offers a simple python interface to the CUDA and OpenCL
backends of VkFFT, compatible with pyCUDA, CuPy and pyOpenCL.

Bug#991962: src: prefix should work also with experimental source only

Le dimanche 19 septembre 2021 à 11:06 +0200, Nis Martensen a écrit :
> On 06 Aug 2021 Patrice Duroux wrote:
> > 
> > $ reportbug src:gtk4
> > 
> > W: Unable to locate package gtk4
> 
> Reportbug calls apt-cache to look up packages. The warning you received
> about the failed package lookup is in fact produced by apt-cache.
> 
> Not sure how reportbug can know about packages if even apt does not know
> about them yet. Do you have a suggestion?

Hi,
Sorry for the delay.
Sure I have no clue then if it possible to have some binary packages installed
using apt without their source package being known by apt-cache. That is just
more strange to me.
At that time, gtk4 was only available in experimental and I was suspecting a bug
due to such a case. I will search in experimental to check for another case like
this one now that gtk4 is in unstable.

Bug#994951: rar: NMU 5.5.0-1.1

2021-10-13 Thread Bastian Germann


I am going to upload a new revision (debdiff enclosed).
The maintainer is on LowThresholdNmu.
diff -Nru rar-5.5.0/debian/changelog rar-5.5.0/debian/changelog
--- rar-5.5.0/debian/changelog  2017-08-29 12:10:31.0 +0200
+++ rar-5.5.0/debian/changelog  2021-10-13 18:51:43.0 +0200
@@ -1,3 +1,15 @@
+rar (2:5.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP-5 copyright file with licenses fixed (Closes: #994951)
+  * Package unrar again for distribution permission compliance (Closes: 
#994956)
+  * Exclude txt files from compression so they are untouched
+  * Update Debian's manpage (Closes: #995001)
+  * Remove autobuild tag (Closes: #862028)
+  * d/watch: Make the package a MUT (download both origtars)
+
+ -- Bastian Germann   Wed, 13 Oct 2021 18:51:43 +0200
+
 rar (2:5.5.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru rar-5.5.0/debian/control rar-5.5.0/debian/control
--- rar-5.5.0/debian/control2017-05-04 04:52:05.0 +0200
+++ rar-5.5.0/debian/control2021-10-13 18:41:25.0 +0200
@@ -4,8 +4,7 @@
 Maintainer: Martin Meredith 
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.8
-Homepage: http://www.rarlabs.com/
-XS-Autobuild: yes
+Homepage: https://www.rarlabs.com/
 
 Package: rar
 Architecture: i386 amd64
diff -Nru rar-5.5.0/debian/copyright rar-5.5.0/debian/copyright
--- rar-5.5.0/debian/copyright  2017-05-04 04:52:05.0 +0200
+++ rar-5.5.0/debian/copyright  2021-10-13 18:51:43.0 +0200
@@ -1,150 +1,202 @@
-This package was debianized by Petr Cech  on
-Sat, 16 May 1998 11:35:01 +0200.
-Changes to Debian Package made by Martin Meredith 
-
-This package is Auto-Buildable
-
-It was downloaded from http://www.rarlab.com/rar/
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment: This package was debianized by Petr Cech  on
+ Sat, 16 May 1998 11:35:01 +0200.
+ Changes to Debian Package made by Martin Meredith 
+Upstream-Name: rar
+Upstream-Contact: https://www.win-rar.com/contact.html
+Source: http://www.rarlab.com/download.htm
+
+Files: *
+Copyright: Copyright (c) 1993-2017 Alexander Roshal 
+Comment: This software is shareware.
+License: RAR-EULA
+
+Files:
+ *default.sfx
+ *rar
 Copyright:
-Copyright (c) 1993-2006 Alexander Roshal 
-
-This software is shareware.
-
-  The RAR Archiver
-  EULA (End User License Agreement) for use and distribution
-
-
-  The RAR archiver is distributed as try before you buy. This means:
-
-   1. All copyrights to RAR are exclusively owned by the author
-  - Alexander Roshal.
-
-   2. Anyone may use this software during a test period of 40 days.
-  Following this test period of 40 days or less, if you wish to
-  continue to use RAR, you must purchase a license.
-
-   3. There are 2 basic types of licenses issued for RAR, these are:
- 
-  a.  A single computer usage license. The user purchases one license
-  to use RAR archiver on one computer.
-
-  Home users may use their single computer usage license on
-  all computers which are in property of the license owner.
-
-  Business users require one license per computer RAR is
-  installed on.
-
-  b.  A multiple usage license. The user purchases a number of usage
-  licenses for use, by the purchaser or the purchaser's employees
-  on the same number of computers.
-
-  In a network (server/client) environment you must purchase
-  a license copy for each separate client (workstation)
-  on which RAR is installed, used, or accessed. A separate
-  license copy for each client (workstation) is needed regardless
-  of whether the clients (workstations) will use RAR simultaneously
-  or at different times. If for example you wish to have
-  9 different clients (workstations) in your network with access
-  to RAR, you must purchase 9 license copies.
-
-  A user who purchased a RAR license, is granted a non-exclusive
-  right to use RAR on as many computers as defined by the licensing
-  terms above according to the number of licenses purchased,
-  for any legal purpose. The licensed RAR software may not be rented
-  or leased, but may be permanently transferred, in it's entirety,
-  if the person receiving it agrees to the terms of this license.
-  If the software is an update, the transfer must include the update
-  and all previous versions.  
-
-   4. Licensing for RAR on mobile devices (U3 stick, USB stick,
-  external harddrive):
-
-  In addition to the terms stated above following licensing terms
-  apply to the licensing of RAR on mobile devices.
-
-  a.  A single computer usage license. Home users may use their
-  single computer usage license on all mobile devices which are
-  in property of the license owner.
-
-  Business users may use their single computer usage license
-

Bug#996399: manpages-(de|es|fr|pl)-dev: missing Breaks+Replaces: manpages-\1 (<< 4.11)

Package: manpages-de-dev,manpages-es-dev,manpages-fr-dev,manpages-pl-dev
Version: 4.11.0-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Preparing to unpack .../manpages-de-dev_4.11.0-1.1_all.deb ...
  Unpacking manpages-de-dev (4.11.0-1.1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/manpages-de-dev_4.11.0-1.1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/de/man4/console_ioctl.4.gz', which is 
also in package manpages-de 4.10.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/manpages-de-dev_4.11.0-1.1_all.deb


The following files do have these conflicts:

usr/share/man/de/man4/console_ioctl.4.gz
usr/share/man/de/man4/tty_ioctl.4.gz
usr/share/man/es/man4/console_ioctl.4.gz
usr/share/man/fr/man4/console_ioctl.4.gz
usr/share/man/fr/man4/tty_ioctl.4.gz
usr/share/man/pl/man4/console_ioctl.4.gz


cheers,

Andreas


manpages-de=4.10.0-1_manpages-de-dev=4.11.0-1.1.log.gz
Description: application/gzip

Bug#996395: SyntaxError: invalid syntax



Already reported upstream: https://github.com/lutris/lutris/issues/3738

Bug#996398: libkdecorations2-5v5: experimental version is instalable and breaks unstable

2021-10-13 Thread Eric Valette

Package: libkdecorations2-5v5
Version: 4:5.22.90-1
Severity: important

Please add a dependency that prevent upgrading. You cannot even log afetr sddm 
restart.


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

Kernel: Linux 5.10.72 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libkdecorations2-5v5 depends on:
ii  libc6 2.33-0experimental2
ii  libkdecorations2private9  4:5.22.90-1
ii  libkf5i18n5   5.86.0-1
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libstdc++611.2.0-9

libkdecorations2-5v5 recommends no packages.

libkdecorations2-5v5 suggests no packages.

-- no debconf information

Bug#994194: hexcurse FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

2021-10-13 Thread Sven Joachim

Control: tags -1 + patch

Am 13.09.2021 um 09:30 schrieb Helmut Grohne:

> Source: hexcurse
> Version: 1.58-1.3
> Severity: serious
> Tags: ftbfs
>
> hexcurse fails to build from source in unstable. A build ends as
> follows:
>
> | gcc -DHAVE_CONFIG_H -I. -I..  -I../include -Wall -Werror -Wextra
> | -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> | -ffile-prefix-map=/<>=. -fstack-protector-strong
> | -Wformat -Werror=format-security -c screen.c
> | screen.c: In function ‘popupWin’:
> | screen.c:490:5: error: format not a string literal and no format arguments 
> [-Werror=format-security]
> |   490 | mvwprintw(tmpwin,2,3, msg);/* output mesg*/
> |   | ^
> | screen.c: In function ‘questionWin’:
> | screen.c:531:5: error: format not a string literal and no format arguments 
> [-Werror=format-security]
> |   531 | mvwprintw(tmpwin,2,3, msg);
> |   | ^
> | cc1: all warnings being treated as errors
> | make[3]: *** [Makefile:258: screen.o] Error 1
> | make[3]: Leaving directory '/<>/src'
> | make[2]: *** [Makefile:266: all-recursive] Error 1
> | make[2]: Leaving directory '/<>'
> | make[1]: *** [Makefile:206: all] Error 2
> | make[1]: Leaving directory '/<>'
> | dh_auto_build: error: make -j1 returned exit code 2
> | make: *** [debian/rules:4: build] Error 25
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2

The attached patch which could be dropped into debian/patches fixes that
by adding "%s" as penultimate argument in the two mvwprintw calls above.
See #993179 for the change in ncurses which triggered these errors.

From 9dec70d033da420ffe77251fc662d9703bf4389e Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 13 Oct 2021 17:46:54 +0200
Subject: [PATCH] Fix string format errors with recent ncurses

---
 src/screen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/screen.c b/src/screen.c
index 5172ccf..f54978b 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -487,7 +487,7 @@ void popupWin(char *msg, int time)

 keypad(tmpwin, TRUE);

-mvwprintw(tmpwin,2,3, msg);/* output mesg*/
+mvwprintw(tmpwin,2,3, "%s", msg);/* output mesg*/
 wmove(tmpwin,2,len+4);
 wrefresh(tmpwin);

@@ -528,7 +528,7 @@ short int questionWin(char *msg)

 tmpwin = drawbox(y, x, 5, len + 6);			/* create window  */

-mvwprintw(tmpwin,2,3, msg);
+mvwprintw(tmpwin,2,3, "%s", msg);
 wmove(tmpwin,2,len+4);
 wrefresh(tmpwin);

--
2.33.0

Bug#996397: rpm-common: macros.* are no longer in any package provided in Debian

2021-10-13 Thread Rich Ercolani

Package: rpm-common
Version: 4.16.1.2+dfsg1-3
Severity: normal

Dear Maintainer,

When debugging why %{python_version} no longer expanded in an alien package,
I discovered that in bullseye and up, the macros.* packages (and their
associated macros) seem entirely absent.

It seems like upstream RPM stopped including them between 4.14.2.1 and 4.15.0.
The alpha changelog [1] notes:
- Remove script language helper macros and associated scripts

And the commit [2] explicitly says:
yes this will break existing packages and force distros to deal
with the fallout, but we believe its for the best:
these macros are also best maintained by people closer to the languages
in question, as has been done with all the newer languages predating
perl and python. rpm-extras exists as the place for maintaining and
collaborating on such material.

- Rich

[1] - https://rpm.org/timeline.html
[2] - 
https://github.com/rpm-software-management/rpm/commit/ba85c95963f9b62f237c0442f6b5aca3e355fa83

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000, 
'stable'), (900, 'oldstable-debug'), (900, 'testing'), (800, 'unstable-debug'), 
(500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'oldstable-proposed-updates-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 rpm-common depends on:
ii  libaudit11:3.0-2
ii  libc62.31-13+deb11u2
ii  libdbus-1-3  1.12.20-2
ii  librpm9  4.16.1.2+dfsg1-3
ii  librpmio94.16.1.2+dfsg1-3
ii  libselinux1  3.1-3

rpm-common recommends no packages.

rpm-common suggests no packages.

-- no debconf information

Bug#996396: ITP: vkfft -- Vulkan/CUDA/HIP/OpenCL Fast Fourier Transform library

2021-10-13 Thread Roland Mas

Package: wnpp
Severity: wishlist
Owner: Roland Mas 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: vkfft
  Version : 1.2.12
  Upstream Author : Dmitrii Tolmachev 
* URL : https://github.com/DTolm/VkFFT
* License : MIT
  Programming Lang: C
  Description : Vulkan/CUDA/HIP/OpenCL Fast Fourier Transform library

VkFFT is an efficient GPU-accelerated multidimensional Fast Fourier
Transform library for Vulkan/CUDA/HIP/OpenCL projects. VkFFT aims to
provide the community with an open-source alternative to Nvidia's
cuFFT library while achieving better performance. VkFFT is written in
C language and supports Vulkan, CUDA, HIP and OpenCL as backends.

Bug#996395: SyntaxError: invalid syntax