Re: python-social-auth 0.2.19-1 review

2016-06-08 Thread Tiago Ilieve
Hi Dmitry, (Sorry for taking so long to reply.) On 1 June 2016 at 08:40, Dmitry Shachnev wrote: > Usually one would do both things using: > > git-dpm import-new-upstream --pristine-tar-commit /path/to/tarball > > In your case .git-dpm was inconsistent with upstream branch,

Re: python-social-auth 0.2.19-1 review

2016-05-30 Thread Tiago Ilieve
Dmitry and Michael, On 24 May 2016 at 07:08, Tiago Ilieve <tiago.my...@gmail.com> wrote: > Thinking about this, the best solution seems to be drop the patch and > remove the "site/" folder, repacking it as a DSFG-compatible tarball. > But if there isn't a strict

Re: python-social-auth 0.2.19-1 review

2016-05-19 Thread Tiago Ilieve
Hi Michael, On 19 May 2016 at 08:41, Michael Fladischer wrote: > my quick review after building it: > > - lintian complains about site/js/bootstrap.min.js, AFAIKT the "site" > folder contains the project's website. Maybe you would like to remove > it by repacking the source

python-social-auth 0.2.19-1 review

2016-05-16 Thread Tiago Ilieve
Hi DPMT, In my first task as a member of the Debian Python Modules Team, I've prepared an upload of "python-social-auth"[1]. It was updated to a newer upstream release (0.2.13 to 0.2.19) and some fixes were also done. Is there anyone here able to review/sponsor those changes? Regards, Tiago.

Re: Request to join Debian Python Modules Team

2016-05-16 Thread Tiago Ilieve
Hi Piotr, On 16 May 2016 at 18:48, Piotr Ożarowski wrote: > welcome :) Thank you very much for accepting my application. Regards, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes

Request to join Debian Python Modules Team

2016-05-13 Thread Tiago Ilieve
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I want to join the Debian Python Modules Team (DPMT), bringing the package "python-path-and-address" to it and maintaining others that are under the team's umbrella. There's a ready-to-be-uploaded version of "python-social-auth"[1] waiting

Re: Properly splitting Python "-doc" packages

2016-04-15 Thread Tiago Ilieve
Piotr, On 14 April 2016 at 18:28, Piotr Ożarowski wrote: > if you decide to go this way, please use python-bootstrapvz, not > python-bootstrap-vz (module name is bootstrapvz, not bootstrap-vz) > > I copy-pasted your typo in package name so dh_python2 didn't find the > right

Re: Properly splitting Python "-doc" packages

2016-04-14 Thread Tiago Ilieve
Piotr, On 14 April 2016 at 12:33, Piotr Ożarowski wrote: > PYBUILD_NAME is used to guess the Debian binary package name (and that's > THE only thing it is used for), whatever is in setup.py doesn't matter. > > If you use PYBUILD_NAME=foo, it will install into: > >

Re: Properly splitting Python "-doc" packages

2016-04-14 Thread Tiago Ilieve
Hi Piotr, On 14 April 2016 at 10:52, Piotr Ożarowski wrote: > that's because python-django is using --buildsystem=pybuild in dh; if you add > > export PYBUILD_NAME=bootstrapvz > > it will install .py / egg-info files into python-bootstrapvz binary package > (please add

Properly splitting Python "-doc" packages

2016-04-14 Thread Tiago Ilieve
Hi, I was working on the "boostrap-vz" package and noticed something really annoying when creating a "boostrap-vz-doc"[1] binary package with its Sphinx documentation: the actual Python files that composes the application weren't being packaged on the main "boostrap-vz" one. I had to add

Re: Packaging Grip

2016-04-06 Thread Tiago Ilieve
Hi Dmitry, On 6 April 2016 at 17:21, Dmitry Shachnev wrote: > 1. Public (/usr/lib/python*/dist-packages) vs private (/usr/share/) location > depends on whether the module is intended to be used by third-party packages, > or only by grip itself. > > 2. The Style Guide doesn't

Bug#820029: RFS: grip/4.1.0-1 [ITP]

2016-04-04 Thread Tiago Ilieve
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "grip" * Package name: grip Version : 4.1.0-1 Upstream Author : Joe Esposito * URL :

Re: Packaging Grip

2016-04-04 Thread Tiago Ilieve
Hi, The Style Guide for Packaging Python Libraries[1] states that in cases like this, one should package the library for both Python 2 and 3, creating a third package that contains the executable. As this package is indeed intended to be used as a CLI application (as its description says), I've

Re: running tests against installed version of package

2016-04-02 Thread Tiago Ilieve
Hi Brian, On 2 April 2016 at 22:32, Brian May wrote: > This will only test the current version of Python 3. Which is OK at the > moment, there is only Python 3.5 > > However it was very useful to have packages run tests against Python 3.5 > while Python 3.4 was still the

Re: running tests against installed version of package

2016-04-02 Thread Tiago Ilieve
Thomas, On 31 March 2016 at 18:49, Thomas Goirand wrote: > Most of the time, you get by this doing: > PYTHONPATH=$(CURDIR) python -m pytest tests Awesome tip! Just stumbled up on this one when imports where changed from relative to absolute and this tip properly fixed the

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

2016-04-02 Thread Tiago Ilieve
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "python-path-and-address" * Package name: python-path-and-address Version : 1.0.0-1 Upstream Author : Joe Esposito

Packaging Grip

2016-04-01 Thread Tiago Ilieve
Hi, I'm packaging grip[1] (ITP #790611[2]) and have a few doubts: Should I package it as an application or a library? It is really a CLI application, but when called it imports its main function as a module[3]. I can't use its entry point script directly because it expects to be installed using

Re: Packaging pythonpy

2016-04-01 Thread Tiago Ilieve
Dmitry, On 31 March 2016 at 15:54, Dmitry Shachnev wrote: > Cool, one little change and it's much better! Actually this has one big implication: as it uses the same interpreter to evaluate its input, it becomes compatible with Python 3 expressions only. Noticed that after

Re: Packaging pythonpy

2016-03-30 Thread Tiago Ilieve
Dmitry, On 30 March 2016 at 16:48, Dmitry Shachnev wrote: > Looks like I was a bit mistaken — dh_python2 will not replace shebangs for > files in /usr/share. But then you can do this manually using a sed call [1], > that is still easier than a patch. This is indeed way

Re: Packaging pythonpy

2016-03-30 Thread Tiago Ilieve
Hi Dmitry, On 29 March 2016 at 18:40, Dmitry Shachnev wrote: > You do not need a patch for this kind of thing. Just pass > --shebang=/usr/bin/whatever to dh_python2 call in your debian/rules. > > Also, for debian/packages, /usr/bin/pythonX is preferred over /usr/bin/env >

Re: Packaging pythonpy

2016-03-25 Thread Tiago Ilieve
Gianfranco, On 25 March 2016 at 19:07, Gianfranco Costamagna wrote: > up to your sponsor :) Tried one or two new approaches and it didn't worked. In the I've created a patch[1] changing "#!/usr/bin/env python2" to "#!/usr/bin/env python". This should work as long

Re: Packaging pythonpy

2016-03-25 Thread Tiago Ilieve
Hi Gianfranco, On 25 March 2016 at 16:21, Gianfranco Costamagna wrote: > http://debomatic-amd64.debian.net/distribution#unstable/pythonpy/0.4.4-1/lintian > please dget it from there and start again :) > > I fixed a lot of issues, and many more are there now! I

Re: Packaging pythonpy

2016-03-25 Thread Tiago Ilieve
following changes: - diff --git a/debian/control b/debian/control index f0c1b3f..5205298 100644 --- a/debian/control +++ b/debian/control @@ -3,6 +3,7 @@ Section: python Priority: optional Maintainer: Tiago Ilieve <tiago.my...@gmail.com> Build-Depends: debhelper (>= 9)

Re: Packaging pythonpy

2016-03-24 Thread Tiago Ilieve
Hi, Can someone please help me on this one? I'm pretty close to finish the initial packaging work. After fixing the following issues, it will be a matter of adding a manpage and filling a RFS. * How to fix the "python-script-but-no-python-dep" lintian error? I've tried with and without pybuild