Python 3.9 for bullseye

2020-10-18 Thread Matthias Klose
Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
are done (thanks to Graham for the work).   Bug reports should be all filed for
all known problems [1], and the current state of the 3.9 addition can be seen at
[2] (a few of the "bad" are false packages with b-d n python3-all-dev, but not
building for 3.9, bug reports also filed).

The major outstanding issue is the pandas stack, all other problems are found in
leaf packages (leaf in the sense of that no other package for the 3.9 addition
is blocked).

Please help fixing the remaining issues!

Matthias

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.9;users=debian-python@lists.debian.org
[2] https://release.debian.org/transitions/html/python3.9.html



Re: [Pkg-javascript-devel] Jupyter project packaging effort

2020-10-18 Thread Jonas Smedegaard
Hi Julien,

Great that you are improving some packages.

I have a hard time understanding what you are trying to say in your post 
below, however...


Quoting Julien Puydt (2020-10-18 09:55:27)

[ long rant about how proper packaging is hard and may fail ]

> Help is welcome,

Did I understand your message correctly, or did I miss something?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Jupyter project packaging effort

2020-10-18 Thread Julien Puydt
Hi,

my first goal was to update nbconvert -- but it needs a more recent
nbsphinx.

So I have a look at nbsphinx. Ah, it requires a more recent ipywidgets.

Now ipywidgets gets interesting : that package suffers from a lack of
love, for reasons made obvious below.

The purely Python part is ok, but there's a widgetsnbextension/
directory. "Lasciate ogni speranza, voi ch'entrate" would be a more
suitable name, though longer. What is it? A trivial Python code, with a
few javascript source files, which need to be "compiled" (webpack'ed,
really).

The package existed, so it just needs brushing, ok? Well, the short
answer is: no. The longer answer is that in debian/, there is a lot of
javascript code. Not even always sources. When the package was (last)
prepared, Debian lacked many, many things on the javascript side, so
there was little choice in the matter. The elephant in the room is
webpack : but now we have it!

There are still probably dozens of missing depends, all in a dep graph,
probably not a tree (there will be loops). I'll probably prepare quite
a few package both in the Debian Python Team and the Debian Javascript
Maintainers Team.

I'm sorry if I'm breaking some things along the way : I'll do my best
to avoid that, but from experience you can hardly upgrade things on one
side without breaking something on another...

Help is welcome,

JP



Bug#972415: ITP: jupyter-server -- Jupyter protocol server backend

2020-10-18 Thread Julien Puydt
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-python@lists.debian.org

* Package name: jupyter-server
Version: 1.0.5
Upstream author: Jupyter Development Team
* URL: https://github.com/jupyter/jupyter_server
License: BSD-3-clause
Description: Jupyter protocol server backend


It's a step towards packaging more recent versions of the Jupyter
project ecosystem. I plan to maintain it within the Debian Python Team,
along with the other Jupyter-related packages.

Cheers,

JP