Bug#996546: jupyter notebook error "duplicate signature"

[Stefan Huber]

Package: python3-jupyter-client
Version: 6.1.11-2

When running a jupyter notebook that spawns processes, in my case using
multiprocessing.Pool.starmap(), then occasionally the notebook kernel is
hit by an exception complaining about "Duplicate Signature" in
zmqstreams.

The bug is known upstream and there is a commit by 2021-06-07 on master:
https://github.com/jupyter/jupyter_client/pull/655/commits/9ac65f998ec1398a4dd206d8d18f3babf9947d7e

The patch is a one-line change which I manually applied on my system
here, after which the errors disappeared. Although the errors occur
infrequently and are hard to trigger, I have a notebook that spawns many
processes and before applying the patch I could not run the notebook
through without restarting the kernel, say, three to four times.

Bug#993577: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A few dependencies still exist:

Checking reverse dependencies...
# Broken Depends:
bfh-metapackages: bfh-gnome-desktop
progress-linux-metapackages: progress-linux-gnome-desktop

Bug#993368: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A dependency still exists:

Checking reverse dependencies...
# Broken Depends:
openscap-daemon: openscap-daemon

Bug#996535: upgrading from 1.68.4-1 to 1.68.4-1+b1 breaks gnome(oh no! something has gone wrong)

[Brent S. Elmer]

Package: gjs
Version: 1.68.4-1+b1
Severity: normal



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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: 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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gjs depends on:
ii  gir1.2-gtk-3.0  3.24.30-3
ii  libc6   2.32-4
ii  libgcc-s1   11.2.0-8
ii  libgjs0g1.68.4-1+b1
ii  libglib2.0-02.70.0-1+b1
ii  libstdc++6  11.2.0-8

gjs recommends no packages.

gjs suggests no packages.

Bug#996545: python3-discogs-client: Fails to get oauth access token

[intrigeri]

Package: python3-discogs-client
Version: 2.3.5-2
Severity: normal

Hi,

Using beets' discogs plugin from sid, OAuth fails:

   To authenticate with Discogs, visit:
   https://www.discogs.com/oauth/authorize?oauth_token=REDACTED
   Enter the code: REDACTED
   discogs: connection error: Only unicode objects are escapable. Got 
b'REDACTED' of type .
   error: Discogs token request failed

This is upstream issue https://github.com/joalla/discogs_client/issues/22,
fixed by https://github.com/joalla/discogs_client/pull/23,
which has been released in version 2.3.7 in January 2021.

I've applied the upstream fix and I confirm it fixes beets' discogs plugin.

Could you please consider updating this package to a newer
upstream release?

Thanks in advance.

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_USER
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 python3-discogs-client depends on:
ii  python33.9.2-3
ii  python3-certifi2020.6.20-1
ii  python3-chardet4.0.0-1
ii  python3-coverage   5.1+dfsg.1-2+b2
ii  python3-docopt 0.6.2-3
ii  python3-idna   2.10-1
ii  python3-oauthlib   3.1.1-1
ii  python3-pkg-resources  58.2.0-1
ii  python3-requests   2.25.1+dfsg-2
ii  python3-urllib31.26.5-1~exp1
ii  python3-yaml   5.4.1-1

python3-discogs-client recommends no packages.

python3-discogs-client suggests no packages.

-- no debconf information

Bug#996544: ITP: libime-jyutping -- libime to implement jyutping (粵拼) input method.

[YaNing Lu]

Package: wnpp
Severity: wishlist
Owner: Lu YaNing 

* Package name: libime-jyutping
  Version : 1.0.3
  Upstream Author : Xuetian Weng 
* URL : https://github.com/fcitx/libime-jyutping

* License : LGPL-2.1+
  Programming Lang: C++
  Description : libime to implement jyutping (粵拼) input method.

A library make use of libime to implement jyutping (粵拼) input method.

It also includes engine for fcitx 5.

-- 
Thanks,
Lu YaNing

Bug#992819: Reverse dependencies

[Luca Falavigna]

Control: tags -1 + moreinfo


A few dependencies still exist:

Checking reverse dependencies...
# Broken Depends:
kmerresistance: kmerresistance [armel armhf i386 mipsel]
resfinder: resfinder
virulencefinder: virulencefinder

# Broken Build-Depends:
resfinder-db: kma

Bug#990789: LERC compression in TIFF

[Antonio Valentino]

Dear Laszlo,
would you accept a patch for this?


kind regards
antonio

On Wed, 7 Jul 2021 16:02:44 +0200 Antonio Valentino 
 wrote:

Package: tiff
Version: 4.3.0-1

Starting form libtiff v4.3 support for the LERC compression codec has been 
officially integrated into libtiff.
LERC is a very interesting compressor and it is gaining a lot o momentum 
recently.

Please consider to enable the LERC coded in the debian package for libtiff 
(v4.3.0~1 is currently in experimental).


--
Antonio Valentino

Bug#996543: ITP: sphinx-press-theme -- responsive theme for Sphinx documentation generator

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 995905 by -1
X-Debbugs-CC: m...@debian.org

* Package name: sphinx-press-theme
  Version : 0.8.0
  Upstream Author : Eduardo Naufel Schettino and other contributors
* URL : https://github.com/schettino72/sphinx_press_theme
* License : Expat
  Programming Lang: Python
  Description : responsive theme for Sphinx documentation generator
(Python 3)

Sphinx Press is a modern responsive theme for Python's Sphinx docs.
This theme is based on VuePress. It uses Vue.js & Stylus managed by vite.

sphinx-press-theme is required to build opencolorio v2.*.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/sphinx-press-theme

Bug#996541: racon: FTBFS when rebuilt against libedlib1

[Niels Thykier]

Package: racon
Version: 1.4.21-1
Severity: serious
X-Debbugs-Cc: ni...@thykier.net

Hi,

A new version of libedlib (with a new ABI) has been uploaded to
unstable and that causes racon to fail to build from source.

Relevant parts of the amd64 log:

```
> /usr/bin/cmake -E cmake_link_script CMakeFiles/racon_test.dir/link.txt 
> --verbose=1
> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wl,-z,relro -Wl,-z,now -rdynamic 
> CMakeFiles/racon_test.dir/test/racon_test.cpp.o 
> CMakeFiles/racon_test.dir/src/logger.cpp.o 
> CMakeFiles/racon_test.dir/src/polisher.cpp.o 
> CMakeFiles/racon_test.dir/src/overlap.cpp.o 
> CMakeFiles/racon_test.dir/src/sequence.cpp.o 
> CMakeFiles/racon_test.dir/src/window.cpp.o -o bin/racon_test  -lspoa -ledlib 
> -lz /usr/lib/x86_64-linux-gnu/libgtest_main.a 
> /usr/lib/x86_64-linux-gnu/libgtest.a -pthread 
> /usr/bin/ld: CMakeFiles/racon_test.dir/test/racon_test.cpp.o: in function 
> `calculateEditDistance(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string, std::allocator 
> > const&)':
> ./obj-x86_64-linux-gnu/./test/racon_test.cpp:18: undefined reference to 
> `edlibDefaultAlignConfig'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./test/racon_test.cpp:18: undefined 
> reference to `edlibAlign'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./test/racon_test.cpp:22: undefined 
> reference to `edlibFreeAlignResult'
> /usr/bin/ld: CMakeFiles/racon_test.dir/src/overlap.cpp.o: in function 
> `racon::Overlap::align_overlaps(char const*, unsigned int, char const*, 
> unsigned int)':
> ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined reference to 
> `edlibNewAlignConfig'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined 
> reference to `edlibAlign'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:213: undefined 
> reference to `edlibAlignmentToCigar'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:223: undefined 
> reference to `edlibFreeAlignResult'
> collect2: error: ld returned 1 exit status
> make[3]: *** [CMakeFiles/racon_test.dir/build.make:182: bin/racon_test] Error 
> 1
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make[2]: *** [CMakeFiles/Makefile2:88: CMakeFiles/racon_test.dir/all] Error 2
> make[2]: *** Waiting for unfinished jobs
> [100%] Linking CXX executable bin/racon
> /usr/bin/cmake -E cmake_link_script CMakeFiles/racon.dir/link.txt --verbose=1
> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wl,-z,relro -Wl,-z,now -rdynamic 
> -pthread CMakeFiles/racon.dir/src/main.cpp.o 
> CMakeFiles/racon.dir/src/logger.cpp.o CMakeFiles/racon.dir/src/polisher.cpp.o 
> CMakeFiles/racon.dir/src/overlap.cpp.o 
> CMakeFiles/racon.dir/src/sequence.cpp.o CMakeFiles/racon.dir/src/window.cpp.o 
> -o bin/racon  -lspoa -ledlib -lz 
> /usr/bin/ld: CMakeFiles/racon.dir/src/overlap.cpp.o: in function 
> `racon::Overlap::align_overlaps(char const*, unsigned int, char const*, 
> unsigned int)':
> ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined reference to 
> `edlibNewAlignConfig'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined 
> reference to `edlibAlign'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:213: undefined 
> reference to `edlibAlignmentToCigar'
> /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:223: undefined 
> reference to `edlibFreeAlignResult'
> collect2: error: ld returned 1 exit status
```

Thanks,
~Niels

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

[Glenn Washburn]

Package: udev
Version: 247.3-5

Probably the easiest solution would be to exit early from the post
install if the current user is not root. There's probably a more subtle
fix that preserves more functionality (eg. maybe updating the hwdb in
PKG_ROOT?), what ever gets the post install to not fail in this
scenario works for me.

Glenn

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

[Glenn Washburn]

Package: install-info
Version: 6.7.0.dfsg.2-6

The post install is failing when dpkg is configured with a root and run
as an unprivileged user. This is an issue partly with packaging and
partly with the upstream package (I think). The upstream issue can be remedied 
with a patch in
the packaging.

My suggestion for a fix is to modify update-info-dir such that it takes
an argument (eg. --root ) prepend that argument to all file paths
used.  Then in the post install call update-info-dir with $PKG_ROOT as
the argument, eg. update-info-dir --root $PKG_ROOT. Any fix will do
though.

Glenn

Bug#996539: ITP: sqlitecpp -- a smart and easy to use C++ SQLite3 wrapper

[YaNing Lu]

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

* Package name: sqlitecpp
  Version : 3.1.1-1
  Upstream Author : Sébastien Rombauts 
* URL : https://github.com/SRombauts/SQLiteCpp

* License : MIT
  Programming Lang: C++
  Description : a smart and easy to use C++ SQLite3 wrapper

SQLiteC++ offers an encapsulation around the native C APIs of SQLite,
with a few intuitive and well documented C++ classes.

NOTE: this is a simple wrapper for sqlite which allows for cleaner
C++ application code. Packaging as plain static library due to
overhead/complexity/benefit trade-off. Refer to Eduard, which has been
pre-packaged for version 2.5.0.

Description: smart and easy to use C++ SQLite3 wrapper
 SQLiteC++ offers an encapsulation around the native C APIs of SQLite, with a
 few intuitive and well documented C++ classes.
 .
 The goals of SQLiteC++ are:
 - to offer the best of the existing simple C++ SQLite wrappers
 - to be elegantly written with good C++ design, STL, exceptions and RAII idiom
 - to keep dependencies to a minimum (STL and SQLite3)
 - to be portable
 - to be light and fast
 - to be thread-safe only as much as SQLite “Multi-thread” mode (see below)
 - to have a good unit test coverage
 - to use API names sticking with those of the SQLite library
 - to be well documented with Doxygen tags, and with some good examples
 - to be well maintained


Regards,

Lu YaNing

Bug#996534: netkit-telnet: Specifying a port in telnetrc is not working

[Dongho Chang]

Package: netkit-telnet
Followup-For: Bug #996534
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch

Dear Maintainer,


*** /tmp/tmpn1vxgjaz/bug_body

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


  * Description: Fix Bug-Specifying a port in telnetrc is not working
 telnetrc parsing routine ( readrc() function in telnet/command.cc ) 
 has a flaw in comparing the port number of command-line with that 
 of telnetrc To proceed command processing, the result of string 
 compare MUST not negated


Thanks for considering the patch.


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

Kernel: Linux 5.11.0-36-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru netkit-telnet-0.17/debian/patches/port-telnetrc 
netkit-telnet-0.17/debian/patches/port-telnetrc
--- netkit-telnet-0.17/debian/patches/port-telnetrc 1970-01-01 
09:00:00.0 +0900
+++ netkit-telnet-0.17/debian/patches/port-telnetrc 2021-10-15 
11:36:04.0 +0900
@@ -0,0 +1,32 @@
+Description: Fix Bug-Specifying a port in telnetrc is not working
+ telnetrc parsing routine ( readrc() function in telnet/command.cc )
+ has a flaw in comparing the port number of command-line with that
+ of telnetrc To proceed command processing, the result of string
+ compare MUST not negated
+ .
+ netkit-telnet (0.17-41.2ubuntu2) UNRELEASED; urgency=medium
+ .
+
+Author: Dongho Chang 
+
+---
+Bug-Debian: https://bugs.debian.org/996534
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1891021 
+Last-Update: 2021-10-15
+
+--- netkit-telnet-0.17.orig/telnet/commands.cc
 netkit-telnet-0.17/telnet/commands.cc
+@@ -2135,7 +2135,7 @@ static void readrc(const char *m1, const
+   continue;
+ 
+   if (line[0] == ':') {
+-  if (!strncasecmp(&line[1], port, lport))
++  if (strncasecmp(&line[1], port, lport))
+   continue;
+   strncpy(line, &line[lport + 1], sizeof(line) - lport - 1);
+   }
diff -Nru netkit-telnet-0.17/debian/patches/series 
netkit-telnet-0.17/debian/patches/series
--- netkit-telnet-0.17/debian/patches/series2019-02-24 22:25:14.0 
+0900
+++ netkit-telnet-0.17/debian/patches/series2021-10-15 11:36:04.0 
+0900
@@ -14,3 +14,4 @@
 142-numeric_hosts.diff
 use-cmake-as-buildsystem.patch
 use-cmake-as-buildsystem-debian-extras.patch
+port-telnetrc

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

[YaNing Lu]

HI Eduard，
I am very interested in this package and want to take over the packaging
project. I will create a new ITP due to the upstream version update.

Best regards,
Lu

Bug#996538: gnome-software: Shows wrong type of license

[yes]

Package: gnome-software
Version: 41.0-1
Severity: normal

Dear Maintainer, hi!

I was looking, through Gnome-software, at some programs that are installed on 
my Debian and to my surprise I came across something a little unusual.
In gnome-software when I accessed the "add-ons" option, then "codecs", I 
noticed that the installed codecs said that the license for that lib/package 
was "Private", but the origin of that package was "debian-bookworm-main ".
Out of curiosity I decided to look at the "copyright" file of that lib I was 
looking at, through the terminal. All information obtained from the result were 
free licenses.
The problem occurs with: libs "GStreamer", Sigil program, GnuCash, WinFF, 
Brasero, OpenLP, etc...
The programs/libs I reported above were chosen at random in gnome-software and 
for all these examples the free license type was expected.
In a way that made me a little worried. If a common user comes across one of 
these packages and sees that the licenses are private, maybe he won't download 
these programs... Or maybe a little worse, maybe the opposite can happen, when 
the user verifies that the informed license is free but actually maybe a 
proprietary/non-free program. :/ 

PS: Sorry for any grammar mistakes... I speak Portuguese. :)





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

Kernel: Linux 5.14.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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-software depends on:
ii  appstream0.14.6-1
ii  apt-config-icons 0.14.6-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  gnome-software-common41.0-1
ii  gsettings-desktop-schemas41.0-1
ii  libappstream40.14.6-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libfwupd21.5.7-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgspell-1-21.8.4-1
ii  libgtk-3-0   3.24.30-3
ii  libgtk3-perl 0.038-1
ii  libgudev-1.0-0   237-2
ii  libhandy-1-0 1.4.0-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmalcontent-0-00.10.1-1
ii  libpackagekit-glib2-18   1.2.2-2
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpolkit-gobject-1-00.105-31
ii  libsoup2.4-1 2.74.0-2
ii  libxmlb2 0.3.2-1
ii  packagekit   1.2.2-2
ii  software-properties-gtk  0.96.20.2-2.1

Versions of packages gnome-software recommends:
ii  fwupd  1.5.7-5

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#996534: netkit-telnet: Specifying a port in telnetrc is not working

[Dongho Chang]

Source: netkit-telnet
Version: 0.17
Severity: normal

Dear Maintainer,



# What expected to happen

 - 1. Specify a port in telnetrc ( $HOME/.telnetrc) as follows
 * DEFAUT:8023 mode character
 - 2. telnet a host with specific port
 * telnet 192.168.1.1 8023
 - The expected is that "mode character" command is executed as soon as server 
is connected, according to "man telnet"

# What happened instead
  - The command in telnetrc specifying a port is not executed
  - But If not specifying a port, the command is executed as expected

# Cause of Bug
  - telnetrc parsing routine ( readrc() function in telnet/command.cc ) has a 
flaw in comparing the port number of command-line with that of telnetrc
  - To proceed command processing, the result of string compare MUST not negated
  - The patch is as follows
--- a/telnet/commands.cc
+++ b/telnet/commands.cc
@@ -2135,7 +2135,7 @@ static void readrc(const char *m1, const char *m2, const 
char *port,
continue;
 while (fgets(line, sizeof(line), rcfile)) {
...
if (gotmachine == 0) {
...

if (line[0] == ':') {
- if (!strncasecmp(&line[1], port, lport))
+ if (strncasecmp(&line[1], port, lport))
continue;
strncpy(line, &line[lport + 1], sizeof(line) - lport - 1);
}
   ...
}
...
process_command(&cmdtab, margc, margv);

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

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

Bug#996533: groff-message (line 1) can't set the locale; make sure $LC_* and $LANG are correct

[肖盛文]

Package: lintian
Version: 2.108.0
Severity: normal
X-Debbugs-Cc: atzli...@sina.com

Hi,

lintian tags groff-message has error report in salsa CI/CD.

Please see:

https://salsa.debian.org/atzlinux-guest/stardict/-/jobs/2071953

W: stardict-gtk: groff-message usr/share/man/man1/stardict.1.gz (line 1) can't
set the locale; make sure $LC_* and $LANG are correct
W: stardict-tools: groff-message usr/share/man/man1/stardict-editor.1.gz (line
1) can't set the locale; make sure $LC_* and $LANG are correct

lintian-explain-tags groff-message say it use:

N:   LC_ALL=en_US.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
N:   man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null

I think set LC_ALL=en_US.UTF-8 is the root cause.
If the machine don't has en_US.utf8 locale(locale -a output hasn't en_US.utf8),
this lintian check will report this warnning.

I suggest change to LC_ALL=POSIX or LC_ALL=C.UTF-8.


xiao sheng wen(atzli...@sina.com)

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

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

Versions of packages lintian depends on:
ii  binutils2.35.2-2
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.39
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012001-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-4+deb11u2
ii  t1utils 1.41-4
ii  unzip   6.0-26ubuntu1
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

Bug#996532: installation-reports: The brightness-control keys won't work on HP Pavilion Gaming Laptop 15-cx0076tx.

[wuniu]

Package: installation-reports
Severity: minor

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/
Date: 

Machine: HP Pavilion Gaming Laptop 15-cx0076tx
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:The brightness-control keys won't work on HP Pavilion Gaming 
Laptop 15-cx0076tx.





Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian-swing 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 
(2021-07-28) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core 
Processor Host Bridge/DRAM Registers [8086:3ec4] (rev 07)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD 
Graphics 630 (Mobile) [8086:3e9b]
lspci -knn: DeviceName: Intel(R) UHD Graphics 630
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon 
E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 
07)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 
v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 
[8086:1911]
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation 
Cannon Lake PCH Thermal Controller [8086:a379] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH 
USB 3.1 xHCI Host Controller [8086:a36d] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared 
SRAM [8086:a36f] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:14.3 Network controller [0280]: Intel Corporation Wireless-AC 
9560 [Jefferson Peak] [8086:a370] (rev 10)
lspci -knn: DeviceName: WLAN
lspci -knn: Subsystem: Intel Corporation Device [8086:0034]
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Cannon 
Lake PCH HECI Controller [8086:a360] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake 
Mobile PCH SATA AHCI Controller [8086:a353] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #20 [8086:a343] (rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #9 [8086:a330] (rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.4 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #13 [8086:a334] (rev f0)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation HM470 Chipset LPC/eSPI 
Controller [8086:a30d] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS 
[8086:a348] (rev 10)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8478]
lspci -knn: Kernel driver in use: snd_hda_int

Bug#996531: tp-smapi-dkms: Loading thinkpad_ec and/or tp_smapi causes kernel oops

[Pascal Giard]

Package: tp-smapi-dkms
Version: 0.43-1
Severity: important
X-Debbugs-Cc: evily...@gmail.com

Dear Maintainer,

While working fine on kernel 5.10, starting with 5.14, when the thinkpad_ec or
tp_smapi modules are loaded, a kernel oop occurs.

Here's a relevant extract from kernel messages:
[   92.365760] tp_smapi 0.43 loading...
[   92.365896] tp_smapi successfully loaded (smapi_port=0xb2).
[   92.445556] BUG: kernel NULL pointer dereference, address: 
[   92.445575] #PF: supervisor instruction fetch in kernel mode
[   92.445581] #PF: error_code(0x0010) - not-present page
[   92.445587] PGD 0 P4D 0
[   92.445597] Oops: 0010 [#2] SMP PTI
[   92.445606] CPU: 2 PID: 1587 Comm: tpacpi-bat Tainted: G  DOE
5.14.0-2-amd64 #1  Debian 5.14.9-2
[   92.445615] Hardware name: LENOVO 4180AP3/4180AP3, BIOS 83ET73WW (1.43 )
11/30/2012
[   92.445620] RIP: 0010:0x0
[   92.445635] Code: Unable to access opcode bytes at RIP 0xffd6.
[   92.445640] RSP: 0018:9cf1c0d27ef0 EFLAGS: 00010246
[   92.445647] RAX:  RBX: 8a3ec373f9c0 RCX:
0002
[   92.445653] RDX: 0001 RSI:  RDI:
8a3dc4389500
[   92.445657] RBP:  R08: 0003 R09:

[   92.445662] R10:  R11:  R12:
0001
[   92.445666] R13: ffea R14: 8a3dc4389500 R15:

[   92.445672] FS:  7f09944572c0() GS:8a3eda28()
knlGS:
[   92.445679] CS:  0010 DS:  ES:  CR0: 80050033
[   92.445684] CR2: ffd6 CR3: 01142002 CR4:
000606e0
[   92.445691] Call Trace:
[   92.445698]  proc_reg_llseek+0x45/0x80
[   92.445719]  ksys_lseek+0x7d/0xb0
[   92.445729]  do_syscall_64+0x3b/0xc0
[   92.445739]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   92.445752] RIP: 0033:0x7f099466ade7
[   92.445758] Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 15 d9 91 00 00 f7
d8 64 89 02 b8 ff ff ff ff eb b8 0f 1f 44 00 00 b8 08 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 01 c3 48 8b 15 b1 91 00 00 f7 d8 64 89 02 48
[   92.445767] RSP: 002b:7ffd5c6b88a8 EFLAGS: 0246 ORIG_RAX:
0008
[   92.445774] RAX: ffda RBX: 56520b25de80 RCX:
7f099466ade7
[   92.445779] RDX: 0001 RSI:  RDI:
0003
[   92.445784] RBP: 56520c749000 R08: 7ffd5c6b8850 R09:

[   92.445788] R10: 0014 R11: 0246 R12:
56520c7282a0
[   92.445793] R13: 7ffd5c6b8aa0 R14: 56520c7283f0 R15:
56520c7d4400
[   92.445802] Modules linked in: tp_smapi(OE) nf_tables nfnetlink tun
cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_ondemand
toshiba_acpi sparse_keymap industrialio toshiba_haps hp_accel lis3lv02d
hdaps(OE) acpi_call(OE) thinkpad_ec(OE) uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc snd_hda_codec_hdmi
snd_ctl_led snd_hda_codec_conexant snd_hda_codec_generic i915 iwldvm
snd_hda_intel intel_rapl_msr intel_rapl_common snd_intel_dspcfg mac80211
snd_intel_sdw_acpi ttm snd_hda_codec x86_pkg_temp_thermal intel_powerclamp
coretemp libarc4 drm_kms_helper snd_hda_core pktcdvd snd_hwdep mei_wdt iTCO_wdt
ghash_clmulni_intel cec aesni_intel iwlwifi thinkpad_acpi snd_pcm rc_core nvram
mei_hdcp intel_pmc_bxt i2c_algo_bit platform_profile at24 iTCO_vendor_support
ledtrig_audio crypto_simd cryptd snd_timer mei_me cfg80211 snd mei watchdog sg
soundcore rapl intel_cstate intel_uncore rfkill evdev joydev ac wmi_bmof pcspkr
serio_raw button
[   92.445953]  binfmt_misc parport_pc ppdev lp parport drm sunrpc configfs
fuse ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq
libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod sr_mod
cdrom t10_pi crc_t10dif crct10dif_generic ehci_pci ahci ehci_hcd libahci e1000e
libata crct10dif_pclmul usbcore crct10dif_common sdhci_pci psmouse crc32_pclmul
cqhci crc32c_intel scsi_mod sdhci mmc_core i2c_i801 ptp i2c_smbus lpc_ich
pps_core usb_common wmi battery video
[   92.446071] CR2: 
[   92.446077] ---[ end trace 5a46d47e5ade0144 ]---

This system is a thinkpad T420.

Please let me know if any more details would be helpful.

Best regards,

