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

2024-04-08 Thread Riccardo Coccioli
Pyparsing upstream finally made the v3.1.2 release the other day with the
fix. So I guess once that lands in unstable it should be ok.


On Sat, Apr 6, 2024 at 12:30 AM Antoine Beaupré  wrote:

> On 2023-07-27 13:04:22, Riccardo Coccioli wrote:
> > I've checked the issue and opened a bug upstream to pyparsing [1] as this
> > is indeed a regression.
> > Running CI on cumin I've also found that pylint is reporting new issues
> > related to pyparsing code, for which I've opened a separate bug upstream
> > [2].
> >
> > [1] https://github.com/pyparsing/pyparsing/issues/502
> > [2] https://github.com/pyparsing/pyparsing/issues/501
>
> Hi!
>
> Thanks for this! It looks like those are fixed upstream, do we need to
> update pyparsing to 3.1.2 to fix this bug or what's the next step?
>
> (upstream 502 is fixed in 3.1.1, in unstable, but 501 is only in
> 3.1.2...)
>
> a.
>
> --
> Sous le projecteur, on ne voit pas les autres.
> - Félix Leclerc
>


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

2023-07-27 Thread Riccardo Coccioli
I've checked the issue and opened a bug upstream to pyparsing [1] as this
is indeed a regression.
Running CI on cumin I've also found that pylint is reporting new issues
related to pyparsing code, for which I've opened a separate bug upstream
[2].

[1] https://github.com/pyparsing/pyparsing/issues/502
[2] https://github.com/pyparsing/pyparsing/issues/501


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

2023-07-27 Thread Riccardo Coccioli
This seems to be caused by the version change of python3-pyparsing
fom 3.0.9-1 in bookworm to 3.1.0-1 in trixie/sid.
At first sight it looks like that this minor version change in pyparsing
has caused some backward incompatibility.

I'll have a look in the next few days at what changed and try to patch
cumin to be compatible with the newer version while maintaining the
existing backward compatibility with pyparsing up to 2.2.0.

On Wed, Jul 26, 2023 at 10:31 PM Lucas Nussbaum  wrote:

> Source: cumin
> Version: 4.2.0-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230726 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
> >  debian/rules build
> > dh build --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:240: python3.11 setup.py config
> > /usr/lib/python3/dist-packages/setuptools/__init__.py:84:
> _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are
> deprecated.
> > !!
> >
> >
>  
> 
> > Requirements should be satisfied by a PEP 517 installer.
> > If you are using pip, you can try `pip install --use-pep517`.
> >
>  
> 
> >
> > !!
> >   dist.fetch_build_eggs(dist.setup_requires)
> > WARNING: The wheel package is not available.
> > running config
> >dh_auto_build -O--buildsystem=pybuild
> > I: pybuild base:240: /usr/bin/python3 setup.py build
> > /usr/lib/python3/dist-packages/setuptools/__init__.py:84:
> _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are
> deprecated.
> > !!
> >
> >
>  
> 
> > Requirements should be satisfied by a PEP 517 installer.
> > If you are using pip, you can try `pip install --use-pep517`.
> >
>  
> 
> >
> > !!
> >   dist.fetch_build_eggs(dist.setup_requires)
> > WARNING: The wheel package is not available.
> > running build
> > running build_py
> > creating /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > copying cumin/__init__.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > copying cumin/cli.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > copying cumin/transport.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > copying cumin/grammar.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > copying cumin/color.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > copying cumin/query.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin
> > creating
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/transports
> > copying cumin/transports/clustershell.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/transports
> > copying cumin/transports/__init__.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/transports
> > creating
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/backends
> > copying cumin/backends/direct.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/backends
> > copying cumin/backends/knownhosts.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/backends
> > copying cumin/backends/__init__.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/backends
> > copying cumin/backends/openstack.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/backends
> > copying cumin/backends/puppetdb.py ->
> /<>/.pybuild/cpython3_3.11_cumin/build/cumin/backends
> >dh_auto_test -O--buildsystem=pybuild
> > I: pybuild base:240: cd
> /<>/.pybuild/cpython3_3.11_cumin/build; python3.11 -m pytest
> /<>/cumin/tests/unit
> > = test session starts
> ==
> > platform linux -- Python 3.11.4, pytest-7.4.0, pluggy-1.2.0
> > rootdir: /<>
> > configfile: pytest.ini
> > plugins: cov-4.1.0, requests-mock-1.9.3
> > collected 416 items
> >
> > ../../../cumin/tests/unit/test_backends.py .
>  [  0%]
> > ../../../cumin/tests/unit/test_cli.py ..
>  [  7%]
> > ../../../cumin/tests/unit/test_color.py .
> [  9%]
> > ../../../cumin/tests/unit/test_grammar.py ...
> [ 12%]
> > ../../../cumin/tests/unit/test_init.py .
>  [ 19%]
> > ../../../cumin/tests/unit/test_query.py 
>  [ 23%]
> > ../../../cumin/tests/unit/test_transport.py 
>  [ 24%]
> > ../../../cumin/tests/unit/backends/test_direct.py ...
> [ 24%]
> > ../../../cumin/tests/unit/backends/test_grammars.py ..F.
>  [ 26%]
> > ../../../cumin/tests/unit/backends/test_knownhosts.py ..
> [ 31%]
> > 
>  [ 32%]
> > ../../../cumin/tests/unit/backends/test_openstack.py 

Bug#924685: RFP: cumin -- An automation and orchestration framework

2022-11-23 Thread Riccardo Coccioli
On Wed, Nov 23, 2022 at 5:15 PM Moritz Mühlenhoff 
wrote:

> Hi Antoine,
>
> [Adding Riccardo Coccioli, my colleague at Wikimedia and the primary
> author of Cumin to CC]
>
> > which makes me wonder: should we drop the debian branch on github and
> > gerrit? or should we (say, debian sponsors) pull changes from you and
> > sync them to salsa?
> >
> > how should we play this long term?
>
> My proposal would be to discard the debian branch on gerrit/github and
> make salsa.debian.org the authoritative repository for Cumin debs (and
> just build backports for apt.wikimedia.org based on the latest version
> on salsa/unstable).
>
> But let's hear from Riccardo on this as well.
>
> Cheers,
> Moritz
>

I'd like to better understand why it would be better/easier to move the
debian branch into salsa instead of leaving it attached to the upstream
project. I'm not that familiar with the whole debian process, so correct me
if I'm missing something obvious.
It would seem to me that leaving the debian branch into the upstream
repository would also allow other distro/users to build their own deb
package using the same config without importing a separate repository.

As for the debian/watch file if you don't mind I would like to upload a
slightly different one that I use for another project as the tags are all
signed and it does work with the new GitHub APIs (see also the recent "Q:
uscan with GitHub" thread in debian-devel).

Thanks both for resuming the work on this!
Riccardo