Re: DPT ideas to organize

[Andreas Tille]

Hi,

Am Mon, Jun 17, 2024 at 02:07:55AM -0400 schrieb Louis-Philippe Véronneau:
> > Another
> > question is: what should we do with packages that are not under the
> > team's umbrella but are affecting Python 3.12?

Salvage[2] those packages?

> > On the other hand, we could assess if there are any improvements needed
> > in our tools, such as pybuild, or determine which packages require, for
> > instance, autopkgtests, lintian, etc. Or maybe we can start making short
> > IRC meetings once a week or every two weeks? Experienced members
> > of the team, do you think this is feasible given the DPT workflow? I
> > would like to hear the opinion from the team :-)
> > 
> > 
> > [0] https://deb.li/3T4QN
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025181
> 
> I agree with the points you raise. It's true the DPT isn't a very organised
> entity (although there's much worse teams in Debian :9).

I agree as well (with both ;-) )

> I think more would be possible if we were more organised. Having regular
> meetings would surely help.

Possibly IRC meetings (as far as I know Perl team is doing so) might be
some first step.

> On my side though, I sadly don't have time for that. I'm already part of
> plenty of Teams in Debian (some of which do have regular meetings, like the
> DebConf Videoteam) and I only have so many spoons... If others want to push
> this way, I'll root for you!

+1

> That said, if I had more time, I would probably prioritise reviewing and
> sponsoring more DPT packages, something I haven't done in a while.

I'd also recommend the "advent bug squashing party" done by the Debian
Med team.  We do team wide bug squashing from Dezember 1st - 24th and
everybody tries to squash a personal bug of the day (no matter who is
Uploader of the package).

Kind regards
   Andreas.

[2] https://wiki.debian.org/PackageSalvaging 

-- 
https://fam-tille.de

Re: Handling sponsorship requests by new contributors (was: Request for Python Team assistance in Debian Mentors)

[Andreas Tille]

Am Sun, Jun 16, 2024 at 06:56:51PM +0200 schrieb Peter Wienemann:
> > What we could do if the idea of giving broad commit rights to newcomers
> > poses issues is to create a specific namespace in python-team for
> > newcomers. (then we'd need to have some migration plan and then oh dear)
> 
> I agree with both of you that it would be good to encourage new contributors
> to put their Python packages in the Python team namespace.

ACK.  My personal policy is to sponsor only packages from some team
space in Salsa for various reasons, mainly because:
  1. The sponsee should feel connected to some team to make me as
 sponsor "replaceable" by other team members.
  2. Its way easier if I commit some slight changes to Git myself and
 write extensive commit messages than asking the sponsee to do
 change XY and move it to mentors again.
 
I'm fine with using some sub-namespace (never worked with this in other
teams but it might be appropriate here).

Kind regards
Andreas.

-- 
https://fam-tille.de

Contacting DPT

[Andreas Tille]

Hi,

I'd like to officially contact all our teams to learn about potential
issues that might affect your work.  I would love to learn how you
organise / share your workload.  If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.  I included individuel Uploaders of python3-defaults
package into this contact.  I'm aware that you are not necessarily
identify yourself as DPT members but I think this package is related
and I would love to see you as well in the DebConf BoF (see below) and
if you could also answer my questions below.

Like previous DPLs, I'm open to any inquiries or requests for
assistance. I personally prefer public discussion whenever possible, as
they can benefit a wider audience. You can find a list of contact
options at the bottom of my page on people.d.o[1].

I prefer being offline when I'm away from my keyboard, so I don't carry
a phone. In urgent situations, I can provide the number of my dumb
phone, though it may not always be within reach. Feel free to ping me
via email if I don't respond promptly to ensure I address your concerns.

Please let me know whether I can do something for you.  I'm fine joining
your IRC channel if needed but please invite me in case I should be
informed about some urgent discussion there since I normally do not lurk
on this channel.

I'd also like to inform you that I've registered a BoF for DebConf24 in
Busan with the following description:

  This BoF is an attempt to gather as much as possible teams inside
  Debian to exchange experiences, discuss workflows inside teams, share
  their ways to attract newcomers etc.

  Each participant team should prepare a short description of their work
  and what team roles (“openings”) they have for new contributors. Even
  for delegated teams (membership is less fluid), it would be good to
  present the team, explain what it takes to be a team member, and what
  steps people usually go to end up being invited to participate. Some
  other teams can easily absorb contributions from salsa MRs, and at some
  point people get commit access. Anyway, the point is that we work on the
  idea that the pathway to become a team member becomes more clear from an
  outsider point-of-view.

I'm sure not everybody will be able to travel this distance but it would
be great if you would at least consider joining that BoF remotely.  I'll
care for a somehow TimeZone aware scheduling - if needed we'll organise
two BoFs to match all time zones.  I'm also aware that we have pretty
different teams and it might make sense to do some infrastructure
related BoF with your team and other teams that are caring for Debian
infrastructure.

I have some specific questions to the Debian Python team.  I'm really
interested into individual answers from single contributors either here
on this list or in private.

  - Do you feel good when doing your work in Debian Python team?
  - Do you consider the workload of your team equally shared amongst its
members?
  - Do you have some strategy to gather new contributors for your team?
  - Can you give some individual estimation how many hours per week you
are working on your tasks in youre team?  Does this fit the amount of
time you can really afford for this task?
  - I guess you will have your regular DPT meeting at DebConf (which I
intend to join).  What do you think about the general team meeting
I registered.
  - In the beginning of this year there was a change in the policy of DPT.
I'd like to hear your opinion about:
 * The process how it went (possibly with suggestions to do better)
 * The final result after a couple of months
(I'm specifically interested also in the opinion of people who were
 not happy about the change.)
  - Since a long time we try to migrate from Python3.11 to Python3.12.
 * What are your thoughts about the transition process?
 * Can you identify some blockers?
 * Do you have some suggestions for enhancements of this process?
  - Can I do anything for you?


Kind regards and thanks a lot for your work
   Andreas.


[1] https://people.debian.org/~tille/

-- 
https://fam-tille.de


signature.asc
Description: PGP signature

Re: DebConf24 Sprint & BoF!

[Andreas Tille]

Am Thu, Apr 25, 2024 at 02:23:27PM + schrieb Stefano Rivera:
> Hi Louis-Philippe (2024.04.25_13:58:42_+)
> > I've taken the liberty of submitting the annual Python BoF for DebConf24. If
> > you have ideas of what we should talk about, please add them to this
> > (temporary? the dc24.pad instance isn't up yet) pad:
> 
> It's alive!
> 
> https://pad.dc24.debconf.org/p/python-team-bof
> https://pad.dc24.debconf.org/p/python-team-sprint

I'll arrive in Busan at 2.8. evening and I'll happily join DPT sprint. 

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: O: pychm -- Python binding for CHMLIB - Python 3

[Andreas Tille]

Hi,

Am Tue, Apr 23, 2024 at 09:02:41AM +0900 schrieb yokota:
> Debian pychm was updated.

Good job.

> I can't upload the new package because I don't have upload rights.
> Please upload the new package by someone in debian-python who has upload 
> rights.

In case you might become Debian Maintainer we could grant you
upload permissions for the packages you are maintaining.

Kind regards
   Andreas. 

-- 
https://fam-tille.de

Re: request for removal of my packages from the DPT namespace

[Andreas Tille]

Hi,

Am Tue, Apr 16, 2024 at 11:21:51AM +0200 schrieb Jeroen Ploemen:
> Jeroen Ploemen  wrote:
> > please delete the following packages from the DPT namespace on
> > salsa:
> > 
> > cheetah
> > jaraco.classes
> > jaraco.collections
> > jaraco.context
> > jaraco.text
> > nfoview
> > ply
> > puremagic
> > python-autocommand
> > python-jaraco.functools
> > python-portend
> > python-rarfile
> > python-tempora
> > python-yenc
> > sabctools
> > sabnzbdplus
> > 
> > All of these have already been mirrored into my personal namespace
> > to keep a public VCS available, while gaining at least some
> > protection against ongoing policy violations.

Not that I would have permissions to remove any repositories in DPT but
I've just checked

$ apt showsrc cheetah 2>/dev/null | grep Vcs-Git
Vcs-Git: https://salsa.debian.org/python-team/packages/cheetah.git

I would not remove anything that is referenced from package metadata.
I realised 

$ apt showsrc sabnzbdplus 2>/dev/null | grep Vcs-Git
Vcs-Git: https://salsa.debian.org/jcfp/sabnzbdplus.git

so here the DPT repository is probably misleading.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Bug#1065221: O: py7zr -- pure Python 7-zip library

[Andreas Tille]

Hi Hiroshi,

Am Mon, Apr 08, 2024 at 08:34:23AM +0900 schrieb yokota:
> > When writing this I'm wondering whether it might be better to remove
> > this in Files-Excluded.  On one hand this saves us from mentioning the
> > copyright on the other hand we could be really sure that it is not used.
> > What do you think - should I override the previous upload without that
> > code copy?  I did not wanted to be too invasive with your packaging
> > but I would have done so in my packages.
> 
> Thanks for your suggestion.
> I was dropped embedded library code from brotlicffi

I commited a change to d/changelog.  In case ftpmaster might accept what
currently is in new queue we need to mention this.  Alternatively I
could push the new version to new since as far as I know ftpmaster can
cope with this.  However, I do not see any urgent need for this.  We can
rather upload your change in the source-only upload after the package
might have been accepted.  In case it will not be accepted we can change
d/changelog accordingly.

> and pyzstd, and push
> them to salsa.debian.org repository.
> 
> I was also fix some copyright issues.

Fine.  I've uploaded python-pyppmd and python-pyzstd to new.  Please
read my commit logs for python-pyzstd. 

Thanks a lot for all your work and ping here on this list if you need
further sponsoring help.

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Bug#1065221: O: py7zr -- pure Python 7-zip library

[Andreas Tille]

Hi again,


Am Sun, Apr 07, 2024 at 11:54:00AM +0900 schrieb yokota:
> Hello,
> 
> I think these packages are now ready for upload to NEW queue.
> Please examine them.
> 
> https://salsa.debian.org/python-team/packages/python-brotlicffi

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#47 where I
forgot to CC Debian Python list.

> https://salsa.debian.org/python-team/packages/python-inflate64

Uploaded as well.  I had to strip d/changelog and fixed the spelling of
"python" in description.  Please verify this for the next two packages.
I've also spotted third party code which was not mentioned in
d/copyright.

I'd recommend to do some

   grep -Ri copyright 

in your source tree to have a rough information about code that is
possibly missing in d/copyright.  Otherwise the package will be rejected
by ftpmaster.

> https://salsa.debian.org/python-team/packages/python-pyppmd
> https://salsa.debian.org/python-team/packages/python-pyzstd

Thanks a lot for your work in any case
Andreas. 

-- 
https://fam-tille.de

Adopting pychm (Was: Packaging multivolumefile?)

[Andreas Tille]

Hi Hiroshi,

Am Sat, Apr 06, 2024 at 02:51:51AM +0900 schrieb yokota:
> Thanks a lot for your detailed document.

You are welcome.

> I will try to fixup other packages.

Just ping me once done.

> PS:
> If py7zr is done, I will also try package pychm to use for Debian
> Calibre package.
> Please sponsor me for pychm package if you have time.

I'll try in any case.  It should be some change of maintainer
+ close bug and - as I'd recommend - some

routine-update -f

away.

Just let me know once you are ready

  Andreas.

> > O: pychm -- Python binding for CHMLIB - Python 3
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065222
> 
> --
> YOKOTA Hiroshi
> 

-- 
https://fam-tille.de

Re: Packaging multivolumefile?

[Andreas Tille]

Hi Yokota,

Am Tue, Apr 02, 2024 at 08:39:36PM +0200 schrieb Andreas Tille:
> > Nevermind, YOKOTA Hiroshi already has done this and more and is looking
> > for sponsors.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17
> 
> Thanks a lot for your packaging work.  My very personal sponsoring
> policy is that I sponsor only team maintained packages.  If you move
> your packages to DPT I'll happily sponsor your work. 

Thanks a lot for all your work on the said pre-requisites and moving
them to DPT.  For the moment I've picked python-multivolumefile and
python-bcj and uploaded them to New queue.  My sponsoring style is to do
additional commits trying to be as verbose as possible to tell the
sponsee what to change and why.  I hope you like this.  When looking
at these two packages I've noticed a pattern of changes that were needed
to fix lintian info messages.  Please make sure to run

   lintian -I PACKAGE_VERSION_amd64.changes

to learn about what changes might be sensible to silence lintian.
Some of them where cosmetic but I try to fix these to make sure the
lintian output is not too noisy and I might miss something that
might really need fixing.  I'd also recommend:

$ grep -v ^# ~/.lintianrc 
color=always
display-info=yes

I hope my commits are sensible to you - if not please ask back.

As a general remark:  In those teams I'm more involved we have the
tradition that sponsees leave the distribution in d/changelog to
UNRELEASED while the sponsor changes this to unstable before the final
upload.  This helps team members to immediately know about the status.
I'd be happy if you would follow this as well.

Please verify that your other packages are fixing the things I
commited to the two example packages.  If time permits I'd happily
sponsor you other packages (if nobody else in the team will beat
me in doing so).

Thanks again for all your work
   Andreas.

-- 
https://fam-tille.de

Re: Packaging multivolumefile?

[Andreas Tille]

Hi Yokota,

Am Sat, Mar 30, 2024 at 06:31:54PM +0100 schrieb Andreas Metzler:
> On 2024-03-30 Andreas Metzler  wrote:
> > I originally intended to file an ITP, but it probably makes more sense
> > to ask here:
> 
> > py7zr >= 0.16.0 requires multivolumefile by the same author. How about
> > packaging it under the debian-python umbrella?
> 
> Nevermind, YOKOTA Hiroshi already has done this and more and is looking
> for sponsors.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17

Thanks a lot for your packaging work.  My very personal sponsoring
policy is that I sponsor only team maintained packages.  If you move
your packages to DPT I'll happily sponsor your work. 

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: Docu: Need help to understand section about package creation

[Andreas Tille]

Hi,

Am Thu, Mar 28, 2024 at 11:45:36PM -0400 schrieb Boyuan Yang:
> 
> I don't have a good solution to Wiki pages yet since the article logic
> needs some major editing.

I can't provide any help for the Wiki page for DPMT.  In Debian Med we
provide some resources for newcomers:

  Mentoring of the Month:

https://salsa.debian.org/med-team/community/MoM/-/wikis/Mentoring-of-the-Month-(MoM)

  Debian Med policy is more verbose about packaging details
https://med-team.pages.debian.net/policy/


Perhaps a hint to my Live packaging workshop

https://debconf23.debconf.org/talks/34-live-packaging-workshop/

might be helpful as well.  I did more of these[1] - unfortunately not
all recordings are available.

Kind regards
Andreas.

[1] https://people.debian.org/~tille/talks/other_en.html

-- 
https://fam-tille.de

Re: Updated package list with packages open for adoption (Was: morph's abandoned packages (list))

[Andreas Tille]

Hi Emmanuel,

Am Thu, Mar 28, 2024 at 11:38:47AM -0300 schrieb Emmanuel Arias:
> 
> With this we cover all packages? I'm asking because I'm looking other list
> with more packages [0]

This is where I started from.  What package are you missing in the updated list?
 
> On 3/28/24 6:24 AM, Andreas Tille wrote:
> 
> > ? #1065246 O: contourpy -- Python library for calculating contours of 2D 
> > quadrilateral grids
> >  rdepends: python3-matplotlib
> >Taken by alexandre.deti...@gmail.com, deba...@debian.org
> oops! sorry! I've just make an upload adopting this package before read this
> mail, please add you as Uploaders. I did not package new upstream release
> because it is a matplotlib dependency. My plan was upload new upstream
> version to experimental, but I prefer wait for tchet and debacle opinion.
> Sorry again.

IMHO, matplotlib deserves more than two uploaders - se yes, please
everybody who likes to work on the package add your ID.
 
> > ? #1065224 O: mysql-connector-python -- pure Python implementation of MySQL 
> > Client/Server protocol
> >  ??> Emmanuel Arias  - I did not fully understood
> >  whether you want to take this.
> >  In the light of the discussion of bug #923347 I wonder whether we need
> >  this package.  Its not part of any stable release listed at tracker.d.o
> Yes, I will add myself as uploader right now, but I will leave this package
> in unstable only because is a dependency of mysql-workbench.

Thank you for the explanation.

Kind regards
Andreas.

> [0] https://lists.debian.org/debian-python/2024/03/msg00045.html

-- 
https://fam-tille.de

Updated package list with packages open for adoption (Was: morph's abandoned packages (list))

[Andreas Tille]

Hi,

I'd like to update the list with names if someone has annouced to take
over.  For packages with no takers I checked rdepends and kept their
Uploaders in CC (please seek for your email in case you do not understand
why you are in CC).

Emmanuel Arias in CC due to some private mail mentioning some packages

Am Thu, Mar 14, 2024 at 06:20:11AM + schrieb Julian Gilbey:
> Removal requested:
> 
  #1066146 RM: flask-basicauth -- ROM; RC buggy, dead upstream, leaf package
--> removal seems to be sensible in any case

  #1065141 RM: gmplot -- ROM; leaf package
  #1064947 RM: nb2plots -- ROM; leaf package
  #1065200 RM: overpass -- ROM; leaf package
==> all by Alexandre Detiste  

? #1065199 RM: pprintpp -- ROM; leaf package
Do we need this package?

? #1065045 RM: pyannotate -- ROM; leaf package
Last upstream release was tagged in Sept 2019
The code contains some references to lib2to3 which triggers
  DeprecationWarning: lib2to3 package is deprecated and may not be able to 
parse Python 3.10+
This might be one reason for bug #1058419 since it could spoil the output
Do we need this package?

  #1065201 RM: python-overpy -- ROM; leaf package
--> Alexandre Detiste 

  #1065202 RM: python-ppmd -- ROM; leaf package
  #1064946 RM: sphinx-a4doc -- ROM; leaf package
==> all by ti...@debian.org
> 
> Recently-orphaned packages (removing those in wnpp which have been
> retitled "ITA") sorted alphabetically; these could, of course, be
> brought into team maintenance.
> 
  #1065235 O: basemap -- matplotlib toolkit to plot on map projections
--> ti...@debian.org
  + eam...@yaerobi.com

  #1065243 O: colorspacious -- library for doing colorspace conversions
--> emoll...@debian.org

? #1065151 O: commonmark -- Python parser for the CommonMark Markdown spec
rdepends: python3-recommonmark (Uploader Jerome Benoit 
)
  python3-orange-canvas-core (Uploader 
   Debian PaN Maintainers 
,
   Roland Mas )

? #1065246 O: contourpy -- Python library for calculating contours of 2D 
quadrilateral grids
rdepends: python3-matplotlib
  Taken by alexandre.deti...@gmail.com, deba...@debian.org

? #1065248 O: cppy -- C++ headers for (Python) C extension development
rdepends: kiwisolver (see below, not taken yet)

  #1065139 O: dot2tex -- Graphviz to LaTeX converter
   --> dtorra...@piedmont.edu

  #1065140 O: fastkml -- fast KML processing
   --> ti...@debian.org

  #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 
specification
   --> mich...@fladi.at

? #1065244 O: kiwisolver -- fast implementation of the Cassowary constraint 
solver
Build-Dep: geophar (Maintainer: Georges Khaznadar )
   turing (Georges Khaznadar )
   python3-vispy (debian-science-maintain...@lists.alioth.debian.org
  Ghislain Antony Vaillant )
   python3-matplotlib (Taken by alexandre.deti...@gmail.com, 
deba...@debian.org) 


? #1065238 O: lazy-object-proxy -- Python 3 fast and thorough lazy object proxy
Build-Dep: astroid (Maintainer: Jonas Smedegaard )

? #1065037 O: m2crypto -- Python wrapper for the OpenSSL library
rdepends: several (skipping the list of related maintainers
  while hoping this will be picked up)

  #1065325 O: matplotlib -- Python based plotting system
   --> alexandre.deti...@gmail.com
 + deba...@debian.org

  #1065143 O: mkautodoc -- AutoDoc for MarkDown
   --> Antonio Terceiro 

  #1065042 O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python 
library
   --> ti...@debian.org (rdepends in Debian Med team)
 Updating to latest upstream depends from pydata-sphinx-theme (see at 
bottom)
 which in turn needs a new dependency which I will not package.  Thus help
 is welcome

  #1065220 O: mpmath -- library for arbitrary-precision floating-point 
arithmetic
--> dtorra...@piedmont.edu

? #1065224 O: mysql-connector-python -- pure Python implementation of MySQL 
Client/Server protocol
??> Emmanuel Arias  - I did not fully understood
whether you want to take this.
In the light of the discussion of bug #923347 I wonder whether we need
this package.  Its not part of any stable release listed at tracker.d.o

  #1065198 O: networkx -- tool to create, manipulate and study complex networks
--> tho...@goirand.fr  (in OpenStack team)
  + roehl...@debian.org

  #1065329 O: numpy -- Fast array facility to the Python 3 language
--> roehl...@debian.org
  + c...@debian.org

? #1065221 O: py7zr -- pure Python 7-zip library
   rdepends: recoll (Kartik Mistry )
 calibre (YOKOTA Hiroshi ,
  Martin Pitt ,
  Nicholas D Steeves )
  Hint: This package is lagging quite behind upstream
  Latest upstream needs https://github.com/miurahr/multivolume
  However:
  This repository has been archived by the owner on Jul 17, 2022. It is 

Re: Wiki: Setup the environment, e.g. "salsa" script / Request to review modified docs

[Andreas Tille]

Am Wed, Mar 20, 2024 at 11:04:41AM + schrieb c.bu...@posteo.jp:
> Sorry, guys but I don't understand nearly nothing of what you explain here
> because I don't know the tool chain nor the process. But I hope you all do.
> 
> I modified the section:
> https://wiki.debian.org/Python/GitPackaging#Policies
> 
> Feel free to improve my modification.

IMHO the best fit is:

- * '''Patch management regime''': The Debian Python team has chosen `gbp pq`. 
But it is also possible to use `quilt`.
+ * '''Patch management regime''': The Debian Python team recommends `gbp pq` 
as interface to `quilt` patches.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Re: Wiki: Setup the environment, e.g. "salsa" script / Request to review modified docs

[Andreas Tille]

Hi Brian,

Am Wed, Mar 20, 2024 at 10:59:34AM +1100 schrieb Brian May:
> Andreas Tille  writes:
> 
> > As someone who touched a lot of packages (>2000) I've always used quilt
> > successfully and have seen quilt patches used by the majority of all
> > those packages.  This is not only true for DPT than generally in Debian.
> > Considering quilt as not recommended is definitely not matching the
> > reality and should not be written in Wiki.
> 
> gbp pq is just another way of quilt patches. The debian/patches written
> by gbp pq are compatable with quilt. The patches written to by quilt can
> be read using gbp pq import.
> 
> While gbp pq has a patch queue stored in git, you probably don't want to
> push this to a shared repo.
> 
> But: If you create patches with quilt, and then import and export them
> using gbp pq you might find that gbp pq wants to make minor/trivial
> changes to the unchanged patch files. Which can be irritating when
> making security patches, etc. Maybe this is why the practise is not
> recommended?

Thanks a lot for the explanation.  So the Wiki should be changed in this
direction it should include this explanation.  In any case creating the
impression quilt should not be used does not reflect reality.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Re: Wiki: Setup the environment, e.g. "salsa" script / Request to review modified docs

[Andreas Tille]

Hi,

Am Tue, Mar 19, 2024 at 11:48:47AM + schrieb weepingclown:
> Improving docs is a very important thing, I appreciate your effort.

+1
 
> I quickly went through thr diff off your changes and it seems that you've 
> changed the wiki to mention that using quilt is not recommended. While gbp pq 
> is what the python team prefers indeed, the python team policy does not 
> prevent quilt usage and instead mentions explicitly that optionally quilt can 
> be used. As such, I do not find mentioning "using quilt is not recommended" 
> appropriate as it has the connotation "you should not use quilt". As someone 
> who takes advantage of the policy leniency and find quilt easier than gbp pq, 
> I thought this has to be mentioned.

As someone who touched a lot of packages (>2000) I've always used quilt
successfully and have seen quilt patches used by the majority of all
those packages.  This is not only true for DPT than generally in Debian.
Considering quilt as not recommended is definitely not matching the
reality and should not be written in Wiki.

> Once again, improving the wiki is a great thing to do. Please keep up the 
> good work :)

+1

Kind regards
   Andreas.

> Best,
> Ananthu
> 
> On 19 March 2024 10:47:07 am UTC, c.bu...@posteo.jp wrote:
> >Hello together,
> >
> >I still struggle with the docs but also improving them.
> >
> >First of all please review my modifications to make sure there are no 
> >misleading errors in the content. I restructured the "Policy" section [1]. I 
> >shortened and rephrased the text. I also added a sub section "Setup and 
> >configure the system" with missing details.
> >
> >I think in the long run I will add setup information to 
> >https://wiki.debian.org/Salsa and link to it from Python/GitPackaging wiki 
> >page.
> >Please see my Salsa related questions in the other thread.
> >
> >As a side note: There is an open discussion at MoinWiki to improve the 
> >handling of headings and page titles [2]. The later should not be part of 
> >the TOC.
> >
> >Best Regards,
> >Christian Buhtz
> >
> >[1] -- 
> >[2] -- 
> >

-- 
http://fam-tille.de

Re: #1066146 RM: flask-basicauth (Re: morph's abandoned packages (list))

[Andreas Tille]

Hi Carsten,

sorry for occupying your time such a long and detailed answer.  I simply had
seen a conflict in your

   I see no real issues to drop
   This horse is long dead

which was surely simply a typo.  I personally agree with the dead horse.

I'm CCing your long explanation to the bug to make sure it has finally
some positive use.

Kind regards
Andreas.

Am Tue, Mar 19, 2024 at 07:06:18AM +0100 schrieb Carsten Schoenert:
> Hello Andreas,
> 
> Am 18.03.24 um 21:15 schrieb Andreas Tille:
> > Hi Carsten,
> > 
> > Am Sun, Mar 17, 2024 at 08:18:58AM +0100 schrieb Carsten Schoenert:
> > > > The arguments to remove  flask-basicauth looks sensible, can someone 
> > > > confirm ?
> > > 
> > > looking at the upstream situation for flask-basicauth I see no real issues
> > > to drop and this package from the archive. This horse is long dead for a
> > > long time.
> > 
> > This sentence looks as if would have been created by autocomplete function.
> > Could you please try to rephrase for better understandability?
> 
> well, it's getting harder to maintain upstream source that is simply not
> maintained anymore by the original upstream author or group. flask-basicauth
> is one of these cases. The last action by upstream is now 8 years old!
> 
> https://github.com/jpvanhal/flask-basicauth
> 
> There is no feedback from upstream on bug reports since years. I'm writing
> bug reports in such cases sometimes mainly only to show the problems we or I
> have discovered in a hope that other will post than how they solved this
> issue.
> 
> And of course also upstream is not reacting on created PRs. I've given up to
> write new and further PRs in such cases, it's a waste of time.
> 
> Doing the needed maintenance for such old repositories is often difficult
> and time consuming, e.g. dealing with old build systems or the test setup.
> I'm primarily a package maintainer not a person that is having fun to update
> or adjust old trees with a 5th possible solution. It's not helpful and wise
> if every distro is doing the same with lots of energy. It's not our
> responsibility to keep every source package alive in the archive if upstream
> has moved away, at least this is my thinking.
> 
> We have more and more the problem to manage big transitions like the usual
> Python major updates, or big frameworks like Sphinx, PyTest, Django etc.
> I've spend a lot of time with rather old and not really maintained anymore
> by upstream packages in the past year.
> We can't deal with all the challenges that will need some action all other
> the time. But shipping then outdated or not really useful packages within a
> release is not something we should do. Sometimes it's better to drop such
> packages from the archive and shift time and energy to other packages.
> 
> And to me flask-basicauth is such a package. It's dead Jim!
> 
> -- 
> Regards
> Carsten
> 
> 

-- 
http://fam-tille.de

Re: Suggesting change in DPT Policy

[Andreas Tille]

Hi Julian,

Am Sat, Mar 09, 2024 at 09:21:40PM + schrieb Julian Gilbey:
> Following on from some earlier discussions, I've been thinking about
> the relationship between the DPT (presumably a group of developers who
> work together) and salsa (could there be packages in the
> python-team/packages area which are not team maintained?).  I reread
> much of the policy at
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and discovered something quite strange.  The introduction begins:
> 
> ---
> [Old version stripped]
> ---
> 
> If the DPT is a team (a group of maintainers/developers/helpful
> others), what does "The DPT is hosted at salsa" mean - how can a
> "team" be hosted?  (And in the first paragraph, "maintained by a team"
> seems a little strange too.)
> 
> Perhaps something like the following would be better (shifting the
> focus from the tools to the people), and would also separate concerns
> more clearly:

I like this shift.

> ---
> Introduction:
> 
> The Debian Python Team (DPT) is a group of maintainers who are jointly
> responsible for a large number of Python packages in Debian.  They
> package and support available Python modules and applications that may
> be useful.
> 
> By using a central location on salsa.debian.org, the Debian GitLab
> instance, for these team-maintained packages, the DPT are able to
> improve responsiveness, integration, and standardization.
> ---

I think it makes sense if you create some MR for the suggested change.

> Then the details of how to mark a package as being team-maintained can
> be left to the Maintainership section.
> 
> We could then include a statement along the lines of the following
> (though I'm not sure where would be best):
> 
> ---
> Python module packages which are not team-maintained by the DPT can
> also be stored in the python-team/packages namespace on salsa in order
> to benefit from the integration and standardization tools such as
> Janitor.  Manual changes to these packages by someone other than the
> package's maintainer should be proposed via salsa merge requests or
> comments in the BTS (or using NMUs if appropriate) as for any other
> individually-maintained package.
> ---

I see the advantage of having all Python packages in a common name space
on Salsa.  However, I fail to see the advantage of individually
maintained packages in Debian in general.  The discussion here did not
really contained arguments convincing me about the need for individual
maintainership.  Well, for sure we have maintainers of very high
competence for specific packages and it is good to consult these before
doing some upload.

The suggsted solution was to add some debian/README.to_be_decided_ext.
I confirm that bumping to a new upstream version might be harmful in
certain cases and there are packages where this should not be done
without confirmation of one of the persons specified in the Uploaders
field.  To my experience these packages are an exception - most packages
that where lagging behind upstream are harmless.

In general I would consider it sensible that *any* team member has
permission to

  1. Add autopkgtest
  2. Fix bugs (no matter about severity)
  3. Fix lintian issues
  4. Upload Janitor changes

by doing

  dch --team

marked cangelog entry.  We have made good experiences with this (not
even written) policy in Debian Med.  Well, in real practice it does not
happen *that* frequently that maintainers have so much time and energy
to crawl the package pool seeking for chances of enhancements (even if I
wished this would be the case).  Thus I suggest to lower the barrier to
do so to a sensible minimum.  Adding some
debian/README.to_be_decided_ext (debian/README.source which is
established and documented) mentioning potential pitfalls should be
sufficient to warn a team member driven by good intentions (and I assume
this is the case for any team member).
 
> It would be good to say something about Uploaders in the
> Maintainership section.  Perhaps something like this:
> 
> ---
> A package maintained within the team must have the name of the team in
> the Maintainer field:
> 
> Maintainer: Debian Python Team 
> 
> This enables the team to have an overview of its packages on the
> DDPO_website.
> 
> If a particular developer wishes to take primary responsibility for a
> package, they should put their name in the Uploaders field.  [*** What
> does this mean though?  Maybe something like: In this case, any DPT
> member is still welcome to make changes to the package, though it is
> polite to contact the developer(s) named in the Uploaders field
> first. ***]

To my experience an Uploader does not respond to say some RC bug due to
time constraints.  Asking and waiting for a time constrained person
might be just another ping that drains time from this person.  For sure
the some imagined bug report in question might just be overlooked and
such a ping might trigger immediate responce.  On the other hand I
experienced 

Re: #1066146 RM: flask-basicauth (Re: morph's abandoned packages (list))

[Andreas Tille]

Hi Carsten,

Am Sun, Mar 17, 2024 at 08:18:58AM +0100 schrieb Carsten Schoenert:
> > The arguments to remove  flask-basicauth looks sensible, can someone 
> > confirm ?
> 
> looking at the upstream situation for flask-basicauth I see no real issues
> to drop and this package from the archive. This horse is long dead for a
> long time.

This sentence looks as if would have been created by autocomplete function.
Could you please try to rephrase for better understandability?

Thank you
   Andreas.

-- 
http://fam-tille.de

Re: Would you agree with swapping Maintainer and Uploaders in eric?

[Andreas Tille]

Control: tags -1 pending
thanks

Hi again,

since I know you from Debian Science team and you are usually
comfortable with setting Maintainer to the team I've done so
besides fixing the bug and polished the package a bit.  I also
upgraded to the latest upstream version.

Please confirm that this all is OK before I upload (feel free
to upload yourself which is perfectly fine for me).

Kind regards
Andreas.

Am Mon, Mar 11, 2024 at 10:13:50PM +0100 schrieb Andreas Tille:
> Hi Gudjon,
> 
> in case you agree with the suggested change of policy discussed on the
> debian-python mailing list[1] would you agree to set DPT as maintainer?
> If yes, I'd volunteer to do this, fix bug #1065855 and #1060736.
> 
> Kind regards and thanks for working on this package
> Andreas.
> 
> 
> [1] https://lists.debian.org/debian-python/2024/02/msg00052.html
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Re: Feature Request (docu): Define "dsc-file"

[Andreas Tille]

Hi again,

Am Fri, Mar 15, 2024 at 11:06:13AM + schrieb c.bu...@posteo.jp:
> Thanks for all your answers.
> 
> Am 15.03.2024 11:07 schrieb Andreas Tille:
> > Please try a web search for instance with the terms
> > [...]
> > which brought several helpful links.  Alternatively you can ask ChatGPT,
> > Gemini or the LLM of your choice
> 
> I am a bit shocked about that advise. For what was Hypertext invented?

Sorry if I might have been a bit blunt. I admit you Wiki changes are OK.

> My mail was not a support question but a Feature Request. Of course I am
> able to search this myself. But this won't help future readers and also
> won't improve the quality of the docs. The latter is my intention.

I'm fine if someone wants to improve the docs.

> Basic knowledge is needed to understand? Of course this is always the case
> in every section of live and the world.
> But why not point to that knowledge? That is what Hypertext is invented for.
> 
> > I do not think that things which are easy to find
> 
> No it is not "easy" when I have to run search engine for it. It is also not
> sustainable.

Well, I'm usually a fan of letting newcomers enhance the docs since
experts might fail to see beginners hurdles.  I admit I was afraid that
the request would end up explaining very basic packaging stuff at places
where the topic is specific about using Git for the Python team.

> > and is pretty clear
> > for the average reader of the text you want to extend should be written
> > down here.
> 
> I don't understand that section.
 
I mean that the topic of that page is "Using git for team packages" and
we should not blur that topic with information which is very basic for
the intended user audience.  Adding a hyperlink as you did is OK.
Explaining .dsc format is over the top IMHO.

To make sure you will not misunderstand me:  I did not wanted to scare
away a newcomer by redirecting to other resources of information.  I
hope that my hints where helpful enough for you to know now what .dsc
is.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Feature Request (docu): Define "dsc-file"

[Andreas Tille]

Hi

Am Fri, Mar 15, 2024 at 07:39:39AM + schrieb c.bu...@posteo.jp:
> Hi,
> 
> this is a feature request to someone who has access and the knowledge to
> improve.
> 
> Description of the problem:
> 
> The second paragraph in
>  tell me
> about importing a "dsc-file" without explaining what a dsc-file is or why I
> have to import it. The knowledge background is missing.

Please try a web search for instance with the terms

debian source format dsc file

which brought several helpful links.  Alternatively you can ask ChatGPT,
Gemini or the LLM of your choice

Can you explain what "import an existing .dsc file" means?

which produced a very verbose and good understandable text for me.

I do not think that things which are easy to find and is pretty clear
for the average reader of the text you want to extend should be written
down here.

Thank you for your suggestion anyway
Andreas.

 
> There is a hyper link behind the text "import an existing .dsc file"
> pointing to .
> Regarding that URL I assume this wiki entry is not maintained by DPT. But it
> also do not explain about dsc-file.
> 
> Suggested solution:
> Create or locate the dsc-file definition in the wiki. It should be an extra
> page. Then just use a hyperlink in your own docu to point to that
> definition.
> 
> "import an existing .dsc file"
>  ^^ ^
>  I  L 
>  L 
> 
> Please let me know if there is another "channel" where I should open such
> requests.
> 
> Thanks in advance
> Christian Buhtz
> 
> 

-- 
http://fam-tille.de

Re: morph's abandoned packages (list)

[Andreas Tille]

Hi Timo,

Am Fri, Mar 15, 2024 at 09:50:39AM +0100 schrieb Timo Röhling:
> * Julian Gilbey  [2024-03-14 06:20]:
> >#1065198 O: networkx -- tool to create, manipulate and study complex
> > networks language
> I use this somewhat regularly, so I'd be happy to share the workload with
> zigo.

Zigo will be probably happy. :-)

> >#1065329 O: numpy -- Fast array facility to the Python 3 language
> I use this a lot; both ckk and I are willing to take over.

I'm really happy that someone is taking over this heavy one.  Lots of
scientific packages I care for are depending from it.

> >#1065223 O: pysimplesoap -- simple and lightweight SOAP Library
> This is a transitive dependency of reportbug through python-debianbts. If no
> one else is interested, I'll take it.

I think its sensible if people simply add their ID to Uploaders in Git.
More than one (active) Uploader would be even better.  I'm currently
trying to find out who are non-active uploaders in R-pkg team - this is
possibly also some issue in DPT (but for a different set of packages
than we are talking about in this thread).

Thanks a lot to so many volunteers
Andreas.

-- 
http://fam-tille.de

Re: morph's abandoned packages (list)

[Andreas Tille]

Am Fri, Mar 15, 2024 at 08:25:00AM +0100 schrieb Thomas Goirand:
> I can take care of networkx, which is used in OpenStack. If nobody else
> care, I prefer to use a git tag based workflow, meaning it cannot stay in
> the team (but everyone is more than welcome in the OpenStack team). If
> anyone doesn't agree, and feel strong about keeping networkx to use
> pristine-tar and stay in the team, please voice your concern (and of course,
> volunteer to do the work).

If you care for the package feel free to do this in your prefered
workflow inside the team that is comfortable with this workflow.

Thanks a lot for taking over.
 
> I probably also need to keep pydot in shape.

Good.

Kind regards and thanks for stepping in
   Andreas. 

-- 
http://fam-tille.de

Re: morph's abandoned packages (list)

[Andreas Tille]

Control: tags -1 moreinfo

Hi,

this package is team maintained.  I have to assume its former maintainer
has decided to leave the team.  Please delay the removal until it is
perfectly clear that no other team member intends to take over this
package.

Thank you for your work as ftpmaster
 Andreas.

-- 
http://fam-tille.de

Re: morph's abandoned packages (list)

[Andreas Tille]

Hi Julian,

thanks a lot for assembling these lists.

To inspire potential takers I'd like to add the according popcon
values:

Am Thu, Mar 14, 2024 at 06:20:11AM + schrieb Julian Gilbey:
> If you are interested in taking one
> or more of them on, that would be great!

+1
 
> Removal requested:
> 
> #1066146 RM: flask-basicauth -- ROM; RC buggy, dead upstream, leaf package
> #1065141 RM: gmplot -- ROM; leaf package
> #1064947 RM: nb2plots -- ROM; leaf package
> #1065200 RM: overpass -- ROM; leaf package
> #1065199 RM: pprintpp -- ROM; leaf package
> #1065045 RM: pyannotate -- ROM; leaf package
> #1065201 RM: python-overpy -- ROM; leaf package
> #1065202 RM: python-ppmd -- ROM; leaf package
> #1064946 RM: sphinx-a4doc -- ROM; leaf package

udd=> SELECT package, insts, vote, olde, recent FROM popcon WHERE package IN (
  SELECT DISTINCT package FROM packages WHERE release = 'sid' AND source IN (
   'flask-basicauth', 'gmplot', 'nb2plots', 'overpass', 'pprintpp', 
'pyannotate', 'python-overpy', 'python-ppmd', 'sphinx-a4doc'
  )
) ;
 package | insts | vote | olde | recent 
-+---+--+--+
 python-ppmd-doc | 3 |0 |0 |  0
 python3-flask-basicauth |23 |1 |   18 |  4
 python3-gmplot  |21 |4 |   12 |  4
 python3-nb2plots|11 |0 |5 |  6
 python3-overpass|78 |7 |   61 | 10
 python3-overpy  |80 |9 |   62 |  9
 python3-ppmd| 7 |1 |5 |  1
 python3-pprintpp|21 |2 |   11 |  8
 python3-pyannotate  | 5 |1 |4 |  0
 python3-sphinx-a4doc|13 |2 |9 |  2
(10 rows)


BTW, the fact that a package has no maintainer is not a good reason for
a package removal.  If someone is interested in one of the packages this
should be added to the according bug report.

> Recently-orphaned packages (removing those in wnpp which have been
> retitled "ITA") sorted alphabetically; these could, of course, be
> brought into team maintenance.
> 
> #1065235 O: basemap -- matplotlib toolkit to plot on map projections
> #1065243 O: colorspacious -- library for doing colorspace conversions
> #1065151 O: commonmark -- Python parser for the CommonMark Markdown spec
> #1065246 O: contourpy -- Python library for calculating contours of 2D 
> quadrilateral grids
> #1065248 O: cppy -- C++ headers for (Python) C extension development
> #1065139 O: dot2tex -- Graphviz to LaTeX converter
> #1065140 O: fastkml -- fast KML processing
> #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 
> specification
> #1065244 O: kiwisolver -- fast implementation of the Cassowary constraint 
> solver
> #1065238 O: lazy-object-proxy -- Python 3 fast and thorough lazy object 
> proxy
> #1065037 O: m2crypto -- Python wrapper for the OpenSSL library
> #1065325 O: matplotlib -- Python based plotting system
> #1065143 O: mkautodoc -- AutoDoc for MarkDown
> #1065042 O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme 
> Python library
> #1065220 O: mpmath -- library for arbitrary-precision floating-point 
> arithmetic
> #1065224 O: mysql-connector-python -- pure Python implementation of MySQL 
> Client/Server protocol
> #1065198 O: networkx -- tool to create, manipulate and study complex 
> networks
> #1065329 O: numpy -- Fast array facility to the Python 3 language
> #1065221 O: py7zr -- pure Python 7-zip library
> #1065222 O: pychm -- Python binding for CHMLIB
> #1065231 O: pydot -- Python interface to Graphviz's dot
> #1065152 O: pygeoif -- basic implementation of the __geo_interface__
> #1065036 O: pyopenssl -- Python wrapper around the OpenSSL library
> #1065149 O: pyproject-metadata -- Dataclass for PEP 621 metadata with 
> support for [core metadata] generation
> #1065223 O: pysimplesoap -- simple and lightweight SOAP Library
> #1064977 O: python-cryptography-vectors -- Test vectors for 
> python-cryptography
> #1065327 O: python-levenshtein -- extension for computing string 
> similarities and edit distances
> #1065025 O: sphinx-book-theme -- clean book theme for scientific 
> explanations and documentation with Sphinx
> #1065026 O: sphinx-bootstrap-theme -- bootstrap theme for Sphinx
> #1065030 O: sphinxcontrib-log-cabinet -- Organize changelog directives in 
> Sphinx docs
> #1065027 O: sphinx-copybutton -- sphinx extension to add a "copy" button 
> to code blocks
> #1065028 O: sphinx-gallery -- extension that builds an HTML gallery of 
> examples from Python scripts
> #1065029 O: sphinx-panels -- documentation for the sphinx-panels Python 
> library
> #1065043 O: sphinxtesters -- utilities for testing Sphinx extensions
> #1064948 O: texext -- sphinx extensions for working with LaTeX math


udd=> SELECT package, 

Re: Maintenance of python-cryptography

[Andreas Tille]

Hi Scott,

Am Wed, Mar 13, 2024 at 11:39:50PM -0400 schrieb Scott Kitterman:
> On Wednesday, March 13, 2024 1:34:14 PM EDT Scott Kitterman wrote:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064979
> > 
> > Would some of you who are pushing so hard to change the policy for
> > Uploaders/ Maintainer in the team please step up and take over this
> > package.  It really needs updated to the new upstream release (blocking
> > both aioquic and dnspythong for me, I don't know about others).

Reading the bug log of your request to upgrade this package has a hint
from Tue, 13 Feb 2024 [1] that some rust dependencies need updates
(thanks for the work on this Jérémy!  BTW, I merged you 41.0.7-5 changes
into master branch and closed bug #1046569 manualy)

The discussion about Policy change started two weeks later[2].  I might
miss the point in the connection you are drawing here.

> > I haven't done a comprehensive check, but I think morph asked for all the
> > leaf packages he was maintaining in the team to be removed from the archive
> > and is removing himself from uploaders/maintainer on others.

Your request to speak up[3] was not heard.  I would have prefered to
read constructive arguments instead of silent leaving the team (in the
sense of not informing the team mailing list about the leave).

> > You all made this mess.  Please clean it up.

I think the good intentions[4] in your sentences here are that you
really care about this important package and you fear that it is left
alone.  So thanks for the pointer.

What I did before your mail was sent:

python-cryptography (42.0.5-1) UNRELEASED; urgency=medium

  * Team upload.
  * New upstream version
Closes: #1059308 (CVE-2023-50782)
Closes: #1064778 (CVE-2024-26130)
Closes: #1063771, #1018159
  * Reorder sequence of d/control fields by cme (routine-update)
  * watch file standard 4 (routine-update)
  * Enable building twice in a row
Closes: #1046569

 -- Andreas Tille   Thu, 29 Feb 2024 10:20:49 +0100

Meanwhile I marked bugs #1059308 and #1064778 pending (they could be
even closed but its good to have some record inside changelog if CVEs
are involved[5])  I also closed bug #1018159 which remained open for
no good reason and closed #1046569 manually since it was not mentioned
in changelog of latest upload.

Jérémy did:

python-cryptography (41.0.7-5) unstable; urgency=medium

  * AMAU, Closes: #1064979

  [ Andreas Tille ]
  * Enable building twice in a row

 -- Jérémy Lal   Thu, 07 Mar 2024 13:42:35 +0100

> Actually, it looks like python-cryptography still has one uploader, but morph 
> was doing work on the package, it's complicated,

Since Tristan Seligmann went MIA the package was uploaded by:

 -- Jérémy Lal   Thu, 07 Mar 2024 13:42:35 +0100
 -- Sandro Tosi   Wed, 28 Feb 2024 12:23:58 -0500
 -- Jérémy Lal   Thu, 08 Feb 2024 15:34:30 +0100
 -- Jérémy Lal   Tue, 09 Jan 2024 01:14:48 +0100
 -- Jérémy Lal   Sun, 07 Jan 2024 13:24:39 +0100
 -- Nicolas Dandrimont   Tue, 08 Aug 2023 17:16:11 +0200
 -- Sandro Tosi   Tue, 28 Feb 2023 00:36:13 -0500
 -- Stefano Rivera   Sun, 08 Jan 2023 16:31:04 -0400
 -- Sandro Tosi   Thu, 15 Dec 2022 12:00:09 -0500
 -- Debian Janitor   Thu, 19 May 2022 05:05:36 -
 -- Stefano Rivera   Wed, 18 May 2022 12:22:15 -0400

Comment: Debian Janitor did not really uploaded the package.  The
Uploader of the subsequent upload probably accidentaly forgot to merge
the changelog entries.  The Upload
   Sandro Tosi   Wed, 28 Feb 2024 12:23:58 -0500
is simply orphaning the package.  BTW, "orphaning" is defined by setting
Debian QA team as maintainer.  The package is not really orphaned but has
DPT as maintainer.  I understand your worries about this package but
looking at these entries I do not see in how far the current status
looks that bad.

> and could use more help, not 
> less.  Pyopenssl, on the other hand, is now unmaintained (no human uploader).

Pyopenssl is lagging slightly behind upstream.  Someone could care for
#1047548 but I personally ignore such bugs until other work on the
package needs to be done.  I'm optimistic that someone will step up
as Uploader.

Kind regards
Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063771#10
[2] https://lists.debian.org/debian-python/2024/02/msg00052.html
[3] https://lists.debian.org/debian-python/2024/02/msg00060.html
[4] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059308#25

-- 
http://fam-tille.de

Would you agree with swapping Maintainer and Uploaders in eric?

[Andreas Tille]

Hi Gudjon,

in case you agree with the suggested change of policy discussed on the
debian-python mailing list[1] would you agree to set DPT as maintainer?
If yes, I'd volunteer to do this, fix bug #1065855 and #1060736.

Kind regards and thanks for working on this package
Andreas.


[1] https://lists.debian.org/debian-python/2024/02/msg00052.html

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Christian,

Am Sat, Mar 02, 2024 at 11:48:57PM +0100 schrieb Christian Kastner:
> On 2024-03-02 23:11, Andreas Tille wrote:
> > I'm curious why you believe I didn't care. I likely would have reverted
> > my change if I didn't have more urgent matters to attend to.
> > Re-uploading a package just to revert the Maintainer and Uploader is
> > lower on my priority list than fixing other RC bugs.
> 
> To add another perspective: what if reverting is not about "fixing" the
> package again, but a courtesy or sign of respect towards the person that
> was upset by this action. Wouldn't that change the priority entirely?

Thanks for pointing this out.  I agree I failed here.  I hope to not
fail the same way in future again since in this very case I can't fix
this any more.
 
The lesson I hopefully learned now is that this kind of failures seems
to put other arguments I gave for a policy change in the shadow at least
for those team members I would love to reach for a constructive
discussion.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Bug#1065042: O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library

[Andreas Tille]

Am Thu, Feb 29, 2024 at 02:06:25PM -0800 schrieb Vagrant Cascadian:
> On 2024-02-29, Sandro Tosi wrote:
> > I intend to orphan the mpl-sphinx-theme package.
> >
> > The package description is:
> >  This is the official Sphinx theme for Matplotlib documentation.  It 
> > extends the
> >  pydata-sphinx-theme project, but adds custom styling and a navigation bar.
> >  .
> >  This package provides documentation for mpl-sphinx-theme
> 
> It looks like you attempted to orphan it, but switched the Maintainer to
> the python team rather than the Debian QA team ... 

It seems Sandro is trying to get rid of several of his packages.  There
are quite some Orphan bugs done by him in the last couple of days.
 
> Was your intention to orphan it, or just leave it up to the python team?

My gut feeling is that someone from the Python team would take over
these packages.  I will bounce the orphan messages from BTS to
debian-python list to keep people informed about these packages.
 
Kind regards

Andreas.

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Am Sat, Mar 02, 2024 at 09:11:52PM + schrieb Scott Kitterman:
> 
> It's possible I am misunderstanding you here (languages are hard even when 
> they are your first), but if I am not, I think you are not really seeing 
> things from the correct perspective.

I'm probably biased since involved into this and I'm interested into
other perspectives.

> Here's my summary of what I understand your argument to be:
> 
> I did not follow the team policy and didn't care about the other people 
> involved to rectify the error.

I'm curious why you believe I didn't care. I likely would have reverted
my change if I didn't have more urgent matters to attend to.
Re-uploading a package just to revert the Maintainer and Uploader is
lower on my priority list than fixing other RC bugs. I've mentioned
multiple times that different wording might have elevated the priority.
I'm not sure how to express this more clearly, sorry.

> They were upset about this, so clearly this mess is all their fault.

What exactly is the "mess" in this story.  Probably not swapping
Maintainer+Uploader since I several times confirmed that it is my fault
and immediately said I'm sorry about this.

>  We should change the rules so that I won't have been wrong.

Again no.  My proposal to change policy was after a second upload of
mine connected to

  pysimplesoap (1.16.2-6) unstable; urgency=3Dmedium

I asked the maintainer to post his response to a public mailing list but
he refused.  *Then* I proposed a change to the policy since I see
problems in it.  If we had only the first story I would have done
nothing (except reverting the change the maintainer considered wrong
once I might have time for it.)
 
> I absolutely do not know how to respond to that level of entitlement.  
> Hopefully I have misunderstood what you are trying to communicate?

I was told that I should not expect any thanks for fixing a bug and I
tried to explain this is not the case.  Now I am being accused of having
a sense of entitlement.  I'm starting to have severe doubt to make
my point clear enough.  My gut feeling tells me that it is time to lean
back and observe this thread passively instead of putting even more
fuel into it.

Kind regards
Andreas.


-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Jeroen,

Am Thu, Feb 29, 2024 at 08:48:33PM +0100 schrieb Jeroen Ploemen:
> ...

Julian had sensibly commented on this and had added interesting
questions I'm keen on hearing your answers.

> As for the inclusion of codes of conduct or similar wording,
> documenting common sense just feels unnecessary. While being on the
> receiving end of a compliment for bug-squashing work is certainly
> nice, the lack thereof isn't a measure of disrespect.

Julien also commented on this.  Despite I never thought to spent so much
time on the bug that triggered the discussion I consider it important
enough to clarify some misunderstandings which obviously were caused by
the mails I wrote about this.

As a non-native speaker, I am actively working on improving my
communication skills. I would appreciate it if you could point out which
part of my messages led you to believe that I felt disrespected. My
intention was simply to provide some insight into why the task someone
scheduled for me was not high on my priority list during my spare time.

To summarize the visible facts:

 2023-12-12 serious bug #1058177 was filed, solution for this kind of
bugs is simple for maintainers comfortable with Python 3.12

 2023-12-22 closed with changelog
[ Andreas Tille ]
* Set DPT maintainer
* Replace SafeConfigParser deprecated in Python3.12
  Closes: #1058177
* Transparently skip test_bad_pagebuilder instead of ignoring test suite
  errors

  --> I confirm "Set DPT mainter" was in conflict with DPT policy since
  I just forgot about that very detail and considered it some
  unintended oversight.  I will not do this again as long as this
  policy is not changed

 Response in Salsa comment[1]

 Sandro Tosi: @tille please explain why you think this is appropriate

 Andreas Tille: In all teams I know policy says the team address should be put
   as Maintainer. After checking DPT policy again again I realise it gives both
   options with different meanings. Sorry about that and feel free to revert.

 Sandro Tosi: @tille you made the mistake, so you do the reverting and the
   uploading to rectify it.


Comment: That seems fair.  If my real-life boss had asked, I would have
done it, considering he pays me for it.  Fortunately, my day job boss
knows how to motivate me better.  I wouldn't had brought this up on my
own behalf.  I just went into more detail to explain why I did not fixed
my mistake immediately.  As a volunteer, I have the freedom to choose
which tasks to prioritize.  A little kindness in communication can
significantly impact my priorities.  I wasn't expecting a "thank you for
fixing the bug," but I believe it's unrealistic for Sandro to expect me
to follow such commands as a volunteer.  (Fun fact:  I was throwing the
last two paragraphs into a LLM and besides fixing my paragraph several
changes where suggested to Sandro's quote.)


sphinxtesters (0.2.3-4) unstable; urgency=medium

  * Revert attempt by a rogue developer to hijack this package

 -- Sandro Tosi   Sun, 14 Jan 2024 01:25:23 -0500


I wonder how the attribute 'rogue' is supported by the discussion above,
nor where the intention to hijack the package is inferred from.


sphinxtesters (0.2.3-5) unstable; urgency=medium

  * orphan

 -- Sandro Tosi   Thu, 29 Feb 2024 01:55:25 -0500


I admit the last upload makes the initial request to revert the
Maintainer change questionable.  I also confirm that I have experienced
worse things before than giving me the attribute "rogue" or blaming
me about bad intentions.  Fine for me I developed some thick skin
meanwhile.

> I cannot recall
> any discussion on the team's IRC channel or mailing list crossing
> that line.

If you cannot recall anything that crossed the line I intended to draw
explicitly in our policy through my MR[2], I am curious to know where,
in your opinion, this falls in relation to our goal of 'striving to
create a kind and inviting atmosphere among team members.'  If it would
be only about me, I would simply move on (which I did until there was
another point of friction with no public traces).  But it does concern
fostering a welcoming team environment. In my view, this crosses the
line, and I am grateful to have been part of teams where such incidents
were not tolerated.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/packages/sphinxtesters/-/commit/d8b1083db26c753c8a76dd91b7e91f3ef98c0515#note_450676
[2] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21

Re: O: python-cryptography -- Python library exposing cryptographic recipes and primitives (documentation)

[Andreas Tille]

Hi,

as per bug #1064979 python-cryptography was orphaned.  Actually the
process of orphaninig is defined differently[1] by setting QA team as
maintainer.  In this case DPT remains maintainer but there is no
Uploader specified any more.  I personally will not add my ID as
Uploader.  I have added those team members who did uploads in the last
year in CC.

I tried to do some bug squashing anyway.  Since the latest version was
requested in bug #1063771 and this new version also closes #1064778
(CVE-2024-26130) (the other CVE-bug should have been closed in previous
upload) I decided to inject latest upstream, adapted the patches and
pushed to Git.  Unfortunately the package does not build as you can
verify in Salsa CI[1].

I admit I have no clue how to fix this but I hope someone can take over
from here.  I guess uploading to experimental first and see how it
plays nicely with its lots of rdepends makes sense here.

Kind regards
Andreas.

PS: I would have expected that to orphan a team maintained package the
team mailing list would have been CCed in the bug report.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#orphaning-a-package
[2] 
https://salsa.debian.org/python-team/packages/python-cryptography/-/jobs/5381997

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Scott,

Am Wed, Feb 28, 2024 at 09:19:29AM -0500 schrieb Scott Kitterman:
> Looking at your list, I note that it includes team members that have been 
> very 
> active in team wide work, not just on their own packages.

I'm fully aware of this.

> I think it would be 
> contrary to the spirit of Debian and working together if we changed the rules 
> and they felt they had to leave the team.

It is not my intention to move anybody out of the team but find
some consensus that other teams in Debian agreed upon as well.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Scott,

Am Wed, Feb 28, 2024 at 11:44:07AM + schrieb Scott Kitterman:
> 
> This makes more sense to me.  It is completely understandable that how things 
> are communicated affects how people feel about them.  This is a difficult 
> thing to get right.  I have experienced similar demotivating conversations in 
> Debian myself.

Seems everybody who has contributed to Debian some time was facing this.
 
> Everyone in Debian is already bound by the code of conduct already, so it 
> seems redundant to add it here again.  While I agree with the principle you 
> are trying to address, I think this change unnecessarily clutters the DPT 
> document and we should not make it.

I have no really strong opinion about this.  I had the cluttering point
in mind when I moved this paragraph right to the end.  I agree that it
is redundant to some extend.  Sometimes saying things repeatedly does
not harm but I would not strongly insist on this change.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Maintaining packages with complex relationships (Was: Suggesting change in DPT policy)

[Andreas Tille]

Hi Étienne,

Am Wed, Feb 28, 2024 at 09:37:59AM +0100 schrieb Étienne Mollier:
> > > Instead of restricting collaboration, we could let policy encourage
> > > maintainers to state such constraints in debian/README.DPT and ask team
> > > members to check that file before they team-upload.
> > 
> > I think this is a very good idea.  In case MR[1] will be accepted this
> > should be added to the policy as well.  I'm not sure whether the
> > "Maintainership" paragraph is the best place to add this.  I wonder if
> > you (or someone with the same doubts) might want to suggest another MR
> > to add this debian/README.DPT feature.
> 
> Policy changes aside,
(Thus changed subject. ;-) )

> I think it could be useful for the
> routine-update command to stop when such file is hit, in order
> to raise the importance that the package has quirks, and should
> not be casually updated without involved scrutiny.  I wonder
> whether this can be generalized, like if d/README.source file is
> present?  (Although the latter use is codified[2] and I'm not
> confident it is 100% suitable for such purpose: I see many such
> files on my radar which do not necessarily hint for quirks.)
> 
> Of course this could be overred with a --readme-reviewed flag
> once ready to finalize the package with automation for instance.

I like all your suggestions.  When reading Timo's suggestion about
debian/README.DPT I also thought about rather using the more generic
debian/README.source.  In any case I agree that routine-update should
respect such debian/README.* (except debian/README.Debian which is
user oriented).

I admit I like this kind of constructive discussion.

Kind regards
   Andreas.
 
> > [1] 
> > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
> [2]: 
> https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi,

Louis-Philippe (just quoting below in case you might have missed it) is
repeating the importance that anyone who thinks my suggestion (MR[1]) is
a bad idea make themselves heard.  I'm hereby adding those maintainers
who have more than 5 packages that are affected and did not yet raised
their opinion in To: field.

udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders 
like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer 
order by maintainer) tmp WHERE count > 5;
   maintainer| 
count 
-+---
 Debian PaN Maintainers  | 7
 Jeroen Ploemen |16
 Piotr Ożarowski  |23
 Sandro Tosi   |82
 Scott Kitterman| 7
 Vincent Bernat   |15
(6 rows)

Debian PaN is another team which might need extra discussion but I think
the intention is clear and Scott has raised his opinion before[2].

Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
[2] https://lists.debian.org/debian-python/2024/02/msg00060.html

Am Tue, Feb 27, 2024 at 03:36:24PM -0500 schrieb Louis-Philippe Véronneau:
> On 2024-02-27 03:05, Andreas Tille wrote:
> > Hi,
> > 
> > I became more deeply involved into DPT since 2022 as a consequence of
> > the suggestion for transfering several Debian Med/Science packages to
> > DPMT[1][2].  I happily followed this suggestion and moved >30 packages
> > from the Blends teams to DPT.  I was happy with this move since it makes
> > sense.
> > 
> > Recently we received lots of testing removal warnings in those Blends
> > teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations.  So
> > I did what I usually do in those teams:  I dedicated quite some time in
> > team wide bug hunting.  That way I squashed about 50 bugs on packages
> > where I was not in Uploaders.  When doing so I usually run
> > routine-update on the package which basically streamlines packaging to
> > latest standards including calling Janitor tools which are so far
> > accepted inside DPT.
> > 
> > I probably should have reviewed the DPT policy on Maintainership[3] more
> > carefully. In other teams, it's common for the Maintainer to be set to
> > the team, so I assumed it was just an oversight when I made this
> > change[4] when touching the package to fix RC bug #1058177.  However, I
> > I was pointed immediately about the fact that I was mistaken according
> > to the current DPT policy.  I apologize for this.  However, the wording
> > of the comment on my commit was discouraging, especially considering I
> > was a volunteer who had fixed a critical bug.  Because of this, I
> > decided to focus my efforts on fixing other critical bugs for the
> > moment.  If the comment had started with a 'Thanks for fixing the
> > critical bug, but...' I likely would have corrected my mistake quickly.
> > The lack of respect from my teammate simply made me prioritize my time
> > on other issues that are more visible to our users.  I wonder whether I
> > should propose another change to the policy about maintaining a kind and
> > polite language inside the team - but that's a different thing.
> > 
> > While I applied the patch for another RC bug (#1063443) after >2 weeks
> > which triggered a RC bug in reportbug I remembered the "keep the
> > maintainer" policy.  But I kept on doing Janitor like changes since
> > finally the package is maintained in a team where Janitor is accepted.
> > When doing so I failed the phrase "please contact the Maintainer for the
> > green light."  I apoligize for this again.  The response was another
> > volunteer-demotivating private mail (thus no quote) which also was
> > lacking the "Thanks for fixing"-phrase and degrading my changes as
> > "frivolous".
> > 
> > So far what happened (seen from my possibly biased perspective).
> > 
> > Why do I like to change the policy?
> > 
> > The current wording provides some means to stop volunteer team members
> > helping out moving forward to speed up migrations and fix Debian wide
> > dependencies.  It hides team maintained packages from a common BTS
> > view.  When pointing my browser to
> >  https://bugs.debian.org/team+pyt...@tracker.debian.org
> > I currently see 1339 open bugs (calculated by [UDD1]).  This hides
> > another 309 [UDD2] bugs (>18% of team

Re: Suggesting change in DPT policy

[Andreas Tille]

Am Tue, Feb 27, 2024 at 04:25:49PM + schrieb weepingclown:
> While perfectly understanding the weak collaboration model reasoning, I've 
> still always found DPT as uploader and not maintainer rather absurd TBH. The 
> current go to tool (as I understand it) for python packaging, py2dsp, also 
> creates an initial packaging with team in uploaders section and the person as 
> maintainer; something that I find even more absurd. Not only would I welcome 
> this suggested change, I also think it is better if py2dsp default to 
> starting with DPT as maintainers.

Good point.  I've filed

  #1064952 pypi2deb: Please set DPT as Maintainer and the ID of the person 
calling py2dsp as uploader

with a patch that works for me in one test example.

The interesting thing is that a tool targeting at streamlining the work
of DPT is not team maintained itself.  It is maintained by those two
maintainers who obviously see some value in the weak cooperation option

udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders 
like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer 
order by maintainer) tmp WHERE count > 20;
 maintainer  | count 
-+---
 Piotr Ożarowski  |23
 Sandro Tosi   |82
(2 rows)

which might influence their decision of the design of the tool.

Kind regards
Andreas.


[1] https://bugs.debian.org/1064952

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Timo,

Am Tue, Feb 27, 2024 at 04:08:51PM +0100 schrieb Timo Röhling:
> I guess the motivation behind the weak collaboration model is that some
> packages have hidden "gotchas", which a casual team uploader might not know.
> For instance, pygit2 is one of multiple libgit2 language bindings which all
> need to be upgraded in lock-step when a new upstream version is released.

You are making an important point here.
 
> Instead of restricting collaboration, we could let policy encourage
> maintainers to state such constraints in debian/README.DPT and ask team
> members to check that file before they team-upload.

I think this is a very good idea.  In case MR[1] will be accepted this
should be added to the policy as well.  I'm not sure whether the
"Maintainership" paragraph is the best place to add this.  I wonder if
you (or someone with the same doubts) might want to suggest another MR
to add this debian/README.DPT feature.

Kind regards
Andreas.


[1] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Scott,

Am Tue, Feb 27, 2024 at 11:54:01PM + schrieb Scott Kitterman:
> It's self-induced.  I mean if it's demotivating to have people point out that 
> you didn't follow the policy, then you can solve that all by yourself by 
> following the policy.  If I take your argument to its logical conclusion, all 
> of Debian's rules can be demotivating when people ignore them, so we should 
> get rid of them all so your feelings are safe.

I agree that it was my mistake to not follow team policy.  I should not
have done this and I apologized for this.  I should have written this
e-mail first to change a policy that does not fit my experiences in
other teams as well as what obviously several contributors consider
inappropriate.  To solve this I started this discussion and meanwhile
created a MR[1].

The demotivating part was the wording to point me to the policy.  I
addressed this with the words "I wonder whether I should propose another
change to the policy about maintaining a kind and polite language inside
the team - but that's a different thing." in my initial mail[2].

To make sure this will really clear I added the proposed change in a
second MR[3] containing the following diff:


--- a/policy.rst
+++ b/policy.rst
@@ -169,6 +169,16 @@ To be merged, a policy update needs the approval of at 
least one team
 administrator.
 
 
+Code of Conduct
+===
+  
+The Debian Python team members agree to the
+`Debian Code of Conduct `
+and strive to create a kind and inviting atmosphere among team members.
+We are welcoming newcomers and will be open to questions to get them
+starting.
+
+


Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
[2] https://lists.debian.org/debian-python/2024/02/msg00052.html
[3] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21

-- 
http://fam-tille.de

Suggesting change in DPT policy

[Andreas Tille]

Hi,

I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2].  I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT.  I was happy with this move since it makes
sense.

Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations.  So
I did what I usually do in those teams:  I dedicated quite some time in
team wide bug hunting.  That way I squashed about 50 bugs on packages
where I was not in Uploaders.  When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.

I probably should have reviewed the DPT policy on Maintainership[3] more
carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177.  However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy.  I apologize for this.  However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug.  Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment.  If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users.  I wonder whether I
should propose another change to the policy about maintaining a kind and
polite language inside the team - but that's a different thing.

While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy.  But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the
green light."  I apoligize for this again.  The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".

So far what happened (seen from my possibly biased perspective).

Why do I like to change the policy?

The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies.  It hides team maintained packages from a common BTS
view.  When pointing my browser to
https://bugs.debian.org/team+pyt...@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]).  This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight.  To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.

When I think twice about the wording
   Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).

How can a team member for instance find another RC bug #1009424?  Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS.  I came across this while looking into
Cython 3.0 bugs.  The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
(#1009424) that stayed unattended for 22 months?  We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs.  But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?

This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these
long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers.  I see no difference to simply do a NMU.

I've checked the current situation who is actually using the DPT team as
Uploaders[UDD3].  66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA.  This means the packages are
de-facto not maintained which is most probably an unwanted effect of the
current policy.  I know other maintainers from other teams to be fine
with stronger team understanding.

Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy.  I've attached
an according patch to the team policy[5].  I'm fine with creating a MR
to be discussed rather in Salsa than this 

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

[Andreas Tille]

HI Andrius,

Am Fri, Feb 23, 2024 at 09:29:27AM +0200 schrieb Andrius Merkys:
> > 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.

Nice hint - implemented.

Thanks a lot
   Andreas. 

-- 
http://fam-tille.de

Help needed to fix python-coverage-test-runner

[Andreas Tille]

Control: tags -1 help

Hi,

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'

In the patch in Git[1] I replaced imp by importlib (and distutils by
setuptools but this is not causing actual problems).  Unfortunately
when trying to run vmdb2 test against this patched package I get:

./check
Running unit tests 
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 313, in 

run()
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 304, in run
result = runner.run()
 
  File "/usr/lib/python3/dist-packages/CoverageTestRunner.py", line 211, in run
importlib.reload(module)
  File "/usr/lib/python3.11/importlib/__init__.py", line 148, in reload
raise ImportError(msg.format(name), name=name)
ImportError: module plugin not in sys.modules


The fact that
   importlib.reload(module)

makes me wonder whether my patch for _load_module_from_pathname() is
correct (despite when I added some debug lines it looked sensible).  Any
help is welcome.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/packages/python-coverage-test-runner/-/blob/master/debian/patches/Python3.12.patch?ref_type=heads

-- 
http://fam-tille.de

Status of sqlalchemy

[Andreas Tille]

Hi,

we have quite some Python3.12 related bugs caused by sqlalchemy which
seem to be fixed in experimental (which is lagging behind upstream
2.0.27 as well as version 1.4 in unstable where upstream just released
1.4.51).

It seems the issue that leads to bug #1058265

  >   File "/usr/lib/python3/dist-packages/sqlalchemy/sql/sqltypes.py", line 
2061, in Interval
  > epoch = dt.datetime.utcfromtimestamp(0)

is not fixed in 1.4.51 so sticking to 1.4 maintenance releases will not
simply solve our Python3.12 issues if we do not fix these ourselves with
patches.  So the question remains for Thomas wo wrote in bug #1058895:

 > It'd be nice if we could have the patch in Unstable with this series 1.4.x
 > before uploading 2.x, so that I have a chance to fix all Python 3.12 bugs and
 > not mix SQLA 2.x and Py 3.12 problems.

Do yuo really want to fix 1.4.x (maybe x=51) first or do we want to
switch to 2.0.27 and fix remaining problems with this latest version?  I
have no resources to run all the tests but I stumbled upon this question
when trying to do some general Python3.12 bug hunting.

Kind regards
Andreas.

-- 
http://fam-tille.de

Help needed to port qiime to Python3.12

[Andreas Tille]

Hi,

as reported in a qiime2 issue[1] there is some problem with Python3.12
in the tests of the q2-* packages which are all using the qiime package.
This problem is currently hidden from the tests made by Python3.12
porters but it became obvious now on Salsa CI[2].  I tried to fiddle
around a bit with the qiime code but with no success at all.  Any help
would be welcome.

Kind regards
Andreas.

[1] https://github.com/qiime2/qiime2/issues/751
[2] https://salsa.debian.org/med-team/q2-types/-/jobs/5313640#L900

-- 
http://fam-tille.de

Re: Spinx help needed

[Andreas Tille]

Hi Dmitry,

thanks a lot and sorry for my naivity

   Andreas.

Am Thu, Feb 15, 2024 at 09:54:55PM +0300 schrieb Dmitry Shachnev:
> On Thu, Feb 15, 2024 at 07:15:18PM +0100, Andreas Tille wrote:
> > Hi Dmitry,
> >
> > thanks a lot for this hint.
> >
> > I've created a quilt patch which replaces the vendored theme by the
> > sphinx13 one which is currently shipped in Debian.  The patches by
> > upstream seem to be void now - at least none applied to the current
> > version.
> >
> > Unfortunately this does not build as well - now with other errors
> > you can see in Salsa CI at
> >
> >https://salsa.debian.org/science-team/lmfit-py/-/jobs/5305535
> >
> > Do you have any further hints?
> 
> It looks like what you did was copying layout.html to basic_layout.html
> within lmfit-py's doc/sphinx/theme/sphinx13/ directory.
> 
> But what I suggested was copying a file from *Sphinx* source package,
> sphinx/themes/basic/layout.html to doc/sphinx/theme/sphinx13/basic_layout.html
> in lmfit-py.
> 
> With your change basic_layout.html tried to extend itself, which caused
> a recursion error.
> 
> I pushed a fix and the build job succeeded now. build-i386 failed, but that
> one is not related to Sphinx.
> 
> --
> Dmitry Shachnev



-- 
http://fam-tille.de

Re: Spinx help needed

[Andreas Tille]

Hi Dmitry,

thanks a lot for this hint.

Am Thu, Feb 15, 2024 at 11:46:45AM +0300 schrieb Dmitry Shachnev:
> lmfit-py ships a vendored copy of sphinx13 theme [1], which was copied from
> Sphinx source code with a minor modification in 2020 [2] and rebased in
> January 2022 [3]. However, there were more Sphinx releases since that month,
> and the theme needs to be updated for compatibility with them.

I've created a quilt patch which replaces the vendored theme by the
sphinx13 one which is currently shipped in Debian.  The patches by
upstream seem to be void now - at least none applied to the current
version.

Unfortunately this does not build as well - now with other errors
you can see in Salsa CI at

   https://salsa.debian.org/science-team/lmfit-py/-/jobs/5305535

Do you have any further hints?

Kind regards
   Andreas.
 
> In particular, the basic_layout.html file misses the change which was made
> in Sphinx commit [4], without which the search will not work. There is a
> comment under that commit which illustrates how exactly it will not work:
> contentRoot will be undefined, and the browser will attempt to make requests
> to a URL that has "undefined" in it. dh_sphinxdoc catches such issues and
> produces an error about them.
> 
> So, to fix this issue, you should copy sphinx/themes/basic/layout.html from
> the latest stable version of Sphinx to lmfit-py's basic_layout.html, applying
> the one-line change which is described in [2] and [3].
> 
> [1]: doc/sphinx/theme/sphinx13/*
> [2]: 
> https://github.com/lmfit/lmfit-py/commit/29e4712036606913149e16b246340a7fbedd8829
> [3]: 
> https://github.com/lmfit/lmfit-py/commit/e2418377c9870e02c820d0fe40d2232187864a81
> [4]: 
> https://github.com/sphinx-doc/sphinx/commit/8e730ae303ae686705ea12f44ef11da926a87cf5
> 
> --
> Dmitry Shachnev



-- 
http://fam-tille.de

Spinx help needed

[Andreas Tille]

Control: tags -1 pending

Hi,

I pushed fixes for #1056419 and #1058311 to Git and I think should be
fixed as well.  The only remaining build problem is new and caused by
sphinx[1]:

  dh_sphinxdoc -i -O--buildsystem=pybuild
dh_sphinxdoc: error: 
debian/python-lmfit-doc/usr/share/doc/python3-lmfit/html/search.html top-level 
node does not have data-content_root attribute


Unfortunately I have no idea how to fix this.  Any ideas?

Kind regards
Andreas.


[1] https://buildd.debian.org/status/package.php?p=lmfit-py=experimental

-- 
http://fam-tille.de

Did Python 3.12 developers honestly broke special regexp sequences? (Was: hatop fails its autopkg tests with Python 3.12)

[Andreas Tille]

Hi,

I was constantly shaking my had above bug #1061802 featuring
Syntaxwarnings like

SyntaxWarning: invalid escape sequence '\.'
573s   CLI_INPUT_RE = re.compile('[a-zA-Z0-9_:\.\-\+; /#%]')
573s /tmp/autopkgtest.G4v4eK/autopkgtest_tmp/hatop.py:215: 
SyntaxWarning: invalid escape sequence '\s'
573s   'software_name':re.compile('^Name:\s*(?P\S+)'),

which is even in contrast with Regular expression operations
documentation for Python3.12[1] where

\s
For Unicode (str) patterns:
Matches Unicode whitespace characters (which includes [ \t\n\r\f\v], and also 
many other characters, for example the non-breaking spaces mandated by 
typography rules in many languages).

Matches [ \t\n\r\f\v] if the ASCII flag is used.

For 8-bit (bytes) patterns:
Matches characters considered whitespace in the ASCII character set; this is 
equivalent to [ \t\n\r\f\v].


remains what I know \s is meaning in regular expressions.  (I admit '\.'
is unusual inside [] and I think just '.' is appropriate here.)  I tried
simple things like


$ python3.12
Python 3.12.2 (main, Feb  7 2024, 20:47:03) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> software_name = re.compile('^Name:\s*(?P\S+)')
:1: SyntaxWarning: invalid escape sequence '\s'
>>> software_name = re.compile('^Name:[\s\t\n]*(?P\S+)')
:1: SyntaxWarning: invalid escape sequence '\s'


which makes me scratching my head what else we should write
for "any kind of space" now in Python3.12.

Kind regards
   Andreas.

[1] https://docs.python.org/3/library/re.html

-- 
http://fam-tille.de

Re: python-etcd: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Andreas Tille]

Control: tags -1 pending

Hi,

I've fixed the issue reported in the bug in Git.  However, Salsa CI
shows another issue[1]:

if _is_instance_mock(spec):
>   raise InvalidSpecError(f'Cannot spec a Mock object. 
> [object={spec!r}]')
E   mock.mock.InvalidSpecError: Cannot spec a Mock object. 
[object=]
/usr/lib/python3/dist-packages/mock/mock.py:537: InvalidSpecError


Any idea how to fix this?

Kind regards
   Andreas.


[1] https://salsa.debian.org/python-team/packages/python-etcd/-/jobs/5265383

-- 
http://fam-tille.de

Sorry, I ment pyrlp (Was: apprise fails its autopkg tests with Python 3.12)

[Andreas Tille]

Hi Ben,

sorry for pointing at the wrong package.  I intended to write pyrlp
(while apprise was in my cut-n-paste buffer.)

Please read the text below with s/apprise/pyrlp/ in mind.
The bug in question is #1056442.

Kind regards and thank you for your quick response anyway
   Andreas.

Am Thu, Feb 08, 2024 at 09:17:17AM +1100 schrieb Ben Finney:
> Howdy Andreas,
> 
> On 07-Feb-2024, Andreas Tille wrote:
> > Hi Ben,
> > 
> > I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest
> > fails with Python3.12.  I'd happily fix packages in Debian Python Team
> > but your package is not team maintained.  Do you have any reason for
> > this?
> 
> The package metadata for ‘apprise’ tells me its maintainer is:
> 
> Maintainer: Debian Python Team 
> 
> http://deb.debian.org/debian/pool/main/a/apprise/apprise_1.7.2-1.dsc>
> 
> so I think you might have the information mixed up? You are talking about
> “version 0.5.1-4”, so maybe you are referring to a different package?
> 
> -- 
>  \ “Speech is human, silence is divine, yet also brutish and dead: |
>   `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 |
> _o__)  |
> Ben Finney 



-- 
http://fam-tille.de

Re: apprise fails its autopkg tests with Python 3.12

[Andreas Tille]

Hi Ben,

I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest
fails with Python3.12.  I'd happily fix packages in Debian Python Team
but your package is not team maintained.  Do you have any reason for
this?

BTW, upstream meanwhile released version 4.0.0.  Is there any reason to
stick to some pretty old version?  Usually following upstream closely
has a good chance to be compatible with recent Python versions and maybe
a simple upgrade would solve this issue.

Kind regards
Andreas.

-- 
http://fam-tille.de

graph-tool does not build on ppc64el architecture

[Andreas Tille]

Hi Tiago,

I updated Debian package of graph-tool to the latest (2.59).  It
turned out that it does not build on the ppc64el architecture.  You
can find a full build log here:

   
https://buildd.debian.org/status/fetch.php?pkg=graph-tool=ppc64el=2.59%2Bds-1=1704656087=0

Just seek for "error:" to navigate quickly to the actual problem
which is:

...
/bin/bash ./libtool  --tag=CXX   --mode=compile g++ -std=gnu++17 
-DHAVE_CONFIG_H -I. -I..  -I../src/boost-workaround -I../src/pcg-cpp/include 
-DHAVE_CONFIG_H -I../src/graph -I. 
-I/usr/lib/python3/dist-packages/cairo/include -I/usr/include/python3.11 
-pthread -I/usr/include -I/usr/lib/python3/dist-packages/numpy/core/include  
-DBOOST_ALLOW_DEPRECATED_HEADERS -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2  
-fopenmp -O3 -fvisibility=default -fvisibility-inlines-hidden -Wno-deprecated 
-Wall -Wextra -ftemplate-backtrace-limit=0 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o src/graph/correlations/graph_assortativity.lo 
../src/graph/correlations/graph_assortativity.cc
libtool: compile:  g++ -std=gnu++17 -DHAVE_CONFIG_H -I. -I.. 
-I../src/boost-workaround -I../src/pcg-cpp/include -DHAVE_CONFIG_H 
-I../src/graph -I. -I/usr/lib/python3/dist-packages/cairo/include 
-I/usr/include/python3.11 -pthread -I/usr/include 
-I/usr/lib/python3/dist-packages/numpy/core/include 
-DBOOST_ALLOW_DEPRECATED_HEADERS -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 
-fopenmp -O3 -fvisibility=default -fvisibility-inlines-hidden -Wno-deprecated 
-Wall -Wextra -ftemplate-backtrace-limit=0 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c ../src/graph/correlations/graph_assortativity.cc  
-fPIC -DPIC -o src/graph/correlations/.libs/graph_assortativity.o
../src/graph/correlations/graph_assortativity.cc: In function 
‘std::pair 
assortativity_coefficient(graph_tool::GraphInterface&, 
graph_tool::GraphInterface::deg_t, boost::any)’:
../src/graph/correlations/graph_assortativity.cc:84:44: note: parameter passing 
for argument of type ‘std::pair’ when C++17 is enabled changed 
to match C++14 in GCC 10.1
   84 |   boost::any weight)
  |^
In file included from 
/usr/include/boost/math/special_functions/detail/round_fwd.hpp:12,
 from /usr/include/boost/math/special_functions/math_fwd.hpp:29,
 from 
/usr/include/boost/math/special_functions/fpclassify.hpp:18,
 from 
/usr/include/boost/math/special_functions/relative_difference.hpp:9,
 from ../src/graph/correlations/graph_assortativity.hh:26,
 from ../src/graph/correlations/graph_assortativity.cc:23:
/usr/include/boost/math/tools/promotion.hpp: In instantiation of ‘struct 
boost::math::tools::promote_args’:
/usr/include/boost/math/tools/promotion.hpp:272:13:   required by substitution 
of ‘template using 
boost::math::tools::promote_args_t = typename 
boost::math::tools::promote_args::type [with T1 = long double; T2 = double; T3 
= float; T4 = float; T5 = float; T6 = float]’
/usr/include/boost/math/special_functions/relative_difference.hpp:17:60:   
required by substitution of ‘template 
boost::math::tools::promote_args_t 
boost::math::relative_difference(const T&, const U&) [with T = long double; U = 
double]’
../src/graph/correlations/graph_assortativity.hh:177:45:   required from ‘void 
graph_tool::get_scalar_assortativity_coefficient::operator()(const Graph&, 
DegreeSelector, Eweight, double&, double&) const [with Graph = 
boost::adj_list; DegreeSelector = graph_tool::in_degreeS; 
Eweight = boost::unchecked_vector_property_map >]’
../src/graph/correlations/graph_assortativity.cc:130:18:   required from 
‘scalar_assortativity_coefficient(graph_tool::GraphInterface&, 
graph_tool::GraphInterface::deg_t, boost::any):: [with auto:68 = boost::adj_list&; auto:69 = 
graph_tool::in_degreeS&; auto:70 = boost::unchecked_vector_property_map >&]’
../src/graph/graph_filtering.hh:492:27:   recursively required from 
‘graph_tool::detail::dispatch_loop, mpl_::bool_ >&, boost::adj_list, 
boost::reversed_graph, const 
boost::adj_list&>, 
boost::undirected_adaptor >, 
boost::filt_graph, 
MaskFilter > >, 
MaskFilter > > >, 
boost::filt_graph, 
const boost::adj_list&>, 
MaskFilter > >, 
MaskFilter > > >, 
boost::filt_graph 
>, MaskFilter > >, 
MaskFilter > > >, 
typelist > >, 
graph_tool::scalarS > >, 
graph_tool::scalarS > >, 
graph_tool::scalarS > >, 
graph_tool::scalarS > >, 
graph_tool::scalarS > >, 
graph_tool::scalarS > >, 
typelist >, 
boost::checked_vector_property_map >, 
boost::checked_vector_property_map >, boost::checked_vector_property_map >, 
boost::checked_vector_property_map >, 
boost::checked_vector_property_map >, 
boost::adj_edge_index_property_map, 
graph_tool::UnityPropertyMap > >, boost::any, 
boost::any&, boost::any&>(const 
action_wrap, mpl_::bool_ >&, typelist, boost::reversed_graph, const 

Re: New upstream version of flufl.i18n fails its test

[Andreas Tille]

Hi Yogeswaran,

Am Mon, Jan 29, 2024 at 02:36:59PM -0500 schrieb Yogeswaran Umasankar:
> > [1] https://salsa.debian.org/python-team/packages/flufl.i18n/-/jobs/5148646
> 
> I made some changes for you to take a look. Included a patch to use
> setuptools and sphinx-build html docs with Python 3.12.
> https://salsa.debian.org/python-team/packages/flufl.i18n

Thanks, Uploaded, Andreas.

-- 
http://fam-tille.de

Re: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Am Mon, Jan 29, 2024 at 02:29:28PM +0300 schrieb Dmitry Shachnev:
> 
> I have seen a similar problem in https://bugs.debian.org/1052802 and solved
> it by disabling dh_auto_clean completely.

I've found another solution by trying hard to keep te .egg-info dirs
(in a tarball inside debian/ dir and rsyncing them back at the place
where expected by the test - nothing I'm proud about but it works).
 
> I agree, it would be nice if pybuild did not delete .egg-info directories
> inside tests, or provided a way to opt out.

+1

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Hi,

I upgraded python-plaster to latest upstream - but this did not changed
the test suite error.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: tags -1 help

Hi,

I upgraded python-miio in Git.  Unfortunately there are some test suite 
errors[1]
Any help would be welcome
 Andreas.


[1] https://salsa.debian.org/python-team/packages/miio/-/jobs/5212674

-- 
http://fam-tille.de

New upstream version of flufl.i18n fails its test

[Andreas Tille]

Hi,

I checked some random DPT packages and had a look into flufl.i18n.

Unfortunately the new upstream version fails its test as you can
see in Salsa CI[1].

Any help is welcome
Andreas.


[1] https://salsa.debian.org/python-team/packages/flufl.i18n/-/jobs/5148646

-- 
http://fam-tille.de

Re: Bug#1043240: transition: pandas 1.5 -> 2.1

[Andreas Tille]

Hi Rebecca,

Am Sun, Jan 21, 2024 at 03:29:21PM + schrieb Rebecca N. Palmer:
> 
> Hence, doing this transition now would involve breaking some reverse
> dependencies with no known fix, but given the number of packages involved,
> trying to wait until they're all fixed is rather likely to instead end in
> pandas 1.5 being broken by a new Python/numpy/etc.

Just go for it and lets try to fix issues as soon as possible.

Thanks a lot for all your work on pandas

 Andreas.

-- 
http://fam-tille.de

[Help] Re: mlpy ftbfs with Python 3.12

[Andreas Tille]

Control: tags 1056819 pending
Control: tags -1 help

Hi,

after applying the patch for the cython3 issue the build issues of this
package are remaining.  This is strange since the missing modules are
provided inside the package.  I wonder what trick I might need to do to
convince the Python3 interpreter to seek for the modules recursively
which was obviously working until some point of time when the package
was building formerly.

Any help would be welcome
Andreas.

-- 
http://fam-tille.de

[Pending] django-session-security: FTBFS with Sphinx 7.1, docutils 0.20: error: invalid command 'build_sphinx'

[Andreas Tille]

Control: tags -1 pending

Hi,

I've fixed this problem in Git[1] but did not uploaded since autopkgtest
is failing in Salsa CI[2].

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/python-team/packages/django-session-security/-/commit/af1ebc734a33cf1b629a2626bad508b833eb2706
[2] 
https://salsa.debian.org/python-team/packages/django-session-security/-/jobs/5150104

-- 
http://fam-tille.de

Re: [Help] Re: python-pkginfo: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Hi Stefano,

Am Thu, Jan 11, 2024 at 08:25:46PM + schrieb Stefano Rivera:
> 
> The test is expecting the module to be installed in the test
> environment. Either we could try harder to emulate that, or skip the
> tests.

I admit I tried to copy around the module before running the test with
no success.  It would be great if this "could try harded" could be taken
over by pybuild. ;-)
 
> I committed a patch to run the test inside tox, which will install it in
> a virtualenv before running the test.

Looks good, thanks a lot.

I realised there are quite some low hanging RC bugs in DPT where I
harvested some but I have to stop after today with this due to new
tasks.  In Debian Med team we are squashing those bugs usually in our
Advent bug squashing party where everybody tries to close one bug (not
open one door ;-) ) in advent time.  It might make sense to establish
such regular bug squashing parties also in other teams.

Kind regards
Andreas. 

-- 
http://fam-tille.de

[Help] Re: python-pkginfo: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: tags -1 help

Hi,

I've fixed the two other bugs in python-pkginfo and upgraded to latest
upstream.  Unfortunately I have no clue about this issue.

Any idea what might be wrong here?

Kind regards
Andreas.

-- 
http://fam-tille.de

[Help] Re: python-srsly: ftbfs with cython 3.0.x

[Andreas Tille]

Control: tags -1 help

Hi,

when applying the patch (thanks for this, Bas) I learned that the
package builds for other reasons.  This is also true for the latest
upstream version[1].

Any help to fix this would be welcome
   Andreas.

[1] https://salsa.debian.org/python-team/packages/python-srsly/-/jobs/5141528

-- 
http://fam-tille.de

[Help] Re: python-stack-data: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13

[Andreas Tille]

Control: tags -1 help

Hi,

I tried the suggested patch for the cython3 issue of bug #1056872
in the currently packaged version[1] as well also tried upgrading
to latest upstream and tried building[2] which failed as well.

I admit, I'm running out of ideas what to do next.

Any help is welcome
   Andreas.

PS: I do not have any specific interest in this package, just intended
to squash some bugs.


[1] 
https://salsa.debian.org/python-team/packages/python-stack-data/-/jobs/5141231
[2] 
https://salsa.debian.org/python-team/packages/python-stack-data/-/jobs/5141459

-- 
http://fam-tille.de

yapsy: ModuleNotFoundError: No module named 'imp'

[Andreas Tille]

Hi Thibauld,

Debian has packaged yapsy.  We try to migrate to Python3.12.  When testing yapsy
with Python3.12 in our CI[1] it fails with:

testActivationAndDeactivation 
(test.test_SimplePlugin.SimpleTestCase.testActivationAndDeactivation)
Test if the activation procedure works. ... Unable to import plugin: 
/builds/python-team/packages/yapsy/debian/output/source_dir/test/plugins/SimplePlugin
Traceback (most recent call last):
  File 
"/builds/python-team/packages/yapsy/debian/output/source_dir/yapsy/PluginManager.py",
 line 518, in loadPlugins
candidate_module = PluginManager._importModule(plugin_module_name, 
candidate_filepath)
   
^^^
  File 
"/builds/python-team/packages/yapsy/debian/output/source_dir/yapsy/PluginManager.py",
 line 584, in _importModule
candidate_module = 
imp.load_module(plugin_module_name,plugin_file,candidate_filepath+".py",("py","r",imp.PY_SOURCE))

 ^
AttributeError: type object 'Loader' has no attribute 'PY_SOURCE'
FAIL
...

You can find the full log in our CI[1].

It would be great if you could port yapsy to Python3.12.

Kind regards
Andreas.


[1] https://salsa.debian.org/python-team/packages/yapsy/-/jobs/5132141#L1187

-- 
http://fam-tille.de

Re: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Hi Alexandre,

Am Thu, Jan 04, 2024 at 12:30:21AM +0100 schrieb Alexandre Detiste:
> 
> There might be some nmu needed too if maintainers don't react.
> 
> @Vincent: this one package "gtextfsm" is yours
> do you green light an upload ?

If you ask me the package is team maintained and a "Team upload"
should be fine.
 
Kind regards
Andreas.

-- 
http://fam-tille.de

Test suite issues with new version of python3-antlr4 (Was: python3-antlr4: FTBFS: AttributeError: 'TestIntervalSet' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'?)

[Andreas Tille]

Control: tags -1 pending

Hi,

I intended to fix bug #1058096.  Since I realised there is a new
upstream version I was considering an upgrade which I pushed to Salsa.
Unfortunately there are other test suite errors as you can see in Salsa
CI[1]:

==
ERROR: test.__main__ (unittest.loader._FailedTest.test.__main__)
--
ImportError: Failed to import test module: test.__main__
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 419, in _find_test_path
module = self._get_module_from_name(name)
 
  File "/usr/lib/python3.11/unittest/loader.py", line 362, in 
_get_module_from_name
__import__(name)
  File "/usr/lib/python3.11/test/__main__.py", line 2, in 
main(_add_python_opts=True)
  File "/usr/lib/python3.11/test/libregrtest/main.py", line 671, in main
ns = _parse_args(sys.argv[1:], **kwargs)
 ^^^
  File "/usr/lib/python3.11/test/libregrtest/cmdline.py", line 402, in 
_parse_args
parser.error("unrecognized arguments: %s" % arg)
  File "/usr/lib/python3.11/test/libregrtest/cmdline.py", line 182, in error
super().error(message + "\nPass -h or --help for complete help.")
  File "/usr/lib/python3.11/argparse.py", line 2642, in error
self.exit(2, _('%(prog)s: error: %(message)s\n') % args)
  File "/usr/lib/python3.11/argparse.py", line 2629, in exit
_sys.exit(status)
SystemExit: 2
...
(see more in Salsa CI log[1])


Since this looks pretty much as if the reason for this failur is that
the PiPY downloadable tarball is lacking the directory test/ (which was
included in the currently packaged version) I checked Github for these
files and added these inside a multi-source tarball (a script to create
this tarball is commited as well).  While the first three tests that
were importing from test/ are passing now.  I've also fixed bug #1058096
in a patch[2] (thus tagging this bug pending).  However, that new version
has now new test failures which you can find in the new Salsa CI build
log which includes the (fixed) tests[3].  It starts with

==
ERROR: TestTokenStreamRewriter 
(unittest.loader._FailedTest.TestTokenStreamRewriter)
--
ImportError: Failed to import test module: TestTokenStreamRewriter
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 419, in _find_test_path
module = self._get_module_from_name(name)
 
  File "/usr/lib/python3.11/unittest/loader.py", line 362, in 
_get_module_from_name
__import__(name)
  File 
"/builds/python-team/packages/python3-antlr4/debian/output/source_dir/.pybuild/cpython3_3.11_antlr4/build/test/TestTokenStreamRewriter.py",
 line 8, in 
from mocks.TestLexer import TestLexer, TestLexer2
  File 
"/builds/python-team/packages/python3-antlr4/debian/output/source_dir/.pybuild/cpython3_3.11_antlr4/build/test/mocks/TestLexer.py",
 line 19, in 
class TestLexer(Lexer):
  File 
"/builds/python-team/packages/python3-antlr4/debian/output/source_dir/.pybuild/cpython3_3.11_antlr4/build/test/mocks/TestLexer.py",
 line 20, in TestLexer
atn = ATNDeserializer().deserialize(serializedATN())
  ^^
  File 
"/builds/python-team/packages/python3-antlr4/debian/output/source_dir/.pybuild/cpython3_3.11_antlr4/build/antlr4/atn/ATNDeserializer.py",
 line 28, in deserialize
self.checkVersion()
  File 
"/builds/python-team/packages/python3-antlr4/debian/output/source_dir/.pybuild/cpython3_3.11_antlr4/build/antlr4/atn/ATNDeserializer.py",
 line 50, in checkVersion
raise Exception("Could not deserialize ATN with version " + str(version) + 
" (expected " + str(SERIALIZED_VERSION) + ").")
Exception: Could not deserialize ATN with version   (expected 4).
...

and I have no idea how to fix this.

Kind regards
Andreas.


[1] https://salsa.debian.org/python-team/packages/python3-antlr4/-/jobs/5066603
[2] 
https://salsa.debian.org/python-team/packages/python3-antlr4/-/blob/master/debian/patches/assertEquals.patch?ref_type=heads
[3] https://salsa.debian.org/python-team/packages/python3-antlr4/-/jobs/5067599

-- 
http://fam-tille.de
#!/bin/sh
# The archive at PiPy is not featuring the test suite files
# This script is fetching the files and creates a tarball that is suited for 
multi-source tarball

UGIT=https://github.com/antlr/antlr4/
UVERSION=$(dpkg-parsechangelog --file ./changelog | grep '^Version' | cut -d' ' 
-f2  | cut -f1 -d-)
tarball=$(dpkg-parsechangelog --file ./changelog | awk '/^Source:/ {print 
$2}')_${UVERSION}.orig-tests.tar.gz
set -x

tmpdir=$(mktemp -d /tmp/python3-antlr4-testsuite)
curdir=$PWD
cd $tmpdir

git clone ${UGIT}
cd 

Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)

[Andreas Tille]

Hi,

I checked debian/obitools.substvars which contains

  python3:Depends=cython3-legacy, python3 (<< 3.12), python3 (>= 3.11~), 
python3-ipython, python3-sphinx, python3-virtualenv, python3-wheel, python3:any

I wonder what mechanism is responsible for adding cython3-legacy to the
package dependencies.  This looks absolutely unmotivated to me.  Is there
any better way than editing debian/obitools.substvars in d/rules by
adding some override_dh_gencontrol?

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Bug#1056419: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Hi Alexandre,

Am Mon, Dec 11, 2023 at 09:18:16PM +0100 schrieb Alexandre Detiste:
> > https://github.com/lebigot/uncertainties/releases/tag/3.1.7
> 
> +1

OK.
 
> > Also we should probably get rid of python-future at some point.
> 
> I removed it from three games this week-end
> and filled 6 more bugs since to remove extraneous stale dependency.
> 
> There are in fact more fake stale dependencies than remaining true ones
> It takes like 10 minutes to review one package.
> It's a peaceful life.
> 
> https://salsa.debian.org/games-team/ardentryst/-/commit/fc6901b0e90b6bb3ec19b23c1c2d458d653b2d4a
> 
> I will continue this review.

I've seen your bug reports on some Debian Med packages and will try
to fix these as quickly as possible.
 
Thanks a lot for your invesigation and the bug reports
   Andreas.

-- 
http://fam-tille.de

[Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: tags -1 help

[Bug #1056419 in CC since the issue seems to be caused by python-future]

Hi Vincent,

I tried to upgrade python-future to the latest upstream version in the
hope that this would solve the issue reported in bug #1042244.
Unfortunately this is not the case and now with Python3.12 we also
have to deal with the removal of imp (which affects bug #1056419).

I'd like to ask for help on debian-python list since I'm pretty
overworked with other stuff.  Please also review my rude patch[1] to
hack around a shinx issue.  It would be great to have some better
solution here.

You can find a full build log of the latest upstream version in
Salsa CI[2].

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/python-team/packages/python-future/-/blob/master/debian/patches/hack_around_missing_toint_in_sphinx.patch
[2] https://salsa.debian.org/python-team/packages/python-future/-/jobs/5027089

-- 
http://fam-tille.de

Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Andreas Tille]

Hi Scott,

Am Fri, Aug 18, 2023 at 01:15:18PM + schrieb Scott Kitterman:
> On August 18, 2023 1:04:26 PM UTC, Andreas Tille  wrote:
> >> In Debian terms, it's not the preferred form for modification, so it's not 
> >> source.  In this regard DFSG goes farther than some software licenses.
> >
> >I think the point Jeroen wanted to make is that these are actually
> >source file archives which "by chance" are featuring a .whl extension
> >rather than a .zip extension.
> 
> A wheel is not the preferred form for modification.  They're not wheels by 
> chance at all.

Yes, thanks to Jeroen's hint I realised this as well and I agree that
this is a nasty way to hide the fact that the files are actually source
archives.

However, you confirmed yourself that future_fstrings is an exception and
comes with source and thus does not violate DFSG.  The only difference
I personally can see is that the archives are just hiding what they are.
We could simply add do some
   for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done
and we have source archives that are obviously what they are.
 
> From a DFSG perspective,

Hmmm, the only thing where I can draw a violation of the DFSG is that
there are no d/copyright entries for the source code that is hidden
inside these *.whl files.  Otherwise its "just" duplicated code (in most
cases) which is definitely not nice but IMHO not a violation of DFSG.

> the most straightforward approach is to build-depend on the relevant Debian 
> packages and build any needed wheels from that.

Do avoid source code duplication I'm willing to do that.  Yes, I
perfectly agree that its pretty ugly (I'm just a bit unsure about
the DFSG violation).  I'm wondering whether a simple

   zip whl.zip /path/to/python/files ; mv whl.zip whl.whl

will be something that can replace the current packages.  I think
we also need to patch the tests to fit the version numbers (if
we do not want to cheat and simply use the version numbers of the
original whl files to avoid patching).

>  It won't necessarily get you the same version as upstream uses, but it's 
> definitely DFSG compliant.

We also might symlink our resulting whl files with the version number
pdm upstream might expect in their tests.  The question is, whether all
this effort might break the tests in some way and we might end up with
endless patching by at the same time loosing the chance to discuss with
upstream.  But it might be time to discuss the issue with upstream
anyway.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Uncleaned egg-info directory giving lots of bugs about failing to build after successful build

[Andreas Tille]

Hi,

Am Fri, Aug 18, 2023 at 01:42:53PM +0100 schrieb Julian Gilbey:
> I'm sure I'm not the only one who received a whole bunch of bugs
> entitled "Fails to build source after successful build" last weekend.
> There was one theme common to most of them: the presence of a
> *.egg-info directory which was not cleaned by debian/rules clean.
> 
> I know the bug report said that this policy is currently under
> discussion, but I did get thinking about it.  I imagine that this
> particular directory should be the responsibility of dh-python to
> clean up, but it may not be sensible to always delete *.egg-info
> directories, as they may be present in the orig.tar.gz file.  One
> could handle it by manually adding this directory to debian/clean in
> each package, but perhaps this should be the default behaviour of
> dh-python?
> 
> Any thoughts?

I agree that having this a no-brainer and getting all this *.egg-info
caused bugs solved by a simple dh-python update without changing
packaging code would be extremely convenient.  I could imagine creating
a backup of the affected *.egg-info files if existent and copy these
back in clean target could solve this.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Andreas Tille]

Hi Scott,

Am Tue, Aug 15, 2023 at 02:18:35PM + schrieb Scott Kitterman:
> >They are zip files containing python source code. It is possible to include
> >compiled C extensions in wheels, but I checked and these wheels are all pure
> >python, so no binary blobs are included.
> 
> In Debian terms, it's not the preferred form for modification, so it's not 
> source.  In this regard DFSG goes farther than some software licenses.

I think the point Jeroen wanted to make is that these are actually
source file archives which "by chance" are featuring a .whl extension
rather than a .zip extension.
 
Kind regards
Andreas.

-- 
http://fam-tille.de

Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Andreas Tille]

Hi Scott,

Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman:
> >Before I upload I'd like to ask for reviewing this patch and opinions
> >about the test suite errors.  While these possibly occure in previous
> >versions (which I did not tested) we might consider ignoring just the
> >failing tests.  I need to admit that I did not went through the list of
> >single failures - may be there is a chance of easy fixes for some of
> >them.  I simply wanted to discuss the reintroduction of the artifacts
> >and my patch first.
> >
> With the exception of future_fstrings

I think there is also the souce for demo included.

> those are all binary without source.  That's a problem.

Given your role as ftpmaster you definitely have more experience than I
in this field.  I personally was thinking more in the line of binary
data we can not avoid in some cases.  This is a bit in the line with
Rdata decision[1] where those binary data files are documented in
debian/README.source.

My point is just: If we remove those data files (which are IMHO harmless
since these are not executd but used as input in tests - please correct
me if I'm wrong) we can not test the package.  Removing the files
prevents testing and thus we can not know whether the package we deliver
will work.  I've actually shown that not all tests are working but
stopped investigating this further.

> It's probably okay if you add the corresponding source somewhere in the 
> package.

We probably have some source packages inside Debian - may be in
different versions.  I need to admit that I intended to do a "quick fix
of a simple bug that affects some Debian Med packages" but realised that
I'm possibly opening a can of worms.  The simplest solution to fulfill
my needs would be probably to revert my change to run the tests and be
done.  However, I'm not sure whetherr this is in the interest of the
users of this package.  I'm absolutely not able time-wise to povide
sources and reconstruct all those *.whl files *and* in addition track
down the test suite errors.  This is a team package and if the team
decides we should go without testing I can do an according upload.
However, my prefered path would to document the issue of some binary
data properly an test what upstream expects to be tested.

> I do think it's odd that pdm would need poetry-core in its test suit.

At least there is poetry_core-1.3.2-py3-none-any.whl which might mean
that poetry-core is used for testing. 

Kind regards
   Andreas.
 

[1] https://lists.debian.org/debian-devel/2013/09/msg00332.html 

-- 
http://fam-tille.de

Re: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends

[Andreas Tille]

Control: tags -1 pending

Hi,

I've fixed the issue reported in this bug[1].

In addition I've took the chance to upload pdm to its latest upstream
version.  When doing so I realised that build time tests are basically
ignored.  This was mainly due to the removal of artefacts that are used
for testing.  I admit I do not see any reason to remove those data
files - in Debian R team this kind of data files which is just used for
testing is accepted.  Thus I took the freedom to re-introduce these
files and was running the tests in d/rules.  Unfortunately there is
quite a number of tests failing

   54 failed, 620 passed, 1 xfailed, 3 rerun in 228.94s (0:03:48) 


(see Salsa CI[2])

I'd like to stress that to run those tests at all I needed a patch[3]
since BaseProvider can't be simply imported from findpython.

Before I upload I'd like to ask for reviewing this patch and opinions
about the test suite errors.  While these possibly occure in previous
versions (which I did not tested) we might consider ignoring just the
failing tests.  I need to admit that I did not went through the list of
single failures - may be there is a chance of easy fixes for some of
them.  I simply wanted to discuss the reintroduction of the artifacts
and my patch first.

Kind regards
Andreas.


[1] 
https://salsa.debian.org/python-team/packages/pdm/-/commit/2691b62c20944e0d9ca2326cb99e196d954b2735
[2] https://salsa.debian.org/python-team/packages/pdm/-/jobs/4555215
[3} 
https://salsa.debian.org/python-team/packages/pdm/-/blob/master/debian/patches/0002_fix_import.patch

-- 
http://fam-tille.de

Re: Taking over package into Debian Python Team maintenance and fixing bug (Was: mdp: FTBFS with numpy 1.21 (in experimental): dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3

[Andreas Tille]

Hi Yaroslav,

Am Mon, Apr 17, 2023 at 05:59:23PM -0400 schrieb Yaroslav Halchenko:
> Hi Andreas,
> 
> Thank you very much for offering help.  I think Tiziano would not mind,
> so please feel very welcome to a) for the sake of b) or any other
> goodness you would like to bring ;)

  
https://tracker.debian.org/news/1429393/accepted-mdp-36-2-source-into-unstable/
  https://salsa.debian.org/python-team/packages/mdp

> Note though that MDP is pretty much inactive project since a few years
> back.  It seems it is still used by some and somewhat maintained
> upstream, so might indeed be worthwhile keeping afloat in Debian but I
> would not cry if it got RMed.

We have some rdepends:

$ apt rdepends python3-mdp
python3-mdp
Reverse Depends:
  Recommends: pan-machine-learning
  Recommends: science-machine-learning
  Enhances: python3-sklearn
  Recommends: python3-pymca5
  Recommends: science-machine-learning

> After/if packaging moves to a new repo on salsa, we can submit a
> PR to add an empty out debian/ and add stub debian/README to that
> upstream repo to signal that packaging moved to salsa.

See above.  A finding that came unexpected after adding autopkgtest
is that 32bit architectures can't cope with 'float128', 'complex256'
data types.  Since I wanted to avoid further trouble in hard freeze
I decided to restrict architectures to 64bit for the moment.
 
Kind regards
Andreas.

-- 
http://fam-tille.de

Re: python-snappy is outdated, was NMUed two times and should be rather maintained by Debian Python Team

[Andreas Tille]

BTW, I've prepared an upload candidate at

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

Unfortunately my initial problem about GPF persists, but that's a
different topic, thought.

Kind regards
 Andreas.

Am Mon, Mar 27, 2023 at 06:33:11PM +0200 schrieb Andreas Tille:
> Hi Shell Xu,
> 
> I need GFU which does not seem to be supported by the python-snappy
> version currently in Debian:
> 
> >>> from snappy import GPF
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: cannot import name 'GPF' from 'snappy' 
> (/usr/lib/python3/dist-packages/snappy/__init__.py)
> 
> 
> Debian has version 0.5.3 while upstream has 0.6.1.  I realised that the
> last two uploads where doen in NMUs.  I'd suggest we move the packaging
> in Salsa[1] to Debian Python Team git, and move on with the update from
> there.  If I do not hear from you I'll do the suggested move next week.
> 
> In any case thanks for introducing this package into Debian.
> 
> Kind regards
>Andreas.
> 
> 
> [1] https://salsa.debian.org/shell909090-guest/python-snappy
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

python-snappy is outdated, was NMUed two times and should be rather maintained by Debian Python Team

[Andreas Tille]

Hi Shell Xu,

I need GFU which does not seem to be supported by the python-snappy
version currently in Debian:

>>> from snappy import GPF
Traceback (most recent call last):
  File "", line 1, in 
ImportError: cannot import name 'GPF' from 'snappy' 
(/usr/lib/python3/dist-packages/snappy/__init__.py)


Debian has version 0.5.3 while upstream has 0.6.1.  I realised that the
last two uploads where doen in NMUs.  I'd suggest we move the packaging
in Salsa[1] to Debian Python Team git, and move on with the update from
there.  If I do not hear from you I'll do the suggested move next week.

In any case thanks for introducing this package into Debian.

Kind regards
   Andreas.


[1] https://salsa.debian.org/shell909090-guest/python-snappy

-- 
http://fam-tille.de

Tiledb-py fails to build (Was: tiledb: uses atomic operations, but is not linked to libatomic)

[Andreas Tille]

Hi,

as you can read in the bug log, there was an upload of a new version of
tiledb a couple of hours before it has migrated to testing.  Thus the
package remains affected by a testing removal (together with its two
reverse dependencies tiledb and genomicsdb).  To follow the freeze
policy I reverted the version bump and NMUed tiledb
2.15.0really2.14.1-0.1 to experimental (since the maintainer did not
responded).

As we can see tiledb-py does not build against tiledb 2.15.0[1]

I've now forced (Build-)Depends to
   tibtiledb-dev (>= 2.15.0really2.14.1~)
but it seems Salsa CI autopkgtest does not respect the setting

variables:
  # Build against tiledb in experimental
  RELEASE: 'experimental'

and thus the autopkgtest log does not reproduce the error I've got
in my local build:

...

=== FAILURES ===
___ TestNumpyToArray.test_from_numpy_empty_str[1-0] 

self = 
empty_str = '', num_strs = 1

@pytest.mark.parametrize("empty_str", ["", b""])
@pytest.mark.parametrize("num_strs", [1, 1000])
def test_from_numpy_empty_str(self, empty_str, num_strs):
uri = self.path("test_from_numpy_empty_str")
np_array = np.asarray([empty_str] * num_strs, dtype="O")
tiledb.from_numpy(uri, np_array)

with tiledb.open(uri, "r") as A:
assert_array_equal(A[:], np_array)
if has_pandas():
>   assert_array_equal(A.query(use_arrow=True).df[:][""], np_array)

tests/test_libtiledb.py:3356:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.
/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:192: in __getitem__
return self if self.return_incomplete else self._run_query()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.

self = 

def _run_query(self) -> Union[DataFrame, Table]:
if self.pyquery is not None:
self.pyquery.submit()

if self.pyquery is None:
df = DataFrame(self._empty_results)
elif self.use_arrow:
with timing("buffer_conversion_time"):
>   table = self.pyquery._buffers_to_pa_table()
E   ModuleNotFoundError: No module named 'pyarrow'

/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:329: 
ModuleNotFoundError
___ TestNumpyToArray.test_from_numpy_empty_str[1-1] 

self = 
empty_str = b'', num_strs = 1

@pytest.mark.parametrize("empty_str", ["", b""])
@pytest.mark.parametrize("num_strs", [1, 1000])
def test_from_numpy_empty_str(self, empty_str, num_strs):
uri = self.path("test_from_numpy_empty_str")
np_array = np.asarray([empty_str] * num_strs, dtype="O")
tiledb.from_numpy(uri, np_array)

with tiledb.open(uri, "r") as A:
assert_array_equal(A[:], np_array)
if has_pandas():
>   assert_array_equal(A.query(use_arrow=True).df[:][""], np_array)

tests/test_libtiledb.py:3356:
/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:192: in __getitem__
return self if self.return_incomplete else self._run_query()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.

self = 

variables:
  # Build against tiledb in experimental
  RELEASE: 'experimental'
def _run_query(self) -> Union[DataFrame, Table]:
if self.pyquery is not None:
self.pyquery.submit()

if self.pyquery is None:
df = DataFrame(self._empty_results)
elif self.use_arrow:
with timing("buffer_conversion_time"):
>   table = self.pyquery._buffers_to_pa_table()
E   ModuleNotFoundError: No module named 'pyarrow'

/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:329: 
ModuleNotFoundError
__ TestNumpyToArray.test_from_numpy_empty_str[1000-0] __

self = 
empty_str = '', num_strs = 1000

@pytest.mark.parametrize("empty_str", ["", b""])
@pytest.mark.parametrize("num_strs", [1, 1000])
def test_from_numpy_empty_str(self, empty_str, num_strs):
uri = self.path("test_from_numpy_empty_str")
np_array = np.asarray([empty_str] * num

=== FAILURES ===
___ TestNumpyToArray.test_from_numpy_empty_str[1-0] 

self = 
empty_str = '', num_strs = 1

@pytest.mark.parametrize("empty_str", ["", b""])
@pytest.mark.parametrize("num_strs", [1, 1000])
def test_from_numpy_empty_str(self, empty_str, num_strs):
uri = self.path("test_from_numpy_empty_str")
np_array = np.asarray([empty_str] * num_strs, dtype="O")
tiledb.from_numpy(uri, np_array)

with tiledb.open(uri, "r") as A:
assert_array_equal(A[:], np_array)
if has_pandas():
>   assert_array_equal(A.query(use_arrow=True).df[:][""], np_array)

Re: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

[Andreas Tille]

Hi Rebecca,

Am Mon, Feb 06, 2023 at 07:59:17AM + schrieb Rebecca N. Palmer:
> (Background: the pandas + dask transition broke dask.distributed and it was
> hence removed from testing; I didn't notice at the time that if we don't get
> it back in we lose Spyder.)

as far as I know Diane has put quite some effort into dask and I
understood that dask and dask.distributed are closely interconnected.
 
> And now test_failing_task_increments_suspicious (once):
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3903956
> (We don't have to pass build-i386 (as this is an arch:all package) or
> reprotest, but if these are effectively-random failures, they might also be
> able to occur in build or autopkgtest.)
> 
> I'm probably the wrong person to be working on this - I don't know enough
> about this package to say whether ignoring this kind of intermittent failure
> (as my 'flaky' marks do) is appropriate, or to have much idea how to
> actually fix it.

In several cases we decided to ignore some tests.  While I like the idea
to mark a test flaky instead ignoring it completely given your
experience I think ignoring these tests is a valid way to proceed with
this package for the moment.
 
> We could also try upgrading dask + dask.distributed to 2023.1, but that's a
> risky move at this point.

I agree that it is risky.  We might discuss this with upstream and
possibly use an experimental branch to verify how it works.  It might be
that later versions work better with later Pandas / Python3.11.
However, the window of opportunity to get something in before the freeze
is closing and I'm afraid we do not have time for experiments.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: python-param: FTBFS: TypeError: The only supported seed types are: None,

[Andreas Tille]

Control: tags -1 help

Hi,

I've bumped upstream version to 1.12.3 which basically has the
suggested patches applied but the issue remains as you can see
in Salsa CI

   https://salsa.debian.org/science-team/python-param/-/jobs/3891083

Do you have any further hints?

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Remaining numpy 1.24 issues on 32bit architectures

[Andreas Tille]

Hi Nilesh,

Am Mon, Jan 30, 2023 at 05:07:37PM +0530 schrieb Nilesh Patra:
> 
> On Mon, Jan 30, 2023 at 09:12:57AM +0100, Andreas Tille wrote:
> > I made some tiny steps forward ("only" 84 failures instead of 89 when I
> > wrote my first mail) in the numpy 1.24 migration for 32bit architectures
> > but I'm facing issues I do not have a real clue for.  In
> > 
> >
> > https://salsa.debian.org/med-team/python-skbio/-/blob/master/debian/patches/numpy-1.24.patch#L123-L126
> 
> Apologies for pointing the discussion into an orthogonal direction for
> once. Ofcourse, we could try fixing these, but if you look closely, skbio
> has never built on 32 bit archs ever since around 2016 on i386[3] and
> it has never built on the rest of 32 bit ever since it entered debian[4]
> and now this new upstream FTBFS that you point to, won't really block
> migration in any way.

Hmmm, I have checked
   https://buildd.debian.org/status/package.php?p=python-skbio
before I started to investigate time into this and it says `uncompiled`
for the 32bit architectures.
 
> So my question is this: Why are we trying hard to fix this on 32-bit _now_
> given that the upstream support has never been solid for this package on
> 32-bit archs?

I admit the 0.5.8-2 has migrated which I did not expected since when
I was looking excuses contained those build problems.

> > ...
> > which obviosly[2] failed.  I wonder whether someone might give some
> > hints how to get dtypes consistently to one integer representation which
> > is the background of nearly all these test suite issues.
> 
> I can think of two alternatives to fix this:
> 
> 1. There are a few type conversions to "int" (.astype(int)) in the skbio 
> source code.
> This defaults to 32-bit integer type on 32-bit machines. Explicitly
> casting them to 64-bit can fix this. I happened to write a similar patch
> for another package recently, see[5] if it helps.
> 
> 2. Just ignore datatypes while comparing pandas dataframes with
> `check_dtype` parameter. An example/reference patch here[6]

Thanks for the additional hints (and have a nice trip).

Kind regards
   Andreas.

> > > [1] 
> > > https://buildd.debian.org/status/package.php?p=python-skbio=experimental
> > [2] https://salsa.debian.org/med-team/python-skbio/-/jobs/3868951
> [3]: https://buildd.debian.org/status/logs.php?pkg=python-skbio=i386
> [4]:https://buildd.debian.org/status/logs.php?pkg=python-skbio=armhf
> [5]: 
> https://salsa.debian.org/med-team/python-bioframe/-/blob/master/debian/patches/32-bits.patch
> [6]: 
> https://salsa.debian.org/python-team/packages/python-upsetplot/-/blob/master/debian/patches/ignore-dtype-while-asserting.patch
> 
> -- 
> Best,
> Nilesh



-- 
http://fam-tille.de

Re: Remaining numpy 1.24 issues on 32bit architectures

[Andreas Tille]

Hi,

I made some tiny steps forward ("only" 84 failures instead of 89 when I
wrote my first mail) in the numpy 1.24 migration for 32bit architectures
but I'm facing issues I do not have a real clue for.  In

   
https://salsa.debian.org/med-team/python-skbio/-/blob/master/debian/patches/numpy-1.24.patch#L123-L126

I tried three variants how I could fix

___ AlphaDiversityTests.test_no_ids 
self = 
def test_no_ids(self):
# expected values hand-calculated
expected = pd.Series([3, 3, 3, 3])
# All this does not help
# expected = pd.Series(np.array([3, 3, 3, 3], int32))
# actual = np.int64(alpha_diversity('observed_otus', self.table1))
# actual = np.dtype('int64').type(alpha_diversity('observed_otus', 
self.table1))
actual = alpha_diversity('observed_otus', self.table1)
>   assert_series_almost_equal(actual, expected)
skbio/diversity/tests/test_driver.py:260: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
left = 03
13
23
33
dtype: int32
right = 03
13
23
33
dtype: int64
def assert_series_almost_equal(left, right):
# pass all kwargs to ensure this function has consistent behavior even 
if
# `assert_series_equal`'s defaults change
>   pdt.assert_series_equal(left, right,
check_dtype=True,
check_index_type=True,
check_series_type=True,
check_names=True,
check_exact=False,
check_datetimelike_compat=False,
obj='Series')
E   AssertionError: Attributes of Series are different
E   
E   Attribute "dtype" are different
E   [left]:  int32
E   [right]: int64
skbio/util/_testing.py:323: AssertionError
 AlphaDiversityTests.test_observed_otus 
self = 
def test_observed_otus(self):
# expected values hand-calculated
expected = pd.Series([3, 3, 3, 3], index=self.sids1)
actual = alpha_diversity('observed_otus', self.table1, self.sids1)
>   assert_series_almost_equal(actual, expected)
skbio/diversity/tests/test_driver.py:223: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
left = A3
B3
C3
D3
dtype: int32
right = A3
B3
C3
D3
dtype: int64
def assert_series_almost_equal(left, right):
# pass all kwargs to ensure this function has consistent behavior even 
if
# `assert_series_equal`'s defaults change
>   pdt.assert_series_equal(left, right,
check_dtype=True,
check_index_type=True,
check_series_type=True,
check_names=True,
check_exact=False,
check_datetimelike_compat=False,
obj='Series')
E   AssertionError: Attributes of Series are different
E   
E   Attribute "dtype" are different
E   [left]:  int32
E   [right]: int64
skbio/util/_testing.py:323: AssertionError
__ AlphaDiversityTests.test_optimized __
self = 
def test_optimized(self):
# calling optimized faith_pd gives same results as calling unoptimized
# version
>   optimized = alpha_diversity('faith_pd', self.table1, tree=self.tree1,
otu_ids=self.oids1)
skbio/diversity/tests/test_driver.py:265: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 


which obviosly[2] failed.  I wonder whether someone might give some
hints how to get dtypes consistently to one integer representation which
is the background of nearly all these test suite issues.

Kind regards
Andreas.

[2] https://salsa.debian.org/med-team/python-skbio/-/jobs/3868951

Am Sun, Jan 29, 2023 at 12:11:15PM +0100 schrieb Andreas Tille:
> Hi,
> 
> I think there are some remaining issues with numpy 1.24 migration on 32
> bit architectures[1].
> 
> Here is one example:
> 
> _ TestSequence.test_getitem_with_slice_has_positional_metadata 
> _
> 
> self =  testMethod=test_getitem_with_slice_has_positional_metadata>
> 
> def test_getitem_with_slice_has_positional_metadata(self):
> s = "0123456789abcdef"
> length = len(s)
> seq = Sequence(s, metadata={'id': 'id3', 'description': 'dsc3'},
>positional_metadata={'quality': np.arange(length)})
> 
> eseq = Sequence("012", metadata={'id': 'id3', 'description': 'dsc3'},
> po

Re: Bug#1029593: nibabel: (armel autopkgtest) needs update for NumPy 1.24

[Andreas Tille]

Hi Étienne,

Am Sun, Jan 29, 2023 at 09:19:44PM +0100 schrieb Étienne Mollier:
> The uname machine name may not have been armv7l on the test bed,
> leading to the present crash.  This should read like the below
> and I consider pushing a "fix" in that direction tomorrow:
> 
>   @pytest.mark.skipif(os.uname().machine[0:3] == 'arm',
>   reason="fails on armel only, see #1029593.")
> 
> Of course it would be even better to fix the root cause on
> armel.

Sounds sensible, thanks for working on this.
 
> Besides, I notice there is a regression in dipy[4], which may be
> caused by the nibabel version bump.  Since we are in transission
> freeze, I suspect the package needs to be reverted to version 4.
> That being said the error message in amd64 doesn't make it very
> obvious the problem comes from nibabel, so I'm having a closer
> look before stating anything definitive.

As far as I understood the transition is only for SONAME bumps which is
not the case for Python modules (even if I personally would think that
bumping versions of widely used modules has features of a transition
in terms of potential breakages).

In the dipy case I think we are safe since I realised this issue and in
turn also upgraded dipy to version 1.6 which seems to build and test
nicely.  We just should observe its migration closely.

Kind regards
   Andreas.
 
> [2]: 
> https://ci.debian.net/data/autopkgtest/unstable/armel/n/nibabel/30782893/log.gz
> [3]: https://wiki.debian.org/ArchitectureSpecificsMemo
> [4]: 
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dipy/30816896/log.gz
> 
> Thanks Graham for having kept an eye on this,

For sure as always thanks to Graham

 Andreas.


> Sorry for my mess,
> -- 
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/tty1, please excuse my verbosity.
> On air: Lee Abraham - Days Gone By



-- 
http://fam-tille.de

Re: Bug#1029593: nibabel: (armel autopkgtest) needs update for NumPy 1.24

[Andreas Tille]

Hi,

the according log[1] says:

=== FAILURES ===
___ test_a2f_nan2zero_range 

def test_a2f_nan2zero_range():
# array_to_file should check if nan can be represented as zero
# This comes about when the writer can't write the value (-intercept /
# divslope) because it does not fit in the output range.  Input clipping
# should not affect this
fobj = BytesIO()
# No problem for input integer types - they don't have NaNs
for dt in INT_TYPES:
arr_no_nan = np.array([-1, 0, 1, 2], dtype=dt)
# No errors from explicit thresholding (nor for input float types)
back_arr = write_return(arr_no_nan, fobj, np.int8, mn=1, 
nan2zero=True)
assert_array_equal([1, 1, 1, 2], back_arr)
back_arr = write_return(arr_no_nan, fobj, np.int8, mx=-1, 
nan2zero=True)
assert_array_equal([-1, -1, -1, -1], back_arr)
# Pushing zero outside the output data range does not generate error
back_arr = write_return(arr_no_nan, fobj, np.int8, intercept=129, 
nan2zero=True)
assert_array_equal([-128, -128, -128, -127], back_arr)
back_arr = write_return(arr_no_nan, fobj, np.int8,
intercept=257.1, divslope=2, nan2zero=True)
assert_array_equal([-128, -128, -128, -128], back_arr)
for dt in CFLOAT_TYPES:
arr = np.array([-1, 0, 1, np.nan], dtype=dt)
# Error occurs for arrays without nans too
arr_no_nan = np.array([-1, 0, 1, 2], dtype=dt)
complex_warn = (np.ComplexWarning,) if np.issubdtype(dt, 
np.complexfloating) else ()
# Casting nan to int will produce a RuntimeWarning in numpy 1.24
nan_warn = (RuntimeWarning,) if FP_RUNTIME_WARN else ()
c_and_n_warn = complex_warn + nan_warn
# No errors from explicit thresholding
# mn thresholding excluding zero
with pytest.warns(complex_warn) if complex_warn else 
error_warnings():
assert_array_equal([1, 1, 1, 0],
   write_return(arr, fobj, np.int8, mn=1))
# mx thresholding excluding zero
with pytest.warns(complex_warn) if complex_warn else 
error_warnings():
assert_array_equal([-1, -1, -1, 0],
   write_return(arr, fobj, np.int8, mx=-1))
# Errors from datatype threshold after scaling
with pytest.warns(complex_warn) if complex_warn else 
error_warnings():
back_arr = write_return(arr, fobj, np.int8, intercept=128)
assert_array_equal([-128, -128, -127, -128], back_arr)
with pytest.raises(ValueError):
write_return(arr, fobj, np.int8, intercept=129)
with pytest.raises(ValueError):
write_return(arr_no_nan, fobj, np.int8, intercept=129)
# OK with nan2zero false, but we get whatever nan casts to
>   with pytest.warns(c_and_n_warn) if c_and_n_warn else 
> error_warnings():
E   Failed: DID NOT WARN. No warnings of type (,) were emitted.
E   The list of emitted warnings is: [].

nibabel/tests/test_volumeutils.py:700: Failed
=== warnings summary ===


Any idea what might be wrong here?

Kind regards
Andreas.

[1] 
https://ci.debian.net/data/autopkgtest/testing/armel/n/nibabel/30796127/log.gz

Am Sun, Jan 29, 2023 at 08:56:08AM +0200 schrieb Graham Inggs:
> Control: reopen -1
> 
> autopkgtests of nibabel/5.0.0-1 still fail in the same way on armel.
> 
> https://ci.debian.net/packages/n/nibabel/testing/armel/
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Remaining numpy 1.24 issues on 32bit architectures

[Andreas Tille]

Hi,

I think there are some remaining issues with numpy 1.24 migration on 32
bit architectures[1].

Here is one example:

_ TestSequence.test_getitem_with_slice_has_positional_metadata _

self = 

def test_getitem_with_slice_has_positional_metadata(self):
s = "0123456789abcdef"
length = len(s)
seq = Sequence(s, metadata={'id': 'id3', 'description': 'dsc3'},
   positional_metadata={'quality': np.arange(length)})

eseq = Sequence("012", metadata={'id': 'id3', 'description': 'dsc3'},
positional_metadata={'quality': np.arange(3)})
self.assertEqual(seq[0:3], eseq)
self.assertEqual(seq[:3], eseq)
self.assertEqual(seq[:3:1], eseq)

eseq = Sequence("def", metadata={'id': 'id3', 'description': 'dsc3'},
positional_metadata={'quality': [13, 14, 15]})
>   self.assertEqual(seq[-3:], eseq)
E   AssertionError: Seque[128 chars]: int32>
E   Stats:
E   length: 3
E   [14 chars]0 def != Seque[128 chars]: int64>
E   Stats:
E   length: 3
E   [14 chars]0 def

skbio/sequence/tests/test_sequence.py:748: AssertionError

How can I ensure that in both cases the arrays have the same type (I think it 
makes
no difference whether it is np.int32 or np.int64 as long as they are of same 
type.

Kind regards

 Andreas.

[1] 
https://buildd.debian.org/status/package.php?p=python-skbio=experimental

-- 
http://fam-tille.de

Re: Help with numpydoc needed (Was: Bug#1029245: nitime: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13)

[Andreas Tille]

Am Fri, Jan 20, 2023 at 04:24:07PM -0500 schrieb Éric Araujo:
> Le 20/01/2023 à 16:21, FC Stegerman a écrit :
> > Should that not use "func" instead of "inspect.getframeinfo"?
> 
> Yes of course!  I tested in a terminal to give valid code and forgot to
> replace my example function with the original variable name.  Thanks!

Thanks to both of you
Andreas. 

-- 
http://fam-tille.de

Help with numpydoc needed (Was: Bug#1029245: nitime: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13)

[Andreas Tille]

Control: tags -1 help

Hi,

I think I have fixed the numpy 1.24 issues that were causing this build
failure.  Unfortunately there are also numpydoc issues and I did not
found documentation about this when doing a web search.  I failed
finding something for inspect.formatargspec which I simply commented
out[1] (review for a better solution is welcome).

I finally do not have an idea how to replace:

   Handler  for event 
'autodoc-process-docstring' threw an exception (exception: 'FullArgSpec' object 
has no attribute 'replace')

which you can find in the latest build log in Salsa CI.

Any help is welcome

Andreas.

[1] 
https://salsa.debian.org/med-team/nitime/-/blob/master/debian/patches/numpydoc_1.24.patch#L15
[2] https://salsa.debian.org/med-team/nitime/-/jobs/3826316

-- 
http://fam-tille.de

Shouldn't packages maintained by DPT be found in salsa.d.o/python-team ?

[Andreas Tille]

Hi,

when looking at bug #1026525 I intended to checkout mitmproxy
and realised

$ apt showsrc mitmproxy | grep -e ^Vcs -e ^Maintainer 2>/dev/null
Maintainer: Debian Python Team 
Vcs-Browser: https://salsa.debian.org/debian/mitmproxy
Vcs-Git: https://salsa.debian.org/debian/mitmproxy.git

I would have expected that the package can be found under

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

Am I missing something?

Sebastien / Andrej are you aware of this bug which blocks a couple
of Python modules (python-uvicorn, python-scrapy)

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Helping hands needed to upgrade scipy

[Andreas Tille]

Hi Drew,

Am Wed, Jan 18, 2023 at 02:45:31AM +0100 schrieb Drew Parsons:
> On 2023-01-17 18:12, Andreas Tille wrote:
> > Hi,
> > 
> > I upgraded the experimental branch of scipy to contain the submodules
> > upstream includes.  I'm *not* convinced that we need them all -
> > hopefully we can get rid of boost (but upstream has some patches here)
> > and scipy-mathjax.
> > 
> > For the moment I've tried to build the experimental branch and ended
> > up with some issue where cython can't be found (should be cython3 for
> > sure)[1].
> > 
> > Unfortunately my spare time is occupied now by other more urgent tasks.
> > I'd be happy if someone else could review / pick up / continue from
> > here.
> 
> 
> The problem was not meson as such, but that upstream is only half using
> meson.  They must have decided they don't trust the way meson handles
> cython, and set up their own custom build tools for it, see
> https://github.com/scipy/scipy/pull/15407
> 
> That is, they hard-coded the cython executable name in
> scipy/_build_utils/cythoner.py
> 
> They actually did the same already in the old setuptools build
> (tools/cythonize.py), but we didn't notice since they had the breaking
> cython call wrapped in a try block which inspected a Cython class from
> inside python.  I raised an Issue about  whether cythoner.py should do the
> same in https://github.com/scipy/scipy/issues/17808
> We could argue the fault is debian's for not providing a cython executable
> (it does have -2 and -3 options for choosing the python version to work
> with).

Thanks for the clarification.

> I figure also we should use python3-mesonpy, since it's what upstream uses.
> Best not to diverge too far from their build method I think.

I'm perfectly fine with this approach.  That's why I initially pushed
meson-python to new.  I've just dput meson-python_0.12.0-2_source to let
it migrate to testing.  My attempt to use plain meson (as per upstream
readme) was just to shorten the time while meson-python was in new
queue.

> I've pushed commits updating cythoner.py to point cythoner.py at cython3.
> The main build now completes. Have to clean up test handling next:
> "FileNotFoundError: [Errno 2] No such file or directory:
> '/projects/python/build/scipy/.coveragerc'

Nice.  Hope my preparation (of meson-python and the multi-source tarball)
helped to move forward.  Please double check whether we really need the
boost code copy. 

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Help for python-pynndescent needed

[Andreas Tille]

Hi Malik,

Am Tue, Jan 17, 2023 at 07:53:32PM +0100 schrieb Malik:
> did you tried to run those tests with a lower python version, you are
> running tests with 3.10 [1]:
> 
> = test session starts
> ==
> platform linux -- Python 3.10.9, pytest-7.2.1, pluggy-1.0.0+repack --
> /usr/bin/python3.10
> 
> and the upstream is running those tests with max 3.9 :
> 
> platform linux -- Python 3.9.16, pytest-7.2.0, pluggy-1.0.0 --
> /opt/hostedtoolcache/Python/3.9.16/x64/bin/python

Lowering the Python3 version does not really help.  If the tests do
not run with the current default 3.11 than it will not migrate to
testing.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Help for python-pynndescent needed

[Andreas Tille]

Hi,

any idea why the build-time test of python-pynndescent fails[1]?

Any help would be welcome.

Kind regards
   Andreas.


[1] 
https://salsa.debian.org/python-team/packages/python-pynndescent/-/jobs/3811021

-- 
http://fam-tille.de

Helping hands needed to upgrade scipy

[Andreas Tille]

Hi,

I upgraded the experimental branch of scipy to contain the submodules
upstream includes.  I'm *not* convinced that we need them all -
hopefully we can get rid of boost (but upstream has some patches here)
and scipy-mathjax.

For the moment I've tried to build the experimental branch and ended
up with some issue where cython can't be found (should be cython3 for
sure)[1].

Unfortunately my spare time is occupied now by other more urgent tasks.
I'd be happy if someone else could review / pick up / continue from
here.

Kind regards
Andreas.


[1] https://salsa.debian.org/python-team/packages/scipy/-/jobs/3809903

-- 
http://fam-tille.de

Re: How to create multi-source tarball with different submodules for scipy

[Andreas Tille]

Am Tue, Jan 17, 2023 at 08:55:21AM +0800 schrieb Paul Wise:
> On Mon, 2023-01-16 at 17:05 +0100, Andreas Tille wrote:
> 
> > I intended to merge all these submodules in a single
> > scipy_1.10.0.orig-submodules.tar.gz.
> Any reason not to use one tarball per submodule?

Yes, this would need manual intervention for any change of the modules
(either we can get rid of one or upstream adds another one).  Single
tarballs also would not really solve the problem I was asking for.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Python 3.11 for bookworm?

[Andreas Tille]

Am Tue, Jan 17, 2023 at 01:04:50AM +0100 schrieb Thomas Goirand:
> > > #1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported 
> > > version
> > > #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version
> 
> I saw the above 2 were fixed.

Fixed in the sense that there was an upload closing the bug.  If you look
at

   https://tracker.debian.org/pkg/pandas
   https://tracker.debian.org/pkg/numba

you see multiple blockers for a testing migration.  So the problem for
the release persists.  I have confirmations of upstream of several
rdepends of these packages that they do not support 3.11 since these two
packages do not officially support Python 3.11 yet (the Debian packages
are coming with several patches - just one example of an answer from
upstream for python-cogent[1])
 
> > I'd like to add
> > 
> >#1027851 [src:pytorch] FTBFS with Python 3.11 as default version
> > 
> > also with lots of rdepends.
> 
> So we're back with one single bug. I remember seeing something similar in
> another package ... (scratching my head...). The latest version of the
> upstream code has some modifications to this broken Stream.cpp, have you
> tried to apply them?

No, I have not dealt with torch.  I just know that this package is in
the very competent hands of Mo Zhou who will know what to do.

> Do you have more to share? It's harder to help if you don't ask for it.
> IMO, feel free to give a full list of problematic packages in this list, so
> others may help.

As I said above the packages above are far from testing.  If someone
could lend helping hands to let these packages migrate this would be
really helpful.
 
> > I did not received any response to my "small" list.  What does this
> > mean for the transition to 3.11 process?
> 
> As much as I know, we're moving toward having Python 3.11 only in Bookworm.
> I'm not the person driving it though, and I am not in the best position to
> make such choice, but I support it (as I would prefer having the nice
> enhancements of Python 3.11 rather than lagging behind). Hopefully, I wont
> regret it and wont find more failures in "my" packages.

I understand the advantages of Python 3.11 and I'm not against releasing
Bookworm with it.  I'm against overlong freezing periods which I see as
the consequence of pushing Python 3.11 while sticking to the current
freeze shedule.  If we would decide that Python 3.11 is really important
I would consider shifting the testing period by one or two months.  We
have just seen that every full rebuild of the archive as Lucas recently
did creates quite some new RC bugs that are related to the Python
version bump and I expect more of these at the next rebuild.

> > > You mean you are fixing Python 3.10 manually in some packages diverging
> > > what will be default Python?
> > 
> > Any answer to this question?
> 
> All of my packages hopefully always test with all available versions, and
> most run autopkgtest. So I was warned early of Py 3.11 failures. They are
> all fixed, as much as I know (no opened RC bug remaining...). And no,
> forcing Python 3.10 is *NOT* an option, one must fix failures in Python
> 3.11.

Since you said above that we want to release with 3.11 only this becomes
clear.  Luckily the teams where I'm working in have also quite good
autopkgtest coverage so I'm positive about sensible warnings.
 
> > I keep on thinking that the timing is unfortunate and that it
> > will spoil the whole release process.
> 
> I'm sad to read this. Hopefully, this is truth only for some of the packages
> you care, and the vast majority of the packages are fine? I'm unfortunately
> not in a good position to tell (I didn't run any survey of broken
> packages...).

We are just a couple of people who are fighting hard through scientific
packages with a complex depency tree.  Some of them (like numba) take
ages to build even on amd64 (salsa CI is set to 6h here) and thus take
quite some time to fix.  As I said above I'm not against Python 3.11 per
see.  I'm simply afraid that this decision will delay the release
process and IMHO it makes sense to shift the schedule if we decide that
Python 3.11 is something we want.

Kind regards
   Andreas.

[1] https://github.com/cogent3/cogent3/issues/1263 

-- 
http://fam-tille.de

Re: Python 3.11 for bookworm?

[Andreas Tille]

Am Sat, Jan 07, 2023 at 09:05:21AM +0100 schrieb Andreas Tille:
> Hi Thomas,
> 
> Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand:
> > 
> > This has since already been discussed here: the final decision was to "at
> > least try 3.11", which is exactly what we're doing.
> 
> I admit I was not at site and may be I missunderstood what was finally
> decided.  From my perspective this "at least try" is that we are
> actually trying by having 3.11 as additional supported version which has
> triggered quite some work.  We are approaching the Transition and
> Toolchain Freeze in 5 days[1].  Given that switching default Python is a
> transition I wonder how you can assume that this is the right time to
> suggest this.  I would not have been that astonished if you would have
> done so say at first December last year.  But now its absolutely clear
> that a migration (with the "option" to revert which will cause extra
> work) will pour sand into the gears of the release process.

How will we decide whether the "at least try 3.11" is success or fail?
Did we defined anything I might have missed in terms of number of
packages that need to pass or number of packages we shoule not loose?
  
> > FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC
> > bugs push the 3 affected packages away from the release, it's just a "would
> > be nice" thing ATM):
> 
> That's a nice situation for the field you are working in.
>  
> > > If I would create a list mine whould be way longer.
> > 
> > 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

I'd like to add

  #1027851 [src:pytorch] FTBFS with Python 3.11 as default version

also with lots of rdepends.

> These packages have a sufficient amount of rdepends and usually trigger
> lots of other autopkgtest failures in other packages which will keep
> them out of testing for quite some time.  We could need all helping
> hands to fix these ... all noise that will happen afterwards will keep
> the relevant teams busy enough.

I did not received any response to my "small" list.  What does this
mean for the transition to 3.11 process?

> > > We are constantly beaten by removal from testing warnings
> > > even with Python3.11 as an option and sometimes we simply need to remove
> > > that option as a temporary means for bookworm.
> > 
> > Same over here. It's finally looking good for me after 2 months of heavy
> > efforts.
> 
> You mean you are fixing Python 3.10 manually in some packages diverging
> what will be default Python?

Any answer to this question?

> > > No better solution but better timing which means after bookworm release.
> > 
> > I've read *many* people saying it would be disappointing for them to see
> > their package removed because of Python 3.11. Well, please consider that it
> > would also be very disappointing to *not* have Python 3.11 for those who
> > managed constantly fix issues for it.
> 
> I can understand that we can never satisfy the needs of everybody.  My
> main problem is the extremely unfortunate timing that is happening now.
>  
> > The timing was exactly what was discussed during Debconf: it's very annoying
> > that this year, upstream Python release was one month late... we're only
> > trying to deal with it.
> 
> I do not remember that the scchedule was discussed.
> 
>* Add 3.11 as a supported Python3 version
> 
> was done in python3-defaults (3.10.6-2) at Fri, 11 Nov 2022 11:10:31
> +0200.  At 12. December Graham suggested on the behalf of the release
> team[2] to switch to 3.11.  If we would have acted upon this at that
> very time I would have considered this quite dense but the last chance
> to consider this in line with the "lets try" attempt discussed at
> DebConf.
> 
> Bug #1026825: python3.11 as default filed right before (21.12.) a series
> of holidays in the region of the world where lots of developers will
> typically reduce their activity which is closely followed by the first
> freeze step is IMHO something else.  Since I realised that the transition
> was started[3] our discussion is a bit useless.  I just want to explain
> the motivation why I sounded "astonished" since you said that you do
> not understood astonishment since we are following the suggested plan.

I keep on thinking that the timing is unfortunate and that it
will spoil the whole release process.

Kind regards
 Andreas.
 
> 
> [1] https://release.debian.org/testing/freeze_policy.html
> [2] https://lists.debian.org/debian-python/2022/12/msg00074.html
> [3] https://release.debian.org/transitions/html/python3.11-default.html
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

How to create multi-source tarball with different submodules for scipy

[Andreas Tille]

Hi,

I tried to create a multi-source tarball for scipy in its experimental
branch[1].  Upstream includes a set of git submodules in its build
process.  I intended to merge all these submodules in a single
scipy_1.10.0.orig-submodules.tar.gz.  This tarball is created with a
script[2] which makes sure that the exact directory structure as it is
used by upstream is conserved.  This directory layout is needed in the
build process.  Unfortunately `dpkg-source -x` extracts the content of
the submodules tarball into a subdirectory submodules/.

Is there any trick to unpack this tarball right into the root?
Otherwise I need to do some symlinks workaround in d/rules to provide
all files where these are needed.

Kind regards
   Andreas.

[1] https://salsa.debian.org/python-team/packages/scipy/-/tree/experimental
[2] 
https://salsa.debian.org/python-team/packages/scipy/-/blob/experimental/debian/get-submodules

-- 
http://fam-tille.de

Re: emperor: FTBFS/autopkgtest fail with pandas 1.5

[Andreas Tille]

Control: tags -1 help

Hi,

I just uploaded 1.0.3+ds-6 where the affected test suite error was
ignored just to have some installable python3-emperor in unstable and
enable building its Depends.  However, the problem is not fixed yet
(as per Salsa CI which has a fresh build log[1]) and upstream has not
responded for months[2].  Thus I'm hoping for help from the Debian
Python community.

Kind regards
   Andreas.

[1] https://salsa.debian.org/med-team/emperor/-/jobs/3789138
[2] https://github.com/biocore/emperor/issues/810

-- 
http://fam-tille.de