Re: morph's abandoned packages (list)

[Alexandre Detiste]

Just add yourself.

Le ven. 15 mars 2024 à 15:38, Martin  a écrit :
>
> On 2024-03-15 14:21, Alexandre Detiste wrote:
> > I would pick-up matplotlib I guess, I have some special connection to it,
>
> I *might* help on this, because we use matplotlib at $DAYJOB, but can't
> promise much, as my workload is already pretty high.

Re: OK to create a new package in "python-team/packages/"

[Nicholas D Steeves]

Carsten Schoenert  writes:

> Am 15.03.24 um 08:31 schrieb c.bu...@posteo.jp:
>
>> On the long run it is my goal to make the package [1] ready for official
>> upload. But I suspect this is a long way. So on short view that repo
>> will be for practicing only. Am I allowed to create such a repo in my
>> position?

Christian, have you filed an ITP (intent to package) yet?  If not,
please do so as soon as you can.

  https://wiki.debian.org/ITP

> There is no need to start any packaging work within the Salsa group of 
> the DPT. You can start any work within your namespace and move the 
> package to any other group later if needed and appropriate.
>
> And within your namespace you can e.g. do force pushing if you feel you 
> need to, within team space that's a no go.
>

+1 Carsten, that's my recommendation too, same rationale, and I'd add
that starting a project in personal namespace is zero risk.

  1. You have a remote backup of your work.
  2. You can do whatever you want with it (ie make branches and/or tags
  of experiments that may or may not work out, squash, rebase, force
  push--as noted--etc.)
  3. So it's lower stress and builds confidence faster than working
  directly in a team-managed namespace imho.
  4. Moving the repo during the sponsorship procedure can be a
  reassuring milestone.
  5. Doing Debian development "in the open" is sometimes an
  uncomfortable adjustment, and staging work in personal namespace is a
  more gentle path.

Regards,
Nicholas


signature.asc
Description: PGP signature

Re: Maintenance of python-resolvelib and python-commentjson

[Scott Kitterman]

On March 15, 2024 11:11:21 PM UTC, Bo YU  wrote:
>Hi!
>
>On Sat, Mar 16, 2024 at 1:18 AM Scott Kitterman  wrote:
>>
>> On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote:
>> > Hi Scott (2024.03.15_13:31:40_+)
>> >
>> > > I originally packaged python-resolvelib for pip and python-commentjson so
>> > > we could run python-resolvelib's tests.  Pip is no longer using the
>> > > packaged version.  It's currently used by pdm and ansible-core.
>> >
>> > However pip does still use resolvelib (albeit vendored). I make an
>> > effort to keep all pip's vendored dependencies in Debian so that we are
>> > familiar with them and track their security issues.
>> >
>> > So, I'll add myself as an uploader of resolvelib.
>>
>> Thanks.  I've removed myself.  Commentjson is required for the resolvelib
>> tests (and nothing else).  Do you want to do that one too?
>Would you mind me to take it? I would like to add myself as one of the
>uploaders before Stefano answers this.

I certainly don't mind.  It's up for grabs for anyone on the team.

Scott K

Re: Maintenance of python-resolvelib and python-commentjson

[Bo YU]

Hi!

On Sat, Mar 16, 2024 at 1:18 AM Scott Kitterman  wrote:
>
> On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote:
> > Hi Scott (2024.03.15_13:31:40_+)
> >
> > > I originally packaged python-resolvelib for pip and python-commentjson so
> > > we could run python-resolvelib's tests.  Pip is no longer using the
> > > packaged version.  It's currently used by pdm and ansible-core.
> >
> > However pip does still use resolvelib (albeit vendored). I make an
> > effort to keep all pip's vendored dependencies in Debian so that we are
> > familiar with them and track their security issues.
> >
> > So, I'll add myself as an uploader of resolvelib.
>
> Thanks.  I've removed myself.  Commentjson is required for the resolvelib
> tests (and nothing else).  Do you want to do that one too?
Would you mind me to take it? I would like to add myself as one of the
uploaders before Stefano answers this.

BR,
Bo

>
> Scott K

mkautodoc adopted

[Antonio Terceiro]

On Thu, Mar 14, 2024 at 06:20:11AM +, Julian Gilbey wrote:
> #1065143 O: mkautodoc -- AutoDoc for MarkDown

I picked this one up as I have at least one projects at $work that uses
it.


signature.asc
Description: PGP signature

Re: Maintenance of python-tomlkit

[Scott Kitterman]

Great.

Thanks,

I've already removed myself from uploaders in git.  Feel free to add yourself 
and go for it.

Scott K

On March 15, 2024 6:03:47 PM UTC, Emmanuel Arias  wrote:
>Hi Scott,
>
>I can take it.
>
>
>cheers,
>Emmanuel Arias
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
> ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: FA9DEC5DE11C63F1
> ⠈⠳⣄
>
>
>On Fri, Mar 15, 2024 at 2:50 PM Scott Kitterman 
>wrote:
>
>> This is another one I don't use anymore where I'm the sole uploader.
>>
>> It's got a fair number of rdepends, most notably poetry.  Any takers
>> before I
>> orphan it?
>>
>> Scott K

Re: Maintenance of python-tomlkit

[Emmanuel Arias]

Hi Scott,

I can take it.


cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: FA9DEC5DE11C63F1
 ⠈⠳⣄


On Fri, Mar 15, 2024 at 2:50 PM Scott Kitterman 
wrote:

> This is another one I don't use anymore where I'm the sole uploader.
>
> It's got a fair number of rdepends, most notably poetry.  Any takers
> before I
> orphan it?
>
> Scott K

Maintenance of python-tomlkit

[Scott Kitterman]

This is another one I don't use anymore where I'm the sole uploader.

It's got a fair number of rdepends, most notably poetry.  Any takers before I 
orphan it?

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Maintenance of python-resolvelib and python-commentjson

[Scott Kitterman]

On Friday, March 15, 2024 10:55:34 AM EDT Stefano Rivera wrote:
> Hi Scott (2024.03.15_13:31:40_+)
> 
> > I originally packaged python-resolvelib for pip and python-commentjson so
> > we could run python-resolvelib's tests.  Pip is no longer using the
> > packaged version.  It's currently used by pdm and ansible-core.
> 
> However pip does still use resolvelib (albeit vendored). I make an
> effort to keep all pip's vendored dependencies in Debian so that we are
> familiar with them and track their security issues.
> 
> So, I'll add myself as an uploader of resolvelib.

Thanks.  I've removed myself.  Commentjson is required for the resolvelib 
tests (and nothing else).  Do you want to do that one too?

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Request to join Debian Python team

[Daniel Echeverri]

Hello Team!

El sáb, 9 mar 2024 a la(s) 11:33 a.m., Daniel Echeverri (epsi...@debian.org)
escribió:

> Hi Team,
>
> I am interested in joining the team, because, actually I am working in
> adopting some python apps [1][2][3]
>
> My Salsa login is epsilon[4].
>
> Thanks!
>
> Regards
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065239
> [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065241
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065237
> [4]: https://salsa.debian.org/epsilon
>
> --
> Daniel Echeverri
> Debian Developer
> Linux user: #477840
> GPG Fingerprint:
> D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
>

I forgot to say, that I accept the policy team mentioned in
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Thanks in advance.

Kind Regards.


-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Re: Maintenance of python-cryptography

[Emmanuel Arias]

Hi!




On Fri, Mar 15, 2024 at 4:19 AM Thomas Goirand  wrote:

> On 3/13/24 18:34, 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).
> >
> > 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.
> >
> > You all made this mess.  Please clean it up.
>
> Absolutely not. Sandro did. There's btw absolutely no reason to declare
> a package as "orphan" if it is supposed to be team maintained. It's also
> a very bad behavior to do this silently, without telling the team about
> it, or taking part of the thread. I very much regret things are
> happening this way, but I don't think the rest of the team should be
> held responsible.
>
> If you have the list of the packages matching what you are saying,
> please do share.
>

I think you are looking for this
https://lists.debian.org/debian-python/2024/03/msg00045.html

>
> On 3/14/24 08:52, Andreas Tille wrote:
>  > 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).
>
> Me too. But I'm not surprised.
>
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>

Re: Maintenance of python-cryptography

[Scott Kitterman]

On March 15, 2024 3:47:25 PM UTC, Thomas Goirand  wrote:
>On 3/15/24 13:52, Scott Kitterman wrote:
>> 
>> 
>> On March 15, 2024 7:19:16 AM UTC, Thomas Goirand  wrote:
>>> On 3/14/24 08:52, Andreas Tille wrote:
 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).
>>> 
>>> Me too. But I'm not surprised.
>> 
>> I didn't have a list, I'm glad someone went through and made one.
>> 
>> Yes, he might have handled his departure from the team differently, but I 
>> found the entire discussion about changing the team policy on setting the 
>> maintainer very off putting.  I haven't talked to him about it beyond making 
>> sure he was aware of the discussion, so I don't know why he handled it the 
>> way he did, but I can easily imagine he was quite frustrated.
>> 
>> Frankly, I think statements like the above aren't particularly consistent 
>> with the project CoC and have me thinking again about if this is the kind of 
>> team I care to be involved with.
>
>Which part? The one where I am saying that I'm not surprised? That in no way 
>should be taken badly, or as an attack on him. Let me explain then.
>
>I too, would prefer if Sandro didn't leave, even if I had difficult moments 
>when communicating with him. I stated it already, I did appreciate his 
>contribution to the team, and to the project at large.
>
>Though it's a fact that I was not surprised, because you mentioned it. We knew 
>in advance it could happen. Looking backward, it seems it was inevitable, 
>unfortunately.
>
>I'd be very sad to see you go as well, please stay.
>
>> While the way he left the team is on him, the fact that it even came up is 
>> 100% on the people pushing this change.
>
>I do not agree. It came up because what it was generating (frustration, flames 
>about "rogue uploads", you name it...) had to be addressed.
>

My level of frustration is not declining.

I suggest to you that the source of the emails about rogue uploads were the 
rogue uploads.  I think that not following the rules and then complaining that 
people called you on not following the rules has an obvious source.

This was an avoidable own goal on the team's part because, in my judgement, 
there was too little openness to diversity of opinions on how to do things.

Scott K

Re: Maintenance of python-cryptography

[Thomas Goirand]

On 3/15/24 13:52, Scott Kitterman wrote:



On March 15, 2024 7:19:16 AM UTC, Thomas Goirand  wrote:

On 3/14/24 08:52, Andreas Tille wrote:

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


Me too. But I'm not surprised.


I didn't have a list, I'm glad someone went through and made one.

Yes, he might have handled his departure from the team differently, but I found 
the entire discussion about changing the team policy on setting the maintainer 
very off putting.  I haven't talked to him about it beyond making sure he was 
aware of the discussion, so I don't know why he handled it the way he did, but 
I can easily imagine he was quite frustrated.

Frankly, I think statements like the above aren't particularly consistent with 
the project CoC and have me thinking again about if this is the kind of team I 
care to be involved with.


Which part? The one where I am saying that I'm not surprised? That in no 
way should be taken badly, or as an attack on him. Let me explain then.


I too, would prefer if Sandro didn't leave, even if I had difficult 
moments when communicating with him. I stated it already, I did 
appreciate his contribution to the team, and to the project at large.


Though it's a fact that I was not surprised, because you mentioned it. 
We knew in advance it could happen. Looking backward, it seems it was 
inevitable, unfortunately.


I'd be very sad to see you go as well, please stay.


While the way he left the team is on him, the fact that it even came up is 100% 
on the people pushing this change.


I do not agree. It came up because what it was generating (frustration, 
flames about "rogue uploads", you name it...) had to be addressed.


Cheers,

Thomas Goirand (zigo)

Re: Maintenance of python-resolvelib and python-commentjson

[Stefano Rivera]

Hi Scott (2024.03.15_13:31:40_+)
> I originally packaged python-resolvelib for pip and python-commentjson so we 
> could run python-resolvelib's tests.  Pip is no longer using the packaged 
> version.  It's currently used by pdm and ansible-core.

However pip does still use resolvelib (albeit vendored). I make an
effort to keep all pip's vendored dependencies in Debian so that we are
familiar with them and track their security issues.

So, I'll add myself as an uploader of resolvelib.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: morph's abandoned packages (list)

[Martin]

On 2024-03-15 14:21, Alexandre Detiste wrote:
> I would pick-up matplotlib I guess, I have some special connection to it,
...
> Help is appreciated, I already cherry picked some commits from Ciel's PR.

I *might* help on this, because we use matplotlib at $DAYJOB, but can't
promise much, as my workload is already pretty high.

Cheers

Maintenance of python-resolvelib and python-commentjson

[Scott Kitterman]

I originally packaged python-resolvelib for pip and python-commentjson so we 
could run python-resolvelib's tests.  Pip is no longer using the packaged 
version.  It's currently used by pdm and ansible-core.

I am the sole uploader for both these packages and intend to orphan them, but 
if someone else once to take them over, please do so.  I have included the 
ansible-core maintainer in cc: since this most directly affects them.

Please speak up if you are interested.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: morph's abandoned packages (list)

[Alexandre Detiste]

Hi,

I would pick-up matplotlib I guess, I have some special connection to it,
It was one the packages that enabled me to escape
my horrible SAS-Insitute powered previous job/life.

It's a big one.

Help is appreciated, I already cherry picked some commits from Ciel's PR.

I already adopted python3-pygraphviz

Greetings

Re: Maintenance of python-cryptography

[Scott Kitterman]

On March 15, 2024 7:19:16 AM UTC, Thomas Goirand  wrote:
>On 3/13/24 18:34, 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).
>> 
>> 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.
>> 
>> You all made this mess.  Please clean it up.
>
>Absolutely not. Sandro did. There's btw absolutely no reason to declare a 
>package as "orphan" if it is supposed to be team maintained. It's also a very 
>bad behavior to do this silently, without telling the team about it, or taking 
>part of the thread. I very much regret things are happening this way, but I 
>don't think the rest of the team should be held responsible.
>
>If you have the list of the packages matching what you are saying, please do 
>share.
>
>On 3/14/24 08:52, Andreas Tille wrote:
>> 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).
>
>Me too. But I'm not surprised.

I didn't have a list, I'm glad someone went through and made one.

Yes, he might have handled his departure from the team differently, but I found 
the entire discussion about changing the team policy on setting the maintainer 
very off putting.  I haven't talked to him about it beyond making sure he was 
aware of the discussion, so I don't know why he handled it the way he did, but 
I can easily imagine he was quite frustrated.

Frankly, I think statements like the above aren't particularly consistent with 
the project CoC and have me thinking again about if this is the kind of team I 
care to be involved with.

While the way he left the team is on him, the fact that it even came up is 100% 
on the people pushing this change.  I don't think there's any evidence that 
some other reason is the cause.

Also, for packages which are team maintained, but only have one uploader, 
orphaning is exactly the correct thing to do when that person gives up the 
package.  A human uploader is required.  Similarly, it's the maintainer's call 
if a package should be removed or if it can remain maintained by QA.  While I 
agree more communication would have better, those are entirely appropriate 
actions for a team maintained package with a single uploader.

Scott K

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: morph's abandoned packages (list)

[Andrey Rakhmatullin]

I'm interested in helping with cryptography and pyopenssl, though I
haven't looked at these packages before.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: morph's abandoned packages (list)

[Thomas Goirand]

On 3/15/24 11:42, Michael Fladischer wrote:

Hi,

Am 14.03.2024 um 07:20 schrieb Julian Gilbey:
 #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG 
HTML5 specification


as I use html5lib in quite a few projects at work, I'd take over this 
one. Is there already a consensus to just ITA it and change Maintainer 
to DPT in the next upload?


I think that's fine. You can as well close the bug, and declare it as 
invalid, saying the package never had to be orphaned at all, since it 
was in the team. IMO, whatever you like as long as the package is kept 
alive and you're doing it in a timely manner. :)


Cheers,

Thomas Goirand (zigo)

Re: morph's abandoned packages (list)

[Thomas Goirand]

On 3/15/24 10:59, Andreas Tille wrote:

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


Yeah, I am. Networkx is a big piece.

