ors/2016/03/msg00223.html
-- Forwarded message --
From: Tiago Ilieve
Date: 11 March 2016 at 11:55
Subject: Re: Packaging pythonpy
To: debian-ment...@lists.debian.org
Hi Ben,
On 10 March 2016 at 22:19, Ben Finney wrote:
> Not by itself. You need to run something that will actu
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 an
ff --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
Build-Depends: debhelper (>= 9),
+ dh-python,
python (>= 2.7.3),
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 really appreciate your effort in tr
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 as Python 2 is the
default inter
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
> pythonX.
Thanks for the
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 clever than an entire patc
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 trying to access "strin
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
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
* URL
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 matter.
Piotr,
On 31
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 default.
>
> I imagine th
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 fo
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 : https://github.com/joeyespo/grip
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 *require* both Python
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 "usr/lib/
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 python-bootstrapvz binary
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:
>
> debian/python-foo/# python
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 directory and didn't d
-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 permi
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 Claros - MG, Brasi
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.
[1
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 tarball.
There's a p
Hi Dmitry,
On 21 May 2016 at 05:47, Dmitry Shachnev wrote:
> I think it's better to put the missing sources in debian/missing-sources/
> directory rather than patching them in.
>
> (That is also suggested by the Lintian error description[1], and should
> make that error disappear.)
The pedantic
Dmitry and Michael,
On 24 May 2016 at 07:08, Tiago Ilieve 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 strictly legal requirement (e.g. to inc
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, so I had to
> pass t
26 matches
Mail list logo
