RFP -> ITP: mistune -- markdown parser in pure python
Control: retitle -1 ITP: mistune -- markdown parser in pure python Hi, I'm willing to work on packaging it. I'm not part of the debian python modules team yet, but I'm willing to. I'm part of the debian-science team already, so I do have some experience packaging for debian. Snark on #debian-science -- 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/554517d0.1070...@laposte.net
Re: RFP -> ITP: mistune -- markdown parser in pure python
Hi, Le 02/05/2015 20:30, Julien Puydt a écrit : I'm willing to work on packaging it. I'm not part of the debian python modules team yet, but I'm willing to. I'm part of the debian-science team already, so I do have some experience packaging for debian. I made a tentative package using git like for my debian-science packages, even though the policy says otherwise : as there is an ingoing migration, that shouldn't be a problem. I have set the DPMT as maintainer and myself as uploader, which should ensure it will end up on my QA page where I'm already used to check for news. Shall I put my would-be package on git.debian.org, inside /git/python-modules/packages/ [of course using the setup-repository script in /git/python-modules/ -- again something in common with the debian-science workflow] ? Thanks, Snark on #debian-python -- 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/5545ca43.2080...@laposte.net
Re: RFP -> ITP: mistune -- markdown parser in pure python
Le 02/05/2015 20:30, Julien Puydt a écrit : I'm willing to work on packaging it. I'm not part of the debian python modules team yet, but I'm willing to. My login is jpuydt-guest and my name is Julien Puydt, by the way... Snark on #debian-python -- 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/5545e862.4060...@laposte.net
Re: RFP -> ITP: mistune -- markdown parser in pure python
Hi, Le 03/05/2015 09:12, Julien Puydt a écrit : Le 02/05/2015 20:30, Julien Puydt a écrit : I'm willing to work on packaging it. I'm not part of the debian python modules team yet, but I'm willing to. I'm part of the debian-science team already, so I do have some experience packaging for debian. I made a tentative package using git like for my debian-science packages, even though the policy says otherwise : as there is an ingoing migration, that shouldn't be a problem. I have set the DPMT as maintainer and myself as uploader, which should ensure it will end up on my QA page where I'm already used to check for news. Shall I put my would-be package on git.debian.org, inside /git/python-modules/packages/ [of course using the setup-repository script in /git/python-modules/ -- again something in common with the debian-science workflow] ? If nobody is against it, I'll put it there in a few days. Snark on #debian-python -- 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/554af3d4.30...@laposte.net
Re: Re: RFP -> ITP: mistune -- markdown parser in pure python
Hi, Le 03/05/2015 11:20, Julien Puydt a écrit : Le 02/05/2015 20:30, Julien Puydt a écrit : I'm willing to work on packaging it. I'm not part of the debian python modules team yet, but I'm willing to. My login is jpuydt-guest and my name is Julien Puydt, by the way... Can I join that team? Or should I just make a tarball of the debian/ directory I have and let someone else take care of everything? Snark on #debian-python and #debian-science -- 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/554f27da.9030...@laposte.net
[DPMT] I would like to join the team
Hi, I would like to join the Debian Python Modules Team. I already have an account on alioth (jpuydt-guest) and I already maintain a few packages under the debian-science team umbrella. I have made a package for mistune (a new dep in ipython 3) (bug #779472), and contributed the necessary patches to update tornado to latest upstream (bug #779035). Thanks, Snark on #debian-python and #debian-science -- 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/5550da92.60...@laposte.net
Re: Re: RFP -> ITP: mistune -- markdown parser in pure python
Le 19/05/2015 23:16, Piotr Ożarowski a écrit : [Julien Puydt, 2015-05-10] Can I join that team? sure, welcome :) Thanks! Snark on #debian-python and #debian-science -- 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/555c333a.8000...@laposte.net
RFS: mistune -- Markdown parser in pure Python
Hi, I have now made my package for mistune in the python-modules/ directory on alioth. I used git like for my debian-science packages, since this team's policy is moving in that direction too. Mistune is a fast markdown parser in pure Python, and is a required dep of ipython 3/jupyter, which was a motivation to package it. Some other trivia : Homepage: https://github.com/lepture/mistune Vcs-Git: git://anonscm.debian.org/python-modules/packages/mistune.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=python-modules/packages/mistune.git Copyright: 2014-2015 Hsiaoming Yang License: BSD-3-clause I need someone to mentor me on this first DPMT package, and if things look neat enough, sponsor an upload to unstable. Thanks, Snark on #debian-python and #debian-science -- 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/555c34c6.4090...@laposte.net
RFS: python-tornado -- scalable, non-blocking web server and tools
Hi, this package already exists in debian ; in fact, the DPMT's svn had 3.2.2-1, debian had 3.2.2-1.1 (a NMU for a *team* package... strange idea), upstream has put 4.1.0 out with 4.2.0 to come [4.2.0.b1 is out, so it's still interesting to work on 4.1.0]. I did the following : - I pushed the changes from 3.2.2-1.1 in DPMT's svn repository ; - I updated the DPMT's svn repository for a 4.1.0-1 : (-) removed outdated patches ; (-) refreshed old patches ; (-) added a patch so we use debian's ca-certificates (instead of a new dep on a certifi package which looks for them around) (-) pushed standards-version up (-) add ca-certificates as a build-dep so tests pass at build-time (-) add myself to uploaders so it's not an NMU (I'm now part of the team, thanks!) (-) updated d/ch to document the above. Hopefully that didn't break anything... Now I need someone to mentor the changes since I'm not an old-timer in DPMT and a sponsor for an upload. Thanks, Snark on #debian-python and #debian-science -- 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/555ca5d9.4000...@laposte.net
Re: RFS: mistune -- Markdown parser in pure Python
Hi, On Wed, May 20, 2015 at 09:16:22AM +0200, Julien Puydt wrote: > Hi, > > I have now made my package for mistune in the python-modules/ directory on > alioth. I used git like for my debian-science packages, since this team's > policy is moving in that direction too. > > Mistune is a fast markdown parser in pure Python, and is a required dep of > ipython 3/jupyter, which was a motivation to package it. > > Some other trivia : > > Homepage: https://github.com/lepture/mistune > Vcs-Git: git://anonscm.debian.org/python-modules/packages/mistune.git > Vcs-Browser: > http://anonscm.debian.org/gitweb/?p=python-modules/packages/mistune.git > Copyright: 2014-2015 Hsiaoming Yang > License: BSD-3-clause > > > I need someone to mentor me on this first DPMT package, and if things look > neat enough, sponsor an upload to unstable. > > Thanks, > > Snark on #debian-python and #debian-science > > This is still current. Snark on #debian-python and #debian-science -- 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/20150526100334.GB14677@cauchy.localdomain
Re: RFS: python-tornado -- scalable, non-blocking web server and tools
On Wed, May 20, 2015 at 05:18:49PM +0200, Julien Puydt wrote: > Hi, > > this package already exists in debian ; in fact, the DPMT's svn had 3.2.2-1, > debian had 3.2.2-1.1 (a NMU for a *team* package... strange idea), upstream > has put 4.1.0 out with 4.2.0 to come [4.2.0.b1 is out, so it's still > interesting to work on 4.1.0]. > > I did the following : > - I pushed the changes from 3.2.2-1.1 in DPMT's svn repository ; > - I updated the DPMT's svn repository for a 4.1.0-1 : > (-) removed outdated patches ; > (-) refreshed old patches ; > (-) added a patch so we use debian's ca-certificates (instead of a new dep > on a certifi package which looks for them around) > (-) pushed standards-version up > (-) add ca-certificates as a build-dep so tests pass at build-time > (-) add myself to uploaders so it's not an NMU (I'm now part of the team, > thanks!) > (-) updated d/ch to document the above. > > Hopefully that didn't break anything... > > Now I need someone to mentor the changes since I'm not an old-timer in DPMT > and a sponsor for an upload. > > Thanks, > > Snark on #debian-python and #debian-science > > This is still current. Snark on #debian-science and #debian-python -- 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/20150526100415.GC14677@cauchy.localdomain
RFS: ptyprocess -- Run a subprocess in a pseudo terminal from Python
* Package name : ptyprocess Version: 0.5 Upstream author: Thomas Kluyver * URL: https://github.com/pexpect/ptyprocess License: ISC Description: Run a subprocess in a pseudo terminal in Python Launch a subprocess in a pseudo terminal (pty), and interact with both the process and its pty. Sometimes, piping stdin and stdout is not enough. There might be a password prompt that doesn't read from stdin, output that changes when it's going to a pipe rather than a terminal, or curses-style interfaces that rely on a terminal. If you need to automate these things, running the process in a pseudo terminal (pty) is the answer. It is a dependency for terminado (RFP #787201), on which ipython's newer version (#780408) depends in its turn for its notebook. I have a package ready for review at the usual place: Vcs-Git: git://anonscm.debian.org/python-modules/packages/ptyprocess.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=python-modules/packages/ptyprocess.git Snark on #debian-python -- 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/20150603184015.GA6986@cauchy.localdomain
Re: RFS: ptyprocess -- Run a subprocess in a pseudo terminal from Python
Hi, Le 03/06/2015 20:40, Julien Puydt a écrit : * Package name : ptyprocess Version: 0.5 Upstream author: Thomas Kluyver * URL: https://github.com/pexpect/ptyprocess License: ISC Description: Run a subprocess in a pseudo terminal in Python Launch a subprocess in a pseudo terminal (pty), and interact with both the process and its pty. Sometimes, piping stdin and stdout is not enough. There might be a password prompt that doesn't read from stdin, output that changes when it's going to a pipe rather than a terminal, or curses-style interfaces that rely on a terminal. If you need to automate these things, running the process in a pseudo terminal (pty) is the answer. It is a dependency for terminado (RFP #787201), on which ipython's newer version (#780408) depends in its turn for its notebook. I have a package ready for review at the usual place: Vcs-Git: git://anonscm.debian.org/python-modules/packages/ptyprocess.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=python-modules/packages/ptyprocess.git Still current, Snark on #debian-python -- 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/557afd42.7080...@laposte.net
Re: RFS: python-tornado -- scalable, non-blocking web server and tools
Hi, Le 20/05/2015 17:18, Julien Puydt a écrit : this package already exists in debian ; in fact, the DPMT's svn had 3.2.2-1, debian had 3.2.2-1.1 (a NMU for a *team* package... strange idea), upstream has put 4.1.0 out with 4.2.0 to come [4.2.0.b1 is out, so it's still interesting to work on 4.1.0]. I did the following : - I pushed the changes from 3.2.2-1.1 in DPMT's svn repository ; - I updated the DPMT's svn repository for a 4.1.0-1 : (-) removed outdated patches ; (-) refreshed old patches ; (-) added a patch so we use debian's ca-certificates (instead of a new dep on a certifi package which looks for them around) (-) pushed standards-version up (-) add ca-certificates as a build-dep so tests pass at build-time (-) add myself to uploaders so it's not an NMU (I'm now part of the team, thanks!) (-) updated d/ch to document the above. Hopefully that didn't break anything... Now I need someone to mentor the changes since I'm not an old-timer in DPMT and a sponsor for an upload. Still current, Snark on #debian-python -- 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/557afd84.7040...@laposte.net
Re: RFS: mistune -- Markdown parser in pure Python
Hi, Le 20/05/2015 09:16, Julien Puydt a écrit : I have now made my package for mistune in the python-modules/ directory on alioth. I used git like for my debian-science packages, since this team's policy is moving in that direction too. Mistune is a fast markdown parser in pure Python, and is a required dep of ipython 3/jupyter, which was a motivation to package it. Some other trivia : Homepage: https://github.com/lepture/mistune Vcs-Git: git://anonscm.debian.org/python-modules/packages/mistune.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=python-modules/packages/mistune.git Copyright: 2014-2015 Hsiaoming Yang License: BSD-3-clause I need someone to mentor me on this first DPMT package, and if things look neat enough, sponsor an upload to unstable. This is still current. Snark on #debian-python -- 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/557afddb.3080...@laposte.net
Re: Help needed for broken clean target of python module
Hi,
Le 22/06/2015 21:20, Andreas Tille a écrit :
File
"/home/andreas/debian-maintain/alioth/debian-med_git/build-area/python-dendropy-4.0.2/dendropy/utility/textprocessing.py",
line 44, in bytes_to_text
s = codecs.decode(s, ENCODING)
TypeError: must be string, not None
>>> codecs.decode(None, 'UTF8')
TypeError: must be string or buffer, not None
>>> codecs.decode('string', None)
TypeError: must be string, not None
I'm sure ENCODING isn't set!
Snark on #debian-python
--
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/5589013f.2080...@laposte.net
RFS: terminado -- a tornado websocket backend for the term.js javascript terminal emulator library
Hi, * Package name: python-terminado Version : 0.5 Upstream author : Thomas Kluyver * URL : https://github.com/takluyver/terminado License : BSD Description : a tornado websocket backend for the term.js javascript terminal emulator library It's one of the deps for the new ipython 3 ; I prepared a package, for review & sponsoring here : ssh://git.debian.org/git/python-modules/packages/terminado.git Thanks, Snark on #debian-python
Re: RFS: terminado -- a tornado websocket backend for the term.js javascript terminal emulator library
Hi, On 21/08/2015 10:42, Vincent Cheng wrote: Hi Julien, On Fri, Aug 14, 2015 at 8:41 AM, Julien Puydt wrote: Hi, * Package name: python-terminado Version : 0.5 Upstream author : Thomas Kluyver * URL : https://github.com/takluyver/terminado License : BSD Description : a tornado websocket backend for the term.js javascript terminal emulator library It's one of the deps for the new ipython 3 ; I prepared a package, for review & sponsoring here : ssh://git.debian.org/git/python-modules/packages/terminado.git The upstream contents of your git repo isn't identical to the tarball I fetched with uscan --download-current-version. Uh... and I "diff -urN" both trees and they're not identical!? I just updated my package, but it's puzzling... would upstream have updated the tarball under my feet ? Also, d/rules seems to include some unused variables (PYVERS and PY3VERS)? Ok, removed. I haven't been keeping up with the list recently...have we already migrated to git, or are we already allowed to use git repos for packaging? As far as I know it's ok to use git for new packages, and the migration of old packages is pending. Snark on #debian-python
Re: RFS: terminado -- a tornado websocket backend for the term.js javascript terminal emulator library
On 22/08/2015 04:26, Vincent Cheng wrote: On Fri, Aug 21, 2015 at 12:25 PM, Julien Puydt wrote: Hi, On 21/08/2015 10:42, Vincent Cheng wrote: Hi Julien, On Fri, Aug 14, 2015 at 8:41 AM, Julien Puydt wrote: Hi, * Package name: python-terminado Version : 0.5 Upstream author : Thomas Kluyver * URL : https://github.com/takluyver/terminado License : BSD Description : a tornado websocket backend for the term.js javascript terminal emulator library It's one of the deps for the new ipython 3 ; I prepared a package, for review & sponsoring here : ssh://git.debian.org/git/python-modules/packages/terminado.git The upstream contents of your git repo isn't identical to the tarball I fetched with uscan --download-current-version. Uh... and I "diff -urN" both trees and they're not identical!? I just updated my package, but it's puzzling... would upstream have updated the tarball under my feet ? Another possibility is that you may have actually imported terminado from github instead of pypi. Either way, please ensure that your orig tarball matches up with whatever uscan spits out for future uploads. The tarball should contain the same code wherever I get it from... anyway, I'll indeed use the sources corresponding to the d/watch for later packages. Uploaded to NEW, thanks! Thanks! Snark on #debian-python
RFS: setuptools_scm -- blessed package to manage your versions by scm tags for Python
Hi, the following ITP is now an RFS ; the package is available from here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/setuptools-scm.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/setuptools-scm.git Thanks, Snark on #debian-python Message transféré Sujet : ITP: setuptools_scm -- blessed package to manage your versions by scm tags for Python Date : Thu, 3 Sep 2015 18:18:16 +0200 De : Julien Puydt Pour : sub...@bugs.debian.org Copie à : python-modules-t...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Julien Puydt * Package name: setuptools-scm Version : 1.7.0 Upstream Author : Ronny Pfannschmidt * URL : https://github.com/pypa/setuptools_scm * License : Expat Programming Lang: Python Description : blessed package to manage your versions by scm tags for Python setuptools_scm handles managing your Python package versions in scm metadata. It also handles file finders for the suppertes scm's. The newest ipython depends on pickleshare, which depends on path.py, which depends on this package. I'll maintain this package within the Debian Python Modules Team. Thanks, Snark on #debian-python
ITP: pickleshare -- File system based database that uses Python pickles
Package: wnpp Severity: wishlist Owner: Julien Puydt * Package name: pickleshare Version : 0.5 Upstream Author : Ville Vainio * URL : https://github.com/pickleshare/pickleshare * License : Expat Programming Lang: Python Description : File system based database that uses Python pickles Like shelve, a PickleShareDB object acts like a normal dictionary. Unlike shelve, many processes can access the database simultaneously. Changing a value in database is immediately visible to other processes accessing the same database. . Concurrency is possible because the values are stored in separate files. Hence the "database" is a directory where all files are governed by PickleShare. The newest ipython depends on this package. I'll maintain this package within the Debian Python Modules Team. Thanks, Snark on #debian-python
Re: RFS: setuptools_scm -- blessed package to manage your versions by scm tags for Python
Hi, Le 03/09/2015 20:17, Julien Puydt a écrit : Hi, the following ITP is now an RFS ; the package is available from here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/setuptools-scm.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/setuptools-scm.git Thanks, Snark on #debian-python Message transféré Sujet : ITP: setuptools_scm -- blessed package to manage your versions by scm tags for Python Date : Thu, 3 Sep 2015 18:18:16 +0200 De : Julien Puydt Pour : sub...@bugs.debian.org Copie à : python-modules-t...@lists.alioth.debian.org Package: wnpp Severity: wishlist Owner: Julien Puydt * Package name: setuptools-scm Version : 1.7.0 Upstream Author : Ronny Pfannschmidt * URL : https://github.com/pypa/setuptools_scm * License : Expat Programming Lang: Python Description : blessed package to manage your versions by scm tags for Python setuptools_scm handles managing your Python package versions in scm metadata. It also handles file finders for the suppertes scm's. The newest ipython depends on pickleshare, which depends on path.py, which depends on this package. I'll maintain this package within the Debian Python Modules Team. this is still current. Thanks, Snark on #debian-python
Bug#798785: ITP: ipython-genutils -- IPython vestigial utilities
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org Owner: Julien Puydt * Package name: ipython-genutils Version : 0.1.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/ipython_genutils * License : BSD-3-clause Programming Lang: Python Description : IPython vestigial utilities Contains some utilities shared by the IPython and Jupyter projects. . No new code should be written against those utilities. Although that code is (as made clear in the long description) not supposed to be used in new code, there is still code using it, and it's not going away soon, so it makes sense to package it (I asked upstream!). It is for example a dependency of 'traitlets', which is a dependency of the whole IPython/Jupyter software stack. Thanks, Snark on #debian-python
RFS: ipython-genutils -- IPython vestigial utilities
Hi, Le 12/09/2015 18:32, Julien Puydt a écrit : Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org Owner: Julien Puydt * Package name: ipython-genutils Version : 0.1.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/ipython_genutils * License : BSD-3-clause Programming Lang: Python Description : IPython vestigial utilities Contains some utilities shared by the IPython and Jupyter projects. . No new code should be written against those utilities. Although that code is (as made clear in the long description) not supposed to be used in new code, there is still code using it, and it's not going away soon, so it makes sense to package it (I asked upstream!). It is for example a dependency of 'traitlets', which is a dependency of the whole IPython/Jupyter software stack. The package is now available here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/ipython-genutils.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/ipython-genutils.git Thanks, Snark on #debian-python
Re: RFS: ipython-genutils -- IPython vestigial utilities
Hi, the following is still current. This time I also remember to add it to the DPMT: [] list in #debian-python's topic. Thanks, Snark on #debian-python Le 12/09/2015 18:46, Julien Puydt a écrit : Le 12/09/2015 18:32, Julien Puydt a écrit : Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org Owner: Julien Puydt * Package name: ipython-genutils Version : 0.1.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/ipython_genutils * License : BSD-3-clause Programming Lang: Python Description : IPython vestigial utilities Contains some utilities shared by the IPython and Jupyter projects. . No new code should be written against those utilities. Although that code is (as made clear in the long description) not supposed to be used in new code, there is still code using it, and it's not going away soon, so it makes sense to package it (I asked upstream!). It is for example a dependency of 'traitlets', which is a dependency of the whole IPython/Jupyter software stack. The package is now available here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/ipython-genutils.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/ipython-genutils.git Thanks, Snark on #debian-python
Bug#799242: ITP: traitlets -- Lightweight Traits-like package
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-python@lists.debian.org * Package name: traitlets Version : 4.0.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/traitlets * License : BSD-3-clause Programming Lang: Python Description : Lightweight Traits-like package A lightweight pure-Python derivative of Enthought Traits, used for configuring Python objects. . It powers the config system of IPython and Jupyter. It depends on ipython-genutils, but I already have a RFS on that one. Cheers, Snark on #debian-python
RFS: path.py -- module wrapper for os.path
Hi, I'm looking for a sponsor for: * Package name: path.py Version : 8.1 Upstream Author : Mikhail Gusarov * URL : https://github.com/jaraco/path.py * License : Expat Programming Lang: Python Description : A module wrapper for os.path path.py implements a path objects as first-class entities, allowing common operations on files to be invoked on those path objects directly. The newest ipython depends on pickleshare, which depends on this package. I'll maintain it within the Debian Python Modules Team : Vcs-Git: git://anonscm.debian.org/python-modules/packages/path.py.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/path.py.git Thanks, Snark on #debian-python
Re: RFS: ipython-genutils -- IPython vestigial utilities
Le jeudi 17 sept. 2015 à 21:07:56 (+), Tristan Seligmann a écrit : > On Sat, 12 Sep 2015 at 18:46 Julien Puydt wrote: > > > The package is now available here: > > Vcs-Git: > > git://anonscm.debian.org/python-modules/packages/ipython-genutils.git > > Vcs-Browser > > <http://anonscm.debian.org/python-modules/packages/ipython-genutils.gitVcs-Browser> > > : > > http://anonscm.debian.org/cgit/python-modules/packages/ipython-genutils.git > > > > Uploaded and tagged. Thanks!
Re: RFS: path.py -- module wrapper for os.path
Le jeudi 17 sept. 2015 à 21:03:20 (+), Tristan Seligmann a écrit : > On Thu, 17 Sep 2015 at 16:11 Julien Puydt wrote: > > > Hi, > > > > I'm looking for a sponsor for: > > > > * Package name: path.py > > > > Uploaded and tagged. Thanks! Snark on #debian-python
Packaging the Jupyter project suite
Hi, I would like to package the Jupyter suite of software (ex-IPython). Of course, that makes quite a few packages to prepare, with a big dependency graph. I already sent a few ITP (pickleshare, traitlets), a few RFS (path.py), some are in NEW (ipython-genutils)... What is annoying is that some of the packages have a dependency chain going in some way, and an extra dependency chain going the other way. For a concrete example, ipykernel depends on ipython... but ipython has an extra-dep on ipykernel. How does one package something like this? Does someone want to lend a hand? Thanks, Snark on #debian-python
Re: Packaging the Jupyter project suite
Hi, Le vendredi 18 sept. 2015 à 14:52:53 (-0700), Thomas Kluyver a écrit : > On Fri, Sep 18, 2015, at 08:49 AM, Julien Puydt wrote: > > What is annoying is that some of the packages have a dependency chain > > going in some way, and an extra dependency chain going the other way. > > For a concrete example, ipykernel depends on ipython... but ipython has > > an extra-dep on ipykernel. > > The extra deps in IPython are for backwards compatibility, so that if > people have scripted (or remembered) commands like "pip install > ipython[notebook]", they will continue to work, by pulling in the > separated package which now contains that functionality. In time we will > probably remove these. That is very comforting! > I'd recommend that you ignore these compatibility dependencies (that is, > all the extra dependency groups of IPython besides doc and test). Of those only testpath looks problematic (I filled an issue on it yesterday), so the future looks quite bright. Thanks, Snark on #debian-python
Dealing with flit -- a simplified packaging of python modules
Hi, here is a new way to package modules for Python: https://github.com/takluyver/flit It means that something packaged using it doesn't use a setup.py or some such, but a flit.ini ; see for example: https://github.com/jupyter/testpath I'm not sure how to package something like this (and testpath is a depends for IPython's tests), so I think asking here is better. Snark on #debian-python
Re: Dealing with flit -- a simplified packaging of python modules
Hi, Le samedi 19 sept. 2015 à 00:35:49 (-0700), Thomas Kluyver a écrit : > On Fri, Sep 18, 2015, at 11:56 PM, Julien Puydt wrote: > > here is a new way to package modules for Python: > > https://github.com/takluyver/flit > > > > It means that something packaged using it doesn't use a setup.py or some > > such, but a flit.ini ; see for example: > > https://github.com/jupyter/testpath > > > > I'm not sure how to package something like this (and testpath is a > > depends for IPython's tests), so I think asking here is better. > > By the way, I am also upstream for flit, and I'm prepared to help build > some tooling to use it for distro packaging. I know it will cause some > inconvenience in the short term because there's infrastructure around > setup.py packaging, but ultimately I think that having declarative > metadata should be an advantage. > > Thomas > Yes, you're also upstream for ptyprocess and terminado :-P I have nothing against declarative -- it's just that I suspect we will need something like a --buildsystem=flit or some such, and I have no clue how to do something like this... Snark on #debian-python
RFS: traitlets -- Lightweight Traits-like package
Hi, * Package name: traitlets Version : 4.0.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/traitlets * License : BSD-3-clause Programming Lang: Python Description : Lightweight Traits-like package A lightweight pure-Python derivative of Enthought Traits, used for configuring Python objects. . It powers the config system of IPython and Jupyter. It is one of the last depends before the newer IPython can be packaged (there is still testpath). Cheers, Snark on #debian-python
Re: RFS: traitlets -- Lightweight Traits-like package
Hi, Le samedi 19 sept. 2015 à 15:29:09 (+0200), Julien Puydt a écrit : > Hi, > > * Package name: traitlets > Version : 4.0.0 > Upstream Author : IPython Development Team > * URL : https://github.com/ipython/traitlets > * License : BSD-3-clause > Programming Lang: Python > Description : Lightweight Traits-like package > A lightweight pure-Python derivative of Enthought Traits, used > for configuring Python objects. > . > It powers the config system of IPython and Jupyter. > > It is one of the last depends before the newer IPython can be packaged > (there is still testpath). > I forgot to mention that I packaged it here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/traitlets.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/traitlets.git Snark on #debian-python
Bug#799470: ITP: jupyter-core -- Core common functionality of Jupyter projects
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: jupyter-core Version : 4.0.6 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_core * License : BSD-3-clause Programming Lang: Python Description : Core common functionality of Jupyter projects This package contains the base framework (application classes and configurations) for the rest of the Jupyter projects ; it doesn't do much by itself. Cheers, Snark on #debian-python
Bug#799599: ITP: testpath -- Collection of utilities for Python code working with files and commands
Package: wnpp Owner: Julien Puydt Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: testpath Version : 0.2 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/testpath * License : MIT Programming Lang: Python Description : Collection of utilities for Python code working with files and commands It contains functions to check things on the filesystem, and tools for mocking system commands and recording calls to those. It is a test-dependency of IPython. Snark on #debian-python
RFS: testpath -- Utilities for Python code working with files and commands
Hi, I finished packaging testpath, whose ITP is #799599 : * Package name: testpath Version : 0.2 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/testpath * License : MIT Programming Lang: Python Description : Collection of utilities for Python code working with files and commands It contains functions to check things on the filesystem, and tools for mocking system commands and recording calls to those. It is a test-dependency of IPython. Here it is: Vcs-Git: git://anonscm.debian.org/python-modules/packages/testpath.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/testpath.git Now I would need a sponsor, please :-) Thanks, Snark on #debian-python
Re: Packaging the Jupyter project suite
Hi, Le 19/09/2015 07:44, Stuart Prescott a écrit : thanks for looking at Jupyter notebooks for us! No problem. Remember that ipython is already in Debian and already has an active maintainer (Julian Taylor). He might already have started work on jupyter too since he may well feel that it's already his responsibility to continue maintaining it. In any case, I would encourage you to reach out to him to see if you can work together on this venture. I suspect that Jupyter is one of those packages where the more people working on it the better as it looks like it's going to be a lot of hard work. I wrote to him some days ago -- but I fear he isn't that active with IPython these days... It shouldn't be that much hard work... but then I've been trying to package sagemath in the debian-science team since something like two or three years, so maybe I'm spoilt. Still, some help would be nice (mentoring, sponsoring -- or even packaging some parts!) Snark on #debian-python
Re: Packaging the Jupyter project suite
Hi, Le 18/09/2015 17:49, Julien Puydt a écrit : I would like to package the Jupyter suite of software (ex-IPython). Of course, that makes quite a few packages to prepare, with a big dependency graph. I already sent a few ITP (pickleshare, traitlets), a few RFS (path.py), some are in NEW (ipython-genutils)... What is annoying is that some of the packages have a dependency chain going in some way, and an extra dependency chain going the other way. For a concrete example, ipykernel depends on ipython... but ipython has an extra-dep on ipykernel. How does one package something like this? Does someone want to lend a hand? Ok, my current plan is : (1) wait until path.py out of NEW ; (2) wait to see testpath and traitlets in NEW (I sent two RFS) ; (3) pickleshare is waiting for path.py (I shall then RFS, the package is ready in the team git repository) ; (4) that will open the way for an updated ipython (the only "old" package) ; (5) that will open the way for jupyter-core (I sent an ITP, I have a prospective package in a local git repository... it needs ipython) ; (6) this will open the way to jupyter-client and nbformat (all untouched) ; (7) this will open the way to ipykernel (untouched) ; (8) this will open the way to nbconvert, ipyparallel and qtconsole (all untouched) (9) this will open the way to notebook (untouched) (10) this will open the way to ipywidgets (untouched) And then, I think Debian will have everything sagemath needs from the Jupyter project -- but perhaps others will want more of it. As you see it is a short ten-steps plan, with some parallelization possible in some places. I'm mostly stuck by IPython for two reasons : (1) it already has a main maintainer [it's in the DPMT team umbrella though] and (2) it is in subversion, which I don't want to use anymore. Help would be appreciated (mentoring, sponsoring, packaging... anything!), Snark on #debian-python
Re: RFS: traitlets -- Lightweight Traits-like package
Hi, Le 19/09/2015 15:43, Julien Puydt a écrit : Hi, Le samedi 19 sept. 2015 à 15:29:09 (+0200), Julien Puydt a écrit : Hi, * Package name: traitlets Version : 4.0.0 Upstream Author : IPython Development Team * URL : https://github.com/ipython/traitlets * License : BSD-3-clause Programming Lang: Python Description : Lightweight Traits-like package A lightweight pure-Python derivative of Enthought Traits, used for configuring Python objects. . It powers the config system of IPython and Jupyter. It is one of the last depends before the newer IPython can be packaged (there is still testpath). I forgot to mention that I packaged it here: Vcs-Git: git://anonscm.debian.org/python-modules/packages/traitlets.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/traitlets.git The RFS is still live. Should I try through mentors.d.n ? Snark on #debian-python
Re: RFS: testpath -- Utilities for Python code working with files and commands
Hi, Le 20/09/2015 22:08, Julien Puydt a écrit : Hi, I finished packaging testpath, whose ITP is #799599 : * Package name: testpath Version : 0.2 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/testpath * License : MIT Programming Lang: Python Description : Collection of utilities for Python code working with files and commands It contains functions to check things on the filesystem, and tools for mocking system commands and recording calls to those. It is a test-dependency of IPython. Here it is: Vcs-Git: git://anonscm.debian.org/python-modules/packages/testpath.git Vcs-Browser: http://anonscm.debian.org/cgit/python-modules/packages/testpath.git Now I would need a sponsor, please :-) The RFS is still live. Should I try through mentors.d.n ? Snark on #debian-python
Re: Packaging the Jupyter project suite
Hi, Le 18/09/2015 17:49, Julien Puydt a écrit : I would like to package the Jupyter suite of software (ex-IPython). Someone asked on IRC if Jupyter was a fork of IPython : no, it's the same upstream, who broke it (or modularized it if you prefer) into chunks, under the "Jupyter project" umbrella. Of course, that makes quite a few packages to prepare, with a big dependency graph. I already sent a few ITP (pickleshare, traitlets), a few RFS (path.py), some are in NEW (ipython-genutils)... There is also something else to discuss since it used to be only IPython : how to transition. Indeed, the current src:ipython package provides several binary packages: ipython (shell for Python 2), ipython3 (shell for Python 3), ipython-qtconsole (Qt shell for Python 2), ipython3-qtconsole (Qt shell for Python 3), ipython-notebook-common (data for the HTML IPython notebook), ipython-notebook (HTML IPython notebook for Python 2), ipython3-notebook (HTML IPython notebook for Python 3) and ipython-doc (documentation). But now, IPython upstream contains (afaik) what used to be in ipython and ipython3. There is an upstream qtconsole which should correspond to ipython-qtconsole and ipython3-qtconsole. And there is an upstream notebook which should correspond to ipython-notebook-common, ipython-notebook and ipython3-notebook. So, how does one do so users of those packages get the future new ones (I'm sure a transition bug to release.debian.org will be needed)? What does one do to the bugs in the current src:ipython package? Snark on #debian-python PS: I still have a path.py stuck in NEW, and traitlets and testpath in RFS.
Re: Packaging the Jupyter project suite
Hi,
Le 25/09/2015 14:00, Julien Cristau a écrit :
Hi Julien,
On Fri, Sep 25, 2015 at 07:48:30 +0200, Julien Puydt wrote:
There is also something else to discuss since it used to be only IPython :
how to transition.
Indeed, the current src:ipython package provides several binary packages:
ipython (shell for Python 2), ipython3 (shell for Python 3),
ipython-qtconsole (Qt shell for Python 2), ipython3-qtconsole (Qt shell for
Python 3), ipython-notebook-common (data for the HTML IPython notebook),
ipython-notebook (HTML IPython notebook for Python 2), ipython3-notebook
(HTML IPython notebook for Python 3) and ipython-doc (documentation).
But now, IPython upstream contains (afaik) what used to be in ipython and
ipython3. There is an upstream qtconsole which should correspond to
ipython-qtconsole and ipython3-qtconsole. And there is an upstream notebook
which should correspond to ipython-notebook-common, ipython-notebook and
ipython3-notebook.
So, how does one do so users of those packages get the future new ones
The future qtconsole or jupyter-qtconsole source package will likely
have to build transitional ipython-qtconsole and ipython3-qtconsole
packages so user systems get upgraded. Likewise, the future
jupyter-notebook package should probably build transitional
ipython{,3}-notebook packages.
Ok, though I think the src:notebook package should perhaps build
python-notebook and python3-notebook packages, as there's probably no
point to have ipython in the package name.
(I'm sure a transition bug to release.debian.org will be needed)?
I don't believe so.
I'll need to read about transitional packages...
What does one do to the bugs in the current src:ipython package?
The ones that are still relevant can be marked as found in the jupyter
packages as well, or reassigned, I don't think that's an issue.
Good (though determining which of them are still current might not be
that simple).
Thanks,
Snark on #debian-python
How does python:Depends work?
Hi, I'm wondering how the python:Depends substitution actually works, since it looks like it doesn't in some of my recent packages : what was I supposed to do that I didn't? Thanks, Snark on #debian-python
Re: How does python:Depends work?
Hi, Le 28/09/2015 09:44, Julien Puydt a écrit : I'm wondering how the python:Depends substitution actually works, since it looks like it doesn't in some of my recent packages : what was I supposed to do that I didn't? The reason why it wasn't working, was that in setup.py, setuptools was activated only conditionally. That in itself isn't a problem. But when not activated (hence using distutils), it was feeding setuptools' setup arguments to distutils' setup. And that is quite wrong, because what is "install_requires" for one is "requires" for the other! So the solution was just : -install_requires = setuptools_args['install_requires'] = [ +setup_args['requires'] = setuptools_args['install_requires'] = [ which I put in a proper Debian patch, and forwarded upstream (which was traitlets... part of the Jupyter project where I'm sure I'll have to report the same for at least half of the packages!). Thanks, Snark on #debian-python
Bug#800404: ITP: nbformat -- Jupyter notebook formats
Package: wnpp Owner: Julien Puydt Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: nbformat Version : 4.0.0 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/nbformat * License : BSD-3-clause Programming Lang: Python Description : Jupyter notebook format This software component contains the reference implementation of the Jupyter notebook format, and Python APIs to work with notebooks. It is part of the Jupyter project, which is a modular rewrite of IPython. I'm interested in maintaining it within the Debian Python Modules Team. Cheers, Snark on #debian-python
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Hi, Le mardi 29 sept. 2015 à 09:48:16 (-0400), Barry Warsaw a écrit : > On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote: > > >Once again, the python policy about Maintainer/Uploaders has been ignored > > > >either policy changes or this has to stop at some point. > > A few observations. > > The policy should perhaps be better promoted or more explicitly written. The > links you provided are useful, but I wonder whether they are easily > overlooked, forgotten, or misinterpreted. > > Policy doesn't really spell out the operational differences for when the team > is Maintainer vs. Uploader, and the wiki page explicitly says it's an > *unwritten* policy (despite the fact that putting it in the wiki probably > qualifies as "written" :). How should the change be acknowledged by the > maintainer? Should I Cc the mailing list when I contact the maintainer? Is > it okay to commit to vcs but not upload? How long do you wait for feedback > before you can do the upload? I'm just a DM, but I'm still in the team, so I think I can state my opinion, and explain how I would do things. First thing, report a bug on the package (request for a new version, for example). Wait. Provide patches. Wait. Second, contact the maintainer off list&bug. Wait. Third, contact the list and put the maintainer in CC, stating that things don't get further fast enough and you would like the team to get involved. Wait. Fourth, if the maintainer hasn't answered, then proceed with an RFS or upload (depending on whether one is DD or DM). > (Aside: git! I would love to be able to commit and push a branch and then ask > for the maintainer to review, merge, and upload - or give me the green light > to go ahead.) I create all my packages in git -- that's what the debian-science team uses. And I consider the fact that a package is subversion-maintained a hindrance. > Should we have some automated tools to help out here? I'm not sure where to > hook in such a tool, but if for example when I build a source package, I got a > nice little lintian-like warning saying "The package is team uploadable but > not team maintained, did you give the maintainer time to respond to your > issue?" Something like that would go a long way toward mitigating accidental > or careless toe-stepping. Oh dear, another lintian output to bother me! And don't call that a "warning", some sensitive people prefer the word "tag" :-P > Do all team members understand the implications when they set the two fields? > Some maintainers may not really care and may have been less conscientious > about setting the fields. I definitely didn't really understand the implications. I put the DPMT as maintainer and myself as uploader because : - I want lintian not to bug me about NMU ; - I want to make clear I won't consider people are stepping on my toes if they start helping with a package. Cheers, Snark on #debian-python
Re: Suggestion for recommended build tools a python application
Hi, Le mercredi 30 sept. 2015 à 00:17:32 (+0600), Titon Barua a écrit : > I found some online resource where someone suggested using autotools for > building GTK+python applications. I can definitely go that route, but how > would it affect packaging for debian? How am I supposed to specify the > python module dependencies? With autotools, you can check python deps using the AC_CHECK_PYTHON_MODULE macro, which you can for example find here: http://anonscm.debian.org/cgit/debian-science/packages/sagemath.git/tree/debian/pruner/m4/python_module.m4 Snark on #debian-python
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
Le mardi 29 sept. 2015 à 20:40:11 (+0200), Piotr Ożarowski a écrit : > [Barry Warsaw, 2015-09-29] > > On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote: > > > > >- I want lintian not to bug me about NMU ; > > > > This one's easy. Just put "Team upload" in the changelog (e.g. `dch > > --team`). > > it's even easier than that... add yourself to Uploaders (you're > maintaining it after all!) Yes, that's what I said: I put myself as uploaders so lintian doesn't bug me about NMU. Snark on #debian-python
Re: lintian and team uploads
Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit : > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote: > > >(and remember to remove DPMT from debian/control if it's not in SVN ;P) > > Given that the final git migration is imminent (really! otherwise I'm going to > scream ;), can we not force people to go through this churn right now? Indeed, I find that offensive : if git is a better tool than subversion, and if it's going to be used, what's the point? > Yes, let's discourage any new packages from manually migrating or starting out > in git just until flag day. But I'm not sure it's worth removing DPMT on > existing repos just to add it back, hopefully RSN. I would like to make some points clear: 1. I wouldn't have contributed a single package in subversion, as it's just too cumbersome to use. I liked svn when it replaced cvs, but not so much since I started using git. 2. When I saw the DPMT policy mentioned only subversion, I asked around (can't remember if it was just on IRC or on this ml) and was told it was ok to use git since the migration was bound to happen sooner or later. 3. Afterwards, being just a DM, I sent RFS mails through this very list in which I generally gave the Vcs-* fields from the d/control files, which clearly showed I used git : no complaint about it. 4. Those package got sponsored without complaint about it either. So you'll understand that getting flames (even with smileys) about it now is quite annoying. I still have a series of things I plan to package for Debian ; those are Python Modules, and I'll use git. If that's a problem for the Debian Python Modules Team, can you point me to a more appropriate team? Snark on #debian-python
RFS updating the setuptools-scm and mistune packages
Hi, I made the following changes to both setuptools-scm and mistune : * New upstream release. * Switch maintainership from DPMT to myself. Those packages both have their previous versions in testing+unstable. They are available from here: ssh://git.debian.org/git/python-modules/packages/mistune.git ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git (I didn't tag & dch -r in case a sponsor finds something to change) Thanks, Snark on #debian-python
Re: RFS updating the setuptools-scm and mistune packages
Le vendredi 02 oct. 2015 à 11:23:57 (+), Tristan Seligmann a écrit : > On Wed, 30 Sep 2015 at 13:55 Julien Puydt wrote: > > > ssh://git.debian.org/git/python-modules/packages/mistune.git > > ssh://git.debian.org/git/python-modules/packages/setuptools-scm.git > > > > Uploaded. Thanks! Snark on #debian-python
Bug#800903: ITP: jupyter-client -- Jupyter protocol client APIs
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: jupyter-client Version : 4.0.0 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/jupyter_client * License : BSD-3-clause Programming Lang: Python Description : Jupyter protocol client APIs This package contains the reference implementation of the Jupyter protocol. It also provides client and kernel management APIs to work with kernels and the "jupyter kernelspec" entry point to install kernelspecs for use with Jupyter frontends. Cheers, Snark on #debian-python
Re: Git migration schedule
Hi, Le dimanche 04 oct. 2015 à 20:03:29 (+0100), Sandro Tosi a écrit : > am I the only one thinking it's quite a huge number to be handled by > hand? and whose hands will be the ones converting these packages? > yours or Barry's dont seem enough and others will need training/time. There's a point to be made here : as long as the team works on the credo that everything must be svn or everything must be git, nothing will bulge. It's a general principle : all or nothing hence nothing! Accept the transition won't be instantaneous and proceed by steps: - disallow creating new packages as subversion repositories ; - migrate now those packages for which the script works ; - the rest should follow at a reasonable pace, and in hand with the maintainers/uploaders/whoever feels responsible. Stop talking about doacracy and actually move! Snark on #debian-python
Bug#800936: ITP: ipykernl -- IPython kernel for Jupyter
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: ipykernel Version : 4.0.3 Upstream Author : Jupyter Development Team * URL : https://github.com/ipython/ipykernel * License : BSD-3-clause Programming Lang: Python Description : IPython kernel for Jupyter This software component provides an IPython kernel, which will hook itself into Jupyter. Cheers, Snark on #debian-python
How to convert a git repo to git-dpm
Hi, I would like to open a nice thread to discuss the "problem" of packages already managed in git, but not with git-dpm. To start the discussion, I'll describe how I did things and what I did to "convert" a repository. My usual way to use a repository is doing things like: gbp import-orig (when a new version comes out) gbp buildpackage -S [-us -uc | -kdebian] to get a source package and use quilt to manage my (rare) patches. Here is what I came up with for the transition: (1) copied patches elsewhere (/tmp/somewhere/, say) (2) git rm -r debian/patches && git commit -m "Remove old patch management" (3) git-dpm init ../foo_version.orig.tar.gz (start using git-dpm) (4) for each patch, use "git-dpm apply-patch" (5) git-dpm update-patches after that, git-dpm status seems happy. I hope this helps, Snark on #debian-python
Bug#801058: ITP: nbconvert -- Jupyter notebook conversion
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: nbconvert Version : 4.0.0 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/nbconvert * License : BSD-3-clause Programming Lang: Python Description : Jupyter notebook conversion Jupyter nbconvert converts notebooks to various other formats using Jinja templates. Cheers, Snark on #debian-python
Re: How to convert a git repo to git-dpm
Hi, Le 05/10/2015 20:27, Julien Puydt a écrit : (3) git-dpm init ../foo_version.orig.tar.gz (start using git-dpm) That point takes actually longer, because one needs to have the tarball around ; this is now wishlist bug #801086 against git-dpm ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801086 ) (4) for each patch, use "git-dpm apply-patch" This just means: git-dpm apply-patch /path/to/first_patch git-dpm apply-patch /path/to/second_patch ... git-dpm will turn each patch into a nice commit (provided those are good DEP3 patchs -- a good Description: and a good Author: ) I hope that helps, Snark on #debian-python
Bug#801366: ITP: notebook -- Jupyter interactive notebook
Package: wnpp Owner: Julien Puydt Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: notebook Version : 4.0.5 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/notebook * License : BSD-3-clause Programming Lang: Python Description : Jupyter interactive notebook The Jupyter HTML notebook is a web-based notebook environment for interactive computing. Snark on #debian-python
RFS: pickleshare -- File system based database that uses Python pickles
Hi, I'm looking for a sponsor for my package: * Package name:pickleshare Version: 0.5 Upstream author: Ville Vainio * URL: https://github.com/pickleshare/pickleshare * License: Expat Progr. lang.:Python Description: File system based database that uses Python pickles Like shelve, a PickleShareDB object acts like a normal dictionary. Unlike shelve, many processes can access the database simultaneously. Changing a value in database is immediately visible to other processes accessing the same database. . Concurrency is possible because the values are stored in separate files. Hence the "database" is a directory where all files are governed by PickleShare. This is a dependance of IPython/Jupyter ; it is available on mentors.debian.net : http://mentors.debian.net/package/pickleshare dget -x http://mentors.debian.net/debian/pool/main/p/pickleshare/pickleshare_0.5-1.dsc or in git: Vcs-Git: git://anonscm.debian.org/python-modules/packages/pickleshare.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/pickleshare.git Thanks, Snark on #debian-python
Re: Git migration schedule
Le mercredi 21 oct. 2015 à 23:28:47 (+0100), Sandro Tosi a écrit : > On Wed, Oct 21, 2015 at 11:01 PM, Brian May wrote: > > Maybe we should fix #801666 first and then revisit this question? > > git-dpm hasnt seen a single line changed since more than a year > (http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont hold > my breath on it :( > Do you know pristine-tar is orphaned ? (bug #737871) Snark on #debian-python
Re: Bug#802730: ITP: python-setuptools-scm -- Handles managing your python package versions in scm metadata.
Hi, Le 23/10/2015 00:46, Brian May a écrit : Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-setuptools-scm Version : 1.8.0 Upstream Author : Ronny Pfannschmidt * URL : https://github.com/pypa/setuptools_scm/ * License : MIT Programming Lang: Python 2 and Python 3 Description : Handles managing your python package versions in scm metadata. Handles managing your Python package versions in scm metadata instead of declaring them as the version argument or in a scm managed file. Required for pytest-django, which is required by djangorestframework. Will be packaged as part of the DPMT (Debian Python Modules Team). setuptools-scm (1.8.0-1) unstable; urgency=medium * New upstream release. * Put myself as sole maintainer. -- Julien Puydt Fri, 02 Oct 2015 11:02:33 +0200 setuptools-scm (1.7.0-1) unstable; urgency=medium * Initial release. (Closes: #797915) -- Julien Puydt Thu, 03 Sep 2015 10:08:15 +0200 Thanks Snark on #debian-python
Re: RFS: pickleshare -- File system based database that uses Python pickles
Hi, Le 16/10/2015 20:48, Julien Puydt a écrit : I'm looking for a sponsor for my package: * Package name:pickleshare Version: 0.5 Upstream author: Ville Vainio * URL: https://github.com/pickleshare/pickleshare * License: Expat Progr. lang.:Python Description: File system based database that uses Python pickles Like shelve, a PickleShareDB object acts like a normal dictionary. Unlike shelve, many processes can access the database simultaneously. Changing a value in database is immediately visible to other processes accessing the same database. . Concurrency is possible because the values are stored in separate files. Hence the "database" is a directory where all files are governed by PickleShare. This is a dependance of IPython/Jupyter ; it is available on mentors.debian.net : http://mentors.debian.net/package/pickleshare dget -x http://mentors.debian.net/debian/pool/main/p/pickleshare/pickleshare_0.5-1.dsc or in git: Vcs-Git: git://anonscm.debian.org/python-modules/packages/pickleshare.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/pickleshare.git This is still pending. Thanks, Snark on #debian-python
IPython: I would need some help/councels
Hi, I made a new version of my IPython packaging : http://mentors.debian.net/package/ipython and I asked Julian Taylor about it : he said I should try to push things without waiting for him. So here am I : I'm not asking for sponsorship of the package yet, but I would like to have some mentorship on it, as it is a delicate matter : - yes, it really is IPython ; - BUT the IPython project is now Jupyter, and what was once IPython has been split into many different packages, so my package is much, much simpler and contains much, much less than the previous one. - oh, and it's a depends of most of th rest... Thanks, Snark on #debian-python
Re: IPython: I would need some help/councels
Hi, Le 19/01/2016 22:17, Sandro Tosi a écrit : could you push already your changes to git (maybe first in a temporary branch)? once done, I would give it a look It is here : ssh://git.debian.org/git/python-modules/packages/ipython4.git Not perfect, but it's a start. Snark on #debian-python
Re: The state of jupyter in Debian
Hi, On 16/04/2016 11:38, Yuri D'Elia wrote: Hi everyone, I have a general question about the state of the jupyter packages. I noticed recently that several packages started to pop-up in the experimental archive, which is great. I've been trying jupyter through anaconda a couple of times, and I'm looking forward to it. Although the actual jupyter notebook is still missing. Any particular trouble with packaging? I had started a packaging effort months ago for jupyter in Debian, but couldn't push it to completion for personal reasons. Recently, Julien Cristau and others decided to start where I stopped, and pushed several packages to experimental. I gave them my experimental work to kickstart their effort. I had a jupyter notebook package, but if I remember well there were problems with some java & nodejs deps. Since things have certainly moved since then, that might not be accurate now. Those last days I started to brush up my existing packages and hope I'll be able to contribute to jupyter on Debian again. Snark on #debian-python
ITP: python-prompt-toolkit -- Library for building powerful interactive command lines in Python
Package: wnpp Severity: wishlist * Package name : python-prompt-toolkit Version : 1.0.3 Upstream author : Jonathan Slenders * URL : https://github.com/jonathanslenders/python-prompt-toolkit License : BSD-3-clause Programming Lang.: Python Description : Library to build powerful interactive command lines in Python This module is a library to build powerful interactive command lines, with syntax highlightning during typing, multi-line editing, advanced code completion and a long list of other features. This is a dep of recent ipython versions. I plan to package it within the Debian Python Module Team repository. Snark on #debian-games
RFS: python-prompt-toolkit/1.0.3-1 (ITP)
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-prompt-toolkit" * Package name: python-prompt-toolkit Version : 1.0.3-1 Upstream Author : Jonathan Slenders * URL : https://github.com/jonathanslenders/python-prompt-toolkit * License : BSD-3-clause Section : python It builds those binary packages: python-prompt-toolkit - Library to build powerful interactive command lines in Python 2 python3-prompt-toolkit - Library to build powerful interactive command lines in Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-prompt-toolkit Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-prompt-toolkit/python-prompt-toolkit_1.0.3-1.dsc It is packaged within the Debian Python Modules Team: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/python-prompt-toolkit.git Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/python-prompt-toolkit.git Cheers, Snark on #debian-python
Re: ITP: python-prompt-toolkit -- Library for building powerful interactive command lines in Python
Hi, On 21/07/2016 12:45, Scott Kitterman wrote: This is already packaged. https://tracker.debian.org/pkg/prompt-toolkit Scott K Sigh... I need a brain. And sleep. :-/ Snark on #debian-python
ITP: python-entrypoints -- Discover and load entry points from installed packages
Package: wnpp Severity: wishlist * Package name : python-entrypoints Version : 0.2.2 Upstream author : Thomas Takluyver * URL : https://github.com/takluyver/entrypoints License : Expat Programming Lang.: Python Description : Discover and load entry points from installed packages This module contains functions to find and load entry points in installed packages. I plan to package it within the Debian Python Module Team repository. Snark on #debian-games
Re: Packaging/installing jupyter kernels
Hi, On 05/08/2016 14:07, Gordon Ball wrote: Jupyter has been in experimental for a while and presumably will make it to unstable in the not too distant future. I don't think that will happen that early... there are a few things not ready yet and what is there isn't perfect yet. Help is welcome! Once that is done, what is the correct way for packages providing a jupyter kernel to install it? * manually install kernel.json in /usr/share/jupyter/kernels/? * build-depend on python3-jupyter-core and call `jupyter kernelspec install` during build? * runtime-depend and install in postinst instead? * (something else) No idea. Snark on #debian-python
Re: Packaging/installing jupyter kernels
On 05/08/2016 20:57, Gordon Ball wrote: On 05/08/16 15:17, Julien Puydt wrote: Hi, On 05/08/2016 14:07, Gordon Ball wrote: Jupyter has been in experimental for a while and presumably will make it to unstable in the not too distant future. I don't think that will happen that early... there are a few things not ready yet and what is there isn't perfect yet. Help is welcome! I might be able to help. What are the outstanding issues/blockers? (I'm not actually a DPMT/PAPT member, but this might be a good time to join). I'm trying to finish nbconvert, with the notebook to come -- last time I had a look, we (Debian) were lacking javascript packages. So perhaps you need not join the DPMT after all :-P If you don't feel good with packaging javascript, you could also launch ipython (the one in experimental) and try to run a few commands in them. You should get a few warnings : those are hints something isn't quite right. Once that is done, what is the correct way for packages providing a jupyter kernel to install it? * manually install kernel.json in /usr/share/jupyter/kernels/? * build-depend on python3-jupyter-core and call `jupyter kernelspec install` during build? * runtime-depend and install in postinst instead? * (something else) No idea. Example: xonsh (a python-based shell) includes a kernel and tries to install it from setup.py (currently disabled by not having jupyter available at build time). But it sounds like the question is premature. See above for ideas what to do -- but you can also try to find out what the better scheme to ship jupyter kernel is... I don't think anybody wondered seriously about it yet. :-) Cheers, Snark on #debian-python
Re: requesting help updating a python package
Hi, On 27/09/2016 01:16, Boylan, Ross wrote: I'd like to use zodb, and it looks as if the most recent Debian version available is 3.3, and that's available only for python2. I'd like to use the current zodb, 5.0, with python3. Aside from preferring to use current software, it looks as if zodb 5 with python 3 sometimes has significant performance advantages. I believe I could just install it using easy_install, but since this has many dependencies I'll end up with a lot of local python packages that the Debian package system won't know about. So I thought I might try updating the existing package (and maybe its dependents). It has some oldish (1 year) requests for newer updates against it, and so I suspect the maintainers aren't too active. The control file references Vcs-Svn: svn://anonscm.debian.org/pkg-zope/zodb/trunk, which has only the debian directory. I'm guessing this is all supposed to work with svn-bp.alioth.debian.org, but am not sure how to proceed. And since I don't have or want commit privileges, I'm not sure that working with subversion is a good idea. Any suggestions how to proceed? I have also downloaded a semi-random python3 package (python3-bitarray, which has some C code) to see how things are packaged for python3. Should I expect that the debhelper scripts will be able to figure out the dependent packages without my need to specify them explicitly? Thanks. Ross Boylan Isn't there a maintainer/uploader for this package, whom you could ask? Snark on #debian-python
Re: Plan for ipython 5 transition
Hi, On 11/10/2016 02:18, Tobias Hansen wrote: Snark, do you want to file the bugs? I'm in the middle of moving -- and I know when I move out, but still have no clue where to move in : I'm not as readily available as I would like. I'll give a hand if I can, but I don't think it's a good idea to take responsibility just now. Sorry, Snark
Re: Plan for ipython 5 transition
Hi, On 11/10/2016 09:27, Tobias Hansen wrote: ok, but are you ok with us moving ahead? Is ipython generally ready to migrate? What about the other related packages (ipykernel, jupyter_client, jupyter_core, nbconvert, nbformat). Should they all migrate together? Are they ready (up to questions of transition)? Of course I'm ok with moving ahead! And yes, everything jupyter-related needs to come together. Snark
Re: replacement for ipython(3)-notebook?
Hi, On 09/11/2016 16:24, Zack Weinberg wrote: ipython(3)-notebook has been dropped from unstable with the transition to ipython 5.0.0. What package now provides this functionality? Gordon Ball is working on packaging jupyter-notebook. It's part of the effort to package sagemath in Debian -- the discussion happens mostly on the debian-science-sagemath mailing-list. Snark on #debian-python
Re: Binary naming for Django Related Packages
+1 On 28/11/2016 17:11, Scott Kitterman wrote: Snark on #debian-python
Re: How do I include info and man pages in an installer?
On 05/01/2017 10:00, Jorge wrote: I'm trying to make my first .deb package. For that I have read https://www.debian.org/doc/debian-policy/ and https://wiki.debian.org/Packaging/Intro. The latest guide was the most useful for me because I had no experience. Apart from all the warnings from lintian, after building the .deb I could install it and it worked, but the manuals didn't. Now running lintian... W: ducker source: non-native-package-with-native-version W: ducker source: no-debian-copyright W: ducker source: ancient-standards-version 3.9.2 (current is 3.9.5) W: ducker: wrong-bug-number-in-closes l3:#XX W: ducker: copyright-without-copyright-notice W: ducker: spelling-error-in-description searchs searches W: ducker: zero-byte-file-in-doc-directory usr/share/doc/ducker/copyright W: ducker: binary-without-manpage usr/bin/duck W: ducker: binary-without-manpage usr/bin/ducker E: ducker: python-script-but-no-python-dep usr/bin/duck E: ducker: python-script-but-no-python-dep usr/bin/ducker Finished running lintian. The tutorial I read is so basic that it doesn't show how to include the man and info pages. I'm using Sphinx to build the info page and the man page its already build in the repository. I also have a Bash autocompletion file. Anyone can point me in the right direction? There are so many packaging guides and I find most of them very confusing? This is the program I'm trying to package in case you wonder: https://notabug.org/Ducker/ducker You should have a look at the manpages for dh_installman and dh_installinfo. Basically, add a packname.info or packname.manpages in the debian directory pointing to what you want to install. For simple questions the #debian-mentors IRC channel is of great help! Cheers, Snark on #debian-mentors
ITP: scandir -- Better directory iterator that returns all file info the OS provides
Control: retitle -1 ITP: scandir -- Better directory iterator that returns all file info the OS provides I would like to package python-scandir, as newer versions of python-pathlib2 now depend on it. As I don't want to add new deps to the python-pathlib2 package now, I'll work in several steps : - close this ITP bug by packaging scandir ; - leave things as-is until stretch is out ; - get newer python-pathlib2 out with a depend on python-scandir (thus closing #851137). For reference, that is a backport of the scandir in Python 3 ; I know it's a wishlist item to stop packaging Python 2 modules, but since it's a new dep of an existing one, I think it still makes sense. Snark on #debian-python
Re: ITP: scandir -- Better directory iterator that returns all file info the OS provides
Hi, On 14/01/2017 17:37, Scott Kitterman wrote: Scandir is pretty generic. I'd suggest python-scandir or similar for the package name. I named it python-scandir. Snark on #debian-python
Re: IPython/Jupyter plans for buster
Hi, Le 27/06/2017 à 18:20, Ximin Luo a écrit : > This assumes the Sage kernel would still work with a python3-only notebook... > I certainly hope so, if jupyter upstream are ready to drop the python2 > notebook so quickly... there's a good chance sagemath will end up using Python 3 too at some not-too-remote moment... Snark on #debian-python
Re: RFS: jupyter components
Hi, Le 28/08/2017 à 23:56, Gordon Ball a écrit : > Hello > > The following packages should be ready for upload, if someone would be > willing to check and sponsor the uploads: > > * ipython 5.4.0-1 > >IPython 6.x is now available, but is python3 only. For the moment, >the existing ipython source package will be the 5.x series, and at >some point it will cease to build the python3 package and a new >source package based on ipython6 will take that binary over. > >Question for previous packagers: we currently ship a custom >ipython.sh script as /usr/bin/ipython[3] instead of using the >entry-points script that would otherwise be installed, but I can't >find the rationale documented - faster startup? > > * jupyter-console: 5.2.0-1 > >I tried out converting this one to gbp-pq (all others are still in >git-dpm format) > > * jupyter-core: 4.3.0-1 > * nbformat 4.4.0-1 > * jupyter-client: 5.1.0-1 > > > The remaining packages are currently blocked: > > * nbconvert: 5.2.1 > >waiting on python-pandocfilters >= 1.4 (already in dpmt git, but >not yet uploaded) > > * jupyter-notebook: 5.0.0 > >working package available, but with some functionality limited due to >unpackaged or out-of-date javascript libraries I haven't dared touching those packages recently (and especially not updating them to later upstream) precisely because I knew I would risk killing Python2 support. Could you be more explicit about which javascript libraries are unpackaged or out-of-date? I've been struggling since pretty long to keep some of the javascript packages I made for jupyter up to date, so perhaps at one point that effort might help... Snark on #debian-python and #debian-js
Re: RFS: jupyter components
Hi, Le 28/08/2017 à 23:56, Gordon Ball a écrit : > * nbconvert: 5.2.1 > >waiting on python-pandocfilters >= 1.4 (already in dpmt git, but >not yet uploaded) I updated it to latest upstream -- the build doesn't fail because of python-pandocfilters afaict, but because for some reason entrypoints don't get activated correctly. I still pushed my changes because I'm sure I'm just missing something stupid... Snark on #debian-python
Re: RFS: jupyter components
Hi, Le 04/09/2017 à 10:49, Gordon Ball a écrit : > On Mon, 4 Sep 2017, Julien Puydt wrote: >> Hi, >> >> Le 28/08/2017 à 23:56, Gordon Ball a écrit : >> >>> * nbconvert: 5.2.1 >>> >>> waiting on python-pandocfilters >= 1.4 (already in dpmt git, but >>> not yet uploaded) >> >> I updated it to latest upstream -- the build doesn't fail because of >> python-pandocfilters afaict, but because for some reason entrypoints >> don't get activated correctly. I still pushed my changes because I'm >> sure I'm just missing something stupid... > > Yes - sorry, should have added some more text for this one. I didn't > find a solution to entry_points not working during dh_auto_test, so my > solution to that was to disable the build-time test and run it instead > as an installed autopkgtest, for which entry_points should work correctly. In fact, I spend a good amount of time investigating the issue : setuptools only create the text file creating the entry points when installing, not when building -- so I think it's best to disable build-time tests and rely on autopkgtest to save ourselves afterwards. Let me override-kill the autotest step. > The issue with pandocfilters arose because I always run autopkgtest as a > build step, but while there is an easy way of getting sbuild to use > other locally built packages (--extra-package=/dir/containing/debs), I > haven't found a way of getting autopkgtest to do the same - so I can > satisfy build dependencies with extra, locally-built packages, but not > the autopkgtest dependencies. Here is how to setup things so it's easier to use local packages (something I do a lot for my javascript experiments...) : 1. put your updated packages in some directory then make it a real repository ( /usr/bin/apt-ftparchive packages . > Packages ) 2. mount that somewhere under /repo in the schroot (add a line to /etc/schroot/sbuild/fstab) 3. add "deb [trusted=yes] file:///repo ./" to your sources.list *within the schroot* 4. now you can do something like "autopkgtest my-package_3.14-159.dsc -- schroot unstable-amd64-sbuild" to test your package! Of course, it's easy to write a script which will update the list of packages in the repo then call autopkgtest on $1 with the right options. > Has anyone else encountered the issue with tests which rely on > entry_points and how to make them work during dh_auto_test? Presumably > there must be some environment/pybuild magic which will make them look > in the right place. See above : there's no right place since entry_points.txt isn't built before installing! Snark
Re: RFS: jupyter components
Hi, Le 04/09/2017 à 17:08, Julien Puydt a écrit : > Hi, > > Le 04/09/2017 à 10:49, Gordon Ball a écrit : >> On Mon, 4 Sep 2017, Julien Puydt wrote: >>> Hi, >>> >>> Le 28/08/2017 à 23:56, Gordon Ball a écrit : >>> >>>> * nbconvert: 5.2.1 >>>> >>>> waiting on python-pandocfilters >= 1.4 (already in dpmt git, but >>>> not yet uploaded) >>> >>> I updated it to latest upstream -- the build doesn't fail because of >>> python-pandocfilters afaict, but because for some reason entrypoints >>> don't get activated correctly. I still pushed my changes because I'm >>> sure I'm just missing something stupid... I don't see a failure with the current pandocfilters, but I see a need for a newer nbsphinx (bug #874266). I made myself an experimental package and checked it would fix things, so I have added the versioned dep to nbconvert. >> The issue with pandocfilters arose because I always run autopkgtest as a >> build step, but while there is an easy way of getting sbuild to use >> other locally built packages (--extra-package=/dir/containing/debs), I >> haven't found a way of getting autopkgtest to do the same - so I can >> satisfy build dependencies with extra, locally-built packages, but not >> the autopkgtest dependencies. I added python-testpath and python3-testpath to the deps of the package, since they were required by the autopkgtest. There are quite many things to fix to correct before uploading, though : lintian is not happy. Snark on #debian-js
Re: RFS: jupyter components
Hi, Le 04/09/2017 à 18:17, Julien Puydt a écrit : > There are quite many things to fix to correct before uploading, though : > lintian is not happy. Lintian still complains about two things: W: nbconvert source: newer-standards-version 4.1.0 (current is 4.0.0) I: nbconvert source: testsuite-autopkgtest-missing The first is ok. The second is strange: autopkgtest is quite happy with the dsc... I would say : ready to upload as soon as we have a newer nbsphinx. Snark
Re: RFS: jupyter components
Hi, old thread but new things. Le 28/08/2017 à 23:56, Gordon Ball a écrit : > * nbconvert: 5.2.1 > >waiting on python-pandocfilters >= 1.4 (already in dpmt git, but >not yet uploaded) The package is up to date, and I am theoretically allowed to upload it, but since it now produces one more binary, I am practically not allowed to upload it -- if someone from the list can sponsor, that would be nice. If not, I'll just dput mentors and file a RFS to sponsorship-requests. Cheers, Snark on #debian-python
Re: pycharm package in debian
Hi, Le 30/09/2017 à 14:22, kamaraju kusumanchi a écrit : > Are there any plans to make a debian package of pycharm that is part > of official debian? I used their community edition on windows 7 and it > is awesome. Maybe you should look at WNPP to see if someone filed a RFP or ITP, and if not, submit a RFP yourself? Snark on #debian-python
Re: RFS: jupyter components
Hi, Le 25/10/2017 à 21:01, Diane Trout a écrit : > >> I have just uploaded the current RFS packages (ipython, >> jupyter-notebook, jupyter-console, nbconvert) to mentors.d.n > > I just reviewed nbconvert > > I got one lintian warning > > nbconvert source: timewarp-standards-version (2017-09-03 < 2017-09-27) > > The source package refers to a Standards-Version that was released > after the date of the most recent debian/changelog entry. Perhaps you > forgot to update the timestamp in debian/changelog before building the > package? > > Would anyone who worked on preparing the release like to update the > changelog timestamp? > > Also it's probably a good idea not push the debian/5.3.1-1 tag for the > release until its actually accepted. There's a couple of commits after > the tag which are in the package on mentors. > > Will go look at the other packages in a bit. I removed the offending tag and updated the changelog timestamp. According to "who-permits-upload nbconvert", I might be able to dput myself... tell me if you want me to. Thanks for the review! Snark on irc.debian.org
Re: How to upload my python application .deb file on to debian repository
Hi, Le 23/11/2017 à 05:07, quickcal calculator a écrit : > I have developed a Python GUI Application, which i feel will be useful > to all desktop users. Please guide on How to upload my python > application .deb file on to debian repositories. Thanks. You can submit a RFP (request for package) bug, and put this list in CC. See: https://wiki.debian.org/RFP The request generally lists things like the homepage, the license and a description ; see for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658393 I hope that helps, Snark on irc.debian.org
Please add me to the relevant group on salsa
Hi, I would like to continue contributing to the Debian Python Module Team (whatever is its name now). I'm juydt-guest on salsa. Thanks, Snark on #debian-python
Thread on flit...
Hi, a new building/packaging/publishing/whatevering tool for Python modules has appeared sometime ago : flit. The homepage is here : https://github.com/takluyver/flit I know a few packages using it already ; and I have terminado (from the same author as flit) which I would like to update. It might be needing a team-level discussion, so I'm opening a thread here : should support for it be added to our current package building tools? Should it be packaged? Snark on #debian-python
Re: Thread on flit...
Hi, Le 17/02/2018 à 07:59, Paul Wise a écrit : > On Thu, Feb 15, 2018 at 11:05 PM, Julien Puydt wrote: > >> Should it be packaged? > > If it meets Debian standards and is needed by another package, there > is no reason why it shouldn't be packaged. > It is intended for trivial packaging... so perhaps dh_python could detect its use and do something smarter. Snark on #debian-python
Re: packages that use dh_python{2,3} but don't depend on dh-python
Hi, Le 26/03/2018 à 13:32, Piotr Ożarowski a écrit : > Here's a list of packages that will FTBFS soon if dh-python will not be > added to Build-Depends (it's time to drop dh-python from python3's > Depends and old version of dh_python2 from python package). > > http://people.debian.org/~piotr/dh_python3_without_dh-python.list > http://people.debian.org/~piotr/dh_python3_without_dh-python.ddlist > http://people.debian.org/~piotr/dh_python2_without_dh-python.list > http://people.debian.org/~piotr/dh_python2_without_dh-python.ddlist > > The plan is to report bugs first and follow up with changes in -defaults > packages in April or May. I added dh-python as build-dep of brial/polybori -- in the git repository : I'm not sure we'll upload a new version that soon (it's a dep of sagemath, so we're cautious). Thanks, Snark on #debian-python
Bug#894786: RFP: python-pytest-flake8 -- pytest plugin to check FLAKE8 requirements
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python-pytest-flake8 Version : 1.0.0 Upstream Author : Thorsten Lockert * URL : https://github.com/tholo/pytest-flake8 * License : BSD Programming Lang: Python Description : pytest plugin to check FLAKE8 requirements This pytest plugin makes it possible to check source code for Flake8 style guide enforcement. The newest path.py versions use that to check the sources ; I have a patch to disable that for now. Snark on #debian-python
Please add me (back?) to the team
Hi, I'm already part of the teams, but as jpuydt-guest, and I would now need to be part of the same teams as jpuydt, as I just completed the process to become a DD. If I remember well, I'm part of: - Debian Science - Debian Python Module Team - Debian Javascript packagers Thanks, Snark on irc.debian.org
Updating nbconvert : problems with privacy breaches
Hi, looking into finishing packaging nbconvert's latest version (thanks Ondřej Nový and Gordon Ball for the help!), lintian had quite a few complaints about privacy breaches: W: python-nbconvert-doc: privacy-breach-generic usr/share/doc/python-nbconvert-doc/html/customizing.html [src="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.1.10/require.min.js";>] (https://cdnjs.cloudflare.com/ajax/libs/require.js/2.1.10/require.min.js) E: python-nbconvert-doc: privacy-breach-uses-embedded-file usr/share/doc/python-nbconvert-doc/html/customizing.html You may use the libjs-jquery package. (https://cdnjs.cloudflare.com/ajax/libs/jquery/2.0.3/jquery.min.js) E: python-nbconvert-doc: privacy-breach-uses-embedded-file usr/share/doc/python-nbconvert-doc/html/customizing.html You may use the libjs-mathjax package. (https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/mathjax.js?config=tex-ams_html)And indeed grepping the source code, there are a few places with links to cloudflare.com :./docs/source/customizing.ipynb:"