Re: RFS: jupyter components
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.
Re: Namespace conflict for python-magic
Mathias Behrle wrote... > Current python(3)-magic in Debian is built from source package 'file'[0]. (...) > OTOH the package providing python-magic on PyPi[3] is provided by another > Upstream[4]. ... and I assume the APIs are not identical? > The cleanest solution for me would look like > - package file in Debian should provide python(3)-file-magic > - python-magic should be the package name corresponding to the PyPi package > python-magic[4] This would result in users of the current python-magic (from file) would be forced into the other one. Unless we (as in Debian) can guarantee this will work in each and every use case, I fail to see why this should be considered a clean solution. The cleanest solution indeed was to bring both upstreams together and ask them to reconcile the APIs and eventually make one of the both implementations obsolete. As things happen such an attempt was started two years ago but appearently never came to a result.[1] Trying to address this conflict in Debian is always only second best. If this is the only feasible way, it still should leave a choice to users so they can install the implementation of their own preference. Co- installability of both package was certainly nice-to-have but will probably impossible for technical reasons. Christoph [1] The file mailing list server is currently down, so I cannot provide URLs. The Message-IDs are <20151020133008.9b79517f...@rebar.astron.com> signature.asc Description: Digital signature
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, 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: Namespace conflict for python-magic
On September 4, 2017 11:42:56 AM EDT, Mathias Behrle wrote:
>
>Hi Christoph, hi folks,
>
>there exists an odd namespace conflict for python-magic.
>
>Current python(3)-magic in Debian is built from source package
>'file'[0].
>According to the included setup.py the package for the python bindings
>are
>published as 'file-magic'[1] and are available on PyPi under this
>name[2].
>
>OTOH the package providing python-magic on PyPi[3] is provided by
>another
>Upstream[4].
>
>The cleanest solution for me would look like
>- package file in Debian should provide python(3)-file-magic
>- python-magic should be the package name corresponding to the PyPi
>package
> python-magic[4]
>
>The realization of this solution would create some substantial
>overhead.
>Therefore it will be more adequate to find a different, but
>nevertheless
>meaningful package name for python-magic from [4]. The ugly, but best
>name
>currently on my mind would be python-python-magic.
>
>Any thoughts?
>
>Cheers,
>Mathias
>
>
>[0] https://sources.debian.net/src/file/
>[1] https://sources.debian.net/src/file/1:5.31-1/python/setup.py/
>[2] https://pypi.python.org/pypi/file-magic/0.3.0
>[3] https://pypi.python.org/pypi/python-magic/
>[4] http://github.com/ahupp/python-magic
There is a nearly equivalent situation with the "dns" namespace. There are two
completely unrelated packages; one provides "DNS" and the other provides "dns".
Obviously they can't both be python-dns in Debian. One is python{3}-dns and
the other is python{3}-dnspython.
If you went down that route, instead of python-python-magic, you'd get
python-magicpython. Personally, I like that a little better, but it's a matter
of taste. Policy doesn't provide any guidance for this case.
Scott K
Namespace conflict for python-magic
Hi Christoph, hi folks, there exists an odd namespace conflict for python-magic. Current python(3)-magic in Debian is built from source package 'file'[0]. According to the included setup.py the package for the python bindings are published as 'file-magic'[1] and are available on PyPi under this name[2]. OTOH the package providing python-magic on PyPi[3] is provided by another Upstream[4]. The cleanest solution for me would look like - package file in Debian should provide python(3)-file-magic - python-magic should be the package name corresponding to the PyPi package python-magic[4] The realization of this solution would create some substantial overhead. Therefore it will be more adequate to find a different, but nevertheless meaningful package name for python-magic from [4]. The ugly, but best name currently on my mind would be python-python-magic. Any thoughts? Cheers, Mathias [0] https://sources.debian.net/src/file/ [1] https://sources.debian.net/src/file/1:5.31-1/python/setup.py/ [2] https://pypi.python.org/pypi/file-magic/0.3.0 [3] https://pypi.python.org/pypi/python-magic/ [4] http://github.com/ahupp/python-magic -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
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
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
