Re: DPMT membership request for acaso-guest
[Alberto Caso, 2016-12-02] > I would like to join the DPMT. I intend to package and maintain python- > dbus (RFP #838791). > > My Alioth login is acaso-guest. > > I have read and accept the DPMT policy [1]. welcome! :) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: How to deal with jupyter notebook extensions
[Ximin Luo, 2016-12-03] > So far, so good. But now I'm having trouble trying to automate away > the "enable" step. What "enable" does is add an entry to > /etc/jupyter/nbconfig/notebook.json. There are two ways of automating > this, and I'm not sure which way is the best. They each have their > downsides. is upstream willing to apply a patch to support /etc/jupyter/nbconfig/notebook.d/ that would solve your problem IIUC? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: [Debian-science-sagemath] How to deal with jupyter notebook extensions
Piotr Ożarowski: > [Ximin Luo, 2016-12-03] >> So far, so good. But now I'm having trouble trying to automate away >> the "enable" step. What "enable" does is add an entry to >> /etc/jupyter/nbconfig/notebook.json. There are two ways of automating >> this, and I'm not sure which way is the best. They each have their >> downsides. > > is upstream willing to apply a patch to support > /etc/jupyter/nbconfig/notebook.d/ that would solve your problem IIUC? > They would probably not want to do that, because (at least currently) the only "config option" each extension would have, is which "sections" it should be enabled in. So we'd get a mess of 1-line files in those directories. However, I've come up with an alternative solution in the meantime, based on triggers but solving the downsides mentioned previously. Each package can install, an extra file, e.g.: /usr/share/jupyter/nbextension/jupyter-js-widgets/extension.nbextension whose contents would simply be "section: notebook" or even "" to imply the default value, "notebook". Then I can write a notebook.nbextensions_scan_update module to scan for .nbextension files, and run this module in the postinst trigger. And I will ask upstream to accept this scanner module. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Versioned dependencies with stdeb and pybuild
Hi, I'm trying to package an application with stdeb and pybuild but have problems generating versioned dependencies in debian/control. The application requires Python 3.5, so I added to stdeb.cfg Depends: python3 (>= 3.5) The application also specifies the following requirements: requests>=2,<3 pyyaml>=3.11,<4 pytz>=2016.7 pip>=7.0.0 jinja2>=2.8 voluptuous==0.9.2 typing>=3,<4 aiohttp==1.0.5 async_timeout==1.0.0 I added entries for aiohttp and async_timeout to debian/py3dist-overrides, because these packages are not included in the existing mapping. Still, most of the dependencies in debian/control were not versioned. The dependency on python3 was not included at all. Looking at dhpython.pydist.guess_dependency, I can see that in order for a version to be included, the mapping must specify a standard (e.g. PEP386) or a rule and the operator may not be '==' or '!='. So I could get versioned dependencies for some requirements with additional entries in debian/py3dist-overrides, but not for all of them. If possible, I would like to see 'python3 (>= 3.5)' included and have all dependencies versioned in debian/control. Any advice on how to achieve this (or explanation why its a bad idea :))? Thanks, Malte
Re: Versioned dependencies with stdeb and pybuild
[Malte Forkel, 2016-12-05]
> The application requires Python 3.5, so I added to stdeb.cfg
>
> Depends: python3 (>= 3.5)
>
> The application also specifies the following requirements:
>
> requests>=2,<3
> pyyaml>=3.11,<4
> pytz>=2016.7
> pip>=7.0.0
> jinja2>=2.8
> voluptuous==0.9.2
> typing>=3,<4
> aiohttp==1.0.5
> async_timeout==1.0.0
this looks like requirements.txt (i.e. environment upstream tested it
with / is comfortable with) rather than install_requires from setup.py.
If it really is in setup.py (and later in requires.txt), then it's a bug
in upstream code ("=="? really?).
anyway... as you mentioned, dh_python3 doesn't copy/translate version
requirements by default (maintainer of given package has to confirm that
upstream uses PEP386 or whatever the current PEP number is this month)
or you can (and should IMHO) put these requirements into Build-Depeneds
and dh_python3 should copy them into Depeneds where possible
> I added entries for aiohttp and async_timeout to
> debian/py3dist-overrides, because these packages are not included in the
> existing mapping. Still, most of the dependencies in debian/control were
> not versioned. The dependency on python3 was not included at all.
please try with DB instead of py3dist-overrides
[...]
> If possible, I would like to see 'python3 (>= 3.5)' included and have
> all dependencies versioned in debian/control. Any advice on how to
> achieve this (or explanation why its a bad idea :))?
try with X-Python3-Version: >= 3.5
PS shameless plug: did you try py2dsp (from pypi2deb)?
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Versioned dependencies with stdeb and pybuild
Thanks for your help!
May be I should have mentioned that I'm packaging for internal use here.
So required package versions not available in the standard distribution
will be provided from a local repository.
Am 05.12.2016 um 13:28 schrieb Piotr Ożarowski:
> this looks like requirements.txt (i.e. environment upstream tested it
> with / is comfortable with) rather than install_requires from setup.py.
>
> If it really is in setup.py (and later in requires.txt), then it's a bug
> in upstream code ("=="? really?).
You're right, this is requirements.txt, including the '=='s ...
> anyway... as you mentioned, dh_python3 doesn't copy/translate version
> requirements by default (maintainer of given package has to confirm that
> upstream uses PEP386 or whatever the current PEP number is this month)
> or you can (and should IMHO) put these requirements into Build-Depeneds
> and dh_python3 should copy them into Depeneds where possible
Why do you recommend putting the requirements into Build-Depends? Most
of those packages are currently not available on the build system (I'm
not pbuilder for this).
How do you think about an additional option for pybuild that would tell
it to translate all version specifications provided by upstream into
Depends?
>> I added entries for aiohttp and async_timeout to
>> debian/py3dist-overrides, because these packages are not included in the
>> existing mapping. Still, most of the dependencies in debian/control were
>> not versioned. The dependency on python3 was not included at all.
>
> please try with DB instead of py3dist-overrides
With DB, you mean Build-Depends?
>> If possible, I would like to see 'python3 (>= 3.5)' included and have
>> all dependencies versioned in debian/control. Any advice on how to
>> achieve this (or explanation why its a bad idea :))?
>
> try with X-Python3-Version: >= 3.5
Ok. But I guess this is overwritten the next time I use stdeb?
> PS shameless plug: did you try py2dsp (from pypi2deb)?
Not yet. Does it handle versioned dependencies differently?
Re: Versioned dependencies with stdeb and pybuild
[Malte Forkel, 2016-12-05] > Why do you recommend putting the requirements into Build-Depends? Most > of those packages are currently not available on the build system (I'm > not pbuilder for this). because you most probably need it for tests anyway and if tests work with version >= A, you don't need to translate requirements.txt with ">A.devRELEASED_TODAY_OR_TOMORROW+post7" if they're not packaged, you should start with the ones without dependencies, even in your local repository. > How do you think about an additional option for pybuild that would tell > it to translate all version specifications provided by upstream into > Depends? pybuild doesn't touch versions at all, you mean dh_python3 See https://anonscm.debian.org/cgit/dh-python/dh-python.git/tree/README.rst (pybuild is an implementation of dh_auto_foo) dh_python3 doesn't have such option, but I guess I can add optional --assume-upstream-versions-match-debians-and-are-sane (after finding a better name for it) > >> I added entries for aiohttp and async_timeout to > >> debian/py3dist-overrides, because these packages are not included in the > >> existing mapping. Still, most of the dependencies in debian/control were > >> not versioned. The dependency on python3 was not included at all. > > > > please try with DB instead of py3dist-overrides > > With DB, you mean Build-Depends? yes > >> If possible, I would like to see 'python3 (>= 3.5)' included and have > >> all dependencies versioned in debian/control. Any advice on how to > >> achieve this (or explanation why its a bad idea :))? > > > > try with X-Python3-Version: >= 3.5 > > Ok. But I guess this is overwritten the next time I use stdeb? you can specify X-Python3-Version in setup.cfg and stdeb will read it > > PS shameless plug: did you try py2dsp (from pypi2deb)? > > Not yet. Does it handle versioned dependencies differently? not really since both use dh_python3 (package name is pypi2deb or you can get it here: https://github.com/p1otr/pypi2deb) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Packaging new version of ZODB (Zope Object Database)
Le 11/04/16 à 16:15, Scott Kitterman a écrit : > On Friday, November 04, 2016 10:47:32 AM Barry Warsaw wrote: >> On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote: >>> Not sure if all python-modules repositories are like persistent, but for >>> me, mixing Debian work with imported tarballs in the same branch is >>> terrible. When possible, I prefer to fork the upstream repository, >>> otherwise no upstream source at all. >> >> You're not alone, but I think that's still a minority opinion in the team. >> Our packages are so tightly integrated with PyPI, and source tarballs are >> such an ingrained aspect of that service, that a pristine-tar based >> approach for team packages still makes sense, IMHO. > > You can integrate a new upstream directly from an upstream git repository > with > git-dpm if that's what makes sense for a particular upstream. That's tempting and I was about to ask how, but I doubt the team would accept. The Zope foundation already releases everything on PyPI and the policy says: « Complete upstream git history should be avoided in the upstream branch. [...] When you must (not want to) deviate, » So I plan to create only 3 new packages in DPMT: - python-btrees - python-zc.customdoctests - zodbpickle Packages maintained by the Debian/Ubuntu Zope Team, like zodb, will stay where there are (since I prefer git-svn+source-less), and I'll also create 'zeo' there (because it depends on zodb). https://wiki.debian.org/Python/GitPackaging: > Q: Source-full or source-less branches? A: Source-full branches please! There > are lots of good reasons for this, including the ability to easily diff > between upstream versions, [...] Such source-full tree is unusable for me. I need git-blame too and auto-generated files are annoying. Julien
gitignore and import of upstream tarballs (was Re: Packaging new version of ZODB (Zope Object Database))
Le 12/05/16 à 20:21, Julien Muchembled a écrit : > So I plan to create only 3 new packages in DPMT: > - python-btrees > - python-zc.customdoctests > - zodbpickle I am also preparing an update for python-persistent. But for all that, I followed https://wiki.debian.org/Python/GitPackaging and there's no indication about gitignore'd files and the *.egg-info directory. 1. Both upstream repositories have a .gitignore file at the root (ignoring *.egg-info among other files) but on PyPI: - BTrees-4.3.1.tar.gz contains it - persistent-4.2.2.tar.gz does not contain it I also have a ~/.gitignore file that ignores *.egg-info/ anyway. 2. The last release of zc.customdoctests is quite old and the tarball contain a egg-info folder that differs slightly to what the new setuptools generates, which is the source of bugs like #825921 Having generated files in Git is not great. 1 thing at a time so just simple questions: - Should the 'Creating a new package' paragraph on the wiki says 'git add -f .' instead of 'git add .' ? - It's quite obvious that ~/.gitignore should be ignored, but is it also the case for the one that may be in the tarball ? - Do we always want *.egg-info directories in Git ? Meanwhile, the wiki should also recommend to add the following line to debian/source/options: extend-diff-ignore="\.egg-info/" Julien signature.asc Description: OpenPGP digital signature
