Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'

2022-03-29 Thread Sandro Tosi
> > I dont think it's a problem per se, but i also want to understand if
> > the time debian-python@ dedicates to solve your issues is well spent.
>
> I'd say it is well spent.
>
> Andreas is herding a lot of cattle for Debian (as in
> packages, or people, or mentees). He's inventor of Debian
> Blends, leader of Debian Med, (co-|team-|sole-)maintainer for
> a lot of packages (neither of which releases him of due
> diligance, though).
>
> I also know him personally.
>
> I am sure his way of going about those Python tracebacks
> shows, indeed, a lack of Python knowledge, and of time, but
> bears neither laziness nor ill will nor entitlement syndrome.

I dont necessarily subscribe to the notion that debian-python is
essentially a help desk for people too busy to learn python (anyone
can always do less, and learn more; quality beats quantity in Debian),
but apparently people disagree with me on this, so i'll refrain from
bringing this up again.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Should we allow Janitor to commit directly to all DPT packages?

2022-03-29 Thread Sandro Tosi
Piotr, Stefano, Bernd, Scott, Ondrey,
as owners of the DPT salsa team (
https://salsa.debian.org/groups/python-team/packages/-/group_members?sort=access_level_desc)
can you approve (or deny) this request, and so give access to Janitor to
directly commit to all our repos, instead of filing MRs?

thanks!

On Thu, Feb 17, 2022 at 12:39 PM Sandro Tosi  wrote:

> Hello all,
> the question is essentially all in the subject line, and my answer is yes.
>
> I receive notifications for all MRs opened against DPT packages, and
> Janitor's are always pretty much ready to merge as is, and so i think
> we should let Janitor commit directly to the team packages.
>
> Jelmer is in CC (not sure if he's subscribed), in case he wants to
> chime in on the implication of this discussion.
>
> Regards,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi


Re: python-catalogue: AttributeError: type object 'EntryPoint' has no attribute '_from_text'

2022-03-17 Thread Sandro Tosi
Andreas,

> > Any hint would be welcome
>
> See: https://github.com/explosion/catalogue/issues/27
>
> TLDR: skip that test on Python 3.10 for now.

this seemed an easy enough issue that, with some common and expected
due diligence, you could have figured it out yourself: checking
upstream issue tracker and in general google for an error is something
i would say any maintainer is expected to do.

since it's not the first time you write to this list with a traceback
or error, asking for help, and the answer from here is generally
pretty straight-forward, i'm wondering why you were not able to find
the solution directly? some of your previous emails are really python
101 questions.

If it's because you have too many things on your plate, it's one
thing, if it's python knowledge is another, but it seems a pattern
that only you engage in.

I dont think it's a problem per se, but i also want to understand if
the time debian-python@ dedicates to solve your issues is well spent.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: I want to join the DPT

2022-03-17 Thread Sandro Tosi
> Sorry again. I recheck the #1007025 [0], it should be RFP tag.
> This is my misspelt in the first request email.
> So I think I can go to to work it :-)

OMG you're right! i guess morning coffee hadnt kicked in when first
replying. I would still contact anarcat before starting any work,
because they may already have started the packaging effort and you two
can collaborate. It's also possible nothing was done and so you can
start from scratch.

if you need help, you can let this mailing list know, or if you're
comfortable using IRC, you can ask questions in #debian-python on the
OFTC network

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: I want to join the DPT

2022-03-17 Thread Sandro Tosi
> >> My salsa account is vimerbf(but I do not know why it hint me 
> >> @vimerbf-guest)
> >>
> >> I have read the document: [1] and understand and follow it.
> >
> >according to 
> >https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team
> >you need to clarly state that you are accepting the policy, and that
> >statement is missing in your email.
> I have read the policy [0] and accept it.
> Is that OK? And you said "missing my email", How to add it?

you just did with the line above :)

> >> If there are any question please let me know.
> >
> >it looks like you may want to spend a bit more time gettingused to how
> >to collaborate in debian, and on our procedures: 2 simple and well
> >documented activities (ITP and joining this team) were not fully
> >grasped by you at the time you wrote this email.
> >
> >We are happy to welcome you when ready to join and in the meantime
> >help if you need further clarifications, but there may be other forums
> >better suited to novices.
> Yeah, The first time to join DPT is fail and I have to spend more time
> to collaborate with Debian. But this is not change my mind to contribute
> Debian as a ~8 year user.

i wouldnt consider this a failure, part of welcoming new contributors
is also telling them if they need to understand some procedures
better, and so be more effective. And by no mean my reply was meant to
discourage you from contributing to Debian, and i see you're still
determined to do so, which is great!

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: I want to join the DPT

2022-03-17 Thread Sandro Tosi
Hello Bo,

> My name is Bo, and want to contribute to Debian. And I
> noticed the ITP[0] and want to help package it. Because
> python is my one of favorite program language also :-)

an ITP means someone else is already working on that package, so that
may not be the right first package for you. did you reach out to the
person that opened that bug report? You may also want to look into
getting more  knowledgeable on how debian development works

> My salsa account is vimerbf(but I do not know why it hint me @vimerbf-guest)
>
> I have read the document: [1] and understand and follow it.

according to 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team
you need to clarly state that you are accepting the policy, and that
statement is missing in your email.

> If there are any question please let me know.

it looks like you may want to spend a bit more time gettingused to how
to collaborate in debian, and on our procedures: 2 simple and well
documented activities (ITP and joining this team) were not fully
grasped by you at the time you wrote this email.

We are happy to welcome you when ready to join and in the meantime
help if you need further clarifications, but there may be other forums
better suited to novices.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Bug#1006663: ITP: python-pyrcb2 -- A powerful asynchronous IRC bot library

2022-03-01 Thread Sandro Tosi
> I need it to properly package an IRC bot designed for the
> DPT itself.

please share your ideas for such bot here, before installing it the
irc channels, thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Salsa python-team write access for tiledb-py ?

2022-02-18 Thread Sandro Tosi
> I however do not have enough powers to add you into
> the team.

that's good, because we have a procedure in place that perspective
team members need to follow to join the team:
https://wiki.debian.org/Teams/PythonTeam/HowToJoin and
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team
-- Dirk, if you're interested, please follow that guide

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Should we allow Janitor to commit directly to all DPT packages?

2022-02-17 Thread Sandro Tosi
> I admit I'm hesitating a bit for different reasons.  While I agree that
> direct commits are better than MRs I found several DPT packages with
> very sensible changes in Git but no uploads following these.  For
> instance fixing VCS fields and Maintainer name should be followed by an
> according upload to make those changes visible to users and developers
> of the *packages* in Debian.
>
> In the Debian Med team for instance we do those automatic changes before
> uploading a package - say when upgrading to new upstream versions or
> fixing some bugs.  Than we run the Janitor scripts and other automatic
> changes which is all done in routine-update.  I personally find this
> workflow more convenient.  That way Debian Med team (as well as pkg-r
> team) are blacklisted for Janitor to not have competing changes inside
> the package.

thanks for bringing the perspective of how things are done in the Med
team, but it feels none of the points you mentioned nor the specific
Med team workflow apply here, or are relevant to just let Janitor
commit directly to our packages.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Should we allow Janitor to commit directly to all DPT packages?

2022-02-17 Thread Sandro Tosi
Hello all,
the question is essentially all in the subject line, and my answer is yes.

I receive notifications for all MRs opened against DPT packages, and
Janitor's are always pretty much ready to merge as is, and so i think
we should let Janitor commit directly to the team packages.

Jelmer is in CC (not sure if he's subscribed), in case he wants to
chime in on the implication of this discussion.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Bug#1005043: lintian: check that Python version numbers are not 0.0.0

2022-02-06 Thread Sandro Tosi
> Or export SETUPTOOLS_SCM_PRETEND_VERSION.
> https://github.com/pypa/setuptools_scm#environment-variables
>
> pybuild does this for you.

i dont remember the exact details, but sometimes that doesnt work:
even just building the source package (which runs dh clean, which
invokes setup.py clean) the build fails because "something something
SCM something".

It could be the specific package is doing things in a funky way but
that's my experience at least

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Please make a separate package for mistune 2.x

2022-02-05 Thread Sandro Tosi
> I'd like other python team member's opinion on this, and I'm not eager
> to maintain that legacy package, as I tend to not want to maintain
> obsolete software. Still, I can do the initial work of creating it.

i wouldnt expect much maintenance needed tho: 0.8.4 is essentially
dead upstream, so it will only need to be kept around until its rdeps
are ported to mistune 2.x

the proposal is "okay", it has the downside of requiring the current
rdeps to be updated to point to the new binary package name for the
old mistune, but it leaves the namespace open for mistune 2 to take
over python3-mistune bin pkg

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian

2022-01-17 Thread Sandro Tosi
> I think the proper fix would be to ask people to move away from
> `py3versions -r` if there is no X-Python3-Version, and use`py3versions
> -s` instead.
>
> As such, I think we should ask the Lintian maintainers to:
>
> 1. Change the desc for tag declare-requested-python-versions-for-test to
>
> The specified test attempts to query the Python versions
> requested by your sources with the command py3versions
> --requested but your sources do not actually declare those
> versions with the field X-Python3-Version.
> .
> Please query all supported Python versions with the command
> py3versions --supported in your test instead.
>
> 2. Change the desc for tag query-requested-python-versions-in-test to
>
> The specified test queries all supported Python versions with
> the command py3versions --supported but your sources
> request a specific set of versions via the field
> X-Python3-Version.
> .
> Please delete the field X-Python3-Version, as it is not needed.

+1

> AFAIU, the only valid use of X-Python3-Version would be a package that
> fails to build on an older but currently supported version of Python
> (let's say 3.9) but builds on the newer version (say 3.10). I think such
> use cases are pretty rare though.

maybe 
https://www.debian.org/doc/packaging-manuals/python-policy/#specifying-supported-versions
would need to be updated to clarify that the optional field is meant
to be used in exceptional circumstances (and state what they are
explicitly) and we generally expect the field to be absent.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Cleaning up the Salsa DPT landing page

2022-01-17 Thread Sandro Tosi
> If they apt source  their debian/control
> will have the obsolete Vcs-Browser information.  I think there should at least
> be a tombstone there for them to understand where the team went.

since we moved these repos within salsa, they are actually being
redirected to the right repo location. I took a random package that
still uses the all address:

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

and if i browse it, i get redirected to

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

with a window stating:

Project 'python-team/modules/webpy' was moved to
'python-team/packages/webpy'. Please update any links and bookmarks
that may still have the old path.

so it looks like even if downstreams have the old url, it will be
redirected to the right place and modules|apps can be removed

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Update packages to recent version

2022-01-13 Thread Sandro Tosi
> I intend to package paperless-ng.
>
> Many of its dependencies are packaged in Debian but in an older version.
> You can see the list at
> https://salsa.debian.org/mechtilde/paperless-ng/-/wikis/home

how did you come up with the list of packages that require updates? i
just checked one, uvicorn, and upstream requires 0.15.0
https://github.com/jonaswinkler/paperless-ng/blob/master/requirements.txt#L95
which is already in the archive, and still it's in your list of
packages that needs to be updated.

are you sure that list is accurate?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)

2022-01-01 Thread Sandro Tosi
> > > Sandro, do you have any other packages in mind?
> >
> > too many to scan by-eyes only, so i planned on running some queries on
> > UDD to figure some other package out, but the udd-mirror is down, so
> > i'm going to provide a list (if any) later on.
>
> In general we are open to hand over general packages that are not
> directly touching the medical / biological field to competent hands.  So
> just ping me and I'll try to respond as quick as possible.

with UDD-mirror U now, i was able to generate the below list. This
is in no way a request to move them, just a potential source of data
for your consideration

arcp 0.2.1-3
python3-arcp : (Archive and Package) URI parser and generator
enlighten 1.7.2-1
python3-enlighten : console progress bar module for Python3
python3-enlighten-doc : console progress bar module for Python3
(documentation)
python3-enlighten-examples : console progress bar module for
Python3 (examples)
h5sparse 0.1.0-4
python3-h5sparse : Scipy sparse matrix in HDF5
indexed-gzip 1.6.4-1
python3-indexed-gzip : fast random access of gzip files in Python
pyrle 0.0.33-2
python3-pyrle : run length arithmetic in Python
python-anndata 0.7.8-2
python3-anndata : annotated gene by sample numpy matrix
python-avro 1.10.2+dfsg-1
python3-avro : Apache Avro serialization system (Python 3 library)
python-ciso8601 2.2.0-1
python3-ciso8601 : fast ISO8601 date time parser for Python written in C
python-colormap 1.0.4-2
python3-colormap : ease manipulation of matplotlib colormaps and
color codecs (Python 3)
python-colormath 3.0.0-1.1
python3-colormath : Abstracts common color math operations (Python
3 version)
python-cooler 0.8.11-1
python3-cooler : library for a sparse, compressed, binary persistent storage
python3-cooler-examples : library for a sparse, compressed, binary
persistent storage (examples)
python-depinfo 1.7.0-1
python3-depinfo : retrieve and print Python 3 package dependencies
python-duckpy 3.2.0-2
python3-duckpy : simple Python library for searching on DuckDuckGo
python-easydev 0.12.0+dfsg-1
python3-easydev : common utilities to ease the development of
Python packages (Python 3)
python-etelemetry 0.2.0-4
python3-etelemetry : lightweight Python3 client to communicate
with the etelemetry server
python-fitbit 0.3.1-2
python-fitbit-doc : FitBit REST API Client Implementation - Documentation
python3-fitbit : FitBit REST API Client Implementation - Python 3
python-hdmedians 0.14.2-3
python3-hdmedians : high-dimensional medians in Python3
python-leidenalg 0.8.8-1
python3-leidenalg : Python3 implementation of the Leiden algorithm in C++
python-lzstring 1.0.4-1.1
python3-lzstring : LZ-based compression algorithm for Python
(Python 3 version)
python-matplotlib-venn 0.11.6-2
python3-matplotlib-venn : Python 3 plotting area-proportional two-
and three-way Venn diagrams
python-multipletau 0.3.3+ds-3
python-multipletau-doc : documentation for multipletau Python module
python3-multipletau : multiple-tau algorithm for Python3/NumPy
python-multisplitby 0.0.1-4
python3-multisplitby : Python3 module to create iterables split on
arbitrary separators
python-ncls 0.0.63+ds-1
python3-ncls : datastructure for interval overlap queries
python-pipdeptree 2.2.0-2
python3-pipdeptree : display dependency tree of the installed
Python 3 packages
python-pyflow 1.1.20-3
python3-pyflow : lightweight parallel task engine for Python
python-pynndescent 0.5.2+dfsg-1
python3-pynndescent : nearest neighbor descent for approximate
nearest neighbors
python-pypubsub 4.0.3-5
python3-pubsub : Python 3 publish-subcribe library
python-sinfo 0.3.1-2
python3-sinfo : print different version information for loaded modules
python-spectra 0.0.11-3
python3-spectra : Easy color scales and color conversion for
Python (Python 3 version)
python-stdlib-list 0.8.0-4
python3-stdlib-list : List of Python Standard Libraries (2.6-7, 3.2-9)
python-streamz 0.6.3-1
python3-streamz : build pipelines to manage continuous streams of data
python-stubserver 1.1-2
python3-stubserver : mock tester of external web dependencies for Python
python-tinyalign 0.2-5
python3-tinyalign : numerical representation of differences between strings
python-typechecks 0.1.0+ds-2
python3-typechecks : express constraints on types
python-upsetplot 0.6.0-2
python3-upsetplot : Draw Lex et al.'s UpSet plots with Pandas and Matplotlib
python-wdlparse 0.1.0-2
python3-wdlparse : Workflow Description Language (WDL) parser for Python
python-wordcloud 1.8.1+dfsg-2
python3-wordcloud : little word cloud generator in Python
python-xopen 1.2.1-3
python3-xopen : Python3 module to open compressed files transparently
smart-open 5.2.1-3
python3-smart-open : utils for streaming large files
sorted-nearest 0.0.31+dfsg-1
python3-sorted-nearest : Cython helper library for pyranges
sphinxcontrib-autoprogram 0.1.7-1

Re: Transfering packages from Debian Med to DPT (Was: Please enable me transfering python-bioblend to Debian Med team)

2021-12-23 Thread Sandro Tosi
> Thus I moved mypy now and moved it to DPT[2].  Feel free to add yourself
> to Uploaders and upload with the new location.

thanks!

> Sandro, do you have any other packages in mind?

too many to scan by-eyes only, so i planned on running some queries on
UDD to figure some other package out, but the udd-mirror is down, so
i'm going to provide a list (if any) later on.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Please enable me transfering python-bioblend to Debian Med team

2021-12-22 Thread Sandro Tosi
Andreas,

On Wed, Dec 22, 2021 at 1:42 PM Andreas Tille  wrote:
>
> Am Wed, Dec 22, 2021 at 06:13:32PM +0100 schrieb Pierre-Elliott Bécue:
> >
> > Andreas Tille  wrote on 21/12/2021 at 15:43:11+0100:
> >
> > > Ping?  Could any admin of Debian Python Team help out?  We can simply
> > > recreate the repository in Debian Med and move on ... but that might
> > > be confusing for users who will find two clones in differen teams.
> > > Thank you, Andreas.
> >
> > I'm sorry but pressuring to take over a package is not really fine. If
> > you're not happy with the time it takes for an answer, you can try to
> > fill an ITS and if the procedure goes to its end then you may take over.
>
> Please note:  The people involved are the same.  We are members of
> both teams but consider the Debian Med team more appropriate.  We
> are simply missing the permissions to do the move properly.

since you're talking about the appropriate team to maintain a given
package (and it seems debian-med may be more suited for bioblend), are
you also going to move all non-bio/med python packages from debian-med
to dpt? because that's the more appropriate place for things like
mypy.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: DPT repositories checks/"violations" report

2021-12-11 Thread Sandro Tosi
> I'm in the process of writing a tool to uniform the repo configuration
> in python-team/package
>
> - add integration: Emails on push
> - remove integration Irker
> - add webhook: KGB (or edit to remove all the extra parameters set,
> which are the default values anyway)
> - add webhook: tagpending

the tool is now ready:
https://github.com/sandrotosi/dpt-repos-check/blob/main/dpt-fix-integrations-webhooks.py

> I'll write back here when i think it's ready for review and request
> authorization to run it.

can any admin check if the changes look sane (i've run a test run on
~25 repos) and that i'm allowed to run this across the whole
`packages` subgroup on salsa?

> I think there's still one point we need to figure out: how to make
> these remarks known to the packages maintainers, instead of all of
> them just being in a text file.

This is still an open point, and i welcome ideas

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: DPT repositories checks/"violations" report

2021-12-09 Thread Sandro Tosi
> When we did the migration to git, there weren't good tools for managing
> the setup of the salsa repos (hooks, etc.) yet.  I'd assume those exist
> now, we should check in with what other teams are doing. That stuff can
> all be fixed in one run of a tool, I'd assume.

yeah i figured that much, and that made sense at that time.

I modified [1] to automatically create the salsa repo enabling both
KGB and tagpending webhooks, but the `salsa` tool doesnt support
setting integrations, so that will need to be fixed later on.

[1] https://github.com/sandrotosi/pypi2deb/tree/morph

I'm in the process of writing a tool to uniform the repo configuration
in python-team/package

- add integration: Emails on push
- remove integration Irker
- add webhook: KGB (or edit to remove all the extra parameters set,
which are the default values anyway)
- add webhook: tagpending

I'll write back here when i think it's ready for review and request
authorization to run it.

I think there's still one point we need to figure out: how to make
these remarks known to the packages maintainers, instead of all of
them just being in a text file.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: sphinxext-opengraph build with tests.

2021-12-05 Thread Sandro Tosi
Hello Chiara,

> I have committed to salsa a new version of sphinxext-opengraph running tests 
> at the build time.
> There are no updates on upstream.
>
> It's not urgent, but if someone want to check my solution (as this is my 
> first using autopkgtest)...

i dont think that's how you should run autopkgtests: they are supposed
to run against the installed package (the way you set them up is
essentially equivalent to how they run during build).

For an example of what that means, you can have a look at (shameless
plug): 
https://salsa.debian.org/python-team/packages/httpx/-/tree/debian/master/debian/tests

> Also, Sandro do you mind letting me know if this is worth a new package 
> version 0.5.0-2? I will update changelog accordingly if needed.

it is my opinion that every time you make a change to a package, you
should also add a relevant entry in debian/changelog, describing what
the change is, and the updated d/changelog should be included in the
same commit introducing the change (as oppose to write
debian/changelog all at once before an upload). With that said, yes a
-2 would be nice, and once autopkgtest is fixed i think it would
appropriate to upload the package, without waiting for a new upstream
release.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Request to join the team

2021-12-04 Thread Sandro Tosi
Hello Yago,

> I am the current maintainer of python-tabulate [1], and would like to
> join the team as I believe it makes more sense for the package to be
> under its roof. The goal is to prevent issues should I be unavailable
> in the future, but I will try continue maintaining it within the team
> for now.

you only maintain this package, you have not uploaded it in more than
3.5 years, and that package received 3 NMUs in the last 2 years; how
can you reassure that you're going to actually take care of this
package moving it to DPT, instead of letting the team essentially
maintain it?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: sphinxext-opengraph new version 0.5.0 ready for upload

2021-11-29 Thread Sandro Tosi
On Mon, Nov 29, 2021 at 2:53 PM Chiara Marmo  wrote:
>
> Dear list, Sandro,
>
> the 0.5.0 version of sphinxext-opengraph is on salsa ready for upload.

I checked it, and it looks good to me so i've uploaded it, thanks for
your contribution to Debian!

For the next upload, it would be good to run tests at build-time,
something that's currently not happening (and ideally add autopkgtest
too)

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



DPT repositories checks/"violations" report

2021-11-26 Thread Sandro Tosi
Hello,
while working on something else[1], i noticed how many of the
repositories in the DPT salsa group are in poor shape:

* missing branches
* changes not pushed to salsa
* general misalignment in configuration/setup/organization
* many other small nuances

[1] https://github.com/sandrotosi/debian-python-team-tracker

That makes it hard to make mass work as in [1], so I thought it would
be interesting to have a tool to evaluate the amount of issues our
repos have, and identify such "violations" so that they can be
addressed.

That information is now available at [2].

[2] https://github.com/sandrotosi/dpt-repos-check/blob/main/violations.txt

please take the content with caution, as it's still an early, raw
draft (i spot-checked some of the reported issues, but there could be
bugs/issues) and it contains data that can be outdated (see below re
caching); the fact that the report indicates only 43 repos are without
violations is a bit disarming, but i think the tool tries to err on
the side of verbosity and pedantry, with 2 level of violations (ERROR
and WARNING) to mark which ones are the most important that require
immediate attention vs the nice-to-have ones.

The checks are under-documented, although they should be somehow
self-explanatory. While the current format is just a text file, I plan
on getting it converted to markdown, although I'm still not sure how
to convey that amount of information effectively.

The report is extremely intensive to generate, as it needs to make 10+
API calls to salsa.d.o for each repository, and it gets throttled
quite early in the run (i got away in dev by installing a cache, so
that i could test it without hitting salsa every time, but that makes
some info stale); for that reason, and if we decide is valuable to
generate it periodically, i don't expect to be able to run it more
than once a month (maybe once a week? TBD).

Comments, critics and improvements are welcome.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: sphinxext-opengraph_0.4.2-1_amd64.changes ACCEPTED into unstable, unstable

