Re: Requests to join DPT haven't been processed for months

[Sergio Durigan Junior]

On Wednesday, April 03 2024, Stefano Rivera wrote:

> Hi Christian (2024.04.01_15:45:20_+)
>> one of the GSoC candidates I'm mentoring hasn't had his request to join
>> the team processed for a month. I then checked and unless I'm mistaken,
>> *no*( requests filed in 2024 have been processed. At least, all threads
>> I could find are as of yet unanswered.
>
> We've added a new owner to help out. Thanks peb!

Thanks.

Can I ask why do we have such high barrier of entry for new team
members?  And while at that, I've offered help to approve new member
requests before and the offer was turned down.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#1025456: RM: flask-oidc -- RoM; inactive upstream; never migrated to testing

[Sergio Durigan Junior]

Package: ftp.debian.org
Severity: normal

Hello,

I would like to request the removal of flask-oidc from unstable.  The
package is currently FTBFSing, and while it would be possible to patch
it and make it build successfully again, I don't think it's worth the
trouble: the package has never migrated to testing, and upstream has
been inactive for 2 years now (the latest upstream release happened more
than 5 years ago).

This package is maintained with the Debian Python team, but I was the
one who added it to Debian and there has been no other person interested
in it ever since.

--8<---cut here---start->8---
$ apt rdepends python3-flask-oidc
python3-flask-oidc
Reverse Depends:
--8<---cut here---end--->8---

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Re: Request to join python team

[Sergio Durigan Junior]

On Tuesday, May 11 2021, Sérgio Cipriano wrote:

> Hi,
>
> 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.

Guys, Sérgio here has been trying to join the team for *months* now.  He
already packaged a few Python modules and is helping maintaining others.
Can we add him to the team, please?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Bug#982176: ITP: flask-oidc -- OpenID Connect support for Flask

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: flask-oidc
  Version : 1.4.0
  Upstream Author : Patrick Uiterwijk 
* URL : https://github.com/puiterwijk/flask-oidc
* License : BSD-2-clause
  Programming Lang: Python
  Description : OpenID Connect support for Flask

 This library should work with any standards compliant OpenID Connect
 provider.  It has been tested with:
 .
  * Google+ login
  * Ipsilon

This package is a dependency for Pagure. .I will maintain it with the
Python Team.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#976629: ITP: python-build -- Simple, correct PEP517 package builder

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-build
  Version : 0.1.0
  Upstream Author : Filipe Laíns 
* URL : https://github.com/pypa/build
* License : Expat
  Programming Lang: Python
  Description : Simple, correct PEP517 package builder

 python-build will invoke the PEP 517 hooks to build a distribution
 package. It is a simple build tool and does not perform any
 dependency management.

I will maintain this package with the Python Team.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#894786: RFP: python-pytest-flake8 -- pytest plugin to check FLAKE8 requirements

[Sergio Durigan Junior]

Control: retitle -1 ITP: python-pytest-flake8 -- pytest plugin to check FLAKE8 
requirements
Control: owner -1 !
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

On Wednesday, April 04 2018, Julien Puydt wrote:

> * Package name: python-pytest-flake8
>   Version : 1.0.0
>   Upstream Author : Thorsten Lockert
> * URL : https://github.com/tholo/pytest-flake8
> * License : BSD
>   Programming Lang: Python
>   Description : pytest plugin to check FLAKE8 requirements
>
> This pytest plugin makes it possible to check source code for Flake8
> style guide enforcement.
>
> The newest path.py versions use that to check the sources ; I have a
> patch to disable that for now.

I will package this.  The current version is 1.0.6.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

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

[Sergio Durigan Junior]

On Monday, August 31 2020, Otto Kekäläinen wrote:

> Hello!

Hey,

> I've been using the address python-apps-t...@lists.alioth.debian.net
> as the maintainer address in my packages, but the address no longer
> works. I tried looking at what other packages have, but there are no
> working examples
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967997).
>
> So dear list members, what is the correct address to use now as
> python-apps-t...@lists.alioth.debian.net no longer works for the
> Maintainer field in d/control files?

I've been using python-apps-t...@lists.alioth.debian.org, which
translates to python-apps-t...@alioth-lists.debian.net.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#962418: ITP: python-email-validator -- Robust email address syntax and deliverability validation library

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-email-validator
  Version : 1.1.1
  Upstream Author : Joshua Tauberer 
* URL : https://github.com/JoshData/python-email-validator
* License : Public Domain
  Programming Lang: Python
  Description : Robust email address syntax and deliverability validation 
library

 This library validates that a string is of the form x...@y.com. This is
 the sort of validation you would want for an email-based login form
 on a website.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Re: Python3.8 as default final status

[Sergio Durigan Junior]

On Saturday, March 28 2020, Scott Kitterman wrote:

> On March 28, 2020 5:10:42 AM UTC, Sergio Durigan Junior  
> wrote:
>>On Friday, March 27 2020, Håvard Flaget Aasen wrote:
>>
>>> On 27.03.2020 20:09, Sergio Durigan Junior wrote:
>>>> On Friday, March 27 2020, Scott Kitterman wrote:
>>>> 
>>>>> The python3-defaults with python3.8 as the default python3 has
>>migrated to 
>>>>> Testing thanks to the release team hammering things around until it
>>went.
>>>> 
>>>> Thanks for this.
>>>> 
>>>>> Most of the outstanding autipkgtest failures with python3.8 were
>>fixed either 
>>>>> in unstable or in git/BTS.  Here are the remaining issues that
>>someone (who 
>>>>> isn't me) should have a look at:
>>>>>
>>>>> celery/4.2.1-5: #952217 autorm 4/13
>>>> 
>>>> FWIW, I looked at this a little bit, but could not make much
>>progress.
>>>> I'm very interested in fixing this since it impacts pagure.  I'll
>>try to
>>>> investigate more this weekend, but if someone else wants to take a
>>look
>>>> (and let me know), you're more than welcome!
>>>> 
>>>
>>> I believe I already fixed that package, it's waiting for someone to
>>> review and upload it. Did you look at the repository in salsa?
>>
>>I had looked at the repository when I was working with the package.
>>I see you pushed your changes 2 days ago, but the last time I looked at
>>the package was at least 7 days ago.
>>
>>Anyhow, I thank you for letting me know, but I am not sure I am
>>satisfied with the solution.  You basically disabled the test on Python
>>3.8, which obviously works, but doesn't really tell me whether there
>>was
>>indeed a problem with the package/testcase or not.
>
> I completely agree.  It's just papering over the problem.  It's not in the 
> spirit of the Debian Social Contract (#3).
>
>>My approach (failed, so far) was to try and figure out what was
>>happening, and then devise a proper fix for it.  My next step was going
>>to be to involve upstream in this.
>>
>>Would you like to follow up with them and check if they're are aware of
>>the failure?  Maybe they already have a proper solution for it.
>
> Upstream should definitely be involved.

... and the package was uploaded anyway :-/.  I'm Cc'ing Jonathan in
case he hasn't seen these messages.

Anyway, I still think it's necessary to follow up on this and involve
upstream; simply disabling the test that is failing is not the Debian
way.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: Python3.8 as default final status

[Sergio Durigan Junior]

On Friday, March 27 2020, Håvard Flaget Aasen wrote:

> On 27.03.2020 20:09, Sergio Durigan Junior wrote:
>> On Friday, March 27 2020, Scott Kitterman wrote:
>> 
>>> The python3-defaults with python3.8 as the default python3 has migrated to 
>>> Testing thanks to the release team hammering things around until it went.
>> 
>> Thanks for this.
>> 
>>> Most of the outstanding autipkgtest failures with python3.8 were fixed 
>>> either 
>>> in unstable or in git/BTS.  Here are the remaining issues that someone (who 
>>> isn't me) should have a look at:
>>>
>>> celery/4.2.1-5: #952217 autorm 4/13
>> 
>> FWIW, I looked at this a little bit, but could not make much progress.
>> I'm very interested in fixing this since it impacts pagure.  I'll try to
>> investigate more this weekend, but if someone else wants to take a look
>> (and let me know), you're more than welcome!
>> 
>
> I believe I already fixed that package, it's waiting for someone to
> review and upload it. Did you look at the repository in salsa?

I had looked at the repository when I was working with the package.
I see you pushed your changes 2 days ago, but the last time I looked at
the package was at least 7 days ago.

Anyhow, I thank you for letting me know, but I am not sure I am
satisfied with the solution.  You basically disabled the test on Python
3.8, which obviously works, but doesn't really tell me whether there was
indeed a problem with the package/testcase or not.

My approach (failed, so far) was to try and figure out what was
happening, and then devise a proper fix for it.  My next step was going
to be to involve upstream in this.

Would you like to follow up with them and check if they're are aware of
the failure?  Maybe they already have a proper solution for it.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Python3.8 as default final status

[Sergio Durigan Junior]

On Friday, March 27 2020, Scott Kitterman wrote:

> The python3-defaults with python3.8 as the default python3 has migrated to 
> Testing thanks to the release team hammering things around until it went.

Thanks for this.

> Most of the outstanding autipkgtest failures with python3.8 were fixed either 
> in unstable or in git/BTS.  Here are the remaining issues that someone (who 
> isn't me) should have a look at:
>
> celery/4.2.1-5: #952217 autorm 4/13

FWIW, I looked at this a little bit, but could not make much progress.
I'm very interested in fixing this since it impacts pagure.  I'll try to
investigate more this weekend, but if someone else wants to take a look
(and let me know), you're more than welcome!

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: cannot allocate memory in static TLS block

[Sergio Durigan Junior]

On Saturday, March 14 2020, Andreas Tille wrote:

> On Fri, Mar 13, 2020 at 11:09:31PM +0100, Paul Gevers wrote:
>> 
>> raise RuntimeError(('Could not find drmaa library.  Please specify
>> its ' +
>> RuntimeError: Could not find drmaa library.  Please specify its full
>> path using the environment variable DRMAA_LIBRARY_PATH
>
> I've fixed this in Git.  Unfortunately I get a new issue when importing
> drmaa
>
> $ python3
> Python 3.7.6 (default, Jan 19 2020, 22:34:52) 
> [GCC 9.2.1 20200117] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 import drmaa
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py",
>  line 65, in 
> from .session import JobInfo, JobTemplate, Session
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py", 
> line 39, in 
> from drmaa.helpers import (adapt_rusage, Attribute, 
> attribute_names_iterator,
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py", 
> line 36, in 
> from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
>   File 
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py",
>  line 58, in 
> _lib = CDLL(libpath, mode=RTLD_GLOBAL)
>   File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory 
> in static TLS block
>
>
> Any help would be welcome

This is an issue with jemalloc's handling of the TLS model when being
dlopened..  See:

  https://github.com/jemalloc/jemalloc/issues/1237

The recommended way to build a libjemalloc that is suitable for being
dlopened is to use '--disable-initial-exec-tls' when building it.  Take
a look at the INSTALL.md file, and look for this option:

  https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md

There is a way to workaround this bug by doing an LD_PRELOAD of
libjemalloc when invoking python, but this will only mask the problem
and we can't expect users to do/know this.

The way I see it, you can try to convince jemalloc's maintainer to
enable that flag.

BTW, the reason 'find_library' can't find drmaa's library is because the
.so is being installed in a non-standard directory.  I don't know why
the package was made like this, though.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Bug#937177: obitools: Python2 removal in sid/bullseye

[Sergio Durigan Junior]

On Sunday, January 12 2020, Andreas Tille wrote:

> On Sun, Jan 12, 2020 at 07:27:59AM -0500, Scott Kitterman wrote:
>> On Fri, 30 Aug 2019 07:28:59 + Matthias Klose  wrote:
>> This 
>> package is blocking several others.  Would it be best to remove it?  It can 
>> always be re-introduced if a python3 port appears.
>
> Since some time I've pushed a 2to3 based port to Git.  I've now fixed
> some issues of this and I wonder whether we might give it a try to do
> the port inside Debian.  For the moment I'm running into the following
> issue:
>
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd 
> /build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build; python3.7 
> -m unittest discover -v 
> obitools (unittest.loader._FailedTest) ... ERROR
>
> ==
> ERROR: obitools (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: obitools
> Traceback (most recent call last):
>   File "/usr/lib/python3.7/unittest/loader.py", line 470, in _find_test_path
> package = self._get_module_from_name(name)
>   File "/usr/lib/python3.7/unittest/loader.py", line 377, in 
> _get_module_from_name
> __import__(name)
>   File 
> "/build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build/obitools/__init__.py",
>  line 23, in 
> from _obitools import BioSequence,NucSequence,AASequence, \
> ModuleNotFoundError: No module named '_obitools'
>
>
> --
> Ran 1 test in 0.000s

Hey Andreas,

I cannot reproduce this bug when building inside a clean schroot
(unstable).  I don't know if the reason is because I don't have
python3.7 installed in the schroot anymore (it was removed recently, and
python3.8 is the default), or because there's something else different.

> FAILED (errors=1)
> E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd 
> /build/obitools-1.2.13+dfsg/.pybuild/cpython3_3.7_obitools/build; python3.7 
> -m unittest discover -v 
> dh_auto_test: pybuild --test -i python{version} -p 3.7 returned exit code 13
> make: *** [debian/rules:15: build] Error 255
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> I: copying local configuration
> E: Failed autobuilding of package
> I: user script 
> /var/cache/pbuilder/build/cow.1543005/tmp/hooks/C99_failed_build starting
> Installing convenience apps: mc less bash-completion 
> root@energija:/# cd build/obitools-1.2.13+dfsg/
> root@energija:/build/obitools-1.2.13+dfsg# find . -name "*.so"
> ./.pybuild/cpython3_3.7_obitools/build/obitools/options/_options.cpython-37m-x86_64-linux-gnu.so
>   
>=
> ./.pybuild/cpython3_3.7_obitools/build/obitools/options/_bioseqfilter.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/profile/_profile.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/utils/_utils.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/_obitools.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/tools/_solexapairend.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/fasta/_fasta.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_upperbond.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_rassemble.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_freeendgapfm.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_nwsdnabyprot.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_assemble.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_freeendgap.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_qsrassemble.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_gprofilenws.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_dynamic.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_nws.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_lcs.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_qsassemble.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_profilenws.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/align/_codonnws.cpython-37m-x86_64-linux-gnu.so
> ./.pybuild/cpython3_3.7_obitools/build/obitools/format/_format.cpython-37m-x86_64-linux-gnu.so
> 

Re: Sponsorship backlog

[Sergio Durigan Junior]

On Monday, February 10 2020, Jonathan Carter wrote:

> Hey Pythonistas

Hey Jonathan,

> The sponsorship request queue in the IRC topic is getting a bit long
> again, I'll try to make time for as many of these as possible this week,
> but if anyone can help reviewing these packages from the IRC topic (and
> then removing them) then that would be great:
>
> python-babel, gpxpy, pyparsing, python-progress, python-urllib3,
> geoalchemy2, python-marshmallow-polyfield, python-mongoengine,
> python-nest-asyncio, djangorestframework-api-key, aionotify,
> python-fastjsonschema, python-cassandra-driver

I was reviewing some of the packages yesterday night, but had to stop.

FYI, python-fastjsonschema and python-cassandra-driver need some TLC
before approval, IMO.  I tried pinging the person but he hasn't replied.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: PAPT: join request

[Sergio Durigan Junior]

On Wednesday, January 22 2020, Joel Cross wrote:

> Dear PAPT,
> 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 there,

That is correct.  I'd like to see Joel in the PAPT team so we can
proceed with the packaging.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Advices on how to use salsa

[Sergio Durigan Junior]

On Monday, October 22 2018, Jerome Kieffer wrote:

> On Sat, 20 Oct 2018 17:21:13 -0400
> Sergio Durigan Junior  wrote:
>> If I may: please consider not using github.  It uses proprietary
>> software for its backend infrastructure, and serves proprietary
>> JavaScript to its users, as well as promote centralization of a
>> distributed protocol.
>
> About 10 years ago, I heard "gitub made git useable for human being".
> At that time mercurial, bazar and git were equally used and it was a
> mess to chose one of them and then select a workflow to work with.
> The work github did (their tutorials !) deserve recognition to simplify
> all this. 
>
> Please remind gitlab (which salsa is just an implementation) was
> originally just a re-implementation github hosted initially on github !
>
>
> Maybe this company is private and has been acquired by
> another you don't like.

Maybe you didn't understand my point at all.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Advices on how to use salsa

[Sergio Durigan Junior]

On Friday, October 19 2018, Jerome Kieffer wrote:

> On Fri, 19 Oct 2018 15:48:13 -0400
> Sergio Durigan Junior  wrote:
>
>> Is it?  I always thought it was OK to host Free Software projects there.
>
> No matter, I have github, gitlab for my code ... I intend to use salsa
> for packaging purposes.

If I may: please consider not using github.  It uses proprietary
software for its backend infrastructure, and serves proprietary
JavaScript to its users, as well as promote centralization of a
distributed protocol.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Advices on how to use salsa

[Sergio Durigan Junior]

On Friday, October 19 2018, Andrey Rahmatullin wrote:

> On Fri, Oct 19, 2018 at 09:13:30PM +0200, Jerome Kieffer wrote:
>> I am a python developer and from time-to-time I also build some
>> packages. I recently re-built python-rfoo for the latest version and I
>> was suggest to make the packaging on salsa. Does the Debian-Python
>> community have recommendation for building packages when using git and
>> the gitlab-forge on salsa ?
> Salsa is only for official Debian packages. Are you going to update
> python-rfoo in Debian?

Is it?  I always thought it was OK to host Free Software projects there.
Ref.: .

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: [Debian PAPT] Question about salsa repo and packaging

[Sergio Durigan Junior]

On Sunday, September 16 2018, Elena wrote:

> On 2018-09-16 at 01:32:05 -0400, Sergio Durigan Junior wrote:
>> > 1. I'd like to revert some changes to the salsa repo for my package, as
>> > these changes were never uploaded to Debian and are not superseded by
>> > new upstream package. Is it OK to do a "git reset --hard " to make
>> > them disappear in my repository?
>> 
>> You mean do a "git reset --hard" locally and then "git push" the
>> modified history?  This is not ideal, but if you're the only one using
>> the repository, and if there was no Debian release containing the code
>> you're reverting, then I'd say it's OK.
>
> can one be sure that nobody else is using the repository? maybe nobody
> in debian, but what about our derivatives? or even our users
>
> if there is a strong need to remove those changes (e.g. for copyright
> reasons) I agree that a reset --hard is a reasonable option, but if it's
> just to keep the repo clean my personal preference would be for a ``git
> revert`` that doesn't break the repo for other users.

I understand and agree with your comment, but it seems like his commits
are pretty recent.  As I said, overwitting history is never ideal, but
under specific circumstances I think it's "ok-ish".

But sure, if you're comfortable with using "git revert", then by all
means, go ahead.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: [Debian PAPT] Question about salsa repo and packaging

[Sergio Durigan Junior]

On Saturday, September 15 2018, Hilmar Preuße wrote:

> Hi,

Hey,

> I'm maintaining the package rubber in the PAPT. I have a few question:
>
> 1. I'd like to revert some changes to the salsa repo for my package, as
> these changes were never uploaded to Debian and are not superseded by
> new upstream package. Is it OK to do a "git reset --hard " to make
> them disappear in my repository?

You mean do a "git reset --hard" locally and then "git push" the
modified history?  This is not ideal, but if you're the only one using
the repository, and if there was no Debian release containing the code
you're reverting, then I'd say it's OK.

> 2. My repo contains a stale branch called "svn". It was created during
> the git -> salsa migration. AFAICT this branch contains obsolete
> versions of some files. May I kill that branch?

Sorry, I don't the answer to this one.

> 3. Recently I imported a new upstream version. According to [1] I should
> rebase my patches. Unfortunately this fails:
>
> 
> hille@sid:~/devel/rubber/rubber.git $ gbp pq rebase
> gbp:info: Switching to 'patch-queue/debian/master'
> First, rewinding head to replay your work on top of it...
> Applying: more accurate log messages when deciding whether to rebuild
> some file
> Using index info to reconstruct a base tree...
> M src/depend.py
> Falling back to patching base and 3-way merge...
> Auto-merging src/depend.py
> CONFLICT (content): Merge conflict in src/depend.py
> error: Failed to merge in the changes.
> Patch failed at 0001 more accurate log messages when deciding whether to
> rebuild some file
> hint: Use 'git am --show-current-patch' to see the failed patch
>
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm ", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase
> --abort".
>
> gbp:error: Couldn't run git rebase: it exited with 128
> 
>
> Could anybody give me a hint, what it wrong here?

While rebasing the patch-queue, there was a conflict with one of the
files.  A conflict happens when you have two distinct versions of the
same file containing modifications that are not trivial to be
automatically merged by git.  The conflict is marked above as:

  CONFLICT (content): Merge conflict in src/depend.py

You now have to resolve this conflict before proceeding.  Basically,
open the file and look for the conflict markers, which look like:

  <<< HEAD
  some content
  ===
  some other content
  >>> some-branch

You will then have to decide how to resolve this, either by deleting one
of the changes, or by adapting them, etc.  Once you resolve all of the
conflicts, you will be able to perform a "git rebase --continue".  Note
that you may encounter many conflicts while rebasing.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


smime.p7s
Description: S/MIME cryptographic signature

Please add me to PAPT

[Sergio Durigan Junior]

Raphael's e-mail reminded me that I'd like to be added to PAPT as well,
for the same reasons: I've wanted to upload packages belonging to the
team, but postponed that because I'm not part of it.  I've read the
policy and accept it.

My salsa username is "sergiodj".

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: RFS: pcapy/0.11.3-1 [ITA]

[Sergio Durigan Junior]

On Wednesday, August 29 2018, eamanu wrote:

> Hello Sergio,
>
> I made the changes!

Thanks.  Did you build the package and run lintian against it, using
"-EI --pedantic" (you can use "-i" if you want more information about
each warning/info tag)?  I can't reply in more detail right now, but you
must fix the lintian warnings.

I'll try to do an in-depth review tomorrow/Friday.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: RFS: pcapy/0.11.3-1 [ITA]

[Sergio Durigan Junior]

Hi Emmanuel,

Sorry, you still have to fix a few things before the package is ready
for upload.  We're almost there; don't give up!

On Tuesday, August 21 2018, eamanu wrote:

> No problem.  However, the "License:" still doesn't reflect the license
>> of the software.  According to LICENSE:
>>
>>   We provide this software under a slightly modified version of the
>>   Apache Software License. The only changes to the document were the
>>   replacement of "Apache" with "Pcapy" and "Apache Software Foundation"
>>   with "CORE Security Technologies". Feel free to compare the resulting
>>   document to the official Apache license.
>>
>>   The `Apache Software License' is an Open Source Initiative Approved
>>   License.
>>
>> Therefore, I think a better value for the field would be:
>>
>>   License: Apache with Pcapy modifications
>>
>
> Ready!

Thanks.  The "License:" must be the same in both places, though.  Here:

  Files: *
  Copyright (C) 2014 CORE Security Technologies . 
  License: Apache Software License with Pcapy modifications

and here:

  License: Apache with Pcapy modifications
   We provide this software under a slightly modified version of the
   ...

It's OK to use "Apache with Pcapy modifications" in both places.

>> I see that the contributions under the debian/ directory are released
>> under GPL-3+.  That's absolutely fine (I am a GPL advocate as well).
>> However, I must warn you that the Debian patches will also be released
>> under this license, which may be problematic if/when you decide to
>> upstream them.  But I understand this is the current situation anyway.
>> You may want to try to contact Arnaud Fontaine and ask him if he's OK
>> with changing the license to Apache in the future.
>>
>
> Ok. I will contact Arnaud Fontaine to ask about it. I think it's ok for
> now. In the next release of package I can update this field.

Great.  It's OK for now, indeed.

> Thanks, but what you did is incomplete.  In order to create a new
>> package, you have to create an entry for it on d/control.  What you did
>> (add ${python3:Depends} to python-pcapy's Depends) is wrong because
>> you're basically pulling Python 3 dependencies for a Python 2 package.
>> Please have a look at other packages under them DPMT and check their
>> d/control; you will find many examples of how to create Python 3
>> packages.
>>
>
> Ready!

Thanks, that's better, but there are still a few things that need
fixing.

1) It's a good practice to explicitly say if the package is a Python 2
or Python 3 module.  We do that by suffixing the short description with
"(Python X)" (where X is 2 or 2), and by appending "This package
installs the library for Python X." to the long description.  Like this:

  Package: python-pcapy
  Architecture: any
  Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
  Recommends: python-impacket
  Description: Python interface to the libpcap packet capture library (Python 2)
   Pcapy is a  Python extension module that interfaces  with the libpcap
   packet capture library.
   .
   Pcapy enables Python scripts to capture packets on the network. Pcapy
   is highly  effective when used in conjunction  with a packet-handling
   package such as Impacket, which is a collection of Python classes for
   constructing and dissecting network packets.
   .
   This package installs the library for Python 2.

2) You don't need to specify "Provides:".  Please remove them from both
packages.


As a last note, it seems that you forgot to push the "upstream" and
"pristine-tar" branches, so I can't really build the package locally
here.  Please do that.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: RFS: pcapy/0.11.3-1 [ITA]

[Sergio Durigan Junior]

On Saturday, August 11 2018, eamanu wrote:

> Hello Sergio!
>
> Thanks for your comments!

No problem, and sorry for the delay.

> 1) On d/copyright, the license specified for the project is wrong.
>> According to the LICENSE file, the project is released under a slightly
>> modified version of the Apache license.  This is something really
>> important to get right, otherwise the ftp-masters will certainly reject
>> the package.  You listed the license as being "GPL-2", but the text is
>> clearly not GPL-2.
>>
>> Ohh!!! Sorry I saw the old d/copyright file to do this.

No problem.  However, the "License:" still doesn't reflect the license
of the software.  According to LICENSE:

  We provide this software under a slightly modified version of the
  Apache Software License. The only changes to the document were the
  replacement of "Apache" with "Pcapy" and "Apache Software Foundation"
  with "CORE Security Technologies". Feel free to compare the resulting
  document to the official Apache license.

  The `Apache Software License' is an Open Source Initiative Approved
  License.

Therefore, I think a better value for the field would be:

  License: Apache with Pcapy modifications

Also, please remove the "All rights reserved." text here:

  Copyright (C) 2003-2011 CORE Security Technologies . 
   All rights reserved.

Oh, and please fix the years.  Nowhere in the code I see "2003-2011".
Doing a basic grep, I see that the year should be 2014.

> 2) Still on d/copyright: as said above, the GPL-2 license is wrong.
>> However, I think it's also important to mention that the license text is
>> formatted in a strange/wrong manner.  You have text like this:
>>
>>  [...]
>>  Redistribution and use in source  and binary forms, with or without
>>modification, are permitted  provided that the following conditions
>>are met:
>>
>>1. Redistributions  of  source   code  must  retain  the  above
>>  [...]
>>
>> The correct format for d/copyright is to indent the text using 1 space,
>> and to use . (dot) for blank lines.  Like this:
>>
>>  [...]
>>  Redistribution and use in source  and binary forms, with or without
>>  modification, are permitted  provided that the following conditions
>>  are met:
>>  .
>>  1. Redistributions  of  source   code  must  retain  the  above
>>  [...]
>>
>
>
> Ready!

Thanks.

I see that the contributions under the debian/ directory are released
under GPL-3+.  That's absolutely fine (I am a GPL advocate as well).
However, I must warn you that the Debian patches will also be released
under this license, which may be problematic if/when you decide to
upstream them.  But I understand this is the current situation anyway.
You may want to try to contact Arnaud Fontaine and ask him if he's OK
with changing the license to Apache in the future.

>>
>> 3) The package uses a *really* old version of debhelper (version 5!).
>> We're at version 11 already, so you should update both d/compat and
>> d/control (i.e., depend on debhelp >= 11) to reflect that.
>>
>
> Ready!

Thanks.

>>
>> 4) You haven't addressed my comment about building a Python 3 package.
>> IMO you should really do that; lintian will warn you if you don't.
>>
>
> Yes, I forgot do that! Sorry!

Thanks, but what you did is incomplete.  In order to create a new
package, you have to create an entry for it on d/control.  What you did
(add ${python3:Depends} to python-pcapy's Depends) is wrong because
you're basically pulling Python 3 dependencies for a Python 2 package.
Please have a look at other packages under them DPMT and check their
d/control; you will find many examples of how to create Python 3
packages.

>>
>> 5) You haven't answered my question about why the package has "Suggests:
>> doc-base".  It seems to be a relic from this very old debhelper; I think
>> you can safely remove it.
>>
>
> Yes, I remove it. Since I do not have much knowledge about doc-base and why
> it is there, I left it. But now is removed.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: RFS: pcapy/0.11.3-1 [ITA]

[Sergio Durigan Junior]

On Friday, August 10 2018, eamanu wrote:

> Hello Sergio,

Hi Emmanuel,

> I am really sorry for the delay.

No need to apologize :-).

> I finish the update of pcapy package. I push the commit, but is on
> UNRELEASED status.
>
> Please, check if whole the things are ok, and then I will make change to
> unstable status on d/changelog

Well, I still see a few problems.  Sorry about that.  Here's the list of
things I spotted:

1) On d/copyright, the license specified for the project is wrong.
According to the LICENSE file, the project is released under a slightly
modified version of the Apache license.  This is something really
important to get right, otherwise the ftp-masters will certainly reject
the package.  You listed the license as being "GPL-2", but the text is
clearly not GPL-2.

2) Still on d/copyright: as said above, the GPL-2 license is wrong.
However, I think it's also important to mention that the license text is
formatted in a strange/wrong manner.  You have text like this:

 [...]
 Redistribution and use in source  and binary forms, with or without
   modification, are permitted  provided that the following conditions
   are met:

   1. Redistributions  of  source   code  must  retain  the  above
 [...]

The correct format for d/copyright is to indent the text using 1 space,
and to use . (dot) for blank lines.  Like this:

 [...]
 Redistribution and use in source  and binary forms, with or without
 modification, are permitted  provided that the following conditions
 are met:
 .
 1. Redistributions  of  source   code  must  retain  the  above
 [...]

3) The package uses a *really* old version of debhelper (version 5!).
We're at version 11 already, so you should update both d/compat and
d/control (i.e., depend on debhelp >= 11) to reflect that.

4) You haven't addressed my comment about building a Python 3 package.
IMO you should really do that; lintian will warn you if you don't.

5) You haven't answered my question about why the package has "Suggests:
doc-base".  It seems to be a relic from this very old debhelper; I think
you can safely remove it.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: git-dpm required?

[Sergio Durigan Junior]

On Monday, July 30 2018, Sean Whitton wrote:

> Hello,
>
> On Mon 30 Jul 2018 at 09:54PM -0400, Sergio Durigan Junior wrote:
>
>> This is my understanding as well: git-dpm is not mandatory anymore, and
>> gbp is the preferred tool.  I've been packaging all of my Python modules
>> using gbp for a while.
>
> Do I have to use the full suite of gbp tools (e.g. gbp-pq) or is it
> enough that `gbp buildpackage` will work?

You don't have to use the full suite if you don't like.  The important
thing is to have the repository in the correct format
(debian/upstream/pristine-tar branches [or something else, as long as
properly documented in d/gbp.conf], tags, etc.), so that other people
can use gbp without problems.

Not even gbp buildpackage is mandatory; you can use your own build
workflow if you want.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: git-dpm required?

[Sergio Durigan Junior]

On Monday, July 30 2018, Sean Whitton wrote:

> [please CC me]
>
> Hello,
>
> The team policy says that git-dpm is mandatory but someone here at
> DebConf (sorry, can't remember who) told me that since the move to
> salsa, this has been relaxed to the simple requirement that the tree be
> buildable with `gbp buildpackage`.
>
> Before I add a new python library to Debian, pleast let me know whether
> I have to use git-dpm.

Hi Sean,

This is my understanding as well: git-dpm is not mandatory anymore, and
gbp is the preferred tool.  I've been packaging all of my Python modules
using gbp for a while.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Request to join

[Sergio Durigan Junior]

On Monday, July 30 2018, Piotr Ożarowski wrote:

> Hi Felix,
>
> [Felix Lechner, 2018-07-16]
>> I would like to join the PAPT team, please. Any pointers would be
>> appreciated. Thank you!
>
> let us know your salsa.d.o username if you accept our policy
> https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst

BTW, I was the person who to Felix to just send an email to
debian-python asking to join the PAPT.  I tried finding the team policy
online but wasn't able to.  Thanks for addressing this, Piotr.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#904877: ITP: trololio -- Trollius and asyncio compatibility library

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: trololio
  Version : 1.0
  Upstream Author : ThinkChaos
* URL : https://github.com/ThinkChaos/Trololio
* License : Expat
  Programming Lang: Python
  Description : trololio -- Trollius and asyncio compatibility library

 Trololio provides a compatibility layer for Trollius and asyncio (aka
 Tulip). It addresses the differences listed in Trollius and Tulip:
 .
  * Allows the use of Trollius' syntax with asyncio.
  * Provides missing objects and aliases for the others.
  * Synchronizes debug environnement variables.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#904066: ITP: python-openidc-client -- A Python OpenID Connect client with token caching and management

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-openidc-client
  Version : 0.6.0
  Upstream Author : Patrick Uiterwijk 
* URL : https://github.com/puiterwijk/python-openidc-client
* License : Expat
  Programming Lang: Python
  Description : A Python OpenID Connect client with token caching and 
management

 This package is a simple Python OpenID Connect client library with
 token caching and management.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#904054: ITP: cccolutils -- Python Kerberos Credential Cache Collection Utilities

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: cccolutils
  Version : 1.4
  Upstream Author : https://pagure.io/cccolutils
* URL : Patrick Uiterwijk 
* License : GPL-2+
  Programming Lang: Python
  Description : Python Kerberos Credential Cache Collection Utilities

 This module provides Kerberos 5 credential cache collection utilities
 for Python 2.6+ and 3.
 .
 When a user authenticates to a Kerberos realm (eg. with kinit), the user
 has a short-lived credential in a cache (view it with klist).
 .
 You can use this cccolutils module to easily determine if the user has
 any valid Kerberos credentials, or what the username is for a particular
 Kerberos realm.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: RFS: pcapy/0.11.3-1 [ITA]

[Sergio Durigan Junior]

Control: owner -1 !
Control: tags -1 + moreinfo

On Thursday, June 07 2018, eamanu wrote:

> Dear mentors,
>
> I am looking for a sponsor for my package "pcapy"
>
> * Package name: pcapy
> Version : 0.11.3-1
> Upstream Author : Core Security 
> * URL : https://github.com/CoreSecurity/pcapy
> * License : Apache Software License
> Section : python
>
> It builds those binary packages:
>
> python-pcapy - Python interface to the libpcap packet capture library
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/pcapy
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> https://mentors.debian.net/debian/pool/main/p/pcapy/pcapy_0.11.3-1.dsc
>
> More information about hello can be obtained from https://www.example.com.
>
> Changes since the last upload:
>
> [ Jakub Wilk ]
> * Use canonical URIs for Vcs-* fields.
>
> [ Ondřej Nový ]
> * Fixed VCS URL (https)
> * d/control: Set Vcs-* to salsa.debian.org
> * d/changelog: Remove trailing whitespaces
> * Remove debian/pycompat, it's not used by any modern Python helper
>
> [ Emmanuel Arias ]
> * new upstream version
> * update d/watch to download correctly the last upstream version
> * update d/control to add Maintainer the DPMT
> * update d/control to add me to Uploaders field (Closes: #895787)
> * update debhelper on d/contorl from 5.0.37.2 to 11
> * update Standards-Version from 3.9.2 to 4.1.4 on d/control
> * add Testsuite: autopkgtest-pkg-python on d/control
> * update d/compat from 5 to 11
> * add to copyright file the debian files copyright

Hi Emmanuel,

Thanks for the package, and for your interest in adopting it!  The first
question I have is about the VCS.  I tried finding your commits on the
official Salsa repo, but wasn't able to.  Are you using any other
repository for that?  It's much easier to review the changes when
there's a repository, and I strongly suggest you use the official one
for the packaging.

As for the review, here's what I'd like you to address:

1) d/copyright should follow DEP-5.  Take a look at:

  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

and you'll be able to find instructions on the format of the file.  It
shouldn't be too hard for you to convert the existing file.

2) The package doesn't need CDBS anymore, so you can safely remove it
from the Build-Depends line.

3) The "Homepage" field can have a better URL:

  https://www.coresecurity.com/corelabs-research/open-source-tools/pcapy

4) You should consider packaging a Python 3 package, as well as the
Python 2 you're already packaging (in which case you could probably
split the documentation part into its own package).  If Python 3 is not
supported, you should contact upstream and probably file a bug against
it.

5) Any reason why the package has "Suggests: doc-base"?

6) It's a good habit to export the PYBUILD_NAME variable (on d/rules):

  export PYBUILD_NAME=pcapy

This variable tells pybuild what's the name of your project.

7) It's a good idea to use (on d/rules):

  export DEB_BUILD_MAINT_OPTIONS = hardening=+all

since your package is building a shlib.

8) The package is installing the LICENSE file by default, but this is
not needed since we have the d/copyright file.  Therefore, it'd be good
if you could remove this file from the package.  You can do that by
e.g. overriding dh_auto_install and rm'ing the file there.


I think that's basically everything I've spotted.  Please let me know if
you need any help.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Request to join python team on salsa

[Sergio Durigan Junior]

On Wednesday, May 30 2018, I wrote:

> On Tuesday, May 29 2018, Samuel Henrique wrote:
>
>> I wasn't able to open
>> https://python-modules.alioth.debian.org/python-modules-policy.html[0] but
>> i'm sure i have read them when joining the team on alioth.
>
> The most recent version I found, from December 11th, 2017:
>
>   
> https://web.archive.org/web/20171211221837/https://python-modules.alioth.debian.org/policy.html
>
> It might be a good idea to provide this link on the wiki, assuming it is
> up-to-date.

Even better:

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

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Request to join python team on salsa

[Sergio Durigan Junior]

On Tuesday, May 29 2018, Samuel Henrique wrote:

> I wasn't able to open
> https://python-modules.alioth.debian.org/python-modules-policy.html[0] but
> i'm sure i have read them when joining the team on alioth.

The most recent version I found, from December 11th, 2017:

  
https://web.archive.org/web/20171211221837/https://python-modules.alioth.debian.org/policy.html

It might be a good idea to provide this link on the wiki, assuming it is
up-to-date.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#734117: RFP: python-check-manifest -- tool to check the completeness of MANIFEST.in for Python packages

[Sergio Durigan Junior]

Control: retitle -1 ITP: python-check-manifest -- tool to check the 
completeness of MANIFEST.in for Python packages
Control: owner -1 !

On Friday, January 03 2014, Francois Marier wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name: python-check-manifest
>   Version : 0.17
>   Upstream Author : Marius Gedminas 
> * URL : https://github.com/mgedmin/check-manifest
> * License : MIT
>   Programming Lang: Python
>   Description : tool to check MANIFEST.in in a Python source package for 
> completeness

I intend to package this.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Sergio Durigan Junior]

On Friday, August 12 2016, Barry Warsaw wrote:

> On Aug 12, 2016, at 05:50 PM, Sergio Durigan Junior wrote:
>
>>I understand this is a matter of personal taste, but I beg to differ.  I
>>have been using git-buildpackage for most of my non-Python packages and,
>>despite really small nits here and there, I think it is an awesome tool.
>
> I think there are multiple ways in which git-buildpackage is used.  E.g. I use
> `gbp buildpackage` even for git-dpm maintained packages, to build the source
> package, etc.  (It even has a nicer `clone` command that makes it easy to
> actually get tracking branches; just wish it had something like
> `pull-and-update-all-branches` since it's a bit of a PITA to update the
> pristine-tar branch.)

Yeah, I use 'gbp dch' and 'gbp buildpackage' when dealing with git-dpm
packaging, too.

> It's just the few things that git-dpm adds on top of gbp that we're discussing
> getting rid of, like importing a new upstream, managing the quilt patch set,
> tagging.

Right, that's what I thought, and those things are exactly what make me
unhappy about using git-dpm :-).

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Sergio Durigan Junior]

On Wednesday, August 10 2016, Nikolaus Rath wrote:

> I don't believe that switching from git-dpm to git-buildpackage is going
> to make things easier, it'll just be trading one set of problems for
> another.

I understand this is a matter of personal taste, but I beg to differ.  I
have been using git-buildpackage for most of my non-Python packages and,
despite really small nits here and there, I think it is an awesome tool.

git-dpm, OTOH, has several limitations (as already mentioned by others,
it's not trivial to merge changes to local patches, and it can be quite
complicated to import a new upstream version into the repository).
I have had to package some Python packages these last weeks, and every
time I had to deal with git-dpm I almost always stumbled upon some
idiosyncrasy that got in the way of my work.

Long story short: I am totally favorable to make the switch to
git-buildpackage (in fact, I recently raised this topic on IRC but the
conversation eventually died).

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: [Python-modules-team] Bug#830186: sphinx: intersphinx mapping extension causes network access during package builds

[Sergio Durigan Junior]

On Thursday, July 14 2016, Andreas Tille wrote:

>> Not sure I understand how dh-python / pybuild help with this problem.
>> 
>> I thought the recommended way to deal with building documentation was
>> something like this in debian/rules:
>> 
>> override_dh_auto_build:
>> dh_auto_build
>> PYTHONPATH=. sphinx-build -b html -N Doc/ Doc/.build/html
>> 
>> ... in which case building the documentation happens outside
>> dh_auto_build.
>
> I'm using
>
> override_dh_auto_build:
> # arch
> USE_CYTHON=true dh_auto_build
> # indep:
> PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -b html doc 
> build/html
> PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -b man doc 
> build/man
>
> in python-biom-format[1] which results in #831239.  I was once advised
> to specify the http_proxy that way (others here in this thread as well)
> and I wonder how to solve this.  If I try to export http_proxy and do
> not call sphinx-build manually at all no documentation will be created.

Hey Andreas,

You have to instruct debhelper to use dh_sphinxdoc.  I.e.:

  dh $@ --with python2,python3,bash-completion,sphinxdoc --buildsystem=pybuild

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Bug#830825: ITP: python-openid-cla -- OpenID CLA extension for python-openid

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: python-openid-cla
  Version : 1.2
  Upstream Author : Patrick Uiterwijk <puiterw...@gmail.com>
* URL : https://github.com/puiterwijk/python-openid-cla
* License : BSD-3-clause
  Programming Lang: Python
  Description : OpenID CLA extension for python-openid

 Implementation of the OpenID CLA extension for python-openid.  The
 purpose of this extension is to allow retrieving a list of signed
 contributor license agreements.

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829655: ITP: python-openid-teams -- OpenID teams extension for python-openid

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: python-openid-teams
  Version : 1.1
  Upstream Author : Patrick Uiterwijk <puiterw...@gmail.com>
* URL : https://github.com/puiterwijk/python-openid-teams
* License : BSD-3-clause
  Programming Lang: Python
  Description : OpenID teams extension for python-openid

 Implementation of the OpenID teams extension for python-openid.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829506: ITP: flask-multistatic -- A simple flask plugin for overriding static files

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: flask-multistatic
  Version : 1.0
  Upstream Author : Pierre-Yves Chibon <pin...@pingoured.fr>
* URL : https://pagure.io/flask-multistatic
* License : GPL-3+
  Programming Lang: Python
  Description : A simple flask plugin for overriding static files

 Simple flask plugin allowing to override static files, making theming
 flask applications really easy.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Bug#829492: Acknowledgement (ITP: flask-wtf -- Simple integration of Flask and WTForms)

[Sergio Durigan Junior]

On Sunday, July 03 2016, Debian Bug Tracking System wrote:

> Thank you for filing a new Bug report with Debian.

As it turns out, this is already packaged for Debian under the name
python-flaskext.wtf.

Closing the ITP.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829492: ITP: flask-wtf -- Simple integration of Flask and WTForms

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: flask-wtf
  Version : 0.12
  Upstream Author : Dan Jacob, Hsiaoming Yang et al
* URL : https://github.com/lepture/flask-wtf
* License : BSD-3-clause
  Programming Lang: Python
  Description : Simple integration of Flask and WTForms

 Simple integration of Flask and WTForms, including CSRF, file upload
 and Recaptcha integration.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#829153: ITP: straight.plugin -- A simple namespaced plugin facility for Python

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior <sergi...@sergiodj.net>

* Package name: straight.plugin
  Version : 1.4.1
  Upstream Author : Calvin Spealman <ironfro...@gmail.com> et al
* URL : https://github.com/ironfroggy/straight.plugin
* License : Expat (MIT)
  Programming Lang: Python
  Description : A simple namespaced plugin facility for Python

  straight.plugin is a Python plugin loader inspired by twisted.plugin
  with two important distinctions:

  - Fewer dependencies
  - Python 3 compatible

  The system is used to allow multiple Python packages to provide plugins
  within a namespace package, where other packages will locate and
  utilize. The plugins themselves are modules in a namespace package where
  the namespace identifies the plugins in it for some particular purpose
  or intent.

This package is a dependency necessary for pagure.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: python-texttable -- status and interest in becoming the maintainer

[Sergio Durigan Junior]

On Tuesday, June 14 2016, I wrote:

>> If you are interested in keeping the package up to date, please add yourself 
>> to Uploaders and then get to work.  Please make sure you use git-dpm on any 
>> DPMT repositories.
>
> Cool, I'll add myself as an Uploader then.  I will still need a sponsor
> for the first upload, however.  I've been working closely with
> Gianfranco Costamagna, but if there's anybody here who'd like to sponsor
> me then that's fine as well.
>
> BTW, I consider the work I posted on my git repo (link above) to be
> basically finished (I'll just need to adjust the Uploaders part), so if
> someone is feeling like reviewing it I'd appreciate.  I used git-dpm and
> follower the DPMT policy.

Hey again,

So, the work is finished.  The latest git changes are here, for now:

  

I haven't pushed them to alioth because I'd like to upload the package
first.  I need some DD to allow me to upload the python-texttable
package.

FWIW, I have also uploaded the package to mentors.d.n, in case anyone is
interested:

  

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: python-texttable -- status and interest in becoming the maintainer

[Sergio Durigan Junior]

On Tuesday, June 14 2016, Scott Kitterman wrote:

> On Tuesday, June 14, 2016 12:55:15 AM Sergio Durigan Junior wrote:
>> Hello,
>> 
>> I'm a user of the python-texttable package on Debian, and I noticed that
>> it seems abandoned.  The first and only upload happened in 2013, and
>> even though there is a new upstream version available the package did
>> not get updated.  Its git repository on Alioth has received some
>> attention recently, when Ondřej Nový migrated the code from SVN and did
>> some adjustments, but the package has not been uploaded.
>> 
>> Anyway, I'm writing this e-mail because I'm interested in the package
>> and I would like to maintain it if its current maintainer (or Ondřej)
>> has no interest in continuing his work.  I have submitted a bug against
>> the package (#826156) and Cc'ed the maintainer to know if he's still
>> interested.  I am Cc'ing Ondřej on this message.  I don't know how long
>> you usually wait before considering a package to be orphaned, so that's
>> another reason I'm writing.
>> 
>> I have worked on an update for the package which can be seen here:
>> 
>>   <http://git.sergiodj.net/?p=debian/python-texttable.git;a=summary>
>> 
>> Anyway, that's it.  I have read the DPMT policy and I agree with it; my
>> username on Alioth is sergiodj-guest and I am DM.
>
> Welcome to the team.  Both the git migration and Ondřej recent changes were 
> general operations done on all team packages and not an indication of any 
> particular interest.  Particularly since Debian Python Modules Team is set as 
> maintainer, you should feel free to work on the package.

Thanks, Scott.

> If you are interested in keeping the package up to date, please add yourself 
> to Uploaders and then get to work.  Please make sure you use git-dpm on any 
> DPMT repositories.

Cool, I'll add myself as an Uploader then.  I will still need a sponsor
for the first upload, however.  I've been working closely with
Gianfranco Costamagna, but if there's anybody here who'd like to sponsor
me then that's fine as well.

BTW, I consider the work I posted on my git repo (link above) to be
basically finished (I'll just need to adjust the Uploaders part), so if
someone is feeling like reviewing it I'd appreciate.  I used git-dpm and
follower the DPMT policy.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

python-texttable -- status and interest in becoming the maintainer

[Sergio Durigan Junior]

Hello,

I'm a user of the python-texttable package on Debian, and I noticed that
it seems abandoned.  The first and only upload happened in 2013, and
even though there is a new upstream version available the package did
not get updated.  Its git repository on Alioth has received some
attention recently, when Ondřej Nový migrated the code from SVN and did
some adjustments, but the package has not been uploaded.

Anyway, I'm writing this e-mail because I'm interested in the package
and I would like to maintain it if its current maintainer (or Ondřej)
has no interest in continuing his work.  I have submitted a bug against
the package (#826156) and Cc'ed the maintainer to know if he's still
interested.  I am Cc'ing Ondřej on this message.  I don't know how long
you usually wait before considering a package to be orphaned, so that's
another reason I'm writing.

I have worked on an update for the package which can be seen here:

  

Anyway, that's it.  I have read the DPMT policy and I agree with it; my
username on Alioth is sergiodj-guest and I am DM.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature