From yuemeng.gui at gmail.com  Mon May 12 07:27:07 2025
From: yuemeng.gui at gmail.com (Yue Gui)
Date: Mon, 12 May 2025 14:27:07 +0800
Subject: [Pkg-matrix-maintainers] Bug#1105140: matrix-synapse:FTBFS:build
 failed(WorkerLockTest Timeout on riscv64)
Message-ID: <CAM5FbjrZ68W=usq6cRf8ceEiH7Dt9qvsbENGH-f9uiQTnWoy-g@mail.gmail.com>

Source: matrix-synapse
Version: 1.128.0-1
Severity: serious
Tags: FTBFS, patch
User: debian-riscv at lists.debian.org
Usertags: riscv64

Dear matrix-synapse maintainer,
The package matrix-synapse build failed on riscv64.The crucial buildd log
below:
```

=================================== FAILURES ===================================
___________________ WorkerLockTestCase.test_lock_contention ____________________

self = <tests.handlers.test_worker_lock.WorkerLockTestCase
testMethod=test_lock_contention>

    def test_lock_contention(self) -> None:
        """Test lock contention when a lot of locks wait on a single worker"""

        # It takes around 0.5s on a 5+ years old laptop
        with test_timeout(5):
            nb_locks = 500
            d = self._take_locks(nb_locks)
>           self.assertEqual(self.get_success(d), nb_locks)

/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/handlers/test_worker_lock.py:61:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/unittest.py:692:
in get_success
    self.pump(by=by)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/unittest.py:688:
in pump
    self.reactor.pump([by] * 100)
/usr/lib/python3/dist-packages/twisted/internet/task.py:838: in pump
    self.advance(amount)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/server.py:642:
in advance
    super().advance(0)
/usr/lib/python3/dist-packages/twisted/internet/task.py:830: in advance
    call.func(*call.args, **call.kw)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/synapse/util/__init__.py:201:
in wrapped_callback
    callback(*args, **kwargs)
/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/synapse/handlers/worker_lock.py:191:
in _wake_all_locks
    if not deferred.called:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <tests.utils.test_timeout object at 0x3f9e3e74d0>, signum = 14
frame = <frame at 0x3f9bda9560, file
'/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/synapse/handlers/worker_lock.py',
line 191, code _wake_all_locks>

    def handle_timeout(self, signum: int, frame: Optional[FrameType]) -> None:
>       raise TestTimeout(self.error_message)
E       tests.utils.TestTimeout: Test timed out after 5s

/build/reproducible-path/matrix-synapse-1.128.0/.pybuild/cpython3_3.13_matrix-synapse/build/tests/utils.py:424:
TestTimeout

```
The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=matrix-synapse&arch=riscv64&ver=1.128.0-1&stamp=1746950558&raw=0

My solution to this issue:
The `test_lock_contention` test, which simulates high lock contention, is
timing out on RISC-V systems likely due to inherent performance differences
of the architecture compared to more established platforms like x86_64, for
which the current 5-second timeout is calibrated.

To address this without masking potential regressions on other
architectures, I propose to conditionally adjust the timeout duration for
the RISC-V architecture. This is achieved by detecting the architecture
using `platform.machine()` within the test case and applying a more lenient
timeout (e.g., 15 seconds)  specifically for RISC-V.The debdiff patch is in
the attachment.I have tested that locally,and it works well.Please let me
know whether this solution can be accepted.

Gui-Yue
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-matrix-maintainers/attachments/20250512/f232f196/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_matrix-synapse_test_timeout_on_riscv.patch
Type: application/octet-stream
Size: 3275 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-matrix-maintainers/attachments/20250512/f232f196/attachment.obj>

From aerusso at aerusso.net  Mon May 12 13:10:27 2025
From: aerusso at aerusso.net (Antonio Russo)
Date: Mon, 12 May 2025 06:10:27 -0600
Subject: [Pkg-matrix-maintainers] Bug#1105140: Bug#1105140:
 matrix-synapse:FTBFS:build failed(WorkerLockTest Timeout on riscv64)
In-Reply-To: <CAM5FbjrZ68W=usq6cRf8ceEiH7Dt9qvsbENGH-f9uiQTnWoy-g@mail.gmail.com>
References: <CAM5FbjrZ68W=usq6cRf8ceEiH7Dt9qvsbENGH-f9uiQTnWoy-g@mail.gmail.com>
 <CAM5FbjrZ68W=usq6cRf8ceEiH7Dt9qvsbENGH-f9uiQTnWoy-g@mail.gmail.com>
Message-ID: <919431ba-b790-45c9-b35c-5e9200f2c08e@aerusso.net>

On 2025-05-12 00:27, Yue Gui wrote:
> 
> My solution to this issue:
> The `test_lock_contention` test, which simulates high lock contention, is
> timing out on RISC-V systems likely due to inherent performance differences
> of the architecture compared to more established platforms like x86_64, for
> which the current 5-second timeout is calibrated.
> 
> To address this without masking potential regressions on other
> architectures, I propose to conditionally adjust the timeout duration for
> the RISC-V architecture. This is achieved by detecting the architecture
> using `platform.machine()` within the test case and applying a more lenient
> timeout (e.g., 15 seconds)  specifically for RISC-V.The debdiff patch is in
> the attachment.I have tested that locally,and it works well.Please let me
> know whether this solution can be accepted.
> 
> Gui-Yue
> Best Regards
> 

Hello Gui-Yue,

Thanks for identifying this and authoring this patch!  Would you be willing
to submit this to upstream [1]?

Best,
Antonio Russo

[1] https://github.com/element-hq/synapse

From yuemeng.gui at gmail.com  Mon May 12 13:24:38 2025
From: yuemeng.gui at gmail.com (Yue Gui)
Date: Mon, 12 May 2025 20:24:38 +0800
Subject: [Pkg-matrix-maintainers] Bug#1105140: Bug#1105140:
 matrix-synapse:FTBFS:build failed(WorkerLockTest Timeout on riscv64)
In-Reply-To: <919431ba-b790-45c9-b35c-5e9200f2c08e@aerusso.net>
References: <CAM5FbjrZ68W=usq6cRf8ceEiH7Dt9qvsbENGH-f9uiQTnWoy-g@mail.gmail.com>
 <919431ba-b790-45c9-b35c-5e9200f2c08e@aerusso.net>
 <CAM5FbjrZ68W=usq6cRf8ceEiH7Dt9qvsbENGH-f9uiQTnWoy-g@mail.gmail.com>
Message-ID: <CAM5FbjqY98UvSsRkNuBMQEc4LLdRiu2j5_ey2o0hHw3yEc64wg@mail.gmail.com>

Looks good to me.

Antonio Russo <aerusso at aerusso.net>?2025?5?12? ??20:10???

> On 2025-05-12 00:27, Yue Gui wrote:
> >
> > My solution to this issue:
> > The `test_lock_contention` test, which simulates high lock contention, is
> > timing out on RISC-V systems likely due to inherent performance
> differences
> > of the architecture compared to more established platforms like x86_64,
> for
> > which the current 5-second timeout is calibrated.
> >
> > To address this without masking potential regressions on other
> > architectures, I propose to conditionally adjust the timeout duration for
> > the RISC-V architecture. This is achieved by detecting the architecture
> > using `platform.machine()` within the test case and applying a more
> lenient
> > timeout (e.g., 15 seconds)  specifically for RISC-V.The debdiff patch is
> in
> > the attachment.I have tested that locally,and it works well.Please let me
> > know whether this solution can be accepted.
> >
> > Gui-Yue
> > Best Regards
> >
>
> Hello Gui-Yue,
>
> Thanks for identifying this and authoring this patch!  Would you be willing
> to submit this to upstream [1]?
>
> Best,
> Antonio Russo
>
> [1] https://github.com/element-hq/synapse
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-matrix-maintainers/attachments/20250512/327448e5/attachment.htm>

From info at formacionestatal.es  Wed May 14 13:29:02 2025
From: info at formacionestatal.es (Natalia)
Date: Wed, 14 May 2025 14:29:02 +0200
Subject: [Pkg-matrix-maintainers] =?utf-8?q?Informaci=C3=B3n_de_mayo?=
Message-ID: <11e268d50efc4448adc9fbb478ab831e@None>

Buenas tardes

?

?

Os informamos que ya se encuentra abierto el plazo de inscripci?n para los cursos 100% bonificables con cargo al cr?dito de formaci?n 2025.

?

Precis?is que os mandemos la informaci?n para inscribir vuestros empleados en esta convocatoria de abril?

?

Quedamos a la espera de vuestra respuesta.

?

?

Un cordial saludo.

  
  


Lara Mart?nez

Departamento de formaci?n bonificable

?

FOESCO - Formaci?n Estatal Continua  
Empresa inscrita en el Registro de empresas de Formaci?n

?

FOESCO ofrece formaci?n a empresas y trabajadores en activo a trav?s de cursos bonificados por la Fundaci?n Estatal para la Formaci?n en el Empleo (antiguo FORCEM) que gestiona las acciones formativas de FORMACI?N CONTINUA para trabajadores y se rige por la ley 30/2015 de 9 de septiembre. 

?

Darme de baja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-matrix-maintainers/attachments/20250514/957d286c/attachment.htm>