FYI, I started working on it already, to upgrade it to 3.2.1. Just to 
build the doc, I had to package mercantile and contextily that were 
needed during the sphinx build of examples. I'll let you know my 
progress (currently, my contextily package is empty... :/ not sure what 
I'm doing wrong with pybuid again...).


Cheers,

Thomas Goirand (zigo)

Re: morph's abandoned packages (list)

[Michael Fladischer]

Hi,

Am 14.03.2024 um 07:20 schrieb Julian Gilbey:

 #1065142 O: html5lib -- HTML parser/tokenizer based on the WHATWG HTML5 
specification


as I use html5lib in quite a few projects at work, I'd take over this 
one. Is there already a consensus to just ITA it and change Maintainer 
to DPT in the next upload?


Regards,
Michael

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

[c . buhtz]

Close via 
https://wiki.debian.org/Python/GitPackaging?action=diff=97=98

Re: "debian/main" support or ticket open?

[c . buhtz]

Dear Simon,

thanks for drawing that big picture for me.

That info goes to my Zettelkasten.

Kind
Christian Buhtz

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

[c . buhtz]

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?

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.


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.



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.

Re: morph's abandoned packages (list)

[Jelmer Vernooij]

Hi Julian,

On Fri, Mar 15, 2024 at 10:21:49AM +, Julian Gilbey wrote:
> On Fri, Mar 15, 2024 at 10:04:42AM +, Jelmer Vernooij wrote:
> > On Thu, Mar 14, 2024 at 06:20:11AM +, Julian Gilbey wrote:
> > > [...]
> > Thanks for collecting the list of packages. I'm planning to adopt these:
> > 
> > > #1065327 O: python-levenshtein -- extension for computing string 
> > > similarities and edit distances
> > > #1065223 O: pysimplesoap -- simple and lightweight SOAP Library
> 
> I've just taken a look at python-levenshtein, as I remember the name
> now: it might make more sense for me to take it as it depends on
> rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting
> in NEW.  But if you want to take it, please feel free to do so!  (Once
> rapidfuzz makes it into unstable, a lot of debian/rules could probably
> also be simplified.)
I'm happy for you to take python-levenshtein (or co-maintain). It's just that 
I'm
using it in lintian-brush, so don't want to see it go away. :)

Cheers,

Jelmer

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

[Andrey Rakhmatullin]

On Fri, Mar 15, 2024 at 07:39:39AM +, c.bu...@posteo.jp wrote:
> 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.
Most of the Debian packaging docs assume at least basic knowledge about
Debian source and binary packages.

> Suggested solution:
> Create or locate the dsc-file definition in the wiki. 
I'm not sure if it makes sense to cross-link basic stuff on all wiki
pages, to be honest. But that's
https://wiki.debian.org/Packaging/SourcePackage


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: morph's abandoned packages (list)

[Jelmer Vernooij]

On Thu, Mar 14, 2024 at 06:20:11AM +, Julian Gilbey wrote:
> For information, here is a list of packages that morph has either
> requested removal of or orphaned.  If you are interested in taking one
> or more of them on, that would be great!
> 
> Recently-orphaned packages (removing those in wnpp which have been
> retitled "ITA") sorted alphabetically; these could, of course, be
> brought into team maintenance.
> 
Thanks for collecting the list of packages. I'm planning to adopt these:

> #1065327 O: python-levenshtein -- extension for computing string 
> similarities and edit distances
> #1065223 O: pysimplesoap -- simple and lightweight SOAP Library

Cheers,

Jelmer

Re: morph's abandoned packages (list)

[Julian Gilbey]

On Fri, Mar 15, 2024 at 10:04:42AM +, Jelmer Vernooij wrote:
> On Thu, Mar 14, 2024 at 06:20:11AM +, Julian Gilbey wrote:
> > [...]
> Thanks for collecting the list of packages. I'm planning to adopt these:
> 
> > #1065327 O: python-levenshtein -- extension for computing string 
> > similarities and edit distances
> > #1065223 O: pysimplesoap -- simple and lightweight SOAP Library

Hi Jelmer,

I've just taken a look at python-levenshtein, as I remember the name
now: it might make more sense for me to take it as it depends on
rapidfuzz and rapidfuzz-cpp, which I've just packaged and are sitting
in NEW.  But if you want to take it, please feel free to do so!  (Once
rapidfuzz makes it into unstable, a lot of debian/rules could probably
also be simplified.)

Best wishes,

   Julian

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: "debian/main" support or ticket open?

[Simon McVittie]

On Fri, 15 Mar 2024 at 08:10:55 +, c.bu...@posteo.jp wrote:
> To my knowledge in context of DPT and Salsa the branch name "debian/master"
> is used. When creating a new package are there any technical reasons not
> renaming that to "debian/main"?

Naming is a social thing, not a technical thing, so there is unlikely to be
any technical reason for or against any naming that fits the syntax rules.
One important non-technical reason not to choose a different branch name
for new packages is to keep all the team-maintained packages consistent.

If there is going to be any change to this branch
name, then I think it should be to debian/latest as per
 (which is the name used
in various other teams like GNOME), not debian/main.

Other teams don't use debian/main because that name would be confusing:
in Debian, "main" normally refers to the archive area that is not contrib,
non-free or non-free-firmware (or in Ubuntu, the archive area that is
not universe etc.).

There are basically two models in DEP-14:

1. The latest development happens on debian/latest, and might be uploaded
   to either unstable or experimental, whichever is more appropriate. If
   experimental contains a version that is not ready for unstable,
   and a new upload to unstable is needed, then create a temporary
   debian/unstable or debian/trixie branch for it.

2. Uploads to unstable are done from debian/unstable. Uploads to
   experimental are done from debian/experimental, when needed. There is
   no debian/latest branch.

(1.) probably makes more sense for large teams like this one (and it's
what the GNOME team does). (2.) can be useful if your upstream has a
long-lived development branch, but that's not going to be the case for
most DPT packages.

When the GNOME team switched from debian/master to debian/latest, it
was a coordinated change applied to every package maintained by the team.

smcv

Re: morph's abandoned packages (list)

[Timo Röhling]

Hi,

* 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.



   #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.


   #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.



Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

"debian/main" support or ticket open?

[c . buhtz]

Hello,

my question is technically only. I don't want to troll or start a 
discussion. So please just say yes or no. ;)


To my knowledge in context of DPT and Salsa the branch name 
"debian/master" is used. When creating a new package are there any 
technical reasons not renaming that to "debian/main"?


It might be that the existing toolchain is not yet able to adapt to it. 
Do we have an open ticket somewhere that I can monitor?


Thanks
Christian Buhtz

Re: OK to create a new package in "python-team/packages/"

[Carsten Schoenert]

Am 15.03.24 um 08:31 schrieb c.bu...@posteo.jp:


On the long run it is my goal to make the package [1] ready for official
upload. But I suspect this is a long way. So on short view that repo
will be for practicing only. Am I allowed to create such a repo in my
position?


There is no need to start any packaging work within the Salsa group of 
the DPT. You can start any work within your namespace and move the 
package to any other group later if needed and appropriate.


And within your namespace you can e.g. do force pushing if you feel you 
need to, within team space that's a no go.


--
Regards
Carsten

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

[c . buhtz]

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.


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

OK to create a new package in "python-team/packages/"

[c . buhtz]

Hi,
for practicing packaging I start again with the docu and stumbled across 
this paragraph:






It tells me to create a package in "python-team/packages/". I ask myself 
if I am allowed to and if it is a "good" idea?
Technically I am allowed. And formally also because I am an formally 
accepted member of the DPT. But I wouldn't call me an active member 
despite asking dump questions and wining about the docu. ;)


On the long run it is my goal to make the package [1] ready for official 
upload. But I suspect this is a long way. So on short view that repo 
will be for practicing only. Am I allowed to create such a repo in my 
position?


Kind
Christian

[1] -- 

Re: morph's abandoned packages (list)

[Thomas Goirand]

On 3/14/24 07:20, Julian Gilbey wrote:

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

There's also an old ITP that was closed:

 #1015231 ITP: sphinx-theme-builder -- tool for authoring Sphinx themes 
with a simple (opinionated) workflow

Best wishes,

Julian


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


I probably also need to keep pydot in shape.

Cheers,

Thomas Goirand (zigo)

Re: Maintenance of python-cryptography

[Thomas Goirand]

On 3/13/24 18:34, 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).

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.

You all made this mess.  Please clean it up.


Absolutely not. Sandro did. There's btw absolutely no reason to declare 
a package as "orphan" if it is supposed to be team maintained. It's also 
a very bad behavior to do this silently, without telling the team about 
it, or taking part of the thread. I very much regret things are 
happening this way, but I don't think the rest of the team should be 
held responsible.


If you have the list of the packages matching what you are saying, 
please do share.


On 3/14/24 08:52, Andreas Tille wrote:
> 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).

Me too. But I'm not surprised.


Cheers,

Thomas Goirand (zigo)