Bug#1084934: /usr/bin/pg_upgradecluster: pg_upgradecluster fails: could not read permissions of log directory

[Antonio Terceiro]

Package: postgresql-common
Version: 264
Severity: important
File: /usr/bin/pg_upgradecluster

Dear Maintainer,

I just tried upgrading my 16 cluster to 17, and pg_upgradecluster fails
to do the upgrade. I tried this on 2 different machines with different
architectures, to the same exact failure. Follows the log of that in the
second one:

8<8<8<-
root@ava:~# pg_dropcluster --stop 17 main
root@ava:~# pg_upgradecluster -m clone 16 main 17
ADVERTÊNCIA:  o banco de dados "template1" possui uma de versão de ordenação 
sem correspondência
DETAIL:  O banco de dados foi criado usando a versão de ordenação 2.39, mas o 
sistema operacional fornece a versão 2.40.
HINT:  Reconstrua todos os objetos nesse banco de dados que usam a ordenação 
padrão e execute ALTER DATABASE template1 REFRESH COLLATION VERSION, ou 
construa o PostgreSQL com a versão correta da biblioteca.
ADVERTÊNCIA:  o banco de dados "template1" possui uma de versão de ordenação 
sem correspondência
DETAIL:  O banco de dados foi criado usando a versão de ordenação 2.39, mas o 
sistema operacional fornece a versão 2.40.
HINT:  Reconstrua todos os objetos nesse banco de dados que usam a ordenação 
padrão e execute ALTER DATABASE template1 REFRESH COLLATION VERSION, ou 
construa o PostgreSQL com a versão correta da biblioteca.
Stopping old cluster...
Creating new PostgreSQL cluster 17/main ...
/usr/lib/postgresql/17/bin/initdb -D 17 --auth-local peer --auth-host 
scram-sha-256 --no-instructions --encoding UTF8 --lc-collate pt_BR.UTF-8 
--lc-ctype pt_BR.UTF-8 --locale-provider libc
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with this locale configuration:
  locale provider:   libc
  LC_COLLATE:  pt_BR.UTF-8
  LC_CTYPE:pt_BR.UTF-8
  LC_MESSAGES: C.UTF-8
  LC_MONETARY: C.UTF-8
  LC_NUMERIC:  C.UTF-8
  LC_TIME: C.UTF-8
The default text search configuration will be set to "portuguese".

Data page checksums are disabled.

fixing permissions on existing directory 17 ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... America/Bahia
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Running init phase upgrade hook scripts ...

/usr/lib/postgresql/17/bin/pg_upgrade -b /usr/lib/postgresql/16/bin -B 
/usr/lib/postgresql/17/bin -p 5432 -P 5433 -d /etc/postgresql/16/main -D 
/etc/postgresql/17/main --clone
Finding the real data directory for the source clusterok
Finding the real data directory for the target cluster2024-10-11 
11:49:15.555 GMT [37914] LOG:  skipping missing configuration file 
"/var/log/postgresql/pg_upgradecluster-16-17-main.evvf/17/postgresql.auto.conf"
ok

could not read permissions of directory 
"/var/log/postgresql/pg_upgradecluster-16-17-main.evvf/17": No such file or 
directory
Failure, exiting

Error during cluster dumping, removing new cluster
Cluster is not running.
Starting old cluster again ...
root@ava:~#
8<8<8<-

/var/log/postgresql/pg_upgradecluster-16-17-main.evvf/ is created by
pg_upgradecluster, but it seems that pg_upgrade is looking for an extra
"17" directory inside that? Maybe this is a bug in pg_upgrade.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.10.11-arm64 (SMP w/32 CPU threads)
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 postgresql-common depends on:
ii  adduser3.137
ii  debconf [debconf-2.0]  1.5.87
ii  init-system-helpers1.67
ii  libjson-perl   4.1-1
ii  perl   5.38.2-5
ii  postgresql-client-common   264
ii  ssl-cert   1.1.3
ii  sysvinit-utils [lsb-base]  3.10-2
ii  ucf3.0043+nmu1

Versions of packages postgresql-common recommends:
ii  e2fsprogs  1.47.1-1
ii  logrotate  3.22.0-1

postgresql-common suggests no packages.

-- debconf information:
  postgresql-common/catversion-bump:
* postgresql-common/obsolete-major:
  postgresql-common/ssl: true


signature.asc
Description: PGP signature

Bug#1069089: ruby-rubygems: Broken platform detection which lead to unability to install sass-embedded

[Antonio Terceiro]

On Mon, Aug 26, 2024 at 04:00:06PM +0200, David Rodríguez wrote:
> Hello, RubyGems upstream maintainer here.
> 
> I heard that Bundler now has trouble installing the proper platform specific 
> version of any gems that ship “non-gnu” variants (not only `sass-embedded`) 
> when using RubyGems packed by Debian due to this issue. That means that 
> people using Debian stable fail to use Jekyll: 
> https://github.com/jekyll/jekyll/issues/9478#issuecomment-1785797746.
> 
> I’m not fully sure about this issues introduced by the upstream patch but 
> happy to help out with making it possible to revert the patch.
> 
> Thanks!

Hi,

The patch mentioned in the jekyll issue was written by me, and looks
like this:

───┬─
   │ File: 
debian/patches/0002-Gem-Platform-emulate-3.3.15-behavior-on-Ruby-3.1.patch
───┼─────
   1   │ From: Antonio Terceiro 
   2   │ Date: Fri, 13 Oct 2023 11:14:01 -0300
   3   │ Subject: Gem::Platform: emulate 3.3.15 behavior on Ruby 3.1
   4   │ 
   5   │ rubygems 3.4 calls a Linux platform something like aarch64-linux-gnu,
   6   │ where 3.3 called it just aarch64-linux. Given all the existing native
   7   │ extensions for Ruby 3.1 in the Debian archive had been built
   8   │ using rubygems 3.3, let's keep the old behavior on Ruby 3.1 as to not
   9   │ immediately break all the existing extensions.
  10   │ ---
  11   │  lib/rubygems/platform.rb | 3 +++
  12   │  1 file changed, 3 insertions(+)
  13   │ 
  14   │ diff --git a/lib/rubygems/platform.rb b/lib/rubygems/platform.rb
  15   │ index b721629..34d94bd 100644
  16   │ --- a/lib/rubygems/platform.rb
  17   │ +++ b/lib/rubygems/platform.rb
  18   │ @@ -117,6 +117,9 @@ def initialize(arch)
  19   │when /^(\w+_platform)(\d+)?/ then [ $1,  $2  ]
  20   │else  [ "unknown",   nil ]
  21   │end
  22   │ +
  23   │ +  # emulate behavior from 3.3.15 on ruby 3.1
  24   │ +  @version = nil if (RUBY_VERSION < "3.2" && @os == "linux")
  25   │  when Gem::Platform then
  26   │@cpu = arch.cpu
  27   │@os = arch.os
───┴─

As far as I can remember, it was necessary in order to not need to
rebuilding every single Debian package that had been compiled before
rubygems 3.4. The workaround mentioned in a previous message will work,
but it will also break all the Debian ruby-* packages that contain
compiled code.

But, as you can see, the changed behavior only applies to ruby < 3.2. We
are about to start a transition to ruby 3.3, and that will probably take
a few months. After the transition is done, this problem will no longer
be relevant.

With that said, I could not reproduce this issue with the current
default ruby. If someone can provide a minimal reproducer, I can try to
look into it.


signature.asc
Description: PGP signature

Bug#1058566: auto-apt-proxy: "approx" should not be given https URLs

[Antonio Terceiro]

Control: tag -1 + wontfix
Control: retitle -1 auto-apt-proxy: https mirror URLs might not work depending 
on the proxy configuration

Hi,

On Fri, Sep 06, 2024 at 03:49:47PM +0200, Lars Kruse wrote:
> Hello,
> 
> 
> Am Wed, 4 Sep 2024 19:48:27 -0300
> schrieb Antonio Terceiro :
> 
> > Can you please clarify how exactly are you hitting this issue? Can you
> > provide an example of how I can reproduce this?
> 
> yes, sorry for omitting these details in my initial bug report.
> 
> I just created a fresh image for testing and ran the following procedure:
> 
> 1. `apt install auto-apt-proxy ca-certificates`
>(certificates are necessary for https connections)
> 1. change the URL in `/etc/apt/sources.list` to
> http://deb.debian.org/debian
> 1. run `apt update` -> success
> 1. change the URL in `/etc/apt/sources.list` to
> https://deb.debian.org/debian
> 1. run `apt update` -> failure (see below)
> 1. `apt purge auto-apt-proxy`
> 1. run `apt update` -> success
> 
> 
> Here `auto-apt-proxy` detected the presence of approx via the DNS SRV entry
> (_apt_proxy._tcp).
> 
> The above example illustrates, that auto-apt-proxy will send the request for
> an https ressource to approx, even though approx cannot handle such requests.
> 
> Of course, the use case behind the above switch to "https" can be questioned,
> since the default settings for apt servers usually use http URLs.
> 
> In my use case we stumbled upon the problem, since our internal apt repository
> server is usually accessed via https (for no specific reasons).
> This turned out to be problematic as soon as approx was indirectly used via
> auto-apt-proxy.
> 
> I hope, this clarifies my use case.

It does. However, HTTP proxy servers and HTTPS is usually problematic
regardless of auto-apt-proxy being in use or not. apt-cacher-ng needs a
specific line in the config file to make it work, and approx seems to
not support HTTPS at all based on what you are saying.

Whether HTTPS will work or not will always depend on the proxy
configuration, and there is not much I can do on auto-apt-proxy to
detect that.

For you case, as a workaround you could put the following in a file
under /etc/apt/apt.conf.d/:

Acquire::https::Proxy "DIRECT";

or even

Acquire::https::Proxy::mirror.hostname "DIRECT";


signature.asc
Description: PGP signature

Bug#1058566: auto-apt-proxy: "approx" should not be given https URLs

[Antonio Terceiro]

Control: tag -1 + moreinfo

Hi, thanks for your bug report.

On Wed, Dec 13, 2023 at 12:42:24AM +0100, Lars Kruse wrote:
> Package: auto-apt-proxy
> Version: 14.1
> Severity: normal
> 
> Dear Maintainer,
> 
> according to d#756656 [1] https-URLs cannot be given to `approx`.
> Thus, the `approx` check should be skipped when an https URL is
> requested.

Can you please clarify how exactly are you hitting this issue? Can you
provide an example of how I can reproduce this?


signature.asc
Description: PGP signature

Bug#1080424: podman: /etc/profile.d/podman-docker.sh breaks docker, should not be shipped in the podman binary package

[Antonio Terceiro]

Package: podman
Version: 5.2.2+ds1-1
Severity: critical
Justification: breaks unrelated software

/etc/profile.d/podman-docker.sh is currently shipped in the podman
binary. If one also has docker installed, the DOCKER_HOST variable set
there makes docker try to connect to the podman daemon which is not
running unless podman-docker is installed.

/etc/profile.d/podman-docker.sh (and .csh) should be shipped in the
podman-docker binary package, not in the main podman binary.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.10.6-arm64 (SMP w/32 CPU threads)
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 podman depends on:
ii  conmon   2.1.10+ds1-1+b1
ii  crun 1.16.1-1
ii  golang-github-containers-common  0.60.1+ds1-3
ii  init-system-helpers  1.66
ii  libc62.40-2
ii  libgpgme11t641.18.0-5
ii  libseccomp2  2.5.5-1+b1
ii  libsqlite3-0 3.46.0-1
ii  libsubid51:4.16.0-4
ii  netavark 1.9.0-4
ii  runc 1.1.12+ds1-5

Versions of packages podman recommends:
ii  buildah 1.37.1+ds1-2
ii  ca-certificates 20240203
ii  catatonit   0.1.7-1+b1
ii  containers-storage  1.55.0+ds1-3
ii  dbus-user-session   1.14.10-4+b1
ii  passt   0.0~git20240821.1d6142f-1
ii  slirp4netns 1.2.1-1+b1
ii  tini0.19.0-1
ii  uidmap  1:4.16.0-4

Versions of packages podman suggests:
pn  docker-compose  
ii  iptables1.8.10-4

-- no debconf information


signature.asc
Description: PGP signature

Bug#1079834: ohcount: FTBFS: ruby/ohcount_wrap.c:2241:34: error: passing argument 3 of ‘rb_iterate’ from incompatible pointer type [-Wincompatible-pointer-types]

[Antonio Terceiro]

Source: ohcount
Version: 4.0.0-4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

Your package fails to build on amd64. This seems caused by gcc 14 being
stricter than previous versions of the compiler.  The full build log is
attached.

Relevant part (hopefully):
> gcc -fPIC -g -O3 -Wall -Wno-pointer-to-int-cast -Wno-parentheses -I -L 
> -shared ruby/ohcount_wrap.c src/sourcefile.c src/detector.c src/licenses.c 
> src/parser.o src/loc.c src/log.c src/diff.c src/parsed_language.c 
> src/hash/language_hash.c -o ruby/aarch64-linux-gnu_debian/ohcount.so 
> -I/usr/include/ruby-3.1.0 -I/usr/include/ruby-3.1.0/aarch64-linux-gnu 
> -I/usr/include/aarch64-linux-gnu/ruby-3.1.0 -lpcre2-8 -lmagic
> ruby/ohcount_wrap.c: In function ‘new_SourceFileListItem’:
> ruby/ohcount_wrap.c:2241:9: warning: ‘rb_iterate’ is deprecated: by: 
> rb_block_call since 1.9 [-Wdeprecated-declarations]
>  2241 | rb_iterate(rb_each, val, SourceFileListItem_rb_add_directory, 
> (VALUE)list);
>   | ^~
> In file included from /usr/include/ruby-3.1.0/ruby/ruby.h:40,
>  from /usr/include/ruby-3.1.0/ruby.h:38,
>  from ruby/ohcount_wrap.c:908:
> /usr/include/ruby-3.1.0/ruby/internal/iterator.h:283:7: note: declared here
>   283 | VALUE rb_iterate(VALUE (*func1)(VALUE), VALUE data1, 
> rb_block_call_func_t proc, VALUE data2);
>   |   ^~
> ruby/ohcount_wrap.c:2241:34: error: passing argument 3 of ‘rb_iterate’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
>  2241 | rb_iterate(rb_each, val, SourceFileListItem_rb_add_directory, 
> (VALUE)list);
>   |  ^~~
>   |  |
>   |  VALUE (*)(VALUE,  SourceFileList *) 
> {aka long unsigned int (*)(long unsigned int,  struct SourceFileListItem *)}
> /usr/include/ruby-3.1.0/ruby/internal/iterator.h:283:75: note: expected 
> ‘rb_block_call_func_t’ {aka ‘long unsigned int (*)(long unsigned int,  long 
> unsigned int,  int,  const long unsigned int *, long unsigned int)’} but 
> argument is of type ‘VALUE (*)(VALUE,  SourceFileList *)’ {aka ‘long unsigned 
> int (*)(long unsigned int,  struct SourceFileListItem *)’}
>   283 | VALUE rb_iterate(VALUE (*func1)(VALUE), VALUE data1, 
> rb_block_call_func_t proc, VALUE data2);
>   |  
> ~^~~~
> ruby/ohcount_wrap.c:2244:9: warning: ‘rb_iterate’ is deprecated: by: 
> rb_block_call since 1.9 [-Wdeprecated-declarations]
>  2244 | rb_iterate(rb_each, val, SourceFileListItem_rb_add_file, 
> (VALUE)list);
>   | ^~
> /usr/include/ruby-3.1.0/ruby/internal/iterator.h:283:7: note: declared here
>   283 | VALUE rb_iterate(VALUE (*func1)(VALUE), VALUE data1, 
> rb_block_call_func_t proc, VALUE data2);
>   |   ^~
> ruby/ohcount_wrap.c:2244:34: error: passing argument 3 of ‘rb_iterate’ from 
> incompatible pointer type [-Wincompatible-pointer-types]
>  2244 | rb_iterate(rb_each, val, SourceFileListItem_rb_add_file, 
> (VALUE)list);
>   |  ^~
>   |  |
>   |  VALUE (*)(VALUE,  SourceFileList *) 
> {aka long unsigned int (*)(long unsigned int,  struct SourceFileListItem *)}
> /usr/include/ruby-3.1.0/ruby/internal/iterator.h:283:75: note: expected 
> ‘rb_block_call_func_t’ {aka ‘long unsigned int (*)(long unsigned int,  long 
> unsigned int,  int,  const long unsigned int *, long unsigned int)’} but 
> argument is of type ‘VALUE (*)(VALUE,  SourceFileList *)’ {aka ‘long unsigned 
> int (*)(long unsigned int,  struct SourceFileListItem *)’}
>   283 | VALUE rb_iterate(VALUE (*func1)(VALUE), VALUE data1, 
> rb_block_call_func_t proc, VALUE data2);
>   |  
> ~^~~~
> src/sourcefile.c: In function ‘ohcount_sourcefile_new’:
> src/sourcefile.c:27:3: warning: ‘strncpy’ output truncated before terminating 
> nul copying as many bytes from a string as its length [-Wstringop-truncation]
>27 |   strncpy(sourcefile->filepath, filepath, length);
>   |   ^~~
> src/sourcefile.c:25:16: note: length computed here
>25 |   int length = strlen(filepath);
>   |^~~~
> src/sourcefile.c: In function ‘ohcount_sourcefile_set_diskpath’:
> src/sourcefile.c:67:3: warning: ‘strncpy’ output truncated before terminating 
> nul copying as many bytes from a string as its length [-Wstringop-truncation]
>67 |   strncpy(sourcefile->diskpath, diskpath, size);
>   |   ^
> src/sourcefile.c:65:14: note: length computed here
>65 |   int size = strlen(diskpath);
>   |  ^~~~
> s

Bug#1079832: dotenv-cli: unnecessary conflicts against ruby-dotenv

[Antonio Terceiro]

Package: dotenv-cli
Version: 3.4.0-1
Severity: normal
Tags: patch

ruby-dotenv used to provide /usr/bin/dotenv, but it doesn't since
bookworm. For some reason the changelog doesn't mention that.

I am including a patch that sets the conflicts to only apply to the
pre-bookworm version, please consider applying it.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.10.6-arm64 (SMP w/32 CPU threads)
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 dotenv-cli depends on:
ii  python3  3.12.5-1

dotenv-cli recommends no packages.

dotenv-cli suggests no packages.

-- no debconf information
From f930fc9f7ab4979e3c90bc030494145c6e994b2b Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Tue, 27 Aug 2024 20:15:41 -0300
Subject: [PATCH] Only Conflicts with the pre-bookworm version of ruby-dotenv

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index e1d3760..fbe16e5 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Testsuite: autopkgtest-pkg-python
 Package: dotenv-cli
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
-Conflicts: ruby-dotenv
+Conflicts: ruby-dotenv (<< 2.4.0-2)
 Replaces: python3-dotenv-cli (<< 3.3.1-1)
 Breaks: python3-dotenv-cli (<< 3.3.1-1)
 Description: CLI that loads .env configuration
@@ -34,7 +34,7 @@ Description: CLI that loads .env configuration
 Package: python3-dotenv-cli
 Architecture: all
 Depends: dotenv-cli, ${misc:Depends}
-Conflicts: ruby-dotenv
+Conflicts: ruby-dotenv (<< 2.4.0-2)
 Section: oldlibs
 Description: transitional package
  This package provides the dotenv command. It reads the .env file from the
-- 
2.45.2



signature.asc
Description: PGP signature

Bug#1079262: FTBFS: error: invalid command 'test'

[Antonio Terceiro]

Source: python-django-pyscss
Version: 2.0.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

python-django-pyscss fails to build. This is hopefully the relevant
part the log:

8<8<8<-
===> Testing with python3.12
/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py:268: UserWarning: 
Unknown distribution option: 'tests_require'
  warnings.warn(msg)