2021-11-23 Thread Sandro Tosi
On Tue, Nov 23, 2021 at 10:40 PM Chiara Marmo  wrote:
>
> Dear Sandro,
>
> thank you very much for your answer and your sponsoring.
>
>>   If you want it to be sponsored,
>> please add a new entry to debian/changelog with a "source only
>> upload"-like text, set the suite to `unstable` (so not UNRELEAED as
>> it's usually created by default), commit and git push and let this
>> list know (or you can reach out to me privately, that's fine too).
>
>
> Done.
>
>> The sponsor usually takes care of git tagging and uploading to the archive.
>
>
> I have untagged.

please note you removed a valid tag, which was for version 0.4.2-1
(the one that just got accepted from NEW), I've restored it. since you
never tagged the new -2 (because there was no new entry in the
changelog at that time) there was no tag to be removed.

Anyway, i've uploaded 0.4.2-2 to unstable, thanks for your
contribution to Debian!

There's also a new upstream release, 0.5.0, which would be nice for
you to package

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: sphinxext-opengraph_0.4.2-1_amd64.changes ACCEPTED into unstable, unstable

2021-11-23 Thread Sandro Tosi
i can sponsor this package, but...

> The package is tagged and ready for upload at
> https://salsa.debian.org/python-team/packages/sphinxext-opengraph

... that doesnt appear to be the case. If you want it to be sponsored,
please add a new entry to debian/changelog with a "source only
upload"-like text, set the suite to `unstable` (so not UNRELEAED as
it's usually created by default), commit and git push and let this
list know (or you can reach out to me privately, that's fine too).

The sponsor usually takes care of git tagging and uploading to the archive.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Status of python-charset-normalizer in Debian

2021-11-16 Thread Sandro Tosi
On Sun, Nov 14, 2021 at 8:52 PM Stefano Rivera  wrote:
>
> Hi Sandro (2021.11.15_01:05:12_+)
> > > I filed https://github.com/Ousret/charset_normalizer/issues/138
> > > upstream.
> >
> > In the interest of moving things along, and while we wait for upstream
> > action on it, should we Files-Excluded: data/ , re-import the upstream
> > tarball, and disable tests/test_cli.py and
> > tests/test_full_detection.py (which appear to be the only 2 test files
> > using the data directory)?
>
> +1 to that.

the conversation continued on #debian-ftp, where we came to the
understanding the REJECT was due to a misunderstanding of how some
Licenses information were reported, so i've just reuploaded
python-charset-normalizer as-is from the git repository

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Status of python-charset-normalizer in Debian

2021-11-14 Thread Sandro Tosi
> FWIW: $ grep charset-normalizer /srv/ftp-master.debian.org/log/2021-11
> 20211106022017|clean-queues|dak|move file to 
> morgue|Incoming/REJECT|python-charset-normalizer_2.0.6-1_amd64.changes|/srv/ftp-master.debian.org/morgue/queues/2021/11/06

oh, didnt know we could search for that, thanks

> So, looks like it got a reject.
> My guess would be due to data/sample*
>
> I filed https://github.com/Ousret/charset_normalizer/issues/138
> upstream.

In the interest of moving things along, and while we wait for upstream
action on it, should we Files-Excluded: data/ , re-import the upstream
tarball, and disable tests/test_cli.py and
tests/test_full_detection.py (which appear to be the only 2 test files
using the data directory)?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Status of python-charset-normalizer in Debian

2021-11-11 Thread Sandro Tosi
Hello Dominik,
can you update the DPT on the status of python-charset-normalizer? it
used to be in NEW, but now i cant find it there and it's not in the
archive.

This package is needed at least by httpx, which cannot be upgraded to
its latest version, thus preventing a growing set of packages to be
upgraded, many of them becoming RC and in danger of being removed from
testing.

Thanks,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Question on installing packages via the Python APT library

2021-11-07 Thread Sandro Tosi
python-apt is not written nor maintained by this team, but rather
(from https://tracker.debian.org/pkg/python-apt) by the APT Dev team
and in particular by Julian Andres Klode (both in CC): please continue
the discussion with them

On Sun, Nov 7, 2021 at 6:21 PM Hunter Wittenborn
 wrote:
>
> Hi! I'm currently working on a project that's going to be using the Python 
> APT library to handle some package installation, but I've got a question on 
> how exactly a certain thing is working:
>
> I've gotten everything up to the actual installation of packages done (up to 
> the point of calling 'DepCache.commit()', but once I get to the 'commit()' 
> stage I can't figure out how to control the output of the 'commit()' call in 
> a way I'm wanting.
>
> Going with the two classes that are specified for the 'commit()' function, I 
> currently have the following implemented (I haven't exactly figured out what 
> to put in each one yet, as I'm still trying to figure out all how this step 
> works):
>
> acquire_progress: 
> https://gist.github.com/hwittenborn/56fa689b86396a904155e4b1b5be817a
> install_progress: 
> https://gist.github.com/hwittenborn/0eb762abdfeb96e2c1cbf4f5b6a975f3
>
> The 'tap.message' library being used inside both of those classes is just a 
> message system for my program, they don't do anything particularly important 
> that would affect anything at all.
>
> The acquire_progress stage *appears* to be working fine, though the packages 
> I downloaded were quite small so I didn't really get a chance to see if it 
> just did some weird stuff like with install progress;
>
> The problem with install_progress is that it's exiting my program, and then 
> proceeding with installing packages, as if it starts installing packages in 
> the background. How exactly should I go about waiting for it to finish though?
>
> On a side note, I'm seeing this text whenever it (presumably) gets to the 
> install part:
>
> """
> custom fork found
> got pid: 31873
> got pid: 0
> got fd: 4
> """
>
> Is there any way I can hide that? I'm thinking it's from the 'fork()' call in 
> the install_progress class, but the Python APT documentation is recommending 
> not changing that [1], so I wasn't really sure.
>
> [1]: 
> https://apt-team.pages.debian.net/python-apt/library/apt.progress.base.html#apt.progress.base.InstallProgress.fork
>
> Thanks, anything helps!
>
> ---
> Hunter Wittenborn
> hun...@hunterwittenborn.com
> https://github.com/hwittenborn
>
>
>
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-10-28 Thread Sandro Tosi
couple of features recently introduced that may interest people:

- rudimental support for autopkgtests: autodep8 + a stub for
developers to setup autopkgstests for unittests
- salsa repo creation, if SALSA_TOKEN is available in ~/.devscripts;
this also setup the KGB webhook to post in #d-p-changes

I'm definitely no expert in autopkgtests, so if there's something to
improve, lemme know.

On Sun, Apr 25, 2021 at 12:22 AM Sandro Tosi  wrote:
>
> Hello,
> recently i've been making some enhancements to py2dsp (part of
> pypi2deb[1] ); for those who dont know what that is, py2dsp is a tool
> that, given a PyPI project, will create an (initial) Debian source
> package.
>
> [1] https://packages.qa.debian.org/p/pypi2deb.html
>
> I've just finished a patch that extend py2dsp to fetch the upstream
> tarball from GitHub instead; nowadays this is my preferred source for
> upstream tarballs, given it contains all the project files (not only
> the one published on pypi via sdist, often missing important files
> like tests, or doc sources, etc).
>
> it's currently available at the git branch at [2] (there's a PR open at [3]):
>
> [2] https://github.com/sandrotosi/pypi2deb/tree/morph
> [3] https://github.com/p1otr/pypi2deb/pull/27
>
> once you cloned/checkout that branch, you can run:
>
> $ ./py2dsp --profile dpt --distribution unstable --revision 1 --github
> https://github.com/USER/PROJECT
>
> alternatively, you can specify an additional argument ``,
> if PROJECT is not the source name you want to use in Debian:
>
> $ ./py2dsp --profile dpt --distribution unstable --revision 1 --github
> https://github.com/USER/PROJECT 
>
> and it will create the source package in the `result/` directory.
>
> Let me know if you find this useful and if there are
> issues/enhancement you'd like to see added/fixed.
>
> Regards,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: python-anyio not building?

2021-10-23 Thread Sandro Tosi
> I don't get why python-anyio is stuck ; I certainly didn't upload it
> without trying to build it, and I just tried again and there was no
> issue :
> https://buildd.debian.org/status/package.php?p=python-anyio
>
> Does someone have a clue what is happening?

it's marked as installed now, which means it was built properly (i
think tracker/pts will take some time to reflect that in the excuses
block)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: request to join python-team/packages group on salsa

2021-10-03 Thread Sandro Tosi
> I sometimes need to add or make updates to python packages. Currently, I
> just uploaded a newer upstream version of httpbin and I'd like to push
> the changes to the git repository, which resides in python-team/packages.

httpbin has been orphaned, so it appears as if this repo should be
moved from the python-team to the debian namespace (only admins can do
that).

please let us know if you still want to join the team.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

2021-09-29 Thread Sandro Tosi
> That's an upstream bug then, and upstream should fix that and ship a complete 
> source tarball.
>
> I always submit pull requests updating MANIFEST.in and until now, all 
> upstreams have accepted them.

and that will require an upstream new release, which does not help
when you want/need to package the current one.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

2021-09-29 Thread Sandro Tosi
> One note: I'd consider watching for PyPI instead of GitHub.

there was actually a recent discussion on this list, discouraging from
using PyPI in favor of github, since GH tarball usually contains docs,
tests, and other files useful when building from source, usually not
included in tarball released to users, ie pypi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Potential issue with numpy

2021-09-29 Thread Sandro Tosi
Please do report bugs in the BTS when there's a problem with a package

