Bug#997662: lintian: Incorrect tag: package-contains-python-dot-directory for .egg-info directories

2021-10-23 Thread Stefano Rivera
Package: lintian
Version: 2.110.0
Severity: normal

Hi, I see lintian 2.110 is now emitting a
package-contains-python-dot-directory tag for .egg-info directories in
binary packages.

We do not want to encourage package maintainers to remove .egg-info
directories from their Python binary packages. Tools inspect these to
know which Python modules are available on the system, as well as many
other things.

I would consider all of these tags to be incorrect:
W: python3-bs4: package-contains-python-dot-directory 
usr/lib/python3/dist-packages/beautifulsoup4-4.10.0.egg-info/
W: python3-bs4: package-contains-python-dot-directory 
usr/lib/python3/dist-packages/beautifulsoup4-4.10.0.egg-info/PKG-INFO
W: python3-bs4: package-contains-python-dot-directory 
usr/lib/python3/dist-packages/beautifulsoup4-4.10.0.egg-info/dependency_links.txt
W: python3-bs4: package-contains-python-dot-directory 
usr/lib/python3/dist-packages/beautifulsoup4-4.10.0.egg-info/requires.txt
W: python3-bs4: package-contains-python-dot-directory 
usr/lib/python3/dist-packages/beautifulsoup4-4.10.0.egg-info/top_level.txt

Thanks,

SR



Re: .egg-info for entry points during dh_auto_test

2021-10-21 Thread Stefano Rivera
Hi Michael (2021.10.21_18:55:51_+)
> pytest-lazy-fixtures is a pytest plugin and registers itself through the
> Python entrypoints mechanism. In its unitests, it assumes that this
> registration has already happened but during dh_auto_test there is no
> .egg-info directory available. I could use "python3 setup.py develop -x" to
> generate it, but this registers the package in /usr inside the build chroot
> which I think is not the best solution.

I looked at this recently for pytest-doctestplus.

The lazy answer is to run the full test suite in an autopkgtest, not at
build time.

pytest also has a mechanism to register plugins through an environment
variable, but I couldn't figure out how to get the test suite to work
with that.

If you do find a nice mechanism, we should probably apply it to the
packaging of all pytest plugins.

SR

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



Re: Join the Python team

2021-10-18 Thread Stefano Rivera
Hi Jose (2021.10.12_19:54:59_+)
> My salsa login is jrivero-guest. I've read the policy at
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst,
> looks good to me.

Added, welcome.

> The only point is that I don't have experience using pq
> for the management of the patches (always used quilt) but does not sound
> difficult to learn.

pq is just a tool to turn a quilt series into a git branch and
vice-versa. It's great for rebasing patches on new upstream releases.

SR

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



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

2021-10-18 Thread Stefano Rivera
Hi Afif (2021.10.04_02:18:30_+)
> On 10/3/21 6:50 PM, Sandro Tosi wrote:
> >> 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.
> > 
> 
> I'd still like to join.

Added, welcome.

And sorry about the delay.

SR

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



Re: Request to join Debian Python Team

2021-10-18 Thread Stefano Rivera
Hi Vasudev (2021.09.29_08:51:47_+)
> I would like to reintroduce foolscap [1] which is part of DPT back to
> unstable as it is a dependency for reintroducing tahoe-lafs which I used
> to maintain earlier in Debian.

Added you on Salsa, welcome to the team!

SR

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



Re: Request to join the team

2021-10-18 Thread Stefano Rivera
Hi Phil (2021.09.29_05:37:20_+)
> Hi all, I've been lurking on the list for a while as several important
> applications I use are written in python and I hope to package e.g.
> mautrix-signal. Right now if I am part of the team, I can help with
> lexicon and backports.

Added, welcome to the team!

SR

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



Re: Request to join the team

2021-10-18 Thread Stefano Rivera
Hi Luiz (2021.09.19_11:02:13_+)
> My Salsa login is lamaral, but my account is not activated yet. Once I
> get salsa access, I will move the fbtftp repository there, as it
> currently resides in my GitHub[2].

I sponsored fbtftp to NEW, we should move its repo into the team.

Added you. Welcome to the team!

SR

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



Re: Joining Debian Python team

2021-10-18 Thread Stefano Rivera
Hi yokota (2021.09.20_03:04:31_+)
> I want to join Debian Python team to help packaging "python-zeroconf"
> to work "calibre" well.
> Because "python-zeroconf" is required package to "calibre".
> 
> Please add me (salsa: yokota) to Debian Python team.

Added, welcome to the team (and sorry about the delay).

SR

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



Re: Request to join the team

2021-09-17 Thread Stefano Rivera
Hi Joshua (2021.09.17_19:26:06_+)
> My official statement: I would like to join the Debian Python Team to
> maintain the pyupgrade, patch-ng, and the eventually the conan Python 
> packages.
> I have read and agree to the DPT policy, and I have subscribed to the
> mailing list (fyi). My salsa login is @ItzSwirlz-guest.

Added, welcome to the team.

SR

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



Re: Joining Python-team

2021-09-16 Thread Stefano Rivera
Hi Alastair (2021.09.16_12:23:15_+)
> My  salsa / DD login is "mckinstry"
> 
> I have read 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>  
> <https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst>
> and will adhere to it.

Added, welcome!

SR

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



Re: Request to join the team by Christian Buhtz

2021-09-16 Thread Stefano Rivera
Hi c.buhtz (2021.09.12_11:45:28_+)
> I want to package feedparser [1][2]. The main reason is my own
> software (not yet released [3]) depends on it. I am in good contact
> with the upstream maintainer for years and he supports my goal. And some
> of your team members still offered to sponsor me.
> 
> In the faraway future I am willing to take care of the package
> "backintime", too; just because my life and my good sleep depends on
> it. ;)
>
> > Your Salsa login.
> 
> "buhtz" (still waiting for admins approval)
> 
> > A statement
> 
> I read and accept the Debian Python Team - Policy at [4].

Welcome!

I'm not going to add you to the team, immediately, without some visible
history of contribution.

However, I've granted you access to the feedparser repo for a year,
which should be all you need for now. After an upload or two, request
here again, and we can grant team membership.

SR

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



Re: pyupgrade has been packaged + request to join the team

2021-09-16 Thread Stefano Rivera
Hi Joshua (2021.09.05_23:13:14_+)
> Now I'm trying to package things to rack up some contributions to
> Debian (and Ubuntu in that vein) by packaging more things.

Welcome. We're glad to have you rack up contributions in our
neighbourhood.

> My previous RFS's was a handful of Nemo extensions, which happened to
> be at the time Bullseye freeze depression struck, and they were all
> expired.

Sometimes the most effective way to get things sponsored in the python
team is via the IRC sponsorship request list. But sometimes they pile up
because nobody is sponsoring...

>   1.  Can I be the maintainer for pyupgrade and have the team as an
>   uploader? I'm asking this because the wiki mentions rule of thumb is
>   the team maintaining to find a 'knowledgeable person'.

Yes, you can. Or the other way around if you want people in the team to
feel free to work on your package (this tends to be rare, though).

>   2.  Can I join the team and later move pyupgrade to the python-team
>   repos? This way I can still upload my package(s, and more as I heard
>   some help is needed for pip at the BoF), and get contributions in
>   for my NM.

If the team is an uploader or maintainer of the package, it should live
in the team repos.

You can move existing package repos into the python-team/packages group.

>   3.  When I join, for the initial release: can the git repo still be
>   my personal salsa repo and use pypi? This way I can just get it
>   pushed, and then later it can be adjusted to pull from a GitHub tag
>   and moved to the team.

Yes, you can delay adding the team as a Maintainer, until the package is
moved into the team salsa group.

> So, with that being said, can I join the team

Please read the team policy:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
And send an email saying that you agree to it.

> how should I carry the initial release out? Let me know when you are
> ready for me to open an RFS.

Once you've got membership, you can move your repo into the team and
request sponsorship.

> Update: I have also packaged a fork of python-patch that is better
> maintained to close #845482, which is visible at
> https://salsa.debian.org/ItzSwirlz-guest/python-patch-ng. I've decided
> to set the team as Maintainer and me as Uploader this time, as I
> figured I would still technically be a maintainer if I was part of the
> team. As soon as pyupgrade gets its initial release I will do the
> same.

In Debian we generally consider the Maintainer and Uploaders of a
package to all be the maintainers of the package. The Maintainer field
only permits a single entity while Uploaders permits more.

In the Debian Python Team, we have some extra nuance about whether the
team is in the Maintainer or Uploaders field. Team as maintainer means
anybody can work on the package, team as uploader means feel free to
commit changes to git but ask for permission before uploading. This is
unusual, I don't know of any other teams that do that.

SR

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



Re: Request to join the team

2021-09-16 Thread Stefano Rivera
Hi Nobuhiro (2021.08.30_05:13:26_+)
> I would like to join the team,  I plan to ITP some python packages and
> would like to
> maintain them as team.
> 
> My salsa login is iwamatsu and I have read the Debian Python Team Policy
> and I accept them.

Added to the team, welcome!

SR

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



Re: Request to join the team

2021-09-16 Thread Stefano Rivera
Hi Dylan (2021.08.19_12:27:42_+)
> I would like to join the team in order to update python-sparse [1] and
> more generally to do some QA work.
> 
> My salsa login is daissi and I have read the Debian Python Team Policy
> and accept it.