-Pascal

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
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=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (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 tp-smapi-dkms depends on:
ii  dkms  2.8.7-2

tp-smapi-dkms recommends no packages.

tp-smapi-dkms suggests no packages.

Bug#996472: nspark: Description doesn't say what it does

[Dave Lambley]

> On 14/10/2021 18:45 Justin B Rye  wrote:
>
> Oh, is this another one for my collection of packages where the prefix
> "n-" stands for "new thirty years ago"?

Yes, I'm afraid so.

> My suggestion:
> 
> # de-archiver for !Spark archives
> #
> # nspark ("new spark") supports extracting files from Spark 1 and 2 or
> # ArcFS archives. It is a cross-platform rewrite of David Pilling's
> # original !Spark for RISC OS.
> 
> (assuming I'm interpreting the manual correctly).

Thank you! I have gone for a tweaked version of that (from looking at the 
mentioned packages and the upstream docs) and uploaded it to mentors. Would you 
be able to upload it?

Description: Unarchiver for Spark and ArcFS files
 nspark "New Spark unarchiver" supports extracting from Spark and ArcFS 
files,
 which originate on RISC OS. It is a cross platform rewrite of David 
Pilling's
 original !Spark for RISC OS.

Here is the mentors stuff;

 * Package name: nspark
   Version : 1.7.8B2+git20210317.cb30779-2
   Upstream Author : https://github.com/mjwoodcock
 * URL : https://github.com/mjwoodcock/nspark
 * License : nspark
 * Vcs : https://repo.or.cz/debian-nspark.git
   Section : non-free/utils

It builds those binary packages:

  nspark - Unarchiver for Spark and ArcFS files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/n/nspark/nspark_1.7.8B2+git20210317.cb30779-2.dsc

Changes since the last upload:

 nspark (1.7.8B2+git20210317.cb30779-2) unstable; urgency=medium
 .
   * Rewrite description (Closes: #996472)

Best regards,
Dave

Bug#996530: yard: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: cannot load such file -- webrick

[Antonio Terceiro]

Source: yard
Version: 0.9.24-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, yard was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>   cannot load such file -- webrick
> # ./lib/yard/server/webrick_adapter.rb:2:in `'
> # ./spec/server/webrick_servlet_spec.rb:4:in `'
> 
> Top 0 slowest examples (0 seconds, 0.0% of total time):
> 
> Finished in 0.0001 seconds (files took 0.90378 seconds to load)
> 0 examples, 0 failures, 2 errors occurred outside of examples
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.0" failed: 

Note that webrick has been removed from the standard library. It's
already been packaged and is currently in NEW, but this package now
needs an explicit build dependency on it.

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/yard/yard_0.9.24-1+rebuild1633401329_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996529: vagrant: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: RuntimeError:

[Antonio Terceiro]

Source: vagrant
Version: 2.2.14+dfsg-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, vagrant was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>  RuntimeError:
>class variable access from toplevel
>  # 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:10:in
>  `block (3 levels) in '
>  # 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:9:in
>  `initialize'
>  # 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:9:in
>  `new'
>  # 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:9:in
>  `block (2 levels) in '
>  # 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:34:in
>  `block (4 levels) in '
> 
> Finished in 14 minutes 32 seconds (files took 5.03 seconds to load)
> 2824 examples, 7 failures, 9 pending
> 
> Failed examples:
> 
> rspec 
> /<>/test/unit/plugins/commands/cloud/provider/upload_test.rb:88 
> # 
> VagrantPlugins::CloudCommand::ProviderCommand::Command::Upload#upload_provider
>  with direct option should use direct upload
> rspec /<>/test/unit/plugins/commands/cloud/search_test.rb:59 # 
> VagrantPlugins::CloudCommand::Command::Search#search with valid options 
> should use options when performing search
> rspec /<>/test/unit/plugins/commands/cloud/search_test.rb:72 # 
> VagrantPlugins::CloudCommand::Command::Search#search with valid options with 
> invalid options should only pass supported options to search
> rspec /<>/test/unit/plugins/kernel_v2/config/disk_test.rb:120 # 
> VagrantPlugins::Kernel_V2::VagrantConfigDisk#add_provider_config normalizes 
> provider config
> rspec 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:21
>  # VagrantPlugins::SyncedFolder::UnixMountHelpers.merge_mount_options with no 
> override should split options into individual options
> rspec 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:28
>  # VagrantPlugins::SyncedFolder::UnixMountHelpers.merge_mount_options with 
> overrides should merge all options
> rspec 
> /<>/test/unit/plugins/synced_folders/unix_mount_helpers_test.rb:33
>  # VagrantPlugins::SyncedFolder::UnixMountHelpers.merge_mount_options with 
> overrides should override options defined in base
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern test/unit/\{plugins\}/\*\*/\*_test.rb  --exclude-pattern 
> \{test/unit/vagrant/action/builtin/box_add_test.rb,test/unit/plugins/communicators/winrm/\*_test.rb,test/unit/plugins/pushes/ftp/\*_test.rb\}
>  -I/<>/debian/lib failed
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/vagrant/vagrant_2.2.14+dfsg-1+rebuild1633400150_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996528: test-kitchen: FTBFS: ERROR: Test "ruby2.7" failed: Could not find 'thor' (~> 0.19) among 87 total gem(s) (Gem::MissingSpecError)

[Antonio Terceiro]

Source: test-kitchen
Version: 1.23.2-5
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, test-kitchen was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'thor' (~> 0.19) among 87 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/test-kitchen/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/test-kitchen/usr/share/rubygems-integration/all/specifications/test-kitchen-1.23.2.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'thor' (~> 0.19) - did find: [thor-1.0.1] (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/test-kitchen/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> aruba (1.0.4)
> bcrypt_pbkdf (1.1.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> builder (3.2.4)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> chef-utils (16.12.3)
> childprocess (4.1.0)
> coderay (1.1.3)
> contracts (0.16.0)
> csv (default: 3.1.2)
> cucumber (2.4.0)
> cucumber-core (1.5.0)
> cucumber-wire (0.0.1)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> ed25519 (1.2.4)
> etc (default: 1.1.0)
> fakefs (1.2.0)
> fcntl (default: 1.0.0)
> ffi (1.12.2)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> gherkin (4.0.0)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> metaclass (0.0.4)
> method_source (1.0.0)
> minitest (5.13.0)
> mixlib-install (3.11.7)
> mixlib-shellout (3.2.5)
> mixlib-versioning (1.1.0)
> mocha (1.7.0)
> multi_json (1.14.1)
> multi_test (0.1.2)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-scp (3.0.0)
> net-smtp (default: 0.1.0)
> net-ssh (6.1.0)
> net-ssh-gateway (2.0.0)
> net-telnet (0.1.1)
> observer (default: 0.1.0)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pry (0.13.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> racc (default: 1.4.16)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec-expectations (3.9.2)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> thor (1.0.1)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webrick (defau

Bug#996527: sup-mail: FTBFS: ERROR: Test "ruby2.7" failed: NameError: uninitialized constant ActiveSupport

[Antonio Terceiro]

Source: sup-mail
Version: 1.0-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, sup-mail was found to fail to build in that situation.

This seems unrelated to ruby3.0, since the ruby2.7 tests already fail.

Relevant part (hopefully):
> /usr/bin/ruby2.7 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Run tests for ruby2.7 from debian/ruby-tests.rb 
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/sup-mail/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/sup-mail/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0
>  ruby2.7 debian/ruby-tests.rb
> tput: No value for $TERM and no -T specified
> tput: No value for $TERM and no -T specified
> Some YAML tests are skipped on Ruby 2.1.0 and newer.
> Run options: --seed 8439
> 
> # Running:
> 
> [2021-10-05 02:07:09 +] WARNING: URI.escape is obsolete
> [2021-10-05 02:07:09 +] WARNING: found invalid date in potential mbox 
> split line, not splitting: "From sea to shining sea\n"
> [2021-10-05 02:07:09 +] WARNING: found invalid date in potential mbox 
> split line, not splitting: "From b...@bob.com I get only spam.\n"
> ..[2021-10-05 02:07:09 +] WARNING: URI.escape is obsolete
> .[2021-10-05 02:07:09 +] WARNING: DEPRECATED: Use assert_nil if expecting 
> nil from /<>/test/test_header_parsing.rb:72. This will fail in 
> Minitest 6.
> E/usr/bin/which: this version of `which' is deprecated; use `command -v' 
> in scripts instead.
> [2021-10-05 02:07:09 +] WARNING: No crypto set up, crypto will not be 
> tested. Reason: ["Environment variable 'GPG_AGENT_INFO' not set, is gpg-agent 
> running?", "If gpg-agent is running, try $ export `cat ~/.gpg-agent-info`"]
> ./usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> [2021-10-05 02:07:09 +] WARNING: No crypto set up, crypto will not be 
> tested. Reason: ["Environment variable 'GPG_AGENT_INFO' not set, is gpg-agent 
> running?", "If gpg-agent is running, try $ export `cat ~/.gpg-agent-info`"]
> ./usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> [2021-10-05 02:07:09 +] WARNING: No crypto set up, crypto will not be 
> tested. Reason: ["Environment variable 'GPG_AGENT_INFO' not set, is gpg-agent 
> running?", "If gpg-agent is running, try $ export `cat ~/.gpg-agent-info`"]
> ./usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> [2021-10-05 02:07:09 +] WARNING: No crypto set up, crypto will not be 
> tested. Reason: ["Environment variable 'GPG_AGENT_INFO' not set, is gpg-agent 
> running?", "If gpg-agent is running, try $ export `cat ~/.gpg-agent-info`"]
> ./usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> [2021-10-05 02:07:09 +] WARNING: No crypto set up, crypto will not be 
> tested. Reason: ["Environment variable 'GPG_AGENT_INFO' not set, is gpg-agent 
> running?", "If gpg-agent is running, try $ export `cat ~/.gpg-agent-info`"]
> ./usr/bin/which: this version of `which' is deprecated; use `command -v' in 
> scripts instead.
> [2021-10-05 02:07:09 +] WARNING: No crypto set up, crypto will not be 
> tested. Reason: ["Environment variable 'GPG_AGENT_INFO' not set, is gpg-agent 
> running?", "If gpg-agent is running, try $ export `cat ~/.gpg-agent-info`"]
> .[2021-10-05 02:07:09 +] WARNING: problem reading message 
> sup-faked-df001467cbd7d1c987812838111e7731
> [2021-10-05 02:07:09 +] WARNING: Message is in sup-test://test_messages 
> at 0
> ..[2021-10-05 02:07:09 +] WARNING: problem reading message 
> sup-faked-b4f27f6a974091c7c1c67484b827eb61
> [2021-10-05 02:07:09 +] WARNING: Message is in sup-test://test_messages 
> at 0
> .
> 
> Finished in 0.164684s, 176.0946 runs/s, 613.2951 assertions/s.
> 
>   1) Error:
> Redwood::TestYamlRegressions#test_yamling_hash:
> NameError: uninitialized constant ActiveSupport
> /usr/lib/ruby/vendor_ruby/rr/integrations/minitest_4.rb:48:in `block (2 
> levels) in hook'
> /usr/lib/ruby/vendor_ruby/rr/integrations/minitest_4.rb:56:in `block (2 
> levels) in hook'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:96:in `block (3 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_

Bug#996526: rubygems: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed.

[Antonio Terceiro]

Source: rubygems
Version: 3.2.27-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, rubygems was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-bundler/usr/share/rubygems-integration/all:/<>/debian/ruby-rubygems/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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\ \"rubygems-update\"
> GEM_PATH=/<>/debian/ruby-bundler/usr/share/rubygems-integration/all:/<>/debian/ruby-rubygems/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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\ \"bundler\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-bundler/usr/share/rubygems-integration/all:/<>/debian/ruby-rubygems/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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
> 
> File does not exist: webrick
> 
> rake aborted!
> Command failed with status (1)
> 
> Tasks: TOP => default => test
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed.

Note that webrick has been removed from the standard library. It's
already been packaged and is currently in NEW, but this package now
needs an explicit build dependency on it.

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/rubygems/rubygems_3.2.27-1+rebuild1633399251_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996525: ruby-xmlrpc: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed.

[Antonio Terceiro]

Source: ruby-xmlrpc
Version: 0.3.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-xmlrpc was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-xmlrpc/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\ \"xmlrpc\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-xmlrpc/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-xmlrpc/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/test_client.rb" "test/test_cookie.rb" "test/test_datetime.rb" 
> "test/test_features.rb" "test/test_helper.rb" "test/test_marshal.rb" 
> "test/test_parser.rb" "test/test_webrick_server.rb" "test/test_xmlrpc.rb" -v
> 
> File does not exist: webrick
> 
> 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/test_client.rb" "test/test_cookie.rb" "test/test_datetime.rb" 
> "test/test_features.rb" "test/test_helper.rb" "test/test_marshal.rb" 
> "test/test_parser.rb" "test/test_webrick_server.rb" "test/test_xmlrpc.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed.

Note that webrick has been removed from the standard library. It's
already been packaged and is currently in NEW, but this package now
needs an explicit build dependency on it.

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-xmlrpc/ruby-xmlrpc_0.3.0-2+rebuild1633399041_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996524: ruby-whitequark-parser: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed.

[Antonio Terceiro]

Source: ruby-whitequark-parser
Version: 2.7.1.4-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-whitequark-parser was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-whitequark-parser/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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\ \"parser\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-whitequark-parser/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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/test_ast_processor.rb" "test/test_base.rb" "test/test_current.rb" 
> "test/test_diagnostic.rb" "test/test_diagnostic_engine.rb" 
> "test/test_encoding.rb" "test/test_lexer.rb" "test/test_lexer_stack_state.rb" 
> "test/test_meta.rb" "test/test_parse_helper.rb" "test/test_parser.rb" 
> "test/test_runner_parse.rb" "test/test_runner_rewrite.rb" 
> "test/test_source_buffer.rb" "test/test_source_comment.rb" 
> "test/test_source_comment_associator.rb" "test/test_source_map.rb" 
> "test/test_source_range.rb" "test/test_source_rewriter.rb" 
> "test/test_source_rewriter_action.rb" "test/test_source_tree_rewriter.rb" 
> "test/test_static_environment.rb" -v
> warning: parser/current is loading parser/ruby27, which recognizes
> warning: 2.7.x-compliant syntax, but you are running 3.0.2.
> warning: please see 
> https://github.com/whitequark/parser#compatibility-with-ruby-mri.
> Run options: -v --seed 1073
> 
> # Running:
> 
> TestSourceTreeRewriter#test_empty = 0.00 s = .
> TestSourceTreeRewriter#test_insert_after = 0.00 s = .
> TestSourceTreeRewriter#test_inserts_on_empty_ranges = 0.07 s = .
> TestSourceTreeRewriter#test_replace = 0.00 s = .
> TestSourceTreeRewriter#test_ordered_replacements = 0.00 s = .
> TestSourceTreeRewriter#test_swallowed_insertions = 0.00 s = .
> TestSourceTreeRewriter#test_merge = 0.02 s = .
> TestSourceTreeRewriter#test_nested_actions = 0.00 s = .
> TestSourceTreeRewriter#test_insert_before = 0.00 s = .
> TestSourceTreeRewriter#test_replace_same_range = 0.00 s = .
> TestSourceTreeRewriter#test_crossing_non_deletions = 0.00 s = .
> TestSourceTreeRewriter#test_multiple_actions = 0.00 s = .
> TestSourceTreeRewriter#test_out_of_range_ranges = 0.00 s = .
> TestSourceTreeRewriter#test_remove = 0.00 s = .
> TestSourceTreeRewriter#test_crossing_deletions = 0.00 s = .
> TestSourceTreeRewriter#test_wrap = 0.00 s = .
> TestSourceTreeRewriter#test_wraps_same_range = 0.00 s = .
> TestParser#test_beginless_range_before_27 = 0.00 s = .
> TestParser#test_comments_before_leading_dot__27 = 0.00 s = .
> TestParser#test_parser_bug_490 = 0.06 s = .
> TestParser#test_asgn_cmd = 0.01 s = .
> TestParser#test_bug_435 = 0.01 s = .
> TestParser#test_hash_label_end = 0.02 s = .
> TestParser#test_masgn_const = 0.02 s = .
> TestParser#test_send_lambda_args_shadow = 0.01 s = .
> TestParser#test_resbody_list = 0.01 s = .
> TestParser#test_space_args_star = 0.00 s = .
> TestParser#test_non_lvar_injecting_match = 0.01 s = .
> TestParser#test_op_asgn = 0.02 s = .
> TestParser#test_until = 0.02 s = .
> TestParser#test_next_block = 0.01 s = .
> TestParser#test_ruby_bug_11990 = 0.00 s = .
> TestParser#test_cond_match_current_line = 0.02 s = .
> TestParser#test_rescue_mod = 0.01 s = .
> TestParser#test_array_words = 0.01 s = .
> TestParser#test_emit_arg_inside_procarg0_legacy = 0.01 s = .
> TestParser#test_send_plain_cmd_ambiguous_literal = 0.01 s = .
> TestParser#test_numbered_and_ordinary_parameters = 0.03 s = .
> TestParser#test_assig

Bug#996523: ruby-websocket: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: cannot load such file -- webrick

[Antonio Terceiro]

Source: ruby-websocket
Version: 1.2.8-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-websocket was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>   cannot load such file -- webrick
> # ./spec/support/all_server_drafts.rb:3:in `'
> # ./spec/spec_helper.rb:6:in `block in '
> # ./spec/spec_helper.rb:6:in `each'
> # ./spec/spec_helper.rb:6:in `'
> # ./spec/handshake/server_76_spec.rb:3:in `'
> No examples found.
> 
> Finished in 0.5 seconds (files took 1.11 seconds to load)
> 0 examples, 0 failures, 20 errors occurred outside of examples
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.0" failed: 

Note that webrick has been removed from the standard library. It's
already been packaged and is currently in NEW, but this package now
needs an explicit dependency on it.

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-websocket/ruby-websocket_1.2.8-2+rebuild1633398813_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996522: ruby-vips: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: ArgumentError:

[Antonio Terceiro]

Source: ruby-vips
Version: 2.0.17-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-vips was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>  ArgumentError:
>tried to create Proc object without a block
>  # ./lib/vips/object.rb:269:in `new'
>  # ./lib/vips/object.rb:269:in `signal_connect'
>  # ./lib/vips/targetcustom.rb:60:in `on_write'
>  # ./spec/connection_spec.rb:155:in `block (2 levels) in '
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:257:in
>  `instance_exec'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:257:in
>  `block in run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:503:in
>  `block in with_around_and_singleton_context_hooks'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:460:in
>  `block in with_around_example_hooks'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:481:in
>  `block in run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:619:in
>  `run_around_example_hooks_for'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/hooks.rb:481:in
>  `run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:460:in
>  `with_around_example_hooks'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:503:in
>  `with_around_and_singleton_context_hooks'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example.rb:254:in
>  `run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:644:in
>  `block in run_examples'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:640:in
>  `map'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:640:in
>  `run_examples'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/example_group.rb:606:in
>  `run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in
>  `block (3 levels) in run_specs'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in
>  `map'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:121:in
>  `block (2 levels) in run_specs'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:2058:in
>  `with_suite_hooks'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:116:in
>  `block in run_specs'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/reporter.rb:74:in
>  `report'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:115:in
>  `run_specs'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:89:in
>  `run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:71:in
>  `run'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:45:in
>  `invoke'
>  # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec:4:in 
> `'
> 
> Finished in 0.88878 seconds (files took 0.23373 seconds to load)
> 91 examples, 3 failures
> 
> Failed examples:
> 
> rspec ./spec/connection_spec.rb:118 # Vips::SourceCustom can load a custom 
> source
> rspec ./spec/connection_spec.rb:132 # Vips::SourceCustom on_seek is optional
> rspec ./spec/connection_spec.rb:151 # Vips::SourceCustom can write an image 
> to a user output stream
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --backtrace -r ./spec/spec_helper.rb failed
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-vips/ruby-vips_2.0.17-1+rebuild1633398529_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996521: ruby-vcr: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: cannot load such file -- webrick

[Antonio Terceiro]

Source: ruby-vcr
Version: 6.0.0+really5.0.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-vcr was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>   cannot load such file -- webrick
> # /<>/spec/support/vcr_localhost_server.rb:2:in ` (required)>'
> # /<>/spec/spec_helper.rb:14:in `require_relative'
> # /<>/spec/spec_helper.rb:14:in `'
> # /<>/spec/lib/vcr_spec.rb:1:in `'
> 
> Finished in 0.7 seconds (files took 2.17 seconds to load)
> 0 examples, 0 failures, 22 errors occurred outside of examples
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.0" failed: 

Note that webrick has been removed from the standard library. It's
already been packaged and is currently in NEW, but this package now
needs an explicit dependency on it.

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-vcr/ruby-vcr_6.0.0+really5.0.0-1+rebuild1633398432_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996520: ruby-varia-model: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Failure/Error: expect(subject.to_json).to eql(JSON.dump(first_name: "brooke", nick: "leblanc"))

[Antonio Terceiro]

Source: ruby-varia-model
Version: 0.6.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-varia-model was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>  Failure/Error: expect(subject.to_json).to eql(JSON.dump(first_name: 
> "brooke", nick: "leblanc"))
> 
>expected: "{\"first_name\":\"brooke\",\"nick\":\"leblanc\"}"
> got: 
> "{\"first_name\":\"brooke\",\"nick\":\"leblanc\",\"json_class\":\"Playa\"}"
> 
>(compared using eql?)
>  # ./spec/unit/varia_model_spec.rb:665:in `block (4 levels) in  (required)>'
> 
> Finished in 0.2 seconds (files took 0.81399 seconds to load)
> 68 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/unit/varia_model_spec.rb:661 # VariaModel#to_json when 
> JSON.create_id is nil does not include a nil key
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-varia-model/ruby-varia-model_0.6.0-1+rebuild1633398422_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996519: ruby-vagrant-cloud: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: ArgumentError:

[Antonio Terceiro]

Source: ruby-vagrant-cloud
Version: 3.0.2-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-vagrant-cloud was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>   ArgumentError:
> wrong number of arguments (given 1, expected 0)
>   # ./lib/vagrant_cloud/data.rb:217:in `initialize'
>   # ./lib/vagrant_cloud/box.rb:21:in `initialize'
>   # ./lib/vagrant_cloud/response/search.rb:57:in `new'
>   # ./lib/vagrant_cloud/response/search.rb:57:in `block in reload_boxes'
>   # ./lib/vagrant_cloud/response/search.rb:51:in `map'
>   # ./lib/vagrant_cloud/response/search.rb:51:in `reload_boxes'
>   # ./lib/vagrant_cloud/response/search.rb:18:in `initialize'
>   # ./spec/unit/vagrant_cloud/response/search_spec.rb:12:in `new'
>   # ./spec/unit/vagrant_cloud/response/search_spec.rb:12:in `block (2 
> levels) in '
>   # ./spec/unit/vagrant_cloud/response/search_spec.rb:101:in `block (3 
> levels) in '
> 
> Finished in 0.47348 seconds (files took 0.61223 seconds to load)
> 501 examples, 92 failures
> 
> Failed examples:
> 
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:23 # 
> VagrantCloud::Box::Version#initialize should load providers
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:36 # 
> VagrantCloud::Box::Version#delete should not delete if version does not exist
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:41 # 
> VagrantCloud::Box::Version#delete should return nil
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:51 # 
> VagrantCloud::Box::Version#delete when version exists should make a version 
> deletion request
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:56 # 
> VagrantCloud::Box::Version#delete when version exists should include box 
> username and name
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:62 # 
> VagrantCloud::Box::Version#delete when version exists should include the 
> version
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:68 # 
> VagrantCloud::Box::Version#delete when version exists should delete the 
> version from the box versions
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:83 # 
> VagrantCloud::Box::Version#release when version is released should error
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:91 # 
> VagrantCloud::Box::Version#release when version has not been saved should 
> error
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:102 # 
> VagrantCloud::Box::Version#release when version is saved and not released 
> should send request to release version
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:108 # 
> VagrantCloud::Box::Version#release when version is saved and not released 
> should include box username, box name, and version
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:114 # 
> VagrantCloud::Box::Version#release when version is saved and not released 
> should update status with value provided in result
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:121 # 
> VagrantCloud::Box::Version#release when version is saved and not released 
> should return self
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:132 # 
> VagrantCloud::Box::Version#revoke when version is not released should error
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:140 # 
> VagrantCloud::Box::Version#revoke when version is released should send 
> request to revoke release
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:146 # 
> VagrantCloud::Box::Version#revoke when version is released should include the 
> box username, box name, and version
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:152 # 
> VagrantCloud::Box::Version#revoke when version is released should update 
> status with value provided in result
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:159 # 
> VagrantCloud::Box::Version#revoke when version is released should return self
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:168 # 
> VagrantCloud::Box::Version#add_provider should create a new provider
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:172 # 
> VagrantCloud::Box::Version#add_provider should add provider to providers 
> collection
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:177 # 
> VagrantCloud::Box::Version#add_provider should raise error when provider 
> exists
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:188 # 
> VagrantCloud::Box::Version#dirty? when version does not exist should be true
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:196 # 
> VagrantCloud::Box::Version#dirty? when version does exist should be false
> rspec ./spec/unit/vagrant_cloud/box/version_spec.rb:203 # 
> VagrantCloud::Box::Version#dirty? when version does e

Bug#996518: ruby-typhoeus: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Failure/Error: require 'rack/handler/webrick'

[Antonio Terceiro]

Source: ruby-typhoeus
Version: 1.4.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-typhoeus was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> Failure/Error: require 'rack/handler/webrick'
> 
> LoadError:
>   cannot load such file -- webrick
> # 
> :85:in
>  `require'
> # 
> :85:in
>  `require'
> # /usr/lib/ruby/vendor_ruby/rack/handler/webrick.rb:3:in `'
> # 
> :85:in
>  `require'
> # 
> :85:in
>  `require'
> # ./spec/support/localhost_server.rb:2:in `'
> # 
> :85:in
>  `require'
> # 
> :85:in
>  `require'
> # ./spec/spec_helper.rb:9:in `block in '
> # ./spec/spec_helper.rb:9:in `each'
> # ./spec/spec_helper.rb:9:in `'
> # 
> :85:in
>  `require'
> # 
> :85:in
>  `require'
> # ./spec/typhoeus_spec.rb:1:in `'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:2103:in
>  `load'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:2103:in
>  `load_file_handling_errors'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:1606:in
>  `block in load_spec_files'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:1604:in
>  `each'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/configuration.rb:1604:in
>  `load_spec_files'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:102:in
>  `setup'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:86:in
>  `run'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:71:in
>  `run'
> # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib/rspec/core/runner.rb:45:in
>  `invoke'
> # /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec:4:in 
> `'
> No examples found.
> 
> Finished in 0.6 seconds (files took 2.62 seconds to load)
> 0 examples, 0 failures, 35 errors occurred outside of examples
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb failed
> ERROR: Test "ruby3.0" failed: 

Note that webrick has been removed from the standard library. It's
already been packaged and is currently in NEW, but this package now
needs an explicit dependency on it.

The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-typhoeus/ruby-typhoeus_1.4.0-1+rebuild1633397810_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996517: ruby-tty-command: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: ArgumentError:

[Antonio Terceiro]

Source: ruby-tty-command
Version: 0.9.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-tty-command was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>   ArgumentError:
> wrong number of arguments (given 1, expected 0)
>   # ./lib/tty/command/cmd.rb:66:in `update'
>   # ./lib/tty/command.rb:177:in `command'
>   # ./lib/tty/command.rb:103:in `run'
>   # ./lib/tty/command.rb:159:in `ruby'
>   # ./spec/unit/ruby_spec.rb:7:in `block (2 levels) in '
> 
> Top 2 slowest examples (0.06033 seconds, 28.6% of total time):
>   TTY::Command::Printers::Pretty prints output on error when 
> only_output_on_error is true
> 0.04233 seconds ./spec/unit/printers/pretty_spec.rb:144
>   TTY::Command :pty logs phased output in pseudo terminal mode
> 0.018 seconds ./spec/unit/pty_spec.rb:30
> 
> Top 2 slowest example groups:
>   TTY::Command::Printers::Null
> 0.00645 seconds average (0.01934 seconds / 3 examples) 
> ./spec/unit/printers/null_spec.rb:3
>   TTY::Command :pty
> 0.00634 seconds average (0.01902 seconds / 3 examples) 
> ./spec/unit/pty_spec.rb:3
> 
> Finished in 0.21107 seconds (files took 0.50957 seconds to load)
> 116 examples, 39 failures
> 
> Failed examples:
> 
> rspec ./spec/unit/pty_spec.rb:30 # TTY::Command :pty logs phased output in 
> pseudo terminal mode
> rspec ./spec/unit/pty_spec.rb:4 # TTY::Command :pty executes command in 
> pseudo terminal mode as global option
> rspec ./spec/unit/pty_spec.rb:17 # TTY::Command :pty executes command in 
> pseudo terminal mode as command option
> rspec ./spec/unit/printers/pretty_spec.rb:120 # 
> TTY::Command::Printers::Pretty prints output on error & raises ExitError when 
> only_output_on_error is true
> rspec ./spec/unit/printers/pretty_spec.rb:144 # 
> TTY::Command::Printers::Pretty prints output on error when 
> only_output_on_error is true
> rspec ./spec/unit/printers/pretty_spec.rb:97 # TTY::Command::Printers::Pretty 
> doesn't print output on success when only_output_on_error is true
> rspec ./spec/unit/redirect_spec.rb:92 # TTY::Command redirect redirects 
> multiple fds to a file
> rspec ./spec/unit/redirect_spec.rb:24 # TTY::Command redirect redirects 
> :stdout -> :stderr
> rspec ./spec/unit/redirect_spec.rb:44 # TTY::Command redirect redirects 
> STDOUT -> :err
> rspec ./spec/unit/redirect_spec.rb:4 # TTY::Command redirect accepts standard 
> shell redirects
> rspec ./spec/unit/redirect_spec.rb:54 # TTY::Command redirect redirects 
> STDOUT -> '/dev/null
> rspec ./spec/unit/redirect_spec.rb:63 # TTY::Command redirect redirects to a 
> file
> rspec ./spec/unit/redirect_spec.rb:34 # TTY::Command redirect redirects 1 -> 2
> rspec ./spec/unit/redirect_spec.rb:75 # TTY::Command redirect redirects to a 
> file as an array value
> rspec ./spec/unit/redirect_spec.rb:14 # TTY::Command redirect redirects :out 
> -> :err
> rspec ./spec/unit/printers/quiet_spec.rb:37 # TTY::Command::Printers::Quiet 
> doesn't print output on success when only_output_on_error is true
> rspec ./spec/unit/printers/quiet_spec.rb:54 # TTY::Command::Printers::Quiet 
> prints output on error when only_output_on_error is true
> rspec ./spec/unit/timeout_spec.rb:14 # TTY::Command#run times out an infite 
> process with constant output
> rspec ./spec/unit/timeout_spec.rb:24 # TTY::Command#run times out an infinite 
> process with constant input data
> rspec ./spec/unit/timeout_spec.rb:4 # TTY::Command#run times out infinite 
> process without input or output
> rspec ./spec/unit/output_spec.rb:6 # TTY::Command :output runs command and 
> prints to a file
> rspec ./spec/unit/dry_run_spec.rb:35 # TTY::Command dry run doesn't collect 
> printout to stdin or stderr
> rspec ./spec/unit/dry_run_spec.rb:11 # TTY::Command dry run runs command in 
> dry run mode
> rspec ./spec/unit/dry_run_spec.rb:23 # TTY::Command dry run allows to run 
> command in dry mode
> rspec ./spec/unit/input_spec.rb:4 # TTY::Command input reads user input data
> rspec ./spec/unit/binmode_spec.rb:4 # TTY::Command#run encodes output as 
> unicode by default
> rspec ./spec/unit/binmode_spec.rb:22 # TTY::Command#run encodes all commands 
> output as binary
> rspec ./spec/unit/binmode_spec.rb:13 # TTY::Command#run encodes output as 
> binary
> rspec ./spec/unit/run_spec.rb:64 # TTY::Command#run runs command successfully 
> with logging without uuid set locally
> rspec ./spec/unit/run_spec.rb:138 # TTY::Command#run logs phased output in 
> one line
> rspec ./spec/unit/run_spec.rb:48 # TTY::Command#run runs command successfully 
> with logging without uuid set globally
> rspec ./spec/unit/run_spec.rb:99 # TTY::Command#run raises ExitError on 
> command failure
> rspec ./spec/unit/run_sp

Bug#996516: ruby-toml-rb: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Segmentation fault

[Antonio Terceiro]

Source: ruby-toml-rb
Version: 2.0.1-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-toml-rb was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-toml-rb/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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\ \"toml-rb\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-toml-rb/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/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/dumper_test.rb" "test/errors_test.rb" "test/grammar_test.rb" 
> "test/toml_test.rb" -v
> Run options: -v --seed 58529
> 
> # Running:
> 
> TomlTest#test_file = 0.01 s = .
> TomlTest#test_invalid_cases = 0.03 s = .
> TomlTest#test_line_break = 0.00 s = .
> TomlTest#test_symbolize_keys = 0.01 s = .
> TomlTest#test_file_v_0_4_0 = 0.06 s = .
> TomlTest#test_valid_cases = /usr/lib/ruby/vendor_ruby/citrus.rb:1286: [BUG] 
> Segmentation fault at 0x556770d23000
> ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux-gnu]
> 
> -- Control frame information ---
> c:0038 p: s:0225 e:000224 CFUNC  :slice!
> c:0037 p:0063 s:0219 e:000218 METHOD /usr/lib/ruby/vendor_ruby/citrus.rb:1286 
> [FINISH]
> c:0036 p: s:0210 e:000209 CFUNC  :new
> c:0035 p:0139 s:0203 e:000202 METHOD /usr/lib/ruby/vendor_ruby/citrus.rb:1470
> c:0034 p:0011 s:0188 e:000187 METHOD /usr/lib/ruby/vendor_ruby/citrus.rb:1330
> c:0033 p:0003 s:0183 e:000182 METHOD /usr/lib/ruby/vendor_ruby/citrus.rb:1336
> c:0032 p:0018 s:0178 e:000176 METHOD 
> /<>/debian/ruby-toml-rb/usr/share/rubygems-integration/all/gems/toml-rb-2.0.1/lib/tom
>  [FINISH]
> c:0031 p: s:0173 e:000172 CFUNC  :map
> c:0030 p:0062 s:0169 e:000168 METHOD 
> /<>/debian/ruby-toml-rb/usr/share/rubygems-integration/all/gems/toml-rb-2.0.1/lib/tom
>  [FINISH]
> c:0029 p: s:0161 e:000160 CFUNC  :new
> c:0028 p:0019 s:0155 e:000154 METHOD 
> /<>/debian/ruby-toml-rb/usr/share/rubygems-integration/all/gems/toml-rb-2.0.1/lib/tom
> c:0027 p:0030 s:0149 e:000148 METHOD 
> /<>/debian/ruby-toml-rb/usr/share/rubygems-integration/all/gems/toml-rb-2.0.1/lib/tom
> c:0026 p:0059 s:0143 e:000142 BLOCK  /<>/test/toml_test.rb:121 
> [FINISH]
> c:0025 p: s:0135 e:000134 CFUNC  :each
> c:0024 p:0059 s:0131 e:000130 METHOD /<>/test/toml_test.rb:117
> c:0023 p:0006 s:0124 E:000510 METHOD /<>/test/toml_test.rb:131
> c:0022 p:0019 s:0120 e:000119 BLOCK  
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:98
> c:0021 p:0002 s:0117 e:000116 METHOD 
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195
> c:0020 p:0005 s:0112 e:000111 BLOCK  
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95
> c:0019 p:0015 s:0109 e:000108 METHOD /usr/lib/ruby/vendor_ruby/minitest.rb:270
> c:0018 p:0005 s:0104 e:000103 BLOCK  
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94
> c:0017 p:0030 s:0101 e:000100 METHOD /usr/lib/ruby/vendor_ruby/minitest.rb:365
> c:0016 p:0045 s:0093 E:001998 METHOD 
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211
> c:0015 p:0004 s:0086 E:001920 METHOD 
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93
> c:0014 p:0008 s:0082 e:81 METHOD 
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029
> c:0013 p:0026 s:0075 e:73 METHOD /usr/lib/ruby/vendor_ruby/minitest.rb:339
> c:0012 p:0010 s:0067 e:66 BLOCK  
> /usr/lib/ruby/vendor_ruby/minitest.rb:326 [FINISH]
> c:0011 p: s:0063 e:62 CFUNC  :each
> c:0010 p:0006 s:0059 e:58 BLOCK  /usr/lib/ruby/vendor_ruby/minitest.rb:325
> c:0009 p:0030 s

Bug#996515: ruby-tilt: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: TypeError: no implicit conversion of Hash into String

[Antonio Terceiro]

Source: ruby-tilt
Version: 2.0.10-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-tilt was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> TypeError: no implicit conversion of Hash into String
> /usr/lib/ruby/3.0.0/csv.rb:1273:in `initialize'
> /usr/lib/ruby/3.0.0/csv.rb:1273:in `new'
> /usr/lib/ruby/3.0.0/csv.rb:1273:in `generate'
> (__TEMPLATE__):in `__tilt_400'
> 
> /<>/debian/ruby-tilt/usr/lib/ruby/vendor_ruby/tilt/template.rb:170:in
>  `call'
> 
> /<>/debian/ruby-tilt/usr/lib/ruby/vendor_ruby/tilt/template.rb:170:in
>  `evaluate'
> 
> /<>/debian/ruby-tilt/usr/lib/ruby/vendor_ruby/tilt/template.rb:109:in
>  `render'
> /<>/test/tilt_csv_test.rb:32:in `block in 
> '
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'
> 
> 237 runs, 433 assertions, 1 failures, 6 errors, 0 skips
> 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/tilt_asciidoctor_test.rb" "test/tilt_blueclothtemplate_test.rb" 
> "test/tilt_buildertemplate_test.rb" "test/tilt_cache_test.rb" 
> "test/tilt_coffeescripttemplate_test.rb" 
> "test/tilt_commonmarkertemplate_test.rb" "test/tilt_compilesite_test.rb" 
> "test/tilt_creoletemplate_test.rb" "test/tilt_csv_test.rb" 
> "test/tilt_erbtemplate_test.rb" "test/tilt_erubistemplate_test.rb" 
> "test/tilt_erubitemplate_test.rb" "test/tilt_etannitemplate_test.rb" 
> "test/tilt_hamltemplate_test.rb" "test/tilt_kramdown_test.rb" 
> "test/tilt_lesstemplate_test.rb" "test/tilt_liquidtemplate_test.rb" 
> "test/tilt_livescripttemplate_test.rb" "test/tilt_mapping_test.rb" 
> "test/tilt_markaby_test.rb" "test/tilt_markdown_test.rb" 
> "test/tilt_marukutemplate_test.rb" "test/tilt_metadata_test.rb" 
> "test/tilt_nokogiritemplate_test.rb" "test/tilt_pandoctemplate_test.rb" 
> "test/tilt_prawntemplate_test.rb" "test/tilt_radiustemplate_test.rb" 
> "test/tilt_rdiscounttemplate_test.rb" "test/tilt_rdoctemplate_test.rb" 
> "test/tilt_redcarpettemplate_test.rb" "test/tilt_redclothtemplate_test.rb" 
> "test/tilt_rstpandoctemplate_test.rb" "test/tilt_sasstemplate_test.rb" 
> "test/tilt_sigil_test.rb" "test/tilt_stringtemplate_test.rb" 
> "test/tilt_template_test.rb" "test/tilt_test.rb" 
> "test/tilt_typescript_test.rb" "test/tilt_wikiclothtemplate_test.rb" 
> "test/tilt_yajltemplate_test.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-tilt/ruby-tilt_2.0.10-1+rebuild1633397153_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996514: ruby-terrapin: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Failure/Error: undef_method :exitstatus

[Antonio Terceiro]

Source: ruby-terrapin
Version: 0.6.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-terrapin was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>  Failure/Error: undef_method :exitstatus
> 
>  FrozenError:
>can't modify frozen object: pid 1724074 exit 0
>  # ./spec/support/unsetting_exitstatus.rb:4:in `undef_method'
>  # ./spec/support/unsetting_exitstatus.rb:4:in `singleton class'
>  # ./spec/support/unsetting_exitstatus.rb:3:in 
> `assuming_no_processes_have_been_run'
>  # ./spec/terrapin/errors_spec.rb:55:in `block (2 levels) in  (required)>'
> 
> Deprecation Warnings:
> 
> Using `should` from rspec-expectations' old `:should` syntax without 
> explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or 
> explicitly enable `:should` with `config.expect_with(:rspec) { |c| c.syntax = 
> :should }` instead. Called from 
> /<>/spec/terrapin/command_line/runners/backticks_runner_spec.rb:19:in
>  `block (2 levels) in '.
> 
> 
> If you need more of the backtrace for any of these deprecations to
> identify where to make the necessary changes, you can configure
> `config.raise_errors_for_deprecations!`, and it will turn the
> deprecation warnings into errors, giving you the full backtrace.
> 
> 1 deprecation warning total
> 
> Finished in 1.4 seconds (files took 0.51763 seconds to load)
> 67 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/terrapin/errors_spec.rb:54 # When an error happens does not blow 
> up if running the command errored before execution
> 
> /usr/bin/ruby3.0 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-terrapin/ruby-terrapin_0.6.0-2+rebuild1633396815_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996513: ruby-stackprof: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed.

[Antonio Terceiro]

Source: ruby-stackprof
Version: 0.2.15-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-stackprof was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-stackprof/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0:/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\ \"stackprof\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-stackprof/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0:/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/test_middleware.rb" "test/test_report.rb" "test/test_stackprof.rb" -v
> /<>/test/test_stackprof.rb:181: warning: assigned but unused 
> variable - raw
> Run options: -v --seed 11397
> 
> # Running:
> 
> StackProfTest#test_raw = 0.00 s = F
> StackProfTest#test_info = 0.00 s = .
> StackProfTest#test_out_to_path_string = 0.00 s = .
> StackProfTest#test_custom = 0.00 s = F
> StackProfTest#test_raises_if_metadata_is_not_a_hash = 0.00 s = .
> StackProfTest#test_metadata = 0.04 s = .
> StackProfTest#test_running = 0.00 s = .
> StackProfTest#test_object_allocation = 0.00 s = F
> StackProfTest#test_cputime = 0.04 s = F
> StackProfTest#test_gc = 0.08 s = .
> StackProfTest#test_empty_metadata = 0.03 s = .
> StackProfTest#test_object_allocation_interval = 0.00 s = .
> StackProfTest#test_recursive_total_samples = 0.00 s = .
> StackProfTest#test_start_stop_results = 0.00 s = .
> StackProfTest#test_fork = 0.00 s = .
> StackProfTest#test_walltime = 0.20 s = F
> StackProfTest#test_pathname_out = 0.00 s = .
> StackProfTest#test_out = 0.00 s = .
> StackProf::MiddlewareTest#test_enabled_should_use_a_proc_if_passed = 0.00 s = 
> .
> StackProf::MiddlewareTest#test_raw = 0.00 s = .
> StackProf::MiddlewareTest#test_path_custom = 0.00 s = .
> StackProf::MiddlewareTest#test_save_custom = 0.00 s = .
> StackProf::MiddlewareTest#test_save_default = 0.00 s = .
> StackProf::MiddlewareTest#test_enabled_should_use_a_proc_if_passed_and_use_the_request_env
>  = 0.00 s = .
> StackProf::MiddlewareTest#test_metadata = 0.00 s = .
> StackProf::MiddlewareTest#test_path_default = 0.00 s = .
> ReportDumpTest#test_dump_to_file = 0.02 s = .
> ReportDumpTest#test_dump_to_stdout = 0.00 s = .
> 
> Finished in 0.424334s, 65.9858 runs/s, 164.9644 assertions/s.
> 
>   1) Failure:
> StackProfTest#test_raw [/<>/test/test_stackprof.rb:108]:
> Expected # encoding: ASCII-8BIT
> #valid: true
> "StackProf.sample" to include "StackProfTest#test_raw".
> 
>   2) Failure:
> StackProfTest#test_custom [/<>/test/test_stackprof.rb:93]:
> Expected # encoding: ASCII-8BIT
> #valid: true
> "StackProf.sample" to include "StackProfTest#test_custom".
> 
>   3) Failure:
> StackProfTest#test_object_allocation 
> [/<>/test/test_stackprof.rb:42]:
> Expected: 2
>   Actual: 4
> 
>   4) Failure:
> StackProfTest#test_cputime [/<>/test/test_stackprof.rb:68]:
> Expected # encoding: ASCII-8BIT
> #valid: true
> "Integer#**" to include "StackProfTest#math".
> 
>   5) Failure:
> StackProfTest#test_walltime [/<>/test/test_stackprof.rb:77]:
> --- expected
> +++ actual
> @@ -1 +1,3 @@
> -"StackProfTest#idle"
> +# encoding: ASCII-8BIT
> +#valid: true
> +"IO.select"
> 
> 
> 28 runs, 70 assertions, 5 failures, 0 errors, 0 skips
> 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/test_middleware.rb" "test/test_report.rb" "test/test_stackprof.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed.


The full build log is available at
https://people.debian.org/~kanashiro/rub

Bug#996512: ruby-spy: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: ArgumentError: tried to create Proc object without a block

[Antonio Terceiro]

Source: ruby-spy
Version: 0.4.3-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-spy was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> ArgumentError: tried to create Proc object without a block
> 
> /<>/debian/ruby-spy/usr/lib/ruby/vendor_ruby/spy/subroutine.rb:196:in
>  `new'
> 
> /<>/debian/ruby-spy/usr/lib/ruby/vendor_ruby/spy/subroutine.rb:196:in
>  `has_been_called_with?'
> 
> /<>/debian/ruby-spy/usr/lib/ruby/vendor_ruby/spy/api.rb:11:in 
> `assert_received_with'
> /<>/test/integration/test_api.rb:19:in 
> `test_assert_received_with'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'
> 
> 65 runs, 108 assertions, 0 failures, 5 errors, 0 skips
> 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/integration/test_api.rb" "test/integration/test_constant_spying.rb" 
> "test/integration/test_instance_method.rb" "test/integration/test_mocking.rb" 
> "test/integration/test_subroutine_spying.rb" "test/spy/test_mock.rb" 
> "test/spy/test_subroutine.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 at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-spy/ruby-spy_0.4.3-1+rebuild1633396140_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996511: ruby-sprockets: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: ArgumentError: wrong number of arguments (given 2, expected 1)

[Antonio Terceiro]

Source: ruby-sprockets
Version: 3.7.2-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-sprockets was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> ArgumentError: wrong number of arguments (given 2, expected 1)
> :14:in `open'
> /<>/test/test_performance.rb:23:in `entries'
> /<>/test/test_performance.rb:23:in `entries'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/path_utils.rb:56:in
>  `entries'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/cached_environment.rb:19:in
>  `block in initialize'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/cached_environment.rb:35:in
>  `entries'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:179:in
>  `dirname_matches'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:157:in
>  `path_matches'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:125:in
>  `block in resolve_under_paths'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:124:in
>  `each'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:124:in
>  `resolve_under_paths'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:108:in
>  `resolve_logical_path'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/resolve.rb:35:in
>  `resolve'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/legacy.rb:66:in
>  `resolve_with_compat'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/base.rb:64:in
>  `find_asset'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/environment.rb:30:in
>  `find_asset'
> 
> /<>/debian/ruby-sprockets/usr/lib/ruby/vendor_ruby/sprockets/base.rb:92:in
>  `[]'
> /<>/test/test_sprocketize.rb:58:in `block in 
> '
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest/parallel.rb:33:in `block (2 levels) in 
> start'
> 
> 773 runs, 1320 assertions, 26 failures, 422 errors, 2 skips
> 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/test_asset.rb" "test/test_bundle.rb" "test/test_cache_store.rb" 
> "test/test_caching.rb" "test/test_coffee_script_processor.rb" 
> "test/test_context.rb" "test/test_digest_utils.rb" 
> "test/test_ejs_processor.rb" "test/test_encoding.rb" 
> "test/test_encoding_utils.rb" "test/test_engines.rb" 
> "test/test_environment.rb" "test/test_erb_processor.rb" 
> "test/test_http_utils.rb" "test/test_jst_processor.rb" "test/test_loader.rb" 
> "test/test_manifest.rb" "test/test_manifest_utils.rb" 
> "test/test_path_dependency_utils.rb" "test/test_path_digest_utils.rb" 
> "test/test_path_utils.rb" "test/test_performance.rb" 
> "test/test_processor_utils.rb" "test/test_rake_task.rb" 
> "test/test_require.rb" "test/test_resolve.rb" "test/test_sass.rb" 
> "test/test_server.rb" "test/test_source_maps.rb" "test/test_sprocketize.rb" 
> "test/test_transformers.rb" "test/test_uglifier_compressor.rb" 
> "test/test_uri_tar.rb" "test/test_uri_utils.rb" "test/test_utils.rb" 
> "--exclude=/eco|closure|yui/" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-sprockets/ruby-sprockets_3.7.2-1+rebuild1633396062_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996510: ruby-spring: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Errno::ENOENT: No such file or directory @ rb_check_realpath_internal - /tmp/d20211005-1582813-mce9ae

[Antonio Terceiro]

Source: ruby-spring
Version: 2.1.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-spring was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> Errno::ENOENT: No such file or directory @ rb_check_realpath_internal - 
> /tmp/d20211005-1582813-mce9ae
> /<>/lib/spring/watcher/abstract.rb:20:in `realpath'
> /<>/lib/spring/watcher/abstract.rb:20:in `initialize'
> /<>/lib/spring/watcher/polling.rb:9:in `initialize'
> /<>/test/support/watcher_test.rb:21:in `new'
> /<>/test/support/watcher_test.rb:21:in `watcher'
> /<>/test/support/watcher_test.rb:30:in `teardown'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:103:in `block (4 levels) in 
> run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:102:in `block (3 levels) in 
> run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:101:in `each'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:101:in `block (2 levels) in 
> run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'
> 
> 32 runs, 31 assertions, 0 failures, 8 errors, 0 skips
> 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/unit/client/help_test.rb" "test/unit/client/version_test.rb" 
> "test/unit/commands_test.rb" "test/unit/process_title_updater_test.rb" 
> "test/unit/watcher_test.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-spring/ruby-spring_2.1.0-2+rebuild1633395982_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996509: ruby-slop: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: ArgumentError: wrong number of arguments (given 2, expected 1)

[Antonio Terceiro]

Source: ruby-slop
Version: 4.6.2-1.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

Hi,

We are about to enable building against ruby3.0 on unstable. During a test
rebuild, ruby-slop was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-all-dev from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> ArgumentError: wrong number of arguments (given 2, expected 1)
> /<>/lib/slop/parser.rb:13:in `initialize'
> /<>/lib/slop/options.rb:32:in `new'
> /<>/lib/slop/options.rb:32:in `initialize'
> /<>/test/result_test.rb:15:in `new'
> /<>/test/result_test.rb:15:in `block (2 levels) in  (required)>'
> /usr/lib/ruby/vendor_ruby/minitest/spec.rb:187:in `instance_eval'
> /usr/lib/ruby/vendor_ruby/minitest/spec.rb:187:in `block in before'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:96:in `block (3 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'
> 
> 79 runs, 7 assertions, 0 failures, 73 errors, 0 skips
> rake aborted!
> Command failed with status (1)
> 
> Tasks: TOP => default => test
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-slop/ruby-slop_4.6.2-1.1+rebuild1633395769_amd64.build.txt


signature.asc
Description: PGP signature

Bug#996265: autopkgtest: The dependency of each test is added to the dependencies of the following tests

[Fab Stz]

Hello Paul,

Thanks for taking the time to look at this.

> Can you please specify which backend you're using? This is *not* what
> I'm seeing in the runs on ci.d.n which uses lxc. As an example, one of
> my packages has Depends mariadb-server in the first test, it doesn't get
> installed in the second test [1]. Can you also share the sources (at
> least debian/control) of the package that builds
> google-android-build-tools-*-installer)? 

I forked the google-android-* packages to update them. The changes have 
not been merged yet that may be why don't. My fork is here [1].

> Are you sure -21.1.2-installer
> has no Dependency itself on the lower version?

I checked again, I don't see such a dependency.

The test jobs are run from the automatic salsa-ci server. I don't know which 
backend is actually used. Ci job is defined here: [4]

You can have a look at the logs of this job here [2]

tests/control can be seen here [3]

[1] https://salsa.debian.org/bastif/google-android-installers
[2] https://salsa.debian.org/bastif/google-android-installers/-/jobs/2069646/
raw
[3] https://salsa.debian.org/bastif/google-android-installers/-/blob/master/
debian/tests/control
[4] https://salsa.debian.org/bastif/google-android-installers/-/blob/master/
debian/.gitlab-ci.yml

Thanks
Fab

Bug#996508: reportbug: davmail server doesn't start

[Peter Chubb]

Package: davmail
Version: 6.0.0.3375-2
Severity: normal

Dear Maintainer,

After upgrading davmail, it did not start.  /usr/bin/davmail is now a jar file; 
it doesn't run without java.

/etc/init.d/davmail start
dows not give any information. (and does not start the server).

I had to do:
  java -jar /usr/bin/davmail -server /etc/davmail/davmail.properties
to start the server.

I'm running davmail in a container, if that makes a difference.
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-72
ii  init-system-helpers   1.60
ii  jarwrapper0.78
ii  libcommons-codec-java 1.15-1
ii  libcommons-httpclient-java3.1-16
ii  libcommons-logging-java   1.2-2
ii  libhtmlcleaner-java   2.24-1
ii  libhttpclient-java4.5.13-3
ii  libjackrabbit-java2.20.3-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.4.1-1
ii  liblog4j1.2-java  1.2.17-10
ii  libmail-java  1.6.5-1
ii  libservlet-api-java   4.0.1-2
ii  libslf4j-java 1.7.32-1
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.1-1
ii  logrotate 3.18.1-2
ii  lsb-base  11.1.0
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.12+7-2

davmail recommends no packages.

Versions of packages davmail suggests:
pn  default-jre 
pn  libopenjfx-java 
pn  libswt-cairo-gtk-4-jni  

-- Configuration Files:
/etc/davmail/davmail.properties changed:
 DavMail settings, see http://davmail.sourceforge.net/ for documentation
davmail.server=true
davmail.mode=EWS
davmail.url=https://outlook.office365.com/EWS/Exchange.asmx
davmail.caldavPort=8443
davmail.imapPort=1143
davmail.ldapPort=1389
davmail.popPort=1110
davmail.smtpPort=1025
davmail.enableProxy=false
davmail.useSystemProxies=false
davmail.proxyHost=
davmail.proxyPort=
davmail.proxyUser=
davmail.proxyPassword=
davmail.noProxyFor=
davmail.allowRemote=true
davmail.bindAddress=
davmail.clientSoTimeout=
davmail.ssl.keystoreType=PKCS12
davmail.ssl.keystoreFile=/etc/davmail/davmail.p12
davmail.ssl.keystorePass=redacted
davmail.ssl.keyPass=redacted
davmail.server.certificate.hash=
davmail.ssl.nosecurecaldav=false
davmail.ssl.nosecureimap=false
davmail.ssl.nosecureldap=false
davmail.ssl.nosecurepop=false
davmail.ssl.nosecuresmtp=false
davmail.disableUpdateCheck=true
davmail.enableKeepAlive=true
davmail.folderSizeLimit=0
davmail.defaultDomain=
davmail.caldavAlarmSound=
davmail.caldavPastDelay=90
davmail.caldavAutoSchedule=true
davmail.forceActiveSyncUpdate=false
davmail.imapAutoExpunge=true
davmail.imapIdleDelay=
davmail.imapAlwaysApproxMsgSize=
davmail.keepDelay=30
davmail.sentKeepDelay=90
davmail.popMarkReadOnRetr=false
davmail.smtpSaveInSent=true
davmail.logFilePath=/var/log/davmail/davmail.log
davmail.logFileSize=1MB
log4j.logger.davmail=WARN
log4j.logger.httpclient.wire=WARN
log4j.logger.org.apache.commons.httpclient=WARN
log4j.rootLogger=WARN

-- no debconf information

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

[Jean-Pierre Giraud]

hi

Le 13/10/2021 à 22:58, Aurelien Jarno a écrit :

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


I am really sorry... I send you the forgotten file.
Regards
Jean-Pierre Giraud


fr.po.xz
Description: application/xz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#996507: trilinos-all-dev: No rule to make target '/usr/lib/x86_64-linux-gnu/libdl.so'

[Nico Schlömer]

Package: trilinos-all-dev
Version: 12.18.1-2
Severity: normal
X-Debbugs-Cc: nico.schloe...@gmail.com

Dear Maintainer,

First of all, I need to say because I'm partly responsible for making this a
"monster" package of packages. It really should have been a libtrilinos-dev
with no subpackaging, this would have made maintaining the thing a lot easier.
Anyway.

I've just tried to build my old Trilinos package [1] for old times' sake, and
it fails with
```
Scanning dependencies of target mikado
[  8%] Building CXX object src/CMakeFiles/mikado.dir/helpers.cpp.o
[ 16%] Building CXX object src/CMakeFiles/mikado.dir/nonlinear_solver.cpp.o
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/libdl.so', neede
```
Not sure what's going wrong, but looks like an outdated build on Debian's side.

Any hints?

Cheers,
Nico

[1] https://github.com/nschloe/mikado


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

Kernel: Linux 5.13.0-16-generic (SMP w/8 CPU threads)
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 trilinos-all-dev depends on:
ii  libtrilinos-amesos-dev 12.18.1-2
ii  libtrilinos-amesos2-dev12.18.1-2
ii  libtrilinos-anasazi-dev12.18.1-2
ii  libtrilinos-aztecoo-dev12.18.1-2
ii  libtrilinos-belos-dev  12.18.1-2
ii  libtrilinos-epetra-dev 12.18.1-2
ii  libtrilinos-epetraext-dev  12.18.1-2
ii  libtrilinos-galeri-dev 12.18.1-2
ii  libtrilinos-globipack-dev  12.18.1-2
ii  libtrilinos-ifpack-dev 12.18.1-2
ii  libtrilinos-ifpack2-dev12.18.1-2
ii  libtrilinos-intrepid-dev   12.18.1-2
ii  libtrilinos-intrepid2-dev  12.18.1-2
ii  libtrilinos-isorropia-dev  12.18.1-2
ii  libtrilinos-kokkos-dev 12.18.1-2
ii  libtrilinos-kokkos-kernels-dev 12.18.1-2
ii  libtrilinos-komplex-dev12.18.1-2
ii  libtrilinos-ml-dev 12.18.1-2
ii  libtrilinos-moertel-dev12.18.1-2
ii  libtrilinos-muelu-dev  12.18.1-2
ii  libtrilinos-nox-dev12.18.1-2
ii  libtrilinos-optipack-dev   12.18.1-2
ii  libtrilinos-pamgen-dev 12.18.1-2
ii  libtrilinos-phalanx-dev12.18.1-2
ii  libtrilinos-pike-dev   12.18.1-2
ii  libtrilinos-piro-dev   12.18.1-2
ii  libtrilinos-pliris-dev 12.18.1-2
ii  libtrilinos-rol-dev12.18.1-2
ii  libtrilinos-rtop-dev   12.18.1-2
ii  libtrilinos-rythmos-dev12.18.1-2
ii  libtrilinos-sacado-dev 12.18.1-2
ii  libtrilinos-shards-dev 12.18.1-2
ii  libtrilinos-shylu-dev  12.18.1-2
ii  libtrilinos-stokhos-dev12.18.1-2
ii  libtrilinos-stratimikos-dev12.18.1-2
ii  libtrilinos-teko-dev   12.18.1-2
ii  libtrilinos-teuchos-dev12.18.1-2
ii  libtrilinos-thyra-dev  12.18.1-2
ii  libtrilinos-tpetra-dev 12.18.1-2
ii  libtrilinos-trilinoscouplings-dev  12.18.1-2
ii  libtrilinos-triutils-dev   12.18.1-2
ii  libtrilinos-xpetra-dev 12.18.1-2
ii  libtrilinos-zoltan-dev 12.18.1-2
ii  libtrilinos-zoltan2-dev12.18.1-2

trilinos-all-dev recommends no packages.

Versions of packages trilinos-all-dev suggests:
pn  trilinos-doc  

Bug#996328: Additional information

[David Christensen]

bugs.debian.org:

I moved the Debian 10 instance disk from the Dell Latitude E6520 laptop 
with Optimus graphics to a Intel DQ67SW motherboard desktop with Intel 
integrated graphics.  The Xfce desktop issues remain.



I installed a Debian 9 instance disk into the DQ67SW and ran it for 
several hours.  I did not experience any Xfce desktop issues.



I moved the Debian 9 instance disk to the E6520 and ran it for several 
hours.  I experienced one event where a second instance of Oracle VM 
VirtualBox Manager version 6.1.26 r145957 (Qt5.7.1) spontaneously opened 
and then minimized.



David

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Andreas Beckmann]

Control: tag -1 pending

On 22/09/2021 15.59, Giuseppe Bilotta wrote:

The virtual ABI package sounds like the best choice.


I've tried to implement this in src:intel-graphics-compiler and 
src:intel-compute-runtime. Couldn't test the first one due to the gcc 11 
ftbfs, but the second one does what I want it to ;-)
Commits are pushed to both packages in git, they need a coordinated 
upload due to the Depends/Breaks added.


Andreas

Bug#996489: awscli: Cryptic error if awscli and boto versions mismatch

[Phil Endecott]

Package: awscli
Version: 1.20.53-1
Severity: normal

Dear Maintainer,

On a system running bullseye (11.1), I wanted to install a newer 
version of awscli. So I added sources.list entries for testing, set 
APT::Default-Release "bullseye"; and then

# apt-get install -t testing install awscli

This installed awscli 1.20.53-1, but it did not change 
python3-botocore which remained at version 1.20.0+repack-1 
(from bullseye) because awscli only requires python3-botocore 
>= 1.20.0.

"aws help" worked but this failed:

  $ aws lambda update-function-configuration help
  'StructureShape' object has no attribute 'is_document_type'

I then upgraded python3-botocore to the bookworm version, 
1.21.53+repack-1:

# apt-get install -t testing python3-botocore

and now awscli seems to function correctly.

It seems to me that awscli should have a tighter dependency on 
python3-botocore.

(I am a bit confused by the version numbers; it looks as if 
awscli 20.x corresponds to boto3 21.x ? What's going on there?)


Thanks, Phil.

Bug#996505: cryptsetup: set CRYPTTAB_OPTION_tries for keyscripts when not explicitly set

[Christoph Anton Mitterer]

Package: cryptsetup
Version: 2:2.4.0-1
Severity: wishlist


Hey.

I've noted that when there is no explicit tries=n in crypttab, that
CRYPTTAB_OPTION_tries isn't set either for the keyscripts.

I think it might sense to actually have that set then (to it's default
of 3) so that keyscripts still see (with the correct number) that there
are several tries.


Cheers,
Chris.

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

On 14 October 2021 at 23:20, Sebastian Ramacher wrote:
| On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote:
| > 
| > Hi Sebastian,
| > 
| > On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| > | Hi Dirk
| > | 
| > | On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
| > | > 
| > | > On 30 August 2021 at 23:42, Niko Tyni wrote:
| > | > | Package: libgsl25
| > | > | Version: 2.7+dfsg-2
| > | > | Control: affects -1 libmath-gsl-perl
| > | > | Severity: serious
| > | > | 
| > | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest 
regressions:
| > | > | 
| > | > |not ok 7 - use Math::GSL::Matrix;
| > | > |
| > | > |#   Failed test 'use Math::GSL::Matrix;'
| > | > |#   at t/00-load.t line 14.
| > | > |# Tried to use 'Math::GSL::Matrix'.
| > | > |# Error:  Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for 
module Math::GSL::Linalg: 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined 
symbol: gsl_linalg_QR_TR_decomp at 
/usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187.
| > | > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm 
line 11.
| > | > |# Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
| > | > |# BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
| > | > |# Compilation failed in require at t/00-load.t line 14.
| > | > |# BEGIN failed--compilation aborted at t/00-load.t line 14.
| > | > |ok 8 - use Math::GSL::Poly;
| > | > |not ok 9 - use Math::GSL::MatrixComplex;
| > | > | 
| > | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing
| > | > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from
| > | > | entering testing because of this regression in 
libmath-gsl-perl_0.42-1.
| > | > | 
| > | > | Looks like upstream Math-GSL-0.43 probably no longer references this
| > | > | symbol, but it's not in Debian yet and I haven't built and verified 
that.
| > | > | 
| > | > | Clearly at least something must be done on the libgsl side. Not sure 
if
| > | > | it needs to restore the symbol or bump its SONAME, or if just a Breaks
| > | > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2)
| > | > 
| > | > I am not fully sure what they are doing.  They do increment values 
sometimes,
| > | > sometimes they keep them. I mostly just followed along.
| > | > 
| > | > We also for a time tried to accomodate lagging Debian packages. I do not
| > | > think that that winnable strategy long term.
| > | > 
| > | > I could add a versioned breaks for libmath-gsl-perl.  Can you send me a
| > | > preferred expression?
| > | 
| > | No, that would just paper over the problem and wouldn't be a proper fix.
| > | 
| > | There are two options to fix this issue:
| > | 
| > | * Unbreak the ABI by reintroducing the removed symbols.
| > 
| > I think we tried that a few gsl release ago and I don't think it was a 
success.
| > 
| > | * Bump the SONAME and change the package name. This will trigger a
| > |   transition and the reverse dependencies will be rebuilt.
| > | 
| > | In any case, the best idea is to talk to upstream. If removal of the
| > | symbols was intentional, please ask them to bump the SONAME.
| > 
| > It is AFAICR the opposite: upstream *did* the change years ago, we decided 
to
| > paper over but at some point that becomes too much.  Upstream is, in my 
book,
| > the best judge of their code, and if they deprecated / changed something
| > years ago then client packages need to (eventually) adapt.
| 
| gsl 2.7 was released in June 2021. So the removal of this symbol is
| recent. I see no patches that would have kept that symbol around for
| longer than it was needed. In fact, diffing 2.6 and 2.7 suggests that
| gsl_linalg_QR_TR_decomp was simply renamed to gsl_linalg_QR_UR_decmp.
| 
| So I'm afraid I am unable to follow your reasoning. This is pretty clear
| case of upstream forgetting to bump the SONAME.

Yes, possibly. I also grep'ed after sending the email.

We did have such an attempt at a 'managed' transition before, and it didn't
work so well.
 
| > If the Perl package needs a (deprecated in the library) function and cannot
| > change its code, maybe it can stub it locally?
| 
| libmath-gsl-perl will eventually need to be fixed. Still, if gsl removes
| a symbol from its public ABI, it needs to bump its SONAME. That's why we
| have them and even encode it in package names.

Yes. And I follow upstream. They didn't change :-/

Dirk
 
| Cheers
| 
| > 
| > Dirk
| > 
| > 
| > | Cheers
| > | 
| > | > 
| > | > | I've also filed the separate bug #993323 about libmath-gsl-perl 
failing to
| > | > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43.
| > | > 
| > | > Right.
| > | > 
| > | > Dirk
| > | > 
| > | > | -- 
| > | > | Niko Tyni nt...@debian.org
| > | > 
| > | > -- 
| >

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Sebastian Ramacher]

On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote:
> 
> Hi Sebastian,
> 
> On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
> | Hi Dirk
> | 
> | On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
> | > 
> | > On 30 August 2021 at 23:42, Niko Tyni wrote:
> | > | Package: libgsl25
> | > | Version: 2.7+dfsg-2
> | > | Control: affects -1 libmath-gsl-perl
> | > | Severity: serious
> | > | 
> | > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest 
> regressions:
> | > | 
> | > |not ok 7 - use Math::GSL::Matrix;
> | > |
> | > |#   Failed test 'use Math::GSL::Matrix;'
> | > |#   at t/00-load.t line 14.
> | > |# Tried to use 'Math::GSL::Matrix'.
> | > |# Error:  Can't load 
> '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for 
> module Math::GSL::Linalg: 
> /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: 
> undefined symbol: gsl_linalg_QR_TR_decomp at 
> /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187.
> | > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 
> 11.
> | > |# Compilation failed in require at 
> /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
> | > |# BEGIN failed--compilation aborted at 
> /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
> | > |# Compilation failed in require at t/00-load.t line 14.
> | > |# BEGIN failed--compilation aborted at t/00-load.t line 14.
> | > |ok 8 - use Math::GSL::Poly;
> | > |not ok 9 - use Math::GSL::MatrixComplex;
> | > | 
> | > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing
> | > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from
> | > | entering testing because of this regression in libmath-gsl-perl_0.42-1.
> | > | 
> | > | Looks like upstream Math-GSL-0.43 probably no longer references this
> | > | symbol, but it's not in Debian yet and I haven't built and verified 
> that.
> | > | 
> | > | Clearly at least something must be done on the libgsl side. Not sure if
> | > | it needs to restore the symbol or bump its SONAME, or if just a Breaks
> | > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2)
> | > 
> | > I am not fully sure what they are doing.  They do increment values 
> sometimes,
> | > sometimes they keep them. I mostly just followed along.
> | > 
> | > We also for a time tried to accomodate lagging Debian packages. I do not
> | > think that that winnable strategy long term.
> | > 
> | > I could add a versioned breaks for libmath-gsl-perl.  Can you send me a
> | > preferred expression?
> | 
> | No, that would just paper over the problem and wouldn't be a proper fix.
> | 
> | There are two options to fix this issue:
> | 
> | * Unbreak the ABI by reintroducing the removed symbols.
> 
> I think we tried that a few gsl release ago and I don't think it was a 
> success.
> 
> | * Bump the SONAME and change the package name. This will trigger a
> |   transition and the reverse dependencies will be rebuilt.
> | 
> | In any case, the best idea is to talk to upstream. If removal of the
> | symbols was intentional, please ask them to bump the SONAME.
> 
> It is AFAICR the opposite: upstream *did* the change years ago, we decided to
> paper over but at some point that becomes too much.  Upstream is, in my book,
> the best judge of their code, and if they deprecated / changed something
> years ago then client packages need to (eventually) adapt.

gsl 2.7 was released in June 2021. So the removal of this symbol is
recent. I see no patches that would have kept that symbol around for
longer than it was needed. In fact, diffing 2.6 and 2.7 suggests that
gsl_linalg_QR_TR_decomp was simply renamed to gsl_linalg_QR_UR_decmp.

So I'm afraid I am unable to follow your reasoning. This is pretty clear
case of upstream forgetting to bump the SONAME.

> If the Perl package needs a (deprecated in the library) function and cannot
> change its code, maybe it can stub it locally?

libmath-gsl-perl will eventually need to be fixed. Still, if gsl removes
a symbol from its public ABI, it needs to bump its SONAME. That's why we
have them and even encode it in package names.

Cheers

> 
> Dirk
> 
> 
> | Cheers
> | 
> | > 
> | > | I've also filed the separate bug #993323 about libmath-gsl-perl failing 
> to
> | > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43.
> | > 
> | > Right.
> | > 
> | > Dirk
> | > 
> | > | -- 
> | > | Niko Tyni nt...@debian.org
> | > 
> | > -- 
> | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | 
> | -- 
> | Sebastian Ramacher
> | [DELETED ATTACHMENT signature.asc, application/pgp-signature]
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#980559: angelscript: FTBFS on arm64: test error

[Reiner Herrmann]

On Thu, Oct 14, 2021 at 05:46:30PM +0200, Reiner Herrmann wrote:
> I was able to fix it by including arm64 in the "buggy archs" list
> in debian/rules (see below).

FTR I tested my change based on 2.35.1+ds-1 (not -2).


signature.asc
Description: PGP signature

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

Hi Sebastian,

On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| Hi Dirk
| 
| On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
| > 
| > On 30 August 2021 at 23:42, Niko Tyni wrote:
| > | Package: libgsl25
| > | Version: 2.7+dfsg-2
| > | Control: affects -1 libmath-gsl-perl
| > | Severity: serious
| > | 
| > | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest 
regressions:
| > | 
| > |not ok 7 - use Math::GSL::Matrix;
| > |
| > |#   Failed test 'use Math::GSL::Matrix;'
| > |#   at t/00-load.t line 14.
| > |# Tried to use 'Math::GSL::Matrix'.
| > |# Error:  Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for 
module Math::GSL::Linalg: 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined 
symbol: gsl_linalg_QR_TR_decomp at 
/usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187.
| > |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11.
| > |# Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
| > |# BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
| > |# Compilation failed in require at t/00-load.t line 14.
| > |# BEGIN failed--compilation aborted at t/00-load.t line 14.
| > |ok 8 - use Math::GSL::Poly;
| > |not ok 9 - use Math::GSL::MatrixComplex;
| > | 
| > | It seems that the 2.7 upload broke the ABI of libgsl25 by removing
| > | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from
| > | entering testing because of this regression in libmath-gsl-perl_0.42-1.
| > | 
| > | Looks like upstream Math-GSL-0.43 probably no longer references this
| > | symbol, but it's not in Debian yet and I haven't built and verified that.
| > | 
| > | Clearly at least something must be done on the libgsl side. Not sure if
| > | it needs to restore the symbol or bump its SONAME, or if just a Breaks
| > | on older libmath-gsl-perl versions is enough. (See policy 8.6.2)
| > 
| > I am not fully sure what they are doing.  They do increment values 
sometimes,
| > sometimes they keep them. I mostly just followed along.
| > 
| > We also for a time tried to accomodate lagging Debian packages. I do not
| > think that that winnable strategy long term.
| > 
| > I could add a versioned breaks for libmath-gsl-perl.  Can you send me a
| > preferred expression?
| 
| No, that would just paper over the problem and wouldn't be a proper fix.
| 
| There are two options to fix this issue:
| 
| * Unbreak the ABI by reintroducing the removed symbols.

I think we tried that a few gsl release ago and I don't think it was a success.

| * Bump the SONAME and change the package name. This will trigger a
|   transition and the reverse dependencies will be rebuilt.
| 
| In any case, the best idea is to talk to upstream. If removal of the
| symbols was intentional, please ask them to bump the SONAME.

It is AFAICR the opposite: upstream *did* the change years ago, we decided to
paper over but at some point that becomes too much.  Upstream is, in my book,
the best judge of their code, and if they deprecated / changed something
years ago then client packages need to (eventually) adapt.

If the Perl package needs a (deprecated in the library) function and cannot
change its code, maybe it can stub it locally?

Dirk


| Cheers
| 
| > 
| > | I've also filed the separate bug #993323 about libmath-gsl-perl failing to
| > | build with GSL 2.7. That should be fixed just by upgrading it to 0.43.
| > 
| > Right.
| > 
| > Dirk
| > 
| > | -- 
| > | Niko Tyni nt...@debian.org
| > 
| > -- 
| > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| 
| -- 
| Sebastian Ramacher
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

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

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Sebastian Ramacher]

