(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,
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
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
In my first task as a member of the Debian Python Modules Team, I've
prepared an upload of "python-social-auth". It was updated to a
newer upstream release (0.2.13 to 0.2.19) and some fixes were also
Is there anyone here able to review/sponsor those changes?
On 16 May 2016 at 18:48, Piotr Ożarowski wrote:
> welcome :)
Thank you very much for accepting my application.
Tiago "Myhro" Ilieve
-BEGIN PGP SIGNED MESSAGE-
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
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
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:
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
I was working on the "boostrap-vz" package and noticed something
really annoying when creating a "boostrap-vz-doc" 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
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
I am looking for a sponsor for my package "grip"
* Package name: grip
Version : 4.1.0-1
Upstream Author : Joe Esposito
* URL :
The Style Guide for Packaging Python Libraries 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
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
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
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
I'm packaging grip (ITP #790611) 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
I can't use its entry point script directly because it expects to be
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
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 ,
> that is still easier than a patch.
This is indeed way
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
On 25 March 2016 at 19:07, Gianfranco Costamagna
> up to your sponsor :)
Tried one or two new approaches and it didn't worked. In the I've
created a patch changing "#!/usr/bin/env python2" to
"#!/usr/bin/env python". This should work as long
On 25 March 2016 at 16:21, Gianfranco Costamagna
> please dget it from there and start again :)
> I fixed a lot of issues, and many more are there now!
diff --git a/debian/control b/debian/control
index f0c1b3f..5205298 100644
@@ -3,6 +3,7 @@ Section: python
Maintainer: Tiago Ilieve <tiago.my...@gmail.com>
Build-Depends: debhelper (>= 9)
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
Mail list logo