Re: Suggesting change in DPT policy

[Arto Jantunen]

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

I support this change to the team policy.

-- 
Arto Jantunen

Bug#1027916: ITP: aiohttp-oauthlib -- oauthlib for aiohttp clients

[Arto Jantunen]

Package: wnpp
Severity: wishlist
Owner: Arto Jantunen 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: aiohttp-oauthlib
  Version : 0.1.0
  Upstream Contact: Hugo Osvaldo Barrera 
* URL : https://git.sr.ht/~whynothugo/aiohttp-oauthlib
* License : ISC
  Programming Lang: Python
  Description : oauthlib for aiohttp clients

This library is a port of requests-oauthlib for aiohttp. vdirsyncer needs this
library to be able to access calendar systems that use OAuth.

The package will be maintained under the Debian Python Team.

Re: Bug#970282: O: python-inflect -- Generate plurals, singular nouns, ordinals, indefinite articles

[Arto Jantunen]

"Iain R. Learmonth"  writes:
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-python@lists.debian.org
>
> I intend to orphan the python-inflect package. This would be a good
> candidate for the Python team. It has reverse dependencies in Debian:
> python3-jaraco.itertools and sqlacodegen.
>
> The package description is:
>  The inflect Python module correctly generates plurals, singular nouns,
>  ordinals and indefinite articles. It can also convert numbers to words.

Agreed, this should be transferred to the Python team. I can be an
uploader for it (I already maintain sqlacodegen, even though it appears
to have been abandoned upstream).

-- 
Arto Jantunen

Bug#960744: ITP: python-aioinflux -- Asynchronous Python client for InfluxDB

[Arto Jantunen]

Package: wnpp
Severity: wishlist
Owner: Arto Jantunen 

* Package name: python-aioinflux
  Version : 0.9.0
  Upstream Author : Gustavo Bezerra 
* URL : https://github.com/gusutabopb/aioinflux
* License : MIT
  Programming Lang: Python
  Description : Asynchronous Python client for InfluxDB

 Asynchronous Python client for InfluxDB. Built on top of
 aiohttp and asyncio.
 Aioinflux is an alternative to the official InfluxDB Python client.
 .
 Aioinflux supports interacting with InfluxDB in a non-blocking way by using 
aiohttp.
 It also supports writing and querying of Pandas dataframes,
 among other handy functionality.

I will maintain this under the DPMT.

Re: Request Access to Salsa

[Arto Jantunen]

Per Andersson  writes:
>> This is maintained in the OpenStack team because upstream is OpenStack
>> since Jan Dittberner stopped working on it, and because it's used mainly
>> in OpenStack. However, I would recommend against using it, as upstream
>> is trying to get rid of it in the favor or Alembic. It's just there for
>> historic reasons.
>
> I understand, new versions of pytrainer depend on sqlalchemy-migrate so
> I'll deal with it.

I'll just randomly note that this pytrainer dependency isn't new, it has
been there since version 1.9.0 in 2011.

What is new is that pytrainer also directly uses sqlalchemy, instead of
just the transitive dependency of pytrainer -> migrate -> sqlalchemy.

-- 
Arto Jantunen

Re: Matplotlib 3.0 - update ok?

[Arto Jantunen]

ghisv...@gmail.com writes:

> On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
>> ghisv...@gmail.com writes:
>> > Don't get me wrong, I am all in favour for a modern stack,
>> > including
>> > Python 3.
>> > 
>> > However, upgrading NumPy et al. to their Python 3 only versions,
>> > introducing new legacy packages for Python 2, and patching the
>> > large
>> > collection of packages relying on the Python 2 versions of these
>> > sounds
>> > like a lot of work for the time we have got left in the Buster
>> > release
>> > cycle.
>> 
>> In my understanding there is no need to patch any of the reverse
>> dependencies. Currently there are binary packages called python-numpy
>> and python3-numpy, built from a source package called python-numpy.
>> In
>> my understanding the proposed change is to keep having the exact same
>> binary packages, just built from two different source packages
>> (python-numpy and python-numpy-legacy or whatever).
>
> Oh, I see what you mean.
>
> So you'd have:
>
> - src:python-numpy-legacy providing python-numpy (<2.0) only
> - src:python-numpy providing python3-numpy (>=2.0) only
>
> Assuming version 2 is when the split happens.
>
> Am I correct?

Yeah, this would be my understanding of the plan. Things could get more
complex if the same split needs to happen at many levels of the stack (a
library that uses numpy is only compatible with numpy <2.0, followed by
another one on the next level down).

-- 
Arto Jantunen

Re: Matplotlib 3.0 - update ok?

[Arto Jantunen]

ghisv...@gmail.com writes:
> Don't get me wrong, I am all in favour for a modern stack, including
> Python 3.
>
> However, upgrading NumPy et al. to their Python 3 only versions,
> introducing new legacy packages for Python 2, and patching the large
> collection of packages relying on the Python 2 versions of these sounds
> like a lot of work for the time we have got left in the Buster release
> cycle.

In my understanding there is no need to patch any of the reverse
dependencies. Currently there are binary packages called python-numpy
and python3-numpy, built from a source package called python-numpy. In
my understanding the proposed change is to keep having the exact same
binary packages, just built from two different source packages
(python-numpy and python-numpy-legacy or whatever).

-- 
Arto Jantunen

Salsa membership, DPMT and PAPT

[Arto Jantunen]

Hi,

I'd like to join both the applications and modules teams, and have a
couple of existing packages I'd like to switch over to group
maintenance.

I have read and accept the team policy.

-- 
Arto Jantunen


signature.asc
Description: PGP signature

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Arto Jantunen]

Barry Warsaw <ba...@debian.org> writes:
> On Feb 14, 2017, at 06:30 PM, Arto Jantunen wrote:
>>The patch-queue branch is based on the Debian branch, not upstream. Try
>>merging the new upstream version to your Debian branch, and then running
>>gbp pq rebase.
>
> This confuses me, or I'm doing something wrong.  With git-dpm the way to drop
> patches was to rebase interactively against upstream.  That doesn't seem to
> work with gbp pq rebase, or with gbp pq import & git rebase -i master (or
> upstream).
>
> So how do I drop a patch with gbp-pq?

The later works for me. Since there is no gbp pq rebase -i (perhaps
there should be one?), this is what I do:

gbp pq import
git rebase -i master

gbp pq export

And git status shows the patch as deleted, and removed from the series
file.

-- 
Arto Jantunen

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Arto Jantunen]

Barry Warsaw <ba...@debian.org> writes:
> On Feb 14, 2017, at 05:54 PM, Brian May wrote:
>>Maybe something like the following?
>>
>>git read-tree --reset -u upstream
>>git reset -- debian
>>git checkout debian
>>git rm debian/.git-dpm
>>git commit
>
> This gets closer, but there still seems to be problems.
>
> gbp pq import
> gbp pq export --drop
>
> That seems to round trip okay, and it just removes a few crufty lines from the
> patches.  The problem comes when you try to rebase your patches on top of
> upstream.
>
> gbp pq import
> git rebase -i upstream
> (way way more commits to pick from than expected)

The patch-queue branch is based on the Debian branch, not upstream. Try
merging the new upstream version to your Debian branch, and then running
gbp pq rebase.

-- 
Arto Jantunen

Re: git-dpm breakage src:faker

[Arto Jantunen]

Scott Kitterman <deb...@kitterman.com> writes:

> On Sunday, January 29, 2017 09:39:10 AM Brian May wrote:
>> Scott Kitterman <deb...@kitterman.com> writes:
>> > On Sunday, January 29, 2017 08:54:57 AM Brian May wrote:
>> >> Can we switch away from git-dpm yet? Sure this is most likely user
>> >> error, however I want to try to solve an RC bug, not fix broken git-dpm
>> >> first.
>> > 
>> > Much like the switch from svn to git, I think we need an agreed new
>> > workflow and tools and a migration plan.
>> > 
>> > What do you propose?
>> 
>> I would think "gbp pq" is the most popular.
>> 
>> I think something like:
>> 
>> * Don't touch existing packages just for the sake of doing so.
>> * Next time you do need to update a package with a debian/.git-dpm:
>>   1. Delete debian/.git-dpm.
>>   2. Unapply all patches and commit (not sure what the easiest way is)
>>   3. Update debian/source/options with "unapply-patches" (anything else?).
>> * If you encounter a package without debian/.git-dpm, don't re-add it.
>> * Don't push the gbp pq patches queue branch.
>
> I've never used it.
>
> Does that then result in one big undifferentiated mass of diff in the source 
> package?

No, it results in separate patches with their headers intact in the
source package. I assume git-dpm (which I've never used) produces the
same end result.

The git repository is of course different, with gbp pq carrying the
patches as patches in the packaging branch, and git-dpm having separate
magical patch branches.

-- 
Arto Jantunen

Bug#806450: RFP: python-inflect -- Python library for correctly generating plurals, singular nouns, ordinals, indefinite articles; convert numbers to words

[Arto Jantunen]

Package: wnpp
Severity: wishlist

* Package name: python-inflect
  Version : 0.2.5
  Upstream Author : Paul Dyson 
* URL : http://pypi.python.org/pypi/inflect
* License : AGPLv3
  Programming Lang: Python
  Description : Python library for correctly generating plurals, singular
  nouns, ordinals, indefinite articles; convert numbers to words

This is a dependency of sqlacodegen.

Re: dh_python2 missing

[Arto Jantunen]

Brian May br...@microcomaustralia.com.au writes:

 Just noticed when building my package that I got this warning:

 dpkg-gencontrol: warning: Depends field of package python-karaage: unknown
 substitution variable ${python:Depends}

 Trying to chase this down, I noticed that I didn't have dh_python2
 installed:

 $ /usr/bin/dh_python2
 zsh: no such file or directory: /usr/bin/dh_python2

 However:

 $ dpkg -S /usr/bin/dh_python2
 python: /usr/bin/dh_python2

 Am guessing that something might have broken when I upgraded wheezy to
 Jessie, I will check if my other systems have the same problem.

 I reinstalled the python package, and as expected in came good.

 Not entirely sure this is a bug that needs to be reported, however letting
 other people know just in case this isn't something unique to be setup on
 this particular computer.

I've seen that as well. I assumed that it was caused by going from
wheezy + backports to jessie, the upgrade of dh-python there was broken
for some time.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mqzwo87@kirika.int.wmdata.fi

Re: Package upgrade needs deletion of config file in ~/

[Arto Jantunen]

Andreas Noteng andr...@noteng.no writes:

 Hello. What is the preffered way of handling situations where a configuration
 file in ~/ needs to be deleted upon package upgrade?

There is nothing the package can do, touching files under the users home
directory is not allowed by policy (and for a very good reason).

If it really is impossible for the program to update it's configuration,
it should probably on startup show the user an error message containing
instructions on what to do.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ucly3u7@kirika.int.wmdata.fi

Re: dh_python2 transition

[Arto Jantunen]

Barry Warsaw ba...@python.org writes:

 On May 02, 2011, at 03:17 PM, Jakub Wilk wrote:

* Bernd Zeimetz be...@bzed.de, 2011-05-02, 14:58:
I would prefer if we could make the transition a release goal.
Would you be up for writing it up and proposing it as such? I support 
the idea.
Uhum, yes, we need more people laughing at us.

How about concentrating on fixing things that *are* broken?

The existance of now 3 helper tools is one of the biggest and long
standing issues we have. It is about time to fix it, and now is a good
time to start it. At least we can try to get it done.

Yes, we had 3 until someone decided to write a 4th one. Progress!

 * python-support
 * python-central
 * dh_python2

 What's the fourth one?

The original dh_python, I'd presume.

How about concentrating on getting rid of dh_python and python-central
for wheezy? My understanding is that consensus about those two being
deprecated and needing to be removed should be achievable without too
much flaming.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wri9xisg@viiru.iki.fi

Re: Switching to git

[Arto Jantunen]

Barry Warsaw ba...@python.org writes:

 On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote:

Do the 2 VCDs you mentioned have clear advantage that make then
preferible to git except being Python-based? If so, I think it's a
quite weak reason.

 Let me turn that around: why would you *not* want to use a Python based dVCS?
 wink

I used to choose tools based on the language they are implemented in, I
justified it with the old it needs to be in a language I know/like in
case I need to modify it or fix bugs in it excuse. Since then I learned
my lesson and, unless I'm specifically planning to modify a certain
component, the language it is implemented in does not matter (except for
cases where I have a fanatical aversion to the language, but I really
can't recommend adopting this mental ilness as a policy).

In the specific case of a project implementing a programming language I
can understand the PR advantages of being able to claim to be self
hosting by using a VCS implemented in that language. As I understand
it, this was a major concern for upstream Python, but I don't think that
point concerns the Debian python team.

 One reason could be that git is the de-facto standard for Debian.  I guess
 choice of dVCS is the editor-wars of the 2010s, and probably just as silly.

The difference of course being that the editor a person uses does not
concern anyone else in any way (text written in emacs works just fine in
vim), but the VCS a person/team uses concerns a lot of people in a lot
of ways. Most VCS client tools can't deal with the repo formats used by
the other tools (and even in those cases where they can there are always
limitations). Nobody wants to waste time learning the quirks of every
possible VCS client.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3m45baf@viiru.iki.fi