Added to the team, welcome!

SR

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



Re: Joining team

2021-09-16 Thread Stefano Rivera
Hi Valdo (2021.08.20_19:33:11_+)
> I would like to join the team and help the team in maintaining and creating
> packages. I love open source and freeware and I want to contribute to the
> betterment of the open source projects. I like to learn and experience the
> joy of being a contributor for one of the open source software that I liked
> so much.

Sorry for the delayed reply.  Thanks for the offer, we'd love to have
your help in the team.

However, I'm not going to add you to the team, immediately.
I'd recommend getting started by contributing Merge Requests in Salsa
and patches through the bug tracking system, or adopting some orphaned
packages, and getting some experience maintaining them.  Ideally finding
some mentors to help you out, along the way. You can get uploads
sponsored through the team or debian-mentors.

Once it's clear that you're familiar with Debian development processes
and package maintenance, then we'll happily grant you commit access to
the team repos.

SR

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



Re: joining python team

2021-09-16 Thread Stefano Rivera
Hi Norbert (2021.07.09_20:43:38_+)
> I think I once was member of this team and had some packages, but
> seemingly in some reorganization this was lost.
> 
> Could you please add me (salsa: preining) to the Debian package team.

Sorry for the delayed reply, added you to the team.

Welcome.

> I am currently updating python-zeroconf which is needed for newer
> calibre.
> I have read the python policy.

I'll interpret that as you saying you agree to follow the Python policy.

SR

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



Considering letting python-pip use vendored dependencies

2021-09-15 Thread Stefano Rivera
As mentioned in debian-devel recently [1], at the DebConf 21 Debian
Python BoF [2] we discussed the idea of reverting our unbundling patches
to python-pip. The group consensus was that it wasn't worth the effort
to maintain these patches.

Debian Security Team and my co-maintainers: Do you have an opinion on
doing this?

What does pip vendor, and why?
--
See: https://github.com/pypa/pip/tree/main/src/pip/_vendor which
includes a README explaining their rationale.

Why is unbundling pip messy in Debian?
--
pip (and setuptools) have a special position in Debian, as they are
bootstrapped into virtualenvs, used by Python developers and deployment
systems. Virtualenvs exist to provide isolated Python library stacks,
and they need to be able to install these libraries, usually via pip.
They are bootstrapped from wheels in /usr/share/python-wheels.

How do we unbundle pip?
---
Our unbundling approach was to build wheels for every one of the
vendored modules, in /usr/share/python-wheels with dirtbike [3].
Historically, every one of these modules built its own python-X-whl
binary package, that python-pip-whl depended on. But as the dependency
set grew we consolidated building the dirtbiked wheels into the
python-pip source package and generated an appropriate Built-Using
field.

This means we've avoided using pip's vendored copies of modules, but at
the cost of building our own vendored copies at build time. To update
the vendored copies (e.g. to apply security updates), we have to do a
sourceful upload of python-pip.

Over time, our unbundling has caused issues:
1. Version mismatches. We've had old/newer versions that upstream knew
   wouldn't work with pip, but we didn't pick up on until bug reports
   came in.
2. The unbundled libraries were visible in the virtualenv. If they were
   updated, the above mismatches could occur again.
   Their presence also confused users.
   This has now been resolved, but there's still the possibility for new
   versions of one of these libraries, in the virtualenv, breaking pip.
3. Historically, pip have occasionally patched their vendored libraries,
   causing our pip to behave differently / brokenly:
   https://github.com/pypa/pip/issues/7784
4. We've had bugs in our unbundling, e.g.
   https://bugs.debian.org/958396
   https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1935882
   https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1880749
   https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1869247
   https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1833229
   https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1822842
5. Upstream doesn't really support the unbundling mechanism (even though
   they provide it), and don't have any CI coverage of it at the moment.
   This means we've pushed them further away, over time (esp. given the
   bugs above).
   Related to that, but not solely because of it, upstream support has
   been likely to suggest to users that they avoid Debian python things.

We don't have great CI coverage of pip. We don't currently run their
test suite (but we probably should), and we have limited integration
testing to avoid executing untrusted code from the Internet in our
autopkgtests. This has improved over time, but it's still far from
perfect.

I spent a couple of weeks earlier this year getting virtualenv and pip
working correctly in Debian and all the Ubuntu stable releases. In many
cases they'd been somewhat broken for years. Most of the issues were
around the de-vendoring patch. Some of the bugs were quite subtle.

This is a good sign that the Debian maintenance of pip hasn't been
keeping up with the bugs, and suggests to me that the cost of
maintaining this patch isn't worth the benefit.

In the past, we've discussed whether we should continue to de-bundle,
and have done so because we could and it seemed important. I'm not so
sure about that, any more.

If we did start letting pip vendor its dependencies, we'd need to
duplicate any significant patches that Debian currently carries to them,
from what I can see, that's just these two:

1. 
https://salsa.debian.org/debian/python-certifi/-/blob/debian/master/debian/patches/0001-Use-Debian-provided-etc-ssl-certs-ca-certificates.cr.patch
2. 
https://salsa.debian.org/python-team/packages/python-urllib3/-/blob/debian/master/debian/patches/02_require-cert-verification.patch
 (which is possibly noop)

SR

[1]: 
https://lists.debian.org/msgid-search/20210902223835.gb2...@mithrandir.lan.emorrp1.name
[2]: 
https://lists.debian.org/msgid-search/20210827233103.72rnnuzdxhppv...@satie.tumbleweed.org.za
[3]: https://tracker.debian.org/pkg/dirtbike

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



Re: Python BoF at DebConf2021

2021-08-27 Thread Stefano Rivera
Hi debian-python (2021.08.26_07:14:20_+)
> I've taken it over, and started an Agenda:
> https://pad.dc21.debconf.org/p/20-python-team-bof

Notes from the BoF:
The video should be published in a couple of hours, to:
https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm

Attendees:
Diane Trout and her cat
Elana Hashman
Emmanuel Arias
Jonathan Carter
Kyle Robbertze
Nicolas Dandrimont
Romain Porte
Stefano Rivera
Thomas Goirand

State of Python in Debian
=
Python 3.9 is currently the default, with 3.10 available in
experimental.

We plan to make 3.10 supported in unstable in October and then make it
default once RC issues are resolved.

We have been trying to mend the rift between Debian and upstream. Hard
to tell if things are any better. Some people upstream still recommend
avoiding Debian/Ubuntu Python. See "Other upstream issues" below.
Adding python3-full for bullseye was part of this.

We aren't ready for all PEP517-packaged modules. See below.

Debian Python Team Status
=

Volunteers always needed for team-wide maintenance, removals, etc.

Should we push towards git sources, as in:
https://lists.debian.org/debian-python/2021/06/msg00026.html
Consensus was yes, even if watch files continue to point to PyPI.
* ACTION: (olasd to propose) document policy change

-dbg module package removal
===

pydebug doesn't involve an ABI change any more, so all C extensions are
compatible with the -dbg interpreter, out of the box. We can retire our
-dbg packages, and migrate to automatic -dbgsym packages.

* ACTION: need tracker/list to be set up for package removal (no volunteers)
* ACTION: (olasd to ask pollo to) add a lintian warning for python-foo-dbg 
packages

python2.7 removal
=
python2.7 is 99% removed, we're basically there.
We plan to remove python-is-python2 from bookworm.

pypy and pypy3 still build-depend on python2.7.
The rpython toolchain is being slowly ported to python 3, but the
upstream is in no hurry, as they maintain a Python 2.7 interpreter (but
provide no real security support for its standard library).

pypy can be migrated to be manually bootstrapped, or automatically
bootstrapped from cpython2.7 sources copied into the pypy source
package.

Is bookworm shipping with (CPython) 2.7?
We probably don't want to.
We may ship with a pypy 2.7, primarily for building pypy3.

Shall we keep virtualenv support for 2.7?
=
This will require a separate pip stack for virtualenv.
Stefano is tempted to, for pypy (2.7)
Consensus is NO, we don't need to spend time on this.

pip in Debian
=
Can't upgrade to the latest pip without dropping 2.7 support. Consensus
was to do this ASAP.

PEP 668 has been filed about making the ownership of packages between
apt and pip clearer:
https://discuss.python.org/t/graceful-cooperation-between-external-and-python-package-managers-pep-668/10302

pip has struggled to get sufficient maintenance over the years, more
maintainers would be appreciated.
A big part of its complexity is the de-vendoring of its dependencies.

Shall we vendor pip dependencies?
=
pip has a special place as the one and only tool you expect to have in
a virtualenv, so it vendors libraries that it depends on.
https://github.com/pypa/pip/tree/main/src/pip/_vendor
The de-vendoring mechanism was made in cooperation with upstream, but
they don't like it, and don't support our use of it.

It doesn't really provide the "single security update" benefit as
rebuilding the wheels needs a sourceful upload of pip

* ACTION: stefanor to open the conversation with the security team on what
  they think about us re-vendoring the deps of pip (in terms of impact
  on them).

PEP517 in Debian

The python world is moving to PEP517+518. They define how to build
python packages with tools like setuptools, however they only define the
process to build wheels, not to install packages into the system.
We need to create build tools that can drive pep517 + pypa/install and
then install the wheel, unpacked.

dh-python already supports flit, directly, not using the pep517
mechanisms.

Emmanuel is working on poetry support, and will look at more general
tooling after that.

Other upstream issues to be aware of:
https://bugs.python.org/issue43976 - Add vendor information
https://bugs.python.org/issue44982 - Allow Python distributors to add
custom site install schemes

SR

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



Re: Python BoF at DebConf2021

2021-08-26 Thread Stefano Rivera
Hi Louis-Philippe (2021.08.14_20:01:27_+)
> Sadly, I have prior engagements and I won't be able to make it. Could
> someone else take on the task of coming up with an agenda and chairing
> the BoF?

I've taken it over, and started an Agenda:
https://pad.dc21.debconf.org/p/20-python-team-bof
Please add anything you think we should cover.

And then help me to prioritize what we should actually cover. I think
we've already got more in there than we can cover in the session, so we
should pick the topics that are most useful to discuss.

SR

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



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

2021-08-14 Thread Stefano Rivera
Hi Sandro (2021.08.14_02:25:21_+)
> [1] https://lintian.debian.org/tags/python-teams-merged

There are more than those, some other variants made it into use too:

udd=> SELECT COUNT(*), maintainer_email FROM sources WHERE release='sid' AND 
maintainer_email LIKE '%python%' GROUP BY maintainer_email;
 count |maintainer_email 
---+-
 1 | gst-python...@packages.debian.org
 1 | pkg-python-debian-ma...@lists.alioth.debian.org
 1 | python-apps-t...@alioth-lists.debian.net
 1 | python-apps-t...@lists.alioth.debian.net
62 | python-apps-t...@lists.alioth.debian.org
15 | python-modules-t...@alioth-lists.debian.net
   713 | python-modules-t...@lists.alioth.debian.org
 9 | team+python-modu...@tracker.debian.org
   670 | team+pyt...@tracker.debian.org
(9 rows)

We should fix them all.

Generally +1 to your proposal.

SR

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



Re: Team membership request

2021-06-11 Thread Stefano Rivera
Hi Timo (2021.06.09_22:09:15_+)
> Right now, I would like to help maintain the
> outdated Tweepy package which I'm currently using, but more
> generally, I am an avid Python user, so it would be my pleasure to
> help keep the Python package ecosystem in good shape.
> I'm also member of the Science Team, where I help maintain a number
> of (ROS related) Python packages.

Added. Welcome!

SR

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



Re: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x

2021-06-05 Thread Stefano Rivera
Hi Nilesh (2021.06.05_15:21:22_+)
> > * What about adding an autopkgtest?
> 
> The test is running during build time.[1] I don't think running the same 
> thing as autopkgtest does a very significant improvement.

I think there's generally an advantage in running the same upstream
tests at build time, as well as in an autopkgtest:

1. If something regresses the test suite, it'll block migration of that
   package into testing.
2. It verifies that the package behaves correctly, as installed. (This
   can mean that you need to disable part of the test-suite, that can't
   handle the installed layout.)

Yes, it's also good to have other kinds of tests in autopkgtests, that
verify installed behaviour (e.g. calling --help on an executable, to see
that it can start-up, and smoke testing library public interfaces).

SR

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



Re: Joining the Python Team

2021-05-25 Thread Stefano Rivera
Hi Kyle (2021.05.25_09:11:25_+)
> I wish to join to the Python team to maintain openswitcher [1] and jack
> mixer [2].
> 
> [1] #988182
> [2] https://rdio.space/jackmixer/
> 
> My salsa login is paddatrapper.
> 
> I have read the Debian Team Policy and accept it.

Added, welcome.

SR

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



Re: joining the team

2021-05-25 Thread Stefano Rivera
Hi Salman (2021.05.24_10:55:23_+)
> I would like to join the team and help maintaining *prospector* package
> which has been removed from Stable and Testing but is still in Sid in a
> broken state.

Added, welcome.

SR

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



Re: Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-24 Thread Stefano Rivera
Hi Thomas (2021.05.12_23:06:45_+)
> This looks great. Is there a video of it somewhere?

The official blog post on it has been published:

https://pyfound.blogspot.com/2021/05/the-2021-python-language-summit_23.html

SR

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



Re: RFS: python-splinter 0.14.0 (new package)

2021-05-21 Thread Stefano Rivera
Hi Joseph (2021.05.20_00:53:31_+)
> I finished packaging splinter, a Python package for testing web applications
> using web browser automation (splinter uses selenium).

Had a quick look at it.

Had to rename things in the pristine-tar branch, to get a source
package to build.

Did you consider getting source from GitHub instead of PyPI? That way
you could get the upstream test suite, docs, and license text.
It would be nice to run the upstream test suite (if possible) and have
autopkgtests.

Did you need to list python3-selenium & python3-six in Depends? I would
have expected dh_python3 to pick them up and list them in
${python3:Depends}.

upstream/metadata:
I don't think of GitHub as being an Archive, as described by the
upstream metadata spec. But I can see why you may disagree.
You could list the PyPI Registry entry.

SR

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



Re: Joining the team

2021-05-21 Thread Stefano Rivera
Hi Pablo (2021.05.21_03:17:57_+)
> I'm Pablo Mestre, currently I maintein 4 packages in Debian[1]. I'd like
> to join the Debian Python team partly to help maintain the packages
> colortest-python[2] and python-language-server[3].

Added, welcome!

SR

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



Re: Joining the team

2021-05-21 Thread Stefano Rivera
Hi Dave (2021.05.20_16:56:59_+)
> I'm Dave Jones, currently at Canonical where I work on Raspberry Pi related
> things. I'm also the author of / contributor to a few (largely Pi related)
> Python packages, including gpiozero (which is currently in Debian). I'd like
> to join the Debian Python team partly to help maintain the packages where
> I'm involved with the upstream (such as gpiozero), and partly in the hopes
> of helping get some of the Python packages which only exist in Raspbian
> upstream to Debian.

Added, welcome.

SR

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



Re: Request to join the Python Team

2021-05-20 Thread Stefano Rivera
Hi Carsten (2021.05.19_10:17:19_+)
> >> I'd like to join the Python team on Salsa.
> > 
> > Please read
> > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> > 
> > Hint: 3rd point about joining the team.
> 
> arg, my bad.
> 
> Of course I have before the policy and I agree on that.

Added, welcome :)

SR

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



Re: Request to join the Python Team

2021-05-18 Thread Stefano Rivera
Hi Carsten (2021.05.17_17:04:13_+)
> I'd like to join the Python team on Salsa.

Please read
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Hint: 3rd point about joining the team.

SR

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



Re: Request to join python team

2021-05-17 Thread Stefano Rivera
Hi Sérgio (2021.05.11_22:15:20_+)
> I would like to join the Debian Python team to help maintain typer and 
> crochet.
> 
> My Salsa login is sergiosacj.
> 
> I have read 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>  and accept it.

Added, welcome.

SR

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



Re: Request to join the Python team

2021-05-17 Thread Stefano Rivera
Hi Roland (2021.05.17_16:20:19_+)
> So I hereby request to be added to the python-team group on salsa. My
> salsa login is "lolando", and I have read and accept the
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> policy.

Added, welcome to the team.

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



Re: Request to join Debian Python Team

2021-05-17 Thread Stefano Rivera
Hi Joseph (2021.05.17_03:26:14_+)
> My Salsa username: @njoseph (https://salsa.debian.org/njoseph)
> 
> I hereby declare that I have read the Policy document of the Debian Python
> Team at 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and that I accept it.

Added, welcome.

SR

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



Re: request to join the team

2021-05-17 Thread Stefano Rivera
Hi Felix (2021.05.14_16:02:53_+)
> My salsa login: obfusk
> I have read and accepted 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

Welcome, added to the team.

SR

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



Re: Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-12 Thread Stefano Rivera
Hi Thomas (2021.05.12_23:06:45_+)
> On 5/12/21 11:21 PM, Stefano Rivera wrote:
> > Matthias Klose gave a presentation at the Python Language Summit on the
> > Challenges packaging Python for a Linux distro.
> > [..]
> This looks great. Is there a video of it somewhere?

No, there won't be videos published, only blog posts written.

SR

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



Challenges packaging Python for a Linux distro - at Python Language Summit

2021-05-12 Thread Stefano Rivera
Matthias Klose gave a presentation at the Python Language Summit on the
Challenges packaging Python for a Linux distro.

There's a follow-on open space for working through some of these
questions, on Saturday:
https://us.pycon.org/2021/events/open-spaces/#openspace-42
2021-05-15 18:15 UTC in Lounge 2

Matthias covered:
* No python on Debian systems by default.
* Python2 removal coming soon, just hanging around for PyPy at this point.
* One 3.x version at a time. Doesn't line up with cpython's support terms.
* Python is split into multiple binary packages, for dependency (and
  historically licensing) reasons.
* DFSG
* autopkgtests, and automatic testing of reverse-dependencies
* The existence of the "deadsnakes" PPA for Ubuntu, for people who want
  non-standard Python versions.
* Applications generally are installed outside the default sys.path.
* Modules are shipped installed with --single-version-externally-managed.
* The site-packages => dist-packages rename.
* PEP 3149 sharing a single /usr/share/python3/ across versions and
  implementations.
* Pip isn't used in our packages (except in rare cases).
* A historic look through license issues in the cpython sources, in the
  past.
* The ensurepip module depends on wheels that are shipped without source.
* pip and distro package managers get in conflict, esp. with
  sudo pip install.
* Arch inclusively. Debian includes some weird architectures, some of
  which aren't widely used.
* Communication issues between the Core Python developers + PyPA and
  Debian/Ubuntu recently.

There was a strong Q section. I didn't take notes for this. Off the
top of my head:
* What do we provide for scientific / data scientist use cases?
* Are there technical issues with using python3.x where x != default?
* Are we aware of the problems on Debian?
* Who decides what is/isn't packaged?
* Have we considered a separate "system-python" that lives off PATH, and
  is used by Debian packaged applications. Then developers can get their
  own pristine python?
* Who is still suggesting sudo pip install? pip upstream would be happy
  to help hunt down any references like that.

SR

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



Re: request to join python team

2021-05-11 Thread Stefano Rivera
Hi Jonas (2021.05.11_20:45:55_+)
> I would like to join the Debian Python team, to help maintain the khal 
> package.
> 
> My Salsa login is js.
> 
> I have read 
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
>  
> and accept it.

Added you, welcome.

SR

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



Re: Joining the team request

2021-05-10 Thread Stefano Rivera
Hi Anton (2021.04.07_21:07:15_+)
> I want to update some packages (for example astral - sure, respecting the
> release policy) and also add some newer ones. I have read [1] and accept it. 
> My
> salsa-login is gladk.

Added, welcome to the team.

> Please give me maintainer-permissions, so I will be able to setup CI-pipelines
> for packages which I touch.

Yeah, that's the standard level for the python team.

SR

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



Re: Joining Debian Python Team

2021-05-10 Thread Stefano Rivera
Hi Robbi (2021.04.14_04:50:55_+)
> My salsa login is: @robbinespu
> 
> I have have read the policy[6] and I accept it.

Added you. Welcome to the team.

SR

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



Re: Access request Salsa python-team unkn0wn-user

2021-05-10 Thread Stefano Rivera
Hi Janis (2021.04.08_07:08:20_+)
> as my last email stated, I am one of the upstream maintainers of NESi
> [1] and would like to become part of the debian-python-team.
> 
> I have read the policy that can be found under
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and accept it.

Added, welcome.

SR

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



Re: Joining the team

2021-05-10 Thread Stefano Rivera
Hi Stephan (2021.05.06_21:27:11_+)

> My Salsa login is stephanlachnit.
> 
> I have read the policy and accept it.

Added to the Salsa project.

Welcome to the team.

SR

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



Re: Need a Python 3.8 virtual environment

2021-03-03 Thread Stefano Rivera
Hi Steven (2021.03.03_03:17:36_+)
> steve@riemann:/tmp$ python3.8 -m venv blah38
> The virtual environment was not created successfully because ensurepip is not
> available.  On Debian/Ubuntu systems, you need to install the python3-venv
> package using the following command.
> 
> apt-get install python3-venv
> 
> You may need to use sudo with that command.  After installing the python3-venv
> package, recreate your virtual environment.
> 
> Failing command: ['/tmp/blah38/bin/python3.8', '-Im', 'ensurepip', '--
> upgrade', '--default-pip']
> 
> 
> Note that I do have 'python3-venv' installed, but it is the 3.9 version:
> ii  python3-venv  3.9.1-1 
> 
> amd64pyvenv-3 binary for python3 (default python3 version)
> 
> 
> Is there something I've missed?  

You need python3.8-venv. But even then you may run into a
missing/incompatible distutils (#979819):
https://bugs.debian.org/979819

You can see if you have, by running the failing ensurepip command by
hand.

Hopefully we'll make that situation better soon...

BTW: There's a deadsnakes-like archive for Debian:
https://people.debian.org/~paravoid/python-all/

SR

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



Re: Ported Python Policy to Sphinx

2021-02-27 Thread Stefano Rivera
Hi Dmitry (2021.02.26_19:10:42_+)
> On Fri, Feb 26, 2021 at 06:09:50PM +0000, Stefano Rivera wrote:
> > Hi Dmitry (2021.02.26_08:31:11_+)
> > > You can use :samp:`python3.{Y}`. See:
> >
> > Thanks for the hint. Glad I asked :)
> >
> > Switched to that, and re-rendered.
> 
> Small addition (sorry that I did not mention it earlier): when referring
> to files you can also use :file:. The difference is only semantic, I think
> it will produce the same result:

I did that too, and some :envvar: etc.

SR

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



Re: Ported Python Policy to Sphinx

2021-02-26 Thread Stefano Rivera
Hi Dmitry (2021.02.26_08:31:11_+)
> You can use :samp:`python3.{Y}`. See:

Thanks for the hint. Glad I asked :)

Switched to that, and re-rendered.

SR

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



Ported Python Policy to Sphinx

2021-02-25 Thread Stefano Rivera
Hacking on the docbook Python Policy is no fun.

I ported the current version to sphinx.

MR: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/10

Render: https://people.debian.org/~stefanor/python-policy-sphinx/

I'd appreciate it if anyone who has the time would give it a proof-read.

There are definitely sections that could use garbage collection and/or
re-writes for clarity, but the intention of this MR is to just port to
Sphinx without content changes.

There's no direct equivalent in RST for
python3.Y, the best is
``python3.Y``.
Similarly, I replaced 3Y+1 with ``3.(Y+1)``.

SR

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



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

2021-02-16 Thread Stefano Rivera
Hi Bastian (2021.02.16_09:17:18_+)
> heck, even PIP is outdated in a way that you actually have to `pip
> install -U pip` in order to use it properly due to the recent
> manylinux change.

Hrm, we probably should be backporting support for manylinux2014. Care
to file a bug against pip?

SR

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



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

2021-02-15 Thread Stefano Rivera
Hi debian-python (2021.02.11_18:24:57_+)
> I have prepared a policy MR for this:
> https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8
> It catches up on the current split situation, too.

We had a discussion on the principle of the change, but nobody has
responded to the policy wording yet.

Anyone seconds / objections?

SR

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



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

2021-02-12 Thread Stefano Rivera
Hi Thomas (2021.02.12_09:16:28_+)

I should have combined this reply with my previous one, but it didn't
thread there cleanly:

> I mostly agree to add a metapackage. I just don't agree with the choice
> of package name. It makes our user believe that Python isn't "full"
> without it, and they then may install it when they don't need it to
> consume whatever is packaged in Debian. Reality is different.

The reality is that you're conflating two statements there:
1. Python isn't "full" without it.
2. Users may believe that they need this to run things that are
   packaged in Debian.

I'd say 1 is true, but users believing 2 would be incorrect. As I said
in my other mail, I hope this can be dealt with in the description. And
there's certainly no harm in users making this mistake, beyond
installing unnecessary junk.

We split the Python standard library up into multiple binary packages,
for a variety of reasons, and when you install python3, you don't get it
all. Developers outside of Debian's sphere of influence won't appreciate
those splits and software they write won't be expecting them. We can
deal with this within Debian, but not when users install 3rd party
software directly.

While we may have the goal of packaging all useful software in Debian,
the reality is that this is only ever a goal, constantly unachievable.
We serve our users better when we make it easy to extend beyond Debian.

SR

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



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

2021-02-12 Thread Stefano Rivera
Hi Thomas (2021.02.12_08:10:51_+)
> > From your arguments above, it doesn't sound like the python3-full solves
> > a problem you experience. So, I'm not sure why you'd be using it.
> 
> I don't think I would. And to me, Python is already "full"(y supported)
> without these. Though at least, adding "dev" in its name shows it's not
> for our users.

Yeah, I can see the argument for calling this python3-full-dev.

On the flip side, in debian packaging, -dev implies C headers, and this
is more than that.

I think this would also be dealt with in the package description, I'd
imagine something like:

 Python, the high-level, interactive object oriented language,
 includes an extensive class library with lots of goodies for
 network programming, system administration, sounds and graphics.
 .
 This package is a dependency package, which depends on the full
 standard library of Python for Python developers. Including modules
 used only at build-time, such as venv and distutils, and modules with
 complex dependencies, such as tk and IDLE.
 .
 This package depends on Debian's default python 3 version's full
 standard library (currently v3.9).

BTW, I noticed some other vague descriptions while I was writing this
example description. Fixed:
https://salsa.debian.org/cpython-team/python3-defaults/-/commit/d1430d009688b9affcfa3b95ffcba4dcdcaf33ff

SR

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



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

2021-02-11 Thread Stefano Rivera
Hi Elana (2021.02.11_18:12:34_+)
> - Stefano: Update python-policy to describe "python3-full".

I have prepared a policy MR for this:
https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8
It catches up on the current split situation, too.

diff --git a/debian/python-policy.dbk b/debian/python-policy.dbk
index 875b281..8b67f4a 100644
--- a/debian/python-policy.dbk
+++ b/debian/python-policy.dbk
@@ -233,17 +233,28 @@
  some exceptions.


- Excluded are modules that cannot be included for licensing reasons
- (for example the profile module), for dependency 
tracking
- purposes (for example the GPL-licensed gdbm 
module), or
- that should not be included for packaging reasons (for example
- the tk module which depends on Xorg).
+ Excluded are modules that cannot be included for licensing reasons,
+ for dependency tracking purposes (for example the GPL-licensed
+ gdbm module), or that should not be included
+ for packaging reasons (for example the tk
+ module which depends on Xorg and the venv
+ module which depends on wheels to bootstrap pip).
+ Modules that would interfere with system package management (for 
example
+ ensurepip, when used outside virtual environments) 
are
+ modified to print a message explaining the problem and recommending
+ alternatives.


  Some tools and files for the development of 
Python
  modules are split off in a separate binary package
  
pythonX.Y-dev.

+   
+ Modules only used for building of Python modules
+ (e.g. distutils and lib2to3) are
+ split into separate packages.
+ The python3-venv binary package depends on these.
+   

  Documentation will be provided separately as well.

@@ -255,6 +266,15 @@
  the python3.Y package 
that installs
  the executable.

+   
+ A python3-full binary package must ensure that the
+ entire Python standard library is available, including all modules
+ split into separate packages (but excluding modules excluded from
+ Debian for licensing reasons).
+ This package exists for the convenience of python developers, and
+ must not be used in dependencies by python module or application
+ packages.
+   

  The version of the python3 package must be
  greater than or equal to 3.Y and lower than

SR

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



Re: help me update dateparser to 1.0.0 in time for bullseye

2021-02-04 Thread Stefano Rivera
Hi Antoine (2021.02.05_02:13:56_+)
> I can't figure out how to update dateparser to 1.0.0. I am battling
> pytest and deps and failing. Seems like we'd need to package
> hijri_converter as a dependency, and fix the build so it doesn't require
> network.

Also probably a good idea to package that CLDR data and rebuild the
tables from source.

I pushed some commits to get the build time test passing. The
autopkgtest still needs to be changed to use pytest too, etc.
I'll finish this up later, and upload.

Instead of my patches, you could have used pytest's
--continue-on-collection-errors flag.

SR

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



Re: Joining the team

2021-01-31 Thread Stefano Rivera
Hi Louis-Philippe (2021.01.31_21:43:48_+)
> > whether it's fine to enable branch/tag protection
> 
> Nothing on that either.

When we imported packages we set this up. But haven't automated managing
it on all / new packages, yet. (The tools for automation didn't exist at
the time)

> > adding webhooks to tag BTS bugs as pending when a fix is merged
> 
> AFAIK, you don't need to add webhooks for that to work, something (I
> don't know what) scans through all new commits on Salsa and checks for
> relevant BTS info.

As I understood it, that's the tagpending webhook, which we have set up
on all our repos, at import time.

SR

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



Re: Joining the team

2021-01-31 Thread Stefano Rivera
Hi nicoo (2021.01.31_16:39:43_+)
> > cool! Please follow our policy:
> > https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
> > to join the team.
> 
> I've read and accepted the policy, my login is nicoo, and I mentionned in
> the previous emails my motivation for joining the team.

Added!

Happy package maintenance :)

SR

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



Re: Request to join the Python Team

2021-01-24 Thread Stefano Rivera
Hi Pablo (2021.01.24_23:33:52_+)
> I'm sending this message as a request to join the Python Team.

Added. Welcome.

SR

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



Re: Respectfully request to join the debian python team

2021-01-21 Thread Stefano Rivera
Hi PerRy (2021.01.22_00:48:18_+)
> thanks for the advice, I'll definitely take a look into patching and
> orphaned packages. As far as mentoring how would I go about doing that?
> finding one that is.

I'd say post upload requests to the debian-mentors lists, or patches to bugs.
There's a freeze coming up soon, so RC bugs are especially valuable to
fix.

I'm afraid this path often isn't easy. It's definitely one of Debian's
weaker areas, but with good work and persistence you should be able to
get some uploads done.

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



Re: Respectfully request to join the debian python team

2021-01-21 Thread Stefano Rivera
Hi PerRy (2021.01.21_07:39:50_+)
> I wanted to request to join the debian python team. In a previous email, I
> shared that I have been using debian for a while now and at this point in
> time I want to contribute back to the project. One of my skills is writing
> scripts in python, and I want to utilize and build upon this skill in
> contributing back to debian.

Aside from a password reset, I'd recommend getting started by
contributing patches through the bug tracking system, or adopting some
orphaned packages, and getting some experience maintaining them. Ideally
finding some mentors to help you out, along the way.

We don't generally give people who are brand new to contributing to the
project commit access to hundreds of packages.

SR

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



Re: could you please add me to the team?

2021-01-10 Thread Stefano Rivera
Hi Francesco (2021.01.07_12:02:08_+)
> Of course I'm familiar with current team policy at
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst

I'm interpreting that as you agreeing to follow the team policy, and
I've added you.

Welcome to the team.

SR

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



Re: Joining the team

2020-12-27 Thread Stefano Rivera
Hi Aron (2020.12.27_18:35:29_+)
> I'd like to join the team to maintain some new packages, namely 
> python3-easydict
> and python3-astunparse, which are dependencies of my other package. I believe
> the two packages are more suitable to be maintained in this team, rather than 
> a
> field specific team.

Added, welcome :)

SR

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



Re: Joining the team request for salsa user microjoe-guest

2020-12-11 Thread Stefano Rivera
Hi Romain (2020.12.02_11:50:22_+)
> In order to publish some Python packages that will act as dependencies
> to packages for font management, I would like to join the fonts team.

And the python team, presumably :)

> My salsa login is "microjoe-guest".

Guessing you meant "microjoe".

Added, welcome.

SR

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



Re: Python 2 support for Bullseye

2020-12-11 Thread Stefano Rivera
Hi Moritz (2020.10.16_18:33:06_+)
> > not ok. That would mean removing pypy3 from the archive as well. If you 
> > don't
> > want to support Python2, then why do you care about it's removal for 
> > bullseye+1?
> 
> Ok. I assumed the need for Py2 in pypy3 was a temporary thing? If it's needed
> for longer (is there an estimate of sorts?), I'm also fine with keeping
> it longer.

Sorry, rather late to this thread.

PyPy upstream is looking at converting the rpython toolchain to python3,
but I wouldn't expect progress any time to. So, I'll continue to need
some form of python2.7 (python2.7 or pypy) to build pypy3 for the
foreseeable future.

pypy (2.7) uses python2.7 to build itself on architectures where that's
faster than using pypy (architectures where pypy has no JIT).

But pypy could be entirely self-hosted and then python2.7 could be
dropped from the archive. Downside: manual bootstrapping of pypy would
be required on new archs & after certain build failures. I assume this
will have to happen at some point.

SR

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



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

2020-12-11 Thread Stefano Rivera
Hi Thomas (2020.10.09_11:12:21_+)
> For those:
> 
>python-etcd3 (U)
>python-requests-mock (U)
>python-sphinxcontrib.apidoc (U)
> 
> they in fact live in the OpenStack team namespace, but I don't have
> enough rights to delete the Git repositories. Can someone do it for me
> please?

Deleted.

SR

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



Re: Joining PAPT

2020-08-17 Thread Stefano Rivera
Hi Taowa (2020.08.17_15:47:41_+)
> I am taking over membernator, currently maintained by pollo. To this
> end, I'd like to be granted access to the team to allow me to
> effectively do so. I am taowa on Salsa.

Added to Salsa.
Welcome to the team :)

SR

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



Re: Request to join Debian Python Team

2020-08-04 Thread Stefano Rivera
Hi Juri (2020.07.29_13:08:48_+)
> I read and accept the policies [1][2]. My Salsa username is gratuxri [3].

Welcome. Added you to PAPT and DPMT.

SR

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



Re: DebConf20 @ Home -- Python Team Bof & Sprint ?

2020-07-01 Thread Stefano Rivera
Hi Louis-Philippe (2020.07.01_13:59:15_+)
> If you'd like to see a Python BoF + Sprint happen during DebConf20@Home,
> please show your support.

Yes please.

SR

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



Re: Moving utility scripts from one package to another

2020-06-23 Thread Stefano Rivera
Hi Scott (2020.06.23_21:56:04_+)
> I have a couple of (mostly library) Python packages, src:wxpython3.0, which
> was Python 2 only and has been recently RM'd and src:wxpython4.0 which is
> Python 3 only.  wxpython3.0 had a subpackage, python-wxtools, which
> contained a few utility scripts.  wxpython4.0 can also provide those utility
> scripts, so I just wanted to confirm what I need to do to make that happen
> safely when adding a python3-wxtools package to replace python-wxtools.
> 
> 1) python3-wxtools should Replace:, Provide:, and Conflict: python-wxtools,
> correct?

Yep. Essentially this is a rename and you're following this method:
https://wiki.debian.org/RenamingPackages#Clean_slate_method

> 2) Should python3-wxtools even be named with the python3- prefix if it is
> not providing a Python library?  I'm thinking not.

Yeah, probably not.

SR

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



Re: Python Wheel Related Policy Change

2020-04-30 Thread Stefano Rivera
Hi Scott (2020.04.30_20:33:59_+)
> > That seems reasonable, although if we're going down that road, it
> > probably makes no sense for any of them to be universal.
> 
> If we were talking about maintaining this for multiple release cycles with 
> lots of version divergence, I would agree.  Let's not do more than we have to 
> until python2 is gone (whether it is before bullseye or after).

I suspect pypy (2.7) will probably be around post-bullseye, unless
somebody funds pypy to migrate rpython to python 3.

But yeah, we can change strategy later, if appropriate.

> As a result, one could add some kind of py2 flag to dirtbike to tell it to 
> look 
> in /usr/lib/python2.7/dist-packages and make a 'universal' wheel from there.  
> It could then rename the files from py2.py3-none-any.whl to py2-none-any.whl. 
>  
> The bonus Tag in the WHEEL file shouldn't hurt anything.
>
> They key is I think we can do this without actually running python2, we just 
> need to be able to install python-setuptools/pkg-resources.  That should be 
> supportable ~as long as python2.7 is in the archive.

Yep, that sounds good.

> Agreed.  As long as pip supports python2, we should try.  Worst case we can 
> tell people to find their own interpreter and do a --download install with 
> setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because 
> they'll 
> get the upstream pip in the virtualenv too.  

When we get to the download route: pip can parse Requires-Python, and it
looks like virtualenv uses the system pip to download pip, so the
pinning shouldn't be necessary, I think.

> > So, the options are:
> > 1. pin pip dependencies at versions that support py2, forever. Obviously
> >this is a no-go.
> > 2. Ship py2 and py3 wheels.
> >2.1. package the py2 weels with dirtbike. This requires bringing back
> > python-wheel, or more work on dirtbike.
> >2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
> > upstream is continuing development...
> > 3. Let virtualenv always download pip from pypi for py2. Only ship py3
> >wheels.
> > 
> > The easy options here are 2.2 and 3.
> 
> 2.1a Where needed package 'py2' wheels with dirtbike running python3.

Ah, yeah.

Still requires keeping py2 source packages whenever a library in the pip
dependency stack drops py2 support. But if they move slowly, that's
fine.

> 2.2 is using sourceless binaries, so I think it's got DFSG issues.  We need 
> the preferred form of modification and a bdist_wheel is not that.

They could be bdist_wheeled at build time, within a single source
package.

> I think 2.1a would be nice if someone can manage it.  We'll need to support 3 
> eventually.  I plan to implement 3 as an option when I upload pip 20.1 and 
> virtualenv 2.0.18.

Not necessarily. 2.2 is equivalent to 3, but without hitting PyPI.

SR

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



Re: Python Wheel Related Policy Change

2020-04-30 Thread Stefano Rivera
Hi Scott (2020.04.30_16:23:41_+)
> Making dirtbike build a py3 wheel for setuptools (and pkg_resources), which 
> is 
> technically accurate at this point since dirtbike can't build wheels from a 
> python2 package was trivial to do:
> 
>  dirtbike/__init__.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Three of the five insertions were comment.

That seems reasonable, although if we're going down that road, it
probably makes no sense for any of them to be universal.

> If someone wants to provide a patch to dirtbike so it can also build wheels 
> from python-setuptools and python-pkg-resources, then we could add then to 
> build-depends and provide both a set of py2 wheels and py3 wheels for as long 
> as they are in the archive.

The window for doing this is probably closing, too.

I hacked this in Ubuntu 20.04, just before release:
https://launchpadlibrarian.net/475592029/python-pip_20.0.2-5_20.0.2-5ubuntu1.diff.gz

As you can see, python-wheel is no longer available, and some of the
other libraries dirtbike uses are probably heading that way.

So, to make that approach work, we have to introduce more py2-only
libraries again, or allow dirtbike to build py2 wheels while running
under python3.

> It still needs the Python policy change since they aren't universal, but it 
> would allow setuptools to keep up for python3 in pip without dropping the 
> local wheels from python2.  We also have ipaddr back in the archive to 
> support 
> wheeling it so pip will run with python2.

But, without the py2 setuptools wheels, I don't know much that buys us.

Long-term: pypy (2.7) is going to continue to be around, until rpython
moves to python3 (which is still officially never, but people are
starting to poke at it).
https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2

If we have a python 2 interpreter, it's really nice to have working
virtualenv for it. Makes it a lot more useful for users, esp. as we
don't have many debian libraries packaged for it.

So, the options are:
1. pin pip dependencies at versions that support py2, forever. Obviously
   this is a no-go.
2. Ship py2 and py3 wheels.
   2.1. package the py2 weels with dirtbike. This requires bringing back
python-wheel, or more work on dirtbike.
   2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
upstream is continuing development...
3. Let virtualenv always download pip from pypi for py2. Only ship py3
   wheels.

The easy options here are 2.2 and 3.

SR

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



Re: pkg-config of python3

2020-04-24 Thread Stefano Rivera
Hi PICCA (2020.04.24_07:33:48_+)
> so it seems that the program is not linked with the Python3 library
> 
> I use pkg-config to obtain the library
> 
> picca@2a02-8420-6c55-6500-d012-4688-0bee-a0c6:~/hkl/contrib/haskell$ 
> pkg-config --libs python3
> 
> picca@2a02-8420-6c55-6500-d012-4688-0bee-a0c6:~/hkl/contrib/haskell$ 
> pkg-config --libs python2
> -lpython2.7

If you want to embed python in an application, you need to use python3-embed.pc
Or python3-config --embed

See:
https://docs.python.org/3/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build

Python libraries should not be linked to libpython, as that's present
when they're loaded into the interpreter.

SR

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



Re: Request to join PAPT and DPMT

2020-02-04 Thread Stefano Rivera
Hi Philipp (2020.02.04_18:34:43_+)
> I'd like to join PAPT and DPMT to move my so far individually maintained
> Python packages into the respective Teams.

Welcome :)

SR

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



Re: Request to join DPMT

2020-02-02 Thread Stefano Rivera
Hi Christoph (2020.01.30_20:31:09_+)
> I'd like to join DPMT to maintain my Python modules mercurial-keyring and
> mercurial-keyring-utils.
> 
> I've read and accept policy.rst.
> 
> My salsa login is: eraserix-guest

Welcome!

SR

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



Re: PAPT: join request

2020-01-29 Thread Stefano Rivera
Hi Joel (2020.01.29_10:46:22_+)
> Yes, joelcross-guest is my username, and I agree to the team policy.

Added, welcome!

SR

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



Re: Request to join DPMT and PAPT teams

2020-01-28 Thread Stefano Rivera
Hi Rhuan (2019.11.07_20:13:16_+)
> I'm interest to join DPMT and PAPT packaging teams because i want to help
> maintain some python modules and applications and future modules/apps made
> by myself.
> 
> I subscribed in this mail list and my salsa login is: @rhuancpq-guest
> 
> I have read and agree to policy of both teams and know about how works
> maintainership, license and QA on them.

Sorry about the delay.

Can you tell us more about what packages you are interested in working
on?

Have you found a sponsor / mentor who will be able to help you with
uploads?

SR

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



Re: Request to join DPMT and PAPT teams

2020-01-28 Thread Stefano Rivera
Hi Balasankar (2020.01.20_19:30:49_+)
> I am a Debian Developer and I maintaining two packages - python-wget and
> vim-autopep8 under DPMT and PAPT teams respetively.

Welcome!

SR

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



Re: Joining the PAPT team

2020-01-28 Thread Stefano Rivera
Hi Devid (2020.01.16_19:33:19_+)
> My Salsa username is d.filoni-guest .

Re-added. Welcome back.

I'll assume you agreed to the team policy, back in the Alioth days...
https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst

SR

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



Re: Request to (re)join Python team

2020-01-28 Thread Stefano Rivera
Hi Utkarsh (2019.12.30_21:31:01_+)
> I'd like to migrate my current membership of the Python team to use my
> new Salsa login, i.e., utkarsh \o/
> (Previously it was utkarsh2102-guest)

\o/

Migrated your membership from utkarsh2102-guest to utkarsh in both
teams.

SR

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



Re: PAPT: join request

2020-01-28 Thread Stefano Rivera
Hi Joel (2020.01.22_13:29:08_+)
> I would like to join this team so that I can maintain the
> python-pipenv-pipes package, which I erroneously initially put on DPMT
> on Salsa, despite it being an application. Sergio is acting as my
> sponsor for this package.

Hi,

I assume your username is joelcross-guest.

Do you agree to the team policy?
https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst

SR

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



Re: Request to join the PAPT (already a member of DPMT)

2020-01-28 Thread Stefano Rivera
Hi Nicholas (2020.01.28_00:03:37_+)
> I'd like to join the PAPT, since the PAPT is the best place for an RFP
> that I've chosen to work on.  I am already a member of the DPMT, so have
> already accepted Team Policy, and of course have accepted remaining in
> compliance with its changes.

Added, welcome to the other side of the team.

SR

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



Re: Salsa repo deletion request: modules/colortest-python

2020-01-07 Thread Stefano Rivera
Hi Otto (2020.01.07_15:28:16_+)
> Can somebody with admin permissions please go to
> https://salsa.debian.org/python-team/modules/colortest-python/edit and
> delete it?

Done.

SR

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



Re: Joining DPMT

2019-12-24 Thread Stefano Rivera
Hi James (2019.11.29_02:41:30_+)
> I'd like to help maintain the python-neovim package, as part of my
> general maintenance of the (neo)vim ecosystem.

Added. Welcome to the team :)

SR

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



Re: Joining PAPT

2019-12-24 Thread Stefano Rivera
Hi Scott (2019.12.05_16:42:02_+)
> I'm already a member of DPMT, I would like to join PAPT as well so I can
> also contribute to those packages.  I have read the policy and accept it.

Added. Sorry about the delay.

SR

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



Re: Joining the team

2019-06-13 Thread Stefano Rivera
Hi Georg (2019.05.28_13:04:24_+0200)
> I became a DD now, could someone please add my new account "georg" to
> the team?

Done. Sorry about the delay.

SR

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



Re: Joining the PAPT team

2019-06-13 Thread Stefano Rivera
Hi Louis-Philippe (2019.06.13_18:55:19_+0200)
> Ping. I haven't heard back from anyone on the list :( I also asked about
> this on IRC and no one replied.

Added. Welcome! Sorry, my mail is a dumpster fire.

SR

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



Re: Byte-compilation for pypy3

2018-08-27 Thread Stefano Rivera
Hi Piotr (2018.08.27_11:15:05_+0200)
> > err, you meant for python3-foo packages

Yes, I did.

> err again (sorry, to many things at once), I meant option 4 (I can
> change dh-python to generate additional checks for pypy{compile,clean})

That'd be pypy3{compile,clean}

OK, so, now to figure out the "magic" part (byte-compiling already
installed modules when pypy3 is installed / removed.

Should I run the runtime.d directory? Currently everything in that will
only do things with cpython bytecode.

Apps that aren't in dist-packages probably don't need pypy3 bytecode,
unless they want to be run with pypy.

Anything that tries to determine the version (e.g
/usr/share/python3/runtime.d/public_modules.rtinstall and
/usr/share/python3/runtime.d/public_modules.rtremove) looks like they
would break if I told them the version was pypy3.

So, I'm somewhat tempted to ignore runtime.d entirely, and just
byte-compile /usr/lib/python3/dist-packages. That seems pretty hacky,
though :/

SR

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



Byte-compilation for pypy3

2018-08-26 Thread Stefano Rivera
So, I've had some pypy3 packages sitting around for a while, and the
main thing that's stopped me from uploading, is figuring out a plan for
byte-compilation.

If it's sharing /usr/lib/python3/dist-packages with cPython (which it
currently is) then we should figure out a plat for byte-compiling for
it.

rtupdate and postinst / prerm hooks for python3 packages currently call
py3{compile,clean} which only operates on cpython3.

Options I can think of:
1. Ignore byte-compilation entirely.
2. Change py3{compile,clean} to call pypy3{compile,clean} too.
   And do some extra compiling / cleaning when pypy3 is installed and
   removed.
3. Change py3{compile,clean} to do the work of pypy3{compile,clean} too.
   And do some extra compiling / cleaning when pypy3 is installed and
   removed.
4. Change the snipets dh_python3 generates, to include
   pypy3{compile,clean}, when they exist. And again, do the extra
   compiling / cleanup.
5. Something else?

3 *seems* like the right option - py3{compile,clean} supports a range of
cpython versions, already. But I'm not really sure.

Here's what I've got:
https://salsa.debian.org/debian/pypy3
https://people.debian.org/~stefanor/pypy3/

Other TODOs that need some attention but possibly aren't blocking an
upload to unstable:
* test failures and errors
* import paths aren't quite right, yet, e.g.:
  - setup.py install installs to a /usr/local path that isn't on
sys.path
  - plat-linux2 is on sys.path, but doesn't exist

SR

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



Re: PAPT migrated to Git on Salsa

2018-02-27 Thread Stefano Rivera
Hi Ondrej (2018.02.27_22:17:56_+0200)
> Any reason why you didn't add entry into d/changelog about changing Vcs-*
> fields?

Because there wasn't a reasonable entity to attribute the change to. I
didn't review them (mostly).

And it was another source of potential failure during the migration.

SR

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



Re: PAPT migrated to Git on Salsa

2018-02-24 Thread Stefano Rivera
Hi debian-python (2018.02.24_20:13:14_+0200)
> 1. Packages that have never been uploaded aren't really in a useful
>state, yet (e.g. alienfeed)

These are the packages that aren't in sid (either never uploaded or
RMed):

{'alienfeed',
 'canto',
 'emesene',
 'episoder',
 'etm-qt',
 'fusion-icon',
 'glipper',
 'gmobilemedia',
 'google-sitemapgen',
 'harvestman',
 'hotssh',
 'indywiki',
 'kabikaboo',
 'kyklop',
 'mpdris',
 'oggconvert',
 'openerp7',
 'plainbox-provider-piglit',
 'pyaimt',
 'pybackpack',
 'pyicqt',
 'pyomo',
 'pypar2',
 'screenlets',
 'series60-remote',
 'topshelf',
 'trac-batchmodify',
 'trac-git',
 'turses',
 'upnp-inspector',
 'viridian',
 'wader',
 'zine'}

Shall we kill them all?

> 2. A couple of packages are going to need some manual intervention:
>dreampie, gitinspector, vdirsyncer

Dealt with. Turns out dreampie is in the first set too, so just never
migrated it.

SR

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



PAPT migrated to Git on Salsa

2018-02-24 Thread Stefano Rivera
I've finished migrating PAPT to Salsa
https://salsa.debian.org/python-team/applications

There are probably some packages in there that aren't actually team
maintained any more. We should clean them up.

There were also a couple of failures not in the log during the
migration:
1. Packages that have never been uploaded aren't really in a useful
   state, yet (e.g. alienfeed)
2. A couple of packages are going to need some manual intervention:
   dreampie, gitinspector, vdirsyncer

Pushes to the SVN repository have been disabled.

SR

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



Re: Help proposed for migration of PAPT repos to Salsa

2018-02-23 Thread Stefano Rivera
Hi Scott (2018.02.23_23:46:21_+0200)
> I think I'll just push them straight to Salsa, and we can review the
> result there. Sound sensible?

Here's one package:
https://salsa.debian.org/python-team/applications/beets

The rest would have the same layout.

SR

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



Re: Help proposed for migration of PAPT repos to Salsa

2018-02-23 Thread Stefano Rivera
Hi Scott (2018.02.23_12:09:20_+0200)
> Yes. I was planning on running the old scripts again. I'll do that
> today.

OK, I think I've got something that's ready.

I think I'll just push them straight to Salsa, and we can review the
result there. Sound sensible?

SR

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



Re: Help proposed for migration of PAPT repos to Salsa

2018-02-23 Thread Stefano Rivera
Hi Scott (2018.02.23_07:53:47_+0200)
> This clearly needs to be done.  Do we have any other volunteers?

Yes. I was planning on running the old scripts again. I'll do that
today.

I didn't get much review last time, but there did seem to be a general
+1

SR

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



Re: PAPT git migration

2017-05-31 Thread Stefano Rivera
Hi Scott (2017.06.01_05:01:00_+0200)
> As long as we have one team solution for this that is documented I
> don't care what it is as long as it works. I don't think we should
> have two approaches.  Let's pick one and use it.  Team members should
> not be surprised when they look at a team git repo.

I don't think anyone is advocating two approaches. But we don't need to
enforce the use of pq. We have git repos that are compatible with the
use of pq, and you can use it to manage your quilt series, if you wish.
The serialized quilt series is what we have in the shared git repo.

The upside of not doing a once-off migration to pq-friendly patch
metadata is that the git migration will cause less churn on source
packages. That patch metadata churn can be delayed until the next
upstream release is imported.

The downside is that it's up to the maintainer to notice and re-format
their patch metadata, the first time they want to use pq, after the
migration.

SR

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



Re: PAPT git migration

2017-05-31 Thread Stefano Rivera
Hi W. (2017.05.31_22:54:10_+0200)
> > * trac-batchmodify: OK
> > * trac-git: missing a tag [DONE]
> 
> Those two are only in oldstable.
> Not sure whether it is worth to migrate them at all.

Yeah, let's ditch them entirely. I picked up on some deleted packages
during my review, when the history was weird. But didn't systematically
look for them.

> > * trac-privateticketsplugin: missing some tags [DONE]
> 
> This git repository should probably renamed to
> trac-privatetickets.

Added rules for all of this in
https://anonscm.debian.org/cgit/users/stefanor/dpmt-migration.git/commit/?id=b746cddd2af2f6b6b24e74866ab8bccd45f1aedc

SR

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



Re: PAPT git migration

2017-05-31 Thread Stefano Rivera
Hi Barry (2017.05.31_23:32:20_+0200)
> I did a spot check on twine.  I don't see a debian/.git-dpm file on master so
> git-dpm won't work.  Is it supposed to?
> Let's assume not (which is fine with me; i.e. why adopt git-dpm for PAPT when
> we know we just want to get rid of it later?).

Yep, no git-dpm. For those reasons.

> upstream as described here https://wiki.debian.org/Python/GitPackagingPQ
> 
> $ gbp pq export
> - This doesn't work until you at least do a first pq import, but now I see the
>   d/p/changlog-docs patch gets changed in ways that lose information:

Sounds like a limitation of pq import. I'm suprised it doesn't support
DEP3. That was something that dpm got right (once we figured out the
right parameters).

So, our options are:
1. fix pq
2. modify all the patches to a format that pq understands
3. leave this to the maintainer to resolve (I think we expect all pq use
   to be entirely local, so pq use isn't something we're imposing on
   anyone)

SR

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



PAPT git migration

2017-05-31 Thread Stefano Rivera
APT
* pythontracer: recent history is NMUs, so it vaguely makes sense
* python-xdgapp: ITP rejected [DELETED FROM SVN]
* pytimechart: recent history is NMUs, so it vaguely makes sense
* pyzor: OK
* rabbitvcs: OK
* raddisplay: never uploaded, abandoned [DELETED FROM SVN]
* rdiff-backup: OK
* remote-hellanzb-gui: never uploaded, ITP closed [DELETED FROM SVN]
* retext: OK
* retweet: missing some intermediate tags, but OK
* roundup: RMed [DELETED FROM SVN]
* rubber: OK
* s3cmd: Moved to DMPT [DELETED FROM SVN]
* s3ql: Moved to collab-maint [DELETED FROM SVN]
* sabnzbdplus: OK
* screenlets: recent uploads didn't get to SVN, but OK
* scribes: RMed [DELETED FROM SVN]
* sec-wall: never uploaded, abandoned [DELETED FROM SVN]
* series60-remote: OK
* simple-image-reducer: OK
* sinntp: recent NMUs, but OK
* sk1: never uploaded, ITP closed [DELETED FROM SVN]
* slapos.core: OK
* slimit: moved to DPMT [DELETED FROM SVN]
* slingshot: missing tag [DONE]
* smem: OK
* snakefood: OK
* sonata: OK (maintainerless)
* spambayes: OK
* speedtest-cli: debian revision missing in tags [DONE]
* spe: OK (recent uploads are NMUs)
* startupmanager: Orphaned [DELETED FROM SVN]
* subdownloader: missing a tag [DONE]
* svnmailer: Orphaned [DELETED FROM SVN]
* synopsis: OK
* terminator: OK
* termsaver: OK
* testrepository: OK
* tictactoe-ng: OK
* topshelf: OK
* tox: moved to DPMT [DELETED FROM SVN]
* trac-batchmodify: OK
* trac-bitten: missing some tags [DONE]
* trac-codecomments: missing a tag [DONE]
* trac-git: missing a tag [DONE]
* trac-mastertickets: missing some tags [DONE]
* trac-privateticketsplugin: missing some tags [DONE]
* trac-roadmap: missing a tag [DONE]
* ttb: OK
* turnin-ng: OK
* turses: missing a tag [DONE]
* tvnamer: OK
* twine: OK
* twitterwatch: missing a tag [DONE]
* txt2tags: OK (most recent upload is an NMU)
* upnp-inspector: OK
* vdirsyncer: never tagged [DONE] there's an experimental upload in there that 
probably messes with the history
* veusz: OK
* viridian: OK
* vitables: moved to debian-science [DELETED FROM SVN]
* vrfydmn: OK
* vulture: OK
* wader: OK
* wapiti: moved to pkg-security-team [DELETED FROM SVN]
* webcheck: OK
* whyteboard: OK
* winpdb: OK
* writetype: OK
* wtop: Orphaned [DELETED FROM SVN]
* xdot: OK
* xtree: RMed [DELETED FROM SVN]
* zine: OK

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



Ad-hoc Debian Python BoF at PyCon US 2017

2017-05-24 Thread Stefano Rivera
Doko, Barry, and I found ourselves in a room at PyCon US. These are the
minutes of our discussion:

== Deprecate Python 2 ==

Lintian checks for python 2 only packages
Lintian checks for /usr/bin/python2? shebangs

Ask FTP-master not to accept Python 2 only packages.

Start using python3-sphinx rather than python-sphinx.

== System Python ==

Whatever that even means, PEP 432?

Users sudo pip / setup.py installing packages can break their applications.

Getting /usr/local off sys.path is a way to stop that from happening, but
users will presumably work around it.

Doko would like to see some example bugs.

== Supporting Python 3.6 ==

Ubuntu is starting to do python 3.6 transition. Many bugs are being submitted
to debian, tagged debian-python@lists.debian.org/python3.6 Sadly not all of 
them.

We should do 3.6 after stretch opens.

== Python for Buster ==

3.7 should release in June 2018, 3.7.1 around September.
doko doesn't want to make 3.7 default until 3.7.1 has come out.

If we have a plan, the release team will hopefully allow us to use 3.7.1, even
if we freeze in November.

== Dropping 3.5 ==

As soon as 3.6 is the default.
doko is also working on GCC 3.7, atm.

== Debug packages ==

Python 3.6 has an alloc debugging framework that works in the normal (non-dbg) 
build.
https://docs.python.org/3/whatsnew/3.6.html#pythonmalloc-environment-variable

Which means that there is less value in the -dbg packages.

Another option would be to turn on the gcc address sanitizer or undefined
behaviour checker, to make it an even better debugging tool. The undefined
behaviour check may be a bridge too far to be useable.

People need to be reminded to create them. They are not dbgsym packages, but
actually a different interpreter.

== pypy3 ==

Sharing a sys.path with cpython is going to mean import errors in some cases.
We should probably just live with those, and see what the bugs look like. It'll
be fairly experimental at first.

== /usr/bin/python = python3? ==

Never! :)

== python 2.7s future ==

Buster *may* be the last Debian release with Python 2.x. Maybe drop it into
unstable-only, after that?

Stefano is sceptical :P

Fedora expects to be shipping 2.7 for a long while still.

== Scan the archive for Python 2.7 apps? ==

Checking Depends would be a good start. May want to scan shebangs too. Start
MBFing.

== DebConf17 ==

Python 3.6 porting sprint, somewhere near the end of DebCamp? On 3rd?

piotr has submitted a Python BoF.

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



Re: PEP 384 (limited ABI)

2016-12-31 Thread Stefano Rivera
Hi Dmitry (2016.12.31_18:07:17_+0200)

cffi modules will also now use the limited ABI, where possible, so I've
played with them a bit.

> A) Build with only one Python 3 version and install the .so files with
>foo.abi3.so filenames (so no rebuilds will be needed for Python updates);

I think dh_python3 already has the necessary support for that.

Just one thing to watch out for: python3-dbg builds will also use
abi3.so, but aren't actually compatible.

https://bugs.python.org/issue28401

SR

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



Re: pypy pakages

2016-05-10 Thread Stefano Rivera
Hi Michael (2016.05.10_19:23:33_+0200)
> is there a specific reason why there are so few pypy-* packages in the
> archive? Is it just a lack of interest or are any practical reasons not
> to have them?

I think we're all kind of waiting for PyPy 3, so that we don't have to
bring up an entire stack of packages (that few people are going to use).

Personally, I've crated a couple, just to be sure that it all works
correctly.

It'd probably be useful to package numpypy, and other non-trivial
things.

Otherwise, I'm not convinced that a large pypy stack in Debian is really
useful right now. Practically, I expect most pypy users to be
virtualenv-heavy.

SR

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



Re: How to put experimental upload into git

2016-02-01 Thread Stefano Rivera
Hi Nikolaus (2016.02.01_18:10:28_+0200)
> I'd like to upload the newest python-llfuse release to experimental first.
> 
> * Commit regularly, with the upload to unstable becoming a descendant   of
> the upload to experimental.

I think it's perfectly reasonable to have experimental uploads like this
in master. If you need to do another unstable upload that precedes it
(which seems rare in these cases), you can always go back and start a
diverging branch.

SR

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



Re: accidental import with git-buildpackage

2015-11-02 Thread Stefano Rivera
Hi Jeremy (2015.10.22_17:34:18_+0200)
> So I imported a new upstream version of python-netfilter using
> git-buildpackage, only to realise I am supposed to use git-dpm. Now my
> repo is in a state which git-dpm cannot handle.

I think you need this:
diff --git a/debian/.git-dpm b/debian/.git-dpm
index 304a57d..489effd 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,8 +1,8 @@
 # see git-dpm(1) from git-dpm package
-c71cce237a933c97428e855b3d0decae10db41b0
-c71cce237a933c97428e855b3d0decae10db41b0
-c71cce237a933c97428e855b3d0decae10db41b0
-7a2d732ba3110dda1892a4be1f57487d9ce295c7
+8c90fbc9ef8d65e5b26ffbaed0aa6723d025a59e
+8c90fbc9ef8d65e5b26ffbaed0aa6723d025a59e
+8c90fbc9ef8d65e5b26ffbaed0aa6723d025a59e
+8c90fbc9ef8d65e5b26ffbaed0aa6723d025a59e
 python-netfilter_0.6.3.orig.tar.gz
 e33e52fff0b0bbdcc5b4731a2ec76f9181656e63
 22925

Then you should be able to drive git-dpm.

SR

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



Re: git repo lint tool

2015-10-13 Thread Stefano Rivera
Hi Daniel (2015.10.13_17:47:01_+0200)
> In all packages, Vcs points to
> Vcs-Git: git://anonscm.debian.org/python-modules/packages/.git
> Vcs-Browser: 
> http://anonscm.debian.org/cgit/python-modules/packages/.git

The linter script wants https for Vcs-Browser.

SR

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



  1   2   >