Hi Dirk

On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
> 
> On 30 August 2021 at 23:42, Niko Tyni wrote:
> | Package: libgsl25
> | Version: 2.7+dfsg-2
> | Control: affects -1 libmath-gsl-perl
> | Severity: serious
> | 
> | gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest 
> regressions:
> | 
> |not ok 7 - use Math::GSL::Matrix;
> |
> |#   Failed test 'use Math::GSL::Matrix;'
> |#   at t/00-load.t line 14.
> |# Tried to use 'Math::GSL::Matrix'.
> |# Error:  Can't load 
> '/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for 
> module Math::GSL::Linalg: 
> /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: 
> undefined symbol: gsl_linalg_QR_TR_decomp at 
> /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187.
> |# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11.
> |# Compilation failed in require at 
> /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
> |# BEGIN failed--compilation aborted at 
> /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
> |# Compilation failed in require at t/00-load.t line 14.
> |# BEGIN failed--compilation aborted at t/00-load.t line 14.
> |ok 8 - use Math::GSL::Poly;
> |not ok 9 - use Math::GSL::MatrixComplex;
> | 
> | It seems that the 2.7 upload broke the ABI of libgsl25 by removing
> | the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from
> | entering testing because of this regression in libmath-gsl-perl_0.42-1.
> | 
> | Looks like upstream Math-GSL-0.43 probably no longer references this
> | symbol, but it's not in Debian yet and I haven't built and verified that.
> | 
> | Clearly at least something must be done on the libgsl side. Not sure if
> | it needs to restore the symbol or bump its SONAME, or if just a Breaks
> | on older libmath-gsl-perl versions is enough. (See policy 8.6.2)
> 
> I am not fully sure what they are doing.  They do increment values sometimes,
> sometimes they keep them. I mostly just followed along.
> 
> We also for a time tried to accomodate lagging Debian packages. I do not
> think that that winnable strategy long term.
> 
> I could add a versioned breaks for libmath-gsl-perl.  Can you send me a
> preferred expression?

