Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #9766 > unrolled thread

RFS: jupyter components

Back to article view | Back to linux.debian.maint.python

Contents

  RFS: jupyter components Gordon Ball <gordon@chronitis.net> - 2017-08-29 00:50 +0200
    Re: RFS: jupyter components Julien Puydt <julien.puydt@laposte.net> - 2017-09-04 04:40 +0200
      Re: RFS: jupyter components Gordon Ball <gordon@chronitis.net> - 2017-09-04 10:50 +0200
        Re: RFS: jupyter components Julien Puydt <julien.puydt@laposte.net> - 2017-09-04 17:10 +0200
          Re: RFS: jupyter components Julien Puydt <julien.puydt@laposte.net> - 2017-09-04 18:20 +0200
            Re: RFS: jupyter components Julien Puydt <julien.puydt@laposte.net> - 2017-09-04 19:30 +0200
              Re: RFS: jupyter components Gordon Ball <gordon@chronitis.net> - 2017-09-04 19:50 +0200
    Re: RFS: jupyter components Julien Puydt <julien.puydt@laposte.net> - 2017-09-08 18:50 +0200
      Re: RFS: jupyter components Gordon Ball <gordon@chronitis.net> - 2017-10-13 01:00 +0200
    Re: RFS: jupyter components Adam Cecile <acecile@le-vert.net> - 2017-10-17 13:40 +0200
      Re: RFS: jupyter components Gordon Ball <gordon@chronitis.net> - 2017-10-17 21:40 +0200
        Re: RFS: jupyter components Diane Trout <diane@ghic.org> - 2017-10-25 21:20 +0200
          Re: RFS: jupyter components Julien Puydt <julien.puydt@laposte.net> - 2017-10-25 22:00 +0200
            Re: RFS: jupyter components Gordon Ball <gordon@chronitis.net> - 2017-10-25 22:30 +0200
              Re: RFS: jupyter components Diane Trout <diane@ghic.org> - 2017-10-25 23:00 +0200
              Re: RFS: jupyter components Diane Trout <diane@ghic.org> - 2017-10-25 23:40 +0200
              Re: RFS: jupyter components Diane Trout <diane@ghic.org> - 2017-10-26 00:10 +0200

#9766 — RFS: jupyter components

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

Thanks

Gordon

[toc] | [next] | [standalone]

#9775

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

[toc] | [prev] | [next] | [standalone]

#9776

[Multipart message — attachments visible in raw view] — view raw

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.

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.



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.

>
> Snark on #debian-python
>

[toc] | [prev] | [next] | [standalone]

#9777

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

[toc] | [prev] | [next] | [standalone]

#9779

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

[toc] | [prev] | [next] | [standalone]

#9781

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

[toc] | [prev] | [next] | [standalone]

#9783

On 04/09/17 19:23, Julien Puydt wrote:
> 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

My understanding is that this field is unnecessary, if d/tests/control
exists [policy 5.6.30], so it's only necessary for the other packages
for which we're relying on autodep8 to generate a autopkgtest.

> 
> 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.

Sounds reasonable. Thanks for looking into this one.

> 
> Snark
> 

[policy 5.6.30]:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Testsuite

This field is automatically added to Debian source control files by dpkg
when a debian/tests/control file is present in the source package.

[toc] | [prev] | [next] | [standalone]

#9807

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

[toc] | [prev] | [next] | [standalone]

#9932

On 08/09/17 18:47, Julien Puydt wrote:
> 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.

I guess this got lost in other things at the time. I think sponsorship
is still sought for:

 * ipython (5.1.0 -> 5.5.0)
 * nbconvert (4.2.0 -> 5.3.1)
 * jupyter-notebook (4.2.3 -> 5.1.0)
 * jupyter-console (5.0.0 -> 5.2.0)

Updating jupyter-notebook depends on nbconvert, the other packages
should be independent.

[toc] | [prev] | [next] | [standalone]

#9941

Hello Gordon,

We are really interested in getting notebook 5, any progress on this ?
Is it possible to get your not-uploaded-yet packages (I did not find 
them on mentors.debian.net).

Thanks in advance,

Best regards, Adam.

On 08/28/2017 11:56 PM, Gordon Ball wrote:
> 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
>
> Thanks
>
> Gordon
>

[toc] | [prev] | [next] | [standalone]

#9942

On 17/10/17 13:31, Adam Cecile wrote:
> Hello Gordon,
> 
> We are really interested in getting notebook 5, any progress on this ?
> Is it possible to get your not-uploaded-yet packages (I did not find
> them on mentors.debian.net).

I have just uploaded the current RFS packages (ipython,
jupyter-notebook, jupyter-console, nbconvert) to mentors.d.n

There is also an ubuntu PPA (ppa:chronitis/jupyter) [1] containing
builds of these packages for xenial, zesty and artful.

They should also all be buildable from the git packaging repositories
(jupyter-notebook build-depends on the updated nbconvert package due to
build-time tests, the rest should build cleanly). [2]

[1]: https://launchpad.net/~chronitis/+archive/ubuntu/jupyter
[2]:
https://anonscm.debian.org/git/python-modules/packages/jupyter-notebook.git
; jupyter-console.git ; ipython4.git; nbconvert.git

> 
> Thanks in advance,
> 
> Best regards, Adam.
> 

[toc] | [prev] | [next] | [standalone]

#9948

> 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.

Diane

[toc] | [prev] | [next] | [standalone]

#9949

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

[toc] | [prev] | [next] | [standalone]

#9950

On 25/10/17 21:51, Julien Puydt wrote:
> 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

Thanks for looking!

>>
>> 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?

I would normally not update the timestamp while the suite is UNRELEASED,
and expect whoever ultimately makes the upload to `dch -r` and tag the
release, but maybe it would be less ambiguous to update it each time
d/changelog gets edited.

>>
>> 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.
> 

For my part I think it is ready.

I think I have DM upload rights for jupyter-notebook but not the others
listed.

> Thanks for the review!
> 
> Snark on irc.debian.org
> 

[toc] | [prev] | [next] | [standalone]

#9951

On Wed, 2017-10-25 at 22:15 +0200, Gordon Ball wrote:
> 
> I would normally not update the timestamp while the suite is
> UNRELEASED,
> and expect whoever ultimately makes the upload to `dch -r` and tag
> the
> release, but maybe it would be less ambiguous to update it each time
> d/changelog gets edited.

In my own packages I update the changelog timestamp when creating a new
release, and then one final update for release. I'm not sure there's
clearly a right answer in this case.

The thing that made me want to have one of you to update the changelog
was Section 4.4 of the debian policy which says:

The maintainer name and email address used in the changelog should be
the details of the person who prepared this release of the package.
They are not necessarily those of the uploader or usual package
maintainer. 

> 
> I think I have DM upload rights for jupyter-notebook but not the
> others
> listed.

I don't mind doing a review & uploading. But if you want to upload go
ahead

I just uploaded nbconvert instead of going around in email a couple
more times.

Diane

[toc] | [prev] | [next] | [standalone]

#9952

[Multipart message — attachments visible in raw view] — view raw

Hi,

I just reviewed ipython from git.

I found a file was added that had a different copyright from the rest
of ipython. I went ahead and updated d/copyright & d/changelog and
pushed that change to git.

Do you want to update d/changelog with "unstable" and todays date? (or
I cloud prepare a team upload if you'd prefer)

I'm detrout on #debian-python if you want to tell me its done over
there.

Diane

[toc] | [prev] | [next] | [standalone]

#9953

[Multipart message — attachments visible in raw view] — view raw

Could you update the timestamp on jupyter-console as well?

That one also has a time-warp-standards

Thanks,
Diane

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web