Re: Help needed to fix python-coverage-test-runner

[Andrius Merkys]

Hi Andreas,

On 2024-02-23 09:15, Andreas Tille wrote:

I've attempted to fix python-coverage-test-runner in Git since this
package is finally responsible for the failure of vmdb2:

  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 22,
in 
 import imp
ModuleNotFoundError: No module named 'imp'


I had a similar problem. I worked it around by depending on 
python3-zombie-imp, the original code did not require any modifications.


Best,
Andrius

Re: Python 3.11 for bookworm?

[Andrius Merkys]

Hi Simon,

On 2023-01-07 13:24, Simon McVittie wrote:

On Sat, 07 Jan 2023 at 10:23:19 +0200, Andrius Merkys wrote:

If I may, I would as well be grateful if someone could give a look at:

#1023972 [src:python-ase] FTBFS with Python 3.11 due to
pathlib.Path.__enter__() deprecation

I have no idea how to fix this and the upstream is silent.

My first thought on seeing this was: why were Path objects a context
manager in the first place? What would that mean?

Looking at the code in python3.10 and python3.11 pathlib, it seems the
reason this is deprecated is indeed that it didn't make sense:

 def __enter__(self):
 # In previous versions of pathlib, __exit__() marked this path as
 # closed; subsequent attempts to perform I/O would raise an IOError.
 # This functionality was never documented, and had the effect of
 # making Path objects mutable, contrary to PEP 428.
 # In Python 3.9 __exit__() was made a no-op.
 # In Python 3.11 __enter__() began emitting DeprecationWarning.
 # In Python 3.13 __enter__() and __exit__() should be removed.
 warnings.warn("pathlib.Path.__enter__() is deprecated and scheduled "
   "for removal in Python 3.13; Path objects as a context "
   "manager is a no-op",
   DeprecationWarning, stacklevel=2)
 return self

 def __exit__(self, t, v, tb):
 pass

So the solution seems to be that if your package contains this:

 with some_path_object:
 do_stuff(some_path_object)

replace it with:

 do_stuff(some_path_object)

and if it contains:

 with Path(...) as my_path:
 do_stuff(my_path)

replace with:

 my_path = Path(...)
 do_stuff(my_path)

I hope that should be a relatively straightforward change.


Thanks a lot for the hint, this indeed worked. Failure in __enter__() 
threw me off tracks, but now I recall how it is related to 'with' 
construction.


Best wishes,
Andrius

Re: Python 3.11 for bookworm?

[Andrius Merkys]

Hello,

On 2023-01-07 10:05, Andreas Tille wrote:

Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand:

Please share it in this list!


#1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version
#1024031 [src:numba] numba FTBFS with Python 3.11 as supported version


If I may, I would as well be grateful if someone could give a look at:

#1023972 [src:python-ase] FTBFS with Python 3.11 due to 
pathlib.Path.__enter__() deprecation


I have no idea how to fix this and the upstream is silent.

Best,
Andrius

Re: Python 3.11 for bookworm?

[Andrius Merkys]

Hello,

On 2022-12-13 01:51, Graham Inggs wrote:

As this transition is non-blocking (i.e. uploaded packages are able to
migrate ahead of python3-defaults), we could wait for the remaining
bugs to be fixed, or for auto-removal to take its course.  However,
with the bookworm transition freeze only one month away [5], we'd like
to hear from the Python Team within the next week whether they wish to
proceed with Python 3.11 being the only supported version for bookworm
(in which case we will allow python3-defaults to migrate right now)
or, revert the changes in python3-defaults and have Python 3.10 as the
only supported version for bookworm.


Am I right that whichever the choice, there will be only one supported 
Python version in bookworm? I believe there are many packages that will 
FTBFS with Python 3.11 as default (i.e., packages that use only the 
default Python). Was there an attempt to rebuild the archive with that 
setting?



[1] https://bugs.debian.org/1021984
[2] https://release.debian.org/transitions/html/python3.11-add.html
[3] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11=debian-python@lists.debian.org
[4] https://veronneau.org/debian-python-team-2022-sprint-report.html
[5] https://release.debian.org/bookworm/freeze_policy.html
[6] 
https://udd.debian.org/bugs/?release=bookworm=ign=7=7=only=python3.11=debian-python%40lists.debian.org=1=1=id=asc=html#results


Best,
Andrius

Re: Fixing upstream branch after tagging

[Andrius Merkys]

Hi Guðjón,

On 2022-12-05 08:24, Guðjón Guðjónsson wrote:

I am working on eric and I made a mistake while updating the git repository.

Some paths have changed so files were not excluded correctly and now 
upstream and pristine-tar contain jquery*.js files.


How can I remove the files after having tagged?
I read that the pristine-tar branch should be removed [1]. Is that correct?


I would suggest repacking the source package [2] (see starting from 
"Copyright"). Branches 'upstream' and 'pristine-tar' should not be 
modified manually.


1) https://go-team.pages.debian.net/workflow-changes.html 



[2] https://wiki.debian.org/Repacking#Copyright

Hope this helps,
Andrius

Re: Updating pytest

[Andrius Merkys]

Hi,

On 2022-06-08 14:47, Julian Gilbey wrote:
> 1. finalcif: it seems like an update to python3-gemmi has broken this
> package

Yes, this is indeed the case with finalcif. Will report and investigate
it soon.

Best,
Andrius

Re: Updating pytest

[Andrius Merkys]

On 2022-06-07 04:01, Sandro Tosi wrote:
> I would consider pytest a "core" python package, and so a complete
> rdeps rebuild is appropriate

+1. That is what I meant by suggesting ratt-rebuilding all the rdeps.

Best,
Andrius

Re: Updating pytest

[Andrius Merkys]

Hi Julian,

On 2022-06-02 11:23, Julian Gilbey wrote:
> When I updated pytest-mock, I noticed that pytest is somewhat out of
> date and it would be good to upgrade it.  But it's quite a major
> package, and I don't really want to do it without a go-ahead from
> others.
> 
> Perhaps we could upload a newer version to experimental first to see
> what breaks?

I would suggest ratt-rebuilding all reverse dependencies. Could that be
done?

Best,
Andrius

Re: python-cryptography, Rust, and OpenSSL 3.0

[Andrius Merkys]

On 2021-12-02 11:42, Tristan Seligmann wrote:
>> python-cryptography_3.4.8-1_source.changes uploaded successfully to localhost

Great, thanks a lot!

Best,
Andrius

Re: python-cryptography, Rust, and OpenSSL 3.0

[Andrius Merkys]

Hi Thomas,

On 2021-12-01 19:22, Thomas Goirand wrote:
> On 12/1/21 4:05 PM, Andrius Merkys wrote:
>> On 2021-12-01 14:31, Simon Chopin wrote:
>>> TL;DR: Does it make sense to upload the intermediary upstream version
>>> 3.4.8 or rather wait for someone to work on the Rust-based later versions?
>>
>> I would say yes. python-cryptography >= v3.4.6 is needed to update
>> python-autobahn [1]. Thomas Goirand (in CC) said [2] he is already
>> working on python-cryptography, thus it would be best to coordinate
>> uploads with him.
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995431
>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994914#19
> 
> Did ?!? I believe I wrote I was working on python-autobahn, but I have
> to admit I completely failed my duty (busy on other stuff, like Ceph and
> many other RC bug fixing).

I must have misinterpreted your words, sorry. You were indeed talking
about python-autobahn.

> At this point, I believe I must accept NMUs, or at least patches,
> otherwise it will take forever...

OK. I believe I have the update of python-autobahn ready in my fork [3].
I will submit PRs whenever python-cryptography 3.4.8 is uploaded.

[3] https://salsa.debian.org/merkys/python-autobahn

Best,
Andrius

Re: Sphinx theme package naming conventions

[Andrius Merkys]

Hi Dmitry,

On 2021-10-21 14:38, Dmitry Shachnev wrote:
> On Thu, Oct 21, 2021 at 10:26:53AM +0300, Andrius Merkys wrote:
>> Is it OK to follow [1] and stay faithful to upstream name, or should I
>> rename both source and binary packages to match already existing sphinx
>> theme package names?
> I would follow the naming policy and use python3-sphinx-press-theme.

Thanks for suggestion!

Best,
Andrius

Sphinx theme package naming conventions

[Andrius Merkys]

Hello,

I am working to package sphinx_press_theme (ITP bug #996543). According
to Python package naming conventions [1] proper binary package name for
it would be python3-sphinx-press-theme. However, most of sphinx theme
packages seem to be named $THEME_NAME-sphinx-theme (source package),
resulting in names like python3-$THEME_NAME-sphinx-theme (binary
package) [2].

Is it OK to follow [1] and stay faithful to upstream name, or should I
rename both source and binary packages to match already existing sphinx
theme package names?

[1]
https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names
[2]
https://packages.debian.org/search?suite=sid=all=any=sourcenames=sphinx

Best,
Andrius

Re: xlsxwriter: How to change homepage url

[Andrius Merkys]

On 2021-09-15 15:46, Neil Williams wrote:
> https://tracker.debian.org/media/packages/x/xlsxwriter/control-1.1.2-0.2 
> 
> The package does not seem to have a current version control repository.
> 
> That would be a good start. There doesn't seem to be a project in
> salsa.debian.org and it would make things a lot easier when asking for
> help with packaging changes, to have a URL in Salsa.

There seems to be a project for xlsxwriter:

https://salsa.debian.org/python-team/packages/xlsxwriter

However, I am not sure whether this one corresponds to the package on
tracker.debian.org, it also would be great to make sure whether it does.

Best,
Andrius

Re: RFS: pynauty

[Andrius Merkys]

Hi,

On Mon, 2 Aug 2021, 13:35 Torrance, Douglas,  wrote:

> I've recently packaged pynauty [1], which provides a Python interface to
> nauty
> [2] for computing automorphism groups of graphs.
>
> I'm a DM, but this package would be NEW, so I need a sponsor.  Would
> anyone be
> willing to review?
> https://salsa.debian.org/python-team/packages/pynauty
>
> Thanks!
> Doug
>
> [1] https://github.com/pdobsan/pynauty
> [2] https://pallini.di.uniroma1.it/


I'm interested in this package. Therefore I'll happily review and upload it
for you. Just allow me a couple of days to do so.

Best,
Andrius

Re: Remove trac from Debian 11?

[Andrius Merkys]

On 2021-05-10 16:06, Martin wrote:
> On 2021-05-10 14:00, Andrius Merkys wrote:
>> I do not think that slowing down of development is reason serious enough
>> to remove a package which is otherwise fine. Or are there other reasons
>> that I am not aware of?
> 
> I don't have a problem with slow development, but the current
> version is probably not good enough to maintain it for some
> years. I'm optimistic, that in some months or so 1.6.x will
> be released, which should be fine. I'm planning to backport it
> to Debian 11, so that users still can install trac easily.

Thanks for explanation. Makes sense, I agree with your decision.

Best,
Andrius

Re: Remove trac from Debian 11?

[Andrius Merkys]

Hi Martin,

On 2021-05-10 13:35, Martin wrote:
> trac is a long-time Debian package, uploaded first by Jesus
> Climent in 2004. I like the traditional look of Trac and its
> climate-friendly resource usage :-)
> 
> Now, while Trac is still maintained upstream and has been ported
> to Python 3 recently, development slowed down since long and the
> current 1.5.x release series is not yet "there".
> 
> I wonder, whether the package should be part of Debian 11, or
> better miss one stable release and have it in better shape for
> Debian 12.
> 
> If nobody objects, I'll file a bug to keep it out of Debian 11.

I do not think that slowing down of development is reason serious enough
to remove a package which is otherwise fine. Or are there other reasons
that I am not aware of?

Best,
Andrius

Re: upstream python concerns, python3-full package for bullseye

[Andrius Merkys]

On 2021-02-12 16:18, Simon McVittie wrote:
> We have a python3 package already. If I saw a python3 package and a
> python3-core package, I would expect that either they're the same thing,
> or python3-core is a smaller and less fully-featured version of python3.
> 
> Conversely, we already have a python3-minimal package, and I would expect
> python3-core to be larger and more fully-featured than python3-minimal
> (or maybe the same), because by definition if it's minimal then it's
> the least Python you can have. So:
> 
> python3-minimal ≤ python3-core ≤ python3 ≤ python3-full

+1. Exactly how I would understand these names.

Andrius

Re: Transfer cherrytree from DPT to Debian group

[merkys]

Hi Ondřej,

On 2020-10-21 11:44, Ondrej Novy wrote:
> done: https://salsa.debian.org/debian/cherrytree 

Thanks a lot!

Andrius

Re: Transfer cherrytree from DPT to Debian group

[merkys]

Hello Raphael,

On 2020-10-21 11:07, Raphael Hertzog wrote:
> Transferring to another group requires owner rights on both the
> source and the target group, and the "debian" group is owned only
> by the salsa admins so you have to ask their help:
> https://salsa.debian.org/salsa/support/-/issues

Thanks a lot for pointing this out. I will turn to salsa admins for the
transfer.

Best,
Andrius

Transfer cherrytree from DPT to Debian group

[Andrius Merkys]

Hello,

Recently cherrytree [1] has been rewritten from Python to C++, thus it
no longer belongs in DPT. Could someone with adequate permissions
transfer it from DPT to generic Debian group on salsa.d.o?
Alternatively, one could grant me permission to manage cherrytree so as
I could transfer it myself.

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

Thanks,
Andrius

Re: Automatically removing "badges" pictures from README.rst files

[merkys]

Hello,

On 2020-04-09 22:20, Thomas Goirand wrote:
> Therefore, I was wondering if anyone thought about an automated way to
> remove these. Maybe we could have some options for dh_sphinxdoc?

I agree that debhelper should be handling this issue. However, the issue
occurs in packages not using sphinx too, so I feel there should be a
more generic tool.

Lintian-brush is a fine tool, but (correct me if I am wrong) it would
generate a patch excluding badges, and patches require maintenance.

Best,
Andrius

Re: RFS: python-lark

[merkys]

Hi Peter,

On 2020-01-01 22:56, Peter Wienemann wrote:
> It would be great if someone could review the code, provide feedback and
> - once everything looks fine - upload it.

The package looks fine to me - uploaded. Thanks for your contribution!

Best,
Andrius

Re: [packaging] wurlitzer

[merkys]

On 2019-10-21 18:00, Dmitry Shachnev wrote:
> A downside of this debian/watch is that it only sees the latest tarball,
> but not the historic releases.
>
> I think using one of these two pages will be better:
>
> - https://pypi.org/simple/wurlitzer/
> - https://pypi.debian.net/wurlitzer/

Right, these addresses should be used instead. I wasn't aware of that, thanks 
for pointing out.

Best,
Andrius

Re: [packaging] wurlitzer

[Andrius Merkys]

On 2019-10-21 16:29, MARIE Alexandre wrote:
> This one works perfectly fine, thanks a lot for giving me some time to help !

You're welcome :)

Andrius

Re: [packaging] wurlitzer

[Andrius Merkys]

On 2019-10-21 16:15, MARIE Alexandre wrote:
> I tried it as you said but I still get the same error : 

Hmm. The layout on PyPI seems to have changed. Could you try this now?:

version=4
opts="pgpmode=none" \
 https://pypi.python.org/pypi/wurlitzer/ \
 https://files.pythonhosted.org/packages/.*/.*/.*/\
 wurlitzer-([\d\.]+).tar.gz debian uupdate

Re: [packaging] wurlitzer

[Andrius Merkys]

On 2019-10-21 16:01, MARIE Alexandre wrote:
> Thanks for your fast answer, but I made a mistake when I pasted the error 
> from the bash.
>
> Here is the real error (according to the d/watch file I gave you) :

I see. Have you tried the third PyPI watch file example from the manpage of 
uscan?:

 version=4
 opts="pgpmode=none" \
 https://pypi.python.org/pypi/cfn-sphere/ \
 https://pypi.python.org/packages/.*/.*/.*/\
 cfn-sphere-([\d\.]+).tar.gz#.* debian uupdate

Just replace 'cfn-sphere' with the name of your package.

Best,
Andrius

Re: [packaging] wurlitzer

[Andrius Merkys]

Hi Alexandre,

On 2019-10-21 15:47, MARIE Alexandre wrote:
> @PACKAGE@-@ANY_VERSION@(?:_src)?@ARCHIVE_EXT@ debian uupdate

Try putting @ANY_VERSION@ inside parenthesis:

@PACKAGE@-(@ANY_VERSION@)(?:_src)?@ARCHIVE_EXT@ debian uupdate

Hope this helps,
Andrius

Re: Update for pyyaml

[merkys]

Hi Scott,

On 2019-08-05 02:07, Scott Kitterman wrote:
> I'm about to upload an updated pyyaml.  It adds deprecation warnings for 
> unsafe pyyaml usage [1].  If you maintain a package that uses pyyaml, you 
> should check and make sure it is using it in a safe way.  Since it's a 
> warning 
> and not an error, I don't expect the update to actually break thins, but it's 
> a good time to be checking.

Thanks a lot for doing this. I believe #918890 can be closed now.

Package Tracker shows some failing autopkgtests for the rdepends [1]. Am
I right to assume that it's OK to patch these rdepends to use safe
pyyaml reader?

Best,
Andrius

#918890 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918890
[1] https://tracker.debian.org/pkg/pyyaml

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Fwd: Request to join the DPMT

[Andrius Merkys]

Hello,

some time ago I've requested to join DPMT as 'merkys' (DD). I used to have
write access as 'merkys-guest', which could be revoked now.

Best,
Andrius

-- Forwarded message -
From: 
Date: Tue, 16 Apr 2019, 19:24
Subject: Request to join the DPMT
To: 


Hello,

I would like to rejoin the DPMT using my DD account. My new Salsa login
is 'merkys'. The old one, 'merkys-guest', should be removed from the
team. Inside the team I will maintain my Python packages and upload new
ones.

I have read the policy [1] and I accept it.

[1]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Best,
Andrius

Request to join the DPMT

[merkys]

Hello,

two weeks ago I have asked to join the DPMT, but received no response.
Thus I resend my previous e-mail.

I would like to rejoin the DPMT using my DD account. My new Salsa login
is 'merkys'. The old one, 'merkys-guest', should be removed from the
team. Inside the team I will maintain my Python packages and upload new
ones.

I have read the policy [1] and I accept it.

[1]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Best,
Andrius

Re: Help needed with celery/kombu

[merkys]

Hello,

On 2019-04-17 00:59, Brian May wrote:
> I see there in stretch that there is a key in
> debian/upstream-signing-key.pgp, maybe upstream changed their key?

at some point in time signing keys should have been moved to
debian/upstream/signing-key.asc, at least this is what manpage of uscan
2.19.4 says.

Hope this helps,
Andrius

Joining Python Modules team

[Andrius Merkys]

Hello,

I would like to join the Python Modules team. I am preparing a package for 
python-reentry, which I would like to maintain together with the team. My salsa 
login is merkys-guest. I have read and I accept the policy as of 
https://web.archive.org/web/20171211221837/http://python-modules.alioth.debian.org/policy.html,
 since the alioth.debian.org is down.

Thanks,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania