Bug#996541: racon: FTBFS when rebuilt against libedlib1

2021-10-14 Thread Niels Thykier
Package: racon
Version: 1.4.21-1
Severity: serious
X-Debbugs-Cc: ni...@thykier.net

Hi,

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

Relevant parts of the amd64 log:

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

Thanks,
~Niels



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

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

Hi,

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

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

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

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

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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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

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

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

Hi,

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

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

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

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

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

Hi,

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

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

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

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

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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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

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

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

Hi,

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

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

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-xmlrpc/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -e gem\ \"xmlrpc\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-xmlrpc/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-xmlrpc/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.0 -w -I"test" 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb 
> "test/test_client.rb" "test/test_cookie.rb" "test/test_datetime.rb" 
> "test/test_features.rb" "test/test_helper.rb" "test/test_marshal.rb" 
> "test/test_parser.rb" "test/test_webrick_server.rb" "test/test_xmlrpc.rb" -v
> 
> File does not exist: webrick
> 
> rake aborted!
> Command failed with status (1): [ruby -w -I"test" 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb 
> "test/test_client.rb" "test/test_cookie.rb" "test/test_datetime.rb" 
> "test/test_features.rb" "test/test_helper.rb" "test/test_marshal.rb" 
> "test/test_parser.rb" "test/test_webrick_server.rb" "test/test_xmlrpc.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed.

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

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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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

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

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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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

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

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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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

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

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

Hi,

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

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

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

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

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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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

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

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

Hi,

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

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

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

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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


The full build log is available at

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

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

Hi,

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

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

Relevant part (hopefully):
> ArgumentError: tried to create Proc object without a block
> 
> /<>/debian/ruby-spy/usr/lib/ruby/vendor_ruby/spy/subroutine.rb:196:in
>  `new'
> 
> /<>/debian/ruby-spy/usr/lib/ruby/vendor_ruby/spy/subroutine.rb:196:in
>  `has_been_called_with?'
> 
> /<>/debian/ruby-spy/usr/lib/ruby/vendor_ruby/spy/api.rb:11:in 
> `assert_received_with'
> /<>/test/integration/test_api.rb:19:in 
> `test_assert_received_with'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:98:in `block (3 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:195:in `capture_exceptions'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:95:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:270:in `time_it'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:94:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:211:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest/test.rb:93:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:1029:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:339:in `run_one_method'
> /usr/lib/ruby/vendor_ruby/minitest.rb:326:in `block (2 levels) in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `each'
> /usr/lib/ruby/vendor_ruby/minitest.rb:325:in `block in run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:365:in `on_signal'
> /usr/lib/ruby/vendor_ruby/minitest.rb:352:in `with_info_handler'
> /usr/lib/ruby/vendor_ruby/minitest.rb:324:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `block in __run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `map'
> /usr/lib/ruby/vendor_ruby/minitest.rb:164:in `__run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:141:in `run'
> /usr/lib/ruby/vendor_ruby/minitest.rb:68:in `block in autorun'
> 
> 65 runs, 108 assertions, 0 failures, 5 errors, 0 skips
> rake aborted!
> Command failed with status (1): [ruby -w -I"test" 
> /usr/lib/ruby/gems/3.0.0/gems/rake-13.0.3/lib/rake/rake_test_loader.rb 
> "test/integration/test_api.rb" "test/integration/test_constant_spying.rb" 
> "test/integration/test_instance_method.rb" "test/integration/test_mocking.rb" 
> "test/integration/test_subroutine_spying.rb" "test/spy/test_mock.rb" 
> "test/spy/test_subroutine.rb" "test/test_helper.rb" -v]
> 
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed: 


The full build log is available at
https://people.debian.org/~kanashiro/ruby3.0/round2/builds/3/ruby-spy/ruby-spy_0.4.3-1+rebuild1633396140_amd64.build.txt


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


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

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

Hi,

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

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

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


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


signature.asc
Description: PGP signature


Bug#984182: marked as done (ignition-common: ftbfs with GCC-11)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 22:48:34 +
with message-id 
and subject line Bug#984182: fixed in ignition-common 3.14.0+dfsg-1
has caused the Debian Bug report #984182,
regarding ignition-common: ftbfs with GCC-11
to be marked as done.

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

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


-- 
984182: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984182
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:ignition-common
Version: 3.5.0+dfsg1-5
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/ignition-common_3.5.0+dfsg1-5_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++  
-I/<>/include -I/<>/obj-x86_64-linux-gnu/include 
-I/<> -I/<>/obj-x86_64-linux-gnu 
-I/<>/test/gtest/include -I/<>/src 
-I/<>/obj-x86_64-linux-gnu/core/include -isystem /usr/include/uuid 
-g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/uuid 
-std=c++11 -o CMakeFiles/UNIT_Util_TEST.dir/Util_TEST.cc.o -c 
/<>/src/Util_TEST.cc
In file included from /<>/src/Util_TEST.cc:22:
/<>/include/ignition/common/Util.hh:187:60: warning: ‘visibility’ 
attribute ignored [-Wattributes]
  187 | constexpr uint64_t IGNITION_COMMON_VISIBLE hash64(std::string_view 
_key)
  |^~~
/<>/include/ignition/common/Util.hh:187:60: error: ‘string_view’ 
is not a member of ‘std’
/<>/include/ignition/common/Util.hh:187:60: note: 
‘std::string_view’ is only available from C++17 onwards
/<>/src/Util_TEST.cc: In member function ‘virtual void 
Util_TEST_Hash64_Test::TestBody()’:
/<>/src/Util_TEST.cc:79:33: error: ‘ignition::common::hash64’ 
cannot be used as a function
   79 |   "priceless. Like the Ark.");
  | ^
/<>/src/Util_TEST.cc:86:52: error: ‘ignition::common::hash64’ 
cannot be used as a function
   86 | constexpr auto computedHash = common::hash64("");
  |^
make[3]: *** [src/CMakeFiles/UNIT_Util_TEST.dir/build.make:85: 
src/CMakeFiles/UNIT_Util_TEST.dir/Util_TEST.cc.o] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1395: src/CMakeFiles/UNIT_Util_TEST.dir/all] 
Error 2
make[2]: *** Waiting for unfinished jobs
[ 32%] Building CXX object 
graphics/src/CMakeFiles/ignition-common3-graphics.dir/Dem.cc.o
cd /<>/obj-x86_64-linux-gnu/graphics/src && /usr/bin/c++ 
-DTINYXML2_MAJOR_VERSION_GE_6 -Dignition_common3_graphics_EXPORTS 
-I/<>/include -I/<>/obj-x86_64-linux-gnu/include 
-I/<>/graphics/include 
-I/<>/obj-x86_64-linux-gnu/graphics/include 
-I/<>/obj-x86_64-linux-gnu/core/include -isystem /usr/include/uuid 
-isystem /usr/include/ignition/math6 -isystem /usr/include/glib-2.0 -isystem 
/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fPIC 
-I/usr/include/uuid -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -o 

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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #994833 [intel-opencl-icd] OpenCL programs abort when intel-opencl-icd is 
installed
Added tag(s) pending.

-- 
994833: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994833
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Andreas Beckmann

Control: tag -1 pending

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

The virtual ABI package sounds like the best choice.


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


Andreas



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

2021-10-14 Thread Dirk Eddelbuettel


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

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

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

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

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

Processed: Update tags for #984260

2021-10-14 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> tags 984260 upstream fixed-upstream
Bug #984260 [src:nut] nut: ftbfs with GCC-11
Added tag(s) upstream and fixed-upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
984260: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984260
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

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

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

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

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

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

Cheers

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#984317: marked as done (rheolef: ftbfs with GCC-11)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 21:06:22 +
with message-id 
and subject line Bug#984317: fixed in rheolef 7.1-7
has caused the Debian Bug report #984317,
regarding rheolef: ftbfs with GCC-11
to be marked as done.

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

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


-- 
984317: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984317
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:rheolef
Version: 7.1-3
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/rheolef_7.1-3_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
bash ../../config/src2man.sh -nowarning-as-error -section 3 
continuation_option.h continuation_option.3rheolef
bash ../../config/src2man.sh -nowarning-as-error -section 3 level_set.h 
level_set.3rheolef
bash ../../config/src2man.sh -nowarning-as-error -section 3 limiter.h 
limiter.3rheolef
rm -f rheolef.man2 && ln -s rheolef.h rheolef.man2
rm -f geo.man2 && ln -s geo.h geo.man2
rm -f field.man2 && ln -s field.h field.man2
rm -f space.man2 && ln -s space.h space.man2
rm -f form.man2 && ln -s form.h form.man2
rm -f branch.man2 && ln -s branch.h branch.man2
rm -f test.man2 && ln -s test.h test.man2
rm -f problem.man2 && ln -s problem.h problem.man2
rm -f problem_mixed.man2 && ln -s problem_mixed.h problem_mixed.man2
rm -f band.man2 && ln -s band.h band.man2
rm -f characteristic.man2 && ln -s characteristic.h characteristic.man2
rm -f adapt.man3 && ln -s adapt.h adapt.man3
rm -f interpolate.man3 && ln -s interpolate.h interpolate.man3
rm -f integrate.man3 && ln -s integrate.h integrate.man3
rm -f expression.man3 && ln -s expression.h expression.man3
rm -f compose.man3 && ln -s compose.h compose.man3
rm -f newton.man3 && ln -s newton.h newton.man3
rm -f damped_newton.man3 && ln -s damped_newton.h damped_newton.man3
rm -f continuation.man3 && ln -s continuation.h continuation.man3
rm -f continuation_option.man3 && ln -s continuation_option.h 
continuation_option.man3
rm -f level_set.man3 && ln -s level_set.h level_set.man3
rm -f limiter.man3 && ln -s limiter.h limiter.man3
Making all in sbin
g++ -DHAVE_CONFIG_H -I. -I../../config  -I../../include -I../../fem/geo_element 
-I../../linalg/lib -I../../util/lib   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/eigen3  -g  -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c++17 -Wall 
-fpermissive -Wno-unused -Wno-strict-aliasing -Wno-deprecated-declarations 
-Wno-narrowing -Wno-literal-suffix -Wno-int-in-bool-context -O3  -c -o 
bamg2geo.o bamg2geo.cc
In file included from bamg2geo.cc:134:
../../include/rheolef/index_set_body.icc: In member function ‘void 
rheolef::index_set::inplace_union(const rheolef::index_set&)’:
../../include/rheolef/index_set_body.icc:98:34: error: ‘numeric_limits’ is not 
a member of ‘std’
   98 | const size_type infty = std::numeric_limits::max();
  |  ^~
../../include/rheolef/index_set_body.icc:98:58: error: expected 
primary-expression before ‘>’ token
   98 | const size_type infty = std::numeric_limits::max();
  |  ^

Bug#996490: marked as done (audacious-plugins: cannot install last binNMU 4.0.5-1+b1)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 21:03:28 +
with message-id 
and subject line Bug#996490: fixed in audacious-plugins 4.0.5-2
has caused the Debian Bug report #996490,
regarding audacious-plugins: cannot install last binNMU 4.0.5-1+b1
to be marked as done.

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

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


-- 
996490: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996490
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: audacious-plugins
Version: 4.0.5-1
Severity: normal

Dear Maintainer,

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

Thanks,
Patrice

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

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

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

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

audacious-plugins suggests no packages.
--- End Message ---
--- Begin Message ---
Source: audacious-plugins
Source-Version: 4.0.5-2
Done: Sebastian Ramacher 

We believe that the bug you reported is fixed in the latest version of
audacious-plugins, which is due to be installed in the Debian FTP archive.

A summary of the changes 

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

2021-10-14 Thread Dirk Eddelbuettel


Hi Sebastian,

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

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

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

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

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

Dirk


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

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



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

2021-10-14 Thread Sebastian Ramacher
Hi Dirk

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

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

There are two options to fix this issue:

* Unbreak the ABI by reintroducing the removed symbols.

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

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