On Wed, Sep 29, 2021 at 10:32 AM Andreas Tille  wrote:
>
> Hi,
>
> in the issue I filed against nipype I was asked to try to rebuild numpy
> and see whether this might make a diffence.  So I tried
>
>   dget http://deb.debian.org/debian/pool/main/n/numpy/numpy_1.19.5-1.dsc
>   cd numpy-1.19.5
>
> and have rebuild it in a recent pbuilder environment.  This ends up in
>
> DISTUTILS.rst.txt:386: WARNING: Unparseable C cross-reference: '/**end 
> repeat1**/'
> Invalid C declaration: Expected identifier in nested name. [error at 0]
>   /**end repeat1**/
>   ^
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 280, in 
> build_main
> app.build(args.force_all, filenames)
>   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 337, in 
> build
> self.builder.build_update()
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 293, in build_update
> self.build(to_build,
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 357, in build
> self.write(docnames, list(updated_docnames), method)
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 531, in write
> self._write_serial(sorted(docnames))
>   File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 
> 541, in _write_serial
> self.write_doc(docname, doctree)
>   File "/usr/lib/python3/dist-packages/sphinx/builders/html/__init__.py", 
> line 626, in write_doc
> self.docwriter.write(doctree, destination)
>   File "/usr/lib/python3/dist-packages/docutils/writers/__init__.py", line 
> 78, in write
> self.translate()
>   File "/usr/lib/python3/dist-packages/sphinx/writers/html.py", line 70, in 
> translate
> self.document.walkabout(visitor)
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 214, in 
> walkabout
> if child.walkabout(visitor):
>   [Previous line repeated 1 more time]
>   File "/usr/lib/python3/dist-packages/docutils/nodes.py", line 206, in 
> walkabout
> visitor.dispatch_visit(self)
>   File "/usr/lib/python3/dist-packages/sphinx/util/docutils.py", line 477, in 
> dispatch_visit
> method(node)
>   File "/usr/lib/python3/dist-packages/sphinx/writers/html5.py", line 417, in 
> visit_literal_block
> highlighted = self.highlighter.highlight_block(
>   File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 149, in 
> highlight_block
> lexer = self.get_lexer(source, lang, opts, force, location)
>   File "/usr/lib/python3/dist-packages/sphinx/highlighting.py", line 127, in 
> get_lexer
> lexer = lexer_classes[lang](**opts)
> TypeError: 'NumPyLexer' object is not callable

there's a new sphinx version in unstable (4.2.0), likely other pieces
of the infrastructure around numpy and its doc need updating. The fact
we dont have access to the build log makes it hard to pin point the
issue.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: RFS: still looking for sponsor for new version of sentry-python (#990519)

2021-09-28 Thread Sandro Tosi
Hello Eberhard,

On Tue, Sep 28, 2021 at 12:10 PM Eberhard Beilharz  wrote:
>
> Hi,
>
> I'm still looking for someone who'd be able and willing to upload the
> new version of sentry-python (1.4.2).

did you contact the current maintainer about this? Adding William to
the recipients list

> The version currently available in
> Debian (0.13.2) is not compatible with the latest version of the Sentry
> server and thus breaks any software that depends on the 1.x version.
>
> Or what is missing that prevents someone from moving this forward?
>
> Thanks,
>  Eberhard
>
>
> https://mentors.debian.net/package/sentry-python/
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990519

This package repository is hosted on the Debian Python Team salsa
group, at https://salsa.debian.org/python-team/packages/sentry-python
while you're proposing an upload outside of this setup via Mentors.
It's usually inappropriate to seek outside sponsors for
team-maintained packages, because that tends to leave the canonical
git repo outdated, forcing people to do extra work to reconcile
history.

Please submit a MR for the upstream, pristine-tar, and master branches
(one MR for each branch) with your changes on salsa, and we can review
them.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

2021-09-21 Thread Sandro Tosi
On Tue, Sep 21, 2021 at 5:00 PM Antonio Terceiro  wrote:
>
> On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > > That's because gbp does not use pristine-tar by default, and
> > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > > fix that.
> >
> > I dont think this is the right approach: the default options to work
> > on DPT packages should be in gbp default config file (or in another,
> > global, config file), and not live in each and every package
> > debian/gbp.conf file; it is already inconsistently maintained with
> > several packages having uncommon settings that will take precedence
> > over the default ones.
>
> I agree with you in theory; my global gbp.cons enables pristine-tar.
>
> However, having it duplicated in every package means we as a team work
> consistently regardless of people's global configuration,

not at all, right now we dont have a *consistent* debian/gbp.conf in
each package, everyone writes their own and it's currently a mess.

what when we decide to add a new option, or change the value of an
existing one? DPT currently has ~2500 packages: how do you maintain
consistency in all of them?

> and that's one
> less detail people need to get just right to be able to contribute
> effectively.
>
> Also, one's global configuration might not apply to all the packages
> they contribute to; it's easier for everyone if gbp just does the
> right thing based on per-package configuration than expecting people to
> remember to switch their defaults, or to pass options explicitly.

please refer to
https://lists.debian.org/debian-python/2021/09/msg00065.html for how i
see this being implemented.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

2021-09-20 Thread Sandro Tosi
On Mon, Sep 20, 2021 at 11:21 AM Andrey Rahmatullin  wrote:
> On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote:
> > > That's because gbp does not use pristine-tar by default, and
> > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> > > fix that.
> > I dont think this is the right approach: the default options to work
> > on DPT packages should be in gbp default config file (or in another,
> > global, config file), and not live in each and every package
> > debian/gbp.conf file;
> What's the mechanism to put these options there for everyone who works on
> a DPT package?

that's a great question! i dont think a technical solution currently exists.

> Or do you mean just working with whatever is shipped with
> gbp?

that wont work, but there could be a solution if we request a new
feature in gbp.

According to man 5 gbp.conf, there is either a global configuration
file, a per user file or a per repo/branch. In order to support
different workflows (for different teams, f.e.), this is not
sufficient.

But it could work if gbp.conf supported something similar to gitconfig
includeIf: in my ~/.gitconfig i have

```
[includeIf "gitdir:~/deb/"]
   path = ~/.gitconfig-deb
```

(~/deb is where i keep all my Debian work), and that means that if the
CWD is part of the ~/deb/ tree, git will also include ~/.gitconfig-deb
which contains Debian-specific configs, like the @d.o mail address.

Now, we'd also need a single location to store the team-specific
gbp.conf, and we already have a repo thta would fit:
https://salsa.debian.org/python-team/tools/packages , which currently
contains files useful to work on the entire team packages. This is
useful in my specific workflow, which is suspect is rather unusual,
but here how it goes:

* i checked https://salsa.debian.org/python-team/tools/packages in
~/deb/python (this could be anywhere)
* run ./checkout -a to checkout all team packages (or ./checkout
... for only a subset)
* use `mr` (via .mcrconfig) to work on _m_ultiple _r_epositories (mr)

this repo could also contain a team-specific gbp.conf file we could
use. Admittedly, we probably only need a handful of options,
pristine-tar = True is only one that comes to mind (be aware this file
will need to be compatible with *all* repos currently in the team, so
setting the debian branch etc, wont work, until all repos are
uniform).

I'm going to file a feature request for the includeIf-like feature for gbp

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: python-django-js-asset_1.2.2-3_source.changes REJECTED

2021-09-20 Thread Sandro Tosi
> That's because gbp does not use pristine-tar by default, and
> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to
> fix that.

I dont think this is the right approach: the default options to work
on DPT packages should be in gbp default config file (or in another,
global, config file), and not live in each and every package
debian/gbp.conf file; it is already inconsistently maintained with
several packages having uncommon settings that will take precedence
over the default ones.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Python3 -dbg packages

2021-09-15 Thread Sandro Tosi
> Now filed as
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pydbg-removal;users=debian-python@lists.debian.org

why "Severity: serious"? none of them violates the policy:
https://www.debian.org/Bugs/Developer#severities; please adjust to
normal or important. thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: How should learning to program in Python be approached, if learning objectives are sought to be customised?

2021-09-05 Thread Sandro Tosi
Rajib,
thanks for your enthusiasm in learning python, but please note this
mailing list is dedicated to "Discussion of issues related to Python
on Debian systems with a stress on packaging standards. Therefore
relevant for maintainers of Python related packages.", while it
appears you have general Python questions unrelated to packaging. so
please look for help with them on a Python support channel as reported
at https://www.python.org/about/help/

Regards,
Sandro

On Sun, Sep 5, 2021 at 7:24 AM Susmita/Rajib  wrote:
>
> Thank you, Ms. Causey and Mr. van Baal-Ilić, for your posts.
>
> I am retaining the same subject line to avoid cluttering of my subsequent 
> posts.
>
> It appears that the Python books by Zed A Shaw are diversifying,
> spreading out. From Learn Python The Hard Way, Addison-Wesley, 2013
> ed., to Learn Python 3 the Hard Way, Addison-Wesley, 2017 to  Learn
> More Python 3 the Hard Way, Addison-Wesley, 2017.
>
> So Python 3 and More Python 3 should be appropriate. But I begin to
> suspect authors who try to replicate their 'success with one book'
> with more number of similar books.
>
> My query regarding a huge repository for Python like the Oracle Java
> repository, including example codes, structured information and object
> library still remains unattended.
>
> Did any software/IT company like Oracle take up the responsibility to
> erect such a meticulous construct bit by bit, or are such construct
> yet to materialise?
>
> I have been using Bluefish to edit html files (simple edits), so I am
> conversant with Bluefish editor. I also have the information regarding
> Pycharm. So all set.
>
> Just waiting for the last mile information, as asked in this post
> above and the earlier one with threat ref.
> .../debian-python/2021/08/msg00033.html
>
> Best
> Rajib
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Plan to upload all packages still using Alioth in Maintainer/Uploaders

2021-08-23 Thread Sandro Tosi
> After the upcoming release of bullseye, I plan to start uploading all
> packages that currently use Alioth to migrate them to Tracker (along
> with the other pending changes in the git repos).

progress for this work is now tracked at
https://github.com/sandrotosi/debian-python-team-tracker

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Plan to upload all packages still using Alioth in Maintainer/Uploaders

2021-08-13 Thread Sandro Tosi
Hello,
a long time ago, we decided to stop using Alioth for the team email
address in Maintainer/Uploaders fields, and onovy mass-committed this
change to our repo; several of our packages (736, according to [1])
are still using Alioth.

[1] https://lintian.debian.org/tags/python-teams-merged

Alioth is no longer maintained (or at the very least, our 2 mailing
lists), and the amount of spam received through it is way too high to
be sustainable.

After the upcoming release of bullseye, I plan to start uploading all
packages that currently use Alioth to migrate them to Tracker (along
with the other pending changes in the git repos).

I understand it's possible an upload exists in experimental that fixes
it, so i'll try and check for that; it's also likely that if a package
is still using Alioth, their maintainer is longer interested in the
package, but i dont think now it's the time for a mass purge. I also
understand some of these packages will have the team as Uploaders and,
according to our Policy, i should contact the physical person doing
the upload beforehand, but i think that would slow down this process
and i'm ready to deal with the consequences of not following the
Policy to the letter.

Please let me know if you prefer me to act differently.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Jupyter team?

2021-05-18 Thread Sandro Tosi
On Tue, May 18, 2021 at 12:29 PM Roland Mas  wrote:
> I just created a topic on discourse to announce my effort.

the link is https://discourse.jupyter.org/t/debian-packaging-effort/9240
for those who want to follow


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Asking for help Poetry

2021-05-10 Thread Sandro Tosi
On Sat, May 8, 2021 at 9:56 PM Emmanuel Arias  wrote:
> On 5/8/21 10:37 PM, Sandro Tosi wrote:
> > On Mon, Mar 15, 2021 at 10:29 AM Emmanuel Arias  wrote:
> >> On Mon, Mar 15, 2021 at 4:22 AM Sandro Tosi  wrote:
> >>>> * poetry-core failing https://ci.debian.net/packages/p/poetry-core/
> >>> are you handling this failure?
> > looks like this is fixed in git: do you need a sponsor?
> Yes, please. Thanks!

sounds good, i'll have a look at this package soon and let you know

> >>>> * python-cleo in review 
> >>>> https://salsa.debian.org/python-team/packages/cleo I hope finished this 
> >>>> week
> > stefanor uploaded it a few days ago
> Yes.
> >>>> * poetry still in progress 
> >>>> https://salsa.debian.org/python-team/packages/poetry -> need help and 
> >>>> reviews
> > for this one it looks like you imported a new upstream release a week
> > ago: is there something we can help/check about poetry?
>
> I've just push some advances. Currently, I'm working on tests, if you
> want to take a look.

maybe just ask here (or directly to me) if you have questions and
what's failing/needs work, so we dont duplicate work

> We need new upstream release for python-httpretty (for tests), that I
> upload to mentors [0]. @zigo ask me about test that this new upstream
> release doesn't break
> cloud-init and python3-scciclient (I would like to take a look to ratt
> for that).

ratt is pretty great, and rather simple to use:

- setup a sbuild schroot for unstable
- build a binary package from the source you're working on
- `ratt _amd64.changes`

and then you'll get on screen the results for each package + a
directory with the build results and logs

https://github.com/Debian/ratt

keep in mind it rebuilds packages sequentially, so it can take some
time if the number of reverse deps is high.

> Perhaps a good help from a more experienced person would be check if all
> is ok with DFSG,that's my biggest concern.

for which package specifically? while it's boring and long work, it's
also rather trivial: look at every single file (yep, all of them) from
the upstream source, and document their copyright and license in
d/copyright -- happy to answer questions if you have something
specific in mind about this

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Asking for help Poetry

2021-05-08 Thread Sandro Tosi
On Mon, Mar 15, 2021 at 10:29 AM Emmanuel Arias  wrote:
> On Mon, Mar 15, 2021 at 4:22 AM Sandro Tosi  wrote:
>>
>> > * poetry-core failing https://ci.debian.net/packages/p/poetry-core/
>>
>> are you handling this failure?

looks like this is fixed in git: do you need a sponsor?

>> > * python-cleo in review https://salsa.debian.org/python-team/packages/cleo 
>> > I hope finished this week

stefanor uploaded it a few days ago

>> > * poetry still in progress 
>> > https://salsa.debian.org/python-team/packages/poetry -> need help and 
>> > reviews

for this one it looks like you imported a new upstream release a week
ago: is there something we can help/check about poetry?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Sandro Tosi
> > this solution also underestimates the in-progress migration towards
> > poetry and pyproject.toml, where `python3 setup.py sdist` is not
> > available.
>
> Where does the metadata come from for projects using these things?

that'd be pyproject.toml AFAIUI

the point i wanted to make is that it would require to implement a
parser for setup.{py,cfg} and pyproject.toml, plus some way to decide
which one to use in case a project supports both (it happens) and how
to override the selection in case one system is available and outdated
(it happens).

All of this is done by PyPI already, and the fact a project exists on
GH but not on PyPI it's either because it's such a niche project or
it's still under heaving development, that working on a solution
*right now* is not a good use of our time.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Sandro Tosi
> Right and thus I am wondering if we could work through this, somehow?
> That is, $something fetches the tarball, runs sdist or whatever, and
> then the py2dsp magic.
>
> P.S. I know this sounds a little ambitious but I believe this would
> really help, too.

i do not plan to implement such a feature.

this solution also underestimates the in-progress migration towards
poetry and pyproject.toml, where `python3 setup.py sdist` is not
available.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Sandro Tosi
On Wed, May 5, 2021 at 2:58 PM Andrey Rahmatullin  wrote:
>
> On Thu, May 06, 2021 at 12:08:06AM +0530, Utkarsh Gupta wrote:
> > However, I am running into an issue (or I guess I am just not doing it
> > correctly).
> > Whilst trying to package from the g/h source
> > (https://github.com/keylime/keylime), it fails like this:
> > http://paste.debian.net/1195339/
> >
> > Am I missing something?
> As far as I can see, the change is only about getting the tarball, it
> still needs metadata from PyPI.

that's correct, the package still needs to be on PyPI, as that's the
place where py2dsp obtains most of the package metadata

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-04-25 Thread Sandro Tosi
> > > or git repository (a directory) that one has already downloaded.
> >
> > i dont see how starting from a git repo is useful, can you expand?
>
> instead of generating a .dsc first and then importing it into a git
> repository, it's more logical to me to import an upstream tarball into a
> git repository first (gbp import-orig), and then generate the debian
> packaging on top of that.

py2dsp does that for you: it creates a git repo, along with a source
package, with the DPT settings (note i used the `--profile dpt`) ready
to be pushed to salsa (the repo creation on salsa is still manual)

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-04-25 Thread Sandro Tosi
> It would be useful if it could also be run against a tarball

this is already supported (but in general by py2dsp and in the context
of --github), f.e.:

$ ./py2dsp --profile dpt --distribution unstable --revision 1 --gh
https://github.com/indygreg/python-zstandard
./zstandard_0.14.1.orig.tar.gz

uses the locally available zstandard_0.14.1.orig.tar.gz tarball (which
is not the latest available on gh) to create the source pkg with the
github customizations

> or git repository (a directory) that one has already downloaded.

i dont see how starting from a git repo is useful, can you expand?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Build an initial Debian source package with py2dsp from a GitHub project

2021-04-24 Thread Sandro Tosi
Hello,
recently i've been making some enhancements to py2dsp (part of
pypi2deb[1] ); for those who dont know what that is, py2dsp is a tool
that, given a PyPI project, will create an (initial) Debian source
package.

[1] https://packages.qa.debian.org/p/pypi2deb.html

I've just finished a patch that extend py2dsp to fetch the upstream
tarball from GitHub instead; nowadays this is my preferred source for
upstream tarballs, given it contains all the project files (not only
the one published on pypi via sdist, often missing important files
like tests, or doc sources, etc).

it's currently available at the git branch at [2] (there's a PR open at [3]):

[2] https://github.com/sandrotosi/pypi2deb/tree/morph
[3] https://github.com/p1otr/pypi2deb/pull/27

once you cloned/checkout that branch, you can run:

$ ./py2dsp --profile dpt --distribution unstable --revision 1 --github
https://github.com/USER/PROJECT

alternatively, you can specify an additional argument ``,
if PROJECT is not the source name you want to use in Debian:

$ ./py2dsp --profile dpt --distribution unstable --revision 1 --github
https://github.com/USER/PROJECT 

and it will create the source package in the `result/` directory.

Let me know if you find this useful and if there are
issues/enhancement you'd like to see added/fixed.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Asking for help Poetry

2021-03-15 Thread Sandro Tosi
> * poetry-core failing https://ci.debian.net/packages/p/poetry-core/

are you handling this failure?

> * python-cleo in review https://salsa.debian.org/python-team/packages/cleo I 
> hope finished this week
> * poetry still in progress 
> https://salsa.debian.org/python-team/packages/poetry -> need help and reviews

what kind of help do you need here?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Asking for help Poetry

2021-03-12 Thread Sandro Tosi
Hello Emmanuel,

> From the missing dependencies we have:
> * poetry-core in NEW [0]
> * pastel in NEW need for clikit [1]
> * pylev in NEW need for clikit [2]
> * crashtest has RFS need for clikit [3]
> * clikit is ready on salsa but waiting for crashtest before RFS [4]
> * cleo ready but waiting for clikit [5]
> * shellingham not ready nor ITP yet.
> * poetry some advances on salsa [6]
>
> For experience in the other packages (pylev, paste, etc) and for  
> recommendation of DDs,
> poetry package use upstream github repository where we have important things 
> like
> tests. I was looking and exist lot of setup.py that makes me think that we 
> will need
> repack the upstream package.
>
> I will continue working on it but after my reset week, I will be offline 
> until 9 january

can you provide a status update on poetry packaging? more and more
upstreams are moving (or planning) to poetry, so having it available
asap is definitely important.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#985035: ITP: pydata-sphinx-theme -- Bootstrap-based Sphinx theme from the PyData community

2021-03-11 Thread Sandro Tosi
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
Owner: Sandro Tosi 

* Package name: pydata-sphinx-theme
  Version : 0.5.0
  Upstream Author : Joris Van den Bossche 
* URL : https://github.com/pydata/pydata-sphinx-theme
* License : BSD
  Programming Lang: Python
  Description : bootstrap-based Sphinx theme from the PyData community

Binary package names: python3-pydata-sphinx-theme

 originally developed for the pandas docs, work is being done to make this more
 generic and more easily extensible to suit the needs of the different projects;
 noteworthy project using this theme:
 .
  * Pandas: https://pandas.pydata.org/docs/
  * NumPy: https://numpy.org/devdocs/
  * Bokeh: https://docs.bokeh.org/en/dev/
  * JupyterHub and Binder: https://docs.mybinder.org/, 
http://z2jh.jupyter.org/en/latest/, 
https://repo2docker.readthedocs.io/en/latest/, 
https://jupyterhub-team-compass.readthedocs.io/en/latest/
  * Jupyter Book beta version uses an extension of this theme: 
https://beta.jupyterbook.org
  * Fairlearn: https://fairlearn.github.io/master/quickstart.html



Bug#984847: ITP: ppmd -- PPMd compression/decompression library

2021-03-08 Thread Sandro Tosi
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org
Owner: Sandro Tosi 

* Package name: ppmd
  Version : 0.3.3
  Upstream Author : miur...@linux.com
* URL : https://github.com/miurahr/ppmd
* License : LGPLv2+
  Programming Lang: Python
  Description : PPMd compression/decompression library

Binary package names: python3-ppmd

 PPM(Prediction by partial matching) is a compression algorithm which has
 several variations of implementations. PPMd is the implementation by Dmitry
 Shkarin. It is used in the RAR and by 7-Zip as one of several possible methods.
 .
 ppmd, aka. ppmd-cffi, is a python bindings with PPMd implementation by C
 language. The C codes are derived from p7zip, portable 7-zip implementation.
 ppmd-cffi support PPMd ver.H and PPMd ver.I.

this is a new dependency of py7zr



Bug#982577: ITP: geventhttpclient -- http client library for gevent

2021-02-11 Thread Sandro Tosi
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org
Owner: Sandro Tosi 

* Package name: geventhttpclient
  Version : 1.4.5
  Upstream Author : Antonin Amand 
* URL : http://github.com/gwik/geventhttpclient
* License : LICENSE-MIT
  Programming Lang: Python
  Description : high performance, concurrent HTTP client library for Python 
using gevent

 geventhttpclient uses a fast http parser, written in C, originating from
 nginx, extracted and modified by Joyent.
 .
 geventhttpclient has been specifically designed for high concurrency,
 streaming and support HTTP 1.1 persistent connections. More generally it is
 designed for efficiently pulling from REST APIs and streaming APIs
 like Twitter's.
 .
 Safe SSL support is provided by default. geventhttpclient depends on
 the certifi CA Bundle. This is the same CA Bundle which ships with the
 Requests codebase, and is derived from Mozilla Firefox's canonical set.


this is a dependency of locust



Bug#982509: ITP: flask-basicauth -- HTTP basic access authentication for Flask

2021-02-10 Thread Sandro Tosi
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org
Owner: Sandro Tosi 

* Package name: flask-basicauth
  Version : 0.2.0
  Upstream Author : Janne Vanhala 
* URL : https://github.com/jpvanhal/flask-basicauth
* License : BSD
  Programming Lang: Python
  Description : HTTP basic access authentication for Flask

Binary package names: python3-flask-basicauth

 Flask-BasicAuth is a Flask extension that provides an easy way to protect
 certain views or your whole application with HTTP `basic access
 authentication`_.


this is a dependency of locust



Bug#982508: ITP: locust -- Developer friendly load testing framework

2021-02-10 Thread Sandro Tosi
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-python@lists.debian.org
Owner: Sandro Tosi 

* Package name: locust
  Version : 1.4.3
  Upstream Author : Carl Byström, Jonatan Heyman
* URL : https://locust.io/
* License : MIT
  Programming Lang: Python
  Description : Developer friendly load testing framework

Binary package names: python3-locust

 Locust is an easy to use, scriptable and scalable performance testing tool. You
 define the behaviour of your users in regular Python code, instead of using a
 clunky UI or domain specific language. This makes Locust infinitely expandable
 and very developer friendly.
 .
 Features:
 .
  * Write user test scenarios in plain-old Python -- If you want your users to
loop, perform some conditional behaviour or do some calculations, you just
use the regular programming constructs provided by Python. Locust runs every
user inside its own greenlet (a lightweight process/coroutine). This enables
you to write your tests like normal (blocking) Python code instead of having
to use callbacks or some other mechanism. Because your scenarios are “just
python” you can use your regular IDE, and version control your tests as
regular code (as opposed to some other tools that use XML or binary
formats).
  * Distributed & Scalable - supports hundreds of thousands of users -- Locust
makes it easy to run load tests distributed over multiple machines. It is
event-based (using gevent), which makes it possible for a single process to
handle many thousands concurrent users. While there may be other tools that
are capable of doing more requests per second on a given hardware, the low
overhead of each Locust user makes it very suitable for testing highly
concurrent workloads.
  * Web-based UI -- Locust has a user friendly web interface that shows the
progress of your test in real-time. You can even change the load while the
test is running. It can also be run without the UI, making it easy to use
for CI/CD testing.
  * Can test any system -- Even though Locust primarily works with web
sites/services, it can be used to test almost any system or protocol. Just
write a client for what you want to test, or explore some created by the
community.



Re: Python louvain packages naming confusion.

2021-02-10 Thread Sandro Tosi
+Steffen explicitly, given the team is not in Maintainer nor Uploaders

> How about renaming the current python3-louvain package to
> python3-community-louvain using a normal transition package.

that's incorrect: src:python-louvain builds a module called
`community` (that includes also a cli tool), so the resulting binary
package should either be `python3-community` or `community` where the
cli is the main product and the module is installed in /usr/share/ to
support it.

> Then I can submit the other louvain package using a binary package name
> of python3-louvain-igraph.

this is incorrect too: (perspective) src:louvain (or
src:louvain-igraph, as the upstream called their repo) builds a module
called `louvain` so the resulting binary package should be
`python3-louvain` eventually conflicting with the existing package (<<
current-version-in-sid)

src:python-louvain is in a pretty bad shape: it received a single
upload in late 2018, it has an RC bug since a *day* after that upload,
and it has never been in testing: tbh i dont consider this package to
be maintained/targeting any stable release, so i believe you can "take
over" the namespace given you seem to show interest in maintaining
https://github.com/vtraag/louvain-igraph

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Joining DPT

2021-02-03 Thread Sandro Tosi
> I would like to join DPT, I already maintain several packages under the DPT
> umbrella

how is this possible (maintaining packages in DPT without being a member)?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Joining the team

2021-01-31 Thread Sandro Tosi
> > Added!
> >
> > Happy package maintenance :)
>
> Thanks  <3

please name the project as the source package name, not "Easy Ansi"
https://salsa.debian.org/python-team/packages/easy-ansi; also
src:python-easy-ansi, the python- prefix is not strictly required --
anyhow, the salsa project name should match what source package name
you decide to set. please fix Easy Ansi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

2021-01-25 Thread Sandro Tosi
> I injected a new tarball drained from Github.  It seems to need lots of
> not yet packaged - I have no idea how to cope with this.

i dont understand what you're trying to say here; if it's that
diskcache requires modules/packages not present in debian yet, it's
simple: you need to package those packages first or find someone else
to do that.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: diskcache: ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

2021-01-25 Thread Sandro Tosi
Andreas,
did you read the error before asking for help? i mean, it's literally
right there

On Mon, Jan 25, 2021 at 11:47 AM Andreas Tille  wrote:

> ERROR: tox config file (either pyproject.toml, tox.ini, setup.cfg) not found

and that's because
https://github.com/grantjenks/python-diskcache/blob/master/tox.ini is
not included in the pypi package (and, independently, the reason i
start packaging tarballs from github, it's just easier than getting
half baked pypi tarballs).

It is not the first time you ask for help for trivial issues. you may
want to look into why that's the case.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Status of https://debian-python.readthedocs.io/en/latest/

2020-12-25 Thread Sandro Tosi
Hello,
it looks like Barry (correct me if i'm wrong) set up
https://debian-python.readthedocs.io/en/latest/ but it has not been
updated in a while.

Do we know what's the status of this website, if we want to continue
to maintain it, or instead we should just consolidate onto
https://www.debian.org/doc/packaging-manuals/python-policy/ ?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#977936: ITP: python-multipart -- streaming multipart parser for Python

2020-12-22 Thread Sandro Tosi
Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: python-multipart
  Version : 0.0.5
  Upstream Author : Andrew Dunham <>
* URL : http://github.com/andrew-d/python-multipart
* License : Apache
  Programming Lang: Python
  Description : streaming multipart parser for Python

Binary package names: python3-python-multipart

this is a dependency for fastapi (and its tests)



Re: Joining the team

2020-11-23 Thread Sandro Tosi
On Mon, Nov 23, 2020 at 6:50 PM Thomas Goirand  wrote:
>
> On 11/23/20 10:10 PM, Sandro Tosi wrote:
> >>> First, an apology: it seems I misremembered being in the team, and 
> >>> uploaded to
> >>> NEW a bunch of packages with the team in `Uploaders`.
> >>
> >> Please put the team as Maintainer, and yourself as Uploaders.
> >
> > why? that's not a requirement:
> > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership
>
> Because joining a team, putting packages in them, and enforcing strong
> ownership, is not logic at all.

that's your opinion, and the policy disagrees with you. this team
welcomes everyone that is willing to follow our policies and its
rules.

> I know you like to do this way, but this
> shouldn't be what we advise for new comers.

that's also what nicoo prefers, given he chose exactly that way for
maintaining his packages.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Joining the team

2020-11-23 Thread Sandro Tosi
> > First, an apology: it seems I misremembered being in the team, and uploaded 
> > to
> > NEW a bunch of packages with the team in `Uploaders`.
>
> Please put the team as Maintainer, and yourself as Uploaders.

why? that's not a requirement:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: [Python-modules-team] Bug#954381: marked as done (python3-kubernetes: New upstream version available)

2020-11-20 Thread Sandro Tosi
>* Use git to generate upstream tarball, as the PyPi module doesn't include
>  the test folder. Using the gen-orig-xz in debian/rules, as using the
>  repack function of debian/watch doesn't make sense (why downloading a
>  tarball that would be later on discarded? I'm open to a better solution
>  which would be uscan compatible though...). Switch d/watch to the github
>  tag therefore.

you can track the github project instead of pypi (man uscan has the
details); this is was i'm doing recently, as most of the time PyPI
releases dont have all the files we need (tests, or test data, or
documentation, or a combination of that)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Looking for information about the Python Team

2020-10-27 Thread Sandro Tosi
> I'm looking for information about the work done by the Python Team for a
> talk to encourage the Cuban python community to collaborate in Debian.

why do you want to encourage people to contribute to a team you're not
part of, to which you never contributed to (at least that i could
quickly find), and of which you virtually know nothing about?

> Where can I find information about:
> - When the Python Team was created
> - Number of active members (approximately)
> - Number of packages under the responsibility of Python Team (approximately)
> - Requirements to be a member of the Python Team
> - Any other information of interest

you can start from ttps://wiki.debian.org/Python

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Newcomers project: DPMT/PAPT pristine-tar verification

2020-10-03 Thread Sandro Tosi
attached the dd-list of the packages missing the pristine-tar branch (some
may have been moved/removed, but these are actual repos in DPT)

On Fri, Jul 10, 2020 at 12:38 AM Sandro Tosi  wrote:

> Hello,
> i would like to propose a project to make sure our teams (DPMT/PAPT)
> repos are using pristine-tar properly.
>
> The checks i have in mind for now, are:
>
> * pristine-tar branch must exist, if not -> it's a bug
> * pristine-tar + upstream branch must produce the same tarball as
> downloaded from the archive, if not -> it's a bug
> * bonus point: fix the repo if it doesn't generate the right tarball
> and or the branch is missing.
> * bonus point: make this into a service that runs regularly (not
> strictly necessary to be limited to us)
>
> i guess we should have a brief discussion about additional checks
> and/or procedures before "assigning" it to a volunteer. let's say up
> to 2 weeks of discussion, and during the same period volunteers can
> nominate themselves.
>
> I marked this project as newcomers as it doesn't require to be a DD/DM
> to work on it, you just need a salsa account and access to our teams.
> a handy tool to retrieve all our repos is at
>
> https://salsa.debian.org/python-team/tools/python-modules
> https://salsa.debian.org/python-team/tools/python-apps
>
> that contains a config file for `mr` and a `checkout` script to fetch
> the repos registered in that config file.
>
> Please feel free to discuss this project now :)
>
> Regards,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi
Alastair McKinstry 
   fparser
   jpy (U)
   usagestats

Ana Custura 
   python-offtrac

Andrej Shadura 
   pydenticon (U)
   pyrsistent (U)
   pyte
   python-ewmh (U)
   python-h2 (U)
   python-libguess (U)
   python-minimock (U)
   python-phonenumbers (U)
   python-urlobject (U)
   txacme (U)
   txsni (U)
   waitress (U)

Andrej Shadura 
   gtimelog (U)

Andrew Shadura 
   python-wheezy.template (U)

Antoine Beaupré 
   pymeeus (U)
   python-internetarchive
   python-spake2

Balasankar C 
   vim-autopep8

Bastian Venthur 
   pipenv (U)

Benjamin Drung 
   pyrundeck (U)

Brian May 
   factory-boy (U)

Corey Bryant 
   python-requests-mock (U)

Daniel Kahn Gillmor 
   py-postgresql (U)
   python-xdo (U)

David da Silva Polverari 
   pem

Debian OpenStack 
   python-etcd3
   python-requests-mock
   python-sphinxcontrib.apidoc

Debian Python Apps Team 
   s3ql (U)

Debian Python Modules Team 
   aiowsgi
   autopep8 (U)
   black
   codespell
   derpconf
   django-session-security
   django-stronghold
   factory-boy
   fail2ban
   flask-assets
   flask-caching
   jpy
   milksnake
   netifaces
   patiencediff
   pikepdf
   power
   pydenticon
   pydle
   pykwalify
   pymeeus
   pyrsistent
   python-altair
   python-distutils-extra
   python-ewmh
   python-h2
   python-injector
   python-libguess
   python-lz4 (U)
   python-lzo
   python-minimock
   python-offtrac (U)
   python-pathtools
   python-pcl
   python-phonenumbers
   python-plaster
   python-plaster-pastedeploy
   python-requests-ntlm
   python-urlobject
   python-wheezy.template
   python-xdo
   sireader (U)
   stardicter
   subvertpy
   txacme
   txsni
   vim-autopep8 (U)
   waitress
   wsgiproxy2

