Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group

Le mer. 29 sept. 2021 à 23:14, Dominik George a écrit : > > > and that will require an upstream new release, which does not help > > when you want/need to package the current one > > Most upstreams kindly make . post releases immediately. > I found that to be pretty rare in my own experience.

Re: Looking to help

Le lundi 18 janvier 2021 à 23:34 -0800, Perry Aganad a écrit : > Greetings everyone!, > > I have been using debian for a while now and I am a point where I > want > to help and start contributing to debian itself. I read the web page > about contributing and I took away that I should just jump

Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])

It results from the ambiguity between absolute and relative imports in Python 2. Here 2to3 considers your imports being relative, hence the added dot. I believe no dots would be added should a `from __future__ import absolute_import` be found in the preamble of the module. Hope this helps. Ghis

Re: Best way to handle circular build deps to make a pypy- package

On Wed, 15 Aug 2018, 12:11 Samuel Thibault, wrote: > Pierre-Elliott Bécue, le mer. 15 août 2018 13:05:09 +0200, a ecrit: > > 2. What's the proper way to handle such packages? > > Build profiles? You can annotate the build-dep needed for check with > so that one can easily (re)bootstrap the

Re: Is there a tool to debianize for the first time a package from pypi

Hi Fred, You can probably use one of the packaging for one of the Spyder plugins as the basis for src:spyder-kernels. Otherwise, I can do it if you prefer? Le ven. 3 août 2018 à 14:45, PICCA Frederic-Emmanuel < frederic-emmanuel.pi...@synchrotron-soleil.fr> a écrit : > Hello, I need to create

Re: Several questions regarding package tifffile

Le lun. 9 avr. 2018 à 08:46, Andreas Tille a écrit : > Hi, > > I realised that upstream of tifffile[1] switched to Python3. When > inspecting the package I somehow think that its main purpose is rather a > user application than a Python module and thus I would rather rename

Re: Where to put docs of a -doc package for python 2 + 3 modules?

2018-03-12 22:30 GMT+00:00 W. Martin Borgert : > On 2018-03-12 23:15, Thomas Goirand wrote: >> But what now that python-foo is gone? Should I rename the doc package? > > No, but that's just my gut feeling. Definitely not, indeed. The python- prefixes in python-foo and

RFS: pytest-qt/2.3.1-1

the tests * Increase verbosity of autopkgtests Regards, Ghislain Vaillant

RFS: python-mechanicalsoup/0.10.0-1

ig-source target * Normalize the package descriptions * Bump the debhelper version to 11 * Bump the standards version to 4.1.3 * Explicitly disable testing at build time. Reason: Tests require network access * Add pytest-mock to the autopkgtest Depends Regards, Ghislain Vaillant

RFS: python-schema/0.6.7-1

-ignore * Bump the debhelper version to 11 * Bump the standards version to 4.1.3 * Update the copyright years Regards, Ghislain Vaillant

RFS: python-jsonrpc/1.10.8-1 [ITP]

m/modules/python-jsonrpc Debomatic build: http://debomatic-amd64.debian.net/distribution#unstable/python-jsonrpc/1.10.8-1 Changes since the last upload: * Initial release. (Closes: #879050) Regards, Ghislain Vaillant

RFS: sphinxcontrib-doxylink/1.5-1

ts for all supported Python versions * Point the Homepage URI to the GitHub repository * Update the copyright years * Bump the debhelper version to 11 * Bump the standards version to 4.1.3 * Normalize the package descriptions Regards, Ghislain Vaillant

Re: Salsa Vcs-* mass-commits

Will it bypass packages for which such change has already been committed, such as in src:flake8-polyfill (currently under RFS)? Just checking. Cheers, Ghis 2018-02-12 13:41 GMT+00:00 Ondrej Novy : > Hi, > > I would like to mass-commit to all DPMT's projects this: > >

Re: Help needed for Python3 package python3-bd2k which does not install due to syntax error

Le lundi 12 février 2018 à 10:10 +0100, Piotr Ożarowski a écrit : > > python-bd2k[1] which builds fine > > it doesn't if you remove the override to not run Python 3.X tests Indeed, the Python build system will almost always let you "build" a package, even if it is not Python 3 ready. Your only

Re: Move to salsa? Merge modules and apps team?

2018-02-07 8:58 GMT+00:00 Matthias Klose : > On 07.02.2018 08:37, W. Martin Borgert wrote: >> Hi, >> >> how about moving the Python team(s) to salsa? >> And how about merging the modules and apps teams into one? >> >> Moving git packages (modules team) is very easy using >>

Re: Move to salsa? Merge modules and apps team?

Le 7 févr. 2018 07:38, "W. Martin Borgert" a écrit : Hi, how about moving the Python team(s) to salsa? I'd be in favour for that. And how about merging the modules and apps teams into one? Same here. A single Python Team (python-team in salsa) would make sense. Moving

Re: python-markdown and mkdocs circular build-dep

2018-01-11 10:35 GMT+00:00 Dmitry Shachnev : > Hi Brian and list, > > The new release of python-markdown has switched docs building from its own > custom build system to mkdocs. However python-mkdocs itself build-depends on > python3-markdown for tests, which results in a

Re: RFP to ITP: python3-ratelimiter

Source package name should be python-ratelimiter, not python3. Le 10 déc. 2017 21:10, "chrysn" a écrit : I seem to have picked the wrong address for the list, re-sending it to hopefully the right one: (Original mail To: 880...@bugs.debian.org) > retitle 880661 ITP:

Re: python-csb: Please help: Clean target throws UnicodeDecodeError

On 13/11/17 07:41, Andreas Tille wrote: Hi, I'm trying to upgrade python-csb to the new upstream version (in Git[1]). If I try to build it I get: gbp:info: Building with (cowbuilder) for sid gbp:info: Tarballs 'python-csb_1.2.5+dfsg.orig.tar.gz' not found at '../tarballs/' gbp:info:

Re: providing sphinx3-* binaries

On 03/10/17 22:46, Thomas Goirand wrote: On 09/29/2017 01:08 PM, PICCA Frederic-Emmanuel wrote: Hello guyes. override_dh_sphinxdoc: ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS))) nodocs or nodoc I alsa do something like this when there is

Re: pycharm package in debian

On 01/10/17 20:33, Thomas Goirand wrote: On 10/01/2017 09:47 AM, Ghislain Vaillant wrote: Besides, rrom an end-user perspective, I can't picture anyone preferring the (potentially lagging) packaged version over more official means like the Jetbrains app or the snap package, both of which have

Re: pycharm package in debian

Le 1 oct. 2017 15:53, "W. Martin Borgert" <deba...@debian.org> a écrit : On 2017-10-01 08:26, Ghislain Vaillant wrote: > May I ask what would be the benefit for pycharm to be in Debian, when we > already have the official Jetbrains Toolbox App or the snap package as means &

Re: pycharm package in debian

Le 1 oct. 2017 09:49, "Ben Finney" <bign...@debian.org> a écrit : Ghislain Vaillant <ghisv...@gmail.com> writes: > Don't get me wrong, I understand the rationales from a DFSG > perspective. I am just questioning whether users of this particular > piece of s

Re: pycharm package in debian

On 01/10/17 08:38, Paul Wise wrote: On Sun, Oct 1, 2017 at 3:26 PM, Ghislain Vaillant wrote: May I ask what would be the benefit for pycharm to be in Debian, when we already have the official Jetbrains Toolbox App or the snap package as means to install and update the application? I've never

Re: pycharm package in debian

On 01/10/17 02:36, Paul Wise wrote: On Sat, Sep 30, 2017 at 10:35 PM, Julien Puydt wrote: Le 30/09/2017 à 14:22, kamaraju kusumanchi a écrit : Are there any plans to make a debian package of pycharm that is part of official debian? I used their community edition on windows 7 and it is awesome.

Re: Python 3 Statsmodels & Pandas

On 22/09/17 20:32, Diane Trout wrote: On Fri, 2017-09-22 at 10:57 +0200, Piotr Ożarowski wrote: [Diane Trout, 2017-09-21] I made larger changes to statsmodels, by using pybuild instead of the previous multiple targets in debian/rules. you can simplify it even further by using pybuild's

Re: Python 3 Statsmodels & Pandas

On 21/09/17 15:22, Andreas Tille wrote: We somehow need to get some working spatstats to continue with other packages. I second Andreas' opinion. In principle, we'd want all tests to run at build and integration times and we might achieve that at some point during the Buster cycle. Right

Re: pydist and install_requires

On 17/08/17 10:43, PICCA Frederic-Emmanuel wrote: Hello Andrey Isn't just adding the package names to Depends easier? I just want this to be automatically generated and "upstreamable". So do you have python-opengl, python-pyqt5 etc in Build-Depends? yes, I think that I found the problem

Re: a few quick questions on gbp pq workflow

On 06/08/17 19:56, Scott Kitterman wrote: Generally when I find shortcomings in the tarball, I file bugs upstream. In general, I've found upstream developers to be accepting of such changes. Same here. There's no need to DFSG the tarball if you can rebuild the docs. The best way to

Re: a few quick questions on gbp pq workflow

On 06/08/17 19:53, Jeremy Stanley wrote: Why would you need to repack a tarball just because it contains prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all for rebuilding those at deb build time just to be sure you have the right deps packaged too, but if the ones in the tarball

Re: dpkg-buildpackage -B fails

On 04/08/17 10:39, Gudjon I. Gudjonsson wrote: Hi list I wanted to fix my terrible track record lately, fix bugs and update my packages but I ran into problems with sbuild on my package eric. dpkg-buildpackage -B fails with the following error message: dpkg-genbuildinfo --build=any

Re: building manpages via setup.py

On 02/08/17 10:45, PICCA Frederic-Emmanuel wrote: First, that's very speculative. Second, that's upstream's problem. # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation

Re: building manpages via setup.py

On 02/08/17 09:55, PICCA Frederic-Emmanuel wrote: PYTHONPATH=. sphinx-build -N -b html One can also use the sphinx-generated Makefile if available: PYTHONPATH=$(CURDIR) $(MAKE) -C html Both are simple one-liners and do not rely on pybuild. Yes it works but this is fragile since

Re: building manpages via setup.py

On 02/08/17 09:19, PICCA Frederic-Emmanuel wrote: At the end of the day, it is just a matter of providing an appropriate PYTHONPATH, regardless of whether pybuild is used or not. Yes but to avoid the multiplications of way to provide this PYTHONPATH. For the vast majority of packages, the

Re: building manpages via setup.py

On 02/08/17 09:03, PICCA Frederic-Emmanuel wrote: Perhaps the LibraryStyleGuide should be updated to reflect on this change? I believe we are still advising explicit http_proxy / https_proxy exports prior to running sphinx-build. And running sphinx-build does not work expecially if there is

Re: building manpages via setup.py

On 02/08/17 08:44, Piotr Ożarowski wrote: [PICCA Frederic-Emmanuel, 2017-08-02] you can drop it, PYTHONPATH and http_proxy should be set by pybuild Is it true for jessie I need to support jessie and stretch And even debian7... I didn't test it even for unstable, but IIRC pybuild

Re: building manpages via setup.py

On 01/08/17 15:15, PICCA Frederic-Emmanuel wrote: Hello, I am working on the pyfai package. This pacakge contain one module with extensions (the important point) The new upstream version 0.14.0 provide a build_man target via the setup.py So in ordert to generate the doc I need to do python

News regarding the ITP for python-coloredlogs

On Sun, 5 Feb 2017 23:51:57 +0530 Gaurav Juvekar wrote: > On Sun, 5 Feb 2017 18:24:27 +0100 Adam Borowski wrote: > > However, the second part, converting logs to HTML, is not only redundant > > with ansi2html (package colorized-logs, split out from

Re: spyder3 missing rope dependency

On Sun, 2017-06-04 at 09:47 -0400, kamaraju kusumanchi wrote: > On Sun, Jun 4, 2017 at 5:00 AM, Ghislain Vaillant <ghisv...@gmail.com> wrote: > > A new version of Spyder was also uploaded to experimental (3.1.4), > > which adds the Python 3 rope dependency. Despit

Re: spyder3 missing rope dependency

On Sun, 2017-06-04 at 00:40 -0400, kamaraju kusumanchi wrote: > Launching spyder3 gives the following error > > You have missing dependencies! > rope >=0.9.4: None (NOK) > Please install them to avoid this message. > > I see a python-rope package but no analogous python3-rope. Any idea > how to

Re: [Python-modules-team] partd_0.3.8-1_source.changes ACCEPTED into unstable

On Fri, 2017-06-02 at 11:35 -0400, Barry Warsaw wrote: > Hi Diane, > > On Jun 02, 2017, at 05:48 AM, Debian FTP Masters wrote: > > > partd (0.3.8-1) unstable; urgency=medium > > . > > * Switch from git-dpm to gbp > > I may be misremembering our previous discussions on the topic, but we all

Re: Joining the team

On Sat, 2017-05-20 at 17:40 +0200, sab wrote: > > On 07/05/2017 17:30, sab wrote: > > > > On 06/05/2017 17:14, Piotr Ożarowski wrote: > > > [sab, 2017-05-06] > > > > 'https://anonscm.debian.org/git/python-modules/packages/python-zxcvbn.git/': > > > > > > >

Re: python-parse-type

On Tue, 2017-05-16 at 12:36 +0200, Piotr Ożarowski wrote: > [Brian May, 2017-05-16] > > python-enum - robust enumerated type support in Python > > ah, that's why python-enum34 name was chosen, there's even > "Breaks: python-enum" - I've missed it because it's no longer in > unstable Indeed both

Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

On Sun, 2017-04-16 at 18:09 +0200, Mattia Rizzolo wrote: > On Sun, Apr 16, 2017 at 05:50:54PM +0200, Hugo Lefeuvre wrote: > > I introduced an additional binary package for this script because I thought > > people cold have found it useful. But, right, everything considered I should > > better drop

Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

Also, the `cpuinfo` utility can be invoked with `python[3] -m cpuinfo` according to the upstream README [1]. So, I am not convinced of the benefit of introducing an additional binary package (py-cpuinfo) for something the library packages already provide. [1]

Re: Fwd: next version of csvkit

On 02/04/17 08:39, Vincent Bernat wrote: ❦ 1 avril 2017 19:42 -0400, Sandro Tosi : It's not at all clear where [1] came from. The lintian changelog [3] does not give a bug reference and I couldn't find a bug. it's just a few lines down in the changelog:

Re: PyPI source or github source?

On Tue, 2017-03-14 at 08:32 +1100, Brian May wrote: > Scott Kitterman writes: > > > Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in > > so > > that the sdist is complete when I point out the issue. > > I have had some people who do argue that

Re: PyPI source or github source?

On Sun, 2017-03-12 at 10:53 +0800, Paul Wise wrote: > On Sun, Mar 12, 2017 at 10:19 AM, Brian May wrote: > > > Sure, you could argue that PyPI source packages should contain > > everything the github package does. In fact there is a PyPI tool to help > > get the MANIFEST.in correct for such

Re: Moving a package from collab-maint to python-modules

On Sat, 2017-03-11 at 18:14 +, Scott Kitterman wrote: > > On March 11, 2017 6:52:59 AM EST, Ghislain Vaillant <ghisv...@gmail.com> > wrote: > > On Sat, 2017-03-11 at 11:24 +, Christopher Hoskin wrote: > > > Hello, > > > > > > I'd like to

Re: Moving a package from collab-maint to python-modules

On Sat, 2017-03-11 at 11:24 +, Christopher Hoskin wrote: > Hello, > > I'd like to package python-jsonpointer for Debian. The filer of the RFP (Bug > #754296) Pietro Battiston, has created a repository at > > https://anonscm.debian.org/cgit/collab-maint/python-jsonpointer.git > > but has no

Re: I want to maintain my current packages within the team

On 10/03/17 08:27, Thomas Güttler wrote: Hi, I am following this instruction: http://python-modules.alioth.debian.org/policy.html Yes, I accept the above policy. Yes, collaborative maintenance is preferred. Here is what I want to package: https://github.com/guettli/reprec Up to now

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

On Thu, 2017-03-09 at 21:13 +1100, Brian May wrote: > Brian May writes: > > > git read-tree --reset -u upstream > > git reset -- debian > > git checkout debian > > git rm debian/.git-dpm > > I have tried these steps on python-mkdocs in the debian/experimental > branch, and then

Re: Under which umbrella should I package my Python IDE for beginners (Thonny)?

On Thu, 2017-03-09 at 09:58 +0200, Aivar Annamaa wrote: > Hi! > > I've developed a Python IDE for beginners, Thonny (http://thonny.org) > and I intend to package it for Debian > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857042). Nice. > The application would consist of a Python 3

RFS: pytest-qt/2.1.0-1

est-qt.git Changes since the last upload:   * Initial release. (Closes: #854365) Regards, Ghislain Vaillant

Re: Re: Naming convention for -doc package

[Piotr Ożarowski] > > For instance, I have a source package (pytest-qt) which builds a Python > > 3 binary package and its corresponding documentation. Right now, they > > are respectively named python3-pytest-qt and pytest-qt-doc. > > I'd use python-modulename-doc even for new packages that

Re: Naming convention for -doc package

On Thu, 2017-02-09 at 18:58 -0500, Sandro Tosi wrote: > On Thu, Feb 9, 2017 at 5:40 PM, Ghislain Vaillant <ghisv...@gmail.com> wrote: > > On Thu, 2017-02-09 at 16:51 -0500, Sandro Tosi wrote: > > > On Thu, Feb 9, 2017 at 3:17 PM, Ghislain Vaillant <ghisv...@gmail.com

Re: Naming convention for -doc package

On Thu, 2017-02-09 at 16:51 -0500, Sandro Tosi wrote: > On Thu, Feb 9, 2017 at 3:17 PM, Ghislain Vaillant <ghisv...@gmail.com> wrote: > > Now that new packages are targeting the Buster cycle, and that Python 2 > > packages should no longer be built, > > this is n

Naming convention for -doc package

Just to get the opinion from the team, Now that new packages are targeting the Buster cycle, and that Python 2 packages should no longer be built, how should the corresponding -doc packages be named? For instance, I have a source package (pytest-qt) which builds a Python 3 binary package and its

Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

I know the discussion is leaning towards replacing usage of git-dpm with gbp-pq. I have nothing against it but, since we are talking about solutions for a git-centric workflow, has anyone considered the dgit- maint-merge workflow [1]? It is very well documented and would simplify team-packaging

Re: Team upload for python-jedi

[Piotr Ożarowski] FYI: I uploaded 0.10.0~git1+f05c071-1 (without running tests during build for now) Great. Too bad for the wasted efforts on my end then. *sigh* As far as testing is concerned, I am forwarding the set of patches which were necessary to get the tests working on top of 0.9.0.

Re: Team upload for python-jedi

On Thu, 2017-01-19 at 20:45 +0300, Dmitry Shachnev wrote: > Hi Ghislain, > > On Wed, Jan 18, 2017 at 05:53:05PM +, Ghislain Vaillant wrote: > > Ok, I have got a working package fixing the RC. However, whoever did > > the migration from svn to git forgot that the

Re: Team upload for python-jedi

I apologize for insisting here, but I need this RC fixed ASAP for another package relying on it and have no idea what to do now. Thanks, Ghis On Wed, 2017-01-18 at 17:53 +, Ghislain Vaillant wrote: > On Wed, 2017-01-18 at 13:37 +0100, Piotr Ożarowski wrote: > > Hi, > >

Re: RFS: python-cartopy/0.14.2-2

, and James proposed a different solution based on a subprocess call to dpkg-architecture. Do you guys have any suggestion of a more Pythonic way to achieve this? Cheers, Ghis On Tue, 2017-01-17 at 23:36 +, Ghislain Vaillant wrote: > On Tue, 2017-01-17 at 20:39 +, James Clarke wr

Re: Team upload for python-jedi

On Wed, 2017-01-18 at 13:37 +0100, Piotr Ożarowski wrote: > Hi, > > [Ghislain Vaillant, 2017-01-18] > > Would you be ok if I push the changes required to fix #830399 and > > #841043 for src:python-jedi and prepare a team-upload? > > > > I need the RC fixed for

Team upload for python-jedi

Hi Piotr, Would you be ok if I push the changes required to fix #830399 and #841043 for src:python-jedi and prepare a team-upload? I need the RC fixed for the packaging of spyder. Cheers, Ghis

status of python-freetype packaging

Hi Daniel, Any news on this? Do you need any help? Ghis

Re: help2man usage with pybuild / debhelper packaging workflow

On 04/06/16 05:25, Paul Wise wrote: On Sat, Jun 4, 2016 at 12:30 AM, Christian Seiler wrote: Well, you could add a custom target to debian/rules that calls help2man for all these scripts - so that you as a maintainer can refresh the manpages every now and then. (And store them in debian/ in

Re: help2man usage with pybuild / debhelper packaging workflow

On 03/06/16 17:59, Wookey wrote: On 2016-06-03 18:30 +0200, Christian Seiler wrote: On 06/03/2016 06:25 PM, Ghislain Vaillant wrote: And I don't mind for a handful of scripts. But what if you have 20 or 30? Well, you could add a custom target to debian/rules that calls help2man for all

Re: help2man usage with pybuild / debhelper packaging workflow

On 03/06/16 17:10, Wookey wrote: On 2016-06-03 16:43 +0100, Ghislain Vaillant wrote: Dear all, Are there any successful examples of integration of help2man with a pybuild / debhelper workflow for an arbitrary number of scripts? help2man breaks cross-building so is best avoided if you can

help2man usage with pybuild / debhelper packaging workflow

Dear all, Are there any successful examples of integration of help2man with a pybuild / debhelper workflow for an arbitrary number of scripts? The only close example I could find was the stdeb package, but I am dealing with many more scripts and I cannot afford to list them all individually by

Re: Maintenance of pydap

to introduce a new source package for it (which I am happy to maintain) and keep the old source package alive until all reverse dependencies relying on 2.x eventually move on. Hoe does that sound? Ghis On 28/01/16 09:50, Ghislain Vaillant wrote: I believe upstream has moved on from the API of 2

Re: Bug in pybuild's handling of --install-lib? [Was: Re: entry-point script and private module install directory]

On 12/05/16 13:16, Piotr Ożarowski wrote: [Ghislain Vaillant, 2016-05-12] Is this a bug in pybuild or am I missing something? you're missing my second reply¹ [¹] https://lists.debian.org/debian-python/2016/05/msg00043.html Indeed, sorry for the noise. Thanks again for the support. Ghis

Bug in pybuild's handling of --install-lib? [Was: Re: entry-point script and private module install directory]

On 12/05/16 09:22, Ghislain Vaillant wrote: On 11/05/16 18:55, Piotr Ożarowski wrote: you can create a wrapper or patch /usr/bin script to sys.path.append('/usr/share/pyfr') but the easiest solution is to install the script to /usr/share/pyfr/ (if the module is "pyfr" as well, sim

Re: entry-point script and private module install directory

On 11/05/16 18:55, Piotr Ożarowski wrote: [Ghislain Vaillant, 2016-05-11] Dear all, I have a package (pyfr), which is meant to be used as a command-line application only. The main script (pyfr) is installed via setuptools' entry_points['console_scripts'], which generates the entry-point

entry-point script and private module install directory

Dear all, I have a package (pyfr), which is meant to be used as a command-line application only. The main script (pyfr) is installed via setuptools' entry_points['console_scripts'], which generates the entry-point automatically and places it under /usr/bin. However, when I install the

Re: Request to join the DPMT

Bumping this and wishing someone with administrative rights could answer my request to join the team. Thanks. Ghislain

Request to join the DPMT

Hello DPMT members, I would like to join the DPMT. I am essentially involved in the Debian Science Team, but I am also working with Python dependencies which are more generic and would be better suited for team-maintenance here. My alioth account is ghisvail-guest. I did request to join via

Fwd: Maintenance of pydap

Forwarding to d-python, as it seems like a more appropriate place to discuss this matter. Forwarded Message Subject: Maintenance of pydap Date: Mon, 25 Jan 2016 08:00:32 + From: Ghislain Vaillant <ghisv...@gmail.com> To: mo...@debian.org CC: python-mod

Re: Maintenance of pydap

for python-mpltoolkits.basemap. Thoughts? Ghis On 28/01/16 09:26, Sandro Tosi wrote: for a start, you can try to get upstream to reply to this (old) question: https://groups.google.com/forum/#!topic/pydap/6A6q-Y6qwtE On Thu, Jan 28, 2016 at 9:24 AM, Ghislain Vaillant <ghisv...@gmail.com>

Re: How to use Debian packaged lapack in python-miso

Hi Andreas, Could you provide an http link to the upstream sources please ? Cheers, 2015-02-16 13:59 GMT+00:00 Andreas Tille andr...@an3as.eu: Hi, I intent to package python MISO on behalf of the Debian Med team. The packaging code is in SVN at Vcs-Svn: svn://

Re: Fwd: [iva] - Python 3 code depends on pysam

At worst, can't you just disable the test suite for the Python 3 builds ? Pybuild should allow to do that easily. Ghis 2014-11-24 16:36 GMT+00:00 Jorge Sebastião Soares j.s.soa...@gmail.com: Hi guys, So essentially the package build halts when it tries to run the test suite: This is the

ITP: pyrecord -- Pythonic record types

Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name : pyrecord Version : 1.0.0~rc1 Upstream Author : Gustavo Narea * URL : https://pythonhosted.org/pyrecord/ * License: Apache-2.0 Programming Lang: Python

packaging advice for cmake generated python wrapper

Hi guys, I am currently trying to package the ISMRMRD library (#732360), which uses cmake for its build system and generates the c++ library and corresponding Java and Python wrappers using SWIG. I was wondering how that would play along with Debian packaging and what would be the best approach