Bug#1069391: marked as pending in nmap

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1069391 in nmap 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/pkg-security-team/nmap/-/commit/06ff1ac3296fd639ae1e9840b2c78b48dfd45196


debian/rules: filter out build flag not supported by i686-w64-mingw32-gcc

We are using the native build flags against the Windows cross compiler,
there is no guarantee that that compiler will support the same flags as
the native, official Debian gcc. Ideally That should be changed to a
hardcoded known-good list of options support by i686-w64-mingw32-gcc.

Closes: #1069391


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069391

Bug#1068290: python3-fastkml: ImportError since python3-pygeoif 1.4.0

[Antonio Valentino]

Dear Thomas and Andreas,

On Wed, 3 Apr 2024 01:22:14 +0100 Tomas Janousek  wrote:

Hi,

On Wed, Apr 03, 2024 at 12:29:36AM +0100, Tomas Janousek wrote:
>I believe this is because both shapely and pygeoif deprecated
>asShape/as_shape respectively. The function is now called just "shape"
>in both.
>[…]
>I think it might be okay to just patch fastkml/geometry.py to
>
>from shapely.geometry import shape as asShape
>…
>from pygeoif.geometry import shape as asShape
>
>but it needs to be tested more thoroughly.

Yep, almost that. The following seems to work well (makes my CI pass):
https://github.com/liskin/liscopridge/commit/c44c3e6054af5a12bdf24d5687b6478d39480194#diff-e8ae9ced1dd6c13b4566c8a4a669116272e05115ce64aa743658523f4455ad5fR11

--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/


Apparently the fix was a little bit more complex that expected.
I think that I have managed to adapt the current version of the 
python3-fastkml package to the new pygeoif.


A MR is available in salsa [1].

I would appreciate if you could review, apply the patch and proceed with 
a new upload.


This would allow to "doris" one of my packages to migrate back in testing.


P.S:: @Andreas, I'm a DM and I would be happy to be listed as uploader 
of this package if it is OK for you.



[1] https://salsa.debian.org/python-team/packages/fastkml/-/merge_requests/1



kind regards
--
Antonio Valentino

Bug#1071201: systemd 256~rc2-1

[Antonio Russo]

I can confirm this version of systemd breaks my system's boot as well. I don't 
have any
modified journald.conf settings.

I'm running dracut, and the image that is built fails to start 
systemd-modules-load.service

Running systemd-modules-load (rd.shell=1 rd.break=cmdline) at the (dracut) 
shell gave

Failed to initialize libkmod context: Operation not supported

I (too) was able to roll back to systemd 255.5-1 (dpkg -i 
/var/cache/apt/archives/*255.5-1*deb)
fully restoring the system.

Best,
Antonio

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071125: python3-donfig and python3-nabu have an undeclared file conflict on /usr/lib/python3/dist-packages/doc/conf.py

[Antonio Valentino]

On Tue, 14 May 2024 22:23:45 +0200 Sebastiaan Couwenberg 
 wrote:

On 5/14/24 8:27 PM, Helmut Grohne wrote:
> The file /usr/lib/python3/dist-packages/doc/conf.py is contained in the
> packages
>   * python3-donfig/0.8.1+dfsg-2 as present in trixie|unstable
>   * python3-nabu/2024.1.6-1 as present in unstable

Neither of these packages should be including this file.

Kind Regards,

Bas

--
  GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



ah, sorry.
Should I reopen?

--
Antonio Valentino

Bug#1070919: compyle: FTBFS in bullseye

[Antonio Valentino]

Dear Santiago,


Il 14/05/24 22:55, Santiago Vila ha scritto:

El 14/5/24 a las 7:15, Antonio Valentino escribió:
On Sat, 11 May 2024 21:46:59 +0200 Santiago Vila  
wrote:

E   error: unknown target CPU 'generic'


I'm sorry but I have no clue about this issue.
Looking at the log It seems that the CPU is not recognized.


Yes, that's what it seems.


Not sure, however if the issue is in compyle or in pyopencl.

Do you have an idea if the updated versions of the package (e.g. the 
ones currently in stable or in unstable) build properly on the same 
platform?


I tried building compyle_0.8.1-4 (bookworm version)
in a bullseye chroot, and it failed with a similar error.

On the other hand, both packages (compyle and pyopencl) build fine
in bookworm (that's why the bugs are marked as closed in the bookworm 
version)

in the same platform.

So yes, this seems to be a problem in pyopencl.

Because this is oldstable and packages are not expected to change,
I think that whoever wants to build this from source will be able
to use nocheck. Therefore, I think it would be ok to forget
about this one.

If you are curious, I'm filing these bugs because the last point
release of bullseye will be the last one, so this is the last
opportunity to have a distribution which builds from source.

Release Policy does not apply anymore, so it is up to the
individual maintainers to decide if they want to fix the bugs
or not.

Thanks.


Thanks for dedicating time on this.
Unfortunately I do not have better ideas so I think that we could leave 
things as they are now for the time being.


kind regards
--
Antonio Valentino

Bug#1070919: compyle: FTBFS in bullseye

[Antonio Valentino]

Dear Santiago,

On Sat, 11 May 2024 21:46:59 +0200 Santiago Vila  wrote:

Package: src:compyle
Version: 0.7-2
Severity: serious
Control: close -1 0.8.1-4
Tags: ftbfs bullseye

Dear maintainer:

During a rebuild of all packages in bullseye, your package failed to build:


[...]
  debian/rules binary
dh binary --with python3 --buildsystem=pybuild
dh_update_autotools_config -O--buildsystem=pybuild
dh_autoreconf -O--buildsystem=pybuild
dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py config
running config
dh_auto_build -O--buildsystem=pybuild
I: pybuild base:232: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.9_compyle/build/compyle
copying compyle/ast_utils.py -> 
/<>/.pybuild/cpython3_3.9_compyle/build/compyle

[... snipped ...]

E   pyopencl._cl.RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE 
- clBuildProgram failed: BUILD_PROGRAM_FAILURE - clBuildProgram failed: 
BUILD_PROGRAM_FAILURE
E
E   Build on :
E
E   error: unknown target CPU 'generic'
E
E   (options: -I /usr/lib/python3/dist-packages/pyopencl/cl)
E   (source saved as /tmp/tmp_oyjksbc.cl)

/usr/lib/python3/dist-packages/pyopencl/__init__.py:579: RuntimeError
 TestParallelUtilsJIT.test_scan_works_with_external_func_opencl 

func = 
args = (,)
kwargs = {'ary': }
key = ('gintp', .input_f 
at 0x7f95841ecb80>, .output_f at 0x7f957f8b1dc0>, 
'a+b', 'opencl', False, ...)

 @my_decorator
 def _deco(func, *args, **kwargs):
 # by Michele Simionato
 # http://www.phyast.pitt.edu/~micheles/python/
 key = key_func(*args, **kwargs)
 try:
>   return func._memoize_dic[key]  # pylint: disable=protected-access
E   KeyError: ('gintp', .input_f at 0x7f95841ecb80>, 
.output_f at 
0x7f957f8b1dc0>, 'a+b', 'opencl', False, True)

/usr/lib/python3/dist-packages/pytools/__init__.py:621: KeyError

During handling of the above exception, another exception occurred:

self = 




I'm sorry but I have no clue about this issue.
Looking at the log It seems that the CPU is not recognized.
Not sure, however if the issue is in compyle or in pyopencl.

Do you have an idea if the updated versions of the package (e.g. the 
ones currently in stable or in unstable) build properly on the same 
platform?



kind regards
--
Antonio Valentino

Bug#1071034: unversioned libuv1 Provides: is inadequate

[Antonio Russo]

Source: libuv1
Version: 1.48.0-3
Severity: serious
X-Debbugs-Cc: aeru...@aerusso.net

Dear Maintainer,

libuv1 version 1.48.0-3 has an unversioned Provides: libuv1 line, but packages 
(such as cmake) have
versioned dependencies on libuv1.  This is breaking cmake in unstable right now.

It appears that dpkg-dev version 1.22.5 (or later) allows you to use

Provides: ${t64:Provides}

to automatically generate the versioned Provides: line.


Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068422: possibly caused by python 3.12.3 Re: Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object

[Antonio Valentino]

On Sun, 21 Apr 2024 13:07:41 +0100 "Rebecca N. Palmer" 
 wrote:
This bug is not *obviously* known to dask upstream, but their CI is 
failing and I haven't checked why.


It happens only in Python 3.12, not 3.11:
https://ci.debian.net/packages/d/dask/unstable/amd64/45013666/
and still doesn't happen in testing, but does happen in mostly-testing 
with 
src:python3-defaults,src:db5.3,src:keras,src:nodejs,src:openssl,src:python3-stdlib-extensions,src:python3.11,src:python3.12,src:readline,src:udisks2,src:viagee 
from unstable:

https://ci.debian.net/packages/d/dask/testing/amd64/45564690/

This suggests that the trigger may be the upgrade of Python itself 
(3.12.2-1 in testing -> 3.12.3-1 in unstable).


*Possibly* related items from the upstream Python changelog:
https://github.com/python/cpython/issues/101293
https://github.com/python/cpython/issues/117110


Apparently this issue seems to be related to:
https://github.com/dask/dask/pull/11035

regards
--
Antonio Valentino

Bug#1069348: closing 1069348

[Antonio Terceiro]

close 1069348 0.16.0-2
thanks

Bug#1068537: marked as pending in ruby-ethon

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1068537 in ruby-ethon reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-ethon/-/commit/c66b1a1db60d982a2648f44977ed104a42d93293


Don't hardcode a dependency on libcurl4

Closes: #1068537


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1068537

Bug#1066854: marked as pending in ruby-magic

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1066854 in ruby-magic reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-magic/-/commit/3a95d42fa6ea9355487927f2c663a73bbad603ea


Use libmagic-dev in Build-Depends/Depends instead of libmagic1

Closes: #1066854


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1066854

Bug#1068589: marked as pending in gem2deb

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1068589 in gem2deb reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/gem2deb/-/commit/31ab3f4026d0365e9300a521d2a75931626d209b


dh_ruby_fixdepends: workaround presence of libruby3.1t64

Closes: #1068589


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1068589

Bug#1067229: metpy: autopkgtest regression with NumPy 1.26

[Antonio Valentino]

Dear Timo,

On Wed, 20 Mar 2024 16:58:12 +0100 =?utf-8?q?Timo_R=C3=B6hling?= 
 wrote:

Source: metpy
Version: 1.6.1+ds-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package has an autopkgtest regression with NumPy 1.26.
Hopefully relevant excerpt from the test log:


  142s >   if np.any(np.max(pressure, axis=vertical_dim) < 950 
  * units.hectopascal):

  142s E   TypeError: no implementation found for 'numpy.max' on types that implement 
__array_function__: [.Quantity'>]
  142s
  142s /usr/lib/python3/dist-packages/metpy/calc/thermo.py:4589: TypeError
  142s === short test summary info 

  142s FAILED tests/calc/test_calc_tools.py::test_get_layer_heights_agl - 
TypeError:...
  142s FAILED 
tests/calc/test_calc_tools.py::test_get_layer_heights_agl_bottom_no_interp
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction - 
TypeError: no...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_edge - 
TypeErro...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_list - 
TypeErro...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_arr - 
TypeError...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_full - 
TypeErro...
  142s FAILED 
tests/calc/test_calc_tools.py::test_angle_to_direction_invalid_scalar
  142s FAILED 
tests/calc/test_calc_tools.py::test_angle_to_direction_invalid_arr - T...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_level_3 - 
TypeE...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_level_2 - 
TypeE...
  142s FAILED tests/calc/test_calc_tools.py::test_angle_to_direction_level_1 - 
TypeE...
  142s FAILED 
tests/calc/test_kinematics.py::test_storm_relative_helicity_no_storm_motion
  142s FAILED 
tests/calc/test_kinematics.py::test_storm_relative_helicity_storm_motion
  142s FAILED 
tests/calc/test_kinematics.py::test_storm_relative_helicity_with_interpolation
  142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity - 
TypeErro...
  142s FAILED tests/calc/test_kinematics.py::test_storm_relative_helicity_agl - 
Type...
  142s FAILED 
tests/calc/test_kinematics.py::test_storm_relative_helicity_masked - T...
  142s FAILED tests/calc/test_thermo.py::test_lfc_ml2 - TypeError: no 
implementation...
  142s FAILED tests/calc/test_thermo.py::test_lfc_and_el_below_lcl - TypeError: 
no i...
  142s FAILED tests/calc/test_thermo.py::test_gdi - TypeError: no 
implementation fou...
  142s FAILED tests/calc/test_thermo.py::test_gdi_xarray - TypeError: no 
implementat...
  142s FAILED tests/calc/test_thermo.py::test_gdi_arrays - TypeError: no 
implementat...
  142s FAILED tests/calc/test_thermo.py::test_gdi_profile - TypeError: no 
implementa...
  142s FAILED tests/calc/test_thermo.py::test_gdi_no_950_raises_valueerror - 
TypeErr...
  142s = 25 failed, 937 passed, 25 skipped, 268 deselected in 21.69s 
==

[CUT]

According to what reported by upstream in 
https://github.com/Unidata/MetPy/issues/3453 the issue is linked to an 
outdated version of python3-pint.

An update to Pint v0.22 should fix the issue.
Reassign to point.


kind reagrds
--
Antonio Valentino

Bug#1067115: gross: diff for NMU version 1.0.2-4.1

[Antonio Radici]

On Sat, Mar 23, 2024 at 11:45:58PM +0200, Adrian Bunk wrote:
> Control: tags 1067115 + patch
> Control: tags 1067115 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for gross (versioned as 1.0.2-4.1) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
> 

Thanks for working on this, no reason to cancel it.

Sorry I couldn't get to this faster enough

Bug#1066789: pycoast: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Antonio Valentino]

Dear Lucas,
thanks for reporting.

On Wed, 13 Mar 2024 15:58:32 +0100 Lucas Nussbaum  wrote:

Source: pycoast
Version: 1.7.0+dfsg-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240313 ftbfs-trixie

Hi,

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


Relevant part (hopefully):


[CUT]


 ERRORS 
 ERROR collecting pycoast/tests/test_pycoast.py 
/usr/lib/python3/dist-packages/pluggy/_hooks.py:501: in __call__
return self._hookexec(self.name, self._hookimpls.copy(), kwargs, 
firstresult)
/usr/lib/python3/dist-packages/pluggy/_manager.py:119: in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
/usr/lib/python3/dist-packages/_pytest/python.py:278: in 
pytest_pycollect_makeitem
return list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:507: in _genfunctions
self.ihook.pytest_generate_tests.call_extra(methods, 
dict(metafunc=metafunc))
/usr/lib/python3/dist-packages/pluggy/_hooks.py:562: in call_extra
return self._hookexec(self.name, hookimpls, kwargs, firstresult)
/usr/lib/python3/dist-packages/pluggy/_manager.py:119: in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
/usr/lib/python3/dist-packages/pytest_lazyfixture.py:74: in 
pytest_generate_tests
normalize_metafunc_calls(metafunc, 'funcargs')
/usr/lib/python3/dist-packages/pytest_lazyfixture.py:81: in 
normalize_metafunc_calls
calls = normalize_call(callspec, metafunc, valtype, used_keys)
/usr/lib/python3/dist-packages/pytest_lazyfixture.py:105: in normalize_call
valtype_keys = set(getattr(callspec, valtype).keys()) - used_keys
E   AttributeError: 'CallSpec2' object has no attribute 'funcargs'
=== warnings summary ===
../../../../../../usr/lib/python3/dist-packages/_pytest/python.py:507
  /usr/lib/python3/dist-packages/_pytest/python.py:507: 
PluggyTeardownRaisedWarning: A plugin raised an exception during an old-style 
hookwrapper teardown.
  Plugin: lazy-fixture, Hook: pytest_generate_tests
  AttributeError: 'CallSpec2' object has no attribute 'funcargs'
  For more information see 
https://pluggy.readthedocs.io/en/stable/api_reference.html#pluggy.PluggyTeardownRaisedWarning
self.ihook.pytest_generate_tests.call_extra(methods, 
dict(metafunc=metafunc))

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=== short test summary info 
ERROR ../../../pycoast/tests/test_pycoast.py - AttributeError: 'CallSpec2' ob...
 Interrupted: 1 error during collection 
= 1 warning, 1 error in 0.26s ==


the issue seems to be related to the pytest-lazyfixture package.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063957.
I will reassign.


regards
--
Antonio Valentino

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

[Antonio Terceiro]

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

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


signature.asc
Description: PGP signature

Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

[Antonio Russo]

Dear maintainer,

This bug is (apparently?) currently preventing the amd64 build of 1.20.1-6.  I
apologize if this is already understood (by the way, is there somewhere on [1]
or elsewhere to see if the build is being retried?).  I'm also assuming I am not
authorized to "give back" and trigger another build attempt.

So, I'm asking for someone to please "give back" the build to the buildds, so 
that
we can spin the roulette wheel and hopefully get a buildd with an ipv4 address.

Best,
Antonio Russo

[1] https://tracker.debian.org/pkg/krb5

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065091: marked as pending in gtg

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1065091 in gtg 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/python-team/packages/gtg/-/commit/89f6c4814684b99f82fbf6be1b43c2da1667da5e


Revert patch switching from imp to importlib; use zombie-imp instead

Closes: #1065091


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065091

Bug#1065091: gtg: crashes on startup

[Antonio Terceiro]

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

Dear Maintainer,

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

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

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

Kernel: Linux 6.6.15-arm64 (SMP w/32 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gtg depends on:
ii  gir1.2-gtk-3.0 [gir1.2-gdk-3.0]  3.24.41-1
ii  gir1.2-gtksource-4   4.8.4-5+b1
ii  gir1.2-pango-1.0 1.51.0+ds-4
ii  gir1.2-secret-1  0.21.2-1
ii  pdftk-java   3.3.3-2
ii  python3  3.11.6-1
ii  python3-caldav   0.11.0-2
ii  python3-cheetah  3.3.3-1
ii  python3-gi   3.47.0-3
ii  python3-gi-cairo 3.47.0-3
ii  python3-liblarch 3.2.0-3
ii  python3-lxml 5.1.0-1
ii  texlive-extra-utils  2023.20240207-1
ii  texlive-latex-base   2023.20240207-1

gtg recommends no packages.

gtg suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1058111: marked as pending in cmdtest

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1058111 in cmdtest 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/python-team/packages/cmdtest/-/commit/dcf5b1bda3cb1ae41b23c23324f88023a993379f


Pull `imp` from python3-zombie-imp

Closes: #1058111


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1058111

Bug#1062033: c-blosc2: NMU diff for 64-bit time_t transition

[Antonio Valentino]

Hi Steve,
On Wed, 31 Jan 2024 03:16:51 + Steve Langasek  wrote:

Source: c-blosc2
Version: 2.13.1+ds-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
c-blosc2 as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for c-blosc2
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.


Just uploaded to experimental a new version of the package with a small 
update of the symbol file.


kind reards
--
Antonio Valentino

Bug#1058301: resampy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Antonio Valentino]

On Fri, 12 Jan 2024 08:07:41 +0100 s3v  wrote:

Dear Maintainer,

> E   If you are not working on Numba development, the original error was: 
'cannot import name '_typeconv' from 'numba.core.typeconv' 
(/usr/lib/python3/dist-packages/numba/core/typeconv/__init__.py)'.
> E   For help, please visit:
> E   
> E   https://numba.readthedocs.io/en/stable/user/faq.html#numba-could-not-be-imported


This is issue was fixed in numba/0.58.1+dfsg-1 [1] actually in unstable and I've
verified your package builds fine locally and autopkg tests pass as well.

Kind Regards

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058301


Thanks a lot


--
Antonio Valentino

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

[Antonio Terceiro]

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

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

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


signature.asc
Description: PGP signature

Bug#1058301: resampy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Antonio Valentino]

On Tue, 12 Dec 2023 09:24:48 +0100 Lucas Nussbaum  wrote:

Source: resampy
Version: 0.4.2+ds-3
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231212 ftbfs-trixie

Hi,

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


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_test
> I: pybuild base:310: cd /<>/.pybuild/cpython3_3.12_resampy/build; 
python3.12 -m pytest ""
> = test session starts 
==
> platform linux -- Python 3.12.1, pytest-7.4.3, pluggy-1.3.0
> rootdir: /<>
> configfile: setup.cfg
> plugins: cov-4.1.0
> collected 0 items / 3 errors
> 
>  ERRORS 

> ___ ERROR collecting .pybuild/cpython3_3.12_resampy/build/tests/test_core.py 
___
> ImportError while importing test module 
'/<>/.pybuild/cpython3_3.12_resampy/build/tests/test_core.py'.
> Hint: make sure your test modules/packages have valid Python names.
> Traceback:
> /usr/lib/python3/dist-packages/numba/core/typeconv/typeconv.py:4: in 
> from numba.core.typeconv import _typeconv
> E   ImportError: cannot import name '_typeconv' from 'numba.core.typeconv' 
(/usr/lib/python3/dist-packages/numba/core/typeconv/__init__.py)
> 
> During handling of the above exception, another exception occurred:

> /usr/lib/python3.12/importlib/__init__.py:90: in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> tests/test_core.py:8: in 
> import resampy
> resampy/__init__.py:7: in 
> from .core import *
> resampy/core.py:7: in 
> import numba
> /usr/lib/python3/dist-packages/numba/__init__.py:73: in 
> from numba.misc.special import (
> /usr/lib/python3/dist-packages/numba/misc/special.py:3: in 
> from numba.core.typing.typeof import typeof
> /usr/lib/python3/dist-packages/numba/core/typing/__init__.py:1: in 
> from .context import BaseContext, Context
> /usr/lib/python3/dist-packages/numba/core/typing/context.py:11: in 
> from numba.core.typeconv import Conversion, rules
> /usr/lib/python3/dist-packages/numba/core/typeconv/rules.py:2: in 
> from .typeconv import TypeManager, TypeCastingRules
> /usr/lib/python3/dist-packages/numba/core/typeconv/typeconv.py:16: in 
> raise ImportError(msg)
> E   ImportError: Numba could not be imported.
> E   

> E   If you are seeing this message and are undertaking Numba development 
work, you may need to rebuild Numba.
> E   Please see the development set up guide:
> E   


The issue seems to be related to the fact that the numba package still 
do not support python 12.


See also #1057461 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057461)



cheers
--
Antonio Valentino

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

[Antonio Terceiro]

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

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

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


signature.asc
Description: PGP signature

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

[Antonio Terceiro]

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

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

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

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

The correct dependency would be on `thin`.

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

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

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

Kernel: Linux 6.5.0-1-arm64 (SMP w/32 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ruby-blade depends on:
ii  ruby  1:3.1
ii  ruby-activesupport2:6.1.7.3+dfsg-2
ii  ruby-blade-qunit-adapter  2.0.1-2
ii  ruby-curses   1.4.4-1+b2
ii  ruby-eventmachine 1.3~pre20220315-df4ab006-3+b1
ii  ruby-faye 1.4.0-1
ii  ruby-sprockets3.7.2-4
pn  ruby-thin 
ii  ruby-thor 1.2.2-1
ii  ruby-useragent0.16.8-1.1
ii  thin  1.8.1-2

ruby-blade recommends no packages.

ruby-blade suggests no packages.


signature.asc
Description: PGP signature

Bug#1052817: sarsen: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Antonio Valentino]

This seems to be the same issue reported in #1050832.
The problem seems to be a regression in xarray v2023.08.
The update to xarray > 2023.08 should fix the issue.
See also https://github.com/bopen/sarsen/issues/54.

I will reassign to xarray.

[#1050832] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050832
--
Antonio Valentino

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

[Antonio Terceiro]

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

Dear Maintainer,

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

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

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

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

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

Versions of packages ohcount depends on:
ii  file   1:5.45-2
ii  libc6  2.37-7
ii  libmagic1  1:5.45-2
ii  libpcre3   2:8.39-15
ii  ruby   1:3.1
ii  ruby-diff-lcs  1.5.0-1

ohcount recommends no packages.

Versions of packages ohcount suggests:
pn  ohcount-doc  

-- no debconf information


signature.asc
Description: PGP signature

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 09:59:53PM +0200, Sebastian Andrzej Siewior wrote:
> Hi Antonio!
> 
> On 2023-09-10 15:57:58 [+0200], Antonio Radici wrote:
> > On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> > > Hi Antonio,
> > > 
> > > FWIW, I have done the bookworm-security upload already to
> > > security-master, and still working on the bullseye-security one (with
> > > plan to release the DSA tonight ideally).
> > 
> > Ack, thanks for the update, I assume this was a particularly serious issue 
> > that
> > had to be handled immediately!
> 
> I pinged Salvatore on IRC about this and he was working on
> stable/old-stable fix of the version at the time. So I suggest to help
> out and prepare latest upstream from upstream for unstable (which was in
> opinion only fixes).
> Unfortunately I saw your reply to the bug after performing the update.
> I'm sorry if I overstepped here. In the meantime I prepared a pull on
> salsa for the changes I made.
> As a matter of fact, I noticed that I somehow missed the latest
> changelog from the package which I noticed while I tried to open the
> pull request. After looking at it again, it looks like I just missed the
> changelog entry.
> 
> Once again, I'm sorry for any trouble I may have caused.

Hi Sebastian,
not a problem at all! It's just that I was unaware! You were much faster than
me and that's definitely very good. Thanks a lot for your contribution to
Debian, I really appreciate it :)

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:47:30PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Sun, Sep 10, 2023 at 01:24:10PM +0200, Antonio Radici wrote:
> > On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> > > Thanks for raising this, I'm uploading the new packages with the fixes 
> > > today.
> > 
> > apparently someone else did a NMU with the new version and incorrectly 
> > closed
> > the bug.
> 
> You mean the NMU by Sebastian?

Yes

> 
> > I reopened the bug because stable needs to be addressed (which I will do 
> > today
> > as I just wrote) and then it's probably worth investigating how to integrate
> > those NMU into the git repo
> 
> Actually you do not need to reopen. A bug can be closed with mutliple
> versions, that is 2.2.12-0.1 closes it, but as well so does then the
> 2.2.9-1+deb12u1 upload and the 2.0.5-4.1+deb11u3 one.
> 
> I think that was not the case several years ago, but nowdays BTS can
> handle that, and will reflect it nicely as well in the version graph.
> 
> Or were you meaning something different?

Ah ok good, then I will add the extra versions if they are not there already

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:38:33PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> FWIW, I have done the bookworm-security upload already to
> security-master, and still working on the bullseye-security one (with
> plan to release the DSA tonight ideally).

Ack, thanks for the update, I assume this was a particularly serious issue that
had to be handled immediately!

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sun, Sep 10, 2023 at 01:05:31PM +0200, Antonio Radici wrote:
> Thanks for raising this, I'm uploading the new packages with the fixes today.

apparently someone else did a NMU with the new version and incorrectly closed
the bug.

I reopened the bug because stable needs to be addressed (which I will do today
as I just wrote) and then it's probably worth investigating how to integrate
those NMU into the git repo

Bug#1051563: mutt: CVE-2023-4874 CVE-2023-4875

[Antonio Radici]

On Sat, Sep 09, 2023 at 10:23:32PM +0200, Salvatore Bonaccorso wrote:
> Source: mutt
> Version: 2.2.9-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerabilities were published for mutt.
> 
> CVE-2023-4874[0]:
> | Null pointer dereference when viewing a specially crafted email in
> | Mutt >1.5.2 <2.2.12
> 
> 
> CVE-2023-4875[1]:
> | Null pointer dereference when composing from a specially crafted
> | draft message in Mutt >1.5.2 <2.2.12
> 
> Make sure to include all three commits referenced from [2], the last
> one is technically not part of the two CVEs, but another crash found
> by upstream.
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2023-4874
> https://www.cve.org/CVERecord?id=CVE-2023-4874
> [1] https://security-tracker.debian.org/tracker/CVE-2023-4875
> https://www.cve.org/CVERecord?id=CVE-2023-4875
> [2] 
> http://lists.mutt.org/pipermail/mutt-announce/Week-of-Mon-20230904/56.html
> 
> Please adjust the affected versions in the BTS as needed.

Thanks for raising this, I'm uploading the new packages with the fixes today.

Bug#1050832: sarsen: autopkgtest needs update for python-xarray 2023.08.0

[Antonio Valentino]

Dear Graham,

On Wed, 30 Aug 2023 08:08:49 + Graham Inggs  wrote:

Control: severity -1 serious
Control: tags -1 + ftbfs

As can be seen on reproducible builds [1], this same error causes
sarsen to FTBFS in unstable.


[1] https://tests.reproducible-builds.org/debian/rb-pkg/sarsen.html


I think that this is a regression in xarray v2023.08.0.
I have tested sarsen with the latest development version of xarray from 
git main, and it works correctly.


Apparently the fix is in the PR #8094 
(https://github.com/pydata/xarray/pull/8094) merged tree days ago.


If it is OK for you I will re-assigning the issue to xarray.


kind regards
--
Antonio Valentino

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Antonio]

ticket:

https://techpatterns.com/forums/about3040.html

Bug#1050586: kmod: Updating to kmod to 30+20230601-1 results in a non booting system modules cannot be decompressed

[Antonio]

I don't build kernel from source, I use binary packages installed from 
liquorix repositories https://liquorix.net/.


I opened a ticket to their forum, maybe a recompilation of the kernel is 
enough.


We await your reply...


Il 27/08/23 03:10, Marco d'Itri ha scritto:

On Aug 26, Jon Westgate <0...@fsck.tv> wrote:


The error message it gave was "decompresson failed with status 6"

Status 6 is XZ_OPTIONS_ERROR, which means "Input was encoded with
settings that are not supported by this XZ decoder".
So it looks like you have compressed the modules (how?) with XZ settings
which are supported by the userspace loader but not by the kernel one.

Bug#1050582: kmod update corrupts systemd uefi boot

[Antonio]

Found this:

# CONFIG_MODULE_COMPRESS_NONE is not set
# CONFIG_MODULE_COMPRESS_GZIP is not set
CONFIG_MODULE_COMPRESS_XZ=y
# CONFIG_MODULE_COMPRESS_ZSTD is not set


Il 26/08/23 19:57, Marco d'Itri ha scritto:

On Aug 26, antonio  wrote:


Kernel: Linux 6.4.12-1-liquorix-amd64 (SMP w/24 CPU threads; PREEMPT)

I see that you are using a custom kernel. What is the status of the
CONFIG_MODULE_COMPRESS_* kernel configuration options?

Bug#1050462: gtg: crashes on startup often

[Antonio Terceiro]

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

Thanks, this indeed seem to work around the issue.

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

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


signature.asc
Description: PGP signature

Bug#1050462: gtg: crashes on startup often

[Antonio Terceiro]

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

Dear Maintainer,

gtg crashes on startup very often.

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

I can reproduce this issue:

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

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

Kernel: Linux 6.5.0-0-arm64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gtg depends on:
ii  gir1.2-gtk-3.0 [gir1.2-gdk-3.0]  3.24.38-2
ii  gir1.2-gtksource-4   4.8.4-4
ii  gir1.2-pango-1.0 1.51.0+ds-2
ii  gir1.2-secret-1  0.21.0-1
ii  pdftk-java   3.3.3-1
ii  python3  3.11.4-5+b1
ii  python3-caldav   0.11.0-1
ii  python3-cheetah  3.3.2-1
ii  python3-gi   3.44.1-2
ii  python3-gi-cairo 3.44.1-2
ii  python3-liblarch 3.2.0-3
ii  python3-lxml 4.9.3-1
ii  texlive-extra-utils  2022.20230122-4
ii  texlive-latex-base   2022.20230122-3

gtg recommends no packages.

gtg suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1049326: pandas FTBFS with numexpr 2.8.5

[Antonio Valentino]

Dear Rebecca,

Il 16/08/23 23:36, Rebecca N. Palmer ha scritto:
I pushed this fix to Salsa as the 'fix1049326' branch - it isn't enough to fix pandas by itself, but is plausibly an 
improvement.


Do you need a new upload with the proposed patch or should we wait for a 
complete solution of the problem?

cheers
--
Antonio Valentino

Bug#1000101: eterm: depends on obsolete pcre3 library

[Jose Antonio Jimenez Madrid]

Bastian Germann wrote:
> Hi,
>
> I am uploading a NMU to fix this. The debdiff is attached.
>
> Sincerely,
> Bastian


Thank you so much for fixing this. I am planing to review build
dependences to removed those no needed.

Sincerely,
Jose

Bug#1039015: About bug #1038014 and this one

[Antonio Miguel Ferreira Marques Trindade]

The patch included in bug #1038014 does not full resolve this issue.

I still got the following build error:

/var/lib/dkms/nvidia-legacy-390xx/390.157/build/nvidia-drm/nvidia-drm-fb.c: 
In function ‘nv_drm_internal_framebuffer_create’:
/var/lib/dkms/nvidia-legacy-390xx/390.157/build/nvidia-drm/nvidia-drm-fb.c:180:5: 
error: implicit declaration of function ‘drm_helper_mode_fill_fb_struct’ 
[-Werror=implicit-function-declaration]

  180 | drm_helper_mode_fill_fb_struct(
  | ^~
cc1: some warnings being treated as errors
make[3]: *** 
[/usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.build:257: 
/var/lib/dkms/nvidia-legacy-390xx/390.157/build/nvidia-drm/nvidia-drm-fb.o] 
Error 1

make[3]: *** Waiting for unfinished jobs
[...]
make[2]: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:2050: 
/var/lib/dkms/nvidia-legacy-390xx/390.157/build] Error 2

make[2]: Leaving directory '/usr/src/linux-headers-6.3.0-1-amd64'
make[1]: *** [Makefile:238: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.3.0-1-common'
make: *** [Makefile:82: modules] Error 2

The included patch solves both #1038014 
 and the 
error above.

Bug#1034395: libkf5kcmutils-dev: need fix incorrect symlink

[Antonio Russo]

control: tag -1 patch

This breaks builds of many things including, e.g., kwin.

I'm attaching couc...@debian.org 's patch, which fixed 5.103.0-3, but
apparently never got into the git repository.

Best,
Antonio Russo
(hello other Antonio!)
--- ../kcmutils/debian/libkf5kcmutils-bin.install	2023-06-19 16:10:51.039117308 -0600
+++ kcmutils-5.103.0/debian/libkf5kcmutils-bin.install	2023-02-28 04:48:46.0 -0700
@@ -1 +1 @@
-usr/lib/*/libexec/kf5/kcmdesktopfilegenerator usr/libexec/kf5/kcmdesktopfilegenerator
+usr/lib/*/libexec/kf5/kcmdesktopfilegenerator usr/libexec/kf5


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

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

[Antonio Terceiro]

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

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

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


signature.asc
Description: PGP signature

Bug#1035568: dnsmasq is broken on new bookworm installations

[Antonio Terceiro]

Control: severity -1 normal

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

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

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


signature.asc
Description: PGP signature

Bug#1018023: Update on this bug?

[Jose Antonio Jimenez Madrid]

Dear Matthew,

I have just uploaded to mentors a new version of the package fixing this
bug.
I will made other improvements after Bookworm is released as we are very
close to the full freeze.
The new package can be found here:

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

Thank you for your interest in Eterm,

Jose

Matthew Vernon wrote:
> Hi,
>
> On 14/02/2023 18:36, Jose Antonio Jimenez Madrid wrote:
>
>> I will test this patch and let you to know whether the bug is fixed.
>
> Any joy? We're approaching the time that eterm is going to be
> autoremoved from bookworm...
>
> Thanks,
>
> Matthew

Bug#1017218: marked as pending in ruby-parallel

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1017218 in ruby-parallel reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-parallel/-/commit/2e9dc6867d9541a89b4f10cd7c71edcb36f51cf1


Disable running upstream test suite

Closes: #905648, #1019646, #1017218


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1017218

Bug#1031238: marked as pending in debci

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1031238 in debci 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/ci-team/debci/-/commit/917430ee7492279993eef2fa5599944866ce6793


debci generate-apt-sources: add support for non-free-firmware

Closes: #1031238


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1031238

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

[Antonio Terceiro]

Control: severity -1 normal

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


signature.asc
Description: PGP signature

Bug#1018023: Update on this bug?

[Jose Antonio Jimenez Madrid]

Thanks Matthew for the links.

I will test this patch and let you to know whether the bug is fixed.

Sincerely,
Jose

Matthew Vernon wrote:
> Hi,
>
> Do you have plans to fix this before the bookworm freeze, please?
>
> I think netbsd at least have patched eterm to work with the newer
> imlib; at least per the comment here
> https://github.com/mej/Eterm/issues/4
>
> That linked to
> http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/eterm/patches/
>
> Which has a couple of patches that seem like they'd do the trick...
>
> Thanks,
>
> Matthew

Bug#1025125: closing 1025125

[Antonio Terceiro]

close 1025125 
thanks

Bug#1029594: Fails to authenticate mit o365

[Antonio]

The proposed fix works for me too.

Bug#1004068: marked as pending in origami-pdf

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1004068 in origami-pdf reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/origami-pdf/-/commit/265003d4bfe95c77983856f6481104db872ca733


Add patch from an upstream fork with fix for Ruby 3+

Closes: #1004068


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1004068

Bug#1028871: marked as pending in djangorestframework

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1028871 in djangorestframework 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/python-team/packages/djangorestframework/-/commit/fd193d9b87d1220836426e15510ea1bcf3085707


Add patch to fix tests against the environment on bookworm

Closes: #1028871


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1028871

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

[Antonio Terceiro]

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

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


signature.asc
Description: PGP signature

Bug#1028890: marked as pending in ruby

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1028890 in ruby reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby/-/commit/ff807c1310d34221957c9c29713cfe7360eab19b


Apply upstream patch to fix TZ tests

Closes: #1028890


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1028890

Bug#1028174: zfs-linux FTBFS due to python3-packaging

[Antonio Russo]

Package: src:zfs-linux
Version: 2.1.7-1
X-Debbugs-Cc: aeru...@aerusso.net
Severity: grave
Tags: patch

The recent upgrade of python3-packaging from 21.3-1.1 to 22.0-2 breaks
packaging.version.LegacyVersion (specifically, it removed it).  The configure
script will fail because it tries to use the unavailable class.

Matthew Ahrens has fixed this with upstream commit b72efb751 [1].

Best,
Antonio Russo


[1] 
https://github.com/openzfs/zfs/commit/b72efb751147ab57afd1588a15910f547cb22600

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

[Antonio Terceiro]

Control: reopen -1

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

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

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

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

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

and also on 2.39.90.20221231-1 (unstable)

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



signature.asc
Description: PGP signature

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

[Antonio Terceiro]

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

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

This is caused by ruby-specinfra.


signature.asc
Description: PGP signature

Bug#1027449: marked as pending in ruby-dbm

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1027449 in ruby-dbm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-dbm/-/commit/10bf8229a52d3f53ed90004bc3c9f27e7141f80a


debian/copyright: drop notes about licensing of resulting binaries

Closes: #1027449


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1027449

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

[Antonio Terceiro]

Control: tag -1 + pending

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

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


signature.asc
Description: PGP signature

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

[Antonio Terceiro]

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

Hi,

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

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


The full build log is attached.

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


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


signature.asc
Description: PGP signature

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

[Antonio Terceiro]

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

Hi,

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

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

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

[Antonio Terceiro]

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

Hi,

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

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

The full build log is attached.

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


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


signature.asc
Description: PGP signature

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

[Antonio Terceiro]

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

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

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


signature.asc
Description: PGP signature

Bug#1026897: marked as pending in ruby-tilt

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1026897 in ruby-tilt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-tilt/-/commit/4990458cf7b824ae7bc0cb7b9562a7f27ff78017


Add patch to remove warnings with ruby-haml >= 6

Closes: #1026897


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1026897

Bug#1026178: marked as pending in ruby-tzinfo

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1026178 in ruby-tzinfo reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-tzinfo/-/commit/f05c11f0a73409edf49bd1f3555198701561f232


Add dependency on tzdata

Closes: #1026178


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1026178

Bug#1026897: ruby-tilt: FTBFS: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

Source: ruby-tilt
Version: 2.0.11-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

After updating ruby-haml to 6.1.1, ruby-tilt fails to build with a test
failure.

Relevant part (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-tilt/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"tilt\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-tilt/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-tilt/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 -w -I"test" 
> /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/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
> Tilt::AsciidoctorTemplate (disabled)
> Tilt::BlueClothTemplate (disabled)
> Tilt::BuilderTemplate (disabled)
> Tilt::CoffeeScriptTemplate (disabled)
> Tilt::CommonMarkerTemplate (disabled)
> /<>/test/tilt_compilesite_test.rb:40: warning: assigned but 
> unused variable - res
> /usr/share/rubygems-integration/all/gems/creole-0.5.0/lib/creole/parser.rb:255:
>  warning: character class has duplicated range: /\A([:alpha:]|[:digit:])+/
> Tilt::ErubiTemplate (disabled)
> Tilt::KramdownTemplate (disabled)
> Tilt::LessTemplate (disabled)
> Tilt::LiquidTemplate (disabled)
> Tilt::LiveScriptTemplate (disabled)
> /<>/test/tilt_markaby_test.rb:51: warning: assigned but unused 
> variable - eval_scope
> Tilt::MarkabyTemplate (disabled)
> /<>/test/tilt_markdown_test.rb:85: warning: assigned but unused 
> variable - boom
> /usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.13.10/lib/nokogiri/version/info.rb:85:
>  warning: possibly useless use of a variable in void context
> Tilt::MarukuTemplate (disabled)
> Tilt::PandocTemplate (disabled)
> Tilt::PrawnTemplate (disabled)
> Tilt::RadiusTemplate (disabled)
> Tilt::RDiscountTemplate (disabled)
> Tilt::RedcarpetTemplate (disabled)
> Tilt::RedClothTemplate (disabled)
> Tilt::RstPandocTemplate (disabled) [cannot load such file -- pandoc]
> Tilt::SassTemplate (disabled)
> Tilt::SigilTemplate (disabled)
> /<>/test/tilt_template_test.rb:3: warning: setting 
> Encoding.default_external
> /<>/test/test_helper.rb:39: warning: method redefined; 
> discarding old test_template_source_with_locals_of_strings
> /<>/test/tilt_template_test.rb:132: warning: previous definition 
> of test_template_source_with_locals_of_strings was here
> Tilt::TypeScriptTemplate (disabled)
> Tilt::WikiClothTemplate (disabled)
> Run options: -v --seed 27460
> 
> # 

Bug#1026895: ruby-html2haml: FTBFS with ruby-haml 6.1.1: ERROR: Test "ruby3.1" failed: Could not find 'haml' (>= 4.0, < 6) among 102 total gem(s) (Gem::MissingSpecError)

[Antonio Terceiro]

Source: ruby-html2haml
Version: 2.2.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

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


Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block 
> in activate_dependencies': Could not find 'haml' (>= 4.0, < 6) among 102 
> total gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-html2haml/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  at: 
> /<>/debian/ruby-html2haml/usr/share/rubygems-integration/all/specifications/html2haml-2.2.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'haml' (>= 4.0, < 6) - did find: [haml-6.1.1] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-html2haml/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> abbrev (default: 0.1.0)
> base64 (default: 0.1.1)
> benchmark (default: 0.2.0)
> bigdecimal (default: 3.1.1)
> bundler (default: 2.3.7)
> cgi (default: 0.3.1)
> csv (default: 3.2.2)
> date (default: 3.2.2)
> debug (1.4.0)
> delegate (default: 0.2.0)
> did_you_mean (default: 1.6.1)
> digest (default: 3.1.0)
> drb (default: 2.1.0)
> english (default: 0.7.1)
> erb (default: 2.2.3)
> error_highlight (default: 0.3.0)
> erubis (2.7.0)
> etc (default: 1.3.0)
> fcntl (default: 1.0.1)
> fiddle (default: 1.1.0)
> fileutils (default: 1.6.0)
> find (default: 0.1.1)
> forwardable (default: 1.3.2)
> getoptlong (default: 0.1.1)
> haml (6.1.1)
> io-console (default: 0.5.11)
> io-nonblock (default: 0.1.0)
> io-wait (default: 0.2.1)
> ipaddr (default: 1.2.4)
> irb (default: 1.4.1)
> json (default: 2.6.1)
> logger (default: 1.5.0)
> matrix (0.4.2)
> mini_portile2 (2.8.0)
> minitest (5.15.0)
> mutex_m (default: 0.1.1)
> net-ftp (0.1.3)
> net-http (default: 0.2.0)
> net-imap (0.2.3)
> net-pop (0.1.1)
> net-protocol (default: 0.1.2)
> net-smtp (0.3.1)
> net-telnet (0.1.1)
> nkf (default: 0.1.1)
> nokogiri (1.13.10)
> observer (default: 0.1.1)
> open-uri (default: 0.2.0)
> open3 (default: 0.1.1)
> openssl (default: 3.0.0)
> optparse (default: 0.2.0)
> ostruct (default: 0.5.2)
> pathname (default: 0.2.0)
> pkg-config (1.4.6)
> power_assert (2.0.1)
> pp (default: 0.3.0)
> prettyprint (default: 0.1.1)
> prime (0.1.2)
> pstore (default: 0.1.1)
> psych (default: 4.0.3)
> racc (default: 1.6.0, 1.4.14)
> rake (13.0.6)
> rbs (2.1.0)
> rdoc (default: 6.4.0)
> readline (default: 0.0.3)
> readline-ext (default: 0.1.4)
> reline (default: 0.3.0)
> resolv (default: 0.2.1)
> resolv-replace (default: 0.1.0)
> rexml (3.2.5)
> rinda (default: 0.1.1)
> rss (0.2.9)
> ruby2_keywords (default: 0.0.5)
> ruby_parser (3.15.1)
> rubygems-update (3.3.15)
> sdbm (1.0.0)
> securerandom (default: 0.1.1)
> set (default: 1.0.2)
> sexp_processor (4.15.2)
> shellwords (default: 0.1.0)
> singleton (default: 0.1.1)
> stringio (default: 3.0.1)
> strscan (default: 3.0.1)
> syslog (default: 0.1.0)
> tempfile (default: 0.1.2)
> temple (0.8.2)
> test-unit (3.5.3)
> thor (1.2.1)
> tilt (2.0.11)
> time (default: 0.2.0)
> 

Bug#1026894: ruby-haml-rails: FTBFS: unsatisfiable build-dependency: ruby-haml (< 6.0) but 6.1.1-1 is to be installed

[Antonio Terceiro]

Source: ruby-haml-rails
Version: 2.0.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

After updating ruby-haml to 6.1.1, ruby-haml-rails has unsatisfiable
build dependencies.

Relevant part (hopefully):
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper-compat (= 12), gem2deb, rails, rake, 
> ruby-actionpack, ruby-activesupport, ruby-haml (<< 6.0), ruby-haml (>= 
> 4.0.6~), ruby-html2haml (>= 2.0~), ruby-railties, ruby-test-unit, 
> build-essential, fakeroot
> Filtered Build-Depends: debhelper-compat (= 12), gem2deb, rails, rake, 
> ruby-actionpack, ruby-activesupport, ruby-haml (<< 6.0), ruby-haml (>= 
> 4.0.6~), ruby-html2haml (>= 2.0~), ruby-railties, ruby-test-unit, 
> build-essential, fakeroot
> dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
> '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
> Ign:1 copy:/<>/apt_archive ./ InRelease
> Get:2 copy:/<>/apt_archive ./ Release [580 B]
> Ign:3 copy:/<>/apt_archive ./ Release.gpg
> Get:4 copy:/<>/apt_archive ./ Sources [776 B]
> Get:5 copy:/<>/apt_archive ./ Packages [808 B]
> Fetched 2164 B in 0s (0 B/s)
> Reading package lists...
> Get:1 file:/<>/resolver-c7QS2B/apt_archive ./ InRelease
> Ign:1 file:/<>/resolver-c7QS2B/apt_archive ./ InRelease
> Get:2 file:/<>/resolver-c7QS2B/apt_archive ./ Release [577 B]
> Get:2 file:/<>/resolver-c7QS2B/apt_archive ./ Release [577 B]
> Get:3 file:/<>/resolver-c7QS2B/apt_archive ./ Release.gpg
> Ign:3 file:/<>/resolver-c7QS2B/apt_archive ./ Release.gpg
> Reading package lists...
> Reading package lists...
> 
> Install main build dependencies (apt-based resolver)
> 
> 
> Installing build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: ruby-haml (< 6.0) but 6.1.1-1 is 
> to be installed
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.


signature.asc
Description: PGP signature

Bug#1026893: ruby-haml-contrib: FTBFS: ERROR: Test "ruby3.1" failed: /<>/debian/ruby-haml-contrib/usr/lib/ruby/vendor_ruby/haml/filters/php.rb:8:in `': Filters is not a modul

[Antonio Terceiro]

Source: ruby-haml-contrib
Version: 1.0.0.1-2.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

After updaring ruby-haml to 6.6.1, ruby-haml-contrib fails to build with
a test failure.

Relevant part (hopefully):
> /<>/debian/ruby-haml-contrib/usr/lib/ruby/vendor_ruby/haml/filters/php.rb:8:in
>  `': Filters is not a module (TypeError)
> /usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/haml-6.1.1/lib/haml/filters/base.rb:5:
>  previous definition of Filters was here
>   from 
> /<>/debian/ruby-haml-contrib/usr/lib/ruby/vendor_ruby/haml/filters/php.rb:7:in
>  `'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from /<>/test/php_filter_test.rb:2:in `'
>   from 
> :85:in
>  `require'
>   from 
> :85:in
>  `require'
>   from debian/ruby-tests.rb:2:in `block in '
>   from debian/ruby-tests.rb:2:in `each'
>   from debian/ruby-tests.rb:2:in `'
> ERROR: Test "ruby3.1" failed: 

Attached is the full build log.


ruby-haml-contrib.log.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1026892: asciidoctor: FTBFS with haml 6.1.1: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

Source: asciidoctor
Version: 2.0.17-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi,

I'm working on updating ruby-haml to the new upstream versinon 6.1.1,
and when trying asciidoctor against that the tests fail.


Relevant part (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-asciidoctor/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"asciidoctor\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-asciidoctor/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-asciidoctor/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 -w -I"lib:test" 
> /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
> "test/api_test.rb" "test/attribute_list_test.rb" "test/attributes_test.rb" 
> "test/blocks_test.rb" "test/converter_test.rb" "test/document_test.rb" 
> "test/extensions_test.rb" "test/helpers_test.rb" "test/invoker_test.rb" 
> "test/links_test.rb" "test/lists_test.rb" "test/logger_test.rb" 
> "test/manpage_test.rb" "test/options_test.rb" "test/paragraphs_test.rb" 
> "test/parser_test.rb" "test/paths_test.rb" "test/preamble_test.rb" 
> "test/reader_test.rb" "test/sections_test.rb" "test/substitutions_test.rb" 
> "test/syntax_highlighter_test.rb" "test/tables_test.rb" "test/text_test.rb" 
> RUBY_GC_HEAP_FREE_SLOTS=75 (default value: 4096)
> RUBY_GC_HEAP_INIT_SLOTS=75 (default value: 1)
> RUBY_GC_HEAP_GROWTH_FACTOR=2.00 (default value: 1.80)
> RUBY_GC_HEAP_GROWTH_MAX_SLOTS=5 (default value: 0)
> RUBY_GC_MALLOC_LIMIT=12800 (default value: 16777216)
> RUBY_GC_OLDMALLOC_LIMIT=12800 (default value: 16777216)
> /usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.13.10/lib/nokogiri/version/info.rb:85:
>  warning: possibly useless use of a variable in void context
> Run options: --seed 60429
> 
> # Running:
> 
> ...Haml::Engine:
>  Option :attr_wrapper is invalid
> Haml::Engine: Option :attr_wrapper is invalid
> FHaml::Engine: Option :attr_wrapper is invalid
> 

Bug#1026779: binutils: cross binutils and foreign libbinutils not coinstallable, breaking upgrades

[Antonio Terceiro]

Source: binutils
Version: 2.39.50.20221208-5
Severity: serious

Dear Maintainer,

Up to src:binutils 2.39-8, binutils-${DEB_HOST_MULTIARCH} and
libbinutils:${DEB_HOST_ARCH} were coinstallable. Upgrading a system
where both are installed (e.g. binutils-aarch64-linux-gnu and
libbinutils:arm64) fails like this:

8<8<8<-
Unpacking libbinutils:arm64 (2.39.50.20221208-5) over (2.39-8) ...
Preparing to unpack 
.../3-binutils-aarch64-linux-gnu_2.39.50.20221208-5_amd64.deb ...
Unpacking binutils-aarch64-linux-gnu (2.39.50.20221208-5) over (2.39-8) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-maU0ym/3-binutils-aarch64-linux-gnu_2.39.50.20221208-5_amd64.deb
 (--unpack):
 trying to overwrite '/usr/lib/aarch64-linux-gnu/libsframe.so.0.0.0', which is 
also in package libbinutils:arm64 2.39.50.20221208-5
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../4-binutils-common_2.39.50.20221208-5_amd64.deb ...
De-configuring binutils-common:arm64 (2.39-8), to allow configuration of 
binutils-common:amd64 (2.39.50.20221208-5) ...
Unpacking binutils-common:amd64 (2.39.50.20221208-5) over (2.39-8) ...
Preparing to unpack .../5-binutils-common_2.39.50.20221208-5_arm64.deb ...
Unpacking binutils-common:arm64 (2.39.50.20221208-5) over (2.39-8) ...
Selecting previously unselected package libbinutils:amd64.
Preparing to unpack .../6-libbinutils_2.39.50.20221208-5_amd64.deb ...
Unpacking libbinutils:amd64 (2.39.50.20221208-5) ...
Selecting previously unselected package libjansson4:amd64.
Preparing to unpack .../7-libjansson4_2.14-2_amd64.deb ...
Unpacking libjansson4:amd64 (2.14-2) ...
Errors were encountered while processing:
 
/tmp/apt-dpkg-install-maU0ym/3-binutils-aarch64-linux-gnu_2.39.50.20221208-5_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
8<8<8<-

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

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

-- no debconf information


signature.asc
Description: PGP signature

Bug#1026427: jekyll: depends on deprecated and broken ruby-safe-yaml

[Antonio Terceiro]

Package: jekyll
Version: 3.9.0+dfsg-5
Severity: serious
Tags: upstream

Dear Maintainer,

Working to get ruby3.1 as the default Ruby version it was noticed that
ruby-safe-yaml is incompatible with ruby3.1 and thus deprecated. Most
upstreams have dropped their dependencies on it; I checked and jekyll is
not there yet. There is this pull request upstream, but that didn't get
into a release yet:

https://github.com/jekyll/jekyll/pull/8772

ruby-safe-yaml will soon be removed from testing due to this (maybe even
before the autoremoval), jekyll needs to drop its dependency on it.

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

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


signature.asc
Description: PGP signature

Bug#1026227: vagrant: Uninstallable in sid with VirtualBox 7.0.x

[Antonio Terceiro]

On Fri, Dec 16, 2022 at 06:31:41PM +0100, Guillem Jover wrote:
> Package: vagrant
> Version: 2.2.19+dfsg-2
> Severity: serious
> 
> Hi!
> 
> Since virtualbox 7.0.4 got uploaded, vagrant is no longer installable
> in Debian sid. I assume this will require packaging a new upstream
> release to support the new virtualbox version 7.0.x series.

I cherry picked a patch from upstream that should solve the issue. The
Breaks: restriction will now make the package installable with
virtualbox 7.0, but I don't use virtualbox so I can't really test that
it actually works.

Can you please try the package from git master?


signature.asc
Description: PGP signature

Bug#1026107: ruby-asciidoctor-pdf: depends on deprecated ruby-safe-yaml

[Antonio Terceiro]

Package: ruby-asciidoctor-pdf
Version: 1.6.2-1
Severity: serious
Tags: upstream
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Dear Maintainer,

Working to get ruby3.1 as the default Ruby version it was noticed that
ruby-safe-yaml is incompatible with ruby3.1 and thus deprecated. Most
upstreams have dropped their dependencies on it; I checked and that is
also the case for asciidoctor-pdf: v2.3.4 no longer depends on
safe_yaml.

ruby-safe-yaml will soon be removed from testing due to this,
ruby-asciidoctor-pdf needs to drop its dependency on it.

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

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

Versions of packages ruby-asciidoctor-pdf depends on:
ii  ruby  1:3.1~1
ii  ruby-asciidoctor  2.0.17-1
ii  ruby-concurrent   1.1.6+dfsg-5
pn  ruby-prawn
pn  ruby-prawn-icon   
pn  ruby-prawn-svg
pn  ruby-prawn-table  
ii  ruby-safe-yaml1.0.5-2
pn  ruby-treetop  

ruby-asciidoctor-pdf recommends no packages.

Versions of packages ruby-asciidoctor-pdf suggests:
ii  ruby-rouge  3.30.0-2


signature.asc
Description: PGP signature

Bug#1022255: fixed in python-xarray 2022.11.0-2

[Antonio Valentino]

Dear Alastair,

Il 12/12/22 12:34, Alastair McKinstry ha scritto:

Dear Antonio


Apologies but I saw this too late to stop the transition to testing.

At this stage, I believe the best solution is to work on the issues in 
satpy and dask; I can help.


Thanks for your kind offer.
Luckily I was able to implement a patch with a workaround for satpy.
I have uploaded a new version that, hopefully, should be able to migrate 
without problems.

We still do not have the CI tests on all platforms anyway.


Kind regards
antonio


On 07/12/2022 08:38, Antonio Valentino wrote:

Dear Alastair,

On Mon, 21 Nov 2022 15:12:02 + Debian FTP Masters 
 wrote:

Source: python-xarray
Source-Version: 2022.11.0-2
Done: Alastair McKinstry 

We believe that the bug you reported is fixed in the latest version of
python-xarray, 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 1022...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry  (supplier of updated 
python-xarray 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: Mon, 21 Nov 2022 14:37:38 +
Source: python-xarray
Architecture: source
Version: 2022.11.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 


Changed-By: Alastair McKinstry 
Closes: 1004869 1022255 1023222
Changes:
 python-xarray (2022.11.0-2) unstable; urgency=medium
 .
   * Ack bogs fixed in this and previous releases:
 Closes: #1022255, #1004869, #1023222
Checksums-Sha1:
 25bfc4ad68c46f9f7428c7a008736478f3bd2fa7 3395 
python-xarray_2022.11.0-2.dsc
 9d5fa48523ea38b6684f9b18e3d3a10a8aee2875 14092 
python-xarray_2022.11.0-2.debian.tar.xz

Checksums-Sha256:
 2921fcf4d7b5b82ed54813180ceacb2261264e99eb22e1b9bcf11e8660755e6e 
3395 python-xarray_2022.11.0-2.dsc
 c480af287094772516773b559ac385d6eed33001e1ded8aa1ddab4db721fc91b 
14092 python-xarray_2022.11.0-2.debian.tar.xz

Files:
 16ee7843761bf700d78213b6a8061f38 3395 python optional 
python-xarray_2022.11.0-2.dsc
 b483b08efbb572a27c4af434d3df17d1 14092 python optional 
python-xarray_2022.11.0-2.debian.tar.xz


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmN7jiUACgkQy+a7Tl2a
06Vb0Q//YmFju6NG15oqqygNRQiiGIGPXS+qvtwPbXKGJDq6g3rX24KdF2tP77i6
Aw9LjfskclEe7TRQCwaS/49qh+6CE+Tndv47nMGb3jnBGL0vYa9YqOn3XeBAHCcw
aYCvbkks5HxDWizJ6Kh2Ohef0okEl2Q/pHDKMDfF+Q8DEvGh7iFtedVF6ARquPSW
95u3V6QhCCQPws26cYPz1L2a+QJuEf49lohoVDC8u4EtaJHbv1NKXtQP1srEqf10
zqbSd6KDqT3mn4dONtF7etxzQGxSHRySEPJpXQ+2kkdmcueLUT5UAEazC6SCdCUB
GMCqMFbwi4kY7CaaK5646XxCm3QQUg3UeZAMHqsBI9gYModfKG8twRhlyA4N9mam



Unfortunately version 2022.11.2 and 2022.12.0 of xarray still causes 
test failures in satpy.
According to the satpy upstream developers [1] (also reported in one 
of the previous messages [2]), the problem should be related to some 
kind of incompatibility between new versions of xarray and the version 
of dask currently in Debian (2022.02.0).


I can confirm that updating dask to 2022.11.1 fixes the issues and 
satpy tests pass with dask 2022.11.1 and xarray 2022.12.0.


I have started preparing a Merge Request [3] to update the dask package.
Unfortunately, while the Python package itself builds and works well, 
it is currently not possible to build the -doc package because of 
outdated build dependencies or new build dependencies still not in 
debian.


In addition, there are some other test failures in satpy that are not 
related to xarray/dask and could be fixed with an update to the latest 
upstream version of satpy (0.38.0).
I have the packaging work done (locally), but I cannot upload until 
the problem with xarray/dask is solved.


In conclusion the satpy version currently in testing works perfectly 
with xarray 2022.06.0, but the migration of xarray 2022.12.0 would 
break satpy and make it unbuildable both in testing and unstable.


Honestly I'm not sure about what is the best way to proceed.
In principle I think that this issue should be re-open and xarray 
2022.12.0 should not migrate, for the moment at least.


But then the way forward is not clear to me.
Waiting for an update of dask could take some time.
Of course I would be more that happy to help to prepare a new version 
of the dask package.


What is your idea about how to proceed?

[1] https://github.com/pytroll/satpy/issues/2248#issuecomment-1296325915
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022255#16
[3] https://salsa.debian.org/python-team/packages/dask/-/merge_requests/1


kind regards




--
Antonio Valentino

Bug#1022255: fixed in python-xarray 2022.11.0-2

[Antonio Valentino]

Dear Alastair,

On Mon, 21 Nov 2022 15:12:02 + Debian FTP Masters 
 wrote:

Source: python-xarray
Source-Version: 2022.11.0-2
Done: Alastair McKinstry 

We believe that the bug you reported is fixed in the latest version of
python-xarray, 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 1022...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alastair McKinstry  (supplier of updated python-xarray 
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: Mon, 21 Nov 2022 14:37:38 +
Source: python-xarray
Architecture: source
Version: 2022.11.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Alastair McKinstry 
Closes: 1004869 1022255 1023222
Changes:
 python-xarray (2022.11.0-2) unstable; urgency=medium
 .
   * Ack bogs fixed in this and previous releases:
 Closes: #1022255, #1004869, #1023222
Checksums-Sha1:
 25bfc4ad68c46f9f7428c7a008736478f3bd2fa7 3395 python-xarray_2022.11.0-2.dsc
 9d5fa48523ea38b6684f9b18e3d3a10a8aee2875 14092 
python-xarray_2022.11.0-2.debian.tar.xz
Checksums-Sha256:
 2921fcf4d7b5b82ed54813180ceacb2261264e99eb22e1b9bcf11e8660755e6e 3395 
python-xarray_2022.11.0-2.dsc
 c480af287094772516773b559ac385d6eed33001e1ded8aa1ddab4db721fc91b 14092 
python-xarray_2022.11.0-2.debian.tar.xz
Files:
 16ee7843761bf700d78213b6a8061f38 3395 python optional 
python-xarray_2022.11.0-2.dsc
 b483b08efbb572a27c4af434d3df17d1 14092 python optional 
python-xarray_2022.11.0-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmN7jiUACgkQy+a7Tl2a
06Vb0Q//YmFju6NG15oqqygNRQiiGIGPXS+qvtwPbXKGJDq6g3rX24KdF2tP77i6
Aw9LjfskclEe7TRQCwaS/49qh+6CE+Tndv47nMGb3jnBGL0vYa9YqOn3XeBAHCcw
aYCvbkks5HxDWizJ6Kh2Ohef0okEl2Q/pHDKMDfF+Q8DEvGh7iFtedVF6ARquPSW
95u3V6QhCCQPws26cYPz1L2a+QJuEf49lohoVDC8u4EtaJHbv1NKXtQP1srEqf10
zqbSd6KDqT3mn4dONtF7etxzQGxSHRySEPJpXQ+2kkdmcueLUT5UAEazC6SCdCUB
GMCqMFbwi4kY7CaaK5646XxCm3QQUg3UeZAMHqsBI9gYModfKG8twRhlyA4N9mam



Unfortunately version 2022.11.2 and 2022.12.0 of xarray still causes 
test failures in satpy.
According to the satpy upstream developers [1] (also reported in one of 
the previous messages [2]), the problem should be related to some kind 
of incompatibility between new versions of xarray and the version of 
dask currently in Debian (2022.02.0).


I can confirm that updating dask to 2022.11.1 fixes the issues and satpy 
tests pass with dask 2022.11.1 and xarray 2022.12.0.


I have started preparing a Merge Request [3] to update the dask package.
Unfortunately, while the Python package itself builds and works well, it 
is currently not possible to build the -doc package because of outdated 
build dependencies or new build dependencies still not in debian.


In addition, there are some other test failures in satpy that are not 
related to xarray/dask and could be fixed with an update to the latest 
upstream version of satpy (0.38.0).
I have the packaging work done (locally), but I cannot upload until the 
problem with xarray/dask is solved.


In conclusion the satpy version currently in testing works perfectly 
with xarray 2022.06.0, but the migration of xarray 2022.12.0 would break 
satpy and make it unbuildable both in testing and unstable.


Honestly I'm not sure about what is the best way to proceed.
In principle I think that this issue should be re-open and xarray 
2022.12.0 should not migrate, for the moment at least.


But then the way forward is not clear to me.
Waiting for an update of dask could take some time.
Of course I would be more that happy to help to prepare a new version of 
the dask package.


What is your idea about how to proceed?

[1] https://github.com/pytroll/satpy/issues/2248#issuecomment-1296325915
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022255#16
[3] https://salsa.debian.org/python-team/packages/dask/-/merge_requests/1


kind regards
--
Antonio Valentino

Bug#1019635: marked as pending in ruby-mail

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1019635 in ruby-mail reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/ruby-mail/-/commit/2460a6e62ef16ff6d73456ca7fb2550523726783


Add patches to fix tests with ruby3.1

Closes: #1019635


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1019635

Bug#1025261: marked as pending in vagrant

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1025261 in vagrant reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/vagrant/-/commit/f89c5d4283f370fda5c2564221812ac1ef058317


Don't force an upper bound on Ruby versions

Closes: #1025261


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1025261

Bug#1024174: closing 1024175, closing 1024174

[Antonio Terceiro]

close 1024175 4.1.0-1
close 1024174 1.0.1-1
thanks

These bugs have been closed in the last uploads of ruby-omniauth-gitlab and
ruby-omniauth-dingtalk-oauth2, respectively, but I missed the bugs already
reported.

Bug#1006022: marked as pending in puma

[Antonio Terceiro]

Control: tag -1 pending

Hello,

Bug #1006022 in puma reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/ruby-team/puma/-/commit/e6961fbc2125bcaccb759b4c7fb05576ed37545e


debian/ruby-tests.rake: skip test that fails often

I tried rebuilding 10 times, and that one test failed in 2 of those
builds.

Closes: #1006022


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1006022

Bug#1022255: python-xarray breaks satpy autopkgtest

[Antonio Valentino]

It seems that the issue is related to an incompatibility between the new 
xarray and the current dask.


According to [1] an update of dask to 2022.10.0 should fix the issue.

[1] https://github.com/pytroll/satpy/issues/2248#issuecomment-1296325915

cheers
antonio


On Sat, 22 Oct 2022 21:36:41 +0200 Paul Gevers  wrote:

Source: python-xarray, satpy
Control: found -1 python-xarray/2022.10.0-1
Control: found -1 satpy/0.37.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


passfail
python-xarray  from testing2022.10.0-1
satpy  from testing0.37.1-1
all others from testingfrom testing

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

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/s/satpy/27389134/log.gz


--
Antonio Valentino

Bug#1022338: satpy: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Antonio Valentino]

Dear Lucas,
thanks for reporting.
This is probably a duplicate of #1022255.

kind regards
antonio

On Sun, 23 Oct 2022 15:08:02 +0200 Lucas Nussbaum  wrote:

Source: satpy
Version: 0.37.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20221023 ftbfs-bookworm

Hi,

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


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_test
> I: pybuild base:240: cd /<>/.pybuild/cpython3_3.10_satpy/build; python3.10 
-m pytest -k "not test_retrieve and not test_offline_retrieve and not test_retrieve_all and not 
test_download_script and not test_start_time and not test_end_time and not test_mimic_TPW2_nc and not 
TestAngleGeneration and not test_get_luts and not test_convert_remote_files_to_fsspec_fsfile and not 
test_convert_remote_files_to_fsspec_filename_dict and not 
test_convert_remote_files_to_fsspec_mixed_sources and not test_get_satpos_from_satname and not 
test_enhanced_image and not test_double_load and not test_correct_area_no_orbital_parameters"
> = test session starts 
==
> platform linux -- Python 3.10.7, pytest-7.1.2, pluggy-1.0.0+repack
> rootdir: /<>
> plugins: lazy-fixture-0.6.3
> collected 1774 items / 64 deselected / 1710 selected
> 
> satpy/tests/test_compat.py ..[  0%]

> satpy/tests/test_composites.py . [  
2%]
> .[  
5%]
> satpy/tests/test_config.py . [  
6%]
> satpy/tests/test_crefl_utils.py .[  
6%]
> satpy/tests/test_data_download.py .  [  
7%]
> satpy/tests/test_dataset.py  [ 
10%]
> ..   [ 
11%]
> satpy/tests/test_demo.py ... [ 
12%]
> satpy/tests/test_dependency_tree.py  [ 
12%]
> satpy/tests/test_file_handlers.py .  [ 
13%]
> satpy/tests/test_modifiers.py F...   [ 
14%]
> satpy/tests/test_multiscene.py ...   [ 
15%]
> satpy/tests/test_node.py [ 
15%]
> satpy/tests/test_readers.py  [ 
18%]
>  [ 
19%]
> satpy/tests/test_regressions.py ...  [ 
19%]
> satpy/tests/test_resample.py ...ss.  [ 
21%]
> satpy/tests/test_scene.py .. [ 
23%]
> FFF...FF.F.FF...F... [ 
28%]
> sss..[ 
28%]
> satpy/tests/test_utils.py ...[ 
30%]
> satpy/tests/test_writers.py .[ 
32%]
> satpy/tests/test_yaml_reader.py  [ 
34%]
> .[ 
34%]
> satpy/tests/compositor_tests/test_abi.py ..  [ 
35%]
> satpy/tests/compositor_tests/test_ahi.py ..  [ 
35%]
> satpy/tests/compositor_tests/test_glm.py ..  [ 
35%]
> satpy/tests/compositor_tests/test_sar.py ..  [ 
35%]
> satpy/tests/compositor_tests/test_viirs.py . [ 
35%]
> satpy/tests/enhancement_tests/test_abi.py .  [ 
35%]
> satpy/tests/enhancement_tests/test_ahi.py .  [ 
36%]
> satpy/tests/enhancement_tests/test_enhancements.py . [ 
37%]
> .[ 
40%]
> satpy/tests/enhancement_tests/test_viirs.py .[ 
40%]
> satpy/tests/modifier_tests/test_crefl.py .   [ 
40%]


--
Antonio Valentino

Bug#1021737: lava: CVE-2022-42902

[Antonio Terceiro]

On Wed, Oct 19, 2022 at 09:57:34PM +0200, Moritz Muehlenhoff wrote:
> On Tue, Oct 18, 2022 at 06:09:42PM -0300, Antonio Terceiro wrote:
> > Hi,
> > 
> > On Thu, Oct 13, 2022 at 09:13:18PM +0200, Moritz Mühlenhoff wrote:
> > > Source: lava
> > > X-Debbugs-CC: t...@security.debian.org
> > > Severity: grave
> > > Tags: security
> > > 
> > > Hi,
> > > 
> > > The following vulnerability was published for lava.
> > > 
> > > CVE-2022-42902[0]:
> > > | In Linaro Automated Validation Architecture (LAVA) before 2022.10,
> > > | there is dynamic code execution in lava_server/lavatable.py. Due to
> > > | improper input sanitization, an anonymous user can force the lava-
> > > | server-gunicorn service to execute user-provided code on the server.
> > > 
> > > https://git.lavasoftware.org/lava/lava/-/merge_requests/1834
> > > https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8f3431740963be228b52?merge_request_iid=1834
> > > 
> > > If you fix the vulnerability please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > > 
> > > For further information see:
> > > 
> > > [0] https://security-tracker.debian.org/tracker/CVE-2022-42902
> > > https://www.cve.org/CVERecord?id=CVE-2022-42902
> > > 
> > > Please adjust the affected versions in the BTS as needed.
> > 
> > I have uploaded a fix version to unstable (latest upstream), and I would
> > like to upload the attached debdiff to -security. That package builds
> > cleanly and passes its autopkgtest on bullseye. Let me know.
> 
> Ack, we can fix this via a DSA. The debdiff looks fine content-wise,
> but the deb111u1 version is slightly off by 100 Debian releases ;-)
> 
> So please change to +deb11u1 and upload to security-master.

Heh, my mistake.

Just uploaded.


signature.asc
Description: PGP signature

Bug#1021737: lava: CVE-2022-42902

[Antonio Terceiro]

On Tue, Oct 18, 2022 at 06:09:45PM -0300, Antonio Terceiro wrote:
> Hi,
> 
> On Thu, Oct 13, 2022 at 09:13:18PM +0200, Moritz Mühlenhoff wrote:
> > Source: lava
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: grave
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for lava.
> > 
> > CVE-2022-42902[0]:
> > | In Linaro Automated Validation Architecture (LAVA) before 2022.10,
> > | there is dynamic code execution in lava_server/lavatable.py. Due to
> > | improper input sanitization, an anonymous user can force the lava-
> > | server-gunicorn service to execute user-provided code on the server.
> > 
> > https://git.lavasoftware.org/lava/lava/-/merge_requests/1834
> > https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8f3431740963be228b52?merge_request_iid=1834
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2022-42902
> > https://www.cve.org/CVERecord?id=CVE-2022-42902
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> I have uploaded a fix version to unstable (latest upstream), and I would
> like to upload the attached debdiff to -security. That package builds
> cleanly and passes its autopkgtest on bullseye. Let me know.

Correction: it fails the autopkgtest, but it fails in the exact same way
as the package already in bullseye fails.


signature.asc
Description: PGP signature

Bug#1021737: lava: CVE-2022-42902

[Antonio Terceiro]

tinue  # just skip this term - results in a query matching All.
+q &= Q(**{f"{key}__contains": val})
+
 if (
 hasattr(self.table_class.Meta, "queries")
 and key in self.table_class.Meta.queries.keys()
 ):
-# note that this calls the function 'key' with the argument from the search
-args = 'q = q.__and__(self.{0}("{1}"))'.format(key, val)
-try:
-exec(args, globals(), local_namespace)
-except SyntaxError:
-# should log exception somewhere...
-continue
+# note that this calls
+# the function 'key' with the argument from the search
+q &= getattr(self, key)(val)
+
 # general OR searches
 if self.request.GET.get(table_search):
 self.terms["search"] = escape(self.request.GET.get(table_search))
 if hasattr(self.table_class.Meta, "searches") and "search" in self.terms:
 for key, val in self.table_class.Meta.searches.items():
-# this is a little bit of magic - creates an OR clause in the query based
-# on the iterable search hash passed in via the table_class
+# this is a little bit of magic - creates an OR clause
+# in the query based on the iterable search hash
+# passed in via the table_class
 # e.g. self.searches = {'id', 'contains'}
-# so every simple search column in the table is queried at the same time with OR
-args = 'q = q.__or__(Q({0}__{1}=self.terms["search"]))'.format(key, val)
-try:
-exec(args, globals(), local_namespace)  # sets the value of q
-except SyntaxError:
-# should log exception somewhere...
-continue  # just skip this term - results in a query matching All.
+# so every simple search column in the table
+# is queried at the same time with OR
+q |= Q(**{f"{key}__{val}": self.terms["search"]})
+
 # call explicit handlers as simple text searches of relational fields.
 if hasattr(self.table_class.Meta, "queries"):
 for key in self.table_class.Meta.queries:
-# note that this calls the function 'key' with the argument from the search
-args = 'q = q.__or__(self.{0}("{1}"))'.format(
-key, self.terms["search"].encode("utf-8")
-)
-try:
-exec(args, globals(), local_namespace)
-except SyntaxError:
-# should log exception somewhere...
-continue
+# note that this calls the function 'key'
+# with the argument from the search
+q |= getattr(self, key)(self.terms["search"])
+
 # now add "class specials" - from an iterable hash
 # datetime uses (start_time__lte=timezone.now()-timedelta(days=3)
-data = data.filter(self._time_filter(local_namespace["q"]))
-return data
+return data.filter(self._time_filter(q))
 
 
 class LavaTable(tables.Table):
From e1f934df702a1db386e301fbe2d51ab4154ee21c Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Tue, 18 Oct 2022 17:57:46 -0300
Subject: [PATCH] share/requires.py: fix building for debian -backports and
 -security suites

---
 share/requires.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/share/requires.py b/share/requires.py
index 2599028d8..00aadc3a4 100755
--- a/share/requires.py
+++ b/share/requires.py
@@ -123,6 +123,8 @@ def main():
 help="Distribution package names for unittest support - requires --names",
 )
 args = parser.parse_args()
+args.suite = args.suite.replace("-backports", "")
+args.suite = args.suite.replace("-security", "")
 if args.unittests and not args.names:
 raise RuntimeError("--unittests option requires --names")
 try:
-- 
2.35.1

diff -Nru lava-2020.12/debian/changelog lava-2020.12/debian/changelog
--- lava-2020.12/debian/changelog	2021-05-24 09:05:18.0 -0300
+++ lava-2020.12/debian/changelog	2022-10-18 17:24:50.0 -0300
@@ -1,3 +1,10 @@
+lava (2020.12-5+deb111u1) bullseye-security; urgency=high
+
+  * Fix remote code execution [CVE-2022-42902] (Closes: #1021737)
+  * Add patch to fix building the package for -security
+
+ -- Antonio Terceiro   Tue, 18 Oct 2022 17:24:50 -0300
+
 lava (2020.12-5) unstable; urgency=medium
 
   * Fix PyYAML usage after backwards-incompatible se

Bug#979887: closing 979887

[Antonio Terceiro]

close 979887 2022.01.3-3
thanks

This has actually been fixed before 2022.01. Closing.

Bug#1020776: closing 1020776

[Antonio Terceiro]

close 1020776 
thanks

Bug#1019610: ruby-ahoy-email: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: cannot load such file -- net/smtp (LoadError)

[Antonio Terceiro]

Hi,

On Fri, Oct 07, 2022 at 01:50:56AM +0300, Adrian Bunk wrote:
> On Mon, Sep 12, 2022 at 08:24:43PM -0300, Antonio Terceiro wrote:
> > Source: ruby-ahoy-email
> > Version: 1.1.1-2
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: debian-r...@lists.debian.org
> > Usertags: ruby3.1
> > 
> > Hi,
> > 
> > We are about to start the ruby3.1 transition in unstable. While trying to
> > rebuild ruby-ahoy-email with ruby3.1 enabled, the build failed.
> > 
> > Relevant part of the build log (hopefully):
> > > /usr/share/rubygems-integration/all/gems/activesupport-6.1.6.1/lib/active_support/dependencies.rb:332:in
> > >  `require': cannot load such file -- net/smtp (LoadError)
> 
> Do you have any ides where this dependency is required and why it isn't found?

$ dpkg -S net/smtp.rb
libruby3.0:amd64: /usr/lib/ruby/3.0.0/net/smtp.rb
libruby3.1:amd64: /usr/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.1/lib/net/smtp.rb

In ruby3.0, net/smtp was part of the standard library, and in ruby3.1,
it's now a "default gem", which is more or less a third-party library
that happens to be shipped together with the standard library.

And it seems that the test suite for this package loads bundler. bundler
prevents any library that is not part of the standard library and is not
explicitly declared the Gemfile from being loaded, therefore it looks
like the library is not installed.

But nothing in ruby-ahoy-email codebase uses net/smtp explicitly, so
this is a bit weird. Our version is also quite outated wrt upstream, so
my first attempt would be to just update the latest upstream (there are
no reverse dependencies in the archive).


signature.asc
Description: PGP signature

Bug#1020435: ruby-prof: FTBFS on ppc64el

[Antonio Terceiro]

Control: tag -1 + unreproducible
Control: severity -1 important

Hi,

On Wed, Sep 21, 2022 at 07:20:31PM +0200, Sebastian Ramacher wrote:
> Source: ruby-prof
> Version: 1.4.3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
> 
> https://buildd.debian.org/status/fetch.php?pkg=ruby-prof=ppc64el=1.4.3-1%2Bb1=1663720013=0
> 
>   1) Failure:
> PrinterGraphTest#test_graph_results_sorting 
> [/<>/test/printer_graph_test.rb:37]:
> Array [0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 
> 0.0, 0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0] is not sorted.
> --- expected
> +++ actual
> @@ -1 +1 @@
> -[0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 0.0, 
> 0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0]
> +[0.171, 0.171, 0.17, 0.17, 0.169, 0.169, 0.167, 0.167, 0.166, 0.164, 0.004, 
> 0.004, 0.002, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
> 
> 
> 51 runs, 687 assertions, 1 failures, 0 errors, 0 skips
> rake aborted!
> Command failed with status (1): [ruby -w -I"test" 
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
>  "test/abstract_printer_test.rb" "test/alias_test.rb" "test/basic_test.rb" 
> "test/call_tree_visitor_test.rb" "test/call_trees_test.rb" 
> "test/duplicate_names_test.rb" "test/enumerable_test.rb" 
> "test/exceptions_test.rb" "test/exclude_methods_test.rb" 
> "test/exclude_threads_test.rb" "test/fiber_test.rb" "test/gc_test.rb" 
> "test/line_number_test.rb" "test/marshal_test.rb" 
> "test/multi_printer_test.rb" "test/no_method_class_test.rb" 
> "test/printer_call_stack_test.rb" "test/printer_call_tree_test.rb" 
> "test/printer_flat_test.rb" "test/printer_graph_html_test.rb" 
> "test/printer_graph_test.rb" "test/printing_recursive_graph_test.rb" 
> "test/profile_test.rb" "test/rack_test.rb" "test/singleton_test.rb" -v]
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in ` (required)>'
> Tasks: TOP => default
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.0" failed. Exiting.

Unfortunately I could not reproduce this on the ppc64el porterbox, even
trying the same random seed as the original build failure. I was
suspecting an random test failure, but I didn't see this after trying 50
builds in a row. In fact, just giving back the build on the buildd made
it succeed. I'm not saying there is no issue, so I am keeping this open
and maybe we will be able to figure it out at some point.

I hope you don't mind me downgrading this to important.


signature.asc
Description: PGP signature

Bug#1020536: unicorn-engine: FTBFS on s390x: several test failures

[Antonio Terceiro]

Source: unicorn-engine
Version: 2.0.0-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Dear Maintainer,

unicorn-engine fails to build on s390x, with several test failures. It
seems to pass on all other release architectures.

8<8<8<-
FAILED: 26 of 33 unit tests have failed.


25% tests passed, 9 tests failed out of 12

Total Test time (real) =   0.31 sec

The following tests FAILED:
  1 - test_x86 (Failed)
  2 - test_arm (Failed)
  3 - test_arm64 (Failed)
  4 - test_m68k (Failed)
  5 - test_mips (Failed)
  7 - test_ppc (Failed)
  8 - test_riscv (Failed)
 11 - test_mem (Failed)
 12 - test_ctl (Failed)
Errors while running CTest
8<8<8<-

The full build log is available at
https://buildd.debian.org/status/fetch.php?pkg=unicorn-engine=s390x=2.0.0-3=1663852538=0


signature.asc
Description: PGP signature

Bug#1019623: ruby-fog-core: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

Source: ruby-fog-core
Version: 2.1.0-3.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-fog-core with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-fog-core/usr/share/rubygems-integration/all:/tmp/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"fog-core\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-fog-core/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-fog-core/usr/share/rubygems-integration/all:/tmp/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 -w -I"spec" 
> /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
> "./spec/compute/models/server_spec.rb" "./spec/compute_spec.rb" 
> "./spec/connection_spec.rb" "./spec/core/cache_spec.rb" 
> "./spec/core/model_spec.rb" "./spec/core/stringify_keys_spec.rb" 
> "./spec/core/whitelist_keys_spec.rb" "./spec/credentials_spec.rb" 
> "./spec/current_machine_spec.rb" "./spec/fog_attribute_spec.rb" 
> "./spec/formatador_spec.rb" "./spec/identity_spec.rb" 
> "./spec/mocking_spec.rb" "./spec/service_spec.rb" "./spec/storage_spec.rb" 
> "./spec/test_helpers/formats_helper_spec.rb" 
> "./spec/test_helpers/schema_validator_spec.rb" "./spec/timeout_spec.rb" 
> "./spec/utils_spec.rb" "./spec/uuid_spec.rb" "./spec/wait_for_spec.rb" -v
> Run options: -v --seed 11896
> 
> # Running:
> 
> Fog::Attributes::.has_many_identities::with a custom collection 
> class#test_0001_should return an instance of that collection class = 0.00 s = 
> .
> Fog::Compute::Server::#sshable?::when the server is ready::when the 
> ssh_ip_address exists::when called successively::and ssh times out::when ssh 
> eventually succeeds#test_0001_resets the timeout to the initial value = 0.00 
> s = .
> Fog::Service::when creating and mocking is enabled#test_0001_returns mocked 
> service = DEPRECATED: global use of must_be_instance_of from 
> /<>/spec/service_spec.rb:118. Use _(obj).must_be_instance_of 
> instead. This will fail in Minitest 6.
> 0.00 s = .
> Fog::Service::when creating and mocking is 
> enabled#test_0003_ChildOfTestService::Mock has 
> ChildOfTestService::Collections and TestService::Collections mixed in = 0.00 
> s = .
> Fog::Service::when creating and mocking is 
> enabled#test_0002_TestService::Mock has TestService::Collections mixed into 
> the mocked service = 0.00 s = .
> Fog::CurrentMachine::ip_address#test_0002_should remove trailing endline 
> characters = 0.00 s = .
> Fog::CurrentMachine::ip_address#test_0001_should be thread safe = 0.00 s = .
> Fog::Compute::#new::when both Fog::Compute:: and 
> FogCompute exist#test_0001_prefers Fog::Compute:: = 
> 0.00 s = .
> Fog::StringifyKeys::.stringify::when key is a String#test_0001_keeps key as 
> String = 0.00 s = .
> Fog::Attributes::.has_one_identity::should create a setter that 
> accept#test_0001_an id as param = 0.00 s = .
> Fog::Attributes::.has_one_identity::should create a setter that 
> accept#test_0002_a model as param = 0.00 s = .
> Fog::Core::Connection:::path_prefix#test_0002_raises when the 'path' arg is 
> present and this arg is supplied = 0.00 s = .
> Fog::Core::Connection:::path_prefix#test_0001_does not emit a warning when 
> provided this argument in the initializer = 0.00 s = .
> Fog::Attributes::#all_associations::without any association#test_0001_should 
> return all associations empty = 0.00 s = .
> Fog::Service::when created with a Hash#test_0001_raises for required argument 
> that are missing = 0.00 s = .
> Fog::Service::when created with a Hash#test_0007_warns for unrecognised 
> options = 0.00 s = .
> Fog::Service::when created with a Hash#test_0003_removes keys with `nil` 
> values = 0.00 s = .
> Fog::Service::when created with a Hash#test_0006_converts 'false' String 
> values to FalseClass = 

Bug#1019620: ruby-enumerize: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

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

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-enumerize with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-enumerize/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"enumerize\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-enumerize/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 -w -I"test" 
> /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
> "test/activemodel_test.rb" "test/activerecord_test.rb" 
> "test/attribute_map_test.rb" "test/attribute_test.rb" "test/base_test.rb" 
> "test/module_attributes_test.rb" "test/mongo_mapper_test.rb" 
> "test/mongoid_test.rb" "test/multiple_test.rb" "test/predicates_test.rb" 
> "test/rails_admin_test.rb" "test/sequel_test.rb" "test/set_test.rb" 
> "test/value_test.rb" -v
> /usr/share/rubygems-integration/all/gems/activesupport-6.1.6.1/lib/active_support/core_ext/class/subclasses.rb:30:
>  warning: method redefined; discarding old subclasses
> /usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.13.7/lib/nokogiri/version/info.rb:85:
>  warning: possibly useless use of a variable in void context
> /<>/test/activerecord_test.rb:411: warning: assigned but unused 
> variable - document_2
> /<>/test/sequel_test.rb:302: warning: assigned but unused 
> variable - document_2
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:232. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> DEPRECATED: global use of wont_be from test/activerecord_test.rb:233. Use 
> _(obj).wont_be instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_include from test/activerecord_test.rb:234. 
> Use _(obj).must_include instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_be_nil from test/activerecord_test.rb:594. Use 
> _(obj).must_be_nil instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:542. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> DEPRECATED: global use of wont_be from test/activerecord_test.rb:217. Use 
> _(obj).wont_be instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_include from test/activerecord_test.rb:218. 
> Use _(obj).must_include instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_be from test/activerecord_test.rb:290. Use 
> _(obj).must_be instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:468. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:469. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:642. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:643. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> DEPRECATED: global use of must_equal from test/activerecord_test.rb:644. Use 
> _(obj).must_equal instead. This will fail in Minitest 6.
> Run options: -v --seed 3512
> 
> # Running:
> 
> Enumerize::ActiveRecordSupport#test_0014_validates inclusion when using 
> write_attribute with string attribute = 0.01 s = .
> Enumerize::ActiveRecordSupport#test_0048_sets attribute to nil if given one 
> is not valid = 0.01 s = .
> Enumerize::ActiveRecordSupport#test_0043_allows using update_all with values 
> = 0.00 s = .
> 

Bug#1019619: ruby-did-you-mean: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed.

[Antonio Terceiro]

Source: ruby-did-you-mean
Version: 1.2.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-did-you-mean with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.1  
>  │
> └──┘
> 
> /<>/lib/did_you_mean/version.rb:2: warning: already initialized 
> constant DidYouMean::VERSION
> /usr/lib/ruby/3.1.0/did_you_mean/version.rb:2: warning: previous definition 
> of VERSION was here
> GEM_PATH=/<>/debian/ruby-did-you-mean/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -e gem\ \"did_you_mean\"
> 
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-did-you-mean/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=/<>/debian/ruby-did-you-mean/usr/share/rubygems-integration/all:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
>  ruby3.1 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.1 -w -I"test" 
> /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
> "test/core_ext/name_error_extension_test.rb" 
> "test/deprecated_formatter_test.rb" "test/edit_distance/jaro_winkler_test.rb" 
> "test/spell_checker_test.rb" "test/spell_checking/class_name_check_test.rb" 
> "test/spell_checking/key_name_check_test.rb" 
> "test/spell_checking/method_name_check_test.rb" 
> "test/spell_checking/uncorrectable_name_check_test.rb" 
> "test/spell_checking/variable_name_check_test.rb" -v
> /<>/test/spell_checking/variable_name_check_test.rb:61: warning: 
> assigned but unused variable - some_var
> DidYouMean version: 1.2.1
> Run options: -v --seed 22188
> 
> # Running:
> 
> KeyNameCheckTest#test_corrects_hash_key_name_with_fetch = 0.00 s = .
> KeyNameCheckTest#test_corrects_hash_key_name_with_fetch_values = 0.00 s = .
> KeyNameCheckTest#test_corrects_sprintf_key_name = 0.00 s = .
> KeyNameCheckTest#test_corrects_env_key_name = 0.00 s = .
> DeprecatedFormatterTest#test_deprecated_formatter = 0.00 s = .
> SpellCheckerTest#test_spell_checker_corrects_misspells = 0.00 s = .
> SpellCheckerTest#test_spell_checker_excludes_input_from_dictionary = 0.00 s = 
> .
> SpellCheckerTest#test_spell_checker_sorts_results_by_simiarity = 0.00 s = .
> SpellCheckerTest#test_spell_checker_corrects_mistypes = 0.00 s = .
> UncorrectableNameCheckTest#test_message = 0.01 s = F
> MethodNameCheckTest#test_corrections_include_method_from_module = 0.00 s = .
> MethodNameCheckTest#test_does_not_append_suggestions_three_times = 0.00 s = .
> MethodNameCheckTest#test_exclude_methods_on_nil = 0.00 s = .
> MethodNameCheckTest#test_corrections_include_instance_method = 0.00 s = .
> MethodNameCheckTest#test_corrections_include_class_method = 0.00 s = .
> MethodNameCheckTest#test_private_methods_should_not_be_suggested = 0.00 s = .
> MethodNameCheckTest#test_corrections_include_private_method = 0.00 s = .
> MethodNameCheckTest#test_does_not_append_suggestions_twice = 0.00 s = .
> MethodNameCheckTest#test_corrections_when_private_method_is_called_with_args 
> = 0.00 s = .
> MethodNameCheckTest#test_does_not_exclude_custom_methods_on_nil = 0.00 s = .
> NameErrorExtensionTest#test_message = 0.00 s = S
> NameErrorExtensionTest#test_to_s_does_not_make_disruptive_changes_to_error_message
>  = 0.00 s = .
> ClassNameCheckTest#test_corrections = 0.00 s = .
> ClassNameCheckTest#test_corrections_candidates_for_names_in_upper_level_scopes
>  = 0.00 s = .
> ClassNameCheckTest#test_does_not_suggest_user_input = 0.00 s = .
> ClassNameCheckTest#test_names_in_corrections_have_namespaces = 0.00 s = .
> ClassNameCheckTest#test_corrections_include_case_specific_class_name = 0.00 s 
> = .
> ClassNameCheckTest#test_corrections_include_top_level_class_name = 0.00 s = .
> ClassNameCheckTest#test_corrections_should_work_from_within_instance_method = 
> 0.00 s = .
> ClassNameCheckTest#test_corrections_should_work_from_within_instance_method_on_nested_class
>  = 0.00 s = .
> VariableNameCheckTest#test_corrections_include_private_method = (none):61: 
> warning: assigned but 

Bug#1019622: ruby-factory-bot: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: expected NoMethodError with "undefined method 'static_attributes_are_gone' in 'broken' factory\nDid you mean? 's

[Antonio Terceiro]

Source: ruby-factory-bot
Version: 6.2.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-factory-bot with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
>expected NoMethodError with "undefined method 
> 'static_attributes_are_gone' in 'broken' factory\nDid you mean? 
> 'static_attributes_are_gone { \"true\" }'\n", got # method 'static_attributes_are_gone' in 'broken' factory
>Did you mean? 'static_attributes_are_gone { "true" }'
> 
> 
>raise NoMethodError.new(<<~MSG)
>^> with backtrace:
>  # ./lib/factory_bot/definition_proxy.rb:99:in `method_missing'
>  # ./spec/factory_bot/definition_proxy_spec.rb:69:in `block (3 
> levels) in '
>  # ./spec/factory_bot/definition_proxy_spec.rb:71:in `block (2 
> levels) in '
>  # ./spec/factory_bot/definition_proxy_spec.rb:71:in `block (2 levels) in 
> '
> 
> Finished in 0.429 seconds (files took 0.32709 seconds to load)
> 290 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/factory_bot/definition_proxy_spec.rb:66 # 
> FactoryBot::DefinitionProxy#method_missing raises a NoMethodError when called 
> with a static-attribute-like argument
> 
> Randomized with seed 11142
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --pattern spec/\{\*_spec.rb,factory_bot/\*\*/\*_spec.rb\} --format 
> documentation failed
> mv ./.gem2deb.Gemfile.lock Gemfile.lock
> ERROR: Test "ruby3.1" failed: 


The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/17/ruby-factory-bot/ruby-factory-bot_6.2.0-2+rebuild1663007590_amd64-2022-09-12T18:33:11Z.build

To reproduce this, you need ruby-all-dev >= 1:3.0+2.  Depending on when you
read this, this might mean installing ruby-all-dev from experimental, or ir the
transition has alraedy started in unstable, a normal build on unstable should
do it.  If you fail to reproduce, please provide a build log and diff it with
mine so that we can identify if something relevant changed in the meantime.

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

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


signature.asc
Description: PGP signature

Bug#1019621: ruby-excon: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: RuntimeError:

[Antonio Terceiro]

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

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-excon with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
>  RuntimeError:
>  Shared Example Group: "a excon test server" called from 
> ./spec/excon/test/server_spec.rb:22
>  # ./lib/excon/test/plugin/server/puma.rb:12:in `start'
>  # 
> ./spec/support/shared_examples/shared_example_for_test_servers.rb:10:in 
> `block (2 levels) in '
> 
> Finished in 1.38 seconds (files took 0.2012 seconds to load)
> 143 examples, 1 failure
> 
> Failed examples:
> 
> rspec './spec/excon/test/server_spec.rb[1:3:1:2]' # Excon::Test::Server when 
> the web server is puma it should behave like a excon test server starts the 
> server
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --pattern spec/\*\*/\*_spec.rb -c -f doc -r ./spec/spec_helper.rb failed
> ERROR: Test "ruby3.1" failed: 


The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/17/ruby-excon/ruby-excon_0.88.0-1+rebuild1663007570_amd64-2022-09-12T18:32:50Z.build

To reproduce this, you need ruby-all-dev >= 1:3.0+2.  Depending on when you
read this, this might mean installing ruby-all-dev from experimental, or ir the
transition has alraedy started in unstable, a normal build on unstable should
do it.  If you fail to reproduce, please provide a build log and diff it with
mine so that we can identify if something relevant changed in the meantime.

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

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


signature.asc
Description: PGP signature

Bug#1019616: ruby-dalli: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: adduser: Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory

[Antonio Terceiro]

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

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-dalli with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
> adduser: Warning: The home dir /nonexistent you specified can't be accessed: 
> No such file or directory
> invoke-rc.d: could not determine current runlevel
> All runlevel operations denied by policy
> invoke-rc.d: policy-rc.d denied execution of start.
> Setting up libldap-2.5-0:amd64 (2.5.12+dfsg-2+b1) ...
> Setting up intltool-debian (0.35.0+20060710.5) ...
> Setting up libpython3.10-stdlib:amd64 (3.10.7-1) ...
> Setting up dh-autoreconf (20) ...
> Setting up patchutils (0.4.2-1) ...
> Setting up ruby-mail (2.7.1+dfsg1-1.1) ...
> Setting up libjs-jquery-ui (1.13.2+dfsg-1) ...
> Setting up ruby-activemodel (2:6.1.6.1+dfsg-4) ...
> Setting up dh-strip-nondeterminism (1.13.0-1) ...
> Setting up libwww-robotrules-perl (6.02-1) ...
> Setting up dwz (0.14-1) ...
> Setting up groff-base (1.22.4-8) ...
> Setting up libhtml-parser-perl:amd64 (3.78-1) ...
> Setting up libxslt1.1:amd64 (1.1.35-1) ...
> Setting up gpgconf (2.2.39-1) ...
> Setting up libio-socket-ssl-perl (2.075-1) ...
> Setting up gpg (2.2.39-1) ...
> Setting up libpython3-stdlib:amd64 (3.10.6-1) ...
> Setting up gnupg-utils (2.2.39-1) ...
> Setting up libhttp-message-perl (6.37-1) ...
> Setting up ruby-rails-deprecated-sanitizer (1.0.3-3.1+rebuild1658565853) ...
> Setting up libhttp-negotiate-perl (6.01-1) ...
> Setting up gpg-agent (2.2.39-1) ...
> Setting up ruby-globalid (0.6.0-1+rebuild1658566084) ...
> Setting up python3.10 (3.10.7-1) ...
> Setting up ruby-activerecord (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-nokogiri (1.13.7+dfsg-2+rebuild1662922586) ...
> Setting up libhttp-cookies-perl (6.10-1) ...
> Setting up ruby-simplecov-html (0.12.3-2) ...
> Setting up po-debconf (1.0.21+nmu1) ...
> Setting up libhtml-tree-perl (5.07-2) ...
> Setting up libparams-classify-perl:amd64 (0.015-2) ...
> Setting up gpgsm (2.2.39-1) ...
> Setting up python3 (3.10.6-1) ...
> Setting up man-db (2.10.2-3) ...
> Not building database; man-db/auto-update is not 'true'.
> Setting up dirmngr (2.2.39-1) ...
> Setting up libmodule-runtime-perl (0.016-2) ...
> Setting up ruby-simplecov (0.21.2-1.1) ...
> Setting up ruby-loofah (2.18.0-1) ...
> Setting up gpg-wks-server (2.2.39-1) ...
> Setting up ruby-rails-dom-testing (2.0.3-4+rebuild1659020114) ...
> Setting up ruby-activejob (2:6.1.6.1+dfsg-4) ...
> Setting up gpg-wks-client (2.2.39-1) ...
> Setting up libimport-into-perl (1.002005-2) ...
> Setting up libmoo-perl (2.005004-3) ...
> Setting up debhelper (13.9.1) ...
> Setting up ruby-rails-html-sanitizer (1.4.2-2) ...
> Setting up ruby-actionview (2:6.1.6.1+dfsg-4) ...
> Setting up gnupg (2.2.39-1) ...
> Setting up ruby-actionpack (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-sprockets-rails (3.4.1-2+rebuild1659020268) ...
> Setting up ruby-actioncable (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-actionmailer (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-activestorage (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-actiontext (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-actionmailbox (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-railties (2:6.1.6.1+dfsg-4) ...
> Setting up ruby-rails (2:6.1.6.1+dfsg-4) ...
> Setting up libwww-perl (6.67-1) ...
> Setting up devscripts (2.22.2) ...
> Setting up gem2deb (2.0.3) ...
> Setting up liblwp-protocol-https-perl (6.10-1) ...
> Setting up sbuild-build-depends-main-dummy (0.invalid.0) ...
> Processing triggers for libc-bin (2.34-8) ...
> 
> +--+
> | Check architectures 
>  |
> +--+
> 
> Arch check ok (amd64 included in all)
> 
> +--+
> | Build environment   
>  |
> +--+
> 
> Kernel: Linux 5.10.0-16-cloud-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) 
> amd64 (x86_64)
> Toolchain package versions: binutils_2.38.90.20220713-2 dpkg-dev_1.21.9 
> g++-11_11.3.0-6 g++-12_12.2.0-2 gcc-11_11.3.0-6 gcc-12_12.2.0-2 
> libc6-dev_2.34-8 libstdc++-11-dev_11.3.0-6 libstdc++-12-dev_12.2.0-2 
> libstdc++6_12.2.0-2 linux-libc-dev_5.19.6-1
> Package versions: adduser_3.129 apt_2.5.2 auto-apt-proxy_14 autoconf_2.71-2 
> automake_1:1.16.5-1.3 autopoint_0.21-9 autotools-dev_20220109.1 
> base-files_12.2 base-passwd_3.6.0 bash_5.2~rc2-2 binutils_2.38.90.20220713-2 
> binutils-common_2.38.90.20220713-2 
> binutils-x86-64-linux-gnu_2.38.90.20220713-2 bsdextrautils_2.38.1-1 
> bsdutils_1:2.38.1-1 build-essential_12.9 bzip2_1.0.8-5 
> 

Bug#1019618: ruby-delayed-job: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error:

[Antonio Terceiro]

Source: ruby-delayed-job
Version: 4.1.9-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-delayed-job with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
>  Failure/Error:
>expect do
>  yaml = "--- !ruby/struct\nn: 1\n"
>  object = YAML.load(yaml)
>  expect(object).to be_kind_of(Struct)
>  expect(object.n).to eq(1)
>end.not_to raise_error
> 
>expected no Exception, got # unspecified class: Struct> with backtrace:
>  # (eval):2:in `struct'
>  # ./spec/yaml_ext_spec.rb:28:in `block (3 levels) in  (required)>'
>  # ./spec/yaml_ext_spec.rb:26:in `block (2 levels) in  (required)>'
>  # ./spec/yaml_ext_spec.rb:26:in `block (2 levels) in '
> 
> Finished in 1.46 seconds (files took 0.9459 seconds to load)
> 177 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/yaml_ext_spec.rb:25 # YAML autoloads the class of an anonymous 
> struct
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/17/ruby-delayed-job/ruby-delayed-job_4.1.9-1+rebuild1663007476_amd64-2022-09-12T18:31:17Z.build

To reproduce this, you need ruby-all-dev >= 1:3.0+2.  Depending on when you
read this, this might mean installing ruby-all-dev from experimental, or ir the
transition has alraedy started in unstable, a normal build on unstable should
do it.  If you fail to reproduce, please provide a build log and diff it with
mine so that we can identify if something relevant changed in the meantime.

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

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


signature.asc
Description: PGP signature

Bug#1019617: ruby-delayed-job-active-record: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error:

[Antonio Terceiro]

Source: ruby-delayed-job-active-record
Version: 4.1.6-3
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-delayed-job-active-record with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
>  Failure/Error:
>expect do
>  YAML.load(Story.create.to_yaml)
>end.not_to raise_error
> 
>expected no Exception, got # unspecified class: Story> with backtrace:
>  # ./spec/delayed/serialization/active_record_spec.rb:8:in `block (3 
> levels) in '
>  # ./spec/delayed/serialization/active_record_spec.rb:7:in `block (2 
> levels) in '
>  # ./spec/delayed/serialization/active_record_spec.rb:7:in `block (2 
> levels) in '
> 
> Finished in 1.4 seconds (files took 0.51816 seconds to load)
> 101 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/delayed/serialization/active_record_spec.rb:6 # ActiveRecord 
> loads classes with non-default primary key
> 
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed: 


The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/17/ruby-delayed-job-active-record/ruby-delayed-job-active-record_4.1.6-3+rebuild1663007492_amd64-2022-09-12T18:31:33Z.build

To reproduce this, you need ruby-all-dev >= 1:3.0+2.  Depending on when you
read this, this might mean installing ruby-all-dev from experimental, or ir the
transition has alraedy started in unstable, a normal build on unstable should
do it.  If you fail to reproduce, please provide a build log and diff it with
mine so that we can identify if something relevant changed in the meantime.

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

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


signature.asc
Description: PGP signature