/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py:268: UserWarning: 
Unknown distribution option: 'test_suite'
  warnings.warn(msg)
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'test'
make[1]: *** [debian/rules:22: override_dh_auto_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2
8<8<8<-

The full build log is attached.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.10.4-arm64 (SMP w/32 CPU threads)
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
sbuild (Debian sbuild) 0.85.10 (30 May 2024) on ava

+==+
| python-django-pyscss (arm64) Wed, 21 Aug 2024 20:11:42 + |
+==+

Package: python-django-pyscss
Distribution: unstable
Machine Architecture: arm64
Host Architecture: arm64
Build Architecture: arm64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-arm64-sbuild-11d59bf1-e5aa-4b18-91ba-a415a6047bc2'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/python-django-pyscss-apyg71/resolver-tYWCeJ' with '<>'

+--+
| Update chroot|
+--+

Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian experimental InRelease [101 kB]
Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:4 http://deb.debian.org/debian unstable/main arm64 Packages.diff/Index 
[63.6 kB]
Get:5 http://deb.debian.org/debian experimental/main arm64 Packages.diff/Index 
[63.3 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources 
T-2024-08-21-1409.09-F-2024-08-20-2012.11.pdiff [58.3 kB]
Get:7 http://deb.debian.org/debian unstable/main arm64 Packages 
T-2024-08-21-1409.09-F-2024-08-20-2012.11.pdiff [81.0 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources 
T-2024-08-21-1409.09-F-2024-08-20-2012.11.pdiff [58.3 kB]
Get:7 http://deb.debian.org/debian unstable/main arm64 Packages 
T-2024-08-21-1409.09-F-2024-08-20-2012.11.pdiff [81.0 kB]
Get:8 http://deb.debian.org/debian experimental/main arm64 Packages 
T-2024-08-21-1409.09-F-2024-08-20-2012.11.pdiff [14.3 kB]
Get:8 http://deb.debian.org/debian experimental/main arm64 Packages 
T-2024-08-21-1409.09-F-2024-08-20-2012.11.pdiff [14.3 kB]
Fetched 643 kB in 9s (72.1 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  libselinux1 linux-libc-dev
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2447 kB of archives.
After this operation, 6144 B of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main arm64 libselinux1 arm64 3.7-1 
[71.6 kB]
Get:2 http://deb.debian.org/debian unstable/main arm64 linux-libc-dev all 
6.10.6-1 [2376 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 2447 kB in 0s (39.7 MB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 11899 files and directories currently installed.)
Preparing to unpack .../libselinux1_3.7-1_arm64.deb ...
Unpacking libselinux1:arm64 (3.7-1)

Bug#1078188: libreoffice-calc: exporting chart as SVG produces empty file

[Antonio Terceiro]

Package: libreoffice-calc
Version: 4:24.8.0~rc2-1
Severity: normal

Dear Maintainer,

I create a chart from my Calc data and try to export the chart as a
graphic. I select the SVG format, click save. The file is created, but
it's empty. Exporting as PNG works normally.

I checked whether I was missing any optional packages, but I couldn't
find any missing Recommends: in either libreoffice-calc,
libreoffice-core, or libreoffice-base-core that looked relevant.

I am running testing/arm64, fully up to date + the latest libreoffice
bits from experimental. This also happens with the version in
testing. I tested on testing/amd64 as well, and got the same result.

-- Package-specific info:
Configuration filePackage Exists Changed
/etc/libreoffice/registry/calc.xcdlibreoffice-calcYes No
All deployed bundled extensions:


All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name VersionArchitecture Description
+++--==--===
ii  libreoffice-gtk3 4:24.8.0~rc2-1 arm64office productivity suite -- 
GTK+ 3 integration
un  libreoffice-kf5  (no description available)
un  libreoffice-qt5  (no description available)

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.9.12-arm64 (SMP w/32 CPU threads)
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 libreoffice-calc depends on:
ii  coinor-libcoinmp1v5 1.8.3-3+b1
ii  debconf [debconf-2.0]   1.5.87
ii  libc6   2.39-6
ii  libetonyek-0.1-10.1.10-5+b1
ii  libgcc-s1   14-20240330-1
ii  libicu7272.1-5
ii  libmwaw-0.3-3   0.3.22-1+b1
ii  libodfgen-0.1-1 0.1.8-2+b1
ii  liborcus-0.18-0 0.19.2-3+b3
ii  liborcus-parser-0.18-0  0.19.2-3+b3
ii  libreoffice-base-core   4:24.8.0~rc2-1
ii  libreoffice-common  4:24.8.0~rc2-1
ii  libreoffice-core4:24.8.0~rc2-1
ii  libreoffice-uiconfig-calc   4:24.8.0~rc2-1
ii  librevenge-0.0-00.0.5-3+b1
ii  libstaroffice-0.0-0 0.0.7-1+b1
ii  libstdc++6  14-20240330-1
ii  libuno-cppu3t64 4:24.8.0~rc2-1
ii  libuno-cppuhelpergcc3-3t64  4:24.8.0~rc2-1
ii  libuno-sal3t64  4:24.8.0~rc2-1
ii  libuno-salhelpergcc3-3t64   4:24.8.0~rc2-1
ii  libwps-0.4-40.4.14-2+b1
ii  libxml2 2.9.14+dfsg-1.3+b3
ii  lp-solve5.5.2.5-3
ii  ucf 3.0043+nmu1
ii  uno-libs-private4:24.8.0~rc2-1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.3.2-1+b1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.15.0-1.1
ii  fonts-opensymbol4:102.12+LibO24.8.0~rc2-1
ii  libabsl20230802 20230802.1-4
ii  libargon2-1 0~20190702+dfsg-4+b1
ii  libboost-locale1.83.0   1.83.0-3+b2
ii  libc6   2.39-6
ii  libcairo2   1.18.0-3+b1
ii  libclucene-contribs1t64 2.3.3.4+dfsg-1.2
ii  libclucene-core1t64 2.3.3.4+dfsg-1.2
ii  libcmis-0.6-6t640.6.2-2.1+b1
ii  libcups2t64 2.4.10-1
ii  libcurl4t64 8.8.0-4
ii  libdbus-1-3 1.14.10-4+b1
ii  libdconf1   0.40.0-4+b2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.10-1+b2
ii  libexpat1   2.6.2-1
ii  libexttextcat-2.0-0 3.4.7-1
ii  libfontconfig1  2.15.0-1.1
ii  libfreetype62.13.2+dfsg-1+b4
ii  libgcc-s1   14-20240330-1
ii  libglib2.0-0t64 2.80.4-1
ii  libgpgmepp6t64  1.18.0-4.1+b2
ii  libgraphite2-3  1.3.14-2
ii  libgstreamer-plugins-base1.0-0  1.24.6-1
ii  libgstreamer1.0-0   1.24.6-1
ii  libharfbuzz-icu08.3.0-2+b1
ii  libharfbuzz0b   8.3.0-2+b1
ii  libhunspell-1.7-0   1.7.2+really1.7.2-10+b2
ii  libhyphen0  2.8.8-7+b1
ii  libice6 2:1.0.10-1+b1
ii  libicu7272.1-5
ii  libjpeg62-turbo 1:2.1.5-3
ii  liblcm

Bug#1072049: please provide a link to the artifacts on the page displaying the log

[Antonio Terceiro]

On Tue, May 28, 2024 at 08:38:04PM +0200, Paul Gevers wrote:
> Hi,
> 
> Unfortunately
> 
> On 28-05-2024 2:46 p.m., Antonio Terceiro wrote:
> > FWIW given this is pretty simple I also live patched the server.
> 
> ..the link now is: 
> https://ci.debian.net/packages/r/reform-setup-wizard/testing/s390x/47038806/%7B%20base_url%20%7D/artifacts.tar.gz
> 
> Note the {base_url}/ which doesn't get replaced correctly... :(

meh. It's fixed now.


signature.asc
Description: PGP signature

Bug#1072049: please provide a link to the artifacts on the page displaying the log

[Antonio Terceiro]

On Tue, May 28, 2024 at 09:40:16AM -0300, Antonio Terceiro wrote:
> Control: tag -1  + pending
> 
> On Mon, May 27, 2024 at 10:10:46PM +0200, Johannes Schauer Marin Rodrigues 
> wrote:
> > Source: debci
> > Severity: wishlist
> > 
> > Hi,
> > 
> > when I stored artifacts for my autopkgtest job, I somehow expected the
> > link to download the artifacts to be shown next to the log:
> > 
> > https://ci.debian.net/packages/r/reform-setup-wizard/testing/s390x/47038806/
> > 
> > Because this is the page one is shown when clicking on failed results
> > via tracker.d.o
> 
> Yes. I have noticed this a few weeks ago and it has been done in git:
> 
> https://salsa.debian.org/ci-team/debci/-/commit/f76020225d70bdd4573bbaf9570b8aae769dbc04

FWIW given this is pretty simple I also live patched the server.


signature.asc
Description: PGP signature

Bug#1072049: please provide a link to the artifacts on the page displaying the log

[Antonio Terceiro]

Control: tag -1  + pending

On Mon, May 27, 2024 at 10:10:46PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Source: debci
> Severity: wishlist
> 
> Hi,
> 
> when I stored artifacts for my autopkgtest job, I somehow expected the
> link to download the artifacts to be shown next to the log:
> 
> https://ci.debian.net/packages/r/reform-setup-wizard/testing/s390x/47038806/
> 
> Because this is the page one is shown when clicking on failed results
> via tracker.d.o

Yes. I have noticed this a few weeks ago and it has been done in git:

https://salsa.debian.org/ci-team/debci/-/commit/f76020225d70bdd4573bbaf9570b8aae769dbc04


signature.asc
Description: PGP signature

Bug#1069292: libcurl4t64: regression: CURLINFO_REQUEST_SIZE returns 0

[Antonio Terceiro]

Package: libcurl4t64
Version: 8.7.1-2
Severity: important
Tags: upstream patch
Forwarded: https://github.com/curl/curl/issues/13269

Dear Maintainer,

curl 8.7 no longer fills in the request_size field. This has been
reported upstream in the following issue:

https://github.com/curl/curl/issues/13269

This causes at least ruby-ethon, a Ruby library that wraps libcurl via
FFI, to fail its test suite (after fixing it to not hardcode libcurl4 as
a dependency), like this:

8<8<8<-
Failures:

  1) Ethon::Easy::Informations#request_size returns 53
 Failure/Error: expect(easy.request_size).to eq(53)

   expected: 53
got: 0

   (compared using ==)
 # ./spec/ethon/easy/informations_spec.rb:92:in `block (3 levels) in '

Finished in 5.06 seconds (files took 0.80166 seconds to load)
578 examples, 1 failure, 2 pending

Failed examples:

rspec ./spec/ethon/easy/informations_spec.rb:91 # 
Ethon::Easy::Informations#request_size returns 53
8<8<8<-

(the same test suite passes just fine against libcurl4 8.6.0-3 from testing.)

I have tested the patch in https://github.com/curl/curl/pull/13275 and
it indeed fixes this. I'm including a patch against the Debian package
in the archive that includes this patch in debian/patches, with the
fuzzyness already removed, and updates debian/patches/series accordingly.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.15-arm64 (SMP w/32 CPU threads)
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 libcurl4t64 depends on:
ii  libbrotli11.1.0-2+b3
ii  libc6 2.37-15
ii  libgssapi-krb5-2  1.20.1-5+b1
ii  libidn2-0 2.3.7-2
ii  libldap-2.5-0 2.5.13+dfsg-5+b3
ii  libnghttp2-14 1.59.0-1
pn  libpsl5t64
ii  librtmp1  2.4+20151223.gitfa8646d.1-2+b2
pn  libssh2-1t64  
pn  libssl3t64
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages libcurl4t64 recommends:
ii  ca-certificates  20240203

libcurl4t64 suggests no packages.
diff -Nru curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch
--- curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch	1970-01-01 00:00:00.0 +
+++ curl-8.7.1/debian/patches/Fix_CURLINFO_REQUEST_SIZE.patch	2024-04-19 13:18:39.0 +
@@ -0,0 +1,210 @@
+From 2793acbfc5e89fb130b1d4e045cb6cd7b6549412 Mon Sep 17 00:00:00 2001
+From: Stefan Eissing 
+Date: Thu, 4 Apr 2024 11:06:06 +0200
+Subject: [PATCH] Fix CURLINFO_REQUEST_SIZE, add tests for transfer infos
+ reported
+
+- refs #13269
+- tests for 'size_request' and other stats reported, for
+  presence and consistency
+---
+ lib/transfer.c  |   3 +
+ tests/http/test_16_info.py  | 162 
+ tests/http/testenv/httpd.py |   1 +
+ 3 files changed, 166 insertions(+)
+ create mode 100644 tests/http/test_16_info.py
+
+Index: curl-8.7.1/lib/transfer.c
+===
+--- curl-8.7.1.orig/lib/transfer.c
 curl-8.7.1/lib/transfer.c
+@@ -1221,6 +1221,9 @@ CURLcode Curl_xfer_send(struct Curl_easy
+ result = CURLE_OK;
+ *pnwritten = 0;
+   }
++  else if(!result && *pnwritten)
++data->info.request_size += *pnwritten;
++
+   return result;
+ }
+ 
+Index: curl-8.7.1/tests/http/test_16_info.py
+===
+--- /dev/null
 curl-8.7.1/tests/http/test_16_info.py
+@@ -0,0 +1,162 @@
++#!/usr/bin/env python3
++# -*- coding: utf-8 -*-
++#***
++#  _   _   _
++#  Project ___| | | |  _ \| |
++# / __| | | | |_) | |
++#| (__| |_| |  _ <| |___
++# \___|\___/|_| \_\_|
++#
++# Copyright (C) Daniel Stenberg, , et al.
++#
++# This software is licensed as described in the file COPYING, which
++# you should have received as part of this distribution. The terms
++# are also available at https://curl.se/docs/copyright.html.
++#
++# You may opt to use, copy, modify, merge, publish, distribute and/or sell
++# copies of the Software, and permit persons to whom the Software is
++# furnished to do so, under the terms of the COPYING file.
++#
++# This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
++# KIND, either express or implied.
++#
++# SPDX-License-Identifier: curl
++#
++#

Bug#1065348: chdist: perl warnings because of the deprecation of given ... when

[Antonio Terceiro]

On Sun, Mar 03, 2024 at 11:23:28AM +0100, Lucas Nussbaum wrote:
> Package: devscripts
> Version: 2.23.4+deb12u1
> Severity: normal
> Tags: patch
> 
> Hi,
> 
> $ chdist list
> given is deprecated at /usr/bin/chdist line 710.
> when is deprecated at /usr/bin/chdist line 711.
> when is deprecated at /usr/bin/chdist line 714.
> when is deprecated at /usr/bin/chdist line 717.
> when is deprecated at /usr/bin/chdist line 720.
> when is deprecated at /usr/bin/chdist line 723.
> when is deprecated at /usr/bin/chdist line 726.
> when is deprecated at /usr/bin/chdist line 729.
> when is deprecated at /usr/bin/chdist line 732.
> when is deprecated at /usr/bin/chdist line 735.
> when is deprecated at /usr/bin/chdist line 738.
> when is deprecated at /usr/bin/chdist line 741.
> when is deprecated at /usr/bin/chdist line 744.
> when is deprecated at /usr/bin/chdist line 747.
> when is deprecated at /usr/bin/chdist line 750.
> when is deprecated at /usr/bin/chdist line 753.
> when is deprecated at /usr/bin/chdist line 756.
> when is deprecated at /usr/bin/chdist line 759.
> when is deprecated at /usr/bin/chdist line 762.
> 
> Attached is a patch that switches to if...elsif instead.

You forgot the attachment. :-)


signature.asc
Description: PGP signature

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Antonio Terceiro]

On Tue, Mar 12, 2024 at 09:13:09PM +0100, Sebastian Andrzej Siewior wrote:
> tried with 1.50+nmu2 which is in deferred for the next 11h. So tomorrow
> it should be all good.

Please make sure to commit the patch to the pristine-tar git repository
as well.


signature.asc
Description: PGP signature

Bug#1065091: gtg: crashes on startup

[Antonio Terceiro]

Package: gtg
Version: 0.6-6
Severity: grave
Justification: renders package unusable

Dear Maintainer,

$ gtg
2024-02-29 14:44:05,373 - ERROR - application:do_activate:153 - Exception 
during activation
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/GTG/gtk/application.py", line 148, in 
do_activate
self.init_shared()
  File "/usr/lib/python3/dist-packages/GTG/gtk/application.py", line 229, in 
init_shared
self.init_plugin_engine()
  File "/usr/lib/python3/dist-packages/GTG/gtk/application.py", line 255, in 
init_plugin_engine
self.plugin_engine.activate_plugins()
  File "/usr/lib/python3/dist-packages/GTG/core/plugins/engine.py", line 199, 
in activate_plugins
plugin.active = True
^
  File "/usr/lib/python3/dist-packages/GTG/core/plugins/engine.py", line 78, in 
_set_active
self.instance = self.plugin_class()
^
AttributeError: 'Plugin' object has no attribute 'plugin_class'
2024-02-29 14:44:06,815 - INFO - errorhandler:handle_response:163 - Going to 
exit because either of fatal error or user choice
Aborted

Downgrading to 0.6-5 from snapshots makes it work again, so some change
in 0.6-6 broke it entirely.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.15-arm64 (SMP w/32 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.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 gtg depends on:
ii  gir1.2-gtk-3.0 [gir1.2-gdk-3.0]  3.24.41-1
ii  gir1.2-gtksource-4   4.8.4-5+b1
ii  gir1.2-pango-1.0 1.51.0+ds-4
ii  gir1.2-secret-1  0.21.2-1
ii  pdftk-java   3.3.3-2
ii  python3  3.11.6-1
ii  python3-caldav   0.11.0-2
ii  python3-cheetah  3.3.3-1
ii  python3-gi   3.47.0-3
ii  python3-gi-cairo 3.47.0-3
ii  python3-liblarch 3.2.0-3
ii  python3-lxml 5.1.0-1
ii  texlive-extra-utils  2023.20240207-1
ii  texlive-latex-base   2023.20240207-1

gtg recommends no packages.

gtg suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1059529: pybuild-autopkgtest: before-pybuild-autopkgtest target presence breaks autopkgtest

[Antonio Terceiro]

On Wed, Feb 28, 2024 at 10:51:31PM -0400, Stefano Rivera wrote:
> Hi Antonio,
> 
> Any thoughts on this bug?
> 
> It seems dh doesn't like our hacks...
> 
> > I have a package where I used a before-pybuild-autopkgtest in the
> > debian/rules file, but when I run autopkgtest, it fails with the error
> > message (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059334):
> > 
> > dh before-pybuild-autopkgtest --buildsystem=pybuild
> > dh: error: Unknown sequence before-pybuild-autopkgtest (choose from: binary 
> > binary-arch binary-indep build build-arch build-indep clean install 
> > install-arch install-indep)
> > make: *** [debian/rules:13: before-pybuild-autopkgtest] Error 25
> > pybuild-autopkgtest: error: /tmp/pJ8OcCInAE/run before-pybuild-autopkgtest 
> > returned exit code 2
> > 
> > That's clearly wrong!  It appears that that "%:" recipe overrides
> > every other recipe in debian/rules, and is called when "debian/rules
> > before-pybuild-autopkgtest" is called.  I don't know if there's any
> > way to override this behaviour.

This was a bug in the python-bytecode debian/rules at that point:

  40   │ before-pybuild-autopkgtest:
  41   │ ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
  42   │ ifeq ($(DEB_BUILD_ARCH),armhf)
  43   │ patch -p1 < debian/armhf.patch
  44   │ endif
  45   │ endif

when the ifeq's don't evaluate to true (what happens everywhere but on
armhf), the body of the `before-pybuild-autopkgtest` target is empty,
and this causes make to call the default (%) target, which then calls
`dh`.

This can be reproduced in the following minimal example:

8<8<8<-
$ cat Makefile
───┬───
   │ File: Makefile
───┼───
   1   │ %:
   2   │ @echo COMMON: $@
   3   │
   4   │ foo:
   5   │ @echo FOO
   6   │
   7   │ bar:
───┴───
$ make foo
FOO
$ make bar
COMMON: bar
8<8<8<-

This could have been fixed at the time by making the patching
unconditional, or by patching the test itself to cause a skip on armhf.


signature.asc
Description: PGP signature

Bug#1061620: autopkgtest: Ignores multiple comma-separated values in Testsuite

[Antonio Terceiro]

Control: forwarded -1 
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/33

On Sat, Jan 27, 2024 at 04:05:32PM +0100, Paul Gevers wrote:
> Hi,
> 
> On 27-01-2024 15:41, Paul Gevers wrote:
> > Indeed, autopkgtest doesn't look at d/control at all. Both
> > autopkgtest-pkg-python and autopkgtest-pkg-pybuild are things that
> > autodep8 deals with and it needs to do the right thing. Reassigning.
> 
> This seems to be problematic (note the "^" and "$" in the expression):
> 
> detect_by_control_field() {
>   local pkgtype="$1"
>   [ -f debian/control ] &&
> grep-dctrl --quiet \
> -F XS-Testsuite,Testsuite \
> -r "^autopkgtest-pkg-$packagetype\$" debian/control
> }
> 
> Paul

Fair enough. I have a proposed fix for this here:

https://salsa.debian.org/ci-team/autodep8/-/merge_requests/33


signature.asc
Description: PGP signature

Bug#1059840: please bump --ram-size for qemu

[Antonio Terceiro]

On Wed, Jan 03, 2024 at 07:32:34AM +0100, Paul Gevers wrote:
> Control: reassign -1 autopkgtest
> 
> Hi Michael,
> 
> On 02-01-2024 22:27, Michael Biebl wrote:
> > You raise an interesting point though by framing this as an autopkgtest
> > issue: Maybe the default in autopkgtest-virt-qemu should be bumped.
> > This value was set in 2014 and systems have significantly more RAM
> > nowadays. This way, one wouldn't have to remember to always pass
> > --ram-size= when running autopkgtest by hand.
> > A value of 2G or even 4G seems reasonable. WDYT?
> 
> I think that sound reasonable, but I don't know how to sufficiently judge
> this. Maybe my co-maintainers have ideas about it?

I think we can use use the smaller of [4GB, 50% of the host RAM], to
avoid killing a host where 4GB is more than what the host could
reasonably afford.


signature.asc
Description: PGP signature

Bug#1058937: /usr-move: Do we support upgrades without apt?

[Antonio Terceiro]

On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> ## Upgrading using dpkg directly?
> 
> We already have quite a number of packages that use Conflicts to prevent
> file loss in upgrades in a very similar way to #1058937 (Ben's
> libnfsidmap1 bug) even in released versions of Debian. For instance,
> dhcpcd-base's Replaces were upgraded to Conflicts, see #1053657. If you
> employ dpkg, you can still experience the problem there.
> 
> Is it ok to call upgrade scenarios failures that cannot be reproduced
> using apt unsupported until we no longer deal with aliasing?

I think so, yes. I don't think it's likely that there are people doing
upgrades on running systems not using apt.

If there are, they already need to deal with doing the dpkg calls in the
right order anyway -- basically doing the apt dependency resolution by
hand -- that this is just another corner case that they need to handle;
there could be already Conflicts in there for other reasons than
/usr-merge.


signature.asc
Description: PGP signature

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Fri, Nov 17, 2023 at 10:05:19AM +0100, Marcin Owsiany wrote:
> Antonio, https://salsa.debian.org/terceiro/textual is now a 404.
> Is your work available somwehere else?

No, by mistake I ended up not making it public in the first place. It's
public now.


signature.asc
Description: PGP signature

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Sat, Nov 04, 2023 at 10:38:32AM -0300, Antonio Terceiro wrote:
> On Fri, Nov 03, 2023 at 09:07:49PM -0300, Antonio Terceiro wrote:
> > On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> > > Package: python3-textual
> > > Severity: normal
> > > X-Debbugs-Cc: 
> > > 
> > > Dear maintainer,
> > > 
> > > The current version of python3-textual in Debian is quite out of date,
> > > and it's not possible to run newer textual apps with it anymore.,
> > > Please upgrade to the latest upstream version (currenly (0.40.0) so
> > > that this package can be useful again.
> > 
> > I have a textual locally updated to the latest upstream version:
> > https://salsa.debian.org/terceiro/textual
> > 
> > I had to disable a few tests due to either missing dependencies, of
> > mismatching expectations between the versions in Debian and the ones
> > assumed by upstream (poetry.lock). There is still some work to do, e.g.
> > converting the autopkgtest to use autopkgtest-pkg-pybuild.
> 
> This is now done.
> 
> BTW there is a new build dependency, python3-time-machine, which is in
> NEW right now:
> 
> https://salsa.debian.org/python-team/packages/python-time-machine

FWIW this package has passed NEW and is even already in testing.


signature.asc
Description: PGP signature

Bug#1055753: debci: --config option is broken

[Antonio Terceiro]

On Fri, Nov 10, 2023 at 06:18:33PM +0100, Christian Kastner wrote:
> Hi Antonio,
> 
> On 2023-11-10 18:10, Antonio Terceiro wrote:
> > Some shared options are defined in lib/environment.sh, I think that's
> > why it currently loads lib/environment.sh before processing the command
> > line options.
> > 
> > OTH your analysis is correct, as this causes the --config option to be
> > useless. A solution to this would be to break the common options into
> > their own file, include that in the scripts, call getopt, process
> > --config before anything else, then load lib/environment.sh for default
> > values, and only then process the rest of the options.
> 
> unless I'm misreading something badly, both default values *and* option
> processing are in lib/environment.sh -- it's just that getopt is called
> somewhat after some defaults have been set, like config_dir, arch, etc.
> 
> My gut says moving getopt to the top of lib/environment.sh would fix
> this, but its current position seemed like a deliberate choice, so I
> assumed I was missing something.

The currenty situation is more a product of oversight than of design.
I'm wiling to review any solution you come up with.


signature.asc
Description: PGP signature

Bug#1055753: debci: --config option is broken

[Antonio Terceiro]

On Fri, Nov 10, 2023 at 04:42:10PM +0100, Christian Kastner wrote:
> Package: debci
> Version: 3.7
> Severity: normal
> 
> The --config option to the debci subcommands does not work:
> 
> $ mkdir /tmp/foo
> $ echo 'debci_arch="i386"' > /tmp/foo/debci.conf
> 
> $ debci config --config /tmp/foo config_dir
> config_dir=/tmp/foo
> 
> $ debci config --config /tmp/foo arch
> arch=amd64
> 
> I believe that this is because it is processed too late.
> 
> It is first processed at the top lib/environment.sh, where it is used to read
> the config, and set important variables, like debci_arch above.
> 
> Only after this has happened, its getopt(1) called. And I believe that all 
> that
> --config does at that point, is to update debci_config_dir.
> 
> 
> In fact, I believe all of the option parsing should be moved to the very top,
> as least some other options are also broken this way:
> 
> $ echo 'debci_arch_list="arm64 i386"' >> /tmp/foo/debci.conf
> $ debci config --config /tmp/foo --arch=i386 arch
> arch=i386
> $ debci config --config /tmp/foo --arch=i386 arch_list
> arch_list=amd64
> 
> 
> I didn't want to file an MR outright, as I don't know the background behind 
> the
> current solution, and there might be a good reason for it.

Some shared options are defined in lib/environment.sh, I think that's
why it currently loads lib/environment.sh before processing the command
line options.

OTH your analysis is correct, as this causes the --config option to be
useless. A solution to this would be to break the common options into
their own file, include that in the scripts, call getopt, process
--config before anything else, then load lib/environment.sh for default
values, and only then process the rest of the options.


signature.asc
Description: PGP signature

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Fri, Nov 03, 2023 at 09:07:49PM -0300, Antonio Terceiro wrote:
> On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> > Package: python3-textual
> > Severity: normal
> > X-Debbugs-Cc: 
> > 
> > Dear maintainer,
> > 
> > The current version of python3-textual in Debian is quite out of date,
> > and it's not possible to run newer textual apps with it anymore.,
> > Please upgrade to the latest upstream version (currenly (0.40.0) so
> > that this package can be useful again.
> 
> I have a textual locally updated to the latest upstream version:
> https://salsa.debian.org/terceiro/textual
> 
> I had to disable a few tests due to either missing dependencies, of
> mismatching expectations between the versions in Debian and the ones
> assumed by upstream (poetry.lock). There is still some work to do, e.g.
> converting the autopkgtest to use autopkgtest-pkg-pybuild.

This is now done.

BTW there is a new build dependency, python3-time-machine, which is in
NEW right now:

https://salsa.debian.org/python-team/packages/python-time-machine


signature.asc
Description: PGP signature

Bug#1055032: Please update to latest upstream version

[Antonio Terceiro]

On Sun, Oct 29, 2023 at 09:29:04PM +0200, Jonathan Carter wrote:
> Package: python3-textual
> Severity: normal
> X-Debbugs-Cc: 
> 
> Dear maintainer,
> 
> The current version of python3-textual in Debian is quite out of date,
> and it's not possible to run newer textual apps with it anymore.,
> Please upgrade to the latest upstream version (currenly (0.40.0) so
> that this package can be useful again.

I have a textual locally updated to the latest upstream version:
https://salsa.debian.org/terceiro/textual

I had to disable a few tests due to either missing dependencies, of
mismatching expectations between the versions in Debian and the ones
assumed by upstream (poetry.lock). There is still some work to do, e.g.
converting the autopkgtest to use autopkgtest-pkg-pybuild.

Sandro, Would it be OK if I push that into the python team repo and
upload to the archive when I'm done?


signature.asc
Description: PGP signature

Bug#1054727: rails: FTBFS: build-dependency not installable: ruby-thin (>= 1.6.0)

[Antonio Terceiro]

Control: forcemerge 1054256 -1
Control affects 1054256 + src:rails

On Fri, Oct 27, 2023 at 09:27:35PM +0200, Lucas Nussbaum wrote:
> Source: rails
> Version: 2:6.1.7.3+dfsg-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231027 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > +--+
> > | Install package build dependencies
> >|
> > +--+
> > 
> > 
> > Setup apt archive
> > -
[...]
> > Install main build dependencies (apt-based resolver)
> > 
> > 
> > Installing build dependencies
> > Reading package lists...
> > Building dependency tree...
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > 
> > The following packages have unmet dependencies:
> >  ruby-blade : Depends: ruby-thin (>= 1.6.0) but it is not installable
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.

This is caused by an issue with ruby-blade (already reported)


signature.asc
Description: PGP signature

Bug#1054256: ruby-blade: uninstallable in unstable (ruby-blade : Depends: ruby-thin (>= 1.6.0) but it is not installable)

[Antonio Terceiro]

Package: ruby-blade
Version: 0.7.1-4
Severity: serious
Justification: uninstallable

After the last upload, ruby-blade ended up with a dependency on
ruby-thin, which does not exist.

8<8<8<-
$ LANG=C sudo apt install ruby-blade/unstable
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '0.7.1-4' (Debian:unstable [all]) for 'ruby-blade'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ruby-blade : Depends: ruby-thin (>= 1.6.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
8<8<8<-

The correct dependency would be on `thin`.

This is actually caused by a bug in gem2deb (unreported), which was not
finding the correct mapping between gem names and Debian package names
for architecture dependent packages. In any case, ruby-blade will need a
no changes upload to be rebuilt once gem2deb 2.2, just uploaded, is
available.

See 
https://salsa.debian.org/ruby-team/gem2deb/-/commit/827cb954c941872e24bb8f489d1a54cba416694b
for more details.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.5.0-1-arm64 (SMP w/32 CPU threads)
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 ruby-blade depends on:
ii  ruby  1:3.1
ii  ruby-activesupport2:6.1.7.3+dfsg-2
ii  ruby-blade-qunit-adapter  2.0.1-2
ii  ruby-curses   1.4.4-1+b2
ii  ruby-eventmachine 1.3~pre20220315-df4ab006-3+b1
ii  ruby-faye 1.4.0-1
ii  ruby-sprockets3.7.2-4
pn  ruby-thin 
ii  ruby-thor 1.2.2-1
ii  ruby-useragent0.16.8-1.1
ii  thin  1.8.1-2

ruby-blade recommends no packages.

ruby-blade suggests no packages.


signature.asc
Description: PGP signature

Bug#1051302: bookworm-pu: package jekyll/4.3.1+dfsg-3+deb12u1

[Antonio Terceiro]

On Sat, Sep 23, 2023 at 08:32:43PM +0100, Adam D. Barratt wrote:
> Control: tags -1 confirmed
> 
> This update fixes processing user configuration that used YAML
> > aliases.
> > 
> > [ Impact ]
> > User configuration with YAML aliases will cause jekyll to crash while
> > parsing it, and therefore jekyll will not work at all.
> > 
> 
> Please go ahead.

Uploaded.


signature.asc
Description: PGP signature

Bug#1051900: ohcount: aborts with segfaul or bus error 90% of the time on arm64

[Antonio Terceiro]

Package: ohcount
Version: 4.0.0-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-...@lists.debian.org

Dear Maintainer,

ohcount segfaults (and sometimes aborts with a Bus error) on arm64,
almost 90% of the time. I tried this on an up to date arm64 Debian
testing against the hexchat source code, but it's also reproducible on
the ohcount source code itself. The same test, when performced on an up
to date amd64 Debian testing, finishes successfully 100% of the time.

For example this is a sample session with 10 runs against the source of
ohcount itself:

$ ohcount
Examining 1192 file(s)
Segmentation fault
$ ohcount
Examining 1192 file(s)
Bus error
$ ohcount
Examining 1192 file(s)
Bus error
$ ohcount
Examining 1192 file(s)
Bus error
$ ohcount
Examining 1192 file(s)
Bus error
$ ohcount
Examining 1192 file(s)
Segmentation fault
$ ohcount
Examining 1192 file(s)
Segmentation fault
$ ohcount
Examining 1192 file(s)
Segmentation fault
$ ohcount
Examining 1192 file(s)
Segmentation fault
$ ohcount
Examining 1192 file(s)
Bus error

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.4.0-3-arm64 (SMP w/32 CPU threads)
Kernel taint flags: 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 ohcount depends on:
ii  file   1:5.45-2
ii  libc6  2.37-7
ii  libmagic1  1:5.45-2
ii  libpcre3   2:8.39-15
ii  ruby   1:3.1
ii  ruby-diff-lcs  1.5.0-1

ohcount recommends no packages.

Versions of packages ohcount suggests:
pn  ohcount-doc  

-- no debconf information


signature.asc
Description: PGP signature

Bug#1050867: marked as pending in jekyll

[Antonio Terceiro]

On Fri, Sep 01, 2023 at 05:25:38PM +0200, Sébastien Villemot wrote:
> Hi Antonio,
> 
> Le mercredi 30 août 2023 à 15:33 +, Antonio Terceiro a écrit :
> > Bug #1050867 in jekyll reported by you has been fixed in the
> > Git repository and is awaiting an upload. You can see the commit
> > message below and you can check the diff of the fix at:
> > 
> > https://salsa.debian.org/ruby-team/jekyll/-/commit/78d57aff39390464d023660c55803806b6b7f06f
> > 
> > 
> > Allow YAML aliases
> > 
> > Closes: #1050867
> > 
> 
> Thanks for swiftly fixing this issue!
> 
> Shouldn’t the fix be backported to bookworm?

yes. I just submitted a stable update bug about it (#1051302)


signature.asc
Description: PGP signature

Bug#1051302: bookworm-pu: package jekyll/4.3.1+dfsg-3+deb12u1

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jek...@packages.debian.org
Control: affects -1 + src:jekyll

[ Reason ]
This update fixes processing user configuration that used YAML aliases.

[ Impact ]
User configuration with YAML aliases will cause jekyll to crash while
parsing it, and therefore jekyll will not work at all.

[ Tests ]
The change is trivial, and is already present in testing.

[ Risks ]
No risks.

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

[ Changes ]
The only change is passing an extra parameter to Psych.safe_load,
telling it to allow aliases in the YAML data.

[ Other info ]
n/a
diff --git a/debian/changelog b/debian/changelog
index b91ea6e..7ba5630 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+jekyll (4.3.1+dfsg-3+deb12u1) bookworm; urgency=medium
+
+  [ Sébastien Villemot ]
+  * Allow YAML aliases (Closes: #1050867)
+
+ -- Antonio Terceiro   Tue, 05 Sep 2023 19:37:14 -0300
+
 jekyll (4.3.1+dfsg-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/0016-Drop-usage-of-safe_yaml.patch b/debian/patches/0016-Drop-usage-of-safe_yaml.patch
index 90aa06e..6caae5d 100644
--- a/debian/patches/0016-Drop-usage-of-safe_yaml.patch
+++ b/debian/patches/0016-Drop-usage-of-safe_yaml.patch
@@ -1,6 +1,9 @@
 From: Antonio Terceiro 
 Date: Sat, 21 Jan 2023 23:25:30 -0300
 Subject: Drop usage of safe_yaml
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
 
 Squashed commit of the following:
 
@@ -22,6 +25,12 @@ Date:   Thu Aug 19 13:42:39 2021 -0300
 
 Use Psych as YAML parser
 
+commit 5afe0f5acbc4cb9880bd2c752f45f39ba4f62835
+Author: Sébastien Villemot 
+Date: Wed, 30 Aug 2023 11:35:36 -0300
+
+Enable YAML aliases
+
 Source: https://github.com/jekyll/jekyll/pull/8772
 Additional changes:
   - Also make the replacement of SafeYAML in lib/jekyll/commands/serve.rb
@@ -193,7 +202,7 @@ index d6c5a0b..3757e04 100644
  
Jekyll.logger.info "Theme Config file:", theme_config_file
 diff --git a/lib/jekyll/utils.rb b/lib/jekyll/utils.rb
-index 2a96527..0dfe2ec 100644
+index 2a96527..252541f 100644
 --- a/lib/jekyll/utils.rb
 +++ b/lib/jekyll/utils.rb
 @@ -316,6 +316,20 @@ module Jekyll
@@ -202,7 +211,7 @@ index 2a96527..0dfe2ec 100644
  
 +# Safely load YAML strings
 +def safe_load_yaml(yaml)
-+  Psych.safe_load(yaml, :permitted_classes => [Date, Time])
++  Psych.safe_load(yaml, :permitted_classes => [Date, Time], aliases: true)
 +rescue ArgumentError
 +  # Psych versions < 3.1 had a different safe_load API and used
 +  # problematic language.


signature.asc
Description: PGP signature

Bug#1051206: auto-apt-proxy: Optional support for mDNS

[Antonio Terceiro]

On Mon, Sep 04, 2023 at 11:42:35PM +1000, James Tocknell wrote:
> Package: auto-apt-proxy
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Would you be open to adding optional support (i.e. at the suggests level) for
> mDNS via avahi-browse (or similar mDNS scanning command)? I'd be happy to
> produce a patch if interested.

Sure.


signature.asc
Description: PGP signature

Bug#1050256: autopkgtest fails on debci

[Antonio Terceiro]

On Fri, Sep 01, 2023 at 11:13:11PM +, Mathias Gibbens wrote:
> Control: block 1038315 by -1
> Control: block 1042880 by -1
> 
>   I don't think we have a good understanding of the root cause of this
> issue. Initially we thought this was a known upstream issue with all-
> but very recent versions of apparmor and a corresponding lxc profile
> fix [0]. However, it appears this is a different issue that somehow
> depends on the interaction of bookworm's versions of the kernel,
> apparmor, and/or lxc.
> 
>   A minimal reproducer is to install bookworm and create a container
> with a systemd service using a hardening option like
> PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the
> service will fail. But, grab a kernel from testing (6.4.11-1) and then
> things work -- with no other changes required. I tried the "oldest"
> kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the
> service works properly with that version as well. So, something changed
> in the kernel (either upstream or in Debian's packaging) between 6.1
> and 6.3 that "unbreaks" services within lxc containers.
> 
>   Given that simply installing a newer kernel fixes things, I am
> hesitant to start making changes to lxc until we actually understand
> what's changed when running the newer kernel and how it's affecting
> lxc's behavior.

Thanks for the investigation. This led to think of something that would
work around this issue, but maybe has bigger consequences.

I'm wondering whether we should, as a policy, run backports kernels on
the ci.debian.net workers. Given the most important use case is testing
testing¹, having a kernel that is closest to the one in testing might
make sense.

¹ pun intended

Of course, this does not prevents having QEMU workers, and I want to
provide that at some point. But since we won't be able to have QEMU for
all architectures, anyway, I still think running backports kernels in
the lxc workers might be a valid strategy.


signature.asc
Description: PGP signature

Bug#1050462: gtg: crashes on startup often

[Antonio Terceiro]

On Fri, Aug 25, 2023 at 08:52:49PM +0200, François Mazen wrote:
> Dear Antonio,
> 
> thanks for the crash report! I can reproduce it easily with unstable
> distribution and the call stack points to pango_font_description_to_string
> method.
> 
> The issues seems to have been already reported upstream [1] and the suggested
> worj around is to add "font_name = Sans 11" in the [browser] section of the
> ~/.config/gtg/gtg.conf config file.

Thanks, this indeed seem to work around the issue.

> I've checked the fix and no more crash occurs, so it could be integrated as a
> quilt patch for the Debian package.

We probably want to fix the code to *not* segfault when the workaround
is not in place. I'm not sure whether this is a bug in gtg itself, or
in pango.


signature.asc
Description: PGP signature

Bug#1050462: gtg: crashes on startup often

[Antonio Terceiro]

Package: gtg
Version: 0.6-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

gtg crashes on startup very often.

~$ gtg
2023-08-24 14:38:12,928 - WARNING - adaptive_button:do_forall:279 - Got error 
in for but it should've stay valid: AttributeError("'AdaptiveFittingWidget' 
object has no attribute '_children'")
~$ gtg
2023-08-24 14:38:17,288 - WARNING - adaptive_button:do_forall:279 - Got error 
in for but it should've stay valid: AttributeError("'AdaptiveFittingWidget' 
object has no attribute '_children'")
~$ gtg
Segmentation fault
~[139]$ gtg
2023-08-24 14:38:25,240 - WARNING - adaptive_button:do_forall:279 - Got error 
in for but it should've stay valid: AttributeError("'AdaptiveFittingWidget' 
object has no attribute '_children'")
~$ gtg
Segmentation fault
~[139]$ gtg
Segmentation fault
~[139]$ gtg
2023-08-24 14:38:40,377 - WARNING - adaptive_button:do_forall:279 - Got error 
in for but it should've stay valid: AttributeError("'AdaptiveFittingWidget' 
object has no attribute '_children'")

I can reproduce this issue:

- on both arm64 and amd64 systems, running testing;
- with or without wiping out ~/.local/share/gtg/ before each attempt at
  starting it.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.5.0-0-arm64 (SMP w/32 CPU threads)
Kernel taint flags: 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 gtg depends on:
ii  gir1.2-gtk-3.0 [gir1.2-gdk-3.0]  3.24.38-2
ii  gir1.2-gtksource-4   4.8.4-4
ii  gir1.2-pango-1.0 1.51.0+ds-2
ii  gir1.2-secret-1  0.21.0-1
ii  pdftk-java   3.3.3-1
ii  python3  3.11.4-5+b1
ii  python3-caldav   0.11.0-1
ii  python3-cheetah  3.3.2-1
ii  python3-gi   3.44.1-2
ii  python3-gi-cairo 3.44.1-2
ii  python3-liblarch 3.2.0-3
ii  python3-lxml 4.9.3-1
ii  texlive-extra-utils  2022.20230122-4
ii  texlive-latex-base   2022.20230122-3

gtg recommends no packages.

gtg suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1050453: gtg: superfluous dependency on texlive-extra-utils

[Antonio Terceiro]

Package: gtg
Version: 0.6-4
Severity: minor

Dear Maintainer,

The gtg README says it needs pdflatex, and for that the Debian package
depends on texlive-extra-utils. However, on a current testing system,
the pdflatex binary is provided by texlive-latex-base.

$ dpkg -S bin/pdflatex
texlive-extra-utils: /usr/bin/pdflatexpicscale
texlive-latex-extra: /usr/bin/pdflatex-dev
texlive-latex-base: /usr/bin/pdflatex

So I think we could avoid the ~75MB of texlive-extra-utils when
installing gtg.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.5.0-0-arm64 (SMP w/32 CPU threads)
Kernel taint flags: 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 gtg depends on:
ii  gir1.2-gtk-3.0 [gir1.2-gdk-3.0]  3.24.38-2
ii  gir1.2-gtksource-4   4.8.4-4
ii  gir1.2-pango-1.0 1.51.0+ds-2
ii  gir1.2-secret-1  0.21.0-1
ii  pdftk-java   3.3.3-1
ii  python3  3.11.4-5+b1
ii  python3-caldav   0.11.0-1
ii  python3-cheetah  3.3.2-1
ii  python3-gi   3.44.1-2
ii  python3-gi-cairo 3.44.1-2
ii  python3-liblarch 3.2.0-3
ii  python3-lxml 4.9.3-1
ii  texlive-extra-utils  2022.20230122-4
ii  texlive-latex-base   2022.20230122-3

gtg recommends no packages.

gtg suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Antonio Terceiro]

On Thu, Aug 24, 2023 at 01:46:11AM +0200, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2023-08-18 at 08:07:44 -0300, Antonio Terceiro wrote:
> > FWIW, I have been maintaining vagrant in Debian for several years.
> 
> BTW, thank you for having done that, it's been much appreciated!
> 
> > TL;DR: I will not be maintaining vagrant anymore.
> 
> > On Fri, Aug 18, 2023 at 02:56:28PM +0900, Kentaro HAYASHI wrote:
> > > * What was the outcome of this action?
> 
> > > Plan A.
> […]
> 
> > > Plan B.
> […]
> 
> > On Fri, Aug 18, 2023 at 09:37:54AM +, gwili.stif...@easymailer.live 
> > wrote:
> > > Plan C.
> […]
> 
> There's perhaps a:
> 
> Plan D.
> 
> - Package Vagrunt (https://github.com/vaagrunt/vagrunt) a fork of
>   Vagrant, that is stated should remain free software. And as it does
>   not have a CLA, if it gets several contributions it will be
>   increasingly hard to relicense.
> - Transition from vagrant to vagrunt via a transitional package.
> 
> (We use Vagrant at work, and I'm not planning on relying on a non-free
> tool, so a fork would do, otherwise I'd have to look into alternatives
> for us to switch to.)

I have seen this a couple of days ago.

So far vagrunt is vaporware. The GitHub user which created has -- as far
as I looked, i.e. on GitHub itself -- 0 contributions to Ruby projects.
I'm also not confident that it will be easy to keep up with e.g. new
VirtualBox versions without effectively infringing on HashiCorp
copyrights.

I will love to be proven wrong, but I'm not holding my breath here.


signature.asc
Description: PGP signature

Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Antonio Terceiro]

On Sat, Aug 19, 2023 at 06:46:06AM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> This license change is so disappointing...
> 
> On 18/08/23 at 08:07 -0300, Antonio Terceiro wrote:
> > > Plan B.
> > > 
> > > - Drop vagrant because of that changed licence and no need to
> > >   keep older vagrant.
> > > - No vagrant avaiable in Debian. Just use upstream's package.
> > 
> > I think keeping a stale version of vagrant in the archive is worse than
> > telling people to just use upstream packages.
> 
> A follow-up question, especially in the case of Plan B, is: what do we
> do about Debian Vagrant images provided on Vagrant Cloud
> (https://app.vagrantup.com/debian/) ?
> 
> A/ continue to maintain them. But as the main uploader of those images
>in the recent times, I might not continue to maintain them, especially
>if I move to another tool for my own uses, so we might need to look
>for other volunteers.
> B/ stop maintaining them
>B.1/ ... and remove existing images from the 'debian' Vagrant Cloud
>account
>B.2/ ... and leave the 'debian' Vagrant Cloud account as it is
>currently
> 
> I don't think B.2 is a good idea.

I agree. Just as we provide cloud images for proprietary platforms, I
think we as a project want to control what is available as "Debian" for
Vagrant users, just like we do with images targetted at proprietary
cloud platforms.

> > Hopefully, being burned a second time will teach me to not put my
> > volunteer time in non-copyleft packages provided by a single
> > corporation.
> 
> Note that the fact that Vagrant was using a non-copyleft license is not
> entirely relevant. The same relicensing could be achieved by
> organizations using a copyleft licence with a copyright transfer
> agreement for external contributions. (I suspect that this is how it was
> achieved for other Hashicorp products, but I haven't checked).

Yes, that's true.


signature.asc
Description: PGP signature

Bug#1049999: vagrant: the future of packaging vagrant in Debian

[Antonio Terceiro]

Hi,

FWIW, I have been maintaining vagrant in Debian for several years. Thank
you for raising this as I have been too lazy to push this discussion.

I am copying the Debian Ruby team plus all the people that I could find
listed as maintainer or uploader of vagrant related packages (mostly
plugins, vagrant-*, but also other related packages) so that they are
aware.

TL;DR: I will not be maintaining vagrant anymore.

On Fri, Aug 18, 2023 at 02:56:28PM +0900, Kentaro HAYASHI wrote:
> Package: vagrant
> Version: 2.3.4+dfsg-1
> Severity: normal
> X-Debbugs-Cc: ken...@xdump.org
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> 
> HashiCorp adopts the BSL.
> 
> https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-adopts-
> business-source-license-future-releases-its

This is the second time a package to which I dedicated extensive amount
of my time is made effectively non-free by its corporate upstream.

The first time was with Chef: while the license itself was not changed,
they started imposing trademark-related requirements that would impose a
large amount of busywork to keep something that looks like Chef (Cinc,
their "community" fork) in Debian. I decided to just give up, and moved
on to using something else.

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

This is now my second time with this, and this time HashiCorp actually
made new versions of vagrant non-free.

I have used Chef Inc and HashiCorp stuff for free for several years, but
I also put in a large amount of work to make their tools available
trivially to Debian users by taking care of those packages in the Debian
archive.

Both Chef Inc and HashiCorp care a lot about having people that use
Debian consuming their products, so much so that they provide binary
packages for Debian. But they don't care at all about the time of
downstream maintainers, and why would they? They are private companies
trying to maximize their profit at the expense of whoever is in their
way. In this case, HashiCorp is apparently trying to counter other
companies who are selling solutions based on their tools that compete
with them, they have no incentive to care about the time of a few
individuals.

I don't see this change as a particularly evil move, but it effectively
destroys my motivation to continue working on it.

> Currently, vagrant 2.3.4+dfsg-1 was packaged in debian.
> 
> * What exactly did you do (or not do) that was effective (or
>   ineffective)?
> 
> Should we keep non-BSL licenced version (A) or drop it (B)?
> 
> * What was the outcome of this action?
> 
> Plan A.
> 
> - Update to 2.3.7 and hold it. (2.3.7 is the last non-BSL licenced
>   version)
> - Follow a newer version only when BSL limitation expired (4 years).
> - As a result, we can't use newer feature in timely manner if you stick
>   on packaged vagrant in Debian.

I had already looked into this, even before the relicensing being
announced, and it turns out that vagrant 2.3.7 has a few extra
dependencies that would need to be packaged too (something like 3 or 4
NEW packages), and I wasn't ready to put the necessary work in yet.

After the news came out, I gave up on doing it entirely, since after
this vagrant would be a dead end.

> Plan B.
> 
> - Drop vagrant because of that changed licence and no need to
>   keep older vagrant.
> - No vagrant avaiable in Debian. Just use upstream's package.

I think keeping a stale version of vagrant in the archive is worse than
telling people to just use upstream packages.

As far as my volunteer time is concerned, this is the most likely
outcome. I have some private notes on my requirements for a vagrant
replacement, and when I reach a conclusion I will most probably pursue
this path and just move on.

On Fri, Aug 18, 2023 at 09:37:54AM +, gwili.stif...@easymailer.live wrote:
> Source: vagrant
> Followup-For: Bug #104
> 
> Plan C.
> 
> - Move BSL-licenced versions of vagrant into debian's non-free section.

I will not maintain any packages in non-free.

Hopefully, being burned a second time will teach me to not put my
volunteer time in non-copyleft packages provided by a single
corporation.


signature.asc
Description: PGP signature

Bug#1043543: autopkgtest: /usr/share/autopkgtest/lib/__pycache__ is not managed

[Antonio Terceiro]

On Sat, Aug 12, 2023 at 09:07:44PM +0200, Alexandre Detiste wrote:
> Le sam. 12 août 2023 à 20:16, Paul Gevers  a écrit :
> >
> > Call me innocent, but I'm not even seeing cache files on my system for
> > the recent python. When are these files created?
> >
> > Paul
> 
> I think I just ran autopkgtest once, as root, on this day at 2am...
> I think I should sleep more.
> 
> So they are created anytime a user with write access to
> /usr/share/autopkgtest/lib
> run autopkgtest, which means root.
> 
> dh_python3 would add the calls to py3compile/py3clean,
> but might have other side effects for your package that have to be
> backportable to oldstable(?not sure) so you might consider calling
> py3{compile/clean} directly.

I think the correct fix for this is to turn autopkgtest into a "proper"
Python package, so that we can just use dh-python instead of the custom
build system, and all of this will be taken care of.

I have thought a few times about starting this, but I haven't had the
spoons to actually do it yet.


signature.asc
Description: PGP signature

Bug#1038139: debci-worker: Process leaks authentication data via amqp-tools

[Antonio Terceiro]

On Thu, Jun 15, 2023 at 10:48:57PM +0200, Christian Kastner wrote:
> 
> Package: debci
> Version: 3.6
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Hi,
> 
> When using authentication in AMQP connections, the username and password
> supplied in the --url option to amqp-consume resp. amqp-publish are
> exposed in the proces list, see #1037322:
> 
>   $ pgrep -a ampq-consume
>   62287 amqp-consume --url amqp://user:pass@192.168.0.1 --queue=myqueue
> 
> A patch has been accepted upstream to read the username and password
> from a file. I assume this will make its way into ampq-tools soon.
> 
> Unless I'm mistaken, debci will need to be updated for this, e.g. by
> adding a debci_amqp_pwfile config option + NEWS entry suggesting that
> people migrate to this new option. I'd be happy to file an MR for this,
> once ampq-tools has been fixed.

Note that the variable where you inserted a username and password is
calle debci_amqp_server, and was never supposed to be used for putting a
password in plain text. For the c.d.n deployment we use SSL client
certificates for authentication, and that's why the variables
debci_amqp_cacert, debci_amqp_cert, debci_amqp_key are there.

IMO that is no different from any other program that takes a url as a
command line parameter: you can pass a URL containing a username and
password, but then that's on you.


signature.asc
Description: PGP signature

Bug#1037499: RM: django-testproject -- ROM; obsolete, unmaintained

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: django-testproj...@packages.debian.org
Control: affects -1 + src:django-testproject

Please remove src:django-testproject. Is not maintained anymore, and
is not used by anything in the archive.


signature.asc
Description: PGP signature

Bug#1031105: unshared debootstrap fails if auto-apt-proxy is installed

[Antonio Terceiro]

On Sat, 11 Feb 2023 21:12:33 +0100 Johannes Schauer Marin Rodrigues 
 wrote:
> Package: debootstrap
> Version: 1.0.128+nmu2
> Severity: normal
> X-Debbugs-Cc: terce...@debian.org
> Control: affects -1 auto-apt-proxy mmdebstrap
> 
> Hi,
> 
> currently the mmdebstrap autopkgtest in experimental fails because debootstrap
> cannot be run with the user namespace unshared if auto-apt-proxy is installed
> and /tmp/.auto-apt-proxy-0 exists. Steps to reproduce:
> 
> $ mmdebstrap --variant=custom --mode=unshare --setup-hook='env container=lxc 
> debootstrap unstable "$1" http://127.0.0.1/debian' /dev/null
> 
> The error message is:
> 
> E: insecure cache dir /tmp/.auto-apt-proxy-0. Must be owned by UID 0 and have 
> permissions 700
> 
> The reason for this error is, that debootstrap will run auto-apt-proxy which
> will find that /tmp/.auto-apt-proxy-0 exists but since the user namespace of
> the process is unshared, it will be owned by user "nobody" from its
> perspective.
> 
> Please provide a way to allow disabling running auto-apt-proxy when running
> debootstrap.

Maybe I am missing something, but debootstrap has no knowledge about
auto-apt-proxy, why would debootstrap be the one responsible for
disabling auto-apt-proxy? Shouldn't mmdebstrap setup a reasonable
(empty) /tmp since it's the one who is setting up the unshared user
namespace?


signature.asc
Description: PGP signature

Bug#1035568: dnsmasq is broken on new bookworm installations

[Antonio Terceiro]

Control: severity -1 normal

On Fri, 05 May 2023 15:17:37 + =?utf-8?q?Jens_Mei=C3=9Fner?= 
 wrote:
> Package: dnsmasq
> Version: 2.89-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: heptal...@gmx.de
> 
> Hello,
> 
> dnsmasq on bookworm fails to start after installation because the dns port 53 
> is already is use by systemd-resolved.
> After stopping systemd-resolved dnsmasq will start but refuses all dns 
> queries with the Extended DNS Error Code 14 "Not Ready".
> This error is reproducible on new installation.
> 
> Setting severity to grave because it affects clean installs. 

This is a bug that needs fixing, for sure. But systemd-resolved is
installed by default only on the cloud images, and not on all Debian
installs. Therefore this does not really affect all users, and grave
severity does not apply.

Enabling (uncommenting) the `bind-interfaces` in /etc/dnsmasq.conf fixes
the issue on my tests, and maybe that should be set by default.


signature.asc
Description: PGP signature

Bug#1034497: unblock: jekyll/4.3.1+dfsg-2

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jek...@packages.debian.org
Control: affects -1 + src:jekyll

Please unblock package jekyll

[ Reason ]
Fix for test failure on some timezones

[ Impact ]
This has no effect on end users

[ Tests ]
All tests pass both during build and under autopkgtest

[ Risks ]
Trivial change

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
n/a

unblock jekyll/4.3.1+dfsg-2
diff --git a/debian/changelog b/debian/changelog
index dbecdf8..b91ea6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+jekyll (4.3.1+dfsg-2) unstable; urgency=medium
+
+  * Team upload
+  * debian/ruby-tests.rake: always run tests under TZ=UTC (Closes: #1034450)
+
+ -- Antonio Terceiro   Sun, 16 Apr 2023 18:35:56 -0300
+
 jekyll (4.3.1+dfsg-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/ruby-tests.rake b/debian/ruby-tests.rake
index e926490..26eeaf2 100644
--- a/debian/ruby-tests.rake
+++ b/debian/ruby-tests.rake
@@ -8,6 +8,8 @@ exclude = %w[
   test/test_win_tz.rb
 ]
 
+ENV["TZ"] = "UTC"
+
 Gem2Deb::Rake::TestTask.new(:test) do |t|
   t.libs << 'lib' << 'test'
   if ENV['AUTOPKGTEST_TEST_NEW_COMMAND']


signature.asc
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Sun, Apr 02, 2023 at 05:44:37PM +0200, Francesco Poli wrote:
> On Sun, 2 Apr 2023 09:42:54 -0300 Antonio Terceiro wrote:
> 
> > On Sat, Apr 01, 2023 at 08:28:28PM +0200, Francesco Poli wrote:
> [...]
> > > Hi Antonio,
> > > is there a better alternative SOAP client library for Ruby in Debian?
> [...]
> > I have no idea, I never worked on anything that needed to support SOAP,
> > except the occasional patch for apt-listbugs itself. savon looks more
> > active, having a release last December. But maybe just updating soap4r
> > based on that fork (which seems abandoned in 2018) is good enough? I
> > don't know.
> 
> Antonio,
> do you think it makes sense, if I reassign the bug report to
> ruby-soap4r?
> 
> The circumstantial evidence collected during the investigation that you
> and Vincent have carried out seems to suggest that the issue is
> probably due to ruby-soap4r, although we do not have conclusive
> evidence...
> 
> Having the bug report reassigned to ruby-soap4r may serve as a reminder
> to try to update the Debian package to a more active (or a less-long
> abandoned!) fork of soap4r. Not now, of course, but after bookworm
> has been released.

I'm also not sure whether soap4r is definitively the origin of the bug.
I also don't think that moving the bug around is going to be of any
help.


signature.asc
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Sat, Apr 01, 2023 at 08:28:28PM +0200, Francesco Poli wrote:
> On Wed, 29 Mar 2023 14:25:23 -0300 Antonio Terceiro wrote:
> 
> > On Wed, Mar 29, 2023 at 03:40:21AM +0200, Vincent Lefevre wrote:
> > > On 2023-03-28 20:37:56 -0300, Antonio Terceiro wrote:
> > > > Still, I see no evidence that this is caused by the Ruby interpreter.
> > > > For example apt-listbugs uses a SOAP library that is severely
> > > > unmaintained upstream and has been on life support for some time now.
> [...]
> 
> Hi Antonio,
> is there a better alternative SOAP client library for Ruby in Debian?
> 
> Searching [the] [web], I've seen some people recommending [Savon], but I
> cannot find it in Debian, not even in an ITP or RFP bug report...
> 
> [the]: 
> <https://stackoverflow.com/questions/40273/whats-the-best-way-to-use-soap-with-ruby>
> [web]: 
> <https://medium.com/@victoria.huang/setting-up-a-ruby-soap-client-2237fc46170a>
> [Savon]: <https://www.savonrb.com/>
> 
> Any other alternative?
> 
> More maintained forks of ruby-soap4r?
> Maybe [rubyjedi's fork], but that is also not too alive (last commit in
> 2018...).
> 
> [rubyjedi's fork]: <https://github.com/rubyjedi/soap4r>

I have no idea, I never worked on anything that needed to support SOAP,
except the occasional patch for apt-listbugs itself. savon looks more
active, having a release last December. But maybe just updating soap4r
based on that fork (which seems abandoned in 2018) is good enough? I
don't know.


signature.asc
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Wed, Mar 29, 2023 at 03:40:21AM +0200, Vincent Lefevre wrote:
> On 2023-03-28 20:37:56 -0300, Antonio Terceiro wrote:
> > Still, I see no evidence that this is caused by the Ruby interpreter.
> > For example apt-listbugs uses a SOAP library that is severely
> > unmaintained upstream and has been on life support for some time now. It
> > could be that library that is doing crazy things when the server does
> > not reply in exactly the way it expects.
> 
> Note that in both failures, a line of the source, e.g.
> 
>   /usr/lib/ruby/3.0.0/uri/generic.rb
> 
> or
> 
>   /usr/lib/ruby/3.0.0/bundler/vendor/uri/lib/uri/generic.rb
> 
> for "  # returns password\n" in my case in 2022, and
> 
>   /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb
> 
> for "if /proxy_detect='(.*)'/ =~ `apt-config \#{@apt_conf} shell 
> proxy_detect acquire::http::proxy-auto-detect`\n"
> in the other case a few days ago, is regarded by the Ruby interpreter
> as a String. Has any .rb library, even if severely buggy, the power
> to do that?

From what I can tell, the only dependency of apt-listbugs that calls
\.default on anything is ruby-soap4r:

/usr/share/rubygems-integration/all/gems/soap4r-ruby1.9-2.0.5/lib/soap/mapping/factory.rb
344-  return nil
345-end
346:if !obj.default.nil? or
347-(obj.respond_to?(:default_proc) and obj.default_proc)
348-  return nil

/usr/share/rubygems-integration/all/gems/soap4r-ruby1.9-2.0.5/lib/soap/mapping/rubytypeFactory.rb
114-param.add("item", elem)
115-  end
116:  param.add('default', Mapping._obj2soap(obj.default, map))
117-  addiv2soapattr(param, obj, map)
118-when ::Regexp
--
300-  end
301-  if node.key?('default')
302:obj.default = Mapping._soap2obj(node['default'], map)
303-  end
304-when TYPE_REGEXP

One think that could be happening is that soap4r is being fooled into
opening local files and that is triggered by some (corrupt?) response
from the server.

If anyone can still see this bug, it would be nice to configure
apt-listbugs in debug mode, e.g. setting

DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs -d apt";};

in /etc/apt/apt.conf.d/10apt-listbugs (i.e. adding the `-d` option), so
that when it happens we have a trace of the requests/reponses.

> Otherwise, could it be that apt-listbugs invokes the `default' method
> of some object obtained by SOAP, but this would mean that the server
> sends some part of .rb code as a String object in some cases? (This
> seems rather unlikely, and that could imply a security issue on the
> client side, if the client doesn't check what it receives.)

This is unlikely since debbugs is written in Perl. There is probably not
even Ruby installed in the server.

> IMHO, this looks like some kind of pointer corruption.

Could be this as well.


signature.asc
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Tue, Mar 28, 2023 at 09:26:29PM +0200, Vincent Lefevre wrote:
> On 2023-03-28 15:20:17 -0300, Antonio Terceiro wrote:
> > I'm sorry but this bug report assumes an unsupported configuration:
> > 
> > >  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > > 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
> > > (1, 'experimental')
> > 
> > This is not supportable at all.
> 
> Why not? Anyway, I doubt that this is related to the issue: packages
> appear in unstable first, so that "testing" and "stable" should have
> no effect in normal time.
> 
> > Plus:
> > 
> > > Versions of packages apt-listbugs depends on:
> > [...]
> > > ii  ruby1:3.0+1
> > 
> > Ruby 3.0, which is explicitly mentioned in the bug report as being used,
> > was just temporarily in bookworm as an intermediate step between 2.7
> > (bullseye) and 3.1 which is the version that is actually to be released
> > with bookworm.
> 
> But at some point (when I reported the bug), it was in unstable.
> See https://tracker.debian.org/pkg/ruby-defaults
> 
> [2022-09-20] Accepted ruby-defaults 1:3.0+3.1 (source) into unstable (Antonio 
> Terceiro)
> [2022-05-01] Accepted ruby-defaults 1:3.0+2 (source) into experimental 
> (Antonio Terceiro)
> [2022-03-10] ruby-defaults 1:3.0+1 MIGRATED to testing (Debian testing watch)
> [2022-03-07] Accepted ruby-defaults 1:3.0+1 (source) into unstable (Lucas 
> Kanashiro)
> 
> I had ruby 1:3.0+1 because it got into unstable on 2022-03-07.

Fair enough. I missed the date of the original bug report, I'm sorry
about that.

Still, I see no evidence that this is caused by the Ruby interpreter.
For example apt-listbugs uses a SOAP library that is severely
unmaintained upstream and has been on life support for some time now. It
could be that library that is doing crazy things when the server does
not reply in exactly the way it expects.


signature.asc
Description: PGP signature

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

Control: reassign -1 apt-listbugs

On Tue, Mar 28, 2023 at 06:39:35PM +0200, Francesco Poli wrote:
> Control: reassign -1 ruby 1:3.0+1
> Control: affects -1 + apt-listbugs
> 
> 
> On Fri, 24 Mar 2023 00:40:41 +0100 Francesco Poli wrote:
> 
> [...]
> > What you saw seems to be another case where some text from the source
> > (a line taken from /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb, in
> > this instance) is treated as a String by the Ruby interpreter and its
> > `default' method is invoked. But the String class has no `default'
> > method, which causes the error.
> > 
> > This seems to happen sporadically and cannot be easily reproduced.
> > 
> > I cannot understand what's going on.
> > I am more and more persuaded that this bug report should be reassigned
> > to another package (probably package ruby), in order to ask for an
> > investigation by people more knowledgeable than me...
> 
> 
> Dear Debian Ruby Team,
> I am reassigning this [bug] to package ruby, since a couple of users
> are experiencing awkward and sporadic behaviors that I really cannot
> understand and do not seem due to the code of apt-listbugs or of the
> libraries.
> 
> [bug]: 
> 
> Could you please investigate these sporadic issues?
> Refer to the [bug] log for more detailed information.
> 
> Thanks for your time and dedication!

I'm sorry but this bug report assumes an unsupported configuration:

>  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
> 'experimental')

This is not supportable at all.

Plus:

> Versions of packages apt-listbugs depends on:
[...]
> ii  ruby1:3.0+1

Ruby 3.0, which is explicitly mentioned in the bug report as being used,
was just temporarily in bookworm as an intermediate step between 2.7
(bullseye) and 3.1 which is the version that is actually to be released
with bookworm. One cannot really support a package that is not even in
Debian anymore, or to a system that mixes random versions of packages
that were once in testing.

Unless you are able to reproduce this in a supported configuration
(either stable or testing, but not something random in between), this is
not a valid bug report. It's also not OK to reassign it to the Ruby
interpreter, since there is no evidence of this actually being a bug in
it, or even in a supported version of Ruby.


signature.asc
Description: PGP signature

Bug#1032070: fixed in ruby3.1 3.1.2-7~exp

[Antonio Terceiro]

On Fri, Mar 24, 2023 at 02:23:07PM +0530, Pirate Praveen wrote:
> On Wed, 15 Mar 2023 01:05:14 +0530 Pirate Praveen 
> wrote:
> > Are you planning to upload this to bookworm? We are starting to test
> > gitlab on bookworm to be able to provide gitlab via bookworm-fasttrack
> > when bookworm releases. I hit this issue today when testing gitlab on
> > bookworm.

I uploaded it yesterday and there is an unblock request already in
place.

> I tried rebuilding ruby in bookworm, but one test failed. Not sure if this
> is a random failure or is it actually using the internet?
> 
> See #1033395

I didn't really try on bookworm, but the difference between it and sid
at this point is probably small and it just worked for me and on the
buildds. it might be random.


signature.asc
Description: PGP signature

Bug#1033573: unblock: ruby3.1/3.1.2-7

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ruby...@packages.debian.org
Control: affects -1 + src:ruby3.1

Please unblock package ruby3.1

[ Reason ]
This release updates the openssl bindings, fixing a few regressions that
have been identified.

[ Impact ]
Without these changes, at least gitlab doesn't work correctly.

[ Tests ]
I had uploaded this to experimental some time ago, and the pseudo
excuses against unstable showed no regressions.

[ Risks ]
The changes are contained to the implementatin of a few openssl methods.
I think the risk is low. I had also tried updating to the new upstream
release 3.1.3, which includes this change, but thought that contained
too many non-critical changes.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I'm also attaching the actual patch included in this upload as it is
easier to read than the diff-in-diff in the debdiff.

unblock ruby3.1/3.1.2-7
diff --git a/debian/changelog b/debian/changelog
index c6bd035fc..54e474d21 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+ruby3.1 (3.1.2-7) unstable; urgency=medium
+
+  * Upload to unstable
+
+ -- Antonio Terceiro   Sat, 25 Mar 2023 14:20:34 -0300
+
+ruby3.1 (3.1.2-7~exp) experimental; urgency=medium
+
+  * Update openssl extension to to 3.0.1 (Closes: #1032070)
+
+ -- Antonio Terceiro   Sun, 05 Mar 2023 17:13:36 -0300
+
 ruby3.1 (3.1.2-6) unstable; urgency=medium
 
   * Add missing dependencies for pkg-config test
diff --git a/debian/patches/openssl-3.0.1.patch b/debian/patches/openssl-3.0.1.patch
new file mode 100644
index 0..0762cb65e
--- /dev/null
+++ b/debian/patches/openssl-3.0.1.patch
@@ -0,0 +1,495 @@
+From: Antonio Terceiro 
+Date: Sun, 5 Mar 2023 17:09:05 -0300
+Subject: openssl 3.0.1
+
+This is a combination of several patches for openssl extension that fix
+bugs in its version 3.0.0.
+
+Forwarded: not-needed
+---
+ ext/openssl/History.md | 40 +
+ ext/openssl/extconf.rb |  5 +++--
+ ext/openssl/lib/openssl/pkey.rb|  8 +++
+ ext/openssl/lib/openssl/version.rb |  2 +-
+ ext/openssl/openssl.gemspec|  2 +-
+ ext/openssl/ossl_hmac.c|  8 +++
+ ext/openssl/ossl_pkey.c| 46 +++---
+ ext/openssl/ossl_pkey_ec.c |  4 
+ ext/openssl/ossl_x509cert.c|  6 ++---
+ ext/openssl/ossl_x509crl.c |  6 ++---
+ ext/openssl/ossl_x509req.c |  6 ++---
+ ext/openssl/ossl_x509revoked.c |  6 ++---
+ test/openssl/test_hmac.rb  |  8 +++
+ test/openssl/test_pkey_dsa.rb  | 19 
+ test/openssl/test_pkey_ec.rb   | 25 +
+ test/openssl/test_pkey_rsa.rb  |  5 +
+ test/openssl/test_ssl.rb   |  6 +
+ 17 files changed, 183 insertions(+), 19 deletions(-)
+
+diff --git a/ext/openssl/History.md b/ext/openssl/History.md
+index 479ec3b..a4f6bd7 100644
+--- a/ext/openssl/History.md
 b/ext/openssl/History.md
+@@ -1,3 +1,27 @@
++Version 3.0.1
++=
++
++Merged changes in 2.1.4 and 2.2.2. Additionally, the following issues are fixed
++by this release.
++
++Bug fixes
++-
++
++* Add missing type check in OpenSSL::PKey::PKey#sign's optional parameters.
++  [[GitHub #531]](https://github.com/ruby/openssl/pull/531)
++* Work around OpenSSL 3.0's HMAC issues with a zero-length key.
++  [[GitHub #538]](https://github.com/ruby/openssl/pull/538)
++* Fix a regression in OpenSSL::PKey::DSA.generate's default of 'q' size.
++  [[GitHub #483]](https://github.com/ruby/openssl/issues/483)
++  [[GitHub #539]](https://github.com/ruby/openssl/pull/539)
++* Restore OpenSSL::PKey.read's ability to decode "openssl ecparam -genkey"
++  output when linked against OpenSSL 3.0.
++  [[GitHub #535]](https://github.com/ruby/openssl/pull/535)
++  [[GitHub #540]](https://github.com/ruby/openssl/pull/540)
++* Restore error checks in OpenSSL::PKey::EC#{to_der,to_pem}.
++  [[GitHub #541]](https://github.com/ruby/openssl/pull/541)
++
++
+ Version 3.0.0
+ =
+ 
+@@ -100,6 +124,12 @@ Notable changes
+ [[GitHub #342]](https://github.com/ruby/openssl/issues/342)
+ 
+ 
++Version 2.2.2
++=
++
++Merged changes in 2.1.4.
++
++
+ Version 2.2.1
+ =
+ 
+@@ -194,6 +224,16 @@ Notable changes
+   [[GitHub #297]](https://github.com/ruby/openssl/pull/297)
+ 
+ 
++Version 2.1.4
++=
++
++Bug fixes
++-
++
++* Do not use pkg-config if --with-openssl-dir option is specified.
++ [[GitHub #486]](https://github.com/ruby/openssl/pull/486)
++
++
+ Version 2.1.3
+ =
+ 
+diff --git a/ext/openssl/extconf.rb b/ext/openssl/extconf.rb
+index fedcb93..d2d7893 100644
+--- a/ext/openssl/extconf.rb
 b/ext/

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Antonio Terceiro]

On Wed, Feb 22, 2023 at 03:33:15PM -0700, Sam Hartman wrote:
> >>  A tool for glamorous shell scripts. Leverage the power of
> >> Bubbles  (https://github.com/charmbracelet/bubbles) and Lip Gloss
> >>  (https://github.com/charmbracelet/lipgloss) in your scripts and
> >> aliases  without writing any Go code!   .   Tutorial  .   Gum
> >> provides highly configurable, ready-to-use utilities to help you
> >> write  useful shell scripts and dotfiles aliases with just a few
> >> lines of code.
> 
> Antonio> This last paragraph above looks like a good enough package
> Antonio> description.  Save everything else for an upstream README
> Antonio> installed on /usr/share/doc/gum/, or some other type of
> Antonio> documentation.
> 
> I disagree.
> I should not have to chase down links to  websites to understand a
> description
> Please include a phrase or two describing each of bubbles and gloss.

I meant only the part that starts with "Gum provides highly-configurable
..."


signature.asc
Description: PGP signature

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Antonio Terceiro]

On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
> 
> On 2/21/23 15:03, Ryan Kavanagh wrote:
> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
> > >Description : A tool for glamourous shell scripts
> > > 
> > > A tool for glamorous shell scripts. Leverage the power of Bubbles and
> > > Lip Gloss in your scripts and aliases without writing any Go code!
> > This long description does not provide users with enough information to
> > understand what the package does. What are "Bubbles" and "Lip Gloss" in
> > a shell script? What is a "glamourous shell script"?
> > 
> > It would be helpful if the package's long description satisfied §3.4.2
> > of the Debian Policy Manual [0]:
> > 
> >  The description field needs to make sense to anyone, even people who
> >  have no idea about any of the things the package deals with. [3]
> > 
> >  [...]
> > 
> >  [3] The blurb that comes with a program in its announcements and/or
> >  README files is rarely suitable for use in a description. It is
> >  usually aimed at people who are already in the community where the
> >  package is used.
> > 
> > Best wishes,
> > Ryan
> > 
> > [0] 
> > https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
> > 
> 
> The package description will be this or close to it:

That is just too long, please don't.

>  A tool for glamorous shell scripts. Leverage the power of Bubbles
>  (https://github.com/charmbracelet/bubbles) and Lip Gloss
>  (https://github.com/charmbracelet/lipgloss) in your scripts and aliases
>  without writing any Go code!
>  .
>  Tutorial
>  .
>  Gum provides highly configurable, ready-to-use utilities to help you write
>  useful shell scripts and dotfiles aliases with just a few lines of code.

This last paragraph above looks like a good enough package description.
Save everything else for an upstream README installed on
/usr/share/doc/gum/, or some other type of documentation.

https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions


signature.asc
Description: PGP signature

Bug#1030987: bullseye-pu: package vagrant/2.2.14+dfsg-2

[Antonio Terceiro]

On Sun, Feb 19, 2023 at 06:54:45PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2023-02-10 at 09:58 +0100, Antonio Terceiro wrote:
> > Since VirtualBox is not in stable, people will install it either from
> > upstream, and from Fasttrack (https://fasttrack.debian.net/). When a
> > new
> > version of VirtualBox comes out, vagrant needs change to work with
> > it.
> > 
> > [ Impact ]
> > stable users can't use vagrant with the latest VirtualBox (7.0).
> > 
> 
> Please go ahead.

Uploaded.


signature.asc
Description: PGP signature

Bug#1008280: pstoedit: silently fails with success return for some purifyeps use cases

[Antonio Terceiro]

Control: severity -1 normal

Failing on some inputs is not a justification for a `serious` severity.
Thus, I am downgrading this bug to normal.


signature.asc
Description: PGP signature

Bug#1030883: release.debian.org: CI for rust-ureq mysteriously "in progress" for 5 days even on most powerful arches

[Antonio Terceiro]

On Thu, Feb 09, 2023 at 09:59:57PM +0100, Paul Gevers wrote:
> Control: reassign -1 debci-collector
> Control: retitle -1 missing filename sanitizing
> 
> Hi Jonas,
> 
> On 08-02-2023 21:20, Paul Gevers wrote:
> > So it's either the timing was extremely unfortunate and your package hit
> > something unknown on our infrastructure, or it's actually the package
> > that's causing issues on our infrastructure.
> 
> We have tracked down the issue and it turns out that this:
> > -ureq-2:gzip PASS
> triggers a bug in debci. The testname is used for filenames and the hyphen
> is interpreted as an option to tar, triggering:
> tar: You may not specify more than one '-Acdtrux', '--delete' or
> '--test-label' option
> 
> We're working on a fix.
> 
> @terceiro: thinking of it, should we request a CVE for this?

Do you think we have enough users of debci to justify this? (as in
people who are actually running their own debci service).


signature.asc
Description: PGP signature

Bug#1030987: bullseye-pu: package vagrant/2.2.14+dfsg-2

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: vagr...@packages.debian.org
Control: affects -1 + src:vagrant

[ Reason ]
Since VirtualBox is not in stable, people will install it either from
upstream, and from Fasttrack (https://fasttrack.debian.net/). When a new
version of VirtualBox comes out, vagrant needs change to work with it.

[ Impact ]
stable users can't use vagrant with the latest VirtualBox (7.0).

[ Tests ]
The full testsuite passes, plus I got one real user to test on theur
system and confirm it works for them.

[ Risks ]
This is a direct cherry pick, with only 1 line change, from the upstream
patch that added VirtualBox 7.0 support. I don't see significant risk.

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

I also attached the actual patch so it's easier to read than the
diff-in-diff in the debdiff.

[ Changes ]
The patch adds a new driver for VirtualBox 7.0, plus unit tests for it.

[ Other info ]
n/a
diff --git a/debian/changelog b/debian/changelog
index fc3cfcf..a28263d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+vagrant (2.2.14+dfsg-2) bullseye; urgency=medium
+
+  * Add support for VirtualBox 7.0 (Closes: #1026227)
+
+ -- Antonio Terceiro   Tue, 07 Feb 2023 10:33:52 +0100
+
 vagrant (2.2.14+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2.2.14+dfsg
diff --git a/debian/patches/0007-Add-support-for-VirtualBox-7.0.patch b/debian/patches/0007-Add-support-for-VirtualBox-7.0.patch
new file mode 100644
index 000..431a3b5
--- /dev/null
+++ b/debian/patches/0007-Add-support-for-VirtualBox-7.0.patch
@@ -0,0 +1,264 @@
+From: Chris Roberts 
+Date: Fri, 14 Oct 2022 10:44:49 -0700
+Subject: Add support for VirtualBox 7.0
+
+Signed-off-by: Antonio Terceiro 
+Changes from the original patch:
+
+- replace `require "rexml"` with `require "rexml/document"` to work with with
+  the rexml shipped with Ruby 2.7
+
+---
+ lib/vagrant/errors.rb  |   4 +
+ plugins/providers/virtualbox/driver/meta.rb|   1 +
+ plugins/providers/virtualbox/driver/version_7_0.rb |  67 +
+ plugins/providers/virtualbox/plugin.rb |   1 +
+ templates/locales/en.yml   |   5 +
+ .../virtualbox/driver/version_7_0_test.rb  | 109 +
+ 6 files changed, 187 insertions(+)
+ create mode 100644 plugins/providers/virtualbox/driver/version_7_0.rb
+ create mode 100644 test/unit/plugins/providers/virtualbox/driver/version_7_0_test.rb
+
+diff --git a/lib/vagrant/errors.rb b/lib/vagrant/errors.rb
+index 782615b..4329d29 100644
+--- a/lib/vagrant/errors.rb
 b/lib/vagrant/errors.rb
+@@ -940,6 +940,10 @@ module Vagrant
+   error_key(:virtualbox_broken_version_040214)
+ end
+ 
++class VirtualBoxConfigNotFound < VagrantError
++  error_key(:virtualbox_config_not_found)
++end
++
+ class VirtualBoxDisksDefinedExceedLimit < VagrantError
+   error_key(:virtualbox_disks_defined_exceed_limit)
+ end
+diff --git a/plugins/providers/virtualbox/driver/meta.rb b/plugins/providers/virtualbox/driver/meta.rb
+index c3be8c8..04c130c 100644
+--- a/plugins/providers/virtualbox/driver/meta.rb
 b/plugins/providers/virtualbox/driver/meta.rb
+@@ -65,6 +65,7 @@ module VagrantPlugins
+ "5.2" => Version_5_2,
+ "6.0" => Version_6_0,
+ "6.1" => Version_6_1,
++"7.0" => Version_7_0,
+   }
+ 
+   if @@version.start_with?("4.2.14")
+diff --git a/plugins/providers/virtualbox/driver/version_7_0.rb b/plugins/providers/virtualbox/driver/version_7_0.rb
+new file mode 100644
+index 000..d94e66b
+--- /dev/null
 b/plugins/providers/virtualbox/driver/version_7_0.rb
+@@ -0,0 +1,67 @@
++require "rexml/document"
++require File.expand_path("../version_6_1", __FILE__)
++
++module VagrantPlugins
++  module ProviderVirtualBox
++module Driver
++  # Driver for VirtualBox 7.0.x
++  class Version_7_0 < Version_6_1
++def initialize(uuid)
++  super
++
++  @logger = Log4r::Logger.new("vagrant::provider::virtualbox_7_0")
++end
++
++# The initial VirtualBox 7.0 release has an issue with displaying port
++# forward information. When a single port forward is defined, the forwarding
++# information can be found in the `showvminfo` output. Once more than a
++# single port forward is defined, no forwarding information is provided
++# in the `showvminfo` output. To work around this we grab the VM configuration
++# file from the `showvminfo` output and extract the port 

Bug#1029728: bullseye-pu: package passenger/5.0.30-1.2+deb11u1

[Antonio Terceiro]

On Sat, Feb 04, 2023 at 06:19:57PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2023-01-26 at 16:40 -0300, Antonio Terceiro wrote:
> > This updates makes it possible for users to use NodeJS binaries newer
> > than the ones provided in bullseye.
> > 
> > [ Impact ]
> > Users using a NodeJS version can't get passenger to work because it
> > fails to start due to use of an invalid global variable.
> > 
> 
> For some reason this bug never made it to debian-release.
> 
> Please go ahead.

Uploaded.


signature.asc
Description: PGP signature

Bug#1029632: unblock: ruby3.1/3.1.2-5

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ruby...@packages.debian.org
Control: affects -1 + src:ruby3.1

Please unblock package ruby3.1

This is a trivial bug fix, and even though there is no real block hint
in place, this bug report is to save you the time from wondering about
the changes.

[ Reason ]
3.1.2-4 had a regression. ./configure was being about an explicit
pkg-config binary, but pkg-config was not a build dependency. So
the pkg-config binary was not really there, so ./configure set the
corresponding configuration variable to an empty string making the
pkg-config bindings in mkmf.rb not really work.

[ Impact ]
This makes some packages fail to build from source, namely ruby-augeas
and ruby-libvirt.

[ Tests ]
An autopkgtest to catch similar issues in the future has been added, and
it passes while it failed with 3.1.2.4.

[ Risks ]
None.

[ Checklist ]
  [✓] all changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in testing

[ Other info ]
n/a

unblock ruby3.1/3.1.2-5
diff --git a/debian/changelog b/debian/changelog
index 59fe6c8a1..8e43cb693 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+ruby3.1 (3.1.2-5) unstable; urgency=medium
+
+  * Add autopkgtest to test pkg_config
+  * Add build dependency on pkg-config from pkgconf.
+The absence of this build dependency made the check for whether
+pkg-config works fail (because it was not there) at the ./configure
+stage, making RbConfig::CONFIG["PKG_CONFIG"] empty, and therefore broke
+the usage of pkg_config() in extconf.rb scripts.
+This was noticed by Lucas Kanashiro (thanks!) in Ubuntu while rebuilding
+all Ruby packages to add ruby3.1 support, where ruby-augeas and
+ruby-libvirt failed to build.
+
+ -- Antonio Terceiro   Wed, 25 Jan 2023 14:46:18 -0300
+
 ruby3.1 (3.1.2-4) unstable; urgency=medium
 
   * Replace cross pkg-config patch with patches applied upstream
diff --git a/debian/control b/debian/control
index 2d6602a40..9802975c0 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,7 @@ Build-Depends: bison,
libyaml-dev,
netbase ,
openssl ,
+   pkg-config (>= 1.8.0-7~),
procps ,
ruby3.1:native ,
rubygems-integration (>= 1.6) ,
diff --git a/debian/tests/control b/debian/tests/control
index 2b0bab840..bd3c7127a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,3 @@
-Tests: run-all bundled-gems builtin-extensions rubyconfig
-Depends: @
+Tests: run-all bundled-gems builtin-extensions rubyconfig pkg-config
+Depends: @, libffi-dev
 Restrictions: allow-stderr
diff --git a/debian/tests/pkg-config b/debian/tests/pkg-config
new file mode 100755
index 0..ce2bd6e23
--- /dev/null
+++ b/debian/tests/pkg-config
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -eu
+
+ruby="${1:-ruby3.1}"
+cd "${AUTOPKGTEST_TMP:-/tmp}"
+
+set -x
+$ruby -rmkmf -e 'pkg_config("libffi") or raise "pkg_config does not work"'


signature.asc
Description: PGP signature

Bug#1026499: rows: diff for NMU version 0.4.1-5.1

[Antonio Terceiro]

On Wed, Jan 18, 2023 at 06:27:59PM +0200, Adrian Bunk wrote:
> Control: tags 1026499 + patch
> Control: tags 1026499 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for rows (versioned as 0.4.1-5.1) and uploaded
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

I'm about to upload a new upstream snapshot that will close this bug, so
I think you can cancel it. Thanks for looking into the package, though.


signature.asc
Description: PGP signature

Bug#1028555: apt-cacher: hardcodes list of supported architectures

[Antonio Terceiro]

Hi,

On Thu, Jan 12, 2023 at 05:22:20PM +, Mark Hindley wrote:
> Antonio,
> 
> Thanks for this.
> 
> On Thu, Jan 12, 2023 at 02:03:59PM -0300, Antonio Terceiro wrote:
> > Package: apt-cacher
> > Version: 1.7.28.1
> > Severity: normal
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > I was creating a cross build environment for riscv64, and my downloads
> > failed because apt-cacher did not recognize it. I then discovered that
> > apt-cacher has a hardcoded list of supported architectures.
> > 
> > The attached patch reads the list of most common supported architectures
> > from dpkg directly, so that you don't need to add architectures by hand
> > every time one comes around.
> 
> Yes, I have tried this approach in the past but rejected it. My concern was 
> that
> it includes many theoretically possible, but practically not available
> architectures.

From reading the code the point of this list seems to be preventing
people from trying to use apt-cacher as a generic HTTP proxy, so I think
it does not hurt to have a list that includes some architectures that
are not used in practice.

> Maybe that is overly cautious.

I would agree with that. :)


signature.asc
Description: PGP signature

Bug#1028555: apt-cacher: hardcodes list of supported architectures

[Antonio Terceiro]

Package: apt-cacher
Version: 1.7.28.1
Severity: normal
Tags: patch

Dear Maintainer,

I was creating a cross build environment for riscv64, and my downloads
failed because apt-cacher did not recognize it. I then discovered that
apt-cacher has a hardcoded list of supported architectures.

The attached patch reads the list of most common supported architectures
from dpkg directly, so that you don't need to add architectures by hand
every time one comes around.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-cacher depends on:
ii  debconf [debconf-2.0]  1.5.81
ii  distro-info-data   0.56
ii  ed 1.18-1
ii  init-system-helpers1.65.2
ii  libdpkg-perl   1.21.13
ii  libfilesys-df-perl 0.92-7+b1
ii  libio-interactive-perl 1.023-2
ii  libio-interface-perl   1.09-2+b2
ii  libipc-sharelite-perl  0.17-4+b7
ii  libnetaddr-ip-perl 4.079+dfsg-2+b1
ii  libsys-syscall-perl0.25-7
ii  libwww-curl-perl   4.17-8+b1
ii  libwww-perl6.67-1
ii  lsb-base   11.5
ii  perl   5.36.0-6
ii  sysvinit-utils [lsb-base]  3.06-2
ii  update-inetd   4.51

Versions of packages apt-cacher recommends:
ii  libberkeleydb-perl0.64-2+b1
ii  libio-compress-lzma-perl  2.201-1

Versions of packages apt-cacher suggests:
pn  libfreezethaw-perl   
ii  libio-socket-inet6-perl  2.73-1

-- debconf information:
* apt-cacher/mode: daemon
From a6dcce83a210167b2c023eb208609e909186cdd8 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Thu, 12 Jan 2023 09:43:33 -0300
Subject: [PATCH] Query dpkg for supported architectures

Instead of maintaining a hardcoded list, just query dpkg-architecture
for all supported architectures, and allow those. This way people
working on new ports and using apt-cacher have one less place to patch.

To avoid a giant list, and a giant configuration file line, drop the
architectures that have dashes (-) in their names, so we avoid more
exotic ports like uclinux-*, aix-* etc, keeping only the traditional
Linux + glibc ports 99.% of us use.
---
 config/apt-cacher.conf |  2 +-
 lib/apt-cacher.pl  | 31 +--
 2 files changed, 2 insertions(+), 31 deletions(-)

diff --git a/config/apt-cacher.conf b/config/apt-cacher.conf
index e6c95ef..1cf41f0 100644
--- a/config/apt-cacher.conf
+++ b/config/apt-cacher.conf
@@ -187,7 +187,7 @@ user = www-data
 # (see below).
 #
 #supported_archs = i386, amd64
-#supported_archs = avr32, amd64, alpha, arm, arm64, armel, armhf, hppa, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, m32r, m68k, mips, mipsel, netbsd-alpha, netbsd-i386, powerpc, powerpcspe, ppc64, s390, s390x, sh4, sparc, sparc64, x32
+#supported_archs = armhf, armel, mipsn32, mipsn32el, mipsn32r6, mipsn32r6el, mips64, mips64el, mips64r6, mips64r6el, powerpcspe, x32, arm64ilp32, alpha, amd64, arc, armeb, arm, arm64, avr32, hppa, loong64, i386, ia64, m32r, m68k, mips, mipsel, mipsr6, mipsr6el, nios2, or1k, powerpc, powerpcel, ppc64, ppc64el, riscv64, s390, s390x, sh3, sh3eb, sh4, sh4eb, sparc, sparc64, tilegx
 
 # List of Ubuntu release names used to expand %VALID_UBUNTU_RELEASE_NAMES% in
 # *_files_regexp (see below). This is required to allow the Ubuntu installer to
diff --git a/lib/apt-cacher.pl b/lib/apt-cacher.pl
index ee14952..3002532 100755
--- a/lib/apt-cacher.pl
+++ b/lib/apt-cacher.pl
@@ -60,36 +60,7 @@ sub read_config {
 		  request_timeout => 30,
 		  return_buffer_size => 1048576, # 1Mb
 		  reverse_path_map => 1,
-		  supported_archs => join(', ', qw(
-		  avr32
-		  amd64
-		  alpha
-		  arm
-		  arm64
-		  armel
-		  armhf
-		  hppa
-		  hurd-i386
-		  i386
-		  ia64
-		  kfreebsd-amd64
-		  kfreebsd-i386
-		  m32r
-		  m68k
-		  mips
-		  mipsel
-		  netbsd-alpha
-		  netbsd-i386
-		  powerpc
-		  powerpcspe
-		  ppc64
-		  s390
-		  s390x
-		  sh4
-		  sparc
-		  sparc64
-		  x32
-		 )),
+		  supported_archs => join(', ', grep { $_ !~ /-/ } Dpkg::Arch::get_valid_arches()),
 		  ubuntu_release_names => join(', ', get_ubuntu_names()),
 		  user => $>,
 
-- 
2.39.0



signature.asc
Description: PGP signature

Bug#1028221: RM: ruby3.0 -- ROM; obsolete

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby...@packages.debian.org
Control: affects -1 + src:ruby3.0

Please remove ruby3.0 from unstable. It was an intermediate step between
ruby2.7 (bullseye) and ruby3.1 (bookworm), and is already not in testing.

A few packages would be left broken by this, but they are already broken
for a while. Maybe I will ask for them to be removed as well at some
point, but in principle they could as well be fixed.

dak says this:
8<8<8<-
$ dak rm -Rn ruby3.0

Will remove the following packages from unstable:

libruby3.0 |3.0.4-8 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x
   ruby3.0 |3.0.4-8 | source, amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
ruby3.0-dev |3.0.4-8 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x
ruby3.0-doc |3.0.4-8 | all

Maintainer: Debian Ruby Team 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
ruby-dataobjects-mysql: ruby-dataobjects-mysql
ruby-gitlab-pg-query: ruby-gitlab-pg-query [amd64 arm64 armel armhf]
ruby-psych: ruby-psych

Dependency problem found.
8<8<8<-


signature.asc
Description: PGP signature

Bug#1026779: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1026779: fixed in binutils 2.39.50.20221224-1)

[Antonio Terceiro]

Control: reopen -1

On Sat, Dec 24, 2022 at 02:45:07PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:binutils package:
> 
> #1026779: binutils: cross binutils and foreign libbinutils not coinstallable, 
> breaking upgrades
> 
> It has been closed by Debian FTP Masters  
> (reply to Matthias Klose ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Matthias Klose ) 
> by
> replying to this email.
> 
> 
> -- 
> 1026779: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026779
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Sat, 24 Dec 2022 14:40:11 +
> From: Debian FTP Masters 
> To: 1026779-cl...@bugs.debian.org
> Subject: Bug#1026779: fixed in binutils 2.39.50.20221224-1
> Reply-To: Matthias Klose 
> Message-Id: 
> 

> Date: Tue, 20 Dec 2022 21:04:46 -0300
> From: Antonio Terceiro 
> To: Debian Bug Tracking System 
> Subject: binutils: cross binutils and foreign libbinutils not
>  coinstallable, breaking upgrades
> Message-ID: 
> 
> Source: binutils
> Version: 2.39.50.20221208-5
> Severity: serious
> 
> Dear Maintainer,
> 
> Up to src:binutils 2.39-8, binutils-${DEB_HOST_MULTIARCH} and
> libbinutils:${DEB_HOST_ARCH} were coinstallable. Upgrading a system
> where both are installed (e.g. binutils-aarch64-linux-gnu and
> libbinutils:arm64) fails like this:
> 
> 8<8<8<-
> Unpacking libbinutils:arm64 (2.39.50.20221208-5) over (2.39-8) ...
> Preparing to unpack 
> .../3-binutils-aarch64-linux-gnu_2.39.50.20221208-5_amd64.deb ...
> Unpacking binutils-aarch64-linux-gnu (2.39.50.20221208-5) over (2.39-8) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-maU0ym/3-binutils-aarch64-linux-gnu_2.39.50.20221208-5_amd64.deb
>  (--unpack):
>  trying to overwrite '/usr/lib/aarch64-linux-gnu/libsframe.so.0.0.0', which 
> is also in package libbinutils:arm64 2.39.50.20221208-5
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Preparing to unpack .../4-binutils-common_2.39.50.20221208-5_amd64.deb ...
> De-configuring binutils-common:arm64 (2.39-8), to allow configuration of 
> binutils-common:amd64 (2.39.50.20221208-5) ...
> Unpacking binutils-common:amd64 (2.39.50.20221208-5) over (2.39-8) ...
> Preparing to unpack .../5-binutils-common_2.39.50.20221208-5_arm64.deb ...
> Unpacking binutils-common:arm64 (2.39.50.20221208-5) over (2.39-8) ...
> Selecting previously unselected package libbinutils:amd64.
> Preparing to unpack .../6-libbinutils_2.39.50.20221208-5_amd64.deb ...
> Unpacking libbinutils:amd64 (2.39.50.20221208-5) ...
> Selecting previously unselected package libjansson4:amd64.
> Preparing to unpack .../7-libjansson4_2.14-2_amd64.deb ...
> Unpacking libjansson4:amd64 (2.14-2) ...
> Errors were encountered while processing:
>  
> /tmp/apt-dpkg-install-maU0ym/3-binutils-aarch64-linux-gnu_2.39.50.20221208-5_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 8<8<8<-

i386 is still affected by this on 2.39.50.20221224-1 (testing):

Unpacking binutils-i686-linux-gnu (2.39.50.20221224-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-X01H6O/8-binutils-i686-linux-gnu_2.39.50.20221224-1_amd64.deb
 (--unpack):
 trying to overwrite '/usr/lib/i386-linux-gnu/libsframe.so.0.0.0', which is 
also in package libbinutils:i386 2.39.50.20221224-1
Errors were encountered while processing:
 
/tmp/apt-dpkg-install-X01H6O/8-binutils-i686-linux-gnu_2.39.50.20221224-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

and also on 2.39.90.20221231-1 (unstable)

Unpacking binutils-i686-linux-gnu (2.39.90.20221231-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/binutils-i686-linux-gnu_2.39.90.20221231-1_amd64.deb 
(--unpack):
 trying to overwrite '/usr/lib/i386-linux-gnu/libsframe.so.0.0.0', which is 
also in package libbinutils:i386 2.39.90.20221231-1
Errors were encountered while processing:
 /var/cache/apt/archives/binutils-i686-linux-gnu_2.39.90.20221231-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



signature.asc
Description: PGP signature

Bug#1027710: libruby3.0: drop Provides: ruby-dbm (now provided separately)

[Antonio Terceiro]

Control: reassign -1 dhelp
Control: retitle -1 dhelp: dependency on ruby-dbm satisfied by (obsolete) 
libruby3.0

On Mon, Jan 02, 2023 at 11:28:54AM +0100, Drew Parsons wrote:
> Package: libruby3.0
> Version: 3.0.4-8
> Severity: normal
> 
> A new ruby-dbm package was recently created to resolve Bug#1027407
> (dhelp Depends: ruby-dbm)
> 
> But libruby3.0 still declares Provides: ruby-dbm (= 1.1.0)
> and so the new ruby-dbm 1.1.0-2 doesn't actually get installed by a
> standard upgrade.
> 
> I guess libruby3.0 should now drop Provides: ruby-dbm
> since it no longer provides dbm.

libruby3.0 won't be part of the release, and in fact I want to get it
removed RSN. Instead of dropping the provides from libruby3.0, I think
the correct fix for this is tighttening the dependency in dhelp instead.


signature.asc
Description: PGP signature

Bug#1027342: itamae: FTBFS: ERROR: Test "ruby3.1" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block in activate_dependencies': Could not find 'net-telnet' (= 0.1.1)

[Antonio Terceiro]

Control: reassign -1 src:ruby-specinfra
Control: forcemerge #1027347 -1
Control: affects #1027347 src:itamae

On Fri, Dec 30, 2022 at 05:20:58PM +0100, Lucas Nussbaum wrote:
> Source: itamae
> Version: 1.14.1-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221230 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This is caused by ruby-specinfra.


signature.asc
Description: PGP signature

Bug#1027407: ruby-rubygems: kernel_require.rb LoadError breaks dhelp

[Antonio Terceiro]

Control: tag -1 + pending

On Fri, Dec 30, 2022 at 08:08:50PM -0300, Antonio Terceiro wrote:
> Control: reassign -1 dhelp
> Control: severity -1 serious
> Control: retitle: dhelp: depends on module removed from the Ruby stdlib (dbm)
> 
> On Fri, Dec 30, 2022 at 06:09:03PM +0100, Drew Parsons wrote:
> > Package: ruby-rubygems
> > Version: 3.3.15-1
> > Severity: important
> > 
> > /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb from
> > ruby-rubygems causes a LoadError which prevents dhelp from updating
> > succcessfully (when packages register a doc-base entry).
> > 
> > This affects all other packages (unrelated to ruby) registering with
> > doc-base, hence marking Severity: important
> > 
> > The error message (when installing any packing using doc-base, in this
> > case python-lmfit-doc) is
> > 
> > Setting up python-lmfit-doc (1.1.0-1) ...
> > Processing triggers for doc-base (0.11.1) ...
> > Processing 1 added doc-base file...
> > Registering documents with dhelp...
> > :85:in
> >  `require': cannot load such file -- dbm (LoadError)
> > from 
> > :85:in
> >  `require'
> > from /usr/lib/ruby/vendor_ruby/dhelp.rb:21:in `'
> > from 
> > :85:in
> >  `require'
> > from 
> > :85:in
> >  `require'
> > from /usr/sbin/dhelp_parse:32:in `'
> 
> The issue is that dhelp depends on a module that has been removed from
> the Ruby standard library (dbm). I imagine the dhelp database is just a
> cache and can be rebuilt from scratch on upgrades, so one way to fix
> this would be to migrate to a similar module that is available and
> probably has a similar enough API, like sdbm (ruby-sdbm).

Actually this would invalidate existing databases, creating extra
complications. I have just uploaded a ruby-dbm package to NEW, and made
the necessary adjustments to the dhelp git repository to use it. I will
make an upload when the new package is accepted.


signature.asc
Description: PGP signature

Bug#1027407: ruby-rubygems: kernel_require.rb LoadError breaks dhelp

[Antonio Terceiro]

Control: reassign -1 dhelp
Control: severity -1 serious
Control: retitle: dhelp: depends on module removed from the Ruby stdlib (dbm)

On Fri, Dec 30, 2022 at 06:09:03PM +0100, Drew Parsons wrote:
> Package: ruby-rubygems
> Version: 3.3.15-1
> Severity: important
> 
> /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb from
> ruby-rubygems causes a LoadError which prevents dhelp from updating
> succcessfully (when packages register a doc-base entry).
> 
> This affects all other packages (unrelated to ruby) registering with
> doc-base, hence marking Severity: important
> 
> The error message (when installing any packing using doc-base, in this
> case python-lmfit-doc) is
> 
> Setting up python-lmfit-doc (1.1.0-1) ...
> Processing triggers for doc-base (0.11.1) ...
> Processing 1 added doc-base file...
> Registering documents with dhelp...
> :85:in
>  `require': cannot load such file -- dbm (LoadError)
>   from 
> :85:in
>  `require'
>   from /usr/lib/ruby/vendor_ruby/dhelp.rb:21:in `'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /usr/sbin/dhelp_parse:32:in `'

The issue is that dhelp depends on a module that has been removed from
the Ruby standard library (dbm). I imagine the dhelp database is just a
cache and can be rebuilt from scratch on upgrades, so one way to fix
this would be to migrate to a similar module that is available and
probably has a similar enough API, like sdbm (ruby-sdbm).


signature.asc
Description: PGP signature

Bug#1027098: vagrant: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: expect(env).to receive(:[]=).with(:machine_ssh_info, host: "ADDRESS")

[Antonio Terceiro]

Source: vagrant
Version: 2.2.19+dfsg-3
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
vagrant failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: expect(env).to receive(:[]=).with(:machine_ssh_info, 
> host: "ADDRESS")
>  
>    {:ui=># @logger=# @fullname="vagrant::ui::interface", @outputters=[], @additive=true, 
> @name="interface", @path="vagrant::ui", 
> @parent=#, 
> @level=0, @trace=false>, @opts={}, @stdin=#>, 
> @stdout=#>, @stderr=#>>, :machine=># "machine">} received :[]= with unexpected arguments
>  expected: (:machine_ssh_info, {:host=>"ADDRESS"}) (keyword 
> arguments)
>   got: (:machine_ssh_info, {:host=>"ADDRESS"}) (options 
> hash)
>  # 
> /<>/test/unit/plugins/providers/hyperv/action/read_guest_ip_test.rb:34:in
>  `block (3 levels) in '
> 
> Finished in 4 minutes 58.9 seconds (files took 1.27 seconds to load)
> 2940 examples, 3 failures, 9 pending
> 
> Failed examples:
> 
> rspec 
> /<>/test/unit/plugins/commands/package/command_test.rb:65 
> # VagrantPlugins::CommandPackage::Command#execute with single argument 
> with --output option packages default machine inside specified folder
> rspec 
> /<>/test/unit/plugins/commands/package/command_test.rb:98 
> # VagrantPlugins::CommandPackage::Command#execute with --base option and 
> option value packages vm defined within virtualbox
> rspec 
> /<>/test/unit/plugins/providers/hyperv/action/read_guest_ip_test.rb:33
>  # VagrantPlugins::HyperV::Action::ReadGuestIP with machine ID set 
> should set the host information into the env
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/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.1" failed: 


The full build log is attached.

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


vagrant.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027096: ruby-webmock: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: @headers = Util::Headers.normalize_headers(@headers)

[Antonio Terceiro]

Source: ruby-webmock
Version: 3.8.3-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-webmock failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: @headers = Util::Headers.normalize_headers(@headers)
> 
># received :normalize_headers with 
> unexpected arguments
>  expected: ({"A"=>"a"}) (keyword arguments)
>   got: ({"A"=>"a"}) (options hash)
>  # ./lib/webmock/response.rb:31:in `headers='
>  # ./lib/webmock/response.rb:76:in `options='
>  # ./lib/webmock/response.rb:20:in `initialize'
>  # ./spec/unit/response_spec.rb:35:in `new'
>  # ./spec/unit/response_spec.rb:35:in `block (2 levels) in  (required)>'
> 
> Finished in 5.14 seconds (files took 1.09 seconds to load)
> 3440 examples, 2 failures
> 
> Failed examples:
> 
> rspec ./spec/unit/request_signature_spec.rb:20 # WebMock::RequestSignature 
> initialization assigns normalized headers
> rspec ./spec/unit/response_spec.rb:33 # WebMock::Response should report 
> normalized headers
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> spec/acceptance/curb/curb_spec.rb 
> spec/acceptance/em_http_request/em_http_request_spec.rb 
> spec/acceptance/httpclient/httpclient_spec.rb 
> spec/acceptance/manticore/manticore_spec.rb 
> spec/acceptance/net_http/net_http_spec.rb 
> spec/acceptance/net_http/real_net_http_spec.rb 
> spec/acceptance/typhoeus/typhoeus_hydra_spec.rb spec/unit/api_spec.rb 
> spec/unit/errors_spec.rb 
> spec/unit/http_lib_adapters/http_lib_adapter_registry_spec.rb 
> spec/unit/http_lib_adapters/http_lib_adapter_spec.rb 
> spec/unit/matchers/hash_excluding_matcher_spec.rb 
> spec/unit/matchers/hash_including_matcher_spec.rb 
> spec/unit/rack_response_spec.rb spec/unit/request_body_diff_spec.rb 
> spec/unit/request_execution_verifier_spec.rb 
> spec/unit/request_pattern_spec.rb spec/unit/request_registry_spec.rb 
> spec/unit/request_signature_snippet_spec.rb 
> spec/unit/request_signature_spec.rb spec/unit/request_stub_spec.rb 
> spec/unit/response_spec.rb spec/unit/stub_registry_spec.rb 
> spec/unit/stub_request_snippet_spec.rb spec/unit/util/hash_counter_spec.rb 
> spec/unit/util/hash_keys_stringifier_spec.rb spec/unit/util/headers_spec.rb 
> spec/unit/util/json_spec.rb spec/unit/util/query_mapper_spec.rb 
> spec/unit/util/uri_spec.rb spec/unit/util/version_checker_spec.rb 
> spec/unit/webmock_spec.rb -c -f progress -r ./spec/spec_helper.rb failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-webmock.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027095: ruby-vcr: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: /<>/lib/vcr/library_hooks/webmock.rb:36:in `block in global_hook_disabled_requests': wrong number of argum

[Antonio Terceiro]

Source: ruby-vcr
Version: 6.0.0+really5.0.0-4
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-vcr failed to build.

Relevant part of the build log (hopefully):
> /<>/lib/vcr/library_hooks/webmock.rb:36:in `block in 
> global_hook_disabled_requests': wrong number of arguments (given 1, expected 
> 0) (ArgumentError)
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-vcr.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027093: ruby-thor: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: result = Thor::LineEditor.readline(message, options)

[Antonio Terceiro]

Source: ruby-thor
Version: 1.2.1-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-thor failed to build.

Relevant part of the build log (hopefully):
>   Failure/Error: result = Thor::LineEditor.readline(message, options)
> 
> Thor::LineEditor received :readline with unexpected arguments
>   expected: ("Overwrite foo? (enter \"h\" for help) [Ynaqdhm] ", 
> {:add_to_history=>false}) (keyword arguments)
>got: ("Overwrite foo? (enter \"h\" for help) [Ynaqdhm] ", 
> {:add_to_history=>false}) (options hash)
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib/rspec/support.rb:102:in
>  `block in '
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib/rspec/support.rb:111:in
>  `notify_failure'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/error_generator.rb:348:in
>  `notify'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/error_generator.rb:332:in
>  `__raise'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/error_generator.rb:55:in
>  `raise_unexpected_message_args_error'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/message_expectation.rb:555:in
>  `raise_unexpected_message_args_error'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/proxy.rb:216:in
>  `message_received'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/proxy.rb:360:in
>  `message_received'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/method_double.rb:91:in
>  `proxy_method_invoked'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-mocks-3.12.1/lib/rspec/mocks/method_double.rb:67:in
>  `block (2 levels) in define_proxy_method'
>   # ./lib/thor/shell/basic.rb:460:in `ask_simply'
>   # ./lib/thor/shell/basic.rb:85:in `ask'
>   # ./lib/thor/shell/basic.rb:290:in `block in file_collision'
>   # ./lib/thor/shell/basic.rb:289:in `loop'
>   # ./lib/thor/shell/basic.rb:289:in `file_collision'
>   # ./spec/shell/basic_spec.rb:492:in `block (4 levels) in  (required)>'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:263:in
>  `instance_exec'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:263:in
>  `block in run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:511:in
>  `block in with_around_and_singleton_context_hooks'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:468:in
>  `block in with_around_example_hooks'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/hooks.rb:486:in
>  `block in run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/hooks.rb:624:in
>  `run_around_example_hooks_for'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/hooks.rb:486:in
>  `run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:468:in
>  `with_around_example_hooks'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:511:in
>  `with_around_and_singleton_context_hooks'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example.rb:259:in
>  `run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:646:in
>  `block in run_examples'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:642:in
>  `map'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:642:in
>  `run_examples'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:607:in
>  `run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:608:in
>  `block in run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:608:in
>  `map'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:608:in
>  `run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:608:in
>  `block in run'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:608:in
>  `map'
>   # 
> /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib/rspec/core/example_group.rb:608:in
>  `run'

Bug#1027092: ruby-stomp: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error:

[Antonio Terceiro]

Source: ruby-stomp
Version: 1.4.10-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-stomp failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error:
>expect(Stomp::Connection).to receive(:new).with(:hosts => [{:login 
> => 'testlogin',
>:passcode 
> => 'testpasscode',
>:host => 
> 'host.foobar.com',
>:port => 
> 12345}],
>:logger => null_logger,
>:reliable => false,
>:client_main => @cli_thread)
> 
># received :new with unexpected arguments
>  expected: ({:client_main=>#, 
> :hosts=>[{:host=>"host.foobar.com", :login=>"testlog...code=>"testpasscode", 
> :port=>12345}], :logger=>#, 
> :reliable=>false}) (keyword arguments)
>   got: ({:client_main=>#, 
> :hosts=>[{:host=>"host.foobar.com", :login=>"testlog...code=>"testpasscode", 
> :port=>12345}], :logger=>#, 
> :reliable=>false}) (options hash)
>  # ./spec/client_spec.rb:273:in `block (3 levels) in '
> 
> Finished in 0.19699 seconds (files took 0.14394 seconds to load)
> 150 examples, 7 failures
> 
> Failed examples:
> 
> rspec ./spec/client_spec.rb:138 # Stomp::Client (created with positional 
> params) should properly parse the URL provided
> rspec ./spec/client_spec.rb:159 # Stomp::Client (created with 
> non-authenticating stomp:// URL and non-TLD host) should properly parse the 
> URL provided
> rspec ./spec/client_spec.rb:181 # Stomp::Client (created with 
> non-authenticating stomp:// URL and a host with a '-') should properly parse 
> the URL provided
> rspec ./spec/client_spec.rb:203 # Stomp::Client (created with authenticating 
> stomp:// URL and non-TLD host) should properly parse the URL provided
> rspec ./spec/client_spec.rb:225 # Stomp::Client (created with authenticating 
> stomp:// URL and a host with a '-') should properly parse the URL provided
> rspec ./spec/client_spec.rb:250 # Stomp::Client (created with 
> non-authenticating stomp:// URL and TLD host) should properly parse the URL 
> provided
> rspec ./spec/client_spec.rb:272 # Stomp::Client (created with authenticating 
> stomp:// URL and non-TLD host) should properly parse the URL provided
> 
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-stomp.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027091: ruby-slack-notifier: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: client.post endpoint, params

[Antonio Terceiro]

Source: ruby-slack-notifier
Version: 1.5.1-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-slack-notifier failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: client.post endpoint, params
> 
># received :post with unexpected arguments
>  expected: (#, 
> {:payload=>"{\"text\":\"the message\"}"}) (keyword arguments)
>   got: (#, 
> {:payload=>"{\"text\":\"the message\"}"}) (options hash)
>  # ./lib/slack-notifier.rb:41:in `ping'
>  # ./spec/lib/slack-notifier_spec.rb:137:in `block (4 levels) in  (required)>'
> 
> Finished in 0.03858 seconds (files took 0.14786 seconds to load)
> 29 examples, 5 failures
> 
> Failed examples:
> 
> rspec ./spec/lib/slack-notifier_spec.rb:49 # Slack::Notifier#ping allows 
> sending only an attachment
> rspec ./spec/lib/slack-notifier_spec.rb:93 # Slack::Notifier#ping with a 
> default channel set uses default channel
> rspec ./spec/lib/slack-notifier_spec.rb:101 # Slack::Notifier#ping with a 
> default channel set allows override channel to be set
> rspec ./spec/lib/slack-notifier_spec.rb:112 # Slack::Notifier#ping with 
> default webhook posts with the correct endpoint & data
> rspec ./spec/lib/slack-notifier_spec.rb:127 # Slack::Notifier#ping with a 
> custom http_client set uses it
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-slack-notifier.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027090: ruby-slack-messenger: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error:

[Antonio Terceiro]

Source: ruby-slack-messenger
Version: 2.3.4-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-slack-messenger failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error:
>expect(mock_http).to receive(:post).with(
>  URI.parse("http://example.com";),
>  payload: '{"channel":"new","user":"ship","text":"hello"}'
>)
> 
># 
> received :post with unexpected arguments
>  expected: (#http://example.com>, 
> {:payload=>"{\"channel\":\"new\",\"user\":\"ship\",\"text\":\"hello\"}"}) 
> (keyword arguments)
>   got: (#http://example.com>, 
> {:payload=>"{\"channel\":\"new\",\"user\":\"ship\",\"text\":\"hello\"}"}) 
> (options hash)
>  # ./spec/lib/slack-messenger_spec.rb:72:in `block (3 levels) in  (required)>'
> 
> Finished in 0.05301 seconds (files took 0.13642 seconds to load)
> 83 examples, 6 failures
> 
> Failed examples:
> 
> rspec ./spec/end_to_end_spec.rb:83 # Slack::Messenger applies options given 
> to middleware
> rspec ./spec/lib/slack-messenger/payload_middleware/stack_spec.rb:67 # 
> Slack::Messenger::PayloadMiddleware::Stack#set creates a stack from hashes 
> passing them as opts
> rspec ./spec/lib/slack-messenger_spec.rb:40 # Slack::Messenger#ping calls 
> #post with the message as the text key in #post
> rspec ./spec/lib/slack-messenger_spec.rb:80 # Slack::Messenger#post calls the 
> middleware stack with the payload
> rspec ./spec/lib/slack-messenger_spec.rb:58 # Slack::Messenger#post uses the 
> defaults set on initialization
> rspec ./spec/lib/slack-messenger_spec.rb:69 # Slack::Messenger#post allows 
> overriding the set defaults
> 
> Randomized with seed 261
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-slack-messenger.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027089: ruby-simplecov: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: Coverage.start(start_arguments)

[Antonio Terceiro]

Source: ruby-simplecov
Version: 0.21.2-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-simplecov failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: Coverage.start(start_arguments)
> 
>Coverage received :start with unexpected arguments
>  expected: ({:branches=>true, :lines=>true}) (keyword arguments)
>   got: ({:branches=>true, :lines=>true}) (options hash)
>  # ./lib/simplecov.rb:354:in `start_coverage_with_criteria'
>  # ./lib/simplecov.rb:343:in `start_coverage_measurement'
>  # ./spec/simplecov_spec.rb:340:in `block (3 levels) in '
> 
> Finished in 4.22 seconds (files took 0.19229 seconds to load)
> 385 examples, 2 failures
> 
> Failed examples:
> 
> rspec ./spec/simplecov_spec.rb:329 # SimpleCov.start_coverage_measurement 
> starts coverage in lines mode by default
> rspec ./spec/simplecov_spec.rb:335 # SimpleCov.start_coverage_measurement 
> starts coverage with lines and branches if branches is activated
> 
> Randomized with seed 22418
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb  --exclude-pattern 
> ./spec/default_formatter_spec.rb,./spec/gemspec_spec.rb --format 
> documentation failed
> mv ./.gem2deb.Gemfile.lock Gemfile.lock
> mv test_projects/monorepo/.gem2deb.Gemfile.lock 
> test_projects/monorepo/Gemfile.lock
> mv test_projects/parallel_tests/.gem2deb.Gemfile.lock 
> test_projects/parallel_tests/Gemfile.lock
> mv test_projects/rails/rspec_rails/.gem2deb.Gemfile.lock 
> test_projects/rails/rspec_rails/Gemfile.lock
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-simplecov.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027087: ruby-rubocop-performance: FTBFS: ERROR: Test "ruby3.1" failed: Failure/Error: subject(:config) { RuboCop::ConfigLoader.load_file('config/default.yml') }

[Antonio Terceiro]

Source: ruby-rubocop-performance
Version: 1.7.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-rubocop-performance failed to build. I retried with the version in
the archive, and obtained the same failure so this is not related to
ruby-rspec.

Relevant part of the build log (hopefully):
>  Failure/Error: subject(:config) { 
> RuboCop::ConfigLoader.load_file('config/default.yml') }
> 
>  RuboCop::ValidationError:
>`Performance` cops have been extracted to the `rubocop-performance` 
> gem.
>(obsolete configuration found in config/default.yml, please update it)
>  # 
> /usr/share/rubygems-integration/all/gems/rubocop-1.39.0/lib/rubocop/config_obsoletion.rb:43:in
>  `reject_obsolete!'
>  # 
> /usr/share/rubygems-integration/all/gems/rubocop-1.39.0/lib/rubocop/config_validator.rb:78:in
>  `check_obsoletions'
>  # 
> /usr/share/rubygems-integration/all/gems/rubocop-1.39.0/lib/rubocop/config_validator.rb:44:in
>  `validate'
>  # 
> /usr/share/rubygems-integration/all/gems/rubocop-1.39.0/lib/rubocop/config.rb:49:in
>  `check'
>  # 
> /usr/share/rubygems-integration/all/gems/rubocop-1.39.0/lib/rubocop/config.rb:38:in
>  `create'
>  # 
> /usr/share/rubygems-integration/all/gems/rubocop-1.39.0/lib/rubocop/config_loader.rb:57:in
>  `load_file'
>  # ./spec/project_spec.rb:5:in `block (3 levels) in '
>  # ./spec/project_spec.rb:34:in `block (4 levels) in '
>  # ./spec/project_spec.rb:33:in `each'
>  # ./spec/project_spec.rb:33:in `block (3 levels) in '
> 
> Finished in 24.75 seconds (files took 2.65 seconds to load)
> 7975 examples, 5 failures
> 
> Failed examples:
> 
> rspec ./spec/project_spec.rb:40 # RuboCop Performance Project default 
> configuration file sorts configuration keys alphabetically
> rspec ./spec/project_spec.rb:22 # RuboCop Performance Project default 
> configuration file requires a nicely formatted `VersionAdded` metadata for 
> all cops
> rspec ./spec/project_spec.rb:14 # RuboCop Performance Project default 
> configuration file has a nicely formatted description for all cops
> rspec ./spec/project_spec.rb:47 # RuboCop Performance Project default 
> configuration file has a SupportedStyles for all EnforcedStyle and 
> EnforcedStyle is valid
> rspec ./spec/project_spec.rb:32 # RuboCop Performance Project default 
> configuration file has a period at EOL of description
> 
> Randomized with seed 20775
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-rubocop-performance.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027088: ruby-seamless-database-pool: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: master_connection = send("#{master_config[:adapter]}_connection".to_sym, master_

[Antonio Terceiro]

Source: ruby-seamless-database-pool
Version: 1.0.20-3
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-seamless-database-pool failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: master_connection = 
> send("#{master_config[:adapter]}_connection".to_sym, master_config)
> 
># received :writer_connection with 
> unexpected arguments
>  expected: ({"adapter"=>"writer", "host"=>"master_host", 
> "pool_weight"=>1, "username"=>"user"}) (keyword arguments)
>   got: ({"adapter"=>"writer", "host"=>"master_host", 
> "pool_weight"=>1, "username"=>"user"}) (options hash)
>  # 
> ./lib/active_record/connection_adapters/seamless_database_pool_adapter.rb:15:in
>  `seamless_database_pool_connection'
>  # ./spec/seamless_database_pool_adapter_spec.rb:72:in `block (2 levels) 
> in '
> 
> Finished in 0.76099 seconds (files took 0.48193 seconds to load)
> 64 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/seamless_database_pool_adapter_spec.rb:38 # 
> SeamlessDatabasePoolAdapter ActiveRecord::Base extension should establish the 
> connections in the pool merging global options into the connection options
> 
> Randomized with seed 55666
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-seamless-database-pool.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027086: ruby-rest-client: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error:

[Antonio Terceiro]

Source: ruby-rest-client
Version: 2.1.0-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-rest-client failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error:
>Request.execute(options.merge(
>:method => :head,
>:url => url,
>:headers => headers,
>:log => log), &(block || @block))
> 
># received :execute with unexpected 
> arguments
>  expected: ({:headers=>{"X-Something"=>"1"}, :log=>nil, 
> :method=>:head, :password=>"mypass", :url=>"http://some/resource";, 
> :user=>"jane"}) (keyword arguments)
>   got: ({:headers=>{"X-Something"=>"1"}, :log=>nil, 
> :method=>:head, :password=>"mypass", :url=>"http://some/resource";, 
> :user=>"jane"}) (options hash)
>  # ./lib/restclient/resource.rb:60:in `head'
>  # ./spec/unit/resource_spec.rb:16:in `block (3 levels) in  (required)>'
> 
> Finished in 0.90862 seconds (files took 0.46198 seconds to load)
> 286 examples, 8 failures
> 
> Failed examples:
> 
> rspec ./spec/unit/request_spec.rb:506 # RestClient::Request class method 
> execute wraps constructor
> rspec ./spec/unit/resource_spec.rb:39 # RestClient::Resource Resource 
> delegation overrides resource headers
> rspec ./spec/unit/resource_spec.rb:19 # RestClient::Resource Resource 
> delegation POST
> rspec ./spec/unit/resource_spec.rb:29 # RestClient::Resource Resource 
> delegation PATCH
> rspec ./spec/unit/resource_spec.rb:9 # RestClient::Resource Resource 
> delegation GET
> rspec ./spec/unit/resource_spec.rb:24 # RestClient::Resource Resource 
> delegation PUT
> rspec ./spec/unit/resource_spec.rb:34 # RestClient::Resource Resource 
> delegation DELETE
> rspec ./spec/unit/resource_spec.rb:14 # RestClient::Resource Resource 
> delegation HEAD
> 
> Randomized with seed 8137
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-rest-client.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027083: ruby-notiffany: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: expect(foo_object).to receive(:notify).with("Hello", foo: "bar")

[Antonio Terceiro]

Source: ruby-notiffany
Version: 0.1.3-3
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-notiffany failed to build.

Relevant part of the build log (hopefully):
>   Failure/Error: expect(foo_object).to receive(:notify).with("Hello", 
> foo: "bar")
> 
> # received 
> :notify with unexpected arguments
>   expected: ("Hello", {:foo=>"bar"}) (keyword arguments)
>got: ("Hello", {:foo=>"bar"}) (options hash)
>   # ./spec/lib/notiffany/notifier_spec.rb:336:in `block (6 levels) in 
> '
> 
> Finished in 0.25327 seconds (files took 0.16632 seconds to load)
> 183 examples, 17 failures, 2 pending
> 
> Failed examples:
> 
> rspec ./spec/lib/notiffany/notifier/terminal_notifier_spec.rb:67 # 
> Notiffany::Notifier::TerminalNotifier#notify should allow the title to be 
> customized
> rspec ./spec/lib/notiffany/notifier/terminal_notifier_spec.rb:57 # 
> Notiffany::Notifier::TerminalNotifier#notify should call the notifier.
> rspec ./spec/lib/notiffany/notifier/terminal_notifier_spec.rb:78 # 
> Notiffany::Notifier::TerminalNotifier#notify without a title set should show 
> the app name in the title
> rspec ./spec/lib/notiffany/notifier/terminal_notifier_spec.rb:45 # 
> Notiffany::Notifier::TerminalNotifier#notify with options passed at 
> initialization overwrites object options with passed options
> rspec ./spec/lib/notiffany/notifier/terminal_notifier_spec.rb:38 # 
> Notiffany::Notifier::TerminalNotifier#notify with options passed at 
> initialization uses these options by default
> rspec ./spec/lib/notiffany/notifier/rb_notifu_spec.rb:80 # 
> Notiffany::Notifier::Notifu#notify without additional options shows the 
> notification with the default options
> rspec ./spec/lib/notiffany/notifier/rb_notifu_spec.rb:101 # 
> Notiffany::Notifier::Notifu#notify with additional options can override the 
> default options
> rspec ./spec/lib/notiffany/notifier/rb_notifu_spec.rb:40 # 
> Notiffany::Notifier::Notifu#notify with options passed at initialization uses 
> these options by default
> rspec ./spec/lib/notiffany/notifier/detected_spec.rb:112 # 
> Notiffany::Notifier::Detected#add with manually configured notifiers when not 
> available shows a warning
> rspec ./spec/lib/notiffany/notifier/detected_spec.rb:103 # 
> Notiffany::Notifier::Detected#add with manually configured notifiers when not 
> available does not add the library
> rspec ./spec/lib/notiffany/notifier/detected_spec.rb:108 # 
> Notiffany::Notifier::Detected#add with manually configured notifiers when not 
> available does not raise an error
> rspec ./spec/lib/notiffany/notifier/growl_spec.rb:144 # 
> Notiffany::Notifier::Growl#notify with options Growl cannot handle passes 
> options only Growl can handle
> rspec ./spec/lib/notiffany/notifier_spec.rb:182 # 
> Notiffany::Notifier#initialize with custom notifier config when connected 
> when enabled when supported when available adds the notifier to the 
> notifications
> rspec ./spec/lib/notiffany/notifier_spec.rb:145 # 
> Notiffany::Notifier#initialize with custom notifier config when not connected 
> when enabled when supported when available adds the notifier to the 
> notifications
> rspec ./spec/lib/notiffany/notifier_spec.rb:360 # Notiffany::Notifier.notify 
> with multiple notifiers when connected when enabled sends notifications
> rspec ./spec/lib/notiffany/notifier_spec.rb:368 # Notiffany::Notifier.notify 
> with multiple notifiers when connected when enabled when a child process 
> sends notifications
> rspec ./spec/lib/notiffany/notifier_spec.rb:335 # Notiffany::Notifier.notify 
> with multiple notifiers when not connected when a child process sends 
> notifications
> 
> Randomized with seed 32791
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-notiffany.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027082: ruby-mysql2: FTBFS: ERROR: Test "ruby3.1" failed: mysqld crashes at startup

[Antonio Terceiro]

Source: ruby-mysql2
Version: 0.5.3-4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-mysql2 failed to build. I retried it with the version in the
archive, and obtained the same failure.

Relevant part of the build log (hopefully):
> adduser: Warning: The home dir /nonexistent you specified can't be accessed: 
> No such file or directory
> Unpacking mariadb-server-10.6 (1:10.6.11-1) ...
> Selecting previously unselected package libpython3.10-minimal:amd64.
> Preparing to unpack .../libpython3.10-minimal_3.10.9-1_amd64.deb ...
> Unpacking libpython3.10-minimal:amd64 (3.10.9-1) ...
> Selecting previously unselected package libexpat1:amd64.
> Preparing to unpack .../libexpat1_2.5.0-1_amd64.deb ...
> Unpacking libexpat1:amd64 (2.5.0-1) ...
> Selecting previously unselected package python3.10-minimal.
> Preparing to unpack .../python3.10-minimal_3.10.9-1_amd64.deb ...
> Unpacking python3.10-minimal (3.10.9-1) ...
> Setting up libpython3.10-minimal:amd64 (3.10.9-1) ...
> Setting up libexpat1:amd64 (2.5.0-1) ...
> Setting up python3.10-minimal (3.10.9-1) ...
> Selecting previously unselected package python3-minimal.
> (Reading database ... 17541 files and directories currently installed.)
> Preparing to unpack .../0-python3-minimal_3.10.6-3+b1_amd64.deb ...
> Unpacking python3-minimal (3.10.6-3+b1) ...
> Selecting previously unselected package media-types.
> Preparing to unpack .../1-media-types_8.0.0_all.deb ...
> Unpacking media-types (8.0.0) ...
> Selecting previously unselected package libmpdec3:amd64.
> Preparing to unpack .../2-libmpdec3_2.5.1-2_amd64.deb ...
> Unpacking libmpdec3:amd64 (2.5.1-2) ...
> Selecting previously unselected package libsqlite3-0:amd64.
> Preparing to unpack .../3-libsqlite3-0_3.40.0-2_amd64.deb ...
> Unpacking libsqlite3-0:amd64 (3.40.0-2) ...
> Selecting previously unselected package libpython3.10-stdlib:amd64.
> Preparing to unpack .../4-libpython3.10-stdlib_3.10.9-1_amd64.deb ...
> Unpacking libpython3.10-stdlib:amd64 (3.10.9-1) ...
> Selecting previously unselected package python3.10.
> Preparing to unpack .../5-python3.10_3.10.9-1_amd64.deb ...
> Unpacking python3.10 (3.10.9-1) ...
> Selecting previously unselected package libpython3-stdlib:amd64.
> Preparing to unpack .../6-libpython3-stdlib_3.10.6-3+b1_amd64.deb ...
> Unpacking libpython3-stdlib:amd64 (3.10.6-3+b1) ...
> Setting up python3-minimal (3.10.6-3+b1) ...
> Selecting previously unselected package python3.
> (Reading database ... 17953 files and directories currently installed.)
> Preparing to unpack .../000-python3_3.10.6-3+b1_amd64.deb ...
> Unpacking python3 (3.10.6-3+b1) ...
> Selecting previously unselected package netbase.
> Preparing to unpack .../001-netbase_6.4_all.deb ...
> Unpacking netbase (6.4) ...
> Selecting previously unselected package sensible-utils.
> Preparing to unpack .../002-sensible-utils_0.0.17_all.deb ...
> Unpacking sensible-utils (0.0.17) ...
> Selecting previously unselected package openssl.
> Preparing to unpack .../003-openssl_3.0.7-1_amd64.deb ...
> Unpacking openssl (3.0.7-1) ...
> Selecting previously unselected package ca-certificates.
> Preparing to unpack .../004-ca-certificates_20211016_all.deb ...
> Unpacking ca-certificates (20211016) ...
> Selecting previously unselected package libmagic-mgc.
> Preparing to unpack .../005-libmagic-mgc_1%3a5.41-4_amd64.deb ...
> Unpacking libmagic-mgc (1:5.41-4) ...
> Selecting previously unselected package libmagic1:amd64.
> Preparing to unpack .../006-libmagic1_1%3a5.41-4_amd64.deb ...
> Unpacking libmagic1:amd64 (1:5.41-4) ...
> Selecting previously unselected package file.
> Preparing to unpack .../007-file_1%3a5.41-4_amd64.deb ...
> Unpacking file (1:5.41-4) ...
> Selecting previously unselected package gettext-base.
> Preparing to unpack .../008-gettext-base_0.21-10_amd64.deb ...
> Unpacking gettext-base (0.21-10) ...
> Selecting previously unselected package libuchardet0:amd64.
> Preparing to unpack .../009-libuchardet0_0.0.7-1_amd64.deb ...
> Unpacking libuchardet0:amd64 (0.0.7-1) ...
> Selecting previously unselected package groff-base.
> Preparing to unpack .../010-groff-base_1.22.4-9_amd64.deb ...
> Unpacking groff-base (1.22.4-9) ...
> Selecting previously unselected package bsdextrautils.
> Preparing to unpack .../011-bsdextrautils_2.38.1-4_amd64.deb ...
> Unpacking bsdextrautils (2.38.1-4) ...
> Selecting previously unselected package libpipeline1:amd64.
> Preparing to unpack .../012-libpipeline1_1.5.7-1_amd64.deb ...
> Unpacking libpipeline1:amd64 (1.5.7-1) ...
> Selecting previously unselected package man-db.
> Preparing to unpack .../013-man-db_2.11.1-1_amd64.deb ...
> Unpacking man-db (2.11.1-1) ...
> Selecting previously unselected package m4.
> Preparing to unpack .../014-m4_1.4.19-1_amd64.deb ...
> Unpacking m4 (1.4.19-1) ...
> Selecting previously unselected p

Bug#1027081: ruby-multi-json: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: self.load_options = self.dump_options = value

[Antonio Terceiro]

Source: ruby-multi-json
Version: 1.14.1-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-multi-json failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: self.load_options = self.dump_options = value
> 
>MultiJson received :dump_options= with unexpected arguments
>  expected: ({:foo=>"bar"}) (keyword arguments)
>   got: ({:foo=>"bar"}) (options hash)
>  # ./lib/multi_json.rb:15:in `default_options='
>  # ./spec/multi_json_spec.rb:153:in `block (4 levels) in '
>  # ./spec/spec_helper.rb:12:in `silence_warnings'
>  # ./spec/multi_json_spec.rb:153:in `block (3 levels) in '
> 
> Finished in 0.11683 seconds (files took 0.11731 seconds to load)
> 29 examples, 1 failure, 4 pending
> 
> Failed examples:
> 
> rspec ./spec/multi_json_spec.rb:150 # MultiJson default options sets both 
> load and dump options
> 
> Randomized with seed 1741
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> spec/multi_json_spec.rb failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-multi-json.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027080: ruby-localhost: FTBFS: tests fail randomly

[Antonio Terceiro]

Source: ruby-localhost
Version: 1.1.9-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-localhost failed to build. I retried it with ruby-rspec 3.10 from
the archive, and I got one successfull build, and one failure exactly
like the one below. So this means the test suite fails randomly, and
that is a problem.

Relevant part of the build log (hopefully):
>  2.2) Failure/Error: expect(status).to be_success
> expected `#.success?` to be 
> truthy, got false
>   # ./spec/localhost/protocol_spec.rb:42:in `block (2 levels) in  (required)>'
>   # 
> /usr/share/rubygems-integration/all/gems/async-rspec-1.16.1/lib/async/rspec/reactor.rb:93:in
>  `block (4 levels) in '
>   # 
> /usr/share/rubygems-integration/all/gems/async-rspec-1.16.1/lib/async/rspec/reactor.rb:57:in
>  `block in run_in_reactor'
>   # 
> /usr/share/rubygems-integration/all/gems/async-1.30.3/lib/async/task.rb:261:in
>  `block in make_fiber'
> 
> Finished in 2.71 seconds (files took 0.22921 seconds to load)
> 10 examples, 2 failures
> 
> Failed examples:
> 
> rspec './spec/localhost/protocol_spec.rb[1:1:2]' # Localhost::Authority 
> behaves like valid protocol can connect using HTTP over TLSv1.2
> rspec './spec/localhost/protocol_spec.rb[1:2:2]' # Localhost::Authority 
> behaves like valid protocol can connect using HTTP over default
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 

The full build log is attached.

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


ruby-localhost.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027079: ruby-listen: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: @snapshots[dir].invalidate(type, rel_path, options)

[Antonio Terceiro]

Source: ruby-listen
Version: 3.7.0-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-listen failed to build.

Relevant part of the build log (hopefully):
>   Failure/Error: @snapshots[dir].invalidate(type, rel_path, options)
> 
> # received :invalidate 
> with unexpected arguments
>   expected: (:dir, ".", {:recursive=>true}) (keyword arguments)
>got: (:dir, ".", {:recursive=>true}) (options hash)
>   # ./lib/listen/adapter/base.rb:108:in `_queue_change'
>   # ./lib/listen/adapter/polling.rb:36:in `_process_event'
>   # ./lib/listen/adapter/base.rb:44:in `block (2 levels) in configure'
>   # ./lib/listen/adapter/polling.rb:26:in `block (2 levels) in _run'
>   # ./lib/listen/adapter/polling.rb:25:in `each'
>   # ./lib/listen/adapter/polling.rb:25:in `block in _run'
>   # ./lib/listen/adapter/polling.rb:23:in `loop'
>   # ./lib/listen/adapter/polling.rb:23:in `_run'
>   # ./lib/listen/adapter/base.rb:79:in `block in start'
>   # ./lib/listen/thread.rb:26:in `rescue_and_log'
>   # ./lib/listen/thread.rb:18:in `block in new'
> 
> Finished in 0.37831 seconds (files took 0.20262 seconds to load)
> 312 examples, 22 failures, 1 pending
> 
> Failed examples:
> 
> rspec ./spec/lib/listen/adapter/linux_spec.rb:137 # Listen::Adapter::Linux 
> instance methods _callback recognizes close_write as modify
> rspec ./spec/lib/listen/adapter/linux_spec.rb:142 # Listen::Adapter::Linux 
> instance methods _callback recognizes moved_to as moved_to
> rspec ./spec/lib/listen/adapter/linux_spec.rb:147 # Listen::Adapter::Linux 
> instance methods _callback recognizes moved_from as moved_from
> rspec ./spec/lib/listen/directory_spec.rb:275 # Listen::Directory#scan with 
> recursive on with empty record with subdir present in dir snapshots changes 
> for subdir
> rspec ./spec/lib/listen/directory_spec.rb:218 # Listen::Directory#scan with 
> recursive on with file.rb & subdir in record with empty dir snapshots changes 
> for file & subdir path
> rspec ./spec/lib/listen/directory_spec.rb:239 # Listen::Directory#scan with 
> recursive on with file.rb & subdir in record with subdir2 path present 
> snapshots changes for file, file2 & subdir paths
> rspec ./spec/lib/listen/directory_spec.rb:75 # Listen::Directory#scan with 
> recursive off with file & subdir in record with empty dir snapshots changes 
> for file path and dir that doesn't exist
> rspec ./spec/lib/listen/directory_spec.rb:92 # Listen::Directory#scan with 
> recursive off with file & subdir in record when subdir is removed notices 
> subdir does not exist
> rspec ./spec/lib/listen/adapter/base_spec.rb:91 # Listen::Adapter::Base 
> handling events when an event occurs passes invalidates the snapshot based on 
> the event
> rspec ./spec/lib/listen/listener_spec.rb:300 # Listen::Listener#ignore! with 
> existing ignore options deletes ignore options
> rspec ./spec/lib/listen/listener_spec.rb:289 # Listen::Listener#ignore! with 
> existing ignore! options overwrites existing ignore options
> rspec ./spec/lib/listen/listener_spec.rb:247 # Listen::Listener#ignore with 
> existing ignore options adds up to existing ignore options
> rspec ./spec/lib/listen/listener_spec.rb:262 # Listen::Listener#ignore with 
> existing ignore options (array) adds up to existing ignore options
> rspec ./spec/lib/listen/listener_spec.rb:313 # Listen::Listener#only with 
> existing only options overwrites existing ignore options
> rspec ./spec/lib/listen/silencer/controller_spec.rb:43 # 
> Listen::Silencer::Controller append_ignores with no previous :ignore rules 
> when providing as array sets the given :ignore rules
> rspec ./spec/lib/listen/silencer/controller_spec.rb:35 # 
> Listen::Silencer::Controller append_ignores with no previous :ignore rules 
> when providing multiple arguments sets the given :ignore rules as a flat array
> rspec ./spec/lib/listen/silencer/controller_spec.rb:27 # 
> Listen::Silencer::Controller append_ignores with no previous :ignore rules 
> when providing a single regexp as argument sets the given :ignore rules as 
> array
> rspec ./spec/lib/listen/silencer/controller_spec.rb:88 # 
> Listen::Silencer::Controller append_ignores with previous :ignore rules when 
> providing as array appends the given :ignore rules
> rspec ./spec/lib/listen/silencer/controller_spec.rb:79 # 
> Listen::Silencer::Controller append_ignores with previous :ignore rules when 
> providing multiple arguments appends the given :ignore rules as a flat array
> rspec ./spec/lib/listen/silencer/controller_spec.rb:62 # 
> Listen::Silencer::Controller append_ignores with previous :ignore rules when 
> providing a nil reconfigures with existing :ignore rules
> rspec ./spec/lib/listen/silencer/controller_spec.rb:70 # 
> Listen::Silencer::Controller append_ignores wit

Bug#1027078: ruby-jira: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: result.push(client.Issue.build(issue))

[Antonio Terceiro]

Source: ruby-jira
Version: 2.1.5-3
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-jira failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: result.push(client.Issue.build(issue))
> 
># received :build with unexpected arguments
>  expected: ({"id"=>"1", "summary"=>"Bugs Everywhere"}) (keyword 
> arguments)
>   got: ({"id"=>"1", "summary"=>"Bugs Everywhere"}) (options hash)
>  # ./lib/jira/resource/issue.rb:59:in `block (2 levels) in all'
>  # ./lib/jira/resource/issue.rb:58:in `map'
>  # ./lib/jira/resource/issue.rb:58:in `block in all'
>  # ./lib/jira/resource/issue.rb:53:in `loop'
>  # ./lib/jira/resource/issue.rb:53:in `all'
>  # ./spec/jira/resource/issue_spec.rb:52:in `block (2 levels) in  (required)>'
> 
> Deprecation Warnings:
> 
> The implicit block expectation syntax is deprecated, you should pass a block 
> rather than an argument to `expect` to use the provided block expectation 
> matcher or the matcher must implement `supports_value_expectations?`. e.g  
> `expect { value }.to raise ArgumentError with "Required option :deadbeef 
> missing"` not `expect(value).to raise ArgumentError with "Required option 
> :deadbeef missing"`
> 
> The implicit block expectation syntax is deprecated, you should pass a block 
> rather than an argument to `expect` to use the provided block expectation 
> matcher or the matcher must implement `supports_value_expectations?`. e.g  
> `expect { value }.to raise JIRA::HTTPError` not `expect(value).to raise 
> JIRA::HTTPError`
> 
> 
> 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.
> 
> 2 deprecation warnings total
> 
> Finished in 0.14389 seconds (files took 0.80057 seconds to load)
> 221 examples, 2 failures
> 
> Failed examples:
> 
> rspec ./spec/jira/oauth_client_spec.rb:57 # JIRA::OauthClient authenticating 
> with oauth the access token initializes
> rspec ./spec/jira/resource/issue_spec.rb:37 # JIRA::Resource::Issue should 
> find all issues
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> ./spec/jira/base_factory_spec.rb ./spec/jira/base_spec.rb 
> ./spec/jira/has_many_proxy_spec.rb ./spec/jira/http_client_spec.rb 
> ./spec/jira/http_error_spec.rb ./spec/jira/jwt_uri_builder_spec.rb 
> ./spec/jira/oauth_client_spec.rb ./spec/jira/request_client_spec.rb 
> ./spec/jira/resource/agile_spec.rb ./spec/jira/resource/attachment_spec.rb 
> ./spec/jira/resource/board_spec.rb ./spec/jira/resource/createmeta_spec.rb 
> ./spec/jira/resource/field_spec.rb ./spec/jira/resource/filter_spec.rb 
> ./spec/jira/resource/issue_spec.rb ./spec/jira/resource/issuelink_spec.rb 
> ./spec/jira/resource/project_factory_spec.rb 
> ./spec/jira/resource/project_spec.rb ./spec/jira/resource/sprint_spec.rb 
> ./spec/jira/resource/user_factory_spec.rb 
> ./spec/jira/resource/worklog_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-jira.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027077: ruby-invisible-captcha: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error:

[Antonio Terceiro]

Source: ruby-invisible-captcha
Version: 1.1.0-5
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-invisible-captcha failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error:
>expect(dummy_handler).to receive(:handle_event).once.with(
>  message: "Invisible Captcha honeypot param 'subtitle' was present.",
>  remote_ip: '0.0.0.0',
>  user_agent: 'Rails Testing',
>  controller: 'topics',
>  action: 'create',
>  url: 'http://test.host/topics',
>  params: {
>topic: { subtitle: "foo"},
>controller: 'topics',
> 
># received :handle_event with unexpected arguments
>  expected: ({:action=>"create", :controller=>"topics", 
> :message=>"Invisible Captcha honeypot param 'subtitle' was...itle=>"foo"}}, 
> :remote_ip=>"0.0.0.0", :url=>"http://test.host/topics";, :user_agent=>"Rails 
> Testing"}) (keyword arguments)
>   got: ({:action=>"create", :controller=>"topics", 
> :message=>"Invisible Captcha honeypot param 'subtitle' was...tle"=>"foo"}}, 
> :remote_ip=>"0.0.0.0", :url=>"http://test.host/topics";, :user_agent=>"Rails 
> Testing"}) (options hash)
>Diff:
>@@ -2,7 +2,7 @@
>   :controller=>"topics",
>   :message=>"Invisible Captcha honeypot param 'subtitle' was 
> present.",
>   :params=>
>-   {:action=>"create", :controller=>"topics", 
> :topic=>{:subtitle=>"foo"}},
>+   {"action"=>"create", "controller"=>"topics", 
> "topic"=>{"subtitle"=>"foo"}},
>   :remote_ip=>"0.0.0.0",
>   :url=>"http://test.host/topics";,
>   :user_agent=>"Rails Testing"}]
>  # ./spec/controllers_spec.rb:164:in `block (4 levels) in  (required)>'
> 
> Finished in 8.44 seconds (files took 1.13 seconds to load)
> 28 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/controllers_spec.rb:160 # InvisibleCaptcha::ControllerExt 
> honeypot attribute ActiveSupport::Notifications dispatches an 
> `invisible_captcha.spam_detected` event
> 
> Randomized with seed 608
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 

The full build log is attached.

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


signature.asc
Description: PGP signature

Bug#1027076: ruby-influxdb: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

Source: ruby-influxdb
Version: 0.8.1-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-influxdb failed to build.

Relevant part of the build log (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-influxdb/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"influxdb\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-influxdb/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> ./spec/influxdb/cases/query_batch_spec.rb 
> ./spec/influxdb/cases/query_cluster_spec.rb 
> ./spec/influxdb/cases/query_continuous_query_spec.rb 
> ./spec/influxdb/cases/query_core_spec.rb 
> ./spec/influxdb/cases/query_database_spec.rb 
> ./spec/influxdb/cases/query_retention_policy_spec.rb 
> ./spec/influxdb/cases/query_series_spec.rb 
> ./spec/influxdb/cases/query_shard_spec.rb 
> ./spec/influxdb/cases/query_user_spec.rb 
> ./spec/influxdb/cases/query_with_params_spec.rb 
> ./spec/influxdb/cases/querying_issue_7000_spec.rb 
> ./spec/influxdb/cases/querying_spec.rb 
> ./spec/influxdb/cases/retry_requests_spec.rb 
> ./spec/influxdb/cases/show_field_keys_spec.rb 
> ./spec/influxdb/cases/udp_client_spec.rb 
> ./spec/influxdb/cases/write_points_spec.rb ./spec/influxdb/client_spec.rb 
> ./spec/influxdb/config_spec.rb ./spec/influxdb/logging_spec.rb 
> ./spec/influxdb/max_queue_spec.rb ./spec/influxdb/point_value_spec.rb 
> ./spec/influxdb/query_builder_spec.rb ./spec/influxdb/time_conversion_spec.rb 
> ./spec/influxdb/worker_spec.rb ./spec/smoke/smoke_batch_spec.rb 
> ./spec/smoke/smoke_spec.rb --format documentation
> SMOKE TESTS ARE NOT CURRENTLY RUNNING
> Run options: exclude {:smoke=>true}
> Run options: exclude {:smoke=>true}
> 
> InfluxDB::Client
>   #batch
> is expected to be a kind of InfluxDB::Query::Batch
> .#execute
>   is expected to eq []
> .#add
>   returns statement id
> .  block form
> returns statement id
> .  #batch.execute
> with multiple queries when there is no data for a query
>   should return responses for all statements
> .with a group by tag query
>   should return a single result
> .
> InfluxDB::Client
>   #create_cluster_admin
> with existing admin user
>   should GET to create a new cluster admin
> .with no admin user
>   should GET to create a new cluster admin
> .  #list_cluster_admins
> should GET a list of cluster admins
> .  #revoke_cluster_admin_privileges
> should GET to revoke cluster admin privileges from a user
> .
> InfluxDB::Client
>   #list_continuous_queries
> should GET a list of continuous queries for specified db only
> .  #create_continuous_query
> without resampling
>   should GET to create a new continuous query
> .with resampling
>   EVERY 
> should GET to create a new continuous query
> .  FOR 
> should GET to create a new continuous query
> .  EVERY  FOR 
> should GET to create a new continuous query
> .  #delete_continuous_query
> should GET to remove continuous query
> .
> InfluxDB::Client
>   #query
> should handle responses with no values
> .
> InfluxDB::Client
>   #create_database
> from param
>   should GET to create a new database
> .from config
>   should GET to create a new database using database name from config
> .  #delete_database
> from param
>   should GET to remove a database
> .from config
>   should GET to remove a database using d

Bug#1027075: ruby-guard: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

Source: ruby-guard
Version: 2.18.0-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-guard failed to build.

Relevant part of the build log (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-guard/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"guard\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-guard/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-guard/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation
> Run options: include {:focus=>true}
> 
> All examples were filtered out; ignoring {:focus=>true}
> 
> Randomized with seed 28844
> 
> Guard::UI
>   .deprecation
> with GUARD_GEM_SILENCE_DEPRECATIONS set to 1
>   silences deprecations
> with GUARD_GEM_SILENCE_DEPRECATIONS unset
>   behaves like a logger method
> resets the line with the :reset option
> logs the message with the given severity
> with the :only option
>   prevents logging other messages
>   allows logging matching messages
> with the :except option
>   prevents logging matching messages
>   allows logging other messages
>   .action_with_scopes
> without a scope
>   with a global plugin scope
> shows the global plugin scoped action
>   with a global group scope
> shows the global group scoped action
> with a groups scope
> stub me: ENV[COLUMNS]!
> 
> Finished in 0.17765 seconds (files took 0.47034 seconds to load)
> 10 examples, 0 failures
> 
> Randomized with seed 28844
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed.


The full build log is attached.

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


ruby-guard.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027074: ruby-grape: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: namespace_inheritable(:version_options, options)

[Antonio Terceiro]

Source: ruby-grape
Version: 1.6.2-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-grape failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: namespace_inheritable(:version_options, options)
> 
>#<# (class)> received :namespace_inheritable 
> with unexpected arguments
>  expected: (:version_options, {:using=>:path}) (keyword arguments)
>   got: (:version_options, {:using=>:path}) (options hash)
>  # ./lib/grape/dsl/routing.rb:50:in `version'
>  # ./spec/grape/dsl/routing_spec.rb:25:in `block (3 levels) in 
> '
> 
> Finished in 4.2 seconds (files took 1.08 seconds to load)
> 2108 examples, 6 failures, 1 pending
> 
> Failed examples:
> 
> rspec ./spec/grape/dsl/request_response_spec.rb:164 # 
> Grape::DSL::RequestResponse.rescue_from list of exceptions is passed sets 
> hash of exceptions as rescue handlers
> rspec ./spec/grape/dsl/request_response_spec.rb:170 # 
> Grape::DSL::RequestResponse.rescue_from list of exceptions is passed rescues 
> only base handlers if rescue_subclasses: false option is passed
> rspec ./spec/grape/dsl/request_response_spec.rb:176 # 
> Grape::DSL::RequestResponse.rescue_from list of exceptions is passed sets 
> given proc as rescue handler for each key in hash
> rspec ./spec/grape/dsl/request_response_spec.rb:183 # 
> Grape::DSL::RequestResponse.rescue_from list of exceptions is passed sets 
> given block as rescue handler for each key in hash
> rspec ./spec/grape/dsl/request_response_spec.rb:190 # 
> Grape::DSL::RequestResponse.rescue_from list of exceptions is passed sets a 
> rescue handler declared through :with option for each key in hash
> rspec ./spec/grape/dsl/routing_spec.rb:21 # Grape::DSL::Routing.version sets 
> a version for route
> 
> [Coveralls] Outside the CI environment, not sending data.
> Stopped processing SimpleCov as a previous error not related to SimpleCov has 
> been detected
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> ./spec/grape/api/custom_validations_spec.rb 
> ./spec/grape/api/deeply_included_options_spec.rb 
> ./spec/grape/api/defines_boolean_in_params_spec.rb 
> ./spec/grape/api/inherited_helpers_spec.rb ./spec/grape/api/instance_spec.rb 
> ./spec/grape/api/invalid_format_spec.rb 
> ./spec/grape/api/namespace_parameters_in_route_spec.rb 
> ./spec/grape/api/nested_helpers_spec.rb 
> ./spec/grape/api/optional_parameters_in_route_spec.rb 
> ./spec/grape/api/parameters_modification_spec.rb 
> ./spec/grape/api/patch_method_helpers_spec.rb 
> ./spec/grape/api/recognize_path_spec.rb 
> ./spec/grape/api/required_parameters_in_route_spec.rb 
> ./spec/grape/api/required_parameters_with_invalid_method_spec.rb 
> ./spec/grape/api/routes_with_requirements_spec.rb 
> ./spec/grape/api/shared_helpers_exactly_one_of_spec.rb 
> ./spec/grape/api/shared_helpers_spec.rb ./spec/grape/api_remount_spec.rb 
> ./spec/grape/api_spec.rb ./spec/grape/config_spec.rb 
> ./spec/grape/dsl/callbacks_spec.rb ./spec/grape/dsl/configuration_spec.rb 
> ./spec/grape/dsl/desc_spec.rb ./spec/grape/dsl/headers_spec.rb 
> ./spec/grape/dsl/helpers_spec.rb ./spec/grape/dsl/inside_route_spec.rb 
> ./spec/grape/dsl/logger_spec.rb ./spec/grape/dsl/middleware_spec.rb 
> ./spec/grape/dsl/parameters_spec.rb ./spec/grape/dsl/request_response_spec.rb 
> ./spec/grape/dsl/routing_spec.rb ./spec/grape/dsl/settings_spec.rb 
> ./spec/grape/dsl/validations_spec.rb ./spec/grape/endpoint/declared_spec.rb 
> ./spec/grape/endpoint_spec.rb ./spec/grape/exceptions/base_spec.rb 
> ./spec/grape/exceptions/body_parse_errors_spec.rb 
> ./spec/grape/exceptions/invalid_accept_header_spec.rb 
> ./spec/grape/exceptions/invalid_formatter_spec.rb 
> ./spec/grape/exceptions/invalid_response_spec.rb 
> ./spec/grape/exceptions/invalid_versioner_option_spec.rb 
> ./spec/grape/exceptions/missing_mime_type_spec.rb 
> ./spec/grape/exceptions/missing_option_spec.rb 
> ./spec/grape/exceptions/unknown_options_spec.rb 
> ./spec/grape/exceptions/unknown_validator_spec.rb 
> ./spec/grape/exceptions/validation_errors_spec.rb 
> ./spec/grape/exceptions/validation_spec.rb 
> ./spec/grape/extensions/param_builders/hash_spec.rb 
> ./spec/grape/extensions/param_builders/hash_with_indifferent_access_spec.rb 
> ./spec/grape/extensions/param_builders/hashie/mash_spec.rb 
> ./spec/grape/integration/global_namespace_function_spec.rb 
> ./spec/grape/integration/rack_sendfile_spec.rb 
> ./spec/grape/integration/rack_spec.rb ./spec/grape/loading_spec.rb 
> ./spec/grape/middleware/auth/base_spec.rb 
> ./spec/grape/middleware/auth/dsl_spec.rb 
> ./spec/grape/middleware/auth/strategies_spec.rb 
> ./spec/grape/middleware/base_spec.

Bug#1027073: ruby-gh: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: expect { subject['/x'] }.to raise_error(GH::Error(:response_status => 500))

[Antonio Terceiro]

Source: ruby-gh
Version: 0.18.0-4
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-gh failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: expect { subject['/x'] }.to 
> raise_error(GH::Error(:response_status => 500))
> 
>expected #, got 
> #https://api.github.com> 
> received :http with unexp...ken", {"Authorization"=>"Basic Zm9vOmJhcg==", 
> :body=>"{\"access_token\": \"baz\"}"}) (options hash)> with backtrace:
>  # ./lib/gh/token_check.rb:28:in `http'
>  # ./lib/gh/token_check.rb:21:in `check_token'
>  # ./lib/gh/token_check.rb:27:in `http'
>  # ./lib/gh/remote.rb:66:in `fetch_resource'
>  # ./lib/gh/wrapper.rb:82:in `[]'
>  # ./spec/token_check_spec.rb:25:in `block (3 levels) in  (required)>'
>  # ./spec/token_check_spec.rb:25:in `block (2 levels) in  (required)>'
>  # ./spec/token_check_spec.rb:25:in `block (2 levels) in '
> 
> Deprecation Warnings:
> 
> Using `should_receive` from rspec-mocks' old `:should` syntax without 
> explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or 
> explicitly enable `:should` instead. Called from 
> /<>/spec/custom_limit_spec.rb:17:in `block (2 levels) in  (required)>'.
> 
> 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/cache_spec.rb:7: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.
> 
> 2 deprecation warnings total
> 
> Finished in 1 second (files took 0.46356 seconds to load)
> 115 examples, 2 failures, 9 pending
> 
> Failed examples:
> 
> rspec ./spec/token_check_spec.rb:10 # GH::TokenCheck adds client_id and 
> client_secret to a request
> rspec ./spec/token_check_spec.rb:19 # GH::TokenCheck does not swallow other 
> status codes
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-gh.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027072: ruby-fission: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: Fission::Action::VM::Stopper.new(self).stop(options)

[Antonio Terceiro]

Source: ruby-fission
Version: 0.5.0-2.1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-fission failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: Fission::Action::VM::Stopper.new(self).stop(options)
> 
># received :stop with unexpected arguments
>  expected: ({:hard=>true}) (keyword arguments)
>   got: ({:hard=>true}) (options hash)
>  # ./lib/fission/vm.rb:135:in `stop'
>  # ./spec/fission/vm_spec.rb:93:in `block (3 levels) in '
> 
> Deprecation Warnings:
> 
> Using `should_receive` from rspec-mocks' old `:should` syntax without 
> explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or 
> explicitly enable `:should` instead. Called from 
> /<>/spec/fission/action/execute_shell_command_spec.rb:12:in 
> `block (3 levels) in '.
> 
> 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/fission/action/execute_shell_command_spec.rb:18:in 
> `block (3 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.
> 
> 2 deprecation warnings total
> 
> Finished in 0.8034 seconds (files took 0.32206 seconds to load)
> 350 examples, 2 failures
> 
> Failed examples:
> 
> rspec ./spec/fission/vm_spec.rb:51 # Fission::VM start should return a 
> successful response when starting headless
> rspec ./spec/fission/vm_spec.rb:88 # Fission::VM stop should return a 
> successful response when stopping hard
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb failed
> ERROR: Test "ruby3.1" failed: 


The full build log is attached.

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


ruby-fission.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027071: ruby-eim-xml: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: EimXML::Formatter.write(element, opt.merge(:preservers=>PRESERVE_SPACES))

[Antonio Terceiro]

Source: ruby-eim-xml
Version: 0.0.4-4.1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-eim-xml failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: EimXML::Formatter.write(element, 
> opt.merge(:preservers=>PRESERVE_SPACES))
> 
># received :write with unexpected arguments
>  expected: (, {:opt=>:dummy, 
> :preservers=>[EimXML::XHTML::PreserveSpace_]}) (keyword arguments)
>   got: (, {:opt=>:dummy, 
> :preservers=>[EimXML::XHTML::PreserveSpace_]}) (options hash)
>  # ./lib/eim_xml/xhtml.rb:150:in `write'
>  # ./spec/xhtml_spec.rb:432:in `block (3 levels) in '
> 
> Finished in 0.06762 seconds (files took 0.1275 seconds to load)
> 111 examples, 2 failures
> 
> Failed examples:
> 
> rspec ./spec/formatter_spec.rb:240 # EimXML::Formatter::ElementWrapper#each 
> will give options from formatter
> rspec ./spec/xhtml_spec.rb:429 # EimXML::XHTML::Formatter#write should set 
> :preservers=>PRESERVE_SPACES to default option
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern spec/\*\*\{,/\*/\*\*\}/\*_spec.rb failed
> ERROR: Test "ruby3.1" failed: 

The full build log is attached.

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


ruby-eim-xml.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027067: ruby-bunny: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: expect(ch).to receive(:exchange_bind).with(src1, dst, routing_key: "abc")

[Antonio Terceiro]

Source: ruby-bunny
Version: 2.19.0-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
ruby-bunny failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: expect(ch).to receive(:exchange_bind).with(src1, dst, 
> routing_key: "abc")
> 
># received :exchange_bind 
> with unexpected arguments
>  expected: (# @channel=#, 
> @name="s...nowait=>false}, @durable=nil, @auto_delete=nil, @internal=nil, 
> @arguments=nil, @bindings=#>, # @channel=#, 
> @name="d...o_delete=nil, @internal=nil, @arguments=nil, @bindings=# {}>>, :opts=>{:routing_key=>"jkl"}}}>>, {:routing_key=>"abc"}) (keyword 
> arguments)
>   got: (# @channel=#, 
> @name="s...nowait=>false}, @durable=nil, @auto_delete=nil, @internal=nil, 
> @arguments=nil, @bindings=#>, # @channel=#, 
> @name="d...o_delete=nil, @internal=nil, @arguments=nil, @bindings=# {}>>, :opts=>{:routing_key=>"jkl"}}}>>, {:routing_key=>"abc"}) (1 time)
>(# @channel=#, 
> @name="s...nowait=>false}, @durable=nil, @auto_delete=nil, @internal=nil, 
> @arguments=nil, @bindings=#>, # @channel=#, 
> @name="d...o_delete=nil, @internal=nil, @arguments=nil, @bindings=# {}>>, :opts=>{:routing_key=>"jkl"}}}>>, {:routing_key=>"ghi"}) (1 time)
>(# @channel=#, 
> @name="s...nowait=>false}, @durable=nil, @auto_delete=nil, @internal=nil, 
> @arguments=nil, @bindings=#>, # @channel=#, 
> @name="d...o_delete=nil, @internal=nil, @arguments=nil, @bindings=# {}>>, :opts=>{:routing_key=>"jkl"}}}>>, {:routing_key=>"jkl"}) (1 time) 
> (options hash)
>  # ./spec/unit/exchange_recovery_spec.rb:31:in `block (3 levels) in 
> '
> 
> Finished in 4 minutes 0.2 seconds (files took 0.24523 seconds to load)
> 324 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/unit/exchange_recovery_spec.rb:7 # Bunny::Exchange recovery 
> recovers exchange bindings, unless already unbound
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> spec/higher_level_api/integration/basic_ack_spec.rb 
> spec/higher_level_api/integration/basic_cancel_spec.rb 
> spec/higher_level_api/integration/basic_consume_spec.rb 
> spec/higher_level_api/integration/basic_consume_with_objects_spec.rb 
> spec/higher_level_api/integration/basic_get_spec.rb 
> spec/higher_level_api/integration/basic_nack_spec.rb 
> spec/higher_level_api/integration/basic_publish_spec.rb 
> spec/higher_level_api/integration/basic_qos_spec.rb 
> spec/higher_level_api/integration/basic_reject_spec.rb 
> spec/higher_level_api/integration/basic_return_spec.rb 
> spec/higher_level_api/integration/channel_close_spec.rb 
> spec/higher_level_api/integration/channel_open_spec.rb 
> spec/higher_level_api/integration/consumer_cancellation_notification_spec.rb 
> spec/higher_level_api/integration/dead_lettering_spec.rb 
> spec/higher_level_api/integration/exchange_bind_spec.rb 
> spec/higher_level_api/integration/exchange_declare_spec.rb 
> spec/higher_level_api/integration/exchange_delete_spec.rb 
> spec/higher_level_api/integration/exchange_unbind_spec.rb 
> spec/higher_level_api/integration/exclusive_queue_spec.rb 
> spec/higher_level_api/integration/heartbeat_spec.rb 
> spec/higher_level_api/integration/predeclared_exchanges_spec.rb 
> spec/higher_level_api/integration/publisher_confirms_spec.rb 
> spec/higher_level_api/integration/publishing_edge_cases_spec.rb 
> spec/higher_level_api/integration/queue_bind_spec.rb 
> spec/higher_level_api/integration/queue_delete_spec.rb 
> spec/higher_level_api/integration/queue_purge_spec.rb 
> spec/higher_level_api/integration/queue_unbind_spec.rb 
> spec/higher_level_api/integration/read_only_consumer_spec.rb 
> spec/higher_level_api/integration/sender_selected_distribution_spec.rb 
> spec/higher_level_api/integration/tx_commit_spec.rb 
> spec/higher_level_api/integration/tx_rollback_spec.rb 
> spec/higher_level_api/integration/with_channel_spec.rb 
> spec/issues/issue100_spec.rb spec/issues/issue141_spec.rb 
> spec/issues/issue202_spec.rb spec/issues/issue224_spec.rb 
> spec/issues/issue465_spec.rb spec/issues/issue609_spec.rb 
> spec/issues/issue78_spec.rb spec/issues/issue83_spec.rb 
> spec/issues/issue97_spec.rb 
> spec/lower_level_api/integration/basic_cancel_spec.rb 
> spec/lower_level_api/integration/basic_consume_spec.rb 
> spec/unit/bunny_spec.rb spec/unit/concurrent/atomic_fixnum_spec.rb 
> spec/unit/concurrent/condition_spec.rb 
> spec/unit/concurrent/linked_continuation_queue_spec.rb 
> spec/unit/exchange_recovery_spec.rb spec/unit/version_delivery_tag_spec.rb 
> --format documentation failed
> Stopping and halting node bunny@lemur ...
> Gracefully halting Erlang VM
> pkill: killing pid 1616

Bug#1027066: atig: FTBFS with ruby-rspec 3.12: ERROR: Test "ruby3.1" failed: Failure/Error: user = t.get("users/show", { screen_name: nick})

[Antonio Terceiro]

Source: atig
Version: 0.6.1-7
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-rspec-3.12

Hi,

I'm about to upload ruby-rspec 3.12. During a test rebuild with that version,
atig failed to build.

Relevant part of the build log (hopefully):
>  Failure/Error: user = t.get("users/show", { screen_name: nick})
> 
># received :get with unexpected arguments
>  expected: ("users/show", {:screen_name=>"mzp"}) (keyword arguments)
>   got: ("users/show", {:screen_name=>"mzp"}) (options hash)
>  # ./lib/atig/command/version.rb:27:in `block in action'
>  # ./spec/command_helper.rb:33:in `delay'
>  # ./lib/atig/command/version.rb:25:in `action'
>  # ./lib/atig/command/command.rb:13:in `block in initialize'
>  # ./spec/command_helper.rb:87:in `call'
>  # ./spec/command/version_spec.rb:60:in `block (2 levels) in  (required)>'
> 
> Top 10 slowest examples (7.71 seconds, 76.3% of total time):
>   Atig::Db::Statuses should cleanup
> 6.21 seconds ./spec/db/statuses_spec.rb:174
>   Atig::Db::Statuses should call listeners
> 0.19883 seconds ./spec/db/statuses_spec.rb:41
>   Atig::Db::Statuses should have unique tid
> 0.18957 seconds ./spec/db/statuses_spec.rb:73
>   Atig::Db::Statuses should be found by id
> 0.17471 seconds ./spec/db/statuses_spec.rb:64
>   Atig::Db::Statuses should be re-openable
> 0.16964 seconds ./spec/db/statuses_spec.rb:37
>   Atig::Db::Statuses should be found by sid
> 0.16772 seconds ./spec/db/statuses_spec.rb:109
>   Atig::Db::Statuses should be found by tid
> 0.16677 seconds ./spec/db/statuses_spec.rb:104
>   Atig::Db::Statuses should have uniq tid/sid when removed
> 0.14759 seconds ./spec/db/statuses_spec.rb:164
>   Atig::Db::Statuses should be found by tid
> 0.14624 seconds ./spec/db/statuses_spec.rb:114
>   Atig::Db::Statuses should be found all
> 0.14196 seconds ./spec/db/statuses_spec.rb:83
> 
> Top 10 slowest example groups:
>   Atig::Db::Statuses
> 0.5593 seconds average (8.39 seconds / 15 examples) 
> ./spec/db/statuses_spec.rb:6
>   Atig::Db::Lists
> 0.05101 seconds average (0.51009 seconds / 10 examples) 
> ./spec/db/lists_spec.rb:5
>   Atig::Db::Followings when updated users
> 0.05079 seconds average (0.50794 seconds / 10 examples) 
> ./spec/db/followings_spec.rb:20
>   Atig::IFilter::ExpandUrl when enable whole url
> 0.03999 seconds average (0.07999 seconds / 2 examples) 
> ./spec/ifilter/expand_url_spec.rb:39
>   Atig::IFilter::ExpandUrl when disable whole url
> 0.03797 seconds average (0.18986 seconds / 5 examples) 
> ./spec/ifilter/expand_url_spec.rb:10
>   Atig::IFilter::ExpandUrl when has urls entities
> 0.03731 seconds average (0.07461 seconds / 2 examples) 
> ./spec/ifilter/expand_url_spec.rb:58
>   Atig::Db::Followings when it is empty
> 0.02807 seconds average (0.02807 seconds / 1 example) 
> ./spec/db/followings_spec.rb:5
>   Atig::OFilter::ShortUrl when no-login bitly
> 0.02606 seconds average (0.02606 seconds / 1 example) 
> ./spec/ofilter/short_url_spec.rb:6
>   Atig::OFilter::ShortUrl when login bitly
> 0.02599 seconds average (0.02599 seconds / 1 example) 
> ./spec/ofilter/short_url_spec.rb:42
>   Atig::OFilter::ShortUrl when nop
> 0.02538 seconds average (0.02538 seconds / 1 example) 
> ./spec/ofilter/short_url_spec.rb:78
> 
> Finished in 10.11 seconds (files took 0.32628 seconds to load)
> 182 examples, 6 failures
> 
> Failed examples:
> 
> rspec ./spec/command/retweet_spec.rb:47 # Atig::Command::Retweet should post 
> un-official retweet with comment
> rspec ./spec/command/retweet_spec.rb:53 # Atig::Command::Retweet should post 
> un-official retweet with comment by screen name
> rspec ./spec/command/retweet_spec.rb:59 # Atig::Command::Retweet should post 
> un-official retweet with long comment
> rspec ./spec/command/user_spec.rb:15 # Atig::Command::User should
> rspec ./spec/command/user_spec.rb:32 # Atig::Command::User should get 
> specified statuses
> rspec ./spec/command/version_spec.rb:48 # Atig::Command::Version should show 
> the source via API
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.12.0/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.12.0/exe/rspec 
> --pattern spec/\*\*/\*_spec.rb failed
> ERROR: Test "ruby3.1" failed: 

The full build log is attached.

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


atig.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1027060: ruby-varia-model: FTBFS with ruby-hashie 5.0.0-1: unsatisfiable build-dependency: ruby-hashie (< 4.0.0) but 5.0.0-1 is to be installed

[Antonio Terceiro]

Source: ruby-varia-model
Version: 0.6.0-2
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-hashie-5.0.0

Hi,

After updating ruby-hashie to 5.0.0-1, ruby-varia-model fails to
build.

Relevant part of the build log (hopefully):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper-compat (= 13), gem2deb, rake, 
> ruby-buff-extensions (>= 2.0), ruby-buff-ruby-engine, ruby-hashie (<< 4.0.0), 
> ruby-rspec, build-essential, fakeroot
> Filtered Build-Depends: debhelper-compat (= 13), gem2deb, rake, 
> ruby-buff-extensions (>= 2.0), ruby-buff-ruby-engine, ruby-hashie (<< 4.0.0), 
> ruby-rspec, build-essential, fakeroot
> dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
> '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
> Ign:1 copy:/<>/apt_archive ./ InRelease
> Get:2 copy:/<>/apt_archive ./ Release [580 B]
> Ign:3 copy:/<>/apt_archive ./ Release.gpg
> Get:4 copy:/<>/apt_archive ./ Sources [722 B]
> Get:5 copy:/<>/apt_archive ./ Packages [754 B]
> Fetched 2056 B in 0s (0 B/s)
> Reading package lists...
> Get:1 file:/<>/resolver-uUKyga/apt_archive ./ InRelease
> Ign:1 file:/<>/resolver-uUKyga/apt_archive ./ InRelease
> Get:2 file:/<>/resolver-uUKyga/apt_archive ./ Release [580 B]
> Get:2 file:/<>/resolver-uUKyga/apt_archive ./ Release [580 B]
> Get:3 file:/<>/resolver-uUKyga/apt_archive ./ Release.gpg
> Ign:3 file:/<>/resolver-uUKyga/apt_archive ./ Release.gpg
> Reading package lists...
> Reading package lists...
> 
> Install main build dependencies (apt-based resolver)
> 
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: ruby-hashie (< 4.0.0) but 5.0.0-1 
> is to be installed
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.


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


signature.asc
Description: PGP signature

Bug#1027059: ruby-rash-alt: FTBFS with ruby-hashie 5.0.0-1: ERROR: Test "ruby3.1" Could not find 'hashie' (~> 3.4) among 98 total gem(s) (Gem::MissingSpecError)

[Antonio Terceiro]

Source: ruby-rash-alt
Version: 0.4.3-1.1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-hashie-5.0.0

Hi,

After updating ruby-hashie to 5.0.0-1, ruby-rash-alt fails to
build.

Relevant part of the build log (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block 
> in activate_dependencies': Could not find 'hashie' (~> 3.4) among 98 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-rash-alt/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  at: 
> /<>/debian/ruby-rash-alt/usr/share/rubygems-integration/all/specifications/rash_alt-0.4.3.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381: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 'hashie' (~> 3.4) - did find: [hashie-5.0.0] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-rash-alt/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381: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 `'
> abbrev (default: 0.1.0)
> base64 (default: 0.1.1)
> benchmark (default: 0.2.0)
> bigdecimal (default: 3.1.1)
> bundler (default: 2.3.7)
> cgi (default: 0.3.1)
> csv (default: 3.2.2)
> date (default: 3.2.2)
> debug (1.4.0)
> delegate (default: 0.2.0)
> did_you_mean (default: 1.6.1)
> diff-lcs (1.5.0)
> digest (default: 3.1.0)
> drb (default: 2.1.0)
> english (default: 0.7.1)
> erb (default: 2.2.3)
> error_highlight (default: 0.3.0)
> etc (default: 1.3.0)
> fcntl (default: 1.0.1)
> fiddle (default: 1.1.0)
> fileutils (default: 1.6.0)
> find (default: 0.1.1)
> forwardable (default: 1.3.2)
> getoptlong (default: 0.1.1)
> hashie (5.0.0)
> io-console (default: 0.5.11)
> io-nonblock (default: 0.1.0)
> io-wait (default: 0.2.1)
> ipaddr (default: 1.2.4)
> irb (default: 1.4.1)
> json (default: 2.6.1)
> logger (default: 1.5.0)
> matrix (0.4.2)
> minitest (5.15.0)
> mutex_m (default: 0.1.1)
> net-ftp (0.1.3)
> net-http (default: 0.2.0)
> net-imap (0.2.3)
> net-pop (0.1.1)
> net-protocol (default: 0.1.2)
> net-smtp (0.3.1)
> net-telnet (0.1.1)
> nkf (default: 0.1.1)
> observer (default: 0.1.1)
> open-uri (default: 0.2.0)
> open3 (default: 0.1.1)
> openssl (default: 3.0.0)
> optparse (default: 0.2.0)
> ostruct (default: 0.5.2)
> pathname (default: 0.2.0)
> power_assert (2.0.1)
> pp (default: 0.3.0)
> prettyprint (default: 0.1.1)
> prime (0.1.2)
> pstore (default: 0.1.1)
> psych (default: 4.0.3)
> racc (default: 1.6.0)
> rake (13.0.6)
> rbs (2.1.0)
> rdoc (default: 6.4.0)
> readline (default: 0.0.3)
> readline-ext (default: 0.1.4)
> reline (default: 0.3.0)
> resolv (default: 0.2.1)
> resolv-replace (default: 0.1.0)
> rexml (3.2.5)
> rinda (default: 0.1.1)
> rspec (3.12.0)
> rspec-core (3.12.0)
> rspec-expectations (3.12.1)
> rspec-mocks (3.12.1)
> rspec-support (3.12.0)
> rss (0.2.9)
> ruby2_keywords (default: 0.0.5)
> rubygems-update (3.3.15)
> sdbm (1.0.0)
> securerandom (default: 0.1.1)
> set (default: 1.0.2)
> shellwords (default: 0.1.0)
> singleton (default: 0.1.1)
> stringio (default: 3.0.1)
> strscan (default: 3.0.1)
> syslog (default: 0.1.0)
> tempfile (default: 0.1.2)
> test-unit (3.5.3)
> time (default: 0.2.

Bug#1027058: ruby-github-api: FTBFS with ruby-hashie 5.0.0-1: ERROR: Test "ruby3.1" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block in activate_dependencies': Coul

[Antonio Terceiro]

Source: ruby-github-api
Version: 0.19.0-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-hashie-5.0.0

Hi,

After updating ruby-hashie to 5.0.0-1, ruby-github-api fails to
build.

Relevant part of the build log (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block 
> in activate_dependencies': Could not find 'hashie' (>= 3.5.2, ~> 3.5) among 
> 104 total gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  at: 
> /<>/debian/ruby-github-api/usr/share/rubygems-integration/all/specifications/github_api-0.19.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381: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 'hashie' (>= 3.5.2, ~> 3.5) - did find: [hashie-5.0.0] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381: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 `'
> abbrev (default: 0.1.0)
> addressable (2.8.0)
> atomic (1.1.16)
> base64 (default: 0.1.1)
> benchmark (default: 0.2.0)
> bigdecimal (default: 3.1.1)
> bundler (default: 2.3.7)
> cgi (default: 0.3.1)
> csv (default: 3.2.2)
> date (default: 3.2.2)
> debug (1.4.0)
> delegate (default: 0.2.0)
> descendants_tracker (0.0.4)
> did_you_mean (default: 1.6.1)
> digest (default: 3.1.0)
> drb (default: 2.1.0)
> english (default: 0.7.1)
> erb (default: 2.2.3)
> error_highlight (default: 0.3.0)
> etc (default: 1.3.0)
> faraday (1.1.0)
> fcntl (default: 1.0.1)
> fiddle (default: 1.1.0)
> fileutils (default: 1.6.0)
> find (default: 0.1.1)
> forwardable (default: 1.3.2)
> getoptlong (default: 0.1.1)
> hashie (5.0.0)
> io-console (default: 0.5.11)
> io-nonblock (default: 0.1.0)
> io-wait (default: 0.2.1)
> ipaddr (default: 1.2.4)
> irb (default: 1.4.1)
> json (default: 2.6.1)
> jwt (2.5.0)
> logger (default: 1.5.0)
> matrix (0.4.2)
> minitest (5.15.0)
> multi_json (1.14.1)
> multi_xml (0.6.0)
> multipart-post (2.0.0)
> mutex_m (default: 0.1.1)
> net-ftp (0.1.3)
> net-http (default: 0.2.0)
> net-imap (0.2.3)
> net-pop (0.1.1)
> net-protocol (default: 0.1.2)
> net-smtp (0.3.1)
> net-telnet (0.1.1)
> nkf (default: 0.1.1)
> oauth2 (1.4.4)
> observer (default: 0.1.1)
> open-uri (default: 0.2.0)
> open3 (default: 0.1.1)
> openssl (default: 3.0.0)
> optparse (default: 0.2.0)
> ostruct (default: 0.5.2)
> pathname (default: 0.2.0)
> power_assert (2.0.1)
> pp (default: 0.3.0)
> prettyprint (default: 0.1.1)
> prime (0.1.2)
> pstore (default: 0.1.1)
> psych (default: 4.0.3)
> public_suffix (4.0.6)
> racc (default: 1.6.0)
> rack (2.2.4)
> rake (13.0.6)
> rbs (2.1.0)
> rdoc (default: 6.4.0)
> readline (default: 0.0.3)
> readline-ext (default: 0.1.4)
> reline (default: 0.3.0)
> resolv (default: 0.2.1)
> resolv-replace (default: 0.1.0)
> rexml (3.2.5)
> rinda (default: 0.1.1)
> rss (0.2.9)
> ruby2_keywords (0.0.5)
> rubygems-update (3.3.15)
> sdbm (1.0.0)
> securerandom (default: 0.1.1)
> set (default: 1.0.2)
> shellwords (default: 0.1.0)
> singleton (default: 0.1.1)
> stringio (default: 3.0.1)
> strscan

Bug#1019628: ruby-hashie: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: expected NoMethodError with "The property 'middle_name' is not defined for DashTest.", got #

[Antonio Terceiro]

Control: reassign -1 ruby-rspec-expectations
Control: retitle -1 ruby-rspec-expectations: raise_error() matcher does not 
work  with ruby3.1
Control: forwarded -1 https://github.com/rspec/rspec-expectations/issues/1338
Control: affects -1 src:ruby-hashie

On Sat, Nov 19, 2022 at 03:29:31PM +0200, Adrian Bunk wrote:
> Control: tags -1 fixed-upstream
[...]
> This seems to be fixed in 5.0.0.

It turns out this is a problem rspec-expectations on ruby3.1. The latest
upstream should fix this.


signature.asc
Description: PGP signature