Python: Including Nosetest

Dear lists, I am working on a package (python-pywcs) that may include a "nosetest" which I want to run before installation. For this, I put the following line into debian/rules (for debhelper): override_dh_auto_test: nosetest However, when I try to build the package, I get the error ==

Re: Python: Including Nosetest

Am 18.10.2011 15:10, schrieb Yaroslav Halchenko: > well -- if you discover some other way -- please let me know. >From elsewhere , I got the hint to try python setup.py build_ext -i which builds the extension in-

RFS: python-pywcs

is command: dget -x http://mentors.debian.net/debian/pool/main/p/python-pywcs/python-pywcs_1.10-1.dsc I would be glad if someone uploaded this package for me. Best regards, Ole Streicher -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe&quo

Re: Python: Including Nosetest

Vincent Bernat writes: > You should not run test against the source package. Instead, you should run > tests against the yet-to-be-installed version. The python package in question is a wrapper for some shared library (wcslib). The goal of the tests is not in the first place that they forgot so

RFS: python-cpl

Dear mentors, I am looking for a sponsor for my package "python-cpl". * Package name: python-cpl Version : 0.3.5-1 Upstream Author : Ole Streicher * URL : http://www.aip.de/~oles/python-cpl/index.html * License : GPL-2 Section :

Re: RFS: python-pywcs

Dear Sylvestre, Am 03.11.2011 21:22, schrieb Sylvestre Ledru: > Yes, you are a member. I just checked and you are indeed listed as a member. > About the VCS issue, it is likely to be a configuration issue on your > side. Could you drop me a message when it is solved? >> I would feel a bit unluck

Re: RFS: python-pywcs

Am 04.11.2011 09:58, schrieb Sylvestre Ledru: > The issue is on your side (ie it is not alioth's fault but yours). OK; I created a git repository for python-pywcs and committed everything for python-pywcs. Since I am not too experienced with git: could you please check this before I store the rem

RFR: python-astropy -- Core functionality for performing astrophysics with Python

Dear mentors, I am looking for review for my package "python-astropy". I still don't need a sponsor since the packaged version is just a beta version, with the final release expected soon. To speed up the process, I'd however like to start to sort out packaging problems already now. * Package nam

Bug#758720: ITP: python-astropy-helpers -- Utilities to build and install Astropy affiliated packages

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, debian-python@lists.debian.org * Package name: python-astropy-helpers Version : 0.4.1 Upstream

RFP: glueviz -- Linked data visualization in Python

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbuggs-CC: debian-as...@lists.debian.org, debian-scie...@lists.debian.org, debian-python@lists.debian.org * Package name: glue Version : 0.3 Upstream Author : Chris Beaumont

multiprocessing.queues.Queue does not work in pbuilder?

Hi, I am trying to get the release candidate for python-astropy packaged. The packaging includes a number of tests, where many fail in pbuilder, which can be traced back to: $ sudo pbuilder login # apt-get install python # python Python 2.7.9 (default, Dec 11 2014, 08:58:12) [GCC 4.9.2] on linux

Re: multiprocessing.queues.Queue does not work in pbuilder?

Julian Taylor writes: > On 31.01.2015 11:32, Dimitri John Ledkov wrote: >> Hello, >> >> On 29 January 2015 at 09:01, Ole Streicher wrote: >>> Hi, >>> >>> I am trying to get the release candidate for python-astropy >>> packaged. The

image-file-in-usr-lib

Hi, some of the package I maintain (namely python-astropy), or want to package, contain images within their python source directories. When installed using the normal setup, these images get installed in /usr/lib, leading to the lintian warning shown in the subject. Is there a simple way to avoid

pybuild (Re: image-file-in-usr-lib)

Ben Finney writes: > Ole Streicher writes: > Installing the non-program files to ‘/usr/share/foopackage/images/’ (for > example) is simple enough, using ‘dh_install’. I am using pybuild, and I am wondering why it doesn't do this automatically (maybe with some help)? Generally: p

Re: pybuild (Re: image-file-in-usr-lib)

Matthias Klose writes: > The FHS never talks about putting *code* into /usr/share. So pybuild > is right from my point of view to put it in /usr/lib. I think the Debian Policy is quite clear here: | [...] However, when a directory is entirely composed of | architecture-independent files, it shou

Re: pybuild (Re: image-file-in-usr-lib)

Charles Plessy writes: > indeed, this is a recent change in the Policy (see > bugs.debian.org/741304). Putting pure python packages (Architecture: all) into /usr/lib is IMO still not coved by the Debian Policy. > Probably Lintian is lagging behind. Maybe somebody can ping bug #415558 ? I'll do

Bug#785015: ITP: wcsaxes -- Framework for plotting astronomical and geospatial data

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: WCSAxes Version : 0.3 Upstream Author : Thomas Robitaille * URL : https://github.com

pybuild --pytest: empty directory?

Hi, I am trying to automatically run pytest from pybuild (by specifying "dh_auto_test -- --test-pytest" in override_dh_auto_test). However, the tests do not run. When I look into the log, I see: I: pybuild base:170: cd /.pybuild/pythonX.Y_2.7/build; python2. = test se

Astropy affiliated packages tutorial

Hi all, the Astropy affiliated packages [1] are a great opportunity to get people involved in Debian packaging: They follow some common rules, tend to have a similar structure (since there is a template for these packages), and the project has a good popularity. Also, all these packages would add

Fwd: ITP: yt -- Astrophysical Simulation Analysis and Visualization package

This ITP did not make its way to the mailing lists. Re-sending... Forwarded Message Subject: ITP: yt -- Astrophysical Simulation Analysis and Visualization package Date: Thu, 25 Jun 2015 15:02:56 -0500 From: Kacper Kowalik To: sub...@bugs.debian.org Package: wnpp

Fwd: ITP: Sherpa -- Modeling and fitting in Python

X-Debbugs-Cc is quite picky, therefore a manual forward to the relevant mailing lists: Weitergeleitete Nachricht Betreff:Sherpa -- Modeling and fitting in Python Datum: Thu, 13 Aug 2015 15:09:03 +0200 Von:Christoph Deil An: sub...@bugs.debian.org Package: w

Re: [Debian-astro-maintainers] glueviz_0.5.2+dfsg-1_amd64.changes ACCEPTED into unstable

Hi Josue, Debian FTP Masters writes: > Changes: > glueviz (0.5.2+dfsg-1) unstable; urgency=medium >* debian/control: Added Conflicts section in order to avoid overwrite > files from glue-sprite (Closes: #793931). One comment on this: I think it is just too simple here to just add a "Co

Re: [Debian-astro-maintainers] glueviz_0.5.2+dfsg-1_amd64.changes ACCEPTED into unstable

Dmitry Shachnev writes: > On Sun, 16 Aug 2015 15:12:34 +0200, Ole Streicher wrote: >> One comment on this: I think it is just too simple here to just add a >> "Conflicts" here. Did you investigate the other optione? >> >> * Try to convince glue-sprite to c

Bug#802457: ITP: APLpy -- Astronomical Plotting Library in Python

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: APLpy Version : 1.0 Upstream Author : Thomas Robitaille and Eli Bressert * URL : http

Bug#802468: ITP: spectral-cube -- Read, manipulate, analyze, and write astronomical data cubes

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: spectral-cube Version : 0.3 Upstream Author : Adam Ginsburg et al. * URL : http://spectral

Bug#803038: ITP: ccdproc -- Basic data reductions of astronomy CCD images

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: ccdproc Version : 0.3.3 Upstream Author : Steve Crawford * URL : http

Bug#803741: ITP: reproject -- Reproject astronomical images with Python

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: reproject Version : 0.2 Upstream Author : Thomas P. Robitaille, Steve Crawford * URL : http

Bug#804520: ITP: astroscrappy -- Optimized Cosmic Ray Annihilation in Python

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: astroscrappy Version : 1.0.3 Upstream Author : Curtis McCully * URL : https://github.com

Bug#804649: ITP: astroml-addons -- Python Machine Learning library for astronomy (performance addons)

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: astroml-addons Version : 0.2.2 Upstream Author : Jake VanderPlas * URL : http

Bug#805853: ITP: photutils -- Astropy affiliated package for image photometry

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: photutils Version : 0.1 Upstream Author : Larry Bradley and Brigitta Sipocz * URL : https

Bug#806694: ITP: spectutils -- Base classes and utilities for astronomical spectra in Python

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: specutils Version : 0.1 (to be updated) Upstream Author : Wolfgang Kerzendorf * URL : https

Bug#807309: ITP: montage-wrapper -- Python wrapper for the Montage mosaicking toolkit

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: montage-wrapper Version : 0.9.8 Upstream Author : Thomas Robitaille * URL : hhttp

Bug#807739: ITP: sunpy -- Software library for solar physics based on Python

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: sunpy Version : 0.6.1 Upstream Author : Sunpyy Developers * URL : https://sunpy.org

Bug#807778: ITP: pyephem -- Compute positions of the planets and stars

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: pyephem Version : 3.7.6.0 Upstream Author : Brandon Rhodes * URL : http://rhodesmill.org

Request to join DPMT

Hello all, I would like to join the DPMT. I already have packages some Python packages (python-astropy and many of its affiliated packages, python-pywcs, python-astroml) under the hood of the Debian-Astro team. In future I probably need to package dependencies like Bottleneck that are not specific

Re: Request to join DPMT

Scott Kitterman writes: > On Wednesday, January 06, 2016 04:11:18 PM Ole Streicher wrote: >> I already applied directly in alioth, but didn't get a response. > According to Alioth, you're in the team already. Oh, I see. I didn't check it again before I processed the

Bug#813147: ITP: emcee -- Kick ass affine-invariant ensemble MCMC sampling for Python

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: emcee Version : 2.1.0 Upstream Author : Dan Foreman-Mackey <https://github.com/dfm>

Bug#813733: ITP: pysynphot -- Python Synthetic Photometry Utilities

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: pysynphot Version : 0.9.7 Upstream Author : Vicki Laidler et al. * URL : http

Bug#813896: ITP: asdf -- Python tools to handle ASDF files

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: asdf Version : 1.0.1 Upstream Author : Erik Bray, Michael Droettboom * URL : https

Bug #820811: ITP: python-fitsio -- Python wrapper on the CFITSIO library

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: python-fitsio Version : 0.9.8 Upstream Author : Eric Sheldon * URL : https://github.com

Bug#823598: ITP: ginga -- Astronomical FITS file viewer

Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: ginga Version : 2.5.20160420043855-1 Upstream Author : Eric R. Jeschke * URL : https

Bug#848112: Python-skimage depends on unavailable package python-dask

package: python-skimage version: 0.12.3-2 severity: serious The Python 2 version of skimage depends on a package "python-dask" that is not available in Debian. There is a patch that make the dependency optional; however the dependency was not removed afterwards. For Python 3, this seems to work.

Re: PyPI source or github source?

Brian May writes: > Should we be using PyPI as our source of packages? Or github? I already had packages that use a helper to generate the version information from the git repository, and therefore need the git metadata to build from source. I could solve this with a "fake" helper that uses debia

How to package for jython?

Hi, I have a large Java package (as a jar in /usr/share/java) that is accompanied with some Jython intergration (Python file). Upstream provides a small script that adds the jar to the classpath, and starts jython with a local python.path. How should I package this for Jython? * where should th

Re: MBF for deprecating Python2 usage

ba...@debian.org writes: > On Aug 3, 2017, at 23:23, Scott Kitterman wrote: > You’re right that folks will still need Python 2 after 2020, and that > their best option may be to build it themselves, but I don’t think > they’ll be building and installing some old Debian package. Instead > they may

Re: MBF for deprecating Python2 usage

Diane Trout writes: >> What I am opposing is the suggestion to install, in the near to >> medium >> term, a command of exactly the same name that has subtly similar but >> incompatible behaviour, when that behaviour *already* has a command – >> ‘python3’ – that is widely used by those who need it.

Bug#879683: ITP: radio-beam -- Tools for radio beam io and manipulation

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: radio-beam Version : 0.1 Upstream Author : Eric Koch, Adam Ginsburg et al. * URL : https://github.com/radio-astro-tools

Bug#884598: ITP: stsci.tools -- Miscellaneous Python tools for astrophysics from STScI

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-as...@lists.debian.org,debian-python@lists.debian.org Control: block 711038 by -1 * Package name: stsci.tools Version : 3.4.3 Upstream Author : Space Telescope Science Institute * URL : http

Packaging with 2to3

Hi, I want to create a package (pyraf, #711038) for both Python2 and Python3. While the package itself is still not Python 3 compatible, upstream says that running through 2to3 will make it; however the resulting code is not Python 2 compatible anymore. Is there a way to instruct pybuild to run t

Python 2 removal strategy

Hi, I am the maintainer of the "python-astropy" package, that currently creates packages for both Python 2 and Python 3. Both packages have a number of reverse dependencies. Recently, upstream announced a new version 3.0 of astropy, which supports Python 3 only, and I think of the best mid-term s

Bug#887020: ITP: pytest-remotedata -- Pytest plugin to control access to online data files

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name: pytest-remotedata Version : 0.1 Upstream Author : Thomas Robitaille * URL : https://github.com/astropy/pytest-remotedata

Bug#887021: ITP: pytest-doctestplus -- Pytest plugin providing advanced doctest features

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name: pytest-doctestplus Version : 0.1.2 Upstream Author : Thomas Robitaille * URL : https://github.com/astropy/pytest

Bug#887023: ITP: pytest-openfiles -- Pytest plugin to check for files left open at the end of a test run

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name: pytest-openfiles Version : 0.2.0 Upstream Author : Thomas Robitaille * URL : https://github.com/astropy/pytest-openfiles

Bug#887024: ITP: pytest-arraydiff -- Pytest plugin that enables the generation and comparison of data arrays

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name: pytest-arraydiff Version : 0.1 Upstream Author : Thomas Robitaille * URL : https://github.com/astrofrog/pytest-arraydiff

Bug#889054: ITP: pytest-astropy -- Metapackage to resolve pytest dependencies for Astropy

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name: pytest-astropy Version : 0.2.1 Upstream Author : Thomas Robitaille * URL : https://github.com/astropy/pytest-astropy

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

Piotr Ożarowski writes: > [W. Martin Borgert, 2018-02-07] >> And how about merging the modules and apps teams into one? > > I don't understand this, though. Why you want to merge them? > Sure, packaging Python applications is very similar to packaging > libraries but the difference is very signifi

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

Thomas Goirand writes: > On 03/13/2018 12:29 AM, Ghislain Vaillant wrote: >> Imo, we should just make it clear in policy that source packages >> should be named `foo` or `python-foo`, >> and corresponding doc packages should be named `foo-doc` or `python-foo-doc`. > > Very often, "foo" is already

pybuild: how to get the build directory name

Hi, one of my Python packages has a test script under debian/tests that I want to run at build time. The problem is now how to get the name of the actual build directory, which is needed to be put into the PYTHONPATH: Up to now, I did the following in debian/rules: test-python%: HOME=/tm

Re: pybuild: how to get the build directory name

Dear Piotr, Piotr Ożarowski writes: > or even better (without using pybuild's internal paths): > > override_dh_auto_test: > dh_auto_test -- --system=custom --test-args '{interpreter} > {dir}/debian/tests/pyraf-test.py' That is optimal for me. Thank you very much for the hint! Best rega

apt.Cache.update with alternative sources.list

Hi, I need some access (as normal user) to an apt cache with an alternative sources.list (those in /etc/blends/ installed by blends-dev), but I have problems to find out how to use it. I first tried to just specify the alternative source file: ``` >>> import apt >>> c = apt.Cache() >>> c.update(

Extra debian.blends Python package

Hi, I am currently rewriting part of the blends-dev package which is used for maintaining Debian Pure Blends into Python. This however comes out some abstractions of Blends (namely the tasks infrastructure) that may be re-usable on other places, f.e. in the blends.d.o web service. So it is probabl

PLY problem

Hi, I have (still) problems with PLY generated files in the astropy package: they are just not generated, and I have no idea how to generate them correctly. For example, there are the files astropy/coordinates/angle_lextab.py astropy/coordinates/angle_parsetab.py which are now cleaned up in d/cl

Problem with pybuild and pytest

Hi, For one of my packages (sunpy), I want to complete the switch to pybuild by removing the custom (and quite unperfect) dh_override_auto_test rule. Currently, I have the following lines in d/rules: override_dh_auto_test: python -m pytest sunpy -k "not figure and not online" pyt

Re: python-drizzle is in two repositories on Salsa

Hi Andreas and Pythonies, Andreas pointed me to the case that we have two repositories "python-drizzle" which is confusing: https://salsa.debian.org/python-team/modules/python-drizzle/ https://salsa.debian.org/debian-astro-team/python-drizzle The reason for this is that in 2016, I took the "free

Re: Upstreams dropping Python 2 support

Dmitry Shachnev writes: > Sphinx 2.0 will also drop Python 2.7 support, so I am going to make the > “sphinx” source package ship only python3-sphinx, and introduce the new > source package (“sphinx-python2”?) which will ship only python-sphinx. > > Eventually I will also do a mass bug filing, but

Problem with pybuild and pytest (repost)

Hi, I already posted this two weeks ago, but didn't get a response yet, and thus it remains unsolved: For one of my packages (sunpy), I want to complete the switch to pybuild by removing the custom (and quite unperfect) dh_override_auto_test rule. Currently, I have the following lines in d/rules

Re: Problem with pybuild and pytest (repost)

Piotr Ożarowski writes: >> >From the pybuild wiki page, I learned to do instead the override: >> >> export PYBUILD_TEST_ARGS=-k "not figure and not online" >> >> However, then the tests are not found anymore and the test step fails: > > 1) remove HOME line from debian/rules, pybuild sets one > 2

Re: Matplotlib 3.0 - update ok?

ghisv...@gmail.com writes: > Indeed. Note that NumPy has already published plans to become Python 3 > only in the near future, so the deprecation of Python 2 in the > scientific stack will happen eventually. > > I just don't think it should be rushed into the Buster release cycle. If we really wan

dh_python3-ply lintian warning

Hi, when I use dh_python3-ply in d/rules like this: --8<--- override_dh_python3: dh_python3-ply $$(find $(PYBUILD_DESTDIR_python3) -name '*tab.py') dh_python3 --8<--

Upcoming pytest-4 problems

Hi all, since the EOL of Python 2 is approaching, the (python-) "astropy" upstream has split its development into a Python 2.7 legacy branch (2.0.X) and the normal development (3.X), where the legacy branch does get only maintenance now. Since many Python 2 packages still depend on astropy, I spli

Re: [Python-modules-team] Bug#914592: Upcoming pytest-4 problems

Hi Ondrej, On 26.11.18 21:29, Ondrej Novy wrote: > my plan is: > > * keep 3.x for Buster > * upgrade to >= 4.x just after Buster release > > Because we are going to drop Python after Buster release, I think it's > perfectly fine that Astropy (Py2 version) will not support Pytest 4.x. Thanks

Re: [Python-modules-team] Bug#914592: Upcoming pytest-4 problems

On 27.11.18 09:35, Ondrej Novy wrote: > út 27. 11. 2018 v 8:46 odesílatel Ole Streicher <mailto:oleb...@debian.org>> napsal: > > Thanks, however it turns out that this will unfortunately not work for > me: from astropys POV, pytest seems to be broken in versions

Bug#915786: ITP: sphinx-automodapi -- Sphinx extension for generating API documentation

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name : sphinx-automodapi Version : 0.9 Upstream Author : Thomas Robitaillie * URL : https://astropy.org/sphinx-automodapi

Numpy migration?

Hi all, Since a few days, a new RC is stalled in unstable: testing: 1:1.15.4-2 unstable: 1:1.16.0~rc1-3 The reason that it can't migrate is that it breaks the CI tests of several packages in testing. For example astropy (where I am the uploader), and its dependencies. The CI test failures were

Re: Numpy migration?

Mattia Rizzolo writes: > The way forward in cases like these is for the package that originally > cuased the breakage (i.e. numpy) to declare a versioned Breaks on the > borken and now fixed package (i.e. astropy (<< 3.1-1)). This way > britney and debci will know they have to test numpy and astr

Re: Numpy migration?

Mattia Rizzolo writes: > The way forward in cases like these is for the package that originally > cuased the breakage (i.e. numpy) to declare a versioned Breaks on the > borken and now fixed package (i.e. astropy (<< 3.1-1)). This way > britney and debci will know they have to test numpy and astro

Re: Numpy migration?

Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote: >> I'll do tonight. It however looks a bit suboptimal: when the CI test >> with a new version fails for an old reverse dependency, then the new >> version obviously breaks that old

Re: Numpy migration?

Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 08:30:28PM +0100, Ole Streicher wrote: >> This would remove one dependent party (release team) from the chain of >> blocking causes for the migration. > > Given your email on -mentors a few minutes ago I see there are troubles

Re: Numpy migration?

Mattia Rizzolo writes: > On Sun, Jan 06, 2019 at 05:07:41PM +0100, Ole Streicher wrote: >> Now it turns out that there is a new migration problem, which is aplpy: >> Current aplpy (2.0~rc2-2) CI test works well > > You probably mean aplpy 1.1.1-4. No, I meant the one above (

Re: Numpy migration?

Mattia Rizzolo writes: > On Mon, Jan 07, 2019 at 09:03:11AM +0100, Ole Streicher wrote: >> The problem is that aplpy uses matplotlib, and the old matplotlib uses >> the deprecated numpy function np.asscalar(), which leads to a >> DeprecationWarning, which is (on purpose, b

Bug#929438: ITP: parfive -- An asyncio based parallel file downloader for Python

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-as...@lists.debian.org, debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name : parfive Version : 1.0.0 Upstream Author : Stuart Mumford * URL : https://github.com

Pybuild: build time test requiring registration of entry point

Hi, I have a package (sunpy) that in the latest registers an entry point for another package (asdf): [options.entry_points] asdf_extensions = sunpy = sunpy.io.special.asdf.extension:SunpyExtension This functionality is also used during some tests, which I would like to keep. However, pybuild

pybuild mysteriously does not copy all files

Hi, I am not sure whether this is a bug in dh-python or if something is wrong with my package (python-asdf). The package has an (almost) standard setup, so dh_build is not overridden. However, when I try to package, some subdirectories are not copied; namely `asdf/external`:

Re: pybuild mysteriously does not copy all testfiles

Hi IOhannes, I have basically the same problem, funnily with almost the same subject: https://lists.debian.org/debian-python/2019/09/msg00040.html The difference is, that the "external" subdirectory is not copied. So, it seems to be a bug in dh-python. Cheers Ole "IOhannes m zmölnig (Debian/G

Re: package_data in python package

Félix Sipma writes: > They just run "python3 setup.py install" > (https://github.com/scheibler/khard/issues/231): > [...] > > For my part, I "just" build the debian package with "gbp buildpackage", > and with "dh $@ --with python3 --buildsystem=pybuild" in debian/rules. > > The solutions I say ar

Bug#943940: ITP: pytest-astropy-header -- Include basic system dependencies in the header of pytest output

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org, debian-as...@lists.debian.org * Package name: pytest-astropy-header Version : 0.1.1 Upstream Author : Thomas Robitaille * URL : https

Python 3.8 transition: CMake problems

Hi, I am currently updating the "casacore" package to the latest upstream version. Doing this, I discovered that it is not marked as part of the Python 3.8 transition, and was also not binNMUed for this, although it has the package libcasa-python3-3 (to be renamed to libcasa-python3-4) that depend

Understanding pybuild

Hi, I am currently updating scikit-image (skimage) to its newest version, and I have some difficulties to understand how pybuild works (for setup.py packages): 1. first, dh_auto_build calls "python3.X setup.py build" to create the packages (Python files and compiled extensions) in ..pybuild/cpyth

Re: Understanding pybuild

Hi Dmitry, Dmitry Shachnev writes: > On Thu, Dec 19, 2019 at 01:09:40PM +0100, Ole Streicher wrote: >> 2. dh_auto_test then tries runs the tests in .pybuild. If the test need >> data files installed, they must be copied manually (right?). > > You can use debian/pybuild.testf

Bug#949470: ITP: pytest-filter-subpackage -- Allow sub-packages to test to be selected with e.g. -P io.fits,modeling

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org, debian-as...@lists.debian.org * Package name: pytest-filter-subpackage Version : 0.1.1 Upstream Author : Thomas Robitaille * URL : https

pybuild with more than one binary package

Hi, we have a source package (older packaging attempt in gavodachs [1], Arch:all) that builds a number of binary packages. Specifically: python3-gavo-stc gavo/stc/ python3-gavo-utils gavo/utils/, gavo/imp python3-gavo-votable gavo/votable python3-gavo all other gavo/* + 2 entry poin

Bug#956048: ITP: extension-helpers -- Utilities for building and installing packages

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name: extension-helpers Version : 0.1 Upstream Author : The Astropy Developers * URL : https://pypi.org/project/extension

Bug#959778: ITP: pybdsf -- Python Blob Detection and Source Finder

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org, debian-as...@lists.debian.org * Package name: pybdfs Version : 1.9.2-1 Upstream Author : LOFAR/Astron * URL : https://www.astron.nl/citt

Bug#960142: ITP: pyerfa -- Python bindings for ERFA routines

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org, debian-as...@lists.debian.org * Package name: pyerfa Version : TBD Upstream Author : Astropy Developers * URL : https://github.com

Bug#960314: ITP: tifffile -- Read and write TIFF(r) files with Python

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-python@lists.debian.org, debian-de...@lists.debian.org * Package name : tifffile   Version : TBD   Upstream Author : Christoph Gohlke <mailto:cgoh...@uci.edu> * URL : https://pypi.org/project/tifffile/#descr

Bug#978432: ITP: astroalign -- Astrometric registration of images when no WCS info is available

Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, debian-python@lists.debian.org * Package name : astroalign Version : 2.3.1 Upstream Author : Martin Beroiz * URL : http

Re: Generic Python packages which don’t work on all architectures

Paul Wise writes: > This is what I eventually chose for iotop. At the time I wanted dpkg > and dak to support something like Architecture: linux-all, which would > build arch: all packages, but only put them in the Packages files for > the Linux architectures. > > I am now thinking that a more gen

Re: Generic Python packages which don’t work on all architectures

Ansgar writes: > On Thu, 2021-01-21 at 13:46 +0100, Ole Streicher wrote: >> I am still wondering why we don't have just empty some pseudo- > packages that are available only on specific architectures >> (or  groups of them, like linux, or little endian, or 64 bit or

Re: Generic Python packages which don’t work on all architectures

Paul Wise writes: > On Thu, Jan 21, 2021 at 1:12 PM Ole Streicher wrote: > >> This would be a quite flexible and extendible approach to have packages >> installable only where they work. > > There is precedent for this sort of thing in the isa-support source > packag

Re: Generic Python packages which don’t work on all architectures

Paul Wise writes: > On Thu, Jan 21, 2021 at 3:42 PM Ole Streicher wrote: > >> But this is also the case for all packages which implicitly depend on >> other packages which are not available on some architectures. > > This is true, but it doesn't make for a good user

  1   2   >