No, that would just paper over the problem and wouldn't be a proper fix.

There are two options to fix this issue:

* Unbreak the ABI by reintroducing the removed symbols.

* Bump the SONAME and change the package name. This will trigger a
  transition and the reverse dependencies will be rebuilt.

In any case, the best idea is to talk to upstream. If removal of the
symbols was intentional, please ask them to bump the SONAME.

Cheers

> 
> | I've also filed the separate bug #993323 about libmath-gsl-perl failing to
> | build with GSL 2.7. That should be fixed just by upgrading it to 0.43.
> 
> Right.
> 
> Dirk
> 
> | -- 
> | Niko Tyni nt...@debian.org
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996504: ITP: oxigraph -- SPARQL server based on Oxigraph graph database

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: oxigraph
  Version : 0.2.5
  Upstream Author : Tpt 
* URL : https://github.com/oxigraph/oxigraph
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : SPARQL server based on Oxigraph graph database

 Oxigraph Server is a standalone HTTP server
 providing a graph database
 implementing the SPARQL 1.1 Protocol
 and SPARQL 1.1 Graph Store Protocol standards.
 .
 SPARQL is an RDF query language -
 that is, a semantic query language for databases -
 able to retrieve and manipulate data
 stored in Resource Description Framework (RDF) format.
 .
 Resource Description Framework (RDF) is a standard model
 for data interchange on the Web.

The package will be team-maintained at https://salsa.debian.org/debian/oxigraph


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFokSIACgkQLHwxRsGg
ASHPxw//UV21chmZcMciL7AggEiPK5AbKPzm78ENqaDqVEVIMdCZ+qt2YoDgCAUT
UOs+tJ5YvvFchNQ/PKseRFU+sMMoLxpAJ5BnAUgMCCzaYPJMngphUFnbvQyp5LFW
lo1B6DQKkXFbyOkB2LvQieoJpXqcsnwDSKidxNk0JDnbJeJb6lPvoq0ITqhQvQks
d7s0gDPA0M8t0brcvLy/5bvQElajIpAdXYiC5Q2mwlsAc+USXcbBmMZXU8x7V+f4
pxdoopRjjW6oDnXcGw/Ra2CEar95J8seyxlEV93ep0l5dkJGB4CvqeFsfLyufV64
ean05WMYH33PL0w1GKrnxUhI5b8YLuw/8Lv4K7nKjE/NO6pyG3exblvjBrajvXGc
sgWEjXuLDEDPuSD6tmOzayX8W8ow4XoxuFvtPx4qd4UOxn4/vuyu9WvFHxtNuYRs
QMIOT9rnMxASx64JeyVaogTcrtPcvDUqHaYggAmuczU1avmHeRMOzZLiLM/Gj4+Q
UvvY8++kU2MwbTuqtYeKqikAHq9+bQG1O9BrnaXFZzMViLkz63+McudmpEGZ0aEH
pw6iPs9s1EeABToqnSX6HJH4+ddDd1CnCCI35/kp3PpKY8U43yreyQzWkx+/03a1
X1YCjRG1+86vFDuOe1OnfeuoF2rodXqFAGxDsn2em3fZUTz5wgY=
=wCD/
-END PGP SIGNATURE-

Bug#996503: sddm fails to start

[mheyes]

Package: sddm
Version: 0.19.0-3
Severity: important
X-Debbugs-Cc: debian...@brinin.org

Dear Maintainer,

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

Noticed since upgrade of nvidia-driver v.470.74-1. SDDM crashes, cannot
login as usual. Messages in /var/log/message shows:

nvidia-uvm: Loaded the UVM driver, major device number 237.
sddm[996]: Error from greeter session: "Process crashed"
sddm[996]: Auth: sddm-helper crashed (exit code 15)
sddm[996]: Error from greeter session: "Process crashed"
sddm[996]: Auth: sddm-helper exited with 15

Stopping sddm and using startx to start X session works fine.

Purging nvidia-driver and using nouveau results in sddm starting as
usual.

Using gdm3 instead of sddm works properly.







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


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

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

Versions of packages sddm depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.77
ii  libc6 2.32-4
ii  libgcc-s1 11.2.0-9
ii  libpam0g  1.4.0-10
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5dbus5   5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5network55.15.2+dfsg-12
ii  libqt5qml55.15.2+dfsg-8
ii  libqt5quick5  5.15.2+dfsg-8
ii  libstdc++611.2.0-9
ii  libsystemd0   249.5-1
ii  libxcb-xkb1   1.14-3
ii  libxcb1   1.14-3
ii  qml-module-qtquick2   5.15.2+dfsg-8
ii  x11-common1:7.7+23
ii  xauth 1:1.1-1
ii  xserver-xephyr [xserver]  2:1.20.11-1
ii  xserver-xorg [xserver]1:7.7+23

Versions of packages sddm recommends:
ii  haveged1.9.14-1
ii  libpam-systemd 249.5-1
ii  sddm-theme-debian-elarun [sddm-theme]  0.19.0-3
ii  sddm-theme-debian-maui [sddm-theme]0.19.0-3
ii  sddm-theme-maya [sddm-theme]   0.19.0-3

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.21.5-2
pn  qtvirtualkeyboard-plugin  

-- debconf information excluded

Bug#996490: audacious-plugins: cannot install last binNMU 4.0.5-1+b1

[Sebastian Ramacher]

Control: severity -1 serious

On 2021-10-14 20:46:53, Patrice Duroux wrote:
> Package: audacious-plugins
> Version: 4.0.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Its dependency 'audacious-plugins-data' does not have an identical version 
> tag.
> I am not sure if this is related to:
> https://salsa.debian.org/multimedia-team/audacious-
> plugins/-/commit/7243b8f6e361af34a09cb169726b7178a6e3e8de

It is. Architecture dependent packages that need to depend on the exact
version of an architecture independent package need to use
${source:Version}.

Cheers

> 
> Thanks,
> Patrice
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-
> debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.14.0-2-amd64 (SMP w/12 CPU threads)
> Kernel taint flags: TAINT_CRAP
> 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 audacious-plugins depends on:
> ii  audacious-plugins-data4.0.5-1
> ii  libasound21.2.5.1-1
> ii  libaudcore5   4.0.5-2
> ii  libaudgui54.0.5-2
> ii  libaudqt2 4.0.5-2
> ii  libaudtag34.0.5-2
> ii  libavcodec58  7:4.4-6+b2
> ii  libavformat58 7:4.4-6+b2
> ii  libavutil56   7:4.4-6+b2
> ii  libbs2b0  3.1.0+dfsg-2.2+b1
> ii  libc6 2.32-4
> ii  libcairo2 1.16.0-5
> ii  libcddb2  1.3.2-7
> ii  libcdio-cdda2 10.2+2.0.0-1+b2
> ii  libcdio19 2.1.0-2
> ii  libcue2   2.2.1-3
> ii  libcurl3-gnutls   7.74.0-1.3+b1
> ii  libfaad2  2.10.0-1
> ii  libflac8  1.3.3-2
> ii  libfluidsynth22.1.7-1.1
> ii  libgcc-s1 11.2.0-9
> ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
> ii  libgl11.3.4-2+b1
> ii  libglib2.0-0  2.70.0-1+b1
> ii  libgtk2.0-0   2.24.33-2
> ii  libjack-jackd2-0 [libjack-0.125]  1.9.19~dfsg-2
> ii  liblirc-client0   0.10.1-6.3
> ii  libmms0   0.6.4-3
> ii  libmodplug1   1:0.8.9.0-3
> ii  libmp3lame0   3.100-3
> ii  libmpg123-0   1.29.0-1+b1
> ii  libneon27-gnutls  0.32.1-1
> ii  libnotify40.7.9-3
> ii  libogg0   1.3.4-0.1
> ii  libopenmpt0   0.4.22-1
> ii  libpango-1.0-01.48.10+ds1-1
> ii  libpangocairo-1.0-0   1.48.10+ds1-1
> ii  libpulse0 15.0+dfsg1-2
> ii  libqt5core5a  5.15.2+dfsg-12
> ii  libqt5gui55.15.2+dfsg-12
> ii  libqt5multimedia5 5.15.2-3
> ii  libqt5opengl5 5.15.2+dfsg-12
> ii  libqt5widgets55.15.2+dfsg-12
> ii  libsamplerate00.2.2-1
> ii  libsdl2-2.0-0 2.0.16+dfsg1-5
> ii  libsidplayfp5 2.0.5-2
> ii  libsndfile1   1.0.31-2
> ii  libsndio7.0   1.5.0-3
> ii  libsoxr0  0.1.3-4
> ii  libstdc++611.2.0-9
> ii  libvorbis0a   1.3.7-1
> ii  libvorbisenc2 1.3.7-1
> ii  libvorbisfile31.3.7-1
> ii  libwavpack1   5.4.0-1
> ii  libx11-6  2:1.7.2-2+b1
> ii  libxcomposite11:0.4.5-1
> ii  libxml2   2.9.12+dfsg-5
> ii  libxrender1   1:0.9.10-1
> ii  zlib1g1:1.2.11.dfsg-2
> 
> Versions of packages audacious-plugins recommends:
> ii  audacious  4.0.5-2
> 
> audacious-plugins suggests no packages.
> 

-- 
Sebastian Ramacher

Bug#996502: RM: networking-arista -- ROM; unmaintained upstream

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Hi,

This Neutron plugin is unmaintained upstream (and in Debian).
Please remove this package from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#982998: chkrootkit chkproc uses incorrect value for max_pid

[Vincent Duvert]

Package: chkrootkit
Version: 0.55-1+b1
Followup-For: Bug #982998
X-Debbugs-Cc: report...@duvert.net

Hello,

I also have the same problem. Looking at the extracted source package, I
noticed that the MAX_PROCESSES 9 define actually comes from the Debian
patch debian/patches/27_fix-race-condition-ps-proc.patch, which replaces the
conditional define:

-#define MAX_PROCESSES 99 
-#if defined (__x86_64) > 0 
-#undef MAX_PROCESSES
-#define MAX_PROCESSES 4194384
-#endif
+#define MAX_PROCESSES 9

I tried to revert this part of the patch and rebuild chkproc, and that seems
to fix the issue (tested on a system with an existing process of PID 1001133).

Not sure if the MAX_PROCESSES change in the patch was made deliberately or not,
however; with MAX_PROCESSES = 4194384, chkproc uses 64 MiB of memory to hold
its state (four int arrays of size MAX_PROCESSES + 1), compared to ~1.5 MiB
with MAX_PROCESSES = 9. It is also noticeably slower since it tries to
read /proc/ for every PID in the 1..4194384 range.

Regards,
Vincent Duvert


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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 chkrootkit depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-client 1:8.4p1-5
ii  procps 2:3.3.17-5

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information excluded

Bug#994911: error modifying deb822 object while iterating

[Jelmer Vernooij]