Debian Python Modules Team 
   aiohttp-wsgi
   gevent-websocket
   py-postgresql

Debian Python Team 
   black
   pyrundeck

Denis Danilov 
   fortran-language-server (U)

Dmitry Smirnov 
   python-lz4
   python-lzo (U)

Federico Ceratto 
   django-stronghold (U)

Gaudenz Steinlin 
   sireader

Georg Faerber 
   codespell (U)

Gilles Dubuc 
   derpconf (U)

gustavo panizzo 
   python-pathtools (U)

Harlan Lieberman-Berg 
   python-requests-ntlm (U)

Jean-Michel Vourgère 
   django-session-security (U)

Jelmer Vernooij 
   aiowsgi (U)
   flask-assets (U)
   flask-caching (U)
   milksnake (U)
   patiencediff (U)
   pydle (U)
   subvertpy (U)
   wsgiproxy2 (U)

Jochen Sprickerhof 
   python-pcl (U)

Johan Fleury 
   pykwalify (U)

Johannes Tiefenbacher 
   discodos (U)

Jonathan Carter 
   feed2toot
   flask-caching (U)
   power (U)
   s-tui
   toot

Marcelo Jorge Vieira 
   derpconf (U)
   yanc

Mario Izquierdo (mariodebian) 
   netifaces (U)

Martin Pitt 
   python-distutils-extra (U)

Martin Wimpress 
   python-injector (U)

Maximiliano Curia 
   python-intbitset

Mehdi Abaakouk 
   python-lzo (U)

Michal Čihař 
   stardicter (U)

Mike Gabriel 
   python-injector (U)

Neil Williams 
   black (U)

Nicolas Dandrimont 
   python-plaster (U)
   python-plaster-pastedeploy (U)

Nikolaus Rath 
   s3ql

Peter Spiess-Knafl 
   codespell (U)

Python Applications Pack

Re: What is the new maintainer address for Python team?

2020-09-07 Thread Sandro Tosi
> New/correct address is:
> Maintainer: Debian Python Team 

Was this discussed somewhere? i cant find references in the ml -- thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: can we disable the bounce kicker? Re: confirm

2020-08-17 Thread Sandro Tosi
To these days, this is still happening! can we finally get rid of
this? Piotr, it looks like you're the admin of the mailing list, can
you take care of it please? thanks!

On Mon, Jun 11, 2018 at 5:44 AM Ondrej Novy  wrote:
>
> Hi,
>
> 2018-06-10 1:35 GMT+02:00 Sandro Tosi :
>>
>> this is still happening, and it looks like more frequently than before
>> - can we please disable this option once and for all?
>
>
> +1. Please.
>
>>
>>
>> On Sat, Sep 10, 2016 at 9:46 AM Sandro Tosi  wrote:
>> > I'm sure i'm not the only member using gmail, which bounces spam
>
>
> me too.
>
> --
> Best regards
>  Ondřej Nový
>
> Email: n...@ondrej.org
> PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable

2020-07-31 Thread Sandro Tosi
argggh removed the wrong address, adding Nick

On Fri, Jul 31, 2020 at 1:27 PM Sandro Tosi  wrote:
>
> >* d/control:
> >  - Mark package python3-uflash-doc as M-A: foreign
>
> This -doc package doesnt follow the policy, of having a python- prefix
> and not a python3- prefix -- please fix

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: [Python-modules-team] python-uflash_1.2.4+dfsg-3_source.changes ACCEPTED into unstable

2020-07-31 Thread Sandro Tosi
>* d/control:
>  - Mark package python3-uflash-doc as M-A: foreign

This -doc package doesnt follow the policy, of having a python- prefix
and not a python3- prefix -- please fix

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Granting `Janitor` direct access to our teams repos

2020-07-27 Thread Sandro Tosi
Hello,
I don't know the technicalities required to do that (nor i have
permissions to do it myself anyway), but I'm wondering if we should
grant direct access to our repos to the Janitor user.

I don't think any of us checks those PRs in depth, and most of the
time Jelmer comes in and bulk-merges them straight away (no complaints
on that).

So: let's just make that automatic? Thoughts?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Newcomers project: DPMT/PAPT pristine-tar verification

2020-07-19 Thread Sandro Tosi
On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog  wrote:
>
> Hi,
>
> On Fri, 10 Jul 2020, Sandro Tosi wrote:
> > The checks i have in mind for now, are:
> >
> > * pristine-tar branch must exist, if not -> it's a bug
> > * pristine-tar + upstream branch must produce the same tarball as
> > downloaded from the archive, if not -> it's a bug
> > * bonus point: fix the repo if it doesn't generate the right tarball
> > and or the branch is missing.
> > * bonus point: make this into a service that runs regularly (not
> > strictly necessary to be limited to us)
>
> I would suggest that this would be a nice job for the janitor bot.
> https://janitor.debian.net/

How would you suggest implementing this?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: RFH: Problemas with test process on python-jsonrpc-server

2020-07-18 Thread Sandro Tosi
did you run the -v option, as suggested by the error? it may lead to
what the problem is

On Sat, Jul 18, 2020 at 7:03 PM Pablo Mestre  wrote:
>
> Hi,
>
> Im trying to packages python-jsonrpc-server to solve the dependencies
> for upgrade Python IDE Spyder.
>
> I get this issue with the test process and I dont find any solution at
> the moment:
>
> https://github.com/palantir/python-jsonrpc-server/issues/43
>
> The problem is only with python version 3.8
>
> Any idea how i can solve this issue
>
> The salsa repo is
> https://salsa.debian.org/elMor3no-guest/python-jsonrpc-server
>
> Thanks in advance
>
> Pablo
>
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Request to join DPMT

2020-07-18 Thread Sandro Tosi
Luca,

> I have read and accept the policy.rst - if accepted, I will update the
> branch policy of my modules to match the policy (mainly
> s|debian/sid|debian/master|) and update the Maintainer field,
> everything else already matches.

In your request to join email, you agreed to accept and follow our
policy, and adapt your packages to it. sadly that did not happen: all
your packages lack both `upstream` and `pristine-tar` branches, and
they still have `debian/sid` as main branch (which would be fine, but
you said you'd change it).

Please rectify the situation.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: mercurial switch to python3 in debian unstable - July 16th, 2020

2020-07-18 Thread Sandro Tosi
> I guess a lot of things are unlocked now. I wonder how we can help
> fixing what's remaining.

I think i already took care of all the packages that got (recursively)
freed up by switching mercurial to python3.

> Please do share your thoughts on that.

I guess one can always look at
http://sandrotosi.me/debian/py2removal/index.html for some work
regarding the py2removal effort

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: mercurial switch to python3 in debian unstable - July 16th, 2020

2020-07-16 Thread Sandro Tosi
> If we dont hear otherwise, we plan to upload the python3 version of
> mercurial in unstable on or around next Thursday, July 16th.

mercurial/5.4.1-2 has just been uploaded to unstable, switching it to
use python3.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: The python command in Debian

2020-07-16 Thread Sandro Tosi
> It seems to be a little bit more controversial what should happen to the 
> python
> command in the long term.  Some people argue that python should never point to
> python3, because it's incompatible,

> however Debian will have difficulties to
> explain that decision to users who start with Python3 and are not aware of 
> the 2
> to 3 transition.

can you explain this point? i think if a new developer starts with
python3 now (and i have plenty of examples at my company) they just
use `python3` on the commandline, shebangs, venv, etc. I dont see the
confusion we would create.

> So yes, in the long term, Debian should have a python command
> again.

I dont think that's the right decision. PEP 0394
(https://www.python.org/dev/peps/pep-0394/) allows distribution not to
ship `python` at all:

https://www.python.org/dev/peps/pep-0394/#for-python-runtime-distributors

* If the python command is installed, it is expected to invoke either
the same version of Python as the python3 command or as the python2
command.
* Distributors may choose to set the behavior of the python command as follows:
** python2,
** python3,
** not provide python command,
** allow python to be configurable by an end user or a system administrator.

> One solution could be not to ship the python command in bullseye, forcing 
> users
> to adjust their local installations.

it is my opinion that that's what we should do: not ship `python` at
all and have users/packagers/developers use either python2 or python3
as needed, and not to reintroduce `python` at a later time.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: py2removal RC severity updates - 2019-12-22 17:36:38.269399+00:00

2020-07-16 Thread Sandro Tosi
> src:dbus-python cannot drop its Python 2 support until all of the reverse
> dependencies of python-dbus have done so (or been removed from testing, but
> that's unlikely to happen while they include key packages like avahi,
> jackd2 and pyqt5).

this is now the case: bin:python-dbus has no more reverse dependencies
(that are not RC and/or being removed from testing), see dak output:

Checking reverse dependencies...
# Broken Depends:
dbus-python: python-dbus-dbg  **Internal deps
python-dbus-tests
ladish: ladish   ** removed from testing in May 2020
neard: neard-tools   ** removed from testing in Dec 2019
wicd: wicd-daemon   ** removed from testing in Oct 2019

So please proceed with drooping python-dbus as soon as possible.
Currently python-dbus is the sole rdep of python-gi, which then could
be dropped when python-dbus is gone.

Let me know if you need help with this activity: i'm available to NMU
or team upload src:dbus-python if that's preferred

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Request to join Python Modules Team

2020-07-15 Thread Sandro Tosi
>   Imaging you are the person that wants to join this cool project.
>   You made some effort to apply for membership and sent in the request.
>   Then you wait humblely. Humble as you are, you wait another day.
>   On third day you start wondering "Is asking again expressing
>   that you care or is it pushing the people you want to join?"

I did not see a single MR from all the people that requested to join
the team in recent times (and i'm subscribed to MR notifications for
both DPMT and PAPT), and i do know that you cannot submit an MR for
new packages.

Almost all those introductory mails mentioned "I want to maintain this
new package *AND* [emphasis added] help with general maintenance" but
those maintenance contributions never really came (neither before or
after membership was granted, at least not at the level a person that
cares so much would lead to expect).

If they really want to contribute they can always submit MRs or
patches to the bts, and/or prepare a NEW package in a temporary
location if access is still not granted; but that didnt really happen.

We dont really have a good process to accept new contributions (it
mostly boils down to single individuals to review, merge, upload), but
we also dont really that many to begin with.

Geert, I personally find your approach towards the current
members/admins pushy, so speaking exclusively for myself l I would
suggest you to be mindful that, while I may believe you're trying to
be helpful, you may come across differently than how you intended.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: [Python-modules-team] pychromecast_7.1.1-1_source.changes ACCEPTED into unstable

2020-07-11 Thread Sandro Tosi
Andrej, the pristine-tar branch has not been updated (not sure if you
didnt push it or it was not imported with the --pristine-tar option)


On Sat, Jul 11, 2020 at 1:04 PM Debian FTP Masters
 wrote:
>
>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Sat, 11 Jul 2020 18:45:04 +0200
> Source: pychromecast
> Architecture: source
> Version: 7.1.1-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Python Modules Team 
> 
> Changed-By: Andrej Shadura 
> Changes:
>  pychromecast (7.1.1-1) unstable; urgency=medium
>  .
>* Team upload.
>* New upstream release.
> Checksums-Sha1:
>  c890d7a377ea7484823065ac404870ec73d909c8 1897 pychromecast_7.1.1-1.dsc
>  0bce73ca78cfa25e585c28b56cc4cdd5b647f5ac 57075 pychromecast_7.1.1.orig.tar.gz
>  76f6076ac34b247501301e587018f392b48b0fb7 3516 
> pychromecast_7.1.1-1.debian.tar.xz
> Checksums-Sha256:
>  783fbdd898819cbccedece2f6055879c3b96005dfe0c0454cdf4f2261b4f9f9a 1897 
> pychromecast_7.1.1-1.dsc
>  e0113bca3323546b9affc0b9187afceb224682a4db66280017a469476b244631 57075 
> pychromecast_7.1.1.orig.tar.gz
>  2856c17018180eed9f7f5767c900100349a3cc7550b7785d3cecf59a7d49804a 3516 
> pychromecast_7.1.1-1.debian.tar.xz
> Files:
>  97c18b1be74e9b6d7c86cf605a51bb3b 1897 python optional 
> pychromecast_7.1.1-1.dsc
>  32726da37759a15deb4e199a31c6fb54 57075 python optional 
> pychromecast_7.1.1.orig.tar.gz
>  3b55122a623accf5d90d79724d0e22ad 3516 python optional 
> pychromecast_7.1.1-1.debian.tar.xz
>
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl8J7NUACgkQXkCM2RzY
> OdLbCQf9HjNvz/dB4itbedQutgeeEEmgStSZdnWuqyiSP6tnd8qqu4wKRvDTEdZM
> AAseqradRlL3cZpnbLeUMkuffOvcZf+rxSh1H+rhfjWPkGn1+rE8mRdB5A+lOAtK
> MKlWiBs2VGuLrrF1phRkTIJxzBLdmBT1JGmfFWqTcEA66kOeCDtHAJJG4Y99lUMV
> I5nL6J2odl6sN4BDhrkyCd7or6yP4ahG+9SiACp+Fw8nhHk2v3728S+HUTOSsbxh
> 1boiiwEbt1T3MQ1MM0e+xMAGbL56EfTmpZsXwaBXjgFjQhSk/iH5j3F8pDNFEaVF
> /d/BM61VF43XFu00s25lF+cCP8Ypqw==
> =pYDM
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Newcomers project: DPMT/PAPT git repos verification

2020-07-09 Thread Sandro Tosi
Hello,
i would like to propose a project to make sure our teams (DPMT/PAPT)
repos are being used correctly; it has a broader set of requirements
than the pristine-tar one (and so it's more complex), thus a separate
message.

The checks i have in mind for now, are:

* packages in DPMT/PAPT need to have a repo in our teams, if not ->
move them in our salsa team if somewhere else or remove DPMT/PAPT from
M/U
* packages no longer in our team (moved, orphaned, etc) needs to get
their repo removed from our team
* is the repo up-to-date with the archive? f.e. is the version in
unstable the latest one released from this repo?
* does the repo contain all the versions uploaded to the archive?
* are tags up to date with the package releases?
* is the content of debian/gbp.conf against our policies?
* bonus point: make this into a service that runs regularly (not
strictly necessary to be limited to us)

i guess we should have a brief discussion about additional checks
and/or procedures before "assigning" it to a volunteer. let's say up
to 2 weeks of discussion, and during the same period volunteers can
nominate themselves.

I marked this project as newcomers as it doesn't require to be a DD/DM
to work on it, you just need a salsa account and access to our teams.
a handy tool to retrieve all our repos is at

https://salsa.debian.org/python-team/tools/python-modules
https://salsa.debian.org/python-team/tools/python-apps

that contains a config file for `mr` and a `checkout` script to fetch
the repos registered in that config file.

Please feel free to discuss this project now :)

Regards,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Newcomers project: DPMT/PAPT pristine-tar verification

2020-07-09 Thread Sandro Tosi
Hello,
i would like to propose a project to make sure our teams (DPMT/PAPT)
repos are using pristine-tar properly.

The checks i have in mind for now, are:

* pristine-tar branch must exist, if not -> it's a bug
* pristine-tar + upstream branch must produce the same tarball as
downloaded from the archive, if not -> it's a bug
* bonus point: fix the repo if it doesn't generate the right tarball
and or the branch is missing.
* bonus point: make this into a service that runs regularly (not
strictly necessary to be limited to us)

i guess we should have a brief discussion about additional checks
and/or procedures before "assigning" it to a volunteer. let's say up
to 2 weeks of discussion, and during the same period volunteers can
nominate themselves.

I marked this project as newcomers as it doesn't require to be a DD/DM
to work on it, you just need a salsa account and access to our teams.
a handy tool to retrieve all our repos is at

https://salsa.debian.org/python-team/tools/python-modules
https://salsa.debian.org/python-team/tools/python-apps

that contains a config file for `mr` and a `checkout` script to fetch
the repos registered in that config file.

Please feel free to discuss this project now :)

Regards,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



mercurial switch to python3 in debian unstable - July 16th, 2020

2020-07-09 Thread Sandro Tosi
Hello,
this email is to inform the maintainers of the reverse dependencies of
mercurial of the plan to upload to unstable the python3 version next
Thursday. We want to be extra-safe with the switch, hence this email.

In To: to this email the maintainers mailing list + key other MLs and
addresses, in Bcc: the real people listed in Maintainer/Uploaders of
the involved packages, apologies if you received more than 1 copy of
it.

The full list of the packages, as produced by dak, is available at the
bottom of this email.

There has been a test rebuilt, via ratt, as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937009#142 and it
doesnt look like there's any failure in the build process due to the
switch (except for meson, which indirectly build-depends on python2
without listing it).

Mercurial is also used as part of the normal operation of a program,
and that cannot be tested automatically, nor via a rebuild. The
python3 version of mercurial is available in experimental
(5.4.1-1+exp1); if you could test it against your package to make sure
it works as you intended, that would help the transition.

Mercurial has an extensive test suite, which passes 100% with python3,
so we dont expect any failure while using the `mercurial` command, but
some interfaces/operations may have changed.

If we dont hear otherwise, we plan to upload the python3 version of
mercurial in unstable on or around next Thursday, July 16th.

This effort will greatly benefit the broader effort of py2removal, by
allowing the chain removal of several other packages.

Regards,
Sandro


$ dak rm -Rn mercurial
Will remove the following packages from unstable:

 mercurial |5.4.1-1 | source, amd64, arm64, armel, armhf, i386,
mips64el, mipsel, ppc64el, s390x
mercurial-common |5.4.1-1 | all

Maintainer: Python Applications Packaging Team


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
git-remote-hg: git-remote-hg
hg-git: mercurial-git
hgsubversion: hgsubversion
mercurial-buildpackage: mercurial-buildpackage
mercurial-crecord: mercurial-crecord
mercurial-extension-utils: mercurial-extension-utils
mercurial-keyring: mercurial-keyring
python-hgapi: python3-hgapi
python-hglib: python3-hglib
sphinx-patchqueue: python-sphinx-patchqueue

# Broken Build-Depends:
check-manifest: mercurial
composer: mercurial
devpi-common: mercurial
git-remote-hg: mercurial
golang-github-masterminds-vcs-dev: mercurial
haskell-filestore: mercurial
hg-git: mercurial (>= 4.8~)
hgsubversion: mercurial (>= 5.2-1~)
jags: mercurial
meson: mercurial
pepper: mercurial
python-hgapi: mercurial
python-hglib: mercurial (>= 1.9)
reposurgeon: mercurial
ros-rosinstall: mercurial
ros-vcstools: mercurial
ros-wstool: mercurial
setuptools-scm: mercurial

Dependency problem found.



Re: py2removal - make all leaf applications RC

2020-07-08 Thread Sandro Tosi
> I propose to raise the severity of all leaf applications in 3 days, if
> i dont hear any objections.

This is now enabled and at the next run (in ~50 minutes) it will take effect.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



py2removal - make all leaf applications RC

2020-07-04 Thread Sandro Tosi
Hello,
Currently only leaf applications (ie something that doesnt start with
`python-`) with popcon <= 1000 get their py2removal bug bumped to RC.

I propose to raise the severity of all leaf applications in 3 days, if
i dont hear any objections.

The current list of applications, and their popcon, impacted by this is:

gnumeric-plugins-extra, popcon = 1072
xchat, popcon = 1437
getmail, popcon = 1285
libapache2-mod-python, popcon = 3626
mysql-workbench, popcon = 1355

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: [Python-apps-team] Bug#937009: mercurial: Python2 removal in sid/bullseye

2020-07-04 Thread Sandro Tosi
> > > Do you need any help in coordinating with the packaged extensions,
> > > testing changes, preparing patches? a lot of time has passed since we
> > > started asking about mercurial and python3 and it is becoming the only
> > > reverse-dependency of several packages that could be removed if
> > > mercurial switched to py3k.
> > >
> > Getting an uptodate list of extensions and their status wrt porting both
> > upstream and in Debian would be useful.  I've spent some time looking at
> > hgsubversion a few weeks ago but there's a ton of work and I don't
> > actually use it so I've kind of given up on that; I forget what the
> > status is on others.
>
> will look into the rdeps of mercurial once 5.4.1-1+exp1 hits the archive

I've rebuilt all rdeps of mercurial against the python3 version
uploaded to unstable; results are:

2020/07/05 00:28:22 Build results:
2020/07/05 00:28:22 PASSED: salt
2020/07/05 00:28:22 PASSED: golang-github-masterminds-vcs-dev
2020/07/05 00:28:22 PASSED: pepper
2020/07/05 00:28:22 PASSED: python-hglib
2020/07/05 00:28:22 PASSED: git-remote-hg
2020/07/05 00:28:22 PASSED: haskell-filestore
2020/07/05 00:28:22 PASSED: composer
2020/07/05 00:28:22 PASSED: yotta
2020/07/05 00:28:22 PASSED: ros-rosinstall
2020/07/05 00:28:22 PASSED: check-manifest
2020/07/05 00:28:22 PASSED: jags
2020/07/05 00:28:22 PASSED: setuptools-scm
2020/07/05 00:28:22 PASSED: reposurgeon
2020/07/05 00:28:22 PASSED: devpi-common
2020/07/05 00:28:22 PASSED: firmware-microbit-micropython
2020/07/05 00:28:22 PASSED: python-hgapi
2020/07/05 00:28:22 PASSED: hgsubversion
2020/07/05 00:28:22 PASSED: ros-wstool
2020/07/05 00:28:22 PASSED: ros-vcstools
2020/07/05 00:28:22 FAILED: hg-git (see buildlogs/hg-git_0.8.12-1.2)
2020/07/05 00:28:22 FAILED: meson (see buildlogs/meson_0.54.3-1)

(build logs and artifacts are at
https://people.debian.org/~morph/mercurial_python3/ )

hg-git is RC and not in testing since mid-December, and meson is i
think a real error, since without mercurial depending on python2 now
the build fails to find that executable

Tbh, i think it's time to just rip the bandaid and upload mercurial
python3 to unstable, and deal with the consequences there (i volunteer
to do so); you mentioned hgsubversion as a potential blocker: that
package are popcon on 56, i dont believe such a minor package should
hold progress with the py2removal effort (I've added debian-python@ to
gather their input on this).

I do understand the rebuild results are not conclusive on the python3
migration (after all hgsubversion rebuilds fine with py3k mercurial,
which also raises the questions of why it b-d on it since it clearly
doesnt use it, but i'm digressing), but i think it's better to just go
ahead and upload the experimental version to unstable and see what's
the impact there

What do people think about this?

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Sandro Tosi
> Running the script shows that 279 reverse (build?) dependencies are
> affected by mock. This clearly isn't something one wants to run on a
> personal computer, and even less a test which one wants to run sequentially.
>
> Has any thought went into having some kind of runners running on a cloud
> to run these tests, and maybe plug this into Salsa's CI to run it
> automatically?
>
> I'd very much would love to set this up, at least as a first
> experimentation on a bunch of package of the DPMT.

i sent this some time ago do d-devel

https://lists.debian.org/debian-devel/2020/03/msg00342.html

it didnt get much traction

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Sandro Tosi
> Is anyone from the team opposing to this?

Yes, i'm against your proposal.

> If so, please explain the
> drawbacks if the OpenStack team takes over.

1. you're personally attacking Ondrej, who is one of the very few
members of this team doing team-wide work, and that should be enough
to reject it
2. this is clearly an hostile take-over (even if you frame it as a
proposal), and that should be enough to reject it
3. you propose to only update those packages every 6 months, i dont
find it appropriate: OS is *just* another software we package for
Debian; is it complex? sure, but it's not special, and it doesnt
warrant any special treatment.
4. you clearly want to have sole and absolute control of the packages
in the openstack-team, because what would happen if a os-team member
will upgrade one of those packages (in good faith) and things will
break? will they get another "well done! :( " email from you?
4.1. You wonder why Ondrey "stopped caring" about OS, if that's the
case, i could see why
5. consolidating packages *into* the DPMT/PAPT gives a lot of
benefits, f.e. people basically got "free" handling of the py2removal
process; moving packages out is actually detrimental for the python
ecosystem (at least that's my opinion).

Thomas, this is not the first time your temperament and aggressive
behavior is causing some troubles, please reassess how you interact
and work with other fellow contributors.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Future of PyPy (not PyPy3) in Debian

2020-06-04 Thread Sandro Tosi
Hello all,
it looks like i started a process that would require the removal of
several PyPy (as in pypy-* depending on the `pypy` package) packages
from the archive.

I'm now wondering: what should we do with the entire pypy ecosystem?
should we treat pypy-* packages like python-* ones and remove then as
part of py2removal? do we need/want to track this effort with the same
usertag? is there a (even if only hypothetical for now) programmed
transition from pypy- to pypy3-?

PS: if i made mistakes, just call me out, and i'll do my best to fix
them or revert them; i have no problem in being told i did something
wrong (let's keep the discussion in this thread on topic, so pypy etc)

Cheers,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#962024: RFP: cppy -- collection of C++ headers which make it easier to write Python C extension modules

2020-06-02 Thread Sandro Tosi
Package: wnpp
Severity: wishlist

* Package name: cppy
  Version : 1.1.0
  Upstream Author : The Nucleic Development Team
* URL : https://github.com/nucleic/cppy
* License : BSD 3-Clause
  Programming Lang: Python
  Description : collection of C++ headers which make it easier to write 
Python C extension modules

this is a new dependency for kiwisolver/1.2.0



Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

2020-05-11 Thread Sandro Tosi
> Any trick to avoid those errors in general?

when i push i always do

$ git push --all ; git push --tags

i also have these in ~/.gitconfig

[push]
   default = current
   followTags = true

with should make the `git push --tags` unnecessary after `git push
--all` (as tags will "follow" the diffs you're pushing) but it's stuck
in my bash history so there it is

> Anyways, it should be there now!

indeed it's there -- thanks!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: [Python-modules-team] Processing of paramiko_2.7.1-1_source.changes

2020-05-11 Thread Sandro Tosi
Antoine, you did not push the upstream branch. please do so, in order
to keep the repo consistent


On Mon, May 11, 2020 at 10:15 PM Debian FTP Masters
 wrote:
>
> paramiko_2.7.1-1_source.changes uploaded successfully to localhost
> along with the files:
>   paramiko_2.7.1-1.dsc
>   paramiko_2.7.1.orig.tar.gz
>   paramiko_2.7.1-1.debian.tar.xz
>   paramiko_2.7.1-1_amd64.buildinfo
>
> Greetings,
>
> Your Debian queue daemon (running on host usper.debian.org)
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#960148: RFP: hstspreload -- Chromium HSTS Preload list as a Python package

2020-05-09 Thread Sandro Tosi
Package: wnpp
Severity: wishlist

* Package name: hstspreload
  Version : 2020.5.5
  Upstream Author : Seth Michael Larson
* URL : https://github.com/sethmlarson/hstspreload
* License : BSD-3
  Programming Lang: Python
  Description : Chromium HSTS Preload list as a Python package

It is used by httpx (althought it's not a hard requirement, but nice-to-have)

Please consider package this under DPMT



Re: issues installing psutil with pip in virtual environment

2020-04-26 Thread Sandro Tosi
> I am running into an issue installing psutil: pip3 install psutil, in a
> virtual environment. I have upgraded my pip and setuptools with no
> avail. I am getting this error: https://pastebin.com/2Xb7UN9g

psutil is not pure python, and contains some extensions that need to
be compiled, so your system needs to have a compiler, gcc, installed;
since it's not you get "unable to execute 'x86_64-linux-gnu-gcc': No
such file or directory"

> Some have suggested installing the python3-dev package. Saying that I
> require "header" files (don't know what those are). So this means
> installing that package and creating a new venv, where those files are
> available. Is there a way to make this install work without installing
> that package? Is that package really necessary? Does this mean my

you will necessarily need to install python3-dev

> virtual environments are somehow subject to what libraries are
> available in my system python installation?

yes, in a similar way as they are dependent on the system interpreter
to create and run the venv

> Is there some pip
> installabel package that provides these files?

some packages on PyPI provide binary releases, but psutil looks like
it doesnt for linux, so you need to compile it.

alternatively you can install python3-psutil on your host and then
"virtualenv --system-site-packages" to use the system-available
modules.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



  1   2   3   4   5   >