Cheers

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#991497: marked as done (RUSTSEC-2021-0074)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 20:41:53 +
with message-id 
and subject line Bug#991497: fixed in rust-ammonia 3.1.2-1
has caused the Debian Bug report #991497,
regarding RUSTSEC-2021-0074
to be marked as done.

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

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


-- 
991497: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991497
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: rust-ammonia
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://rustsec.org/advisories/RUSTSEC-2021-0074.html

Patch: 
https://github.com/rust-ammonia/ammonia/commit/4b8426b89b861d9bea20e126576b0febb9d13515

Cheers,
 Moritz
--- End Message ---
--- Begin Message ---
Source: rust-ammonia
Source-Version: 3.1.2-1
Done: Henry-Nicolas Tourneur 

We believe that the bug you reported is fixed in the latest version of
rust-ammonia, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 991...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Henry-Nicolas Tourneur  (supplier of updated rust-ammonia 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 14 Oct 2021 22:14:28 +0200
Source: rust-ammonia
Architecture: source
Version: 3.1.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Rust Maintainers 

Changed-By: Henry-Nicolas Tourneur 
Closes: 991497
Changes:
 rust-ammonia (3.1.2-1) unstable; urgency=medium
 .
   * Team upload.
   * Package ammonia 3.1.2 from crates.io using debcargo 2.4.4 (Closes:
 #991497)
Checksums-Sha1:
 5aa490b05ebc10e3beb63fb7c50f357fe9c6dc68 2527 rust-ammonia_3.1.2-1.dsc
 5f44b2f481cb9a008bf9b182952990dbb540fa52 39704 rust-ammonia_3.1.2.orig.tar.gz
 9df7871afcc31c3d55909da215d0cda65f974d9b 2828 
rust-ammonia_3.1.2-1.debian.tar.xz
 1e7bf7bec96bfb8960b5eaff72620a32783b5527 8397 
rust-ammonia_3.1.2-1_source.buildinfo
Checksums-Sha256:
 cb9d32f04659e5d74c67a4958158bee150e8cde9142c39d519d128e6d5415c6e 2527 
rust-ammonia_3.1.2-1.dsc
 2e445c26125ff80316eaea16e812d717b147b82a68682bd4730f74d4845c8b35 39704 
rust-ammonia_3.1.2.orig.tar.gz
 9e26ffa0e97daf54af1e974764323236ca03a3497647a12d0fea6fa6b16967bb 2828 
rust-ammonia_3.1.2-1.debian.tar.xz
 fc8431c5018a10595b8c27c5f70e3488c41299af8208bed0e99fc1dcc4bcfa35 8397 
rust-ammonia_3.1.2-1_source.buildinfo
Files:
 122a4e0ebf5fc6f9ecd81bcec0b44249 2527 rust optional rust-ammonia_3.1.2-1.dsc
 1fe846b8e6d1593ab5b6d9a1f7bb03fc 39704 rust optional 
rust-ammonia_3.1.2.orig.tar.gz
 903f21c8643dd80032815277082d51dd 2828 rust optional 
rust-ammonia_3.1.2-1.debian.tar.xz
 7431ead98b7cf67d27492621a4b40b4e 8397 rust optional 
rust-ammonia_3.1.2-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmFoj6oACgkQfmUo2nUv
G+HOYA//RNyPUr8N3YXCcM4VV/CoGqjzhy6rtzeOra0twD2lSnvZwv4rQyAOT46i
cZqBlP/UQf0LJKhgq9JhARHKrmnIB7Kb/gzDob6QlNZF2E9qmwC+xE7C1wQail2F
R+NJai0dUJNg3vbTo6DpGziM2ze8OZmkUqPnts/eK9fY6DHfrjcRZR+aNUvMq6xD
FzK55USvEewgdpSGeSgUk0Z7HDdbvRiMqDGxTz14+KFziXPkiEaaO0EkFvvRex9R
45bE/muSkxTEuF3jUGXBZyOeazlEs+FaNU/gbfzoxAZznUpCZ0NqGxdA9fi6cHIn
UTCbThowZqPoIx4ayoNwIxbO7KQwLeLy6o3v8z8zHaeCoJttDtlBE9DNmdIXPDta
Ah1ftkNe08QWCUqa044FSut6nauYWryOL/+JojCD+lQ2WjwBZu+pfaAg/B+r1NcC
FfSiSwt/paY/EIt4n7RdsB/BOucEMxDyyOSZB5yRDUsr3ZWZ9QbV4Sy4l7wUlEsr
yD9q6ChC3dDGfVdBzeq3Dncm4AtmsdiggiIRYqIXt6yVkq7Y1YZFdp1KoXRiOHAN
t20QwSc9bnsShYy991kEq+gmVDj/2Pz2272lTYtdJcD6tMw79BHkjZJP3R8BGb5O
A+jrwabQjTPEqVm8j5Vi65OqLmbhy7zJTo1ho2FOPKgXKQ0G6Pw=
=veCb
-END PGP SIGNATURE End Message ---


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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 serious
Bug #996490 [audacious-plugins] audacious-plugins: cannot install last binNMU 
4.0.5-1+b1
Severity set to 'serious' from 'normal'

-- 
996490: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996490
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#984319: marked as done (ri-li: ftbfs with GCC-11)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 19:20:12 +
with message-id 
and subject line Bug#984319: fixed in ri-li 2.0.1+ds-11
has caused the Debian Bug report #984319,
regarding ri-li: ftbfs with GCC-11
to be marked as done.

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

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


-- 
984319: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984319
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:ri-li
Version: 2.0.1+ds-10
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/ri-li_2.0.1+ds-10_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking SDL/SDL.h usability... yes
checking SDL/SDL.h presence... yes
checking for SDL/SDL.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking SDL/SDL_mixer.h usability... yes
checking SDL/SDL_mixer.h presence... yes
checking for SDL/SDL_mixer.h... yes
checking for sqrt... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating data/Makefile
config.status: creating Sounds/Makefile
config.status: creating gentoo/Makefile
config.status: creating config.h
config.status: executing depfiles commands
make[1]: Leaving directory '/<>'
   debian/rules override_dh_auto_build-arch
make[1]: Entering directory '/<>'
I: ri-li_2.0.1+ds
dh_auto_build -Dsrc
cd src && make -j4 "INSTALL=install --strip-program=true"
make[2]: Entering directory '/<>/src'
g++ -DHAVE_CONFIG_H -I. -I..  -DDATA_DIR="\"/usr/share/games/ri-li/Ri-li\"" 
-Wno-deprecated -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o audio.o audio.cc
g++ -DHAVE_CONFIG_H -I. -I..  -DDATA_DIR="\"/usr/share/games/ri-li/Ri-li\"" 
-Wno-deprecated -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o ecran.o ecran.cc
g++ -DHAVE_CONFIG_H -I. -I..  -DDATA_DIR="\"/usr/share/games/ri-li/Ri-li\"" 
-Wno-deprecated -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o editeur.o editeur.cc
g++ -DHAVE_CONFIG_H -I. -I..  -DDATA_DIR="\"/usr/share/games/ri-li/Ri-li\"" 
-Wno-deprecated -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o jeux.o jeux.cc
g++ -DHAVE_CONFIG_H -I. -I..  -DDATA_DIR="\"/usr/share/games/ri-li/Ri-li\"" 
-Wno-deprecated -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o loco.o loco.cc
g++ -DHAVE_CONFIG_H -I. -I..  -DDATA_DIR="\"/usr/share/games/ri-li/Ri-li\"" 
-Wno-deprecated -Wdate-time -D_FORTIFY_SOURCE=2 -DLINUX  -g 

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

2021-10-14 Thread Helmut Grohne
Source: wlroots
Version: 0.12.0-2
Severity: serious
Tags: ftbfs

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

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

Helmut



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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> close -1 1.1.2-3
Bug #996496 [src:golang-gopkg-square-go-jose.v1] 
src:golang-gopkg-square-go-jose.v1: fails to migrate to testing for too long: 
uploader built arch:all binary
Marked as fixed in versions golang-gopkg-square-go-jose.v1/1.1.2-3.
Bug #996496 [src:golang-gopkg-square-go-jose.v1] 
src:golang-gopkg-square-go-jose.v1: fails to migrate to testing for too long: 
uploader built arch:all binary
Marked Bug as done

-- 
996496: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996496
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

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

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature


Processed: Bug#984319 marked as pending in ri-li

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #984319 [src:ri-li] ri-li: ftbfs with GCC-11
Added tag(s) pending.

-- 
984319: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984319
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#984319: marked as pending in ri-li

2021-10-14 Thread Markus Koschany
Control: tag -1 pending

Hello,

Bug #984319 in ri-li 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/games-team/ri-li/-/commit/020205609cb6172b1583db9854ed15ae5e9dcb11


Force C++14 because the code is not C++17 ready.

Closes: #984319


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/984319



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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> close -1 3.32.2+dfsg1-3
Bug #996491 [src:gnome-authenticator] src:gnome-authenticator: fails to migrate 
to testing for too long: uploader built arch:all
Marked as fixed in versions gnome-authenticator/3.32.2+dfsg1-3.
Bug #996491 [src:gnome-authenticator] src:gnome-authenticator: fails to migrate 
to testing for too long: uploader built arch:all
Marked Bug as done

-- 
996491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996491
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> close -1 0.0~git20190325.f02dbb0-3
Bug #996493 [src:golang-github-getlantern-hidden] 
src:golang-github-getlantern-hidden: fails to migrate to testing for too long: 
uploader built arch:all binary
Marked as fixed in versions 
golang-github-getlantern-hidden/0.0~git20190325.f02dbb0-3.
Bug #996493 [src:golang-github-getlantern-hidden] 
src:golang-github-getlantern-hidden: fails to migrate to testing for too long: 
uploader built arch:all binary
Marked Bug as done

-- 
996493: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996493
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

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

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature


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

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

Dear maintainer(s),

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

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

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

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

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

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature


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

2021-10-14 Thread Paul Gevers
Hi Georges,

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

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

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

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

> Thank you in advance for any suggestion.

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

Paul



OpenPGP_signature
Description: OpenPGP digital signature


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

2021-10-14 Thread Sven Joachim
Control: tags -1 + patch

Am 27.09.2021 um 22:25 schrieb Helmut Grohne:

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

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

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

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

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

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

--
2.33.0



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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + patch
Bug #995202 [src:horst] horst FTBFS: error: format not a string literal and no 
format arguments
Added tag(s) patch.

-- 
995202: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995202
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 src:pytorch 1.7.1-7
Bug #994423 [src:pytorch-vision] pytorch-vision: FTBFS on armhf: Illegal 
instruction
Bug reassigned from package 'src:pytorch-vision' to 'src:pytorch'.
No longer marked as found in versions pytorch-vision/0.8.2-1.
Ignoring request to alter fixed versions of bug #994423 to the same values 
previously set
Bug #994423 [src:pytorch] pytorch-vision: FTBFS on armhf: Illegal instruction
Marked as found in versions pytorch/1.7.1-7.
> retitle -1 pytorch: Baseline violation on armhf
Bug #994423 [src:pytorch] pytorch-vision: FTBFS on armhf: Illegal instruction
Changed Bug title to 'pytorch: Baseline violation on armhf' from 
'pytorch-vision: FTBFS on armhf: Illegal instruction'.
> affects -1 python3-torch src:pytorch-vision
Bug #994423 [src:pytorch] pytorch: Baseline violation on armhf
Added indication that 994423 affects python3-torch and src:pytorch-vision

-- 
994423: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994423
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Adrian Bunk
Control: reassign -1 src:pytorch 1.7.1-7
Control: retitle -1 pytorch: Baseline violation on armhf
Control: affects -1 python3-torch src:pytorch-vision

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

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

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

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

> Cheers

cu
Adrian



Bug#994424: marked as done (spice-vdagent FTBFS: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' instead [-Werror=deprecated-declarations])

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 17:54:31 +
with message-id 
and subject line Bug#994424: fixed in spice-vdagent 0.20.0-3
has caused the Debian Bug report #994424,
regarding spice-vdagent FTBFS: error: ‘g_memdup’ is deprecated: Use 'g_memdup2' 
instead [-Werror=deprecated-declarations]
to be marked as done.

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

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


-- 
994424: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994424
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: spice-vdagent
Version: 0.20.0-2
Severity: serious
Tags: ftbfs

spice-vdagent fails to build from source in unstable. A non-parallel
build ends as follows:

| gcc -DHAVE_CONFIG_H -I. -I./src   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/libdrm  -I/usr/include/spice-1 -pthread 
-I/usr/include/gio-unix-2.0 -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
-I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/x86_64-linux-gnu -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -I./src -DUDSCS_NO_SERVER  -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Werror -Wp,-D_FORTIFY_SOURCE=2 
-fno-strict-aliasing -fstack-protector --param=ssp-buffer-size=4 -c -o 
src/vdagent/spice_vdagent-x11-randr.o `test -f 'src/vdagent/x11-randr.c' || 
echo './'`src/vdagent/x11-randr.c
| src/vdagent/x11-randr.c: In function ‘vdagent_x11_set_monitor_config’:
| src/vdagent/x11-randr.c:1007:21: error: ‘g_memdup’ is deprecated: Use 
'g_memdup2' instead [-Werror=deprecated-declarations]
|  1007 | g_memdup(mon_config, 
config_size(mon_config->num_of_monitors));
|   | ^~~~
| In file included from /usr/include/glib-2.0/glib.h:82,
|  from src/vdagent/x11-randr.c:25:
| /usr/include/glib-2.0/glib/gstrfuncs.h:257:23: note: declared here
|   257 | gpointer  g_memdup (gconstpointer mem,
|   |   ^~~~
| cc1: all warnings being treated as errors
| make[1]: *** [Makefile:1184: src/vdagent/spice_vdagent-x11-randr.o] Error 1
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:18: build] Error 25
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Helmut
--- End Message ---
--- Begin Message ---
Source: spice-vdagent
Source-Version: 0.20.0-3
Done: Adrian Bunk 

We believe that the bug you reported is fixed in the latest version of
spice-vdagent, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 994...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Adrian Bunk  (supplier of updated spice-vdagent package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Oct 2021 20:30:48 +0300
Source: spice-vdagent
Architecture: source
Version: 0.20.0-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Adrian Bunk 
Closes: 994424
Changes:
 spice-vdagent (0.20.0-3) unstable; urgency=medium
 .
   * QA upload.
   * Add patch for autoconf 2.71 compatibility. (Closes: #994424)
Checksums-Sha1:
 37f4967a5b797c8034e2e9fb568ce24abcc56bd7 2450 spice-vdagent_0.20.0-3.dsc
 d923243bd2c2d81996d1e7833f2d29b013bf9396 21556 
spice-vdagent_0.20.0-3.debian.tar.xz
Checksums-Sha256:
 3eec040059f76a8c5491cdc4ecab466fadce9661e1610401d89345e91a77 2450 
spice-vdagent_0.20.0-3.dsc
 174d7e886cdccc7452c281526f0958384519662a3733646fc2338155ec399e54 21556 
spice-vdagent_0.20.0-3.debian.tar.xz
Files:
 

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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tags -1 + patch
Bug #995624 [src:pktstat] pktstat FTBFS: error: format not a string literal and 
no format arguments [-Werror=format-security]
Added tag(s) patch.

-- 
995624: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995624
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Sven Joachim
Control: tags -1 + patch

Am 03.10.2021 um 12:00 schrieb Helmut Grohne:

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

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

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

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

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



Bug#995584: marked as done (ht-el build-depends on removed transitional package.)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 17:49:43 +
with message-id 
and subject line Bug#995584: fixed in ht-el 2.3-2
has caused the Debian Bug report #995584,
regarding ht-el build-depends on removed transitional package.
to be marked as done.

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

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


-- 
995584: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995584
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: ht-el
Version: 2.3-1
Severity: serious
Justification: rc policy - "packages must be buildable within the same release"
Tags: bookworm, sid

ht-el build-depends on the dash-el binary package which is no longer built by 
the
dash-el source package. It is still present in unstable as a cruft package but
is completely gone from testing.

Please update your build-dependency.
--- End Message ---
--- Begin Message ---
Source: ht-el
Source-Version: 2.3-2
Done: Lev Lamberov 

We believe that the bug you reported is fixed in the latest version of
ht-el, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 995...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Lev Lamberov  (supplier of updated ht-el package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Oct 2021 22:22:53 +0500
Source: ht-el
Architecture: source
Version: 2.3-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Emacsen team 
Changed-By: Lev Lamberov 
Closes: 995584
Changes:
 ht-el (2.3-2) unstable; urgency=medium
 .
   * d/control: Build-Depend on elpa-dash, not dash-el (Closes: #995584)
   * d/control: Declare Standards-Version 4.6.0 (no changes needed)
Checksums-Sha1:
 7be1b1aad8a5296776c2a77c776a0e1143ca6ddf 1899 ht-el_2.3-2.dsc
 b819bd6771feacd3c1c96781bee5d99fe29b5cbd 2692 ht-el_2.3-2.debian.tar.xz
 d7c88f3d4ac4e45ce2789528e8b4f3e336274887 7817 ht-el_2.3-2_amd64.buildinfo
Checksums-Sha256:
 dba86d7a3bb68a1367bf7346e5c75d6de231ee37cfc68a906ac1a4313053ba26 1899 
ht-el_2.3-2.dsc
 dc3756c2fc006833edffedc816d4453a3dcb46e547343667d2810cf6007d27a1 2692 
ht-el_2.3-2.debian.tar.xz
 a260f503843ec9cc86b0a696dbd0bc85d8b963f7a02b075606db02f66c8753d9 7817 
ht-el_2.3-2_amd64.buildinfo
Files:
 c97bae13a7e5a08c1a5a15e286474479 1899 lisp optional ht-el_2.3-2.dsc
 ef1051e60ec4d6c18b3a89133d9e4123 2692 lisp optional ht-el_2.3-2.debian.tar.xz
 4738dfae33e3f4eceb90a85163e301aa 7817 lisp optional ht-el_2.3-2_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE3mumcdV9mwCc9oZQXudu4gIW0qUFAmFoaA4ACgkQXudu4gIW
0qVGSA//a4ejy3XadnScsesvxl7bO1qZ4nGwIUMeGl4N1EF6QhQeNTWUuLDmMQWW
1L1aaGV4histkdNN/u/+llap+ep2Oea6ALbUZDNnM27eYV0Wj5diclFv6qVQjoGD
Y9GnlbXsfpvZIZRzK2idb1oFNNOVtH+dOnDaO7dp46Djq/WJNdGpjrbje7QWUHba
G7dnv76cPRHpY2kB9gMoafkJkSpRcsddWjKnSl60CDVRc7LDZA1BAw1ZVbq3RH2q
qJcUwbylw+eB3xUcDT8YMbxqh7kCXC2Vz3BfM09Ib/SSZ2BMsee9SbDTCHnoO90v
iBOsUNVrymxy/62HeCYF71g4ZDkGg85MrMNy7l1P6g7YGYrEM/76KfO0KAUJ4XyD
oWgjk8aFB9NF+s+05a1HkZcCR3FU5rU4cBNi69eV3WNy1OqjmwYI45mQBg4Ci6Hx
Wf3gpchqXDDCokh5OPwq3WBRx7MHa40d1ichHuqyy22iYKT6oDV8c1URol5T6l3m
+Mp5jieBgZNpxb2uexa3WDU1PDJwhjWC5QSAIQTOM97sZIG1t70RZ8wIQyiLvAtk
k3vk/SveNjVZIl7SYjC4F+z4QfPwyk8WZxoJeQURnSyeJ8Ff91Dr9EVa8+9US2Fr
n62lvZSmo6FFSWaSEZbJFhvg6zSX4IYX0eXuZu73tevzkuO273E=
=K7Zv
-END PGP SIGNATURE End Message ---


Bug#993201: fixed in upstream pull request

2021-10-14 Thread Christian Lauinger
I fixed it and created a pull request upstream:
https://gitlab.com/bertoldia/gnome-shell-trash-extension/-/merge_requests/23



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

2021-10-14 Thread Ondrej Zary
e46f76c9749d7758765ba274a212cfc2dcf3eeb8 is the first bad commit
commit e46f76c9749d7758765ba274a212cfc2dcf3eeb8
Author: Marko Mäkelä 
Date:   Mon Jun 21 12:34:07 2021 +0300

MDEV-15912: Remove traces of insert_undo

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

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

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



-- 
Ondrej Zary



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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 libleveldb1d
Bug #996486 [libleveldb1d] bitcoind: fails to start with undefined symbol: 
_ZTIN7leveldb6LoggerE
Ignoring request to reassign bug #996486 to the same package
> affects -1 bitcoind
Bug #996486 [libleveldb1d] bitcoind: fails to start with undefined symbol: 
_ZTIN7leveldb6LoggerE
Ignoring request to set affects of bug 996486 to the same value previously set

-- 
996486: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996486
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Jonas Smedegaard
Control: reassign -1 libleveldb1d
Control: affects -1 bitcoind

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

Thanks for reporting this issue, Vincas.

Sounds like a bug in libleveldb1d.


 - Jonas

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

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

signature.asc
Description: signature


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

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> reassign -1 libleveldb1d
Bug #996486 [bitcoind] bitcoind: fails to start with undefined symbol: 
_ZTIN7leveldb6LoggerE
Bug reassigned from package 'bitcoind' to 'libleveldb1d'.
No longer marked as found in versions bitcoin/22.0-1.
Ignoring request to alter fixed versions of bug #996486 to the same values 
previously set
> affects -1 bitcoind
Bug #996486 [libleveldb1d] bitcoind: fails to start with undefined symbol: 
_ZTIN7leveldb6LoggerE
Added indication that 996486 affects bitcoind

-- 
996486: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996486
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: [bts-link] source package prometheus

2021-10-14 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package prometheus
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #995999 (http://bugs.debian.org/995999)
> # Bug title: FTBFS: FAIL: TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks
> #  * https://github.com/prometheus/prometheus/issues/8403
> #  * remote status changed: (?) -> closed
> #  * closed upstream
> tags 995999 + fixed-upstream
Bug #995999 [prometheus] FTBFS: FAIL: 
TestChunkDiskMapper_WriteChunk_Chunk_IterateChunks
Added tag(s) fixed-upstream.
> usertags 995999 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
995999: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995999
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



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

2021-10-14 Thread Vincas Dargis
Package: bitcoind
Version: 22.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

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

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

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

It seems libleveldb1d 1.23-2 broke bitcoind?

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

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

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

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

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

-- no debconf information



Processed: closing 984103

2021-10-14 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> close 984103 1.2.7-1
Bug #984103 [src:libedlib] libedlib: ftbfs with GCC-11
Marked as fixed in versions libedlib/1.2.7-1.
Bug #984103 [src:libedlib] libedlib: ftbfs with GCC-11
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
984103: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984103
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#984004: marked as done (briquolo: ftbfs with GCC-11)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 16:18:41 +
with message-id 
and subject line Bug#984004: fixed in briquolo 0.5.7-10
has caused the Debian Bug report #984004,
regarding briquolo: ftbfs with GCC-11
to be marked as done.

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

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


-- 
984004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:briquolo
Version: 0.5.7-9
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/briquolo_0.5.7-9_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
 from MOGL_ElementPanneau.cpp:23:
MOGL_PoliceTTF.h:142:25: warning: unnecessary parentheses in declaration of 
‘_Correspondance’ [-Wparentheses]
  142 | MOGL_Struct_Carac * (_Correspondance[256-32]);
  | ^
MOGL_PoliceTTF.h:142:25: note: remove parentheses
  142 | MOGL_Struct_Carac * (_Correspondance[256-32]);
  | ^
  | -   -
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DSRCTOPDIR=\"/<>\"  
-DDATADIR_BRIQUOLO=\"/usr/share/games/briquolo\" -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wall -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security  
-I/usr/include/libpng16 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o 
MOGL_Fenetre.o MOGL_Fenetre.cpp
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DSRCTOPDIR=\"/<>\"  
-DDATADIR_BRIQUOLO=\"/usr/share/games/briquolo\" -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wall -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security  
-I/usr/include/libpng16 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o 
MOGL_FenetreKit.o MOGL_FenetreKit.cpp
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -DSRCTOPDIR=\"/<>\"  
-DDATADIR_BRIQUOLO=\"/usr/share/games/briquolo\" -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wall -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security  
-I/usr/include/libpng16 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o 
MOGL_GenerateurParticule.o MOGL_GenerateurParticule.cpp
MOGL_EnsembleObjet.cpp: In member function ‘bool 
MOGL_EnsembleObjet::ChargerArmaturePeau(char*, MOGL_GestionnaireTexture)’:
MOGL_EnsembleObjet.cpp:260:16: warning: variable ‘PtNum’ set but not used 
[-Wunused-but-set-variable]
  260 |   unsigned int PtNum[3];
  |^
MOGL_Fenetre.cpp: In member function ‘bool MOGL_Fenetre::Initialiser()’:
MOGL_Fenetre.cpp:112:30: warning: variable ‘info’ set but not used 
[-Wunused-but-set-variable]
  112 | const SDL_VideoInfo* info;
  |  ^~~~
MOGL_Fenetre.cpp: In member function ‘bool MOGL_Fenetre::SetMode(int, int, 
bool)’:
MOGL_Fenetre.cpp:349:30: warning: variable ‘info’ set but not used 
[-Wunused-but-set-variable]
  349 | const SDL_VideoInfo* info;
  |  ^~~~
MOGL_Fenetre.cpp: In member function ‘void MOGL_Fenetre::_ManualResize(int, 
int)’:
MOGL_Fenetre.cpp:538:26: warning: variable ‘info’ set but not used 
[-Wunused-but-set-variable]
  538 | const 

Bug#983986: marked as done (berusky: ftbfs with GCC-11)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 16:18:35 +
with message-id 
and subject line Bug#983986: fixed in berusky 1.7.2-2
has caused the Debian Bug report #983986,
regarding berusky: ftbfs with GCC-11
to be marked as done.

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

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


-- 
983986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983986
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:berusky
Version: 1.7.2-1
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/berusky_1.7.2-1_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
  601 | RECT r = {EDIT_ITEM_PICT_START_X+EDITOR_ITEM_SIZE_X+10,
In file included from berusky.h:109,
 from editor.cpp:45:
defines.h:101:66: warning: narrowing conversion of 
‘(berusky_config::editor_screen_start_y + 
berusky_config::level_resolution_y) - 140) + 20) + 20) + 10)’ from ‘int’ to 
‘Sint16’ {aka ‘short int’} [-Wnarrowing]
  101 | #define EDIT_ITEM_PICT_START_Y(EDIT_ITEM_START_Y+EDIT_ITEM_DY+10)
  |   ~~~^~~~
editor.cpp:602:15: note: in expansion of macro ‘EDIT_ITEM_PICT_START_Y’
  602 |   EDIT_ITEM_PICT_START_Y,
  |   ^~
editor.cpp: In member function ‘void editor_gui::layer_status_create()’:
defines.h:84:55: warning: narrowing conversion of 
‘(berusky_config::editor_resolution_x - ((20 * 3) * 2))’ from ‘int’ to ‘Uint16’ 
{aka ‘short unsigned int’} [-Wnarrowing]
   84 | #define EDITOR_LAYER_STATUS_DX
(EDITOR_RESOLUTION_X-EDITOR_LAYER_STATUS_X)
  |   
^~~
editor.cpp:819:13: note: in expansion of macro ‘EDITOR_LAYER_STATUS_DX’
  819 | EDITOR_LAYER_STATUS_DX,
  | ^~
editor.cpp: In member function ‘void editor_gui::level_config()’:
defines.h:87:52: warning: narrowing conversion of 
‘berusky_config::editor_screen_start_x’ from ‘int’ to ‘Sint16’ {aka ‘short 
int’} [-Wnarrowing]
   87 | #define EDITOR_SCREEN_START_X 
(berusky_config::editor_screen_start_x)
  |   
~^~
editor.cpp:960:13: note: in expansion of macro ‘EDITOR_SCREEN_START_X’
  960 |   RECT r = 
{EDITOR_SCREEN_START_X,EDITOR_SCREEN_START_Y,LEVEL_RESOLUTION_X,LEVEL_RESOLUTION_Y};
  | ^
defines.h:88:52: warning: narrowing conversion of 
‘berusky_config::editor_screen_start_y’ from ‘int’ to ‘Sint16’ {aka ‘short 
int’} [-Wnarrowing]
   88 | #define EDITOR_SCREEN_START_Y 
(berusky_config::editor_screen_start_y)
  |   
~^~
editor.cpp:960:35: note: in expansion of macro ‘EDITOR_SCREEN_START_Y’
  960 |   RECT r = 
{EDITOR_SCREEN_START_X,EDITOR_SCREEN_START_Y,LEVEL_RESOLUTION_X,LEVEL_RESOLUTION_Y};
  |   ^
defines.h:51:52: warning: narrowing conversion of 
‘berusky_config::level_resolution_x’ from ‘int’ to ‘Uint16’ {aka ‘short 
unsigned int’} [-Wnarrowing]
   51 | #define LEVEL_RESOLUTION_X   

Processed: Bug#984004 marked as pending in briquolo

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #984004 [src:briquolo] briquolo: ftbfs with GCC-11
Added tag(s) pending.

-- 
984004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984004
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#984004: marked as pending in briquolo

2021-10-14 Thread Markus Koschany
Control: tag -1 pending

Hello,

Bug #984004 in briquolo 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/games-team/briquolo/-/commit/a02a66786ecc1fc54c9f26b5e3336b2a44ded8c8


Force C++14 because this code is not C++17 ready.

Closes: #984004


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/984004



Processed: Bug#983986 marked as pending in berusky

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #983986 [src:berusky] berusky: ftbfs with GCC-11
Added tag(s) pending.

-- 
983986: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983986
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#983986: marked as pending in berusky

2021-10-14 Thread Markus Koschany
Control: tag -1 pending

Hello,

Bug #983986 in berusky 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/games-team/berusky/-/commit/bdae486affc658003460704c8ad97c70f4a14712


Force C++14 because the code is not C++17 ready.

Closes: #983986


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/983986



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

2021-10-14 Thread Georges Khaznadar
Dear Paul,

thank you for your e-mail.

I believed that I fixed the FTBFS bug when I uploaded the release 4.2-1
of units-filter approximately one month ago. However, I probably did too
much work: I enriched the package with a new graphic user interface, so
the new package is now in the NEW queue.

If I upload another package, without the new features (and the new
binary artifact), is there a chance that it will be taken in
consideration by the build system ? I fear that it would compete with
the other package in the NEW queue.

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

Thank you in advance for any suggestion.

Best regards,   Georges.


Paul Gevers a écrit :
> Source: units-filter
> Version: 4.0-1
> Severity: serious
> Control: close -1 4.0.1-1
> Tags: sid bookworm
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 992508
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 60 days as having a Release Critical bug in
> testing [1]. Your package src:units-filter has been trying to migrate
> for 61 days [2]. Hence, I am filing this bug.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bookworm, so
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=units-filter
> 
> 




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature


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

2021-10-14 Thread Helmut Grohne
Source: mp3blaster
Version: 1:3.2.6-2
Severity: serious
Tags: ftbfs

mp3blaster fails to build from source in unstable due to ncurses having
gained format string annotations. A non-parallel build now ends as
follows:

| g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/ncurses -I. -I/usr/include  
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Wdate-time -D_FORTIFY_SOURCE=2 
 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -std=gnu++98 -c -o nullmixer.o nullmixer.cc
| nmixer.cc: In member function ‘void NMixer::DrawScrollbar(short int, int)’:
| nmixer.cc:219:26: error: format not a string literal and no format arguments 
[-Werror=format-security]
|   219 | mvwprintw(mixwin, my_y - 1, my_x, (char*)source);
|   | ~^~~
| cc1plus: some warnings being treated as errors
| make[3]: *** [Makefile:445: nmixer.o] Error 1
| make[3]: Leaving directory '/<>/nmixer'
| make[2]: *** [Makefile:457: all-recursive] Error 1
| make[2]: Leaving directory '/<>'
| make[1]: *** [Makefile:355: all] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j8 returned exit code 2
| make: *** [debian/rules:9: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Helmut



Bug#996480: dvbstreamer: FTBFS with autoconf 2.71

2021-10-14 Thread Bastian Germann

Source: dvbstreamer
Version: 2.1.0-5.1
Severity: serious
Tags: sid bookworm

dvbstreamer fails building with autoconf 2.71. A build log of an 
unrelated NMU can be seen at 
https://buildd.debian.org/status/fetch.php?pkg=dvbstreamer=amd64=2.1.0-5.3=1634219631


(On my test machine there was still an older autoconf: my bad...)



Bug#996478: checkinstall: FTBFS with glibc 2.33+

2021-10-14 Thread Lukas Märdian
Package: checkinstall
Version: 1.6.2+git20170426.d24a630-2
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu  ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Dear Maintainer,

checkinstall fails to build from source with the following error if
compiled with glibc 2.33+:

gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>/checkinstall-1.6.2+git20170426.d24a630=. 
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-Bsymbolic-functions -flto=auto -Wl,-z,relro -Wall 
-c -g -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DVERSION=\"0.7.0beta7\" 
installwatch.c
installwatch.c: In function ‘true_stat’:
installwatch.c:162:27: error: ‘_STAT_VER’ undeclared (first use in this 
function)
  162 | return true_xstat(_STAT_VER,pathname,info);
  |   ^
installwatch.c:162:27: note: each undeclared identifier is reported only once 
for each function it appears in
installwatch.c: In function ‘true_mknod’:
installwatch.c:166:28: error: ‘_MKNOD_VER’ undeclared (first use in this 
function)
  166 | return true_xmknod(_MKNOD_VER,pathname,mode,);
  |^~
installwatch.c: In function ‘true_lstat’:
installwatch.c:170:28: error: ‘_STAT_VER’ undeclared (first use in this 
function)
  170 | return true_lxstat(_STAT_VER,pathname,info);
  |^
installwatch.c: In function ‘true_fstatat’:
installwatch.c:174:30: error: ‘_STAT_VER’ undeclared (first use in this 
function)
  174 | return true_fxstatat(_STAT_VER, dirfd, pathname, info, flags);
  |  ^
installwatch.c: In function ‘true_fstatat64’:
installwatch.c:178:32: error: ‘_STAT_VER’ undeclared (first use in this 
function)
  178 | return true_fxstatat64(_STAT_VER, dirfd, pathname, info, flags);
  |^
installwatch.c: In function ‘true_mknodat’:
installwatch.c:182:30: error: ‘_MKNOD_VER’ undeclared (first use in this 
function)
  182 | return true_xmknodat(_MKNOD_VER, dirfd, pathname, mode, );
  |  ^~
installwatch.c: In function ‘instw_init’:
installwatch.c:1211:17: warning: ignoring return value of ‘realpath’ declared 
with attribute ‘warn_unused_result’ [-Wunused-result]
 1211 | realpath(proot,wrkpath);
  | ^~~
installwatch.c:1330:17: warning: ignoring return value of ‘realpath’ declared 
with attribute ‘warn_unused_result’ [-Wunused-result]
 1330 | realpath(__instw.root,wrkpath);
  | ^~
installwatch.c:1348:25: warning: ignoring return value of ‘realpath’ declared 
with attribute ‘warn_unused_result’ [-Wunused-result]
 1348 | realpath(pexclude,wrkpath);
  | ^~
installwatch.c: In function ‘true_stat’:
installwatch.c:163:1: warning: control reaches end of non-void function 
[-Wreturn-type]
  163 | }
  | ^
installwatch.c: In function ‘copy_path’:
installwatch.c:757:33: warning: ignoring return value of ‘write’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
  757 | write(translfd,buffer,bytes);
  | ^~~~
installwatch.c: In function ‘true_lstat’:
installwatch.c:171:1: warning: control reaches end of non-void function 
[-Wreturn-type]
  171 | }
  | ^
installwatch.c: In function ‘true_mknod’:
installwatch.c:167:1: warning: control reaches end of non-void function 
[-Wreturn-type]
  167 | }
  | ^
make[3]: *** [Makefile:22: installwatch.o] Error 1
make[3]: Leaving directory 
'/<>/checkinstall-1.6.2+git20170426.d24a630/installwatch'
make[2]: *** [Makefile:12: all] Error 2
make[2]: Leaving directory 
'/<>/checkinstall-1.6.2+git20170426.d24a630'
dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" returned 
exit code 2
make[1]: *** [debian/rules:10: override_dh_auto_build] Error 25
make[1]: Leaving directory 
'/<>/checkinstall-1.6.2+git20170426.d24a630'
make: *** [debian/rules:7: build] Error 2
dpkg-buildpackage.pl: error: debian/rules build subprocess returned exit status 
2


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

  * Fix FTBFS with glibc 2.33+ (dropped definitions of _STAT_VER & _MKNOD_VER)


Thanks for considering the patch.

Cheers,
  Lukas


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

Kernel: Linux 5.13.0-16-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 

Bug#991970: marked as done (piuparts: ftbfs with golang-1.16)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 13:54:12 +
with message-id 
and subject line Bug#991970: fixed in piuparts 1.1.5
has caused the Debian Bug report #991970,
regarding piuparts: ftbfs with golang-1.16
to be marked as done.

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

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


-- 
991970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991970
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: piuparts
Version: 1.1.4
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Dear Maintainer,

The attached patch will fix a FTBFS with golang-1.16.

This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/1939171

The description, from Brian Murray, follows:

In 
https://launchpadlibrarian.net/551476957/buildlog_ubuntu-impish-amd64.piuparts_1.1.4_BUILDING.txt.gz
 we can see the following:

touch build-stamp
(cd helpers/debiman-piuparts-distill && go build)
go: go.mod file not found in current directory or any parent directory; see 'go 
help modules'
make[2]: *** [Makefile:61: build-master-stamp] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

This happens with piuparts version 1.1.4 and a test rebuild of 1.12 using 
golang-go (which depends on golang-1.16-go) also failed.

-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
>From 63a6d460c8578ec9b5e2c400d7d9ec5b22f14f81 Mon Sep 17 00:00:00 2001
From: Brian Murray 
Date: Fri, 6 Aug 2021 12:49:18 -0700
Subject: [PATCH] Fix FTBFS w/ golang-1.16

---
 CONTRIBUTING | 1 +
 Makefile | 2 +-
 debian/changelog | 7 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 932bee56..5d1f732d 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -16,6 +16,7 @@ or to the tracking bug: @bugs.debian.org.
 
 One possible workflow:
   git clone https://salsa.debian.org/debian/piuparts.git
+  cd piuparts
   git checkout origin/develop -b 
   
   git commit -a
diff --git a/Makefile b/Makefile
index df373eb5..ff7b7ca0 100644
--- a/Makefile
+++ b/Makefile
@@ -58,7 +58,7 @@ build-stamp: $(SCRIPTS_GENERATED) $(DOCS_GENERATED) Makefile
touch $@
 
 build-master-stamp:
-   (cd helpers/debiman-piuparts-distill && go build)
+   (go mod init helpers/debiman-piuparts-distill && cd 
helpers/debiman-piuparts-distill && go build)
touch $@
 
 build-doc: $(DOCS_GENERATED)
diff --git a/debian/changelog b/debian/changelog
index 251b90ee..6ec38e22 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+piuparts (1.1.5) UNRELEASED; urgency=medium
+
+  * Makefile: Execute go mod init before running go build, fixes FTBFS with
+golang-1.16. (LP: #1939171)
+
+ -- Brian Murray   Fri, 06 Aug 2021 12:47:14 -0700
+
 piuparts (1.1.3) unstable; urgency=medium
 
   [ Michael Prokop ]
-- 
2.31.1

--- End Message ---
--- Begin Message ---
Source: piuparts
Source-Version: 1.1.5
Done: Holger Levsen 

We believe that the bug you reported is fixed in the latest version of
piuparts, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 991...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Holger Levsen  (supplier of updated piuparts package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Oct 2021 15:23:26 +0200
Source: piuparts
Architecture: source
Version: 1.1.5
Distribution: unstable
Urgency: medium
Maintainer: piuparts developers team 
Changed-By: Holger Levsen 
Closes: 991970
Changes:
 piuparts (1.1.5) unstable; urgency=medium
 .
   [ Nicolas Dandrimont ]
   * pejacevic: update enabled suites for bullseye as stable, bookworm as
 testing.
   * Add news for the bullseye update.
   * Fix perjacevic typo in docs.
 .
   [ David Steele ]
   * Remove oldstable results from summary.json.
 .
   [ Athos Ribeiro ]
   * d/rules: set GO111MODULE to auto to maintain pre Go 

Bug#983971: marked as done (asc: ftbfs with GCC-11)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 13:33:26 +
with message-id 
and subject line Bug#983971: fixed in asc 2.6.1.0-8
has caused the Debian Bug report #983971,
regarding asc: ftbfs with GCC-11
to be marked as done.

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

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


-- 
983971: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983971
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:asc
Version: 2.6.1.0-7
Severity: normal
Tags: sid bookworm
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-11

[This bug is not targeted to the upcoming bullseye release]

Please keep this issue open in the bug tracker for the package it
was filed for.  If a fix in another package is required, please
file a bug for the other package (or clone), and add a block in this
package. Please keep the issue open until the package can be built in
a follow-up test rebuild.

The package fails to build in a test rebuild on at least amd64 with
gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
severity of this report will be raised before the bookworm release,
so nothing has to be done for the bullseye release.

The full build log can be found at:
http://people.debian.org/~doko/logs/20210228/filtered/gcc11/asc_2.6.1.0-7_unstable_gcc11.log
The last lines of the build log are at the end of this report.

To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

  apt-get -t=experimental install g++ 

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-11/porting_to.html

GCC 11 defaults to the GNU++17 standard.  If your package installs
header files in /usr/include, please don't work around C++17 issues
by choosing a lower C++ standard for the package build, but fix these
issues to build with the C++17 standard.

[...]
/bin/bash ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../../..   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I../../../source/libs/loki-0.1.6/include/ -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-sign-compare -D_UNIX_ -D_SDL_ 
-I/usr/include/freetype2 -I/usr/include/libpng16  -DSIZE_T_not_identical_to_INT 
-c -o Singleton.lo ./src/Singleton.cpp
/bin/bash ../../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../../..   -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I../../../source/libs/loki-0.1.6/include/ -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-sign-compare -D_UNIX_ -D_SDL_ 
-I/usr/include/freetype2 -I/usr/include/libpng16  -DSIZE_T_not_identical_to_INT 
-c -o SmartPtr.lo ./src/SmartPtr.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I../../../source/libs/loki-0.1.6/include/ -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-sign-compare -D_UNIX_ -D_SDL_ 
-I/usr/include/freetype2 -I/usr/include/libpng16 -DSIZE_T_not_identical_to_INT 
-c ./src/SmartPtr.cpp -o SmartPtr.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I../../../source/libs/loki-0.1.6/include/ -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-sign-compare -D_UNIX_ -D_SDL_ 
-I/usr/include/freetype2 -I/usr/include/libpng16 -DSIZE_T_not_identical_to_INT 
-c ./src/SmallObj.cpp -o SmallObj.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.0 
-I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ 
-I../../../source/libs/loki-0.1.6/include/ -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-sign-compare -D_UNIX_ -D_SDL_ 
-I/usr/include/freetype2 -I/usr/include/libpng16 -DSIZE_T_not_identical_to_INT 
-c ./src/Singleton.cpp -o Singleton.o
In file included 

Processed: Bug#983971 marked as pending in asc

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #983971 [src:asc] asc: ftbfs with GCC-11
Added tag(s) pending.

-- 
983971: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983971
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#983971: marked as pending in asc

2021-10-14 Thread Markus Koschany
Control: tag -1 pending

Hello,

Bug #983971 in asc 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/games-team/asc/-/commit/ca90275ff5140b6e76acb7dcfd9879aa02e20399


Build with C++11 standard.

Closes: #983971


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/983971



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

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 13:03:36 +
with message-id 
and subject line Bug#996408: fixed in libepoxy 1.5.9-2
has caused the Debian Bug report #996408,
regarding libepoxy: autopkgtest failure: No such build data file as 
"'/tmp/autopkgtest-lxc.08f3y1bd/downtmp/build.XWR/src/meson-private/build.dat'".
to be marked as done.

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

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


-- 
996408: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996408
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libepoxy
Version: 1.5.9-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

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

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

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

Paul

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

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


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

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



OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: libepoxy
Source-Version: 1.5.9-2
Done: Timo Aaltonen 

We believe that the bug you reported is fixed in the latest version of
libepoxy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 996...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Timo Aaltonen  (supplier of updated libepoxy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Oct 2021 15:45:29 +0300
Source: libepoxy
Built-For-Profiles: noudeb
Architecture: source
Version: 1.5.9-2
Distribution: unstable
Urgency: medium
Maintainer: Debian X Strike Force 
Changed-By: Timo Aaltonen 
Closes: 996408
Changes:
 libepoxy (1.5.9-2) unstable; urgency=medium
 .
   * Clean up autopkgtest cruft that shouldn't have been included.
 (Closes: #996408)
Checksums-Sha1:
 28a4d03fe97f6daafd24e92b5ee92a539c3f4f14 2088 libepoxy_1.5.9-2.dsc
 1da99e308c408ab3e609d96cd10547190fbbda88 17448 libepoxy_1.5.9-2.debian.tar.xz
 eaec0a032b49f1cdb29d30262a1d9dd1a7d0591f 9530 libepoxy_1.5.9-2_source.buildinfo
Checksums-Sha256:
 0d1730d0e71bf958ff89294669b331c23cf19a72c26f0e4831074a98a8f1b969 2088 
libepoxy_1.5.9-2.dsc
 c14d46b1b4b1d7a2c6cabc8f0f7a552f5b439b33649cf2903a64dcf295f0715a 17448 
libepoxy_1.5.9-2.debian.tar.xz
 c10319d1d370eca7ebf7922e1e80c5dd548de4c1048886d4f02a9fd62556c76a 9530 
libepoxy_1.5.9-2_source.buildinfo
Files:
 22867247d6f479d141892bbdcab74b78 2088 libs optional libepoxy_1.5.9-2.dsc
 d5ea7d1a6904f7e1974a76acfce16170 17448 libs optional 
libepoxy_1.5.9-2.debian.tar.xz
 690bfe21de94f869ef8430ae2c423904 9530 libs optional 
libepoxy_1.5.9-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdS3ifE3rFwGbS2Yjy3AxZaiJhNwFAmFoJpMACgkQy3AxZaiJ
hNzlbxAArt/x5S7CMu5+lpyHngXwkJPvVpkKhmwFFEF3bdDHX4Dr98O53OMHcY2h
NYSpHqo8CIdmhHerLGQQf8LBlnbOSFXQ5LFP1Rhoh4MUzyl1PJhoZ9Hn5K0OUFF9
pUF74g+xLKLgNFPEPQcLB479kpnBtZq4HgcnaYppwl51lDrlpHMHBSal4rYNnFBm
H+dU3naEiLVsXXRu7lls5PodexgFPd/UUCj5VDBC0qIySmmGcLFLMXqmieu//2g5
kh1VHIaG2ZfKusIWJ93EWjpO0c8/SWXIFLvN9J4nqcCmOldknNM1kamNl2TKyhNJ
giOWxDKrj+bwjAMW/ExwWC7cSQIfNb9jByGcDPWoeRRJLWWTKSX2Hbg3iadC5JKp
I9dyvHFvjfOUaf2akk6Z6rz39ph+kJmx7+Rk6bh1ujGY9xlWsyJCnP7/jrD4ZaHx
Qxu74LxVNr8UsQColsspyuRloXxLTYhnQGwBQz3Zq15gxyUCufY9Dn5wzIcvv17X
SHfs3O93xPuNZ/0lm9kN+Gec1U/ltlGYos1p+U2rcD0KTxNNGjv0Tc9W38+B+Elb
KS0eOUBZAYcnrPTTy3gWV40WGb9PHs7izWIsm61zn3uyC0oymaVtZYfMJHevaSte
k9YG4T/UAlp1WoiR8thCwF8WayDY9UNelksR/h+p3j85myJQfEg=
=WTJH
-END PGP SIGNATURE End Message ---


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

2021-10-14 Thread Timo Aaltonen

On 13.10.2021 22.09, Paul Gevers wrote:

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

Dear maintainer(s),

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

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

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

Paul

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

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


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

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



That was a lousy attempt at trying to run the build-time tests, 
uncommitted files were left on the repo and got included. I'll drop them.




--
t



Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

2021-10-14 Thread Andrea Turbiglio
On Wed, 13 Oct 2021 10:58:34 +0200 =?UTF-8?Q?Bernhard_=c3=9cbelacker?= 
 wrote:
> On Tue, 28 Sep 2021 15:01:22 +0200 uninsubria.it 
 wrote:

>
> > example from 'dmesg' output:
> > [Tue Sep 28 11:05:22 2021] omshell[4604]: segfault at 0 ip 
55623cdd06dc sp 7ffd5a2c7c78 error 4 in omshell[55623cd97000+45000]

> >
>
>
> Hello,
> maybe you can add a few pairs of the
> dmesg "segfault" and "code" lines.
> This would make it possible to locate the crashing instruction,
> and therefore maybe point to a source code line.
>
> Kind regards,
> Bernhard
>

>


Hi,

Fortunately our Rsyslog has some logs of the problem when it happened 
2-3 weeks ago.


It happened after migrating from Debian10 to Debian11 on our DHCPD 
production servers, so I had to rollback to the Deb10 snapshots to 
restore functionality.


If it's needed, I can try to recreate a testing environment with the 2 
servers having dhcpd failover partnership and see if the problem happens 
without dhcpd clients (or very few of them).


Thanks for your attention.


*DHCPD-SERVER1*

daemon.err-20210924.log.gz:Sep 24 15:24:01 Sep 24 15:24:01 $hostname1 
omshell[15957]: Bad descriptor 8.
daemon.err-20210924.log.gz:Sep 24 15:24:01 Sep 24 15:24:01 $hostname1 
omshell[15957]: Object 55b8caa695d0 io
daemon.err-20210924.log.gz:Sep 24 16:01:51 Sep 24 16:01:51 $hostname1 
omshell[5643]: Bad descriptor 8.
daemon.err-20210924.log.gz:Sep 24 16:01:51 Sep 24 16:01:51 $hostname1 
omshell[5643]: Object 564b87a855d0 io
daemon.err-20210924.log.gz:Sep 24 18:42:36 Sep 24 18:42:36 $hostname1 
omshell[24902]: Bad descriptor 8.
daemon.err-20210924.log.gz:Sep 24 18:42:36 Sep 24 18:42:36 $hostname1 
omshell[24902]: Object 55db2d44e5d0 io
daemon.err-20210924.log.gz:Sep 24 22:05:42 Sep 24 22:05:42 $hostname1 
omshell[48864]: Bad descriptor 8.
daemon.err-20210924.log.gz:Sep 24 22:05:43 Sep 24 22:05:42 $hostname1 
omshell[48864]: Object 55df88ace5d0 io
daemon.err-20210925.log.gz:Sep 25 07:14:13 Sep 25 07:14:13 $hostname1 
omshell[113565]: Bad descriptor 8.
daemon.err-20210925.log.gz:Sep 25 07:14:13 Sep 25 07:14:13 $hostname1 
omshell[113565]: Object 5610441a65d0 io
daemon.err-20210925.log.gz:Sep 25 07:24:19 Sep 25 07:24:18 $hostname1 
omshell[114622]: Bad descriptor 8.
daemon.err-20210925.log.gz:Sep 25 07:24:19 Sep 25 07:24:18 $hostname1 
omshell[114622]: Object 55bd6a3b95d0 io
daemon.err-20210925.log.gz:Sep 25 10:36:24 Sep 25 10:36:24 $hostname1 
omshell[137283]: Bad descriptor 8.
daemon.err-20210925.log.gz:Sep 25 10:36:24 Sep 25 10:36:24 $hostname1 
omshell[137283]: Object 55bcd68a55d0 io
daemon.err-20210925.log.gz:Sep 25 18:11:45 Sep 25 18:11:45 $hostname1 
omshell[190235]: Bad descriptor 8.
daemon.err-20210925.log.gz:Sep 25 18:11:45 Sep 25 18:11:45 $hostname1 
omshell[190235]: Object 55cf7d0525d0 io
daemon.err-20210926.log.gz:Sep 26 04:22:52 Sep 26 04:22:52 $hostname1 
omshell[262070]: Bad descriptor 8.
daemon.err-20210926.log.gz:Sep 26 06:44:17 Sep 26 06:44:17 $hostname1 
omshell[279284]: Bad descriptor 8.
daemon.err-20210926.log.gz:Sep 26 06:44:17 Sep 26 06:44:17 $hostname1 
omshell[279284]: Object 5611e3e6c5d0 io
daemon.err-20210926.log.gz:Sep 26 08:05:27 Sep 26 08:05:27 $hostname1 
omshell[289631]: Bad descriptor 8.
daemon.err-20210926.log.gz:Sep 26 08:05:27 Sep 26 08:05:27 $hostname1 
omshell[289631]: Object 557af2d875d0 io
daemon.err-20210926.log.gz:Sep 26 14:10:49 Sep 26 14:10:49 $hostname1 
omshell[332719]: Bad descriptor 8.
daemon.err-20210926.log.gz:Sep 26 14:10:49 Sep 26 14:10:49 $hostname1 
omshell[332719]: Object 55f9db1c05d0 io
daemon.err-20210927.log.gz:Sep 27 02:10:08 Sep 27 02:10:08 $hostname1 
omshell[417339]: Bad descriptor 8.
daemon.err-20210927.log.gz:Sep 27 02:10:08 Sep 27 02:10:08 $hostname1 
omshell[417339]: Object 55a1fa8085d0 io
daemon.err-20210928.log.gz:Sep 28 13:56:06 Sep 28 13:56:05 $hostname1 
omshell[19675]:  line 1: unknown token: obj
daemon.err-20210928.log.gz:Sep 28 13:56:06 Sep 28 13:56:05 $hostname1 
omshell[19675]: obj:
daemon.err-20210928.log.gz:Sep 28 13:56:06 Sep 28 13:56:05 $hostname1 
omshell[19675]: ^
daemon.err-20210928.log.gz:Sep 28 13:56:25 Sep 28 13:56:25 $hostname1 
omshell[20427]:  line 1: unknown token: obj
daemon.err-20210928.log.gz:Sep 28 13:56:25 Sep 28 13:56:25 $hostname1 
omshell[20427]: obj:
daemon.err-20210928.log.gz:Sep 28 13:56:25 Sep 28 13:56:25 $hostname1 
omshell[20427]: ^
kern.info-20210924.log.gz:Sep 24 15:24:01 Sep 24 15:24:01 $hostname1 
kernel: [1726104.115073] omshell[15957]: segfault at 0 ip 
55b8c9f4b6dc sp 74281c78 error 4 in omshell[55b8c9f12000+45000]
kern.info-20210924.log.gz:Sep 24 16:01:51 Sep 24 16:01:51 $hostname1 
kernel: [ 2073.362145] omshell[5643]: segfault at 0 ip 564b861f26dc 
sp 7b22d868 error 4 in omshell[564b861b9000+45000]
kern.info-20210924.log.gz:Sep 24 18:42:36 Sep 24 18:42:36 $hostname1 
kernel: [11718.391350] omshell[24902]: segfault at 0 ip 55db2c85d6dc 
sp 7ffcfd1c2ee8 error 4 in omshell[55db2c824000+45000]
kern.info-20210924.log.gz:Sep 24 

Bug#996451: src:gsl: fails to migrate to testing for too long: unresolved RC bug (found by autopkgtest breakage)

2021-10-14 Thread Dirk Eddelbuettel


On 14 October 2021 at 10:55, Paul Gevers wrote:
| Source: gsl
| Version: 2.6+dfsg-2
| Severity: serious
| Control: close -1 2.7+dfsg-2
| Tags: sid bookworm
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
| 
| Dear maintainer(s),
| 
| The Release Team considers packages that are out-of-sync between testing
| and unstable for more than 60 days as having a Release Critical bug in
| testing [1]. Your package src:gsl has been trying to migrate for 61 days
| [2]. Hence, I am filing this bug.
| 
| If a package is out of sync between unstable and testing for a longer
| period, this usually means that bugs in the package in testing cannot be
| fixed via unstable. Additionally, blocked packages can have impact on
| other packages, which makes preparing for the release more difficult.
| Finally, it often exposes issues with the package and/or
| its (reverse-)dependencies. We expect maintainers to fix issues that
| hamper the migration of their package in a timely manner.
| 
| This bug will trigger auto-removal when appropriate. As with all new
| bugs, there will be at least 30 days before the package is auto-removed.
| 
| I have immediately closed this bug with the version in unstable, so if
| that version or a later version migrates, this bug will no longer affect
| testing. I have also tagged this bug to only affect sid and bookworm, so
| it doesn't affect (old-)stable.
| 
| If you believe your package is unable to migrate to testing due to
| issues beyond your control, don't hesitate to contact the Release Team.

I believe this to be an issue in the three packages listed here:

https://qa.debian.org/excuses.php?package=gsl

As we see here, the package itself is just fine

https://buildd.debian.org/status/package.php?p=gsl

Dirk

| Paul
| 
| [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
| [2] https://qa.debian.org/excuses.php?package=gsl
| 
| 
| x[DELETED ATTACHMENT OpenPGP_signature, application/pgp-signature]

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



Bug#996462: marked as done (libc++-13-dev: uninstallable on s390x)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 12:04:46 +
with message-id 
and subject line Bug#996462: fixed in llvm-toolchain-13 1:13.0.0-5
has caused the Debian Bug report #996462,
regarding libc++-13-dev: uninstallable on s390x
to be marked as done.

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

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


-- 
996462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996462
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc++-13-dev
Version: 1:13.0.0-3
Severity: serious

Fixing #998510 causes installability issues on s390x:

$ apt-get install libc++-13-dev
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:
 libc++-13-dev : Depends: libunwind-13-dev but it is not installable
E: Unable to correct problems, you have held broken packages.


Cheers
-- 
Sebastian Ramacher
--- End Message ---
--- Begin Message ---
Source: llvm-toolchain-13
Source-Version: 1:13.0.0-5
Done: Sylvestre Ledru 

We believe that the bug you reported is fixed in the latest version of
llvm-toolchain-13, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 996...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sylvestre Ledru  (supplier of updated llvm-toolchain-13 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 14 Oct 2021 12:33:15 +0200
Source: llvm-toolchain-13
Architecture: source
Version: 1:13.0.0-5
Distribution: unstable
Urgency: medium
Maintainer: LLVM Packaging Team 
Changed-By: Sylvestre Ledru 
Closes: 996462
Changes:
 llvm-toolchain-13 (1:13.0.0-5) unstable; urgency=medium
 .
   *  Restrict the dependency on libunwind-13-dev from Package: libc++-13-dev
  on amd64 arm64 armhf i386 mips64el ppc64el ppc64 riscv64
  (Closes: #996462)
Checksums-Sha1:
 e9ce8474f0bda3349e756fe7e3b8f67949c505cc 6703 llvm-toolchain-13_13.0.0-5.dsc
 b49ea84eff71fe65e6a9c760766cb725a0a66cf5 141688 
llvm-toolchain-13_13.0.0-5.debian.tar.xz
 56fdb382af6a654630dcd69a7162caf33e0d8c0b 28773 
llvm-toolchain-13_13.0.0-5_amd64.buildinfo
Checksums-Sha256:
 4482d48d21f62abc8abf715c28b7b53676d52953392da51a786ddaa16dd67b0d 6703 
llvm-toolchain-13_13.0.0-5.dsc
 79eeb3599df5eee8553946d889a158f347d39f7f5adf1452b3381c411db9fcae 141688 
llvm-toolchain-13_13.0.0-5.debian.tar.xz
 3f0cf6178f66a7f3ee4308b6493c46707cf3d6ef00489d59157ab906b6dd6b3e 28773 
llvm-toolchain-13_13.0.0-5_amd64.buildinfo
Files:
 85c501a4383ec8ed712a609641342948 6703 devel optional 
llvm-toolchain-13_13.0.0-5.dsc
 7f997df42354b9adfcf7461a045036c0 141688 devel optional 
llvm-toolchain-13_13.0.0-5.debian.tar.xz
 90f50acc45d9e6a176c65df745f9f0f4 28773 devel optional 
llvm-toolchain-13_13.0.0-5_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmFoFmEACgkQfmUo2nUv
G+HZcw/8DjVbkc1Xyn/w/+EIZBiU85VbI9Gnt5GqNRjy4QsiyLm7oE4Ne6vRiFBP
H3c/e/ScKMhCJO/54SOUl64pmWAiSHXiq/6U7FFUHf4ayfEX32/kNsVU3fZsFTZC
sDf0NZqe+CKCQ4Eio1eaTOQW8nFDbELDTvyvukfkGYhybYaioS3lZv3XgzjBHEQ2
vsfCdku+EnVqFCPRoeLMHb50lrg9Mmc9ABUQQxuo0IGGiuIovQKDmU+5YYsC2KYj
XIxlNBaBjfyappCtUSKxdUsu628uNUiNtRGFIazIMSFlYeq6oR9nhvp42V+2/iAv
RvQiLO/+cF63MTVhTO61WNg046hKbkJq/17miiPlccWSJF+TPE3z5zW13ffopZ0N
LdN4oJ56n1PcAP8itlyieJzh3Z6eHW5QqLYfyGm75QHNJt1O3UyzbZ8ntAONDMNe
Nvxv6m3vzmJA+ol9OgIKNi7HYo6PVJgmVDKsRgob75o0Lz+6uDDO2CNKB7UAhpqQ
B2pGg79WHTuIanpmhzhYrSnfEQZ9JL3BBuOhpOYJfPLhysXSmTtekJD5xDNVEJ2g
QBzXJxH8VJyKTNLTmncQ/Gx2mO6+mcJqRhZr11+Yy+0DckUCP+EuS6FJEdTdqZoz
4tdxGsHNHb8TDwDPRald0WT/AGwzqPAcGQMk0Q7cKws+FSn2CNQ=
=XTTz
-END PGP SIGNATURE End Message ---


Bug#995875: Stable also affected

2021-10-14 Thread Antonio Terceiro
On Thu, Oct 14, 2021 at 11:06:52AM +0200, Diederik de Haas wrote:
> On 7 Oct 2021 18:35:18 +0200 Francesco Poli  wrote:
> > This seems to be exactly the same issue that was reported in #995448,
> > which is marked as affecting package apt-listbugs.
> > 
> > However, I see that you are using oldstable: I don't know whether a
> > fixed version of ruby-httpclient will ever be backported to oldstable.
> > Maybe it can enter oldstable as a security update... I am not sure
> > whether it will be considered as a security issue worth a DSA, though...
> 
> I just started to write to #995448 to mention that Stable is also affected. 
> Maybe that changes the equation?
> The version of ruby-httpclient is the same for Stable and Oldstable btw.

I have stable and oldstable updates lined up (#996026 and #996024).


signature.asc
Description: PGP signature


Bug#995021: closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)

2021-10-14 Thread Jerome BENOIT

Hi, it appears that I cannot reproduce the issue on the armhf porterbox 
amdahl.debian.org .
Cheers Jerome



OpenPGP_signature
Description: OpenPGP digital signature


Bug#790576: marked as done (ghextris: depends on python-gnome2 which is deprecated)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 11:00:10 +
with message-id 
and subject line Bug#790576: fixed in ghextris 0.9.0-4
has caused the Debian Bug report #790576,
regarding ghextris: depends on python-gnome2 which is deprecated
to be marked as done.

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

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


-- 
790576: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790576
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ghextris
Severity: important
Tags: sid stretch
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gnome2 gnome-python

Hi,

ghextris depends on python-gnome2, which is long deprecated and going
to be removed from the archive. ghextris should be ported away from
it.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Stretch release as we're going to
try to remove python-gnome2 this cycle.

If you have any question don't hesitate to ask.

Emilio

[1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/action/show/Projects/PyGObject 
--- End Message ---
--- Begin Message ---
Source: ghextris
Source-Version: 0.9.0-4
Done: Peter Michael Green 

We believe that the bug you reported is fixed in the latest version of
ghextris, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 790...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Peter Michael Green  (supplier of updated ghextris package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 15 Jun 2021 18:51:54 +
Source: ghextris
Binary: ghextris
Architecture: source all
Version: 0.9.0-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team 
Changed-By: Peter Michael Green 
Description:
 ghextris   - Tetris-like game on a hexagonal grid
Closes: 790576 989894
Changes:
 ghextris (0.9.0-4) unstable; urgency=medium
 .
   * Reintroduce package, keep games team as maintainer, set myself
 as uploader. (Closes: 989894)
   * Port from obsolete python2/gtk2/gnome2 to python3/python3-gi/gtk3/glade
 (Closes: 790576)
   * Update standards version to 4.5.1
 + Remove Debian menu stuff (the package has a desktop file).
   * Change vcs fields in debian/control to point to salsa
   * Bump debhelper compat and debhelper dependency to 12.
   * Remove "A" from start of short description
Checksums-Sha1:
 34b29344a917e71260c04f4a71c51cb50d0568c8 1943 ghextris_0.9.0-4.dsc
 1033b927ed8940aeeb5f249844b118de1c1ecccd 11004 ghextris_0.9.0-4.debian.tar.xz
 2be1f2dcc0e0736a9949f0f2a2ccfd6e4d87f1bd 12720 ghextris_0.9.0-4_all.deb
 f33d6efcf9239060978f857957cf99ed6ed1ecf2 5997 ghextris_0.9.0-4_amd64.buildinfo
Checksums-Sha256:
 3565829293febe2159b5f3f63596c7f41736592bdb7f39f72b1f1b4221277354 1943 
ghextris_0.9.0-4.dsc
 5e079997314874cb9fac2676dac0a1a14b6a35f03679216e34daa5b5ec6ea48b 11004 
ghextris_0.9.0-4.debian.tar.xz
 5edaf400286ff58b25670fc7a53b125bc3e9d0d86cc5d1be65602ee5ee15203b 12720 
ghextris_0.9.0-4_all.deb
 8dd5228663622060797f1b5ddbc0c94a661f97069aec0084c51cdaf1730c34b4 5997 
ghextris_0.9.0-4_amd64.buildinfo
Files:
 8e0b2273d55f80a14294d7386a1d6389 1943 games optional ghextris_0.9.0-4.dsc
 2dc2fc1a2e4ef6eea81603b2e22f9411 11004 games optional 
ghextris_0.9.0-4.debian.tar.xz
 f1c311cfd75cf736745bc14422c0de33 12720 games optional ghextris_0.9.0-4_all.deb
 71897110ee612a70e7eebc44781d15a9 5997 games optional 
ghextris_0.9.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEEU0DQATYMplbjSX63DEjqKnqP/XsFAmDI+lUUHHBsdWd3YXNo
QGRlYmlhbi5vcmcACgkQDEjqKnqP/XuSmQ/9HRHamja4RuafMO96wNByWhV64MfZ
Cihh7EvdJV8NvEWZDZ6B0awv5JCLaCwG9FMNzrrze1hf/wkhbEn3mUorRJH0Rtp6
DFErgBPlNLVu2f541p+mKhUZP8gWeCC12pxgWk1n4uAbA13WEPx6uzKWxOyK6xpa
KMLRK9oC8wybKujoVidM4zn0KDdTI4DLyv9QSh9BHFZVZWlrIPva3n/v6IdPqSPD
dPWFi2inkwG77Vg5t2y5g9OScm3vMsoEjxGFAecp7y9LgxGk7HLhxOnTbCdIfoXp
GpEfnTf94Jmk6TXYzc+TvkzaPz8brAuA6zod4zgirXH2l3I1qfLdRMcvcr1FngHT
DwLZeFs4jn1USz5/SA+ZPXXj16RrOlL6Bx8iWVPYd1tGvl+05KEoK0xGIaUKgTTI
a12r1qgZHXm2m1nA+NzSwvXwLbUChgE6PkPJ8SIlBiTkzoLrGO4Vj1PWIX0/f+FN

Processed: Re: Bug#995021 closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> reopen -1
Bug #995021 {Done: Jerome Benoit } [src:osmnx] osmnx: 
autopkgtest regression on armhf: iteration over a 0-d array
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions osmnx/1.1.1+ds-3.

-- 
995021: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995021
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#995021: closed by Debian FTP Masters (reply to Jerome Benoit ) (Bug#995021: fixed in osmnx 1.1.1+ds-3)

2021-10-14 Thread Paul Gevers
Control: reopen -1

Hi,

On 11-10-2021 17:09, Debian Bug Tracking System wrote:
>  osmnx (1.1.1+ds-3) unstable; urgency=medium
>  .
>* Debianization:

[...]

>  - d/tests/control:
>- online tests:
>  - Restrictions field, add needs-internet (Closes: #995021).

This doesn't fix the issue, as the workers on ci.d.n have unrestricted
internet access, so this restriction doesn't change anything and limited
internet access can't be the cause of the issue.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#996462: libc++-13-dev: uninstallable on s390x

2021-10-14 Thread Sylvestre Ledru

Le 14/10/2021 à 12:17, Sebastian Ramacher a écrit :

Package: libc++-13-dev
Version: 1:13.0.0-3
Severity: serious

Fixing #998510 causes installability issues on s390x:

$ apt-get install libc++-13-dev
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:
  libc++-13-dev : Depends: libunwind-13-dev but it is not installable
E: Unable to correct problems, you have held broken packages.



Oh, right...
libunwind doesn't exist on s390x ...


I have a fix for that
S



Bug#984260: Fixed upstream

2021-10-14 Thread Jeremy Sowden
Upstream has removed all the dynamic exception specfications.  I've
created a merge-request to add the upstream patch to the Debian Salsa
repo.

J.


signature.asc
Description: PGP signature


Bug#996462: libc++-13-dev: uninstallable on s390x

2021-10-14 Thread Sebastian Ramacher
Package: libc++-13-dev
Version: 1:13.0.0-3
Severity: serious

Fixing #998510 causes installability issues on s390x:

$ apt-get install libc++-13-dev
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:
 libc++-13-dev : Depends: libunwind-13-dev but it is not installable
E: Unable to correct problems, you have held broken packages.


Cheers
-- 
Sebastian Ramacher



Bug#994822: marked as done (pat: /usr/bin/pat is already shipped by the (unrelated) dist package)

2021-10-14 Thread Debian Bug Tracking System
Your message dated Thu, 14 Oct 2021 09:48:43 +
with message-id 
and subject line Bug#994822: fixed in pat 0.10.0-2
has caused the Debian Bug report #994822,
regarding pat: /usr/bin/pat is already shipped by the (unrelated) dist package
to be marked as done.

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

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


-- 
994822: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994822
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: pat
Version: 0.10.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../pat_0.10.0-1_amd64.deb ...
  Unpacking pat (0.10.0-1) ...
  dpkg: error processing archive /var/cache/apt/archives/pat_0.10.0-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/pat', which is also in package dist 1:3.5-236-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/pat_0.10.0-1_amd64.deb

dist has been in the archive for ages, so pat will probably have to rename its
executable (and the corresponding manpage).
(Breaks+Replaces are *NOT* appropriate in this case.)


cheers,

Andreas


dist=1:3.5-236-1_pat=0.10.0-1.log.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: pat
Source-Version: 0.10.0-2
Done: Federico Grau 

We believe that the bug you reported is fixed in the latest version of
pat, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 994...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Federico Grau  (supplier of updated pat package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 Oct 2021 22:14:42 -0400
Source: pat
Architecture: source
Version: 0.10.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Hamradio Maintainers 
Changed-By: Federico Grau 
Closes: 994822
Changes:
 pat (0.10.0-2) unstable; urgency=medium
 .
   * Rename binary and man page; d/rules README.Debian edits (Closes: #994822)
 and 04-update_man_pages_for_renamed_binary_994822.patch
   * Update d/control Standards to 4.6.0
Checksums-Sha1:
 8fa7f1a2fb2b77dc90765b66ccd69aaa0bde7ebc 2626 pat_0.10.0-2.dsc
 07ee507eb739a087c3dc7578c2c2be6b44577d26 116672 pat_0.10.0-2.debian.tar.xz
Checksums-Sha256:
 6d3f8c80ea5b0901b724d6449625c1ffd42dee2ca14cdbd37741c3730de2b2e1 2626 
pat_0.10.0-2.dsc
 d0feb869dd99691ff47d1cf38bed58fdd4e6a0ac2dc32948493effaafa46e2b0 116672 
pat_0.10.0-2.debian.tar.xz
Files:
 e3a875d8f586e14104872a16dd9e06be 2626 hamradio optional pat_0.10.0-2.dsc
 2cbe89c43daa83cdff4529cd84d131f2 116672 hamradio optional 
pat_0.10.0-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAmFn+2kACgkQTFprqxLS
p66WChAAiKZD4NWarMiJhur490cJOVM9baj16TTFe+ytb9JkGgs+hFY9Ws7vp5ZV
YuMjSsXn41wLEygjZMNGRjdg/WA+AGMXriXNiurZk1qpH/UOC2JZt/QiQ1MISBhs
HC4LV8lWj8oZf/Tr1k+JHl9qLhJowORSFuBGjHkdivs8/1lY7+L21AQH2PsbzCmO
0Pw5zNqPyNACLcKT7pfGpL9K5QwPVxQcdm5Yr08n0EyBu6iTQbB+2MZ8iJXg6y5r
1ONff+JthTYhDYR/2U/GffCBsc2mziAwczAu/OPqhHPD9V4Nvn5N522KvTU8PyhA
YZZdoNFkPr9XfiCOOj1B+xWT0P4pxGJ6HfGhZwfWVLoHhKbNFIP+jdr2WVH6cyFH
KqrQ6vvOFCElxeiL0c/ezYASr654mvdGNZF/u7Krce3fy+sRPP1AnCSAtI8c3HPe
jrFdeSuKIaxpWvr0G3xV6+Sdi2QjOF0cZRR+1skMjYGleCS9J2a1dT5LifIkemmO
5NzLbtiFjTGRGGgG4j6lXs5/kmSmyWHdrJ0t1Xv4YnqGSgbX2kHxkwRgUUdsX/wI
k/+UILgP8ap9ZN4p7qengt5vyqQ9As8YJF52hBqTNvM+hxvUPUF4+SxBz77sGseG
c3/GJl1OxhfR1auA7n/KItTWqCgSkQa0fo287gycT8byCLitH9o=
=PFBz
-END PGP SIGNATURE End Message ---


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

2021-10-14 Thread Ondrej Zary
Tested upstream mariadb packages. 10.3.30 works, 10.3.31 fails.

-- 
Ondrej Zary



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

2021-10-14 Thread Ondrej Zary
On Thursday 14 October 2021, Yves-Alexis Perez wrote:
> On Thu, 2021-10-14 at 00:03 -0700, Otto Kekäläinen wrote:
> > Right. Here is for Buster:
> >
> > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/8ccf2240960cbb609cedfeb269df22d43ccbba21
> > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/pipelines/302376
> 
> Unfortunately, with:
> 
> ii  libmariadb3:amd64  1:10.3.31-0+deb10u1+salsaci   
> amd64MariaDB database client library
> ii  mariadb-client 1:10.3.31-0+deb10u1+salsaci   all  
> MariaDB database client (metapackage depending on the latest version)
> ii  mariadb-client-10.31:10.3.31-0+deb10u1+salsaci   
> amd64MariaDB database client binaries
> ii  mariadb-client-core-10.3   1:10.3.31-0+deb10u1+salsaci   
> amd64MariaDB database core client binaries
> ii  mariadb-common 1:10.3.31-0+deb10u1+salsaci   all  
> MariaDB common metapackage
> ii  mariadb-server 1:10.3.31-0+deb10u1+salsaci   all  
> MariaDB database server (metapackage depending on the latest version)
> ii  mariadb-server-10.31:10.3.31-0+deb10u1+salsaci   
> amd64MariaDB database server binaries
> ii  mariadb-server-core-10.3   1:10.3.31-0+deb10u1+salsaci   
> amd64MariaDB database core server files
> 
> 
> I still get:
> 
> 2021-10-14  9:38:48 0 [Note] InnoDB: Using Linux native AIO
> 2021-10-14  9:38:48 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic 
> builtins
> 2021-10-14  9:38:48 0 [Note] InnoDB: Uses event mutexes
> 2021-10-14  9:38:48 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
> 2021-10-14  9:38:48 0 [Note] InnoDB: Number of pools: 1
> 2021-10-14  9:38:48 0 [Note] InnoDB: Using SSE2 crc32 instructions
> 2021-10-14  9:38:48 0 [Note] InnoDB: Initializing buffer pool, total size = 
> 128M, instances = 1, chunk size = 128M
> 2021-10-14  9:38:48 0 [Note] InnoDB: Completed initialization of buffer pool
> 2021-10-14  9:38:48 0 [Note] InnoDB: If the mysqld execution user is 
> authorized, page cleaner thread priority can be changed. See the man page of 
> setpriority().
> 2021-10-14  9:38:48 0 [ERROR] InnoDB: corrupted TRX_NO 10002001a6990af
> 2021-10-14  9:38:48 0 [Note] InnoDB: Retry with innodb_force_recovery=5
> 2021-10-14  9:38:48 0 [ERROR] InnoDB: Plugin initialization aborted with 
> error Data structure corruption
> 2021-10-14  9:38:49 0 [Note] InnoDB: Starting shutdown...
> 2021-10-14  9:38:49 0 [ERROR] Plugin 'InnoDB' init function returned error.
> 2021-10-14  9:38:49 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE 
> ENGINE failed.
> 2021-10-14  9:38:49 0 [Note] Plugin 'FEEDBACK' is disabled.
> 2021-10-14  9:38:49 0 [ERROR] Unknown/unsupported storage engine: InnoDB
> 2021-10-14  9:38:49 0 [ERROR] Aborting
> 
> So maybe I do have a corrupted database or something but I'm unsure what to do
> next (I don't think I have an older backups of the database). Also it still
> works just fine with 10.3.25.

I still get the error too. That patch was meant to fix a problem specific to 
BSD.

-- 
Ondrej Zary



Bug#995875: Stable also affected

2021-10-14 Thread Diederik de Haas
On 7 Oct 2021 18:35:18 +0200 Francesco Poli  wrote:
> This seems to be exactly the same issue that was reported in #995448,
> which is marked as affecting package apt-listbugs.
> 
> However, I see that you are using oldstable: I don't know whether a
> fixed version of ruby-httpclient will ever be backported to oldstable.
> Maybe it can enter oldstable as a security update... I am not sure
> whether it will be considered as a security issue worth a DSA, though...

I just started to write to #995448 to mention that Stable is also affected. 
Maybe that changes the equation?
The version of ruby-httpclient is the same for Stable and Oldstable btw.

Cheers,
  Diederik

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


Bug#996336: pygalmesh: autopkgtest regression on i386

2021-10-14 Thread Nico Schlömer
Yeah, that's a little weird. And it only occurs on i386? Sounds like a
CGAL bug then.

On Wed, Oct 13, 2021 at 3:24 PM Drew Parsons  wrote:
>
> On 2021-10-13 13:42, Nico Schlömer wrote:
> > Or PR upstream. I can merge and release any time.
>
> Thanks Nico. I'll check which tolerances it needs and file a PR.
>
> The error in test_rectangle might need your attention,
> "At index 0 diff: 279 != 276". I guess it's not just tolerances.
>
> Drew



Bug#996452: src:healpix-cxx: fails to migrate to testing for too long: soname bump (fixed in experimental)

2021-10-14 Thread Paul Gevers
Source: healpix-cxx
Version: 3.60.0-2
Severity: serious
Control: close -1 3.80.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing
and unstable for more than 60 days as having a Release Critical bug in
testing [1]. Your package src:healpix-cxx has been trying to migrate for
61 days [2]. Hence, I am filing this bug. If I followed correctly, the
package in experimental should just be uploaded to unstable, no?

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

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

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

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature


Processed: src:healpix-cxx: fails to migrate to testing for too long: soname bump (fixed in experimental)

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> close -1 3.80.0-1
Bug #996452 [src:healpix-cxx] src:healpix-cxx: fails to migrate to testing for 
too long: soname bump (fixed in experimental)
Marked as fixed in versions healpix-cxx/3.80.0-1.
Bug #996452 [src:healpix-cxx] src:healpix-cxx: fails to migrate to testing for 
too long: soname bump (fixed in experimental)
Marked Bug as done

-- 
996452: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996452
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Processed: src:gsl: fails to migrate to testing for too long: unresolved RC bug (found by autopkgtest breakage)

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> close -1 2.7+dfsg-2
Bug #996451 [src:gsl] src:gsl: fails to migrate to testing for too long: 
unresolved RC bug (found by autopkgtest breakage)
Marked as fixed in versions gsl/2.7+dfsg-2.
Bug #996451 [src:gsl] src:gsl: fails to migrate to testing for too long: 
unresolved RC bug (found by autopkgtest breakage)
Marked Bug as done

-- 
996451: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996451
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#996451: src:gsl: fails to migrate to testing for too long: unresolved RC bug (found by autopkgtest breakage)

2021-10-14 Thread Paul Gevers
Source: gsl
Version: 2.6+dfsg-2
Severity: serious
Control: close -1 2.7+dfsg-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature


Processed: src:scipy: fails to migrate to testing for too long: build depends on blocked package and unresolved RC bug

2021-10-14 Thread Debian Bug Tracking System
Processing control commands:

> close -1 1.7.1-1
Bug #996450 [src:scipy] src:scipy: fails to migrate to testing for too long: 
build depends on blocked package and unresolved RC bug
Marked as fixed in versions scipy/1.7.1-1.
Bug #996450 [src:scipy] src:scipy: fails to migrate to testing for too long: 
build depends on blocked package and unresolved RC bug
Marked Bug as done
> block -1 by 992676 950598
Bug #996450 {Done: Paul Gevers } [src:scipy] src:scipy: 
fails to migrate to testing for too long: build depends on blocked package and 
unresolved RC bug
996450 was not blocked by any bugs.
996450 was not blocking any bugs.
Added blocking bug(s) of 996450: 992676 and 950598

-- 
996450: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996450
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#996450: src:scipy: fails to migrate to testing for too long: build depends on blocked package and unresolved RC bug

2021-10-14 Thread Paul Gevers
Source: scipy
Version: 1.6.0-2
Severity: serious
Control: close -1 1.7.1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 992676 950598

Dear maintainer(s),

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

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

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

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

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

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




OpenPGP_signature
Description: OpenPGP digital signature


  1   2   >