Re: RFS: python-twython - Pure Python wrapper for the Twitter API

2014-05-01 Thread Vincent Cheng 
On Thu, May 1, 2014 at 8:07 PM, Josue Ortega  wrote:
> Hi Team,
> I am looking for a sponsor for my package and maitain it with the DPMT.
> The package is python-twython Pure Python wrapper for the Twitter API.
> This closes #739010 which is an ITP.
> Here is some useful information about the package:
>  Version : 3.1.2-1
>  Upstream Author : Ryan McGrath 
>  URL : https://github.com/ryanmcgrath/twython/tree/master
>  License : MIT
>
>
> It builds those binary packages:
> python-twython - Pure Python wrapper for the Twitter API
> python3-twython - Pure Python3 wrapper for the Twitter API
>
> If you are interested you can get it on mentors[0] or in the SVN DPMT[1].

Just curious, how does this differ from python-twitter, which is
already in the archive? Do we need two different sets of python
wrappers around Twitter's API?

Regards,
Vincent


-- 
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/CACZd_tDxg1bkV_1kAdt8tWssh5EwWp1y-3WMpUCX5WfjTa=-8...@mail.gmail.com

Re: future of python-pipeline package

2014-05-01 Thread Brian May 
On 16 May 2012 18:57, Dmitry Nezhevenko  wrote:

> Holger suggests to ask here and thinks that it's better to remove orphaned
> pipeline package. Any ideas or suggestions?
>

I just noticed this thread from 2012 in debian-devel / #620067, because I
am in exactly the same situation.

There has been a grave bug opened in fact:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674042

Nobody has given any reason why we can't resolve this situation in unstable
by removing python-pipeline. It is orphaned[1]. This will remove the
conflicting package and we can close the bug.

Somebody said in this thread "However, I object to another package taking
over the module name." - but the other package is already in Debian - he
already missed his chance to object, and he failed to give any reasons why.
I think it is wrong that one person can prevent constructive work to
resolve release critical bugs like this.

Alternatively, django-pipeline could be modified to conflict with
python-pipeline. This would allow closing the grave bug report, but seems
wrong.

Notes:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620067
-- 
Brian May

Re: building python debian packages and virtualenv

2014-05-01 Thread Stuart Prescott 
Hi Brian,

> Fortunately, so far I have always noticed this before uploading the
> package, however think it is only a matter of time before I stuff up an
> upload.

While not directly addressing your question, perhaps this is also a good 
opportunity to add some autopkgtest tests to the packages -- even if there's 
not a full test suite from upstream, a (minimal) smoke test would catch 
this. The autopkgtest tests probe the installed package as opposed to the 
the just-built source so it catches wrong file paths, files that get missed 
out from the "install" step etc.

The autopkgtest specification is also known as DEP-8:

http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-
tests;hb=HEAD

http://packaging.ubuntu.com/html/auto-pkg-test.html

and an example of a python module's test suite that runs upstream's test 
suite is:

http://sources.debian.net/src/translate-toolkit/1.11.0%2Bdfsg-1/debian/tests

(or look for other packages that declare "Testsuite: autopkgtest" in the 
Sources file)

To run the tests, there's "sadt" from devscripts which runs in your current 
environment (but would possibly still suffer from the virtualenv problem -- 
I don't think it sanitises this part of the environment). For better 
isolation, adt-run can run it in a chroot or virtual machine -- if you're 
already using schroot/sbuild to build things, then you can:

adt-run -B \
  --binary $DEBS \
  --source $DSC \
  --log-file $CHANGES.adt.log \
  --- adt-virt-schroot unstable-amd64-sbuild

cheers
Stuart

(this message was brought to you by the package testing fan club)


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7




-- 
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/ljva27$lp5$1...@ger.gmane.org

RFS: python-twython - Pure Python wrapper for the Twitter API

2014-05-01 Thread Josue Ortega 
Hi Team,
I am looking for a sponsor for my package and maitain it with the DPMT.
The package is python-twython Pure Python wrapper for the Twitter API.
This closes #739010 which is an ITP.
Here is some useful information about the package:
 Version : 3.1.2-1
 Upstream Author : Ryan McGrath 
 URL : https://github.com/ryanmcgrath/twython/tree/master
 License : MIT


It builds those binary packages:
python-twython - Pure Python wrapper for the Twitter API
python3-twython - Pure Python3 wrapper for the Twitter API

If you are interested you can get it on mentors[0] or in the SVN DPMT[1].

Thank you for your help.

Cheers

[0]: http://mentors.debian.net/debian/pool/main/t/twython/twython_3.1.2-1.dsc
[1]: http://anonscm.debian.org/viewvc/python-modules/packages/twython/
---
Josue Ortega
«Happy Hacking»
http://josueortega.org

signature.asc
Description: Digital signature

Re: building python debian packages and virtualenv

2014-05-01 Thread Ben Finney 
Brian May  writes:

> Several times I have made the mistake of building a Debian package
> while a virtualenv is active. This results in the paths being
> incorrect in the Debian package.

The best way to avoid this is to always use a build tool which builds
the package in its *own* environment, separate from what you're doing
for your interactive session. ‘pbuilder(1)’ and ‘sbuild(1)’ are good for
this.

> Fortunately, so far I have always noticed this before uploading the
> package, however think it is only a matter of time before I stuff up
> an upload.

Right. Now is the time to make a session-based build tool a non-optional
part of your package maintenance :-)

> Just wondering if it would be considered appropriate to have, say,
> dh_auto_build fail if it is about to call setup.py and it is inside a
> virtualenv.

Possibly; I don't have enough expertise on that to say whether it's a
good idea.

-- 
 \  “Be careless in your dress if you must, but keep a tidy soul.” |
  `\  —Mark Twain, _Following the Equator_ |
_o__)  |
Ben Finney


-- 
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/85eh0chomv@benfinney.id.au

Re: dh_auto_* and Makefile

2014-05-01 Thread Brian May 
On 2 May 2014 11:14, Christian Kastner  wrote:

> %:
>  dh $@ --with python2 --buildsystem=python_distutils
>
> See also section BUILD SYSTEM OPTIONS of debhelper(7).
>

Just what I wanted. Thanks.

I did see this in the debhelper(7) man page, but got confused when it
wasn't mentioned in the dh_auto_install man page, and I wasn't sure what
value to use.
-- 
Brian May

Re: dh_auto_* and Makefile

2014-05-01 Thread Christian Kastner 
On 2014-05-02 02:48, Brian May wrote:
> In a particular project (django-model-utils 2.0.3 to be precise), if I
> have a debian/rules file containing:
> 
> 
> %:
> dh $@ --with python2
> 
> Then dh_auto_* tools determine that the project comes with a Makefile
> (upstream file), and uses that instead of setup.py
> 
> How can I force it to use setup.py?

%:
 dh $@ --with python2 --buildsystem=python_distutils

See also section BUILD SYSTEM OPTIONS of debhelper(7).

> I have tried providing override_dh_auto_*, but then I hard coded the
> python version to use.
> 
> Or should I create a patch in debian/patches that removes the Makefile?
> This seems to be the simplest solution, but want to make sure it sounds
> reasonable.
> 
> Thanks
> -- 
> Brian May  >


-- 
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/5362f173.6080...@kvr.at

building python debian packages and virtualenv

2014-05-01 Thread Brian May 
Hello,

Several times I have made the mistake of building a Debian package while a
virtualenv is active. This results in the paths being incorrect in the
Debian package. Sometimes the package build will fail as a result, this
depends on the package.

Fortunately, so far I have always noticed this before uploading the
package, however think it is only a matter of time before I stuff up an
upload.

Just wondering if it would be considered appropriate to have, say,
dh_auto_build fail if it is about to call setup.py and it is inside a
virtualenv.

Just a thought.

Thanks.
-- 
Brian May

dh_auto_* and Makefile

2014-05-01 Thread Brian May 
Hello,

In a particular project (django-model-utils 2.0.3 to be precise), if I have
a debian/rules file containing:


%:
dh $@ --with python2

Then dh_auto_* tools determine that the project comes with a Makefile
(upstream file), and uses that instead of setup.py

How can I force it to use setup.py?

I have tried providing override_dh_auto_*, but then I hard coded the python
version to use.

Or should I create a patch in debian/patches that removes the Makefile?
This seems to be the simplest solution, but want to make sure it sounds
reasonable.

Thanks
-- 
Brian May

Re: Getting rid of python-support?

2014-05-01 Thread Barry Warsaw 
On May 01, 2014, at 07:15 AM, Scott Kitterman wrote:

>>If PEP 404 is ever update to actually release, then it would be
>>reasonable to expect/demand for PEP 3147 to be implemented / included.

Don't worry, it won't (PEP 404 that is).

-Barry


-- 
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/20140501092154.2433f...@anarchist.wooz.org

Re: Getting rid of python-support?

2014-05-01 Thread Scott Kitterman 
On April 30, 2014 1:15:42 PM EDT, Dimitri John Ledkov  wrote:
>On 30 April 2014 18:01, Matthias Klose  wrote:
>> Am 30.04.2014 17:31, schrieb Luca Falavigna:
>>> Hi,
>>>
>>> python-central is gone (\o/) and python-support usage is slowly
>>> decreasing in the archive:
>>> http://lintian.debian.org/tags/dh_pysupport-is-obsolete.html
>>>
>>> Do you think it would be the right time to prepare a mass bug filing
>>> asking to convert to dh_python{2,3}?
>>
>> that would be good. However before we start this, I'd like to make
>sure that we
>> get rid of /usr/share/pyshared as well.  With PEP 404 [1] reconfirmed
>this year
>> at PyCon we can safely remove the symlink farm.
>>
>
>If PEP 404 is ever update to actually release, then it would be
>reasonable to expect/demand for PEP 3147 to be implemented / included.

Why?

Scott K


-- 
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/44b6f815-2cf1-4cfe-b50d-aa75c81b8...@email.android.com

Re: Getting rid of python-support?

2014-05-01 Thread Luca Falavigna 
2014-04-30 19:27 GMT+02:00 Jakub Wilk :
> This tag doesn't catch indirect use of python-support, via dh or cdbs. The
> actual number of affect packages is much higher.

Indeed, I erroneously thought it considered build dependencies as well.
I'll propose a new check to take into account B-Ds, so we can improve
on that side too.

Cheers,
Luca


-- 
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/CADk7b0MixFJuJxj=zsnrf8r7tgl75sytv-sxi4kybm+ml6s...@mail.gmail.com