Re: Dealing with flit -- a simplified packaging of python modules
On Sun, Sep 20, 2015 at 12:47 PM, Thomas Kluyver wrote: > However, my hope in that sentence was that other packaging will come not > to rely on Python sdists containing a setup.py file. Using sdists for > Debian packaging is already somewhat dubious, because they can contain > generated and bundled files (we do both for Jupyter Notebook sdists). Source tarballs containing generated/bundled files is a bug that should be fixed. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Dealing with flit -- a simplified packaging of python modules
On Thu, Sep 24, 2015, at 03:30 AM, Paul Wise wrote: > Source tarballs containing generated/bundled files is a bug that > should be fixed. That's my point ;-). From our upstream point of view, it's not a bug that the distributions we put on PyPI contain generated/bundled files - we do it that way deliberately, so that end users can install without needing Javascript developer tools to build those files. If you want a pure source tarball without generated files, that's available from Github. Thomas
Re: Bug#798999: transition: python3.5 supported
On Wed, 16 Sep 2015 17:43:53 -0400 Scott Kitterman wrote: > On Wednesday, September 16, 2015 10:23:19 PM Jonathan Wiltshire wrote: > > > I would appreciate it if you would go ahead and publish it and then with > > > your permission, I'll coordinate binNMUs as I've done in the past for > > > python transitions. > > > > Does https://release.debian.org/transitions/html/python3.5.html look about > > right? I adjusted the build-depend slightly. > > Yes. It looks good. Thanks. > > > There's quite some tangling with g++ stuff at the moment so please hold > > tight for now. Is it feasible to do rebuild tests in experimental ahead of > > time? > > I'm currently focusing on the packages that show up as neither good nor bad > as they are almost inevitably buggy. > > Many of the packages that show up as being tangled with g++ actually aren't > since they've already been rebuilt and transitioned to testing. I will, of > course, hold off and try and get a better picture of how much overlap there > really is. I've now reviewed the potential for entanglement between doing this python3.5 transition and the ongoing gcc5 transition. I reviewed the packages listed on the transition tracker as being affected by both transitions, reduced the list down to the packages that have not already been explicitly transitioned to a v5 or rebuilt for the transition and then examined and/or rebuilt the rest. None of the remaining packages [1] were listed on the titanpad [2] as needing transition nor did rebuilding them show any problems that would indicate a delay to the transition nor any gcc5 transition related issues with the exceptions of pandas and uwsgi, which are unbuildable for other reasons [3][4]. I have the python3-defaults upload to enable python3.5 as a supported python3 version prepared and ready to upload when I get an ack from the release team. I think we are ready to start. Scott K Please CC me on any replies to debian-release as I'm not subscribed. [1] gyoto, libkdtree++, liblinear, matplotlib, pandas, pykde4, pymia, pysubnettree, python-espeak, pyviennacl, uwsgi [2] https://titanpad.com/UtA5km2wW6 [3] #790024, #790924, and #790925 [4] #788957 signature.asc Description: This is a digitally signed message part.
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.