On Sun, Oct 10, 2021 at 08:41:55AM +0200, Niels Thykier wrote:
> On Thu, 23 Sep 2021 00:43:50 + Jelmer Vernooij 
> wrote:
> > Package: python3-debian
> > Version: 0.1.41
> > Severity: normal
> > 
> > Modifying a deb822 file while iterating over it results in a RuntimeError:
> > 
> > ...
> >   File 
> > "/home/jelmer/src/debian-janitor/python-debian/lib/debian/_deb822_repro/parsing.py",
> >  line 2208, in iter_keys
> > yield from self._kvpair_elements
> > RuntimeError: dictionary keys changed during iteration
> > 
> > (This doesn't happen with the default deb822 implementation)
> > 
> > [...]
> 
> 
> Hi,
> 
> Can you provide the code snippet that triggers this bug?
> 
> As I understand it, this is "normal" for a dict depending on the exact
> usage, which is why I would like to see what you were doing when you
> triggered the bug. :)
> 
> Example with dict:
> 
>  d = {'a': 1, 'b': 2}
>  for e in d:
> > ...   if d[e] == 2:
> > ... d['z'] = 1
> > ... 
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > RuntimeError: dictionary changed size during iteration
>  for e in d:
> > ... d[e] = 2
> > ... 
>  
Yep, this is standard behaviour with a dict - so I wouldn't be surprised if
this was happening generally, but the default deb822 doesn't exhibit
this so it makes migrating a bit harder.

Unfortunately I've lost track of the run in the janitor that
showed this issue so we'll just have to re-enable and see
if it's fixed now.

Jelmer

Bug#996501: systemd FTCBFS: unsatisfiable Build-Depends: python3-jinja2

[Helmut Grohne]

Source: systemd
Version: 249.5-1
Severity: important
Justification: breaks architecture bootstrap
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

systemd can no longer be cross built from source, because it gained a
build dependency on python3-jinja2, which cannot be satisfied. Since
jinja2 depends on a Python extension (python3-markupsafe), it cannot be
marked Multi-Arch: foreign. Instead, consumers must specify which jinja2
they need. In this case, it is fairly obvious that jinja2 is only used
during build, so you need the build architecture one. Thus, it should be
annotated :native. Please consider applying the attached patch.

Helmut
diff --minimal -Nru systemd-249.5/debian/changelog 
systemd-249.5/debian/changelog
--- systemd-249.5/debian/changelog  2021-10-12 22:39:59.0 +0200
+++ systemd-249.5/debian/changelog  2021-10-14 19:56:26.0 +0200
@@ -1,3 +1,10 @@
+systemd (249.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python3-jinja2 dependency with :native. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 14 Oct 2021 19:56:26 +0200
+
 systemd (249.5-1) unstable; urgency=medium
 
   * New upstream version 249.5
diff --minimal -Nru systemd-249.5/debian/control systemd-249.5/debian/control
--- systemd-249.5/debian/control2021-10-12 22:39:59.0 +0200
+++ systemd-249.5/debian/control2021-10-14 19:56:25.0 +0200
@@ -51,7 +51,7 @@
linux-base ,
acl ,
python3:native,
-   python3-jinja2,
+   python3-jinja2:native,
python3-lxml:native,
python3-pyparsing:native ,
python3-evdev:native ,

Bug#996500: wlroots FTBFS: error: ‘av_init_packet’ is deprecated [-Werror=deprecated-declarations]

[Helmut Grohne]

Source: wlroots
Version: 0.12.0-2
Severity: serious
Tags: ftbfs

wlroots fails to build from source in unstable on amd64. A non-parallel
build now ends as follows:

| FAILED: examples/dmabuf-capture.p/dmabuf-capture.c.o
| cc -Iexamples/dmabuf-capture.p -Iexamples -I../examples -Iprotocol 
-I/usr/include/x86_64-linux-gnu -I/usr/include/libdrm 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
-Werror -std=c11 -DWLR_USE_UNSTABLE -Wundef -Wlogical-op -Wmissing-include-dirs 
-Wold-style-definition -Wpointer-arith -Winit-self -Wstrict-prototypes 
-Wimplicit-fallthrough=2 -Wendif-labels -Wstrict-aliasing=2 -Woverflow 
-Wmissing-prototypes -Wno-missing-braces -Wno-missing-field-initializers 
-Wno-unused-parameter -fmacro-prefix-map=../= -DLIBINPUT_MAJOR=1 
-DLIBINPUT_MINOR=19 -DLIBINPUT_PATCH=1 '-DICONDIR="/usr/share/icons"' -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -MD -MQ 
examples/dmabuf-capture.p/dmabuf-capture.c.o -MF 
examples/dmabuf-capture.p/dmabuf-capture.c.o.d -o 
examples/dmabuf-capture.p/dmabuf-capture.c.o -c ../examples/dmabuf-capture.c
| ../examples/dmabuf-capture.c: In function ‘vid_encode_thread’:
| ../examples/dmabuf-capture.c:494:25: error: ‘av_init_packet’ is deprecated 
[-Werror=deprecated-declarations]
|   494 | av_init_packet(&pkt);
|   | ^~
| In file included from /usr/include/x86_64-linux-gnu/libavcodec/bsf.h:30,
|  from /usr/include/x86_64-linux-gnu/libavcodec/avcodec.h:44,
|  from 
/usr/include/x86_64-linux-gnu/libavformat/avformat.h:312,
|  from ../examples/dmabuf-capture.c:2:
| /usr/include/x86_64-linux-gnu/libavcodec/packet.h:488:6: note: declared here
|   488 | void av_init_packet(AVPacket *pkt);
|   |  ^~
| cc1: all warnings being treated as errors
| ninja: build stopped: subcommand failed.
| dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
returned exit code 1
| make: *** [debian/rules:7: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut

Bug#996498: ocp FTCBFS: multiple reasons

[Helmut Grohne]

Source: ocp
Version: 1:0.2.90-3.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ocp fails to cross build from source, because configure.ac hard codes
the build architecture pkg-config in a lot of occasions. A good solution
is using the PKG_CHECK_MODULES macro. I'm attaching a patch for doing
the conversion. You need to regenerate configure after applying it.

Also note that since you dropped gcc-11 from Build-Depends, you should
also stop exporting CC=gcc-11.

Helmut
--- ocp-0.2.90.orig/configure.ac
+++ ocp-0.2.90/configure.ac
@@ -343,13 +343,11 @@
 AC_SUBST(LIBJPEG_LIBS)
 AC_SUBST(LIBPNG_CFLAGS)
 AC_SUBST(LIBPNG_LIBS)
-if test "x$with_mad" != "xno"; then
+AS_IF([test "x$with_mad" != "xno"],[
 	AC_MSG_CHECKING([mad support])
-	MAD_LIBS=`pkg-config --libs mad 2> /dev/null`
-	MAD_CFLAGS=`pkg-config --cflags mad 2> /dev/null`
-	if test "$?" = 0; then
+	PKG_CHECK_MODULES([MAD],[mad],[
 		AC_MSG_RESULT("$MAD_CFLAGS $MAD_LIBS")
-	else
+	],[
 		AC_MSG_RESULT([pkg-config failed]);
 	dnl Fall back to non-pkg-config method
 		AC_CHECK_LIB(mad, mad_stream_init, , if test "x$with_mad" = "xyes"; then AC_MSG_ERROR("libmad not found"); else with_mad="no"; fi)
@@ -361,26 +359,22 @@
 			MAD_CFLAGS=""
 			LIBS=$push_LIBS
 		fi
-	fi
-fi
+	])
+])
 
 AC_MSG_CHECKING([libjpeg / libjpeg-turbo support])
-LIBJPEG_LIBS=`pkg-config --libs libjpeg 2> /dev/null`
-LIBJPEG_CFLAGS=`pkg-config --cflags libjpeg 2> /dev/null`
-if test "$?" = 0; then
+PKG_CHECK_MODULES([LIBJPEG],[libjpeg],[
 	AC_MSG_RESULT("$LIBJPEG_CFLAGS $LIBJPEG_LIBS")
-else
+],[
 	AC_MSG_ERROR([pkg-config failed]);
-fi
+])
 
 AC_MSG_CHECKING([libpng support])
-LIBPNG_LIBS=`pkg-config --libs libpng 2> /dev/null`
-LIBPNG_CFLAGS=`pkg-config --cflags libpng 2> /dev/null`
-if test "$?" = 0; then
+PKG_CHECK_MODULES([LIBPNG],[libpng],[
 	AC_MSG_RESULT("$LIBPNG_CFLAGS $LIBPNG_LIBS")
-else
+],[
 	AC_MSG_ERROR([pkg-config failed]);
-fi
+])
 
 AC_SUBST(HAVE_MAD)
 if test "x$with_mad" = "xno"; then
@@ -393,27 +387,23 @@
 AC_SUBST(OGG_CFLAGS)
 AC_SUBST(OGG_LIBS)
 AC_MSG_CHECKING([ogg support])
-OGG_LIBS=`pkg-config --libs ogg 2> /dev/null`
-OGG_CFLAGS=`pkg-config --cflags ogg 2> /dev/null`
-if test "$?" = 0; then
+PKG_CHECK_MODULES([OGG],[ogg],[
 	AC_MSG_RESULT("$OGG_CFLAGS $OGG_LIBS")
-else
+],[
 	AC_MSG_RESULT([pkg-config failed]);
 dnl Fall back to non-pkg-config method
 	AC_CHECK_LIB(ogg, ogg_sync_init, , AC_MSG_ERROR("ogg libraries not found"))
 	OGG_LIBS="-logg"
 	OGG_CFLAGS=""
 	LIBS=$push_LIBS
-fi
+])
 
 AC_SUBST(VORBIS_CFLAGS)
 AC_SUBST(VORBIS_LIBS)
 AC_MSG_CHECKING([vorbis support])
-VORBIS_LIBS=`pkg-config --libs vorbis 2> /dev/null`
-VORBIS_CFLAGS=`pkg-config --cflags vorbis 2> /dev/null`
-if test "$?" = 0; then
+PKG_CHECK_MODULES([VORBIS],[vorbis],[
 	AC_MSG_RESULT("$VORBIS_CFLAGS $VORBIS_LIBS")
-else
+],[
 	AC_MSG_RESULT([pkg-config failed]);
 dnl Fall back to non-pkg-config method
 	AC_CHECK_LIB(vorbis, vorbis_bitrate_init, , AC_MSG_ERROR("vorbis libraries not found"), -logg)
@@ -421,16 +411,14 @@
 	VORBIS_LIBS="-lvorbis"
 	VORBIS_CFLAGS=""
 	LIBS=$push_LIBS
-fi
+])
 
 AC_SUBST(VORBISFILE_CFLAGS)
 AC_SUBST(VORBISFILE_LIBS)
 AC_MSG_CHECKING([vorbisfile support])
-VORBISFILE_LIBS=`pkg-config --libs vorbisfile 2> /dev/null`
-VORBISFILE_CFLAGS=`pkg-config --cflags vorbisfile 2> /dev/null`
-if test "$?" = 0; then
+PKG_CHECK_MODULES([VORBISFILE],[vorbisfile],[
 	AC_MSG_RESULT("$VORBISFILE_CFLAGS $VORBISFILE_LIBS")
-else
+],[
 	AC_MSG_RESULT([pkg-config failed]);
 dnl Fall back to non-pkg-config method
 
@@ -441,7 +429,7 @@
 	VORBISFILE_LIBS="-lvorbisfile"
 	VORBISFILE_CFLAGS=""
 	LIBS=$push_LIBS
-fi
+](
 
 AC_SUBST(FLAC_CFLAGS)
 AC_SUBST(FLAC_LIBS)
@@ -537,13 +525,11 @@
 org_cppflags="$CPPFLAGS"
 AC_SUBST(SDL_CFLAGS)
 AC_SUBST(SDL_LIBS)
-if test "x$with_sdl" != "xno"; then
+AS_IF([test "x$with_sdl" != "xno"],[
 	AC_MSG_CHECKING([SDL support])
-	SDL_LIBS=`pkg-config --libs sdl 2> /dev/null`
-	SDL_CFLAGS=`pkg-config --cflags sdl 2> /dev/null`
-	if test "$?" = 0; then
+	PKG_CHECK_MODULES([SDL],[sdl],[
 		AC_MSG_RESULT("$SDL_CFLAGS $SDL_LIBS")
-	else
+	],[
 		AC_MSG_RESULT([pkg-config failed])
 
 		AC_CHECK_LIB(SDL, SDL_Init, SDL_LIBS="-lSDL", if test "x$with_sdl" = "xyes"; then AC_MSG_ERROR("libSDL was not found"); else with_sdl="no"; fi)
@@ -553,8 +539,8 @@
 			CPPFLAGS="$CPPFLAGS -I/usr/include/SDL"
 			AC_CHECK_HEADER(SDL.h, SDL_CFLAGS="-I/usr/include/SDL", if test "x$with_sdl" = "xyes"; then AC_MSG_ERROR("SDL header files not found"); else with_sdl="no"; fi)
 		fi
-	fi
-fi
+	])
+])
 AC_SUBST(HAVE_SDL)
 if test "x$with_sdl" = "xno"; then
 	HAVE_SDL=
@@ -567,18 +553,16 @@
 
 AC_SUBST(FREETYPE2_LIBS)
 AC_SUBST(FREETYPE2_CFLAGS)
-if test "x$HAVE_SDL" = "x1" || test "x$HAVE_SDL2" = "x1" || test "x$HAVE_X11" = "x1"; then
+AS_IF([test "x$HAVE_SDL" = "x1" || test "x$HAVE_SDL2" = "x1" || test "x$HAVE_X11" = "x1"],[
 	AC_MSG_CHECKING([freetype2 support])
-	FREETYPE2_LIBS=`pkg-config --libs freetype2 2> /dev/null`
-	FREETYPE2_CFLAGS=`pkg-config --cflags fr

Bug#996499: jdim FTCBFS: exports DEB_BUILD_OPTIONS

[Helmut Grohne]

Source: jdim
Version: 0.6.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

jdim fails to cross build from source, because it fails running tests
despite being passed DEB_BUILD_OPTIONS=nocheck. That variable is
ignored, because debian/rules sets it. Please drop that.

Helmut
diff --minimal -Nru jdim-0.6.0/debian/changelog jdim-0.6.0/debian/changelog
--- jdim-0.6.0/debian/changelog 2021-07-11 12:47:45.0 +0200
+++ jdim-0.6.0/debian/changelog 2021-10-14 20:08:08.0 +0200
@@ -1,3 +1,10 @@
+jdim (0.6.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't ignore DEB_BUILD_OPTIONS. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 14 Oct 2021 20:08:08 +0200
+
 jdim (0.6.0-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru jdim-0.6.0/debian/rules jdim-0.6.0/debian/rules
--- jdim-0.6.0/debian/rules 2021-07-11 12:47:45.0 +0200
+++ jdim-0.6.0/debian/rules 2021-10-14 20:08:06.0 +0200
@@ -3,7 +3,6 @@
 # export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS := hardening=+all
-export DEB_BUILD_OPTIONS=buildinfo=+path
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk

Bug#996497: u-boot FTCBFS: missing build dependency on libssl-dev

[Helmut Grohne]

Source: u-boot
Version: 2021.10+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

u-boot fails to cross build from source, because it misses a build
dependency on libssl-dev. Please add it.

Helmut
diff --minimal -Nru u-boot-2021.10+dfsg/debian/changelog 
u-boot-2021.10+dfsg/debian/changelog
--- u-boot-2021.10+dfsg/debian/changelog2021-10-10 06:20:52.0 
+0200
+++ u-boot-2021.10+dfsg/debian/changelog2021-10-14 20:14:58.0 
+0200
@@ -1,3 +1,10 @@
+u-boot (2021.10+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: libssl-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 14 Oct 2021 20:14:58 +0200
+
 u-boot (2021.10+dfsg-1) unstable; urgency=medium
 
   * Upload new upstream version to unstable.
diff --minimal -Nru u-boot-2021.10+dfsg/debian/control 
u-boot-2021.10+dfsg/debian/control
--- u-boot-2021.10+dfsg/debian/control  2021-10-10 05:19:41.0 +0200
+++ u-boot-2021.10+dfsg/debian/control  2021-10-14 20:14:58.0 +0200
@@ -17,6 +17,7 @@
  libc6:armel [armel] ,
  libc6:riscv64 [riscv64] ,
  libpython3-dev:native [linux-any],
+ libssl-dev,
  libssl-dev:native,
  opensbi (>= 0.9-2~) [riscv64],
  python3:any [linux-any],

Bug#996496: src:golang-gopkg-square-go-jose.v1: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: golang-gopkg-square-go-jose.v1
Version: 1.1.2-2
Severity: serious
Control: close -1 1.1.2-3
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:golang-gopkg-square-go-jose.v1 has been
trying to migrate for 61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=golang-gopkg-square-go-jose.v1




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996495: bash-completion: [regression from buster] tab no longer completes filenames in some cases

[Timo Lindfors]

Package: bash-completion
Version: 1:2.11-2
Severity: normal
X-Debbugs-Cc: timo.lindf...@iki.fi

I'm not quite sure what is the right package for this report, please
feel free to reassign/retitle when needed.

Steps to reproduce:
1) Install vanilla Debian 11 from netinst CD
2) Login and start gnome-terminal
3) Type "col -b < /etc/iss" and hit TAB

Expected results:
3) The filename /etc/issue is completed

Actual results:
3) Nothing visible happens. The filename is completed only if the user
   knows  that they need to type ESC-/.

I do not see the same issue with Debian buster.

My experience is that most people have not heard about ESC-/. For these 
people this is quite a major usability issue as they are forced to type 
really long filenames by hand. I hope we can improve the default 
configuration and make it more usable.


-Timo


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (500, 'oldstable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information
~

Bug#996040: Acknowledgement (qml-module-qtpositioning: Bogus Altitude, Direction and Speed values with geoclue2 backend)

[Teemu Ikonen]

Control: tags -1 patch

A simple fix, once it's seen.

As a bonus, fix the invalid altitude detection.

>From f83eb0b27b0e9458a371b725a8e360ef4230cc8a Mon Sep 17 00:00:00 2001
From: Teemu Ikonen 
Date: Thu, 14 Oct 2021 21:22:23 +0300
Subject: [PATCH 1/2] Fix assignment vs. comparison precedence error in
 geoclue2 plugin

Replace constructs of type

 if(const auto foo = location.foo() > bar)
 // foo is boolean

with

 const auto foo = location.foo();
 if(foo > bar)
// foo equals location.foo()
---
 .../geoclue2/qgeopositioninfosource_geoclue2.cpp| 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp b/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp
index 10484e3..d92230d 100644
--- a/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp
+++ b/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp
@@ -410,7 +410,9 @@ void QGeoPositionInfoSourceGeoclue2::handleNewLocation(const QDBusObjectPath &ol
 } else {
 QGeoCoordinate coordinate(location.latitude(),
   location.longitude());
-if (const auto altitude = location.altitude() > std::numeric_limits::min())
+
+const auto altitude = location.altitude();
+if (altitude > std::numeric_limits::min())
 coordinate.setAltitude(altitude);
 
 const Timestamp ts = location.timestamp();
@@ -426,11 +428,14 @@ void QGeoPositionInfoSourceGeoclue2::handleNewLocation(const QDBusObjectPath &ol
 const auto accuracy = location.accuracy();
 // We assume that an accuracy as 0.0 means that it comes from a sattelite.
 m_lastPositionFromSatellite = qFuzzyCompare(accuracy, 0.0);
-
 m_lastPosition.setAttribute(QGeoPositionInfo::HorizontalAccuracy, accuracy);
-if (const auto speed = location.speed() >= 0.0)
+
+const auto speed = location.speed();
+if (speed >= 0.0)
 m_lastPosition.setAttribute(QGeoPositionInfo::GroundSpeed, speed);
-if (const auto heading = location.heading() >= 0.0)
+
+const auto heading = location.heading();
+if (heading >= 0.0)
 m_lastPosition.setAttribute(QGeoPositionInfo::Direction, heading);
 
 emit positionUpdated(m_lastPosition);
-- 
2.30.2

>From 3d5e2c302be87ba84681c45cd206b050ea71761f Mon Sep 17 00:00:00 2001
From: Teemu Ikonen 
Date: Thu, 14 Oct 2021 21:56:29 +0300
Subject: [PATCH 2/2] Fix detection of invalid altitude values in geoclue2
 plugin

Replace std::numeric_limits::min() with ::lowest().
---
 .../position/geoclue2/qgeopositioninfosource_geoclue2.cpp   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp b/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp
index d92230d..e3be986 100644
--- a/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp
+++ b/src/plugins/position/geoclue2/qgeopositioninfosource_geoclue2.cpp
@@ -412,7 +412,7 @@ void QGeoPositionInfoSourceGeoclue2::handleNewLocation(const QDBusObjectPath &ol
   location.longitude());
 
 const auto altitude = location.altitude();
-if (altitude > std::numeric_limits::min())
+if (altitude > std::numeric_limits::lowest())
 coordinate.setAltitude(altitude);
 
 const Timestamp ts = location.timestamp();
-- 
2.30.2

Bug#996494: unbound in bullseye fails to start under systemd - issue already fixed in unbound upstream

[Grant Chesy]

Package: unbound
Version: 1.13.1-1

After upgrading to bullseye from buster (unbound v1.9.0-2+deb10u2), 
unbound fails to start via systemd, but starts and runs fine when daemon 
is started directly.


There is an upstream fix (to unbound, not systemd) for this issue:

https://github.com/NLnetLabs/unbound/pull/351

The original bug report from arch package maintainer:

https://github.com/NLnetLabs/unbound/issues/350


Can we get this fix applied to unbound in bullseye?


Under systemd, the error is:

Oct 14 10:56:35 systemd[1]: Starting Unbound DNS server...

Oct 14 10:56:36 unbound[93822]: [1634234196] unbound[93822:0] error: 
failed to list interfaces: getifaddrs: Address family not supported by 
protocol


Oct 14 10:56:36 unbound[93822]: [1634234196] unbound[93822:0] fatal 
error: could not open ports


Oct 14 10:56:36 systemd[1]: unbound.service: Main process exited, 
code=exited, status=1/FAILURE

Bug#996177: cryptsetup: please report fatal errors without having to use -v

[Guilhem Moulin]

On Thu, 14 Oct 2021 at 20:48:51 +0200, Marc Lehmann wrote:
> I reported this from another system, but both were recently upgraded to
> bullseye.
> 
> I know because I use kvm to see if the machine will actually boot (Cthus
> the different memory setup) and the kvm in bullseye has a bug that makes
> this very hard (remote display makes it freeze randomly), and I had to
> work around this bug, so I know it was not buster.

Could still be an older initramfs image though.  If you're able to
reproduce this please run `cryptsetup --version` directly afterwards
(i.e., at initramfs stage if that's where the issue appears).
 
>> Looking at the upstream git log, I found 
>> 206b70c837f29c8b34cb0d80ae496870550ec50c
>> which fixes https://gitlab.com/cryptsetup/cryptsetup/-/issues/488 which looks
>> really familiar :-)
> 
> It looks very similar. It is not the message I got with -v, which
> specifically had the error number (3) in it somewhere, but maybe thats
> because it ran out of memory in a different place.

My reproducer (with cryptsetup 2.1.0) does have “Command failed with
code -3 (out of memory)” with ‘-v’:

(initramfs) free
  totalusedfree  shared  buff/cache   
available
Mem: 493060   29808  363896  40   99356  
364040
Swap: 0   0   0
(initramfs) cryptsetup luksDump /dev/vda5
[…]
Keyslots:
  0: luks2
Key:512 bits
Priority:   normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF:  argon2i
Time cost:  4
Memory: 605915
Threads:2
[…]
(initramfs) cryptsetup luksOpen /dev/vda5 --keyfile-size=32 
--key-file=/dev/urandom --test-passphrase
(initramfs) echo $?
3

(initramfs) cryptsetup luksOpen -v /dev/vda5 --keyfile-size=32 
--key-file=/dev/urandom --test-passphrase
Command failed with code -3 (out of memory).

(initramfs) cryptsetup luksOpen --debug /dev/vda5 --keyfile-size=32 
--key-file=/dev/urandom --test-passphrase
# cryptsetup 2.1.0 processing "cryptsetup luksOpen --debug /dev/vda5 
--keyfile-size=32 --key-file=/dev/urandom --test-passphrase"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/vda5.
# Trying to open and read device /dev/vda5 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/vda5.
# Crypto backend (OpenSSL 1.1.1d  10 Sep 2019) initialized in cryptsetup 
library version 2.1.0.
# Detected kernel Linux 4.19.0-18-amd64 x86_64.
# Loading LUKS2 header (repair disabled).
# Opening lock resource file /run/cryptsetup/L_254:5
# Acquiring read lock for device /dev/vda5.
# Verifying read lock handle for device /dev/vda5.
# Device /dev/vda5 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:e3d5da875cd56c8d48144ec6ef85229a8bdf52ad42a6c8b98a3b72ad32ece6de 
(on-disk)
# Checksum:e3d5da875cd56c8d48144ec6ef85229a8bdf52ad42a6c8b98a3b72ad32ece6de 
(in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Opening locked device /dev/vda5
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:af4ba03f7cdd87c763d505ae21b76c475fb072428949c8a87e94e15bbe54339b 
(on-disk)
# Checksum:af4ba03f7cdd87c763d505ae21b76c475fb072428949c8a87e94e15bbe54339b 
(in-memory)
# Device size 3781165056, offset 16777216.
# Device /dev/vda5 READ lock released.
# Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
# Not enough physical memory detected, PBKDF max memory decreased from 
1048576kB to 246530kB.
# PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb 
246530, parallel_threads 2.
# Checking volume passphrase using token -1.
# File descriptor passphrase entry requested.
# Checking volume passphrase [keyslot -1] using passphrase.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Keyslot 0 (luks2) open failed with -12.
# Releasing crypt device /dev/vda5 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code -3 (out of memory).

However, after upgrading (and rebuilding the initramfs) I get “Not
enough available memory to open a keyslot.” instead of having to pass
‘-v’, ‘--debug’ or inspect the return code.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996493: src:golang-github-getlantern-hidden: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: golang-github-getlantern-hidden
Version: 0.0~git20190325.f02dbb0-2
Severity: serious
Control: close -1 0.0~git20190325.f02dbb0-3
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:golang-github-getlantern-hidden has been
trying to migrate for 61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2]
https://qa.debian.org/excuses.php?package=golang-github-getlantern-hidden




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996492: O: mpack -- tools for encoding/decoding MIME messages

[Fabio Augusto De Muzio Tobich]

Package: wnpp
Severity: normal
X-Debbugs-Cc: ftob...@debian.org
Control: affects -1 src:mpack

I intend to orphan the mpack package.

The package description is:
 Mpack and munpack are utilities for encoding and decoding
 (respectively) binary files in MIME (Multipurpose Internet
 Mail Extensions) format mail messages. For compatibility
 with older forms of transferring binary files, the munpack
 program can also decode messages in split-uuencoded format.

mpack has a non-existing upstream and it's unmaintained.

I don't have the time and interest to keep working on this
package anymore.

The package is in good shape.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Bug#996491: src:gnome-authenticator: fails to migrate to testing for too long: uploader built arch:all

[Paul Gevers]

Source: gnome-authenticator
Version: 3.32.2+dfsg1-2
Severity: serious
Control: close -1 3.32.2+dfsg1-3
X-Debbugs-CC: jel...@debian.org
Tags: sid bookworm pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:gnome-authenticator has been trying to
migrate for 61 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bookworm, so
it doesn't affect (old-)stable.

Your package is only blocked because the arch:all binary package(s)
aren't built on a buildd. Unfortunately the Debian infrastructure
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
shortly do a no-changes source-only upload to DELAYED/15, closing this
bug. Please let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=gnome-authenticator




OpenPGP_signature
Description: OpenPGP digital signature

Bug#996265: autopkgtest: The dependency of each test is added to the dependencies of the following tests

[Paul Gevers]

Control: tags -1 moreinfo

Hi Fab,

On 12-10-2021 20:04, Fab Stz wrote:
> I noticed that the dependency of each test is added to the dependencies of the
> following tests
> 
> For example: debian/tests/control contains:
> 
> Test-Command: /usr/lib/android-sdk/build-tools/19.1.0/aapt v
> Depends: google-android-build-tools-19.1.0-installer
> 
> Test-Command: /usr/lib/android-sdk/build-tools/20.0.0/aapt v
> Depends: google-android-build-tools-20.0.0-installer
> 
> Test-Command: /usr/lib/android-sdk/build-tools/21.1.2/aapt v
> Depends: google-android-build-tools-21.1.2-installer
> 
> The observer behaviour is:
> 
> - for the test #1, it installs:  google-android-build-tools-19.1.0-installer
> - for the test #2, it installs:  google-android-build-tools-19.1.0-installer &
> google-android-build-tools-20.0.0-installer
> - for the test #3, it installs:  google-android-build-tools-19.1.0-installer &
> google-android-build-tools-20.0.0-installer & google-android-build-
> tools-21.1.2-installer

Can you please specify which backend you're using? This is *not* what
I'm seeing in the runs on ci.d.n which uses lxc. As an example, one of
my packages has Depends mariadb-server in the first test, it doesn't get
installed in the second test [1]. Can you also share the sources (at
least debian/control) of the package that builds
google-android-build-tools-*-installer)? Are you sure -21.1.2-installer
has no Dependency itself on the lower version?

> And so on...
> 
> The packages named here are packages build by the source package that is being
> tested
> 
> Is this expected? I expected to have only the declared Dependency to be
> installed, but it seems they are cumulative.

That's indeed not expected behavior.

Paul

[1]
https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cacti/15817105/log.gz



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996177: cryptsetup: please report fatal errors without having to use -v

[Marc Lehmann]

On Tue, Oct 12, 2021 at 02:25:31AM +0200, Guilhem Moulin  
wrote:
> > Also did you run luksFormat on that same machine (and didn't remove
> > memory sticks afterwards)?
> 
> I was actually able to reproduce this with buster's 2.1.0, but doing the
> same thing after upgrading to bullseye or sid yields

> which sounds alright.  Did you run reportbug(1) from the affected system
> or from an older one?

I reported this from another system, but both were recently upgraded to
bullseye.

I know because I use kvm to see if the machine will actually boot (Cthus
the different memory setup) and the kvm in bullseye has a bug that makes
this very hard (remote display makes it freeze randomly), and I had to
work around this bug, so I know it was not buster.

> Looking at the upstream git log, I found 
> 206b70c837f29c8b34cb0d80ae496870550ec50c
> which fixes https://gitlab.com/cryptsetup/cryptsetup/-/issues/488 which looks
> really familiar :-)

It looks very similar. It is not the message I got with -v, which
specifically had the error number (3) in it somewhere, but maybe thats
because it ran out of memory in a different place.

I tried to recreate the conditions again (which was basically runnign kvm
without -m option), but I can't get the kernel to boot with the default
memory, and the minimum amount I got it to boot with was 256MB, at which
cryptsetup was able to open the volume.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#996490: audacious-plugins: cannot install last binNMU 4.0.5-1+b1

[Patrice Duroux]

Package: audacious-plugins
Version: 4.0.5-1
Severity: normal

Dear Maintainer,

Its dependency 'audacious-plugins-data' does not have an identical version tag.
I am not sure if this is related to:
https://salsa.debian.org/multimedia-team/audacious-
plugins/-/commit/7243b8f6e361af34a09cb169726b7178a6e3e8de

Thanks,
Patrice

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_CRAP
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 audacious-plugins depends on:
ii  audacious-plugins-data4.0.5-1
ii  libasound21.2.5.1-1
ii  libaudcore5   4.0.5-2
ii  libaudgui54.0.5-2
ii  libaudqt2 4.0.5-2
ii  libaudtag34.0.5-2
ii  libavcodec58  7:4.4-6+b2
ii  libavformat58 7:4.4-6+b2
ii  libavutil56   7:4.4-6+b2
ii  libbs2b0  3.1.0+dfsg-2.2+b1
ii  libc6 2.32-4
ii  libcairo2 1.16.0-5
ii  libcddb2  1.3.2-7
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-2
ii  libcue2   2.2.1-3
ii  libcurl3-gnutls   7.74.0-1.3+b1
ii  libfaad2  2.10.0-1
ii  libflac8  1.3.3-2
ii  libfluidsynth22.1.7-1.1
ii  libgcc-s1 11.2.0-9
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libgl11.3.4-2+b1
ii  libglib2.0-0  2.70.0-1+b1
ii  libgtk2.0-0   2.24.33-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.19~dfsg-2
ii  liblirc-client0   0.10.1-6.3
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-3
ii  libmp3lame0   3.100-3
ii  libmpg123-0   1.29.0-1+b1
ii  libneon27-gnutls  0.32.1-1
ii  libnotify40.7.9-3
ii  libogg0   1.3.4-0.1
ii  libopenmpt0   0.4.22-1
ii  libpango-1.0-01.48.10+ds1-1
ii  libpangocairo-1.0-0   1.48.10+ds1-1
ii  libpulse0 15.0+dfsg1-2
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5multimedia5 5.15.2-3
ii  libqt5opengl5 5.15.2+dfsg-12
ii  libqt5widgets55.15.2+dfsg-12
ii  libsamplerate00.2.2-1
ii  libsdl2-2.0-0 2.0.16+dfsg1-5
ii  libsidplayfp5 2.0.5-2
ii  libsndfile1   1.0.31-2
ii  libsndio7.0   1.5.0-3
ii  libsoxr0  0.1.3-4
ii  libstdc++611.2.0-9
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libwavpack1   5.4.0-1
ii  libx11-6  2:1.7.2-2+b1
ii  libxcomposite11:0.4.5-1
ii  libxml2   2.9.12+dfsg-5
ii  libxrender1   1:0.9.10-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages audacious-plugins recommends:
ii  audacious  4.0.5-2

audacious-plugins suggests no packages.

Bug#996443: src:units-filter: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Hi Georges,

On 14-10-2021 17:43, Georges Khaznadar wrote:
> If I upload another package, without the new features (and the new
> binary artifact), is there a chance that it will be taken in
> consideration by the build system ? I fear that it would compete with
> the other package in the NEW queue.

Yes, but if you want to keep the stuff that's in NEW in NEW, I suggest
you pick a version between what's now in unstable and what you have in
NEW. E.g. 4.0.1-2 (if based on 4.0.1) or 4.2-1~no-units-master.1 (if you
can ship 4.2 without the new binary).

> Another option would be to manage the NEW package, either drop it or
> accept it, in order to fix the bug immediately, or open the way for a
> simple bugfix upload.

The NEW queue is not something I control. You could ping ftp-master.
Typically pinging them on IRC (#debian-ftp) helps somewhat to speed up
review if needed to fix issues in the archive.

> Thank you in advance for any suggestion.

That said, personally I'd go for *both* options if the first one is not
too much work as time wise the second is rather uncertain.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996177: cryptsetup: please report fatal errors without having to use -v

[Guilhem Moulin]

On Thu, 14 Oct 2021 at 19:53:14 +0200, Marc Lehmann wrote:
> On Tue, Oct 12, 2021 at 12:33:32AM +0200, Guilhem Moulin  
> wrote:
>> Could you please share the memory cost of the PBKDF,
> 
> I wouldn't know how to do that.

`cryptsetup luksDump`
 
>> of `free` just before running cryptsetup?  That would help us trying to
>> reproduce this and forward the issue upstream.  I tried to reproduce
>> this but only managed to trigger the OOM killer.
> 
> Not sure what this extra information has to do with the problem I reported

Which is why I'm saying, I tried to reproduce this and failed.

>> Also did you run luksFormat on that same machine (and didn't remove
>> memory sticks afterwards)?
> 
> There was _significantly_ less memory in the machine at the time of the
> problem.

Unrelated to this issue, it's best to run `cryptsetup luksChangeKey`
after hardware changes to use adequate PBKDF parameters.

> I think you are likely confused about the nature of the problem I reported
> - the problem is not that cryptsetup used too much memory. The problem
> is that it only reported it when using an extra option, as opposed to
> reporting it when it hit the issue.
>
> cryptsetup was not killed by the oom killer, so it should have had no
> problems reporting the result of some failed allocation.

Got that.  And again I believe this is 
https://gitlab.com/cryptsetup/cryptsetup/-/issues/488 .
Are you really running 2:2.3.5-1 on the affected system?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#996488: ITP: transforms3d -- Python code to convert between various geometric transformations

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: transforms3d
  Version : 0.3.1
  Upstream Author : Matthew Brett and Christoph Gohlke
* URL : https://github.com/matthew-brett/transforms3d.git
* License : BSD-2, BSD-3
  Programming Lang: Python
  Description : Code to convert between various geometric transformations


The plan would be to maintain the package inside the debian-python team
if possible.

Bug#995202: horst FTBFS: error: format not a string literal and no format arguments

[Sven Joachim]

Control: tags -1 + patch

Am 27.09.2021 um 22:25 schrieb Helmut Grohne:

> Source: horst
> Version: 5.1-2
> Severity: serious
> Tags: ftbfs
>
> horst fails to build from source in unstable on amd64 due to ncurses
> having become stricter about format strings. A build now ends as
> follows:
>
> | cc -g -O2
> | -ffile-prefix-map=/<>=. -fstack-protector-strong
> | -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g
> | -I. -DVERSION=\"5.1\" -DDO_DEBUG -I/usr/include/libnl3 -Wdate-time
> | -D_FORTIFY_SOURCE=2 -c -o display-main.o display-main.c
> | display-main.c: In function ‘print_dump_win’:
> | display-main.c:56:2: error: format not a string literal and no format 
> arguments [-Werror=format-security]
> |56 |  wprintw(dump_win, str);
> |   |  ^~~
> | display-main.c: In function ‘print_node_list_line’:
> | display-main.c:255:40: warning: format ‘%d’ expects argument of type
> | ‘int’, but argument 5 has type ‘long unsigned int’ [-Wformat=]
> |   255 |  mvwprintw(list_win, line, COL_SIG, "%3d", 
> -ewma_read(&n->phy_sig_avg));
> |   |  ~~^   
> ~~~
> |   ||   |
> |   |int long unsigned int
> |   |  %3ld
> | display-main.c: In function ‘update_dump_win’:
> | display-main.c:455:21: warning: too many arguments for format 
> [-Wformat-extra-args]
> |   455 |   wprintw(dump_win, "%-7s", "ARP", ip_sprintf(p->ip_src));
> |   | ^~
> | display-main.c:481:31: warning: format ‘%llx’ expects argument of
> | type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’
> | {aka ‘long unsigned int’} [-Wformat=]
> |   481 |wprintw(dump_win, "'%s' %llx", p->wlan_essid,
> |   |~~~^
> |   |   |
> |   |   long long unsigned int
> |   |%lx
> |   482 | p->wlan_tsf);
> |   | ~~~
> |   |  |
> |   |  uint64_t {aka long unsigned int}
> | display-main.c: In function ‘sort_input’:
> | display-main.c:129:11: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
> |   129 |   do_sort = c;
> |   |   ^~~
> | display-main.c:131:2: note: here
> |   131 |  case '\r': case KEY_ENTER:
> |   |  ^~~~
> | cc1: some warnings being treated as errors
> | make[1]: *** [: display-main.o] Error 1
> | make[1]: Leaving directory '/<>'
> | dh_auto_build: error: make -j1 returned exit code 2
> | make: *** [debian/rules:19: build] Error 25
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2

I have attached a patch for the two errors, adding "%s" as penultimate
argument to the *printw calls.  Did not really look at the warnings.

From 8110d832bd6502b7caed75b6504bd6d24d30d36b Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Thu, 14 Oct 2021 20:06:26 +0200
Subject: [PATCH] Fix string format errors with recent ncurses

---
 display-main.c | 2 +-
 display.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/display-main.c b/display-main.c
index b613291..6519895 100644
--- a/display-main.c
+++ b/display-main.c
@@ -53,7 +53,7 @@ static struct ewma bpsn_avg;
 void print_dump_win(const char *str, int refresh)
 {
 	wattron(dump_win, RED);
-	wprintw(dump_win, str);
+	wprintw(dump_win, "%s", str);
 	wattroff(dump_win, RED);
 	if (refresh)
 		wrefresh(dump_win);
diff --git a/display.c b/display.c
index 777c7a2..e0755f4 100644
--- a/display.c
+++ b/display.c
@@ -86,7 +86,7 @@ print_centered(WINDOW* win, int line, int cols, const char *fmt, ...)
 	vsnprintf(buf, cols, fmt, ap);
 	va_end(ap);

-	mvwprintw(win, line, cols / 2 - strlen(buf) / 2, buf);
+	mvwprintw(win, line, cols / 2 - strlen(buf) / 2, "%s", buf);
 	free(buf);
 }

--
2.33.0

Bug#996177: cryptsetup: please report fatal errors without having to use -v

[Marc Lehmann]

On Tue, Oct 12, 2021 at 12:33:32AM +0200, Guilhem Moulin  
wrote:
> Could you please share the memory cost of the PBKDF,

I wouldn't know how to do that.

> of `free` just before running cryptsetup?  That would help us trying to
> reproduce this and forward the issue upstream.  I tried to reproduce
> this but only managed to trigger the OOM killer.

Not sure what this extra information has to do with the problem I reported
- the problem is that the oom error is not reported unless -v is used,
which has nothing to do with the oom killer or how much memory was needed
- cryptsetup surely had reasons to use a lot of memory, but it should
report an error if it can, as opposed to silently fail to do its job.

> Also did you run luksFormat on that same machine (and didn't remove
> memory sticks afterwards)?

There was _significantly_ less memory in the machine at the time of the
problem.

I think you are likely confused about the nature of the problem I reported
- the problem is not that cryptsetup used too much memory. The problem
is that it only reported it when using an extra option, as opposed to
reporting it when it hit the issue.

cryptsetup was not killed by the oom killer, so it should have had no
problems reporting the result of some failed allocation.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#994423: pytorch-vision: FTBFS on armhf: Illegal instruction

[Adrian Bunk]

Control: reassign -1 src:pytorch 1.7.1-7
Control: retitle -1 pytorch: Baseline violation on armhf
Control: affects -1 python3-torch src:pytorch-vision

On Wed, Sep 15, 2021 at 10:00:09PM +0200, Sebastian Ramacher wrote:
> Source: pytorch-vision
> Version: 0.8.2-1
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> | I: pybuild base:232: python3.9 setup.py clean 
> | Illegal instruction
> | E: pybuild pybuild:353: clean: plugin distutils failed with: exit code=132: 
> python3.9 setup.py clean 
> | dh_auto_clean: error: pybuild --clean -i python{version} -p 3.9 returned 
> exit code 13
> | make: *** [debian/rules:6: clean] Error 25
> 
> https://buildd.debian.org/status/fetch.php?pkg=pytorch-vision&arch=armhf&ver=0.8.2-1%2Bb1&stamp=1631302732&raw=0

The root cause is a baseline violation of pytorch on armhf
(NEON is not part of the armhf baseline):

(sid_armhf-dchroot)bunk@abel:~$ python3 
Python 3.9.7 (default, Sep 24 2021, 09:43:00) 
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Illegal instruction
(sid_armhf-dchroot)bunk@abel:~$ 

(bullseye_armhf-dchroot)bunk@abel:~$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Illegal instruction
(bullseye_armhf-dchroot)bunk@abel:~$ 

> Cheers

cu
Adrian

Bug#996487: nbd-client: connects to localhost instead of the requested server

[Adam Borowski]

Package: nbd-client
Version: 1:3.22-1
Severity: important

Hi!
Since a few days ago (ie, since 1:3.22-1 upload), nbd-client stopped working
for me.  stracing it shows:

[pid  4166] socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
[pid  4166] connect(3, {sa_family=AF_INET6, sin6_port=htons(10809), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), 
sin6_scope_id=0}, 28) = 0
[pid  4166] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(53150), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), 
sin6_scope_id=0}, [28]) = 0
[pid  4166] connect(3, {sa_family=AF_UNSPEC, 
sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid  4166] connect(3, {sa_family=AF_INET, sin_port=htons(10809), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid  4166] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(50006), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, ":::127.0.0.1", &sin6_addr), 
sin6_scope_id=0}, [28]) = 0
[pid  4166] close(3)= 0
[pid  4166] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 3
[pid  4166] connect(3, {sa_family=AF_INET6, sin6_port=htons(10809), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), 
sin6_scope_id=0}, 28) = -1 ECONNREFUSED (Connection refused)
[pid  4166] close(3)= 0
[pid  4166] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid  4166] connect(3, {sa_family=AF_INET, sin_port=htons(10809), 
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)

ie, it tries to connect to the localhost via various means, instead of the
server specified in /etc/nbdtab (2001:470:64f4::90).

And indeed, if I set up a tunnel from localhost:10809 to the server, the
connection succeeds.

Downgrading to 1:3.21-1 fixes the issue.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.14.0-2-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages nbd-client depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.32-4
ii  libgnutls303.7.2-2
ii  libnl-3-2003.4.0-1+b1
ii  libnl-genl-3-200   3.4.0-1+b1

nbd-client recommends no packages.

nbd-client suggests no packages.

-- Configuration Files:
/etc/nbdtab changed:
nbd0 2001:470:64f4::90 cacodemon persist,timeout=3600
nbd1 2001:470:64f4::90 mancubus swap,persist,timeout=3600


-- debconf information:
  nbd-client/no-auto-config:
  nbd-client/killall_set:

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

[Sven Joachim]

Control: tags -1 + patch

Am 03.10.2021 um 12:00 schrieb Helmut Grohne:

> Source: pktstat
> Version: 1.8.5-7
> Severity: serious
> Tags: ftbfs
>
> pktstat fails to build from source in unstable on amd64. A non-parallel
> build ends as follows:
>
> | gcc -DHAVE_CONFIG_H -I.  -DPATH_PKTSTATRC=\"/etc/pktstatrc\" -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic 
> -D_BSD_SOURCE -c -o display.o display.c
> | In file included from 
> /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33,
> |  from /usr/include/stdio.h:27,
> |  from display.c:17:
> | /usr/include/features.h:187:3: warning: #warning "_BSD_SOURCE and 
> _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
> |   187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use 
> _DEFAULT_SOURCE"
> |   |   ^~~
> | display.c: In function ‘display_update’:
> | display.c:499:33: warning: field width specifier ‘*’ expects
> | argument of type ‘int’, but argument 2 has type ‘long unsigned int’
> | [-Wformat=]
> |   499 |  attron(A_UNDERLINE); printw("%-*s",
> |   |   ~~^~
> |   | |
> |   | int
> | display.c:552:13: warning: field precision specifier ‘.*’ expects
> | argument of type ‘int’, but argument 2 has type ‘long unsigned int’
> | [-Wformat=]
> |   552 |   printw("%.*s\n", MIN(maxx - LLEN, sizeof flows[i].tag - 1),
> |   |   ~~^~
> |   | |
> |   | int
> | display.c:566:15: warning: field precision specifier ‘.*’ expects
> | argument of type ‘int’, but argument 2 has type ‘long unsigned int’
> | [-Wformat=]
> |   566 |printw(" %.*s\n", MIN(maxx - LLEN - 2,
> |   | ~~^~
> |   |   |
> |   |   int
> | display.c:285:21: warning: variable ‘x’ set but not used 
> [-Wunused-but-set-variable]
> |   285 |  int maxx, maxy, y, x;
> |   | ^
> | display.c: In function ‘printhelp’:
> | display.c:672:3: error: format not a string literal and no format arguments 
> [-Werror=format-security]
> |   672 |   printw((char *)h->name + 1);
> |   |   ^~
> | cc1: some warnings being treated as errors
> | make[2]: *** [Makefile:483: display.o] Error 1
> | make[2]: Leaving directory '/<>'
> | make[1]: *** [Makefile:339: all] Error 2
> | make[1]: Leaving directory '/<>'
> | dh_auto_build: error: make -j1 returned exit code 2
> | make: *** [debian/rules:11: build] Error 25
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2
>
> This is likely due to ncurses including format string annotations.

Indeed.  The fix for the error is quite simple, add "%s" as first
argument in the printw call.  Patch for that attached, although the
warnings might also be worth a look.

From f3368493fe0365f7f37064fb0ae5fd1fba50fc36 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Thu, 14 Oct 2021 19:40:32 +0200
Subject: [PATCH] Fix format string error with recent ncurses

---
 display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/display.c b/display.c
index 2ff4c11..16b1b68 100644
--- a/display.c
+++ b/display.c
@@ -669,7 +669,7 @@ printhelp()
 			attron(A_REVERSE);
 		printw("%c", h->name[0]);
 		attroff(A_UNDERLINE);
-		printw((char *)h->name + 1);
+		printw("%s", (char *)h->name + 1);
 		attrset(0);
 		printw(" ");
 	}
--
2.33.0

Bug#993201: fixed in upstream pull request

[Christian Lauinger]

I fixed it and created a pull request upstream:
https://gitlab.com/bertoldia/gnome-shell-trash-extension/-/merge_requests/23

Bug#992116: release-notes: Add breakage from merged-/usr-via-aliased-dirs

[Justin B Rye]

Paul Gevers wrote:
> On 23-09-2021 21:25, Paul Gevers wrote:
>> "The Debian project is still deciding how to do this and how to migrate
>> existing systems as the proper solution isn't known yet." Yes, highly
>> frustrating, but it is reality.
>> 
>> For reference:
>> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md
> 
> What do you think?

I thank my lucky stars I'm not on that committee.  Focussing on the
phrasing...

   The Debian project is still deciding on the best way of achieving this
   and in particular the best way of migrating systems.

Somehow this seems bland and longwinded despite being shorter than the
previous version.  Or to be more alarmist about it:

   Finding an approach to this transition that avoids the various subtle
   pitfalls involved is still a work in progress.

My next step would be to find a compromise version, but so far I'm not
making much progress on that either.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#996472: nspark: Description doesn't say what it does

[Justin B Rye]

Simon McVittie wrote:
> Package: nspark
> Version: 1.7.8B2+git20210317.cb30779-1
> Severity: normal
> X-Debbugs-Cc: debian-l10n-engl...@lists.debian.org

Well, it reached me, but the BTS etc. don't seem to be sure whether
the package exists...

# A rewritten version of RISC OS !Spark for UNIX
#
# nspark is a rewritten version of !Spark for UNIX. The original
# version of !Spark (sometimes known as "cark") was based upon the
# BASIC program "bark", written by David Pilling.

This seems to be saying that Bark was written by Pilling but Spark
wasn't.  Other sources tell me they both were (and show no sign of
anyone referring to Spark as cark), but it's unclear why users would
want these details anyway.  Put it in /usr/share/doc/nspark/
somewhere!

> This package's Description says it's a rewrite of RISC OS !Spark, but
> doesn't give any clue as to what that means for people who don't already
> know what RISC OS !Spark did.
>
> According to its Github page, it seems to be an unarchiver (analogous
> to unzip) for a specific archive format mainly used on RISC OS? If so,
> saying so in the Description would be helpful.
> 
> The lhasa, unzip, unrar and unrar-free packages' descriptions might provide
> useful inspiration for what a clearer Description might look like.

Oh, is this another one for my collection of packages where the prefix
"n-" stands for "new thirty years ago"?

My suggestion:

# de-archiver for !Spark archives
#
# nspark ("new spark") supports extracting files from Spark 1 and 2 or
# ArcFS archives. It is a cross-platform rewrite of David Pilling's
# original !Spark for RISC OS.

(assuming I'm interpreting the manual correctly).
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

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

[Ondrej Zary]

e46f76c9749d7758765ba274a212cfc2dcf3eeb8 is the first bad commit
commit e46f76c9749d7758765ba274a212cfc2dcf3eeb8
Author: Marko Mäkelä 
Date:   Mon Jun 21 12:34:07 2021 +0300

MDEV-15912: Remove traces of insert_undo

Let us simply refuse an upgrade from earlier versions if the
upgrade procedure was not followed. This simplifies the purge,
commit, and rollback of transactions.

Before upgrading to MariaDB 10.3 or later, a clean shutdown
of the server (with innodb_fast_shutdown=1 or 0) is necessary,
to ensure that any incomplete transactions are rolled back.
The undo log format was changed in MDEV-12288. There is only
one persistent undo log for each transaction.

:04 04 4bd1cf7f96bcfcfdeadbdcd6771e348e13b0d312 
6b52363e618d955a49834ebcef6778430e6372cb M  extra
:04 04 25b37ceda117b9a05a200c6e3a8d4bca38e23bd5 
dff451f0a7a6d6246334aace697b230b4174f2c1 M  mysql-test
:04 04 4a0352d498b9487cae46c6363d86603de0ccb361 
3e6aa2377e89f28192e987f2f8655e3d866ab4be M  storage



-- 
Ondrej Zary

Bug#996486: bitcoind: fails to start with undefined symbol: _ZTIN7leveldb6LoggerE

[Jonas Smedegaard]

Control: reassign -1 libleveldb1d
Control: affects -1 bitcoind

Quoting Vincas Dargis (2021-10-14 19:16:00)
> Package: bitcoind
> Version: 22.0-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Since 2021-10-12 bitcoind fails to start on my machine:
> 
> ```
> # fgrep leveldb /var/log/syslog
> Oct 12 20:00:34 vinco bitcoind[1103]: /usr/bin/bitcoind: symbol lookup error: 
> /usr/bin/bitcoind: undefined symbol: _ZTIN7leveldb6Logger
> ```
> 
> This is list of updated packages just before first failure (from 
> /var/log/apt/history.log):
> 
> ```
> Start-Date: 2021-10-12  19:59:47
> Commandline: apt full-upgrade
> Requested-By: vincas (1000)
> Install: libraqm0:amd64 (0.7.0-4, automatic)
> Upgrade: libffi8:amd64 (3.4.2-2, 3.4.2-3), libffi8:i386 (3.4.2-2,
> 3.4.2-3), libntfs-3g89:amd64 (1:2021.8.22-2, 1:2021.8.22-3),
> ntfs-3g:amd64 (1:2021.8.22-2, 
> 1:2021.8.22-3), libleveldb1d:amd64 (1.22-3, 1.23-2), licensecheck:amd64
> (3.2.11-1, 3.2.13-1), python3-pkg-resources:amd64 (52.0.0-4, 58.2.0-1),
> python3-packa
> ging:amd64 (20.9-2, 21.0-1), python3-pil:amd64 (8.1.2+dfsg-0.3,
> 8.3.2-1), libisl23:amd64 (0.23-1, 0.24-2), python3-setuptools:amd64
> (52.0.0-4, 58.2.0-1), dkm
> s:amd64 (2.8.7-1, 2.8.7-2)
> End-Date: 2021-10-12  20:00:07
> ```
> 
> It seems libleveldb1d 1.23-2 broke bitcoind?

Thanks for reporting this issue, Vincas.

Sounds like a bug in libleveldb1d.


 - Jonas

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

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

signature.asc
Description: signature

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Gianfranco Costamagna]

Hello Tomasz

On Fri, 01 Oct 2021 00:04:51 +0200 Tomasz Wolak  wrote:
> Package: libyaml-cpp-dev
> Version: 0.6.3-9
> Severity: normal
> X-Debbugs-Cc: tomas.wo...@gmail.com
> 
> One of the package config files for CMake:
> 
> /usr/lib/x86_64-linux-gnu/cmake/yaml-cpp/yaml-cpp-config.cmake
> 
> contains an incorrect path to the library's header files:
> 'include' instead of '/usr/include/yaml-cpp'.
> 
> I have managed to hot-fix this by correcting debian patches:
> 
> 1. install-cmake-dev-files.patch - the line (for CMakeLists.txt):
>  set(INCLUDE_INSTALL_ROOT_DIR include)
> was changed to:
> -set(INCLUDE_INSTALL_ROOT_DIR include)
> +set(INCLUDE_INSTALL_ROOT_DIR /usr/include)
> 
> 2. fix-pkg-config.patch, where I changed the line:
> +set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_ROOT_DIR@")
> to the following:
> +set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_DIR@")
> 
> After changing this, the rebuilt package contains the correct
> path to the header files (/usr/include/yaml-cpp) in its cmake
> configuration.
> 
> (I am not sure if this is the best way for fixing this but it seems
> reasonable. It should be reviewed and tested, of course.
> I am not sure how to provide you a patch to a Debian patch...
> that's why such descriptive form).
> 
> (Btw. version 0.6.3-10 seems to have the same problem).
> 
> 


can you please check if 0.7.0 in debian/experimental fixes this issue?
The cmake scripts have been reworked, and I can't see anymore the variable not 
correctly evaluated.

In case please let me know if the bug is fixed

thanks

Gianfranco

> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libyaml-cpp-dev depends on:
> ii  libyaml-cpp0.6  0.6.3-9
> 
> libyaml-cpp-dev recommends no packages.
> 
> libyaml-cpp-dev suggests no packages.
> 
> -- no debconf information
> 

Bug#996486: bitcoind: fails to start with undefined symbol: _ZTIN7leveldb6LoggerE

[Vincas Dargis]

Package: bitcoind
Version: 22.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since 2021-10-12 bitcoind fails to start on my machine:

```
# fgrep leveldb /var/log/syslog
Oct 12 20:00:34 vinco bitcoind[1103]: /usr/bin/bitcoind: symbol lookup error: 
/usr/bin/bitcoind: undefined symbol: _ZTIN7leveldb6Logger
```

This is list of updated packages just before first failure (from 
/var/log/apt/history.log):

```
Start-Date: 2021-10-12  19:59:47
Commandline: apt full-upgrade
Requested-By: vincas (1000)
Install: libraqm0:amd64 (0.7.0-4, automatic)
Upgrade: libffi8:amd64 (3.4.2-2, 3.4.2-3), libffi8:i386 (3.4.2-2,
3.4.2-3), libntfs-3g89:amd64 (1:2021.8.22-2, 1:2021.8.22-3),
ntfs-3g:amd64 (1:2021.8.22-2, 
1:2021.8.22-3), libleveldb1d:amd64 (1.22-3, 1.23-2), licensecheck:amd64
(3.2.11-1, 3.2.13-1), python3-pkg-resources:amd64 (52.0.0-4, 58.2.0-1),
python3-packa
ging:amd64 (20.9-2, 21.0-1), python3-pil:amd64 (8.1.2+dfsg-0.3,
8.3.2-1), libisl23:amd64 (0.23-1, 0.24-2), python3-setuptools:amd64
(52.0.0-4, 58.2.0-1), dkm
s:amd64 (2.8.7-1, 2.8.7-2)
End-Date: 2021-10-12  20:00:07
```

It seems libleveldb1d 1.23-2 broke bitcoind?

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

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

Versions of packages bitcoind depends on:
ii  libboost-filesystem1.74.0  1.74.0-11
ii  libc6  2.32-4
ii  libdb5.3++ 5.3.28+dfsg1-0.8
ii  libevent-2.1-7 2.1.12-stable-1
ii  libevent-pthreads-2.1-72.1.12-stable-1
ii  libgcc-s1  11.2.0-9
ii  libleveldb1d   1.23-2
ii  libminiupnpc17 2.2.1-1
ii  libsqlite3-0   3.36.0-2
ii  libstdc++6 11.2.0-9
ii  libzmq54.3.4-1

Versions of packages bitcoind recommends:
ii  tor  0.4.5.10-1+b1

Versions of packages bitcoind suggests:
ii  bash-completion  1:2.11-4

-- no debconf information

Bug#954215: pybuild: Should do better than a traceback if cmake is not found

[Andreas Beckmann]

On Wed, 18 Mar 2020 13:26:56 -0400 Scott Kitterman 
 wrote:

Pybuild should catch the error and if needed print something useful.  I
don't know that this needs anything though.  If a package uses cmake and
it's not there, it'll eventually blow up the build anyway.  I don't thnk
pybuild needs to call it out.


Seconded. This traceback just sent me down the wrong road when 
investigating a build failure after importing a new upstream release of 
pyopencl.



Andreas

Bug#996485: pytools: please package 2021.2.7 or later, needed by pyopencl

[Andreas Beckmann]

Source: pytools
Version: 2021.1-2
Severity: important
Tags: sid bookworm
Control: affects -1 + src:pyopencl

Hi,

whily trying to upgrade pyopencl to its latest release I noticed that it
has bumped the dependency on pytools to >= 2021.2.7. (And it actually
uses some of the new features.)

Please package that or a newer version.


Thanks

Andreas

Bug#996484: Doesn not starts

[Picca Frédéric-Emmanuel]

Package: pushover
Version: 0.0.5+git20180909-4+b2
Severity: important
X-Debbugs-Cc: pi...@debian.org

Hello, while trying to play with pushover, I got this message

$ pushover 
Using portable datadir: ./data
File not found: ./data/pushover/images/dominoes.png
File not found: ./data/pushover/images/ant.png
File not found: ./data/pushover/images/box.png
 oops box image hasn't the right dimensions
found font /usr/share/fonts/truetype/freefont/FreeSans.ttf
Can't load sound from file: ./data/pushover/sounds/01_StandardFalling.ogg
Can't load sound from file: ./data/pushover/sounds/02_StopperHit.ogg
Can't load sound from file: ./data/pushover/sounds/03_Splitter.ogg
Can't load sound from file: ./data/pushover/sounds/04_Exploder.ogg
Can't load sound from file: ./data/pushover/sounds/05_Delay.ogg
Can't load sound from file: ./data/pushover/sounds/06_TumblerFalling.ogg
Can't load sound from file: ./data/pushover/sounds/07_BridgerFalling.ogg
Can't load sound from file: ./data/pushover/sounds/06_TumblerFalling.ogg
Can't load sound from file: ./data/pushover/sounds/09_TriggerFalling.ogg
Can't load sound from file: ./data/pushover/sounds/0A_Ascender.ogg
Can't load sound from file: ./data/pushover/sounds/0B_Falling.ogg
Can't load sound from file: ./data/pushover/sounds/0C_Landing.ogg
Can't load sound from file: ./data/pushover/sounds/0D_PickUpDomino.ogg
Can't load sound from file: ./data/pushover/sounds/0E_Tapping.ogg
Can't load sound from file: ./data/pushover/sounds/0F_Schrugging.ogg
Can't load sound from file: ./data/pushover/sounds/10_DoorClose.ogg
Can't load sound from file: ./data/pushover/sounds/11_DoorOpen.ogg
Can't load sound from file: ./data/pushover/sounds/13_Victory.ogg
terminate called after throwing an instance of 'std::runtime_error'
  what():  Can't open directory: ./data/pushover/levels
Abandon

Cheers

Fred


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

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

Versions of packages pushover depends on:
ii  fonts-freefont-ttf 20120503-10
ii  libboost-filesystem1.74.0  1.74.0-11
ii  libc6  2.32-4
ii  libfribidi01.0.8-2
ii  libgcc-s1  11.2.0-9
ii  liblua5.3-05.3.6-1
ii  libpng16-161.6.37-3
ii  libsdl-mixer1.21.2.12-16+b1
ii  libsdl-ttf2.0-02.0.11-6
ii  libsdl1.2debian1.2.15+dfsg2-6
ii  libstdc++6 11.2.0-9
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages pushover recommends:
ii  pushover-data  0.0.5+git20180909-4

pushover suggests no packages.

-- no debconf information

Bug#995066: [debian-mysql] Bug#995066: mariadb-server: Incorrect warning about corrupt tables on mysql start

[Александр Кириллов]

Otto Kekäläinen писал 2021-09-25 22:04:

Thanks for the report and patch!

Would you want to submit it as a MR at
https://salsa.debian.org/mariadb-team/mariadb-10.5 ?


The problem can be fixed by adding

default-character-set = utf8mb4

to the [client] section of /etc/mysql/debian.cnf.

Consider the issue closed.

Thanks.

Bug#961129: xscreensaver should not search for screensaver executables in PATH

[Jamie Zawinski]

You could solve this problem with a one-line change: simply make "xscreensaver" 
depend upon "xscreensaver-data", "xscreensaver-data-extra", "xscreensaver-gl", 
"xscreensaver-gl-extra", "xscreensaver-screensaver-bsod" and 
"xscreensaver-screensaver-webcollage".

I can see the argument for allowing the hacks to be installed without the 
XScreenSaver daemon, in case some other screen saver framework wanted to run 
them (do any of the other frameworks still support that? I don't think so?)

However, if the XScreenSaver daemon is installed, then *all* of XScreenSaver 
must be installed, or else you get the "zoom" problem and related. 

That is how it was designed, and that is how it was tested. Trying to install 
bits and pieces of it and hoping it still holds together demonstrably does not 
work.

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

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

[Александр Кириллов]

Otto Kekäläinen писал 2021-10-14 04:55:

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?


This is not a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995066 but there's an 
easier fix for #995066 and #996389: to add


default-character-set = utf8mb4

to [client] section of /etc/mysql/debian.cnf.

This seems to be working with legacy charsets too, so you may consider 
the issue closed.

Thanks.

Bug#996470: motion terminates directly after startup when run as service from systemd

[pelzi]

Package: motion
Version: 4.3.2-1
Severity: important

Dear Maintainer,

after migration of motion settings to a fresh setup of Raspbian 11, the motion 
process terminates
directly after startup without any error message. Without any changes to config 
files, running
the command
 motion -b -p /var/run/motion/motion.pid
is running exactly as expected.

Note: error/warning messages about one of the camera appear in both variants, 
because a hot-pluggable
camera was unplugged at that time. Motion copes with this situation if started 
manually.
The reason of "motion_loop: Thread wird beendet" as well as of "Active: 
deactivating (stop-sigterm)"
remains mysterious to me.

-- systemd status:
$ sudo service motion status
● motion.service - Motion detection video capture daemon
 Loaded: loaded (/lib/systemd/system/motion.service; enabled; vendor 
preset: enabled)
 Active: deactivating (stop-sigterm) since Thu 2021-10-14 13:31:41 CEST; 
462ms ago
   Docs: man:motion(1)
Process: 13537 ExecStart=/usr/bin/motion (code=exited, status=0/SUCCESS)
   Main PID: 13537 (code=exited, status=0/SUCCESS)
  Tasks: 8 (limit: 2059)
CPU: 1.151s
 CGroup: /system.slice/motion.service
 ├─13543 /usr/bin/motion
 ├─13546 sh -c /var/lib/motion/bin/motion_status.sh 0  &
 ├─13547 /bin/bash /var/lib/motion/bin/motion_status.sh 0
 ├─13549 /usr/bin/ssh -n -T mot...@athlon1.internal.flying-snail.de
 ├─13550 sh -c /var/lib/motion/bin/motion_status.sh 0  &
 ├─13551 /bin/bash /var/lib/motion/bin/motion_status.sh 0
 └─13553 /usr/bin/ssh -n -T mot...@athlon1.internal.flying-snail.de

Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [ERR] [VID] vid_start: 
V4L2-Gerät konnte nicht geöffnet werden
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [WRN] [ALL] motion_init: Das 
ursprüngliche Bild konnte nicht von der Kamera abgerufen werden
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [WRN] [ALL] motion_init: Die 
Bewegung verwendet weiterhin die Breite und Höhe der Konfigurationsdatei (en).
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [CRT] [NET] motion_init: 
Substream nicht verfügbar. Bildgrößen nicht modulo 16.
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [NTC] [ALL] image_ring_resize: 
Ändern der Größe des Pre-Capture-Puffers auf 1 Elemente
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [NTC] [ALL] image_ring_resize: 
Ändern der Größe des Pre-Capture-Puffers auf 10 Elemente
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [NTC] [ALL] mlp_actions: Ende 
des Ereignisses 1
Okt 14 13:31:41 somehost motion[13548]: Motion event: 0
Okt 14 13:31:41 somehost motion[13543]: [2:ml2] [NTC] [ALL] motion_loop: Thread 
wird beendet
Okt 14 13:31:41 somehost motion[13552]: Motion event: 0

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

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

Versions of packages motion depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  libavcodec58   7:4.3.2-0+rpt3+deb11u2
ii  libavdevice58  7:4.3.2-0+rpt3+deb11u2
ii  libavformat58  7:4.3.2-0+rpt3+deb11u2
ii  libavutil567:4.3.2-0+rpt3+deb11u2
ii  libc6  2.31-13+rpt2+rpi1
ii  libjpeg62-turbo1:2.0.6-4
ii  libmariadb31:10.5.12-0+deb11u1
ii  libmicrohttpd120.9.72-2
ii  libpq5 13.4-0+deb11u1
ii  libsqlite3-0   3.34.1-3
ii  libswscale57:4.3.2-0+rpt3+deb11u2
ii  lsb-base   11.1.0+rpi1

Versions of packages motion recommends:
pn  ffmpeg  

Versions of packages motion suggests:
pn  default-mysql-client  
pn  postgresql-client 

-- Configuration Files:
/etc/motion/motion.conf [Errno 13] Keine Berechtigung: '/etc/motion/motion.conf'

-- debconf information:
  motion/moved_conf_dir: