Joining python-modules
Hi everyone, I recently wanted to increase my debian contributions as a prospective maintainer. I've read the policy from https://python-modules.alioth.debian.org/policy.html and I accept it (in fact, I love the idea behind collaborative maintenance, collab-maint, and I subscribed to LowThresholdNmu as well). There are three python packages that I'd like to contribute, all three from pypi: - https://pypi.python.org/pypi/python-bond (I'm the author) - https://pypi.python.org/pypi/tabview (contributor) - https://pypi.python.org/pypi/gtabview (author) I filed already an ITP for python-bond, and I was probably too trigger-happy as I created the package into collab-maint already: https://anonscm.debian.org/cgit/collab-maint/python-bond.git/ (ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809542) Only afterwards I realized that python-modules would be a better place. Conversion with p2dsc was pretty straightforward. I only added copyright, tweaked the control file with the correct build-depends, description, installed the documentation correctly. The test suite in the package is rather complex, as it depends on a whole slew of other runtimes (perl, nodejs, ssh, etc). The package is independently tested via travis, so I disabled the tests instead of adding build-depends for all of them. Could somebody review the package? I only need to tweak the changelog and fix uploaders/maintainer at this point. Thanks!
Re: Enabling Python bindings for jellyfish
Hi Guillaume, On Thu, Dec 31, 2015 at 06:24:57PM -0500, Guillaume Marcais wrote: > if I am attached to the name Jellyfish for the main software itself, the > script bindings have seen little use (I believe) up to now. Renaming python > module to dna_jellyfish, bio_jellyfish, or some other suggestion, would be > OK with me. Since you are the author would you mind fixing a name yourself. The rationale is that if we might choose a name for Debian other distributions (or consumers of the code from source directly) might choose a different one which might lead to a lot of confusion. It would be great if you could issue a new release with a proper name for the Python module. > Regarding the module itself, it should work for both Python2 and Python3. > If you have example where it does not, please let me know. When trying to build the module I get: ... running build_ext building '_jellyfish' extension creating build/temp.linux-x86_64-3.5 x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.5m -c jellyfish_wrap.cxx -o build/temp.linux-x86_64-3.5/jellyfish_wrap.o -std=c++0x cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++ jellyfish_wrap.cxx:3104:33: fatal error: jellyfish/mer_dna.hpp: No such file or directory compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 since the includes are not properly set. Kind regards Andreas. -- http://fam-tille.de
Re: Switching Default Python3 To Python3.5
On 31.12.2015 10:44, Scott Kitterman wrote: I went through the bad/unknown packages in the python3.5 transition tracker [1] and the remainder seems reasonable for doing the transition. Many of them only build support for the default python3 and so they will be bad until after they are rebuilt following the switch. I filed bugs with patches for packages that seemed to be ~easy to make build for multiple versions. Some of the remainder should not be build-depending on python3-dev at all since they don't have any arch specific content. I filed a stack of bugs on those too (as well as doing a team upload or two). That should leave in the neighborhood of 45 - 50 binNMUs, which isn't so many. Does anyone object if I go ahead and ask the release team for a transition slot? No. However there is a real issue with ipython. For Ubuntu xenial I just disabled the tests. It would be nice if ipython would have an update strategy, whether this is the 2.x, 3.x or the 4.x branch. Matthias
Re: Request to join the Debian Python Modules Team
[Víctor Cuadrado Juan, 2016-01-01]
> I would like to join the DPMT to maintain python-neovim [1][2]
great!
> [2]: http://mentors.debian.net/package/python-neovim
http://mentors.debian.net/debian/pool/main/p/python-neovim/python-neovim_0.1.0-1.dsc
* how about "Description: scripting Nvim processes through its msgpack-rpc API"?
* long description (after removing short one from it) can mention what
nvim is ("Vim-fork focused on extensibility and agility") and that
this package provides Python client to it.
* shouldn't python3-neovim be Architecture: all?
* use these:
Vcs-Git: git://anonscm.debian.org/python-modules/packages/python-neovim.git
Vcs-Browser:
https://anonscm.debian.org/cgit/python-modules/packages/python-neovim.git
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
signature.asc
Description: PGP signature
Re: [Python-modules-team] My Pip installation is broken after upgrading Debian from oldstable/Wheezy to stable/Jessie...
Ant Dude writes: >> In short, it isn't recommended practise to use pip install with Debian, >> except for inside a virtualenv (or similar), as the packages can >> conflict with Debian packages - especially after a upgrade. > > Interesting. I did find a fix and it seems like others had the same > problem. FFrom Debian's forum, it said > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744145#31 -- rm -rf > /usr/local/lib/python2.7/dist-packages/requests* I renamed request > directory and now can run Debian's pip command. Sheesh. I also notice it > is an old bug that is still not fixed. :( Are you sure? This bug was supposedly fixed in the Jessie version... -- Brian May
Re: [Python-modules-team] My Pip installation is broken after upgrading Debian from oldstable/Wheezy to stable/Jessie...
> >> In short, it isn't recommended practise to use pip install with Debian, > >> except for inside a virtualenv (or similar), as the packages can > >> conflict with Debian packages - especially after a upgrade. > > > > Interesting. I did find a fix and it seems like others had the same > > problem. FFrom Debian's forum, it said > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744145#31 -- rm -rf > > /usr/local/lib/python2.7/dist-packages/requests* I renamed request > > directory and now can run Debian's pip command. Sheesh. I also notice it > > is an old bug that is still not fixed. :( > > Are you sure? This bug was supposedly fixed in the Jessie version... Maybe it is a different issue? Pip is still working so far with that directory renamed: $ ls /usr/local/lib/python2.7/dist-packages/requestsRENAMED -all total 684 drwxr-sr-x 3 root staff 4096 Dec 21 07:10 . drwxrwsr-x 49 root staff 4096 Jan 1 10:30 .. -rw-r--r-- 1 root staff 17495 Dec 21 07:10 adapters.py -rw-r--r-- 1 root staff 16160 Dec 21 07:10 adapters.pyc -rw-r--r-- 1 root staff 5419 Dec 21 07:10 api.py -rw-r--r-- 1 root staff 6194 Dec 21 07:10 api.pyc -rw-r--r-- 1 root staff 7550 Dec 21 07:10 auth.py -rw-r--r-- 1 root staff 8065 Dec 21 07:10 auth.pyc -rw-r--r-- 1 root staff 344712 Dec 21 07:10 cacert.pem -rw-r--r-- 1 root staff613 Dec 21 07:10 certs.py -rw-r--r-- 1 root staff883 Dec 21 07:10 certs.pyc -rw-r--r-- 1 root staff 1469 Dec 21 07:10 compat.py -rw-r--r-- 1 root staff 1691 Dec 21 07:10 compat.pyc -rw-r--r-- 1 root staff 17387 Dec 21 07:10 cookies.py -rw-r--r-- 1 root staff 21091 Dec 21 07:10 cookies.pyc -rw-r--r-- 1 root staff 2776 Dec 21 07:10 exceptions.py -rw-r--r-- 1 root staff 5974 Dec 21 07:10 exceptions.pyc -rw-r--r-- 1 root staff767 Dec 21 07:10 hooks.py -rw-r--r-- 1 root staff 1212 Dec 21 07:10 hooks.pyc -rw-r--r-- 1 root staff 2007 Dec 21 07:10 __init__.py -rw-r--r-- 1 root staff 2664 Dec 21 07:10 __init__.pyc -rw-r--r-- 1 root staff 29277 Dec 21 07:10 models.py -rw-r--r-- 1 root staff 25836 Dec 21 07:10 models.pyc drwxr-sr-x 4 root staff 4096 Dec 21 07:10 packages -rw-r--r-- 1 root staff 24544 Dec 21 07:10 sessions.py -rw-r--r-- 1 root staff 19948 Dec 21 07:10 sessions.pyc -rw-r--r-- 1 root staff 3280 Dec 21 07:10 status_codes.py -rw-r--r-- 1 root staff 4598 Dec 21 07:10 status_codes.pyc -rw-r--r-- 1 root staff 2977 Dec 21 07:10 structures.py -rw-r--r-- 1 root staff 5252 Dec 21 07:10 structures.pyc -rw-r--r-- 1 root staff 21845 Dec 21 07:10 utils.py -rw-r--r-- 1 root staff 21397 Dec 21 07:10 utils.pyc
