Re: matplotlib

[ciel]

Alexandre-san,

Sorry, it seems like I cannot contribute this because (at least) I'm
pretty not sure if I can transplant this line properly:

```
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
echo "backend  : TkAgg" > matplotlibrc
```

Ciel.

2024年3月19日(火) 19:02 Alexandre Detiste :
>
> If you have the time/will,
>
> I would suggest to overhaul build to from 7 to new debhelper 13
> with the automagic "%: dh $@" rule.
>
> Almost all other Python projects have already been converted.
>
>  wc -l */debian/rules
> 29 lincity-ng/debian/rules
> 25 lmfit-py/debian/rules
> 21 logbook/debian/rules
> 28 logilab-constraint/debian/rules
> 35 love/debian/rules
> 21 ltris/debian/rules
> 15 lua-lpeg/debian/rules
> 13 magic-wormhole/debian/rules
>206 matplotlib/debian/rules
> 14 mdp/debian/rules
> 18 microsoft-authentication-library-for-python/debian/rules
> 56 minetest/debian/rules
> 13 mir-eval/debian/rules
> 12 mrrescue/debian/rules
> 18 mu-cade/debian/rules

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

[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?
-- 
Brian May @ Debian

Bug#1067200: RM: cython-legacy -- ROM; Legacy transition package no longer needed

[Julian Gilbey]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-python@lists.debian.org

cython-legacy was introduced as a transitional measure until cython
version 3.x was supported by all source packages using cython.

There are now no source packages in unstable or testing (main)
depending on cython3-legacy and no binary packages either, so this
legacy package can be removed.  (It also has an RC bug against it, and
doesn't really work with Python 3.12.)

Best wishes,

   Julian

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: Salsa: Setup tokens

[Julian Gilbey]

Hi Christian,

On Tue, Mar 19, 2024 at 01:29:55PM +0100, Joost van Baal-Ilić wrote:
> Hi Christian,
> 
> Thanks for working on the documentation!
> 
> Op Tue, Mar 19, 2024 at 10:54:43AM + schreef c.bu...@posteo.jp:
> > Hello,
> > [...]
> 
> I can answer some of your questions, but not all of them.  What I usually do:
> 
> Get a personal access token "somesecret" from the salsa web interface.  Then:
> 
>  $ touch ~/.salsa-token
>  $ chmod og-r ~/.salsa-token
>  $ echo somesecret > ~/.salsa-token
>  $ SALSA_TOKEN=`cat ~/.salsa-token`
> 
> For some actions, the salsa(1) tool (and/or gitlab on salsa.d.o) seems to need
> such a token.  An SSH key is not always enough.
> 
> HTH, Bye,
> 
> Joost

Might also be worth taking a look at
https://wiki.debian.org/Javascript/Tutorial
which has a whole discussion about using salsa and tokens.

Best wishes,

   Julian

request for removal of my packages from the DPT namespace

[Jeroen Ploemen]

Dear team admins,

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.


pgpe_6_ro4Wy1.pgp
Description: OpenPGP digital signature

Re: Salsa: Setup tokens

[Joost van Baal-Ilić]

Hi Christian,

Thanks for working on the documentation!

Op Tue, Mar 19, 2024 at 10:54:43AM + schreef c.bu...@posteo.jp:
> Hello,
> 
> this is not a regular support message. I was not able to find clear
> information in the wiki or somewhere else. Please point me to it if exist.
> My intention is to improve the related wiki pages about it.
> 
> The command "salsa create_repo" do not work because of a missing
> SALSA_TOKEN. Technically it is clear to me why this happens. My question is
> how am I supposed to handle that in the context of DPT and its policy.
> 
> The error message:
> 
> salsa warn: SALSA_TOKEN not set in configuration files. Some commands
> may fail
> salsa warn: Project not created: Error POSTing
> https://salsa.debian.org/api/v4/projects (HTTP 401): Unauthorized
> {"message":"401 Unauthorized"} at
> /usr/share/perl5/Devscripts/Salsa/create_repo.pm line 36.
> 
> OK, I logged into Salsa and navigated to "User Settings" -> "Access Tokens".
> I assume I have to create a "Personal Access Tokens" instead of a "Feed
> Token" or "Incoming mail token"?
> 
> Are there any suggestions or recommendations from DPT about the "Expiration
> date"?
> 
> What is about "select scopes"? I see 10 unchecked items. They are described
> but it is not totally clear for new users what they are about or what the
> implications are. Any recommendations from DPT about that? Just select all?
> 
> A more broad question: I never used tokens before. I do use SSH keys when
> accessing Codeberg, GitHub or something else. Are this tokens a replacement
> for SSH keys? Should I prefer one of this two methods?

I can answer some of your questions, but not all of them.  What I usually do:

Get a personal access token "somesecret" from the salsa web interface.  Then:

 $ touch ~/.salsa-token
 $ chmod og-r ~/.salsa-token
 $ echo somesecret > ~/.salsa-token
 $ SALSA_TOKEN=`cat ~/.salsa-token`

For some actions, the salsa(1) tool (and/or gitlab on salsa.d.o) seems to need
such a token.  An SSH key is not always enough.

HTH, Bye,

Joost

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

[weepingclown]

Hi Christian,

Improving docs is a very important thing, I appreciate your effort.

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.

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

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] -- 
>

Salsa: Setup tokens

[c . buhtz]

Hello,

this is not a regular support message. I was not able to find clear 
information in the wiki or somewhere else. Please point me to it if 
exist. My intention is to improve the related wiki pages about it.


The command "salsa create_repo" do not work because of a missing 
SALSA_TOKEN. Technically it is clear to me why this happens. My question 
is how am I supposed to handle that in the context of DPT and its 
policy.


The error message:

salsa warn: SALSA_TOKEN not set in configuration files. Some 
commands may fail
salsa warn: Project not created: Error POSTing 
https://salsa.debian.org/api/v4/projects (HTTP 401): Unauthorized 
{"message":"401 Unauthorized"} at 
/usr/share/perl5/Devscripts/Salsa/create_repo.pm line 36.


OK, I logged into Salsa and navigated to "User Settings" -> "Access 
Tokens".
I assume I have to create a "Personal Access Tokens" instead of a "Feed 
Token" or "Incoming mail token"?


Are there any suggestions or recommendations from DPT about the 
"Expiration date"?


What is about "select scopes"? I see 10 unchecked items. They are 
described but it is not totally clear for new users what they are about 
or what the implications are. Any recommendations from DPT about that? 
Just select all?


A more broad question: I never used tokens before. I do use SSH keys 
when accessing Codeberg, GitHub or something else. Are this tokens a 
replacement for SSH keys? Should I prefer one of this two methods?


Thanks in advance
Christian Buhtz

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

[c . buhtz]

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] -- 

matplotlib

[Alexandre Detiste]

If you have the time/will,

I would suggest to overhaul build to from 7 to new debhelper 13
with the automagic "%: dh $@" rule.

Almost all other Python projects have already been converted.

 wc -l */debian/rules
29 lincity-ng/debian/rules
25 lmfit-py/debian/rules
21 logbook/debian/rules
28 logilab-constraint/debian/rules
35 love/debian/rules
21 ltris/debian/rules
15 lua-lpeg/debian/rules
13 magic-wormhole/debian/rules
   206 matplotlib/debian/rules
14 mdp/debian/rules
18 microsoft-authentication-library-for-python/debian/rules
56 minetest/debian/rules
13 mir-eval/debian/rules
12 mrrescue/debian/rules
18 mu-cade/debian/rules

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))

[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