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

2021-01-22 Thread Ole Streicher
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 experience.

Yes, but this is a separate problem, and this IMO cannot be reliably
solved by adding a simple arch-specific declaration to the source
package: If we would do (require) f.e. an additional "installs-on" field
in d/control, then each maintainer would be requested to monitor all
dependencies on all archs to find out where the package could be
installable, and to re-upload the package with adjustments whenever one
of the dependencies changes the list of supported architectures.

IMO, a useful solution would be to parse the dependency chain on the
client (aptitude, synaptic or whatever) and to list only those packages
that can be installed.

If we would introduce arch specific marker packages, we wouldn't solve
this ofcourse, but we would solve the problem that you can install a
package that is actually not working on the architecture, which is even
a worse user experience. And we would solve the problem that one can't
specify f.e. all little-endian systems, or all 64-bit systems as build
dependency, except for explicitly listing all of them (which is IMO a
nightmare for ports or for derivatives that have additional
architectures).

It is not perfect, but a pragmatic step forward.

Best

Ole



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

2021-01-21 Thread Ole Streicher
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
> package, which fails installation when your CPU doesn't support
> particular ISA extensions like SSE or NEON.
>
> It is a reasonable workaround for now, but the packages using the
> pseudo-packages would still be available, causing confusion when
> people try to install them.

But this is also the case for all packages which implicitly depend on
other packages which are not available on some architectures. This is
not very rare:

 * Python arch:all packages may depend on arch:* Python packages which
   are not available everywhere

 * Packages written in an interpreted language are arch:all, but depend
   on the interpreter and can only installed on archs where the
   interpreter exists (like gnudatalanguage or iraf from my portfolio)

Generally, arch:all packages depend on a lot of architecture dependent
packages, and unless one resolves the whole dependency chain, there is
no way to check whether a package is actually installable.

> It would be better to just not have them available where they aren't
> going to work. I also wonder how multi-arch stuff would interact with
> the pseudo-packages idea.

IMO this is a problem that already exists there and is not
solved. Imagine the following constellation:

 * I have a python3-foo package with arch:all.
 * this depends on python3-foo-obj that exists only for i386.

Now I have a x86_64 machine that gets i386 added. On this machine, I
could install python3-foo (since the dependency is resolvable), but
'import foo' with the x86_64 interpreter would fail.

Best regards

Ole



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

2021-01-21 Thread Ole Streicher
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 so).
>
> To solve which problem?

For example, the problem that a certain package is working properly only
on big endian systems. Or on Linux.

Currently, there is (as discussed here) no way to tell that an arch:all
package is not working on a 32-bit system. And for architecture
dependent builds, one needs to specify every single architecture where
it is supposed to build. How do you currently otherwise would specify
"all little endian systems" as build dependency?

> Packages being installable don't mean that they can do anything useful
> as they might, for example, require special hardware.  We don't have a
> way to express "requires device ${X}" on a package level.

Special hardware is another topic, which is surely not solved here (and
not solvable at all in general, since hardware today may be
hot-pluggable, and the hardware configuration at install time does not
need to be the configuration at run time).

However, the proposal to have architecture (group) specific empty
packages would already solve some of the problems if this is limited to
architecture specification.

Best regards

Ole



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

2021-01-21 Thread Ole Streicher
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 generic solution than Architecture:
> linux-all is needed, in order to cover your case as well. Perhaps
> something like Available-Architecures or Runtime-Architectures or
> Architecture-all-Architectures: or similar.

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 so). If a package works (or
builds) only on a specific arch (or an arch with specific properties),
it can be set dependent (or built-dependent) on that.

This would be a quite flexible and extendible approach to have packages
installable only where they work.

Best regards

Ole



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

2020-12-27 Thread Ole Streicher

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://astroalign.readthedocs.io/
* License  : Expat
  Programming lang : Python
  Upstream git : https://github.com/quatrope/astroalign
  Pypi URL : https://pypi.python.org/pypi/astroalign
  Description  : Astrometric registration of images

ASTROALIGN is a python module that will try to register (align) two stellar
astronomical images, especially when there is no WCS information available.

It does so by finding similar 3-point asterisms (triangles) in both images
and estimating the affine transformation between them.

This is a popular astropy affiliated package. It will be maintained under the
umbrella of the Debian Astro team. A salsa repo was created at

https://salsa.debian.org/debian-astro-team/astroalign

Best regards

Ole



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

2020-05-11 Thread Ole Streicher
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/#description
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Read and write TIFF(r) files with Python

Tifffile is a Python library to

 1. store numpy arrays in TIFF (Tagged Image File Format) files, and
 2. read image and metadata from TIFF-like files used in bioimaging.

Image and metadata can be read from TIFF, BigTIFF, OME-TIFF, STK, LSM,
SGI, NIHImage, ImageJ, MicroManager, FluoView, ScanImage, SEQ, GEL, SVS,
SCN, SIS, ZIF, QPTIFF, NDPI, and GeoTIFF files.

Numpy arrays can be written to TIFF, BigTIFF, and ImageJ hyperstack
compatible files in multi-page, memory-mappable, tiled, predicted, or
compressed form.
This is a new dependency of the scikit-image (skimage) package. I will
maintain it within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/modules/tifffiles

Best regards

Ole



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

2020-05-09 Thread Ole Streicher
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/liberfa/pyerfa
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python bindings for ERFA routines

PyERFA is the Python wrapper for the ERFA library (Essential Routines
for Fundamental Astronomy), a C library containing key algorithms for
astronomy, which is based on the SOFA library published by the
International Astronomical Union (IAU). All C routines are wrapped as
Numpy universal functions, so that they can be called with scalar or
array inputs.

The project is a split of astropy._erfa module, developed in the context
of Astropy project, into a standalone package, and therefore will be a
dependency of upcoming Astropy releases.

The packages will be maintained under Debian Astro team maintainance,
with the repository at

https://salsa.debian.org/debian-astro-team/pyerfa

Best regards

Ole



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

2020-05-05 Thread Ole Streicher
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/pybdsf/
* License : GPLv2
  Programming Lang: Python
  Description : Python Blob Detection and Source Finder

PyBDSF (the Python Blob Detection and Source Finder)
is a tool designed to decompose radio interferometry images into source
and make available their properties for further use. PyBDSF can
decompose an image into a set of Gaussians, shapelets, or wavelets as
well as calculate spectral indices and polarization properties of
sources and measure the psf variation across an image. PyBDSF uses an
interactive environment based on CASA that will be familiar to most
radio astronomers. Additionally, PyBDSF may also be used in Python
scripts.

The packages will be maintained under Debian Astro team maintainance,
with the repository at

https://salsa.debian.org/debian-astro-team/pybdfs

Best regards

Ole



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

2020-04-06 Thread Ole Streicher
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-helpers/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Utilities for building and installing packages

The extension-helpers package includes convenience helpers to assist
with building Python packages with compiled C/Cython extensions. It is
developed by the Astropy project but is intended to be general and
usable by any Python package.

This is not a traditional package in the sense that it is not intended
to be installed directly by users or developers. Instead, it is meant to
be accessed when the setup.py command is run and should be defined as a
build-time dependency in pyproject.toml files.

This package is a new dependency of many astropy affiliated packages. I
intend to maintain it under the DPMT hood, so the salsa git dir will be

https://salsa.debian.org/python-team/modules/extension-helpers

Best regards

Ole



pybuild with more than one binary package

2020-01-27 Thread Ole Streicher
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 points

How do I do that? The pybuild documentation states that it is possible
to magically build several binary packages without the need of *.install
files, but this seems not to be the case here: all goes into
python3-gavo, the other packages are empty.

Is there a trick to do the magic? And if not, what should one specify in
the *.install files in that case?

Best

Ole

[1] https://salsa.debian.org/debian-astro-team/gavodachs



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

2020-01-21 Thread Ole Streicher
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://github.com/astropy/pytest-filter-subpackage
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Allow sub-packages to test to be selected with -P

This package contains a simple plugin for the pytest framework that
provides a shortcut to testing all code and documentation for a given
sub-package. It is a new build dependency of pytest-astropy.

I will maintain it within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/modules/pytest-filter-subpackage

Best regards

Ole



Re: Understanding pybuild

2019-12-19 Thread Ole Streicher
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.testfiles to copy the test files. See pybuild(1)
> for details.

That would formalize it a bit, but still does not solve the underlying
problem: it requires that I maintain the list of these files manually,
while upstream already does this (by adding them to the list of data
files).

And also, the built time tests are with pybuild not done with the files
(anc compilations) that are finally installed, but the installed files
(especially Python extensions) are created again from scratch, doubling
the compile time and introducing another difficile source of error.

Best regards

Ole



Understanding pybuild

2019-12-19 Thread Ole Streicher
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/cpython3_3.X/. This however does not include the copying of any
data files.

2. dh_auto_test then tries runs the tests in .pybuild. If the test need
data files installed, they must be copied manually (right?).

3. dh_auto_install finally calls "python3.X setup.py install ..." to
install the complete packages (Python files, extensions, and data files)
from their original place to debian/tmp/. This includes a re-compilation
of the extensions.

What I do not understand now is: what is the purpose of step 1? Except
for the tests, these files seem to be unused. And for the tests, they
are not complete, since the data files are missing.

And what is the canonical way to get the data files copied to
..pybuild/...? They are already marked as such in setup.py. Doing this
manually by the Debian maintainer seems a constant source of error.

Best

Ole



Python 3.8 transition: CMake problems

2019-11-26 Thread Ole Streicher
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 depends on libpython3.7. Was this somehow forgotten?

Nevertheless, when I now try to build the (updated) package, I get the
following error:

8<-
  Could NOT find Python3 (missing: Python3_LIBRARY Python3_INCLUDE_DIR
  Development NumPy) (found version "3.8.0")
Call Stack (most recent call first):
  /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.15/Modules/FindPython/Support.cmake:1653 
(find_package_handle_standard_args)
  /usr/share/cmake-3.15/Modules/FindPython3.cmake:215 (include)
  python3/CMakeLists-cmake3.14.txt:3 (find_package)
8<-

The corresponding line in python3/CMakeLists-cmake3.14.txt is

find_package(Python3 REQUIRED COMPONENTS Interpreter Development NumPy)

which looks normal to me. Any idea why CMAKE does not find Python 3.8?

Best regards

Ole



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

2019-11-01 Thread Ole Streicher
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://github.com/astropy/pytest-astropy-header
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Include basic sysdeps in the header of pytest output

This plugin package provides a way to include information about the
system, Python installation, and select dependencies in the header of
the output when running pytest. It can be used with packages that are
not affiliated with the Astropy project, but is optimized for use
It is a new build dependency of pytest-astropy.

I will maintain it within the Debian Astro team. Salsa dir is

https://salsa.debian.org/debian-astro-team/pytest-astropy-header

Best regards

Ole



Re: package_data in python package

2019-10-28 Thread Ole Streicher
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 are: I can keep the patch in the package (without
> really understanding the need for it) or try to convince upstream to
> merge it (but they can't reproduce the problem, so why would they do
> that?). In both cases, probably others will encounter the same problem
> in other packages... It would be nice to fix the problem once for all
> (if possible :)).

Just FYI, https://bugs.debian.org/940728 describes a similar problem,
although there the unhandled files are Python source files. pybuild
seems to handle things different from plain setup.py.

Cheers

Ole



Re: pybuild mysteriously does not copy all testfiles

2019-09-10 Thread Ole Streicher
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/GNU)"  writes:
> updating one of my packages (python-can), the test-suite started to
> fail, with an error-code 5, indicating that "no tests have been run".
>
> since there *are* tests to be run, i investigated and - after scratching
> my head - found that 'pybuild' did not fully copy the test-directory
> from the source-directory to the build directory.
>
> The sources "test/" directory contains:
> ```
> test/serial_test.py
> test/test_slcan.py
> test/test_cyclic_socketcan.py
> test/data/logfile.blf
> test/data/__init__.py
> test/data/example_data.py
> test/data/logfile.asc
> test/test_bit_timing.py
> test/zero_dlc_test.py
> test/test_systec.py
> test/open_vcan.sh
> test/message_helper.py
> test/contextmanager_test.py
> test/test_detect_available_configs.py
> test/test_message_sync.py
> test/notifier_test.py
> test/config.py
> test/simplecyclic_test.py
> test/test_scripts.py
> test/logformats_test.py
> test/listener_test.py
> test/back2back_test.py
> test/test_message_class.py
> test/__init__.py
> test/test_message_filtering.py
> test/test_socketcan.py
> test/test_kvaser.py
> test/test_viewer.py
> test/network_test.py
> test/test_vector.py
> test/test_socketcan_helpers.py
> test/test_load_file_config.py
> ```
>
> However, ".pybuild/cpython3_3.7_can/build/test/" contains only: (after
> dh_auto_test failed):
> ```
> test/data/__init__.py
> test/data/example_data.py
> ```
>
> d/rules is pretty standard:
> ```
> #! /usr/bin/make -f
> export PYBUILD_NAME=can
> include /usr/share/dpkg/default.mk
> export DEB_VERSION_UPSTREAM
> %:
> dh $@ --with python3,sphinxdoc --buildsystem=pybuild
> override_dh_clean:
> dh_clean
> rm -f test.asc test.csv
> rm -rf .pytest_cache/
> override_dh_auto_build:
> dh_auto_build
> python3 -m sphinx -E -T -b html doc .pybuild/docs/html/
> override_dh_auto_install:
> dh_auto_install
> -for f in debian/*/usr/bin/*.py; do mv $$f $${f%.py}; done
> -rm -f debian/*/usr/lib/python*/dist-packages/test.???
> ```
>
> and the package does not contain d/pybuild.testfiles or similar.
>
> Now if I add a file from tests (say "test/network_test.py") to
> d/pybuild.testfiles, that file is copied (although into
> .pybuild/cpython3_3.7_can/build/ rather than into
> .pybuild/cpython3_3.7_can/build/test/) and runs correctly.
> adding "test/" to d/pybuild.testfiles (with or without the trailing
> slash) did not do anything (apart from the original behaviour of only
> copying 2 files).
> doing something like "find test -type f > d/pybuild.testfiles" copied
> all files, however the directory structure was lost (all files ended up
> in .pybuild/cpython3_3.7_can/build/), and the tests started to fail as
> they didn't find files in the subdirectories as expected.
>
> i'm totally stumified.
>
> an intermediate hack i found to work is to manually copy the "test/"
> directoy into the build-dir, using:
> export PYBUILD_BEFORE_TEST=cp -r {dir}/test {build_dir}
>
> but that seems extraordinarily clumsy. esp. since pybuild(1) says:
>> By default only test and tests directories are copied to build
>> directory.
>
> any ideas what does wrong?
> mgfdsar
> IOhannes



pybuild mysteriously does not copy all files

2019-09-04 Thread Ole Streicher
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`:

8<--
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /build/python-asdf-2.4.2/.pybuild/cpython3_3.7_asdf/build/asdf
[...]
8<--

The subdir `asdf/external` which is in the source is not created and not
filled during this process.

However, when I run `python3 setup.py build` or `pybuild --build`
manually, everything is correct:

8<--
$ python3 setup.py build -vvv
running build
running build_py
creating build
creating build/lib
creating build/lib/asdf
copying asdf/yamlutil.py -> build/lib/asdf
[...]
creating build/lib/asdf/extern
copying asdf/extern/RangeHTTPServer.py -> build/lib/asdf/extern
copying asdf/extern/__init__.py -> build/lib/asdf/extern
copying asdf/extern/atomicfile.py -> build/lib/asdf/extern
copying asdf/extern/decorators.py -> build/lib/asdf/extern
[...]
8<--

Is there any idea what happens here? Why does pybuild (or setup.py)
behave differently when called from dh_python than directly?

How can I ensure that all files are copied during dh_auto_build?

Best regards

Ole



Pybuild: build time test requiring registration of entry point

2019-05-28 Thread Ole Streicher
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 runs the test before "setup.py install" is called, so
the extension is not there at this time. I would not like to disable the
test, since it checks some important functionality.

Is there a way to solve this?

Best regards

Ole



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

2019-05-23 Thread Ole Streicher
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/Cadair/parfive
* License  : MIT
  Programming lang : Python
  Description  : A parallel file downloader using asyncio.

Parfive is a small library for downloading files, its objective is to
provide a simple API for queuing files for download and then providing
excellent feedback to the user about the in progress downloads. It also
aims to provide a clear interface for inspecting any failed downloads.

The parfive package was motivated by the needs of SunPy’s net submodule,
but should be generally applicable to anyone who wants a user friendly
way of downloading multiple files in parallel.

Parfive supports downloading files over either HTTP or FTP using aiohttp
and aioftp aioftp is an optional dependency, which does not need to be
installed to download files over HTTP.

The Debian package will be maintained by the Debian Astro team. A git
repository will be created at

https://salsa.debian.org/debian-astro-team/astropy-sphinx-theme

Best regards

Ole



Re: Numpy migration?

2019-01-07 Thread Ole Streicher
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, by upstream) thrown as error.
>> 
>> https://ci.debian.net/data/autopkgtest/testing/amd64/a/aplpy/1658948/log.gz
>> 
>> This does only happen in the combination "new numpy + old matplotlib",
>> but this is the one that is tested for the CI test.
>
> mhh… for this, indeed a breaks numpy -> matplotlib could be used, but it
> feels a bit too strong to me, as nothing was really broken since it's
> just deprecations.
>
> elbrus; this is a case where I think I could use your input (tl;dr: new
> numpy causes deprecations in testing's version of matplotlib (fixed in
> unstable), which in turn causes failures in new aplpy, how to make the
> stack happy?).

BTW, same is true for astropy-healpix and pyregion (both not maintained
by me). Just to shorten the list of relevant CI failures.

Cheers

Ole



Re: Numpy migration?

2019-01-07 Thread Ole Streicher
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 (although the unstable test was not done on
ci.d.n when I wrote my last mail).

>>  - with numpy-1.15.4-2 (testing) and matplotlib-2.2.2-4 (testing),
>>  - with numpy-1.16.0~rc2-1 (unstable) and matplotlib-3.0.2-2 (unstable).
>> 
>> However it does not work well when combining numpy-1.16.0~rc2 (unstable)
>> and matplotlib-2.2.2-4 (testing), which is the combination that is
>> tested for migration of numpy. Needless to say that matplotlib migrates
>> only after numpy. What should one do here? Declaring another
>> "Breaks: matplotlib (<< 3.0)" in numpy?
>
> Well, to me it seems it's python3-astropy that is missing a dependency
> on python3-skimage there, to be honest:
> |>   from skimage.measure import block_reduce
> |E   ModuleNotFoundError: No module named 'skimage'
> |
> |/usr/lib/python3/dist-packages/astropy/nddata/utils.py:370: 
> ModuleNotFoundError
>
> However I wouldn't be able to tell you why it would pass with numpy and
> matplotlib from unstable, given that neither pulls in skimage…

astropy needs askimage only in some cases, so it is (should be) a
suggestion and not a recommendation. aplpy is however one of these
cases -- but this is not the problem here, since aplpy 2.0~rc2-2 has
skimage in its test dependency.

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, by upstream) thrown as error.

https://ci.debian.net/data/autopkgtest/testing/amd64/a/aplpy/1658948/log.gz

This does only happen in the combination "new numpy + old matplotlib",
but this is the one that is tested for the CI test.

best

Ole



Re: Numpy migration?

2019-01-06 Thread Ole Streicher
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
> on removing python-astropy from unstable (I'll reply to that in a bit),
> but for testing is quite easy.
> Just file a bug against release.debian.org asking to remove it from
> testing, and one against python-astropy at RC-level with "not release
> with buster", and it will be out of testing beofore you even notice.

The reverse build deps of python-astropy in testing are pyregion and
veusz. Veusz has the build-dep removed in unstable, but didn't migrate
since 192 days. Pyregion just got an upload with a fix, but will
probably only migrate after numpy (which will not migrate until
python-astropy is removed).

Now it turns out that there is a new migration problem, which is aplpy:
Current aplpy (2.0~rc2-2) CI test works well

 - with numpy-1.15.4-2 (testing) and matplotlib-2.2.2-4 (testing),
 - with numpy-1.16.0~rc2-1 (unstable) and matplotlib-3.0.2-2 (unstable).

However it does not work well when combining numpy-1.16.0~rc2 (unstable)
and matplotlib-2.2.2-4 (testing), which is the combination that is
tested for migration of numpy. Needless to say that matplotlib migrates
only after numpy. What should one do here? Declaring another
"Breaks: matplotlib (<< 3.0)" in numpy?

Best

Ole



Re: Numpy migration?

2019-01-05 Thread Ole Streicher
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 package. So, the breakage could be
>> detected (and taken into account) automatically. Why do we need a manual
>> action then?
>
> Let me try to suggest you see from another side: the goal of the Breaks
> field is to prevent a given combination of known broken packages to be
> installed.
> Currently autopkgtest blocks the migration of numpy, but if there wasn't
> that block a Breaks should still be added, as the astropy in testing is
> not compatible with the new numpy.  The fact that it hints britney to
> trigger the right tests is just a "side effects", the Breaks should be
> added nonetheless, theoretically; in practice, we rarely did it before
> autopkgtest started blocking the testing migration.

I agree (with the explanation in your other mail) here; it just states
the fact that they really don't go together very well (at least in
situation similar to the specific CI test).

>> Python-astropy is however going to be removed completely; it has
>> however some cruft rdeps left in unstable. So, it cannot removed from
>> unstable now, and therefore still remains in testing and
>> (unnecessarily) blocks the numpy migration.  Python-astropy already
>> has an RC bug, but its autoremoval from testing is still not even
>> announced yet.
>
> Maybe you could ask the release team to hasten the removal of
> python-astropy and rdeps from testing?  If the plan is to not relase
> it in buster I don't see a reason to keep it further.

Couldn't we just also add a "breaks" to numpy? The important fact here
is, that the new numpy and the current python-astropy don't work
together; and this is independent of whether a fixed python-astropy
version exists.

This would remove one dependent party (release team) from the chain of
blocking causes for the migration.

>> The migration blocking CI tests seem to cause much more headaches than
>> just "fix your bugs"...
>
> Well, from what I see, it has helped a lot in this half a year detect a
> ton of regressions that would have otherwise bothered several people in
> a later moment…

I usually regularly look into my packages and file bugs if a CI test
fails caused by a buggy updated dependency. This works well without the
need of blocks. It would also work, when a failing CI test would
automatically trigger a bug report against the updated package, which
then could be re-assigned to the rdep in case the problem was there.

So, I value very much the CI tests by themself: they are the greatest
invention since sliced bread, but I still dislike the inflexible
handling of blocks. Often, a failing CI test makes a package only buggy
with respect to a certain feature, so it would correspond to a
"important" or "normal" bug severity. They are however always handled
like a "serious" bug by preventing migration. I miss the "That was not a
serious failure" button.

Thanks fur your help!

Best

Ole



Re: Numpy migration?

2019-01-05 Thread Ole Streicher
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 astropy
> together, and will be able to correctly migrate to testing at the same
> time, and properly avoid a situation when two incompatible packages
> are installed.
> Maybe you could open a bug on numpy to get the maintainer to add the breaks.

There is one more problem, which are transitional dependencies:

The new python3-numpy version breaks (f.e.) python3-pyregion because of
the problem in python3-astropy. The new upload of python3-astropy fixes
this, so in unstable everything is OK. Even when one now adds a

Breaks: python3-astropy (<< fixed-version)

to python-numpy, it will not migrate due to the test failure of
python3-pyregion in testing. Adding a "Breaks: python3-pyregion" is
however wrong, since pyregion is perfect for the new numpy version.

So, how to handle this?

Cheers

Ole



Re: Numpy migration?

2019-01-05 Thread Ole Streicher
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 astropy
> together, and will be able to correctly migrate to testing at the same
> time, and properly avoid a situation when two incompatible packages
> are installed.
> Maybe you could open a bug on numpy to get the maintainer to add the
> breaks.

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 package. So, the breakage could be
detected (and taken into account) automatically. Why do we need a manual
action then?

>> Another CI problem is python-astropy, which is the Python 2 version of
>> Astropy. python-astropy is going to be removed as soon as there are no
>> backward dependencies left; however there is still some cruft in
>> unstable that depends on python-astropy. But this should not hinder
>> numpy to migrate.
>
> I don't understand this, I don't see any python2-related issue right
> now.  Could you please expand?

The new python-numpy breaks python-astropy in testing. Python-astropy is
however going to be removed completely; it has however some cruft rdeps
left in unstable. So, it cannot removed from unstable now, and therefore
still remains in testing and (unnecessarily) blocks the numpy migration.
Python-astropy already has an RC bug, but its autoremoval from testing
is still not even announced yet.

The migration blocking CI tests seem to cause much more headaches than
just "fix your bugs"...

Best

Ole



Numpy migration?

2019-01-05 Thread Ole Streicher
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 caused by
astropy (#917466) and are fixed since a week in unstable.

However, astropy cannot migrate now, to testing, since it depends on the
new numpy version (and therefore can only migrate after numpy). And
numpy is blocked by the CI failure of astropy ...

Looks like a deadlock. Which will be resolved before the migration delay
ends. Which is in the second half of february, and therefore will cause
all packages that depend on numpy and are not in testing yet to be kept
outside of Buster (due to the release timeline).

What is the way to resolve those problems? These deadlocks probably
appear regularly when a package gets a major update: package A breaks
the CI test of the rdep B in testing, and a rebuild of B in unstable
depends on the newer version of A.

Another CI problem is python-astropy, which is the Python 2 version of
Astropy. python-astropy is going to be removed as soon as there are no
backward dependencies left; however there is still some cruft in
unstable that depends on python-astropy. But this should not hinder
numpy to migrate.

How to solve this?

Best

Ole



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

2018-12-06 Thread Ole Streicher
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
* License  : BSD 3-Clause
  Programming lang : Python
  Upstream git : https://github.com/astropy/sphinx-automodapi
  Pypi URL : https://pypi.python.org/pypi/sphinx-automodapi
  Description  : Sphinx extensions for generating API documentation

The sphinx-automodapi package provides Sphinx directives that help
facilitate the automatic generation of API documentation pages for
Python package modules. It was originally developed for the Astropy
project, but is now developed as a standalone package that can be used
for any project.

I will maintain it within the Debian Python team.

Best regards

Ole



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

2018-11-27 Thread Ole Streicher
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 3.7 - 3.10;
> see
> 
> https://github.com/astropy/astropy/issues/8177
> 
> 
> according to linked issue, that bug is fixed in 3.10.1, which is in
> Debian unstable now.

Thanks for updating, but I still get failures. And I asked pytest
upstream about possible fixes of the 3.X branch, which they are not
going to do:

https://github.com/astropy/astropy/pull/8173#issuecomment-441959185

> I also observed diverse failures on other (astropy dependent) packages
> with 3.10. Which basically means that I need to switch off the tests,
> unless pytests upstream provides a bugfixed 3.X version.
> 
> maybe just disable some of that tests? Not whole testsuite?

The current failure in python-astropy is

E   UsageError: Plugin specs must be a ','-separated string or a
list/tuple of strings for plugin names. Given: 

which blocks the whole suite. Other packages have errors that really
look strange (data files are missing, submodules not found etc). Sure,
that all could be workarounded somehow, but in a few weeks the next
update of a dependency may make trouble again.

We will publish Debian Buster not earlier than summer/fall next year,
and this is just ~6-9 months before Python 2 EOL. I don't want to put
too many efforts in keeping this alive.

Best

Ole



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

2018-11-27 Thread Ole Streicher
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, however it turns out that this will unfortunately not work for
me: from astropys POV, pytest seems to be broken in versions 3.7 - 3.10;
see

https://github.com/astropy/astropy/issues/8177

I also observed diverse failures on other (astropy dependent) packages
with 3.10. Which basically means that I need to switch off the tests,
unless pytests upstream provides a bugfixed 3.X version.

However, it seems that I need to start with the removal of the Python 2
astropy ecosystem, which may be in any case not the worst decision.
Personally, I like to put pressure to move towards Python 3.

Cheers

Ole



Upcoming pytest-4 problems

2018-11-25 Thread Ole Streicher
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 split the upstream source into a 2.X legacy package
(src:python-astropy) and a 3.X standard package (src:astropy).

Yesterday, upstream decided that the legacy package will not support
pytest 4:

https://github.com/astropy/astropy/pull/8173

Pytest 4 is however the upcoming version, and I could imagine that
others may have similar problems with Python 2 legacy. Therefore, my
question is how these problems should be solved:

* creating a legacy version package for pytest

* remove the tests for these packages

* remove the legacy packages in question completely

For us, the third option would basically mean to remove the whole Python
2 astronomy ecosystem, and we would need to hurry in making some general
packages Python 3 compatible (mainly astrometry.net).

I opened a bug on pytest to discuss this:

https://bugs.debian.org/914592

Best regards

Ole



dh_python3-ply lintian warning

2018-10-20 Thread Ole Streicher
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<---

I get the following lintian warnings about the generated files:

W: python3-astropy: python-module-in-wrong-location 
usr/lib/python3.7/dist-packages/astropy/ usr/lib/python3/dist-packages/astropy/
W: python3-astropy: python-module-in-wrong-location 
usr/lib/python3.7/dist-packages/astropy/coordinates/ 
usr/lib/python3/dist-packages/astropy/coordinates/
W: python3-astropy: python-module-in-wrong-location 
usr/lib/python3.7/dist-packages/astropy/coordinates/angle_lextab.py 
usr/lib/python3/dist-packages/astropy/coordinates/angle_lextab.py

How can I fix that?

Best regards

Ole



Re: Matplotlib 3.0 - update ok?

2018-10-16 Thread Ole Streicher
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 want to then have a Python-2-numpy, why can't there be a
separate Python-2 legacy numpy source package? I do the same for
astropy.

Holding back normal updates especially for science packages just because
we don't want to use a modern numpy/scipy/matplotlib stack is not really
friendly to our users, which (in science) rely on at least "somehow"
modern software. And astropy that is more than a 1.5 years old already
at the release of Buster would not be accepted by the users, and
patching it to use an older sw stack is also impractical.

Even when we /still/ support Python 2, our focus and preference should
be clearly Python 3.

Best regards

Ole



Re: Problem with pybuild and pytest (repost)

2018-09-28 Thread Ole Streicher
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) you have ".." in PYBUILD_TEST_ARGS (in the git repo) - remove it
> 3) for python2.7 (and 2.7 only, 3.X works fine), cmdclassd somehow
>disables distutils' settings from .pydistutils.cfg (probably
>overwrites too much or doesn't invoke parent's methods).
>It works for 3.X because "from sunpy.tests.setup_command import SunPyTest"
>fails on 3.X and thus SunPyTest is not used at all.
>Disabling SunPyTest fixes it for me

Thanks. Just removing the cmdclass option did the trick, and it works
now.

Best

Ole



Problem with pybuild and pytest (repost)

2018-09-28 Thread Ole Streicher
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:

override_dh_auto_test:
python -m pytest sunpy -k "not figure and not online"
python3 -m pytest sunpy -k "not figure and not online"

This gives successfull tests with the following output in the log:


--8<---
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
python -m pytest sunpy -k "not figure and not online"
= test session starts ==
platform linux2 -- Python 2.7.15, pytest-3.6.4, py-1.5.4, pluggy-0.6.0
rootdir: /<>, inifile: setup.cfg
plugins: mock-1.7.1, hypothesis-3.44.1
collected 1448 items / 34 deselected
[...]
--8<---


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


--8<---
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd /build/sunpy-0.9.3/.pybuild/cpython2_2.7_sunpy/build; 
python2.7 -m pytest -k "not figure and not online"
= test session starts ==
platform linux2 -- Python 2.7.15+, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /build/sunpy-0.9.3, inifile: setup.cfg
plugins: mock-1.7.1, hypothesis-3.44.1
collected 0 items

= no tests ran in 0.00 seconds =
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=5: cd 
/build/sunpy-0.9.3/.pybuild/cpython2_2.7_sunpy/build; python2.7 -m pytest -k 
"not figure and not online"
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned 
exit code 13
--8<---


I don't understand why the tests fail now? How do I correctly specify
them?

Best regards

Ole



Re: Upstreams dropping Python 2 support

2018-09-27 Thread Ole Streicher
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 with the current 314
> python-sphinx reverse build-depends it is clear that I will have to ship
> sphinx-python2 for quite some time.

Is there a reason why one would use Python2-sphinx instead of the Python
3 version? How often in these 314 cases it is not just used as an
executable in d/rules?

Cheers

Ole



Re: python-drizzle is in two repositories on Salsa

2018-09-20 Thread Ole Streicher
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" name
python-drizzle for one of the Debian Astro packages, not realizing that
this name was taken for a Python module, which was removed in wheezy.

The repository for the old Python module however keeps existing, was
migrated to Salsa, and now gets all the nice maintenance updates from
Chris and Ondrej.

I would recommend to rename and/or archive this repository. There is no
need to keep it up-to-date anymore. I however don't have the permission
to archive it. Could I ask one of the owners to do so?

Best regards

Ole

On 20.09.2018 13:00, Andreas Tille wrote:
> Hi Ole,
> 
>   
> https://salsa.debian.org/search?utf8=%E2%9C%93=python-drizzle_id=_id=_ref=
> 
> both repository get updates - that's confusing.  I'd recommend to
> remove one of these.
> 
> Kind regards
> 
>Andreas.
> 



Problem with pybuild and pytest

2018-09-13 Thread Ole Streicher
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"
python3 -m pytest sunpy -k "not figure and not online"

This gives successfull tests with the following output in the log:


--8<---
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
python -m pytest sunpy -k "not figure and not online"
= test session starts ==
platform linux2 -- Python 2.7.15, pytest-3.6.4, py-1.5.4, pluggy-0.6.0
rootdir: /<>, inifile: setup.cfg
plugins: mock-1.7.1, hypothesis-3.44.1
collected 1448 items / 34 deselected
[...]
--8<---


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


--8<---
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:217: cd /build/sunpy-0.9.3/.pybuild/cpython2_2.7_sunpy/build; 
python2.7 -m pytest -k "not figure and not online"
= test session starts ==
platform linux2 -- Python 2.7.15+, pytest-3.6.4, py-1.6.0, pluggy-0.6.0
rootdir: /build/sunpy-0.9.3, inifile: setup.cfg
plugins: mock-1.7.1, hypothesis-3.44.1
collected 0 items

= no tests ran in 0.00 seconds =
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=5: cd 
/build/sunpy-0.9.3/.pybuild/cpython2_2.7_sunpy/build; python2.7 -m pytest -k 
"not figure and not online"
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned 
exit code 13
--8<---


I don't understand why the tests fail now? How do I correctly specify
them?

Best regards

Ole



PLY problem

2018-05-16 Thread Ole Streicher
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/clean, and they are somehow cached
regenerated from

astropy/coordinates/angle_utilities.py

The latter file contains the hint

# This module includes files automatically generated from ply (these end in
# _lextab.py and _parsetab.py). To generate these files, remove them from this
# folder, then build astropy and run the tests in-place:
#
#   python setup.py build_ext --inplace
#   pytest astropy/coordinates

but this seems not to fit very well into the pybuild procedure. And, I
have a few more of them (in astropy/units/format).

What would be the best way to regenerate them?

Best regards

Ole



Extra debian.blends Python package

2018-03-24 Thread Ole Streicher
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 probably a good idea to create a separate Python package from it.

Since this package deals with tasks sources, it sounds natural to put
this as a sub-package of the "debian" package. I would however not like
to integrate the sources to python-debian. First, it is very new and
likely to change API quickly in the next time. But also, the blends
subpackage is quite special; there is no need to have it installed in
such a broad manner as python-debian.

And finally, I do not care about Python 2 compatibility here.

What I could do easily is to create a python3-debian-blends binary
package (maintained in the "blends" source package) for this subpackage,
just installs a "blends.py" into ../dist-packages/debian/

Since this is however somehow hijacking (part of) the namespace of
python-debian, I'd like to know the policy here.

Are there any problems with that approach?

Best regards

Ole



apt.Cache.update with alternative sources.list

2018-03-21 Thread Ole Streicher
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('sources_list='/etc/blends/sources.list.testing')
LockFailedException: Failed to lock /var/lib/apt/lists/lock
```

Then I tried to use an alternative root directory:

```
>>> import apt
>>> c = apt.Cache(rootdir='/tmp/myapttmp')
>>> c.update('sources_list='/etc/blends/sources.list.testing')
FetchFailedException: W:GPG error: http://ftp.debian.org/debian testing 
InRelease: The following signatures couldn't be verified because the public key 
is not available: NO_PUBKEY 7638D0442B90D010, E:The repository 
'http://ftp.debian.org/debian testing InRelease' is not signed.
```

To which place in the new root directory do I need to copy the keyring?
I tried <>/usr/share/keyrings/ but this didn't work.

And/or how can I disable authentication (--allow-unauthenticated,
resp. APT::Get::AllowUnauthenticated)?

Version of python3_apt is 1.4.0~beta3+b1

Best regards

Ole



Re: pybuild: how to get the build directory name

2018-03-21 Thread Ole Streicher
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 regards

Ole



pybuild: how to get the build directory name

2018-03-20 Thread Ole Streicher
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=/tmp/ PYTHONPATH=$(CURDIR)/.pybuild/pythonX.Y_$*/build python$* 
debian/tests/pyraf-test.py

override_dh_auto_test: $(PYTHON2:%=test-python%) $(PYTHON3:%=test-python%)

This however does not work anymore, since the subdir under .pybuild is
now changed to cpython2_2.7_pyraf resp. cpython3_3.6_pyraf.

To be backward compatible, I would however not like to just follow this
change. How can I get the correct build dir here?

Best regards

Ole



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

2018-03-13 Thread Ole Streicher
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 taken by another package, and we have to
> fallback to python-foo. Think about generic libs for compression,
> images, network standards...
>
> Which is why I think we should have standardize on python-foo for the
> source package (which is what I do).

I disagree. Often packages already signalize their Python origin:
astropy, sunpy, pyephem etc. Or relate to pytest (pytest-mpl for
example). Or provide a Python package just as one of many other packages
(plplot). Prefixing them with "python-" increases useless redundancy,
and makes it harder for external people to find the package.

I would deviate from the rule of thumb "stick with the upstream name
unless there is a (potential) conflict". And if there is a conflict,
talk to upstream to find a solution -- it is quite probable that it will
lead to file conflicts as well (tools/apps in /usr/bin).

Best

Ole



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

2018-02-07 Thread Ole Streicher
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 significant - unfortunately many
> application maintainers don't know or care about it and pollute global
> Python namespace with private libraries.

So, why would you like to keep them separate?

> If not separated at team level, I definitely want to have them somehow
> separated at repository level so that it's clear which package is which
> type or to easily checkout libraries only.

At least in the field where I package (astronomy), this does not work:
many of our packages are libraries *and* apps. Often they come as a big
(public) library with a small startup wrapper, and it is a matter of
taste (and of how deep an astronomer digs into Python) whether it is
used from the shell or from a Jupyter notebook.

The rules for both are (should be) the same, right? So, what is the
difference? 

Best regards

Ole



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

2018-02-01 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pytest dependencies for Astropy & Co.

This is a meta-package that pulls in the dependencies that are used by
`astropy` and some `affiliated packages` for testing. It can also be
used for testing packages that are not affiliated with the Astropy
project. It is a new build dependency of astropy 3.0.

I will maintain it within the Debian Astro team.

Best regards

Ole



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

2018-01-12 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pytest plugin that enables the generation and comparison of 
data arrays

This is a py.test plugin to facilitate the generation and comparison
of data arrays produced during tests. The basic idea is that you can
write a test that generates a Numpy array (or other related objects
depending on the format). You can then either run the tests in a mode
to generate reference files from the arrays, or you can run the tests
in comparison mode, which will compare the results of the tests to the
reference ones within some tolerance.

It is a new build dependency of astropy 3.0.

I will maintain it within the Debian Python team.

Best regards

Ole



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

2018-01-12 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pytest plugin to check for files left open at the end of a 
test run

This package provides a plugin for the pytest framework that allows
developers to detect whether any file handles or other file-like
objects were inadvertently left open at the end of a unit test. It is
a new build dependency of astropy 3.0.

I will maintain it within the Debian Python team.

Best regards

Ole



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

2018-01-12 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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-doctestplus
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pytest plugin providing advanced doctest features

This package contains a plugin for the pytest framework that provides
advanced doctest support and enables the testing of reStructuredText
(".rst") files. It is a new build dependency of astropy 3.0.

I will maintain it within the Debian Python team.

Best regards

Ole



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

2018-01-12 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pytest plugin to control access to online data files

This package provides a plugin for the pytest framework that allows
developers to control unit tests that require access to data from the
internet. It is a new build dependency of astropy 3.0.

I will maintain it within the Debian Python team.

Best regards

Ole



Python 2 removal strategy

2018-01-10 Thread Ole Streicher
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 strategy: The
old version 2.0 is supported upstream for ~2 years, and I want to have a
smooth migration path. I checked the wiki, but could not find good
information about migration.

I thought of a temporary package split: create a new source package
"astropy" that inherits of the current python-astropy package, but only
builds python3-astropy (and the utils + doc, which depend on
python3-astropy), and update this to version 3.0. Then I would remove
these binary packages from the python-astropy package. In parallel, I
would file bugs (severity: important) to remove the reverse dependencies
of the Python 2 packages (many of them are mine, but also may have
reverse dependencies).

As long as there are substantial problems with the removal of the Python
2 support, I then keep the "old" python-astropy package updated. Once
everything is figured out and we decide to finally kick out Python 2
support (from Debian-Astro, or from Debian), I would set the remaining
bugs as RC, and (once they are solved) remove the "python-astropy"
package.

Does this sound reasonable? And how should I do this technically?

Best regards

Ole



Packaging with 2to3

2017-12-18 Thread Ole Streicher
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 the Python 3 code through
2to3?

Best regards

Ole



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

2017-12-17 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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://www.stsci.edu/resources/software_hardware/stsci_python
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Miscellaneous Python tools for astrophysics from STScI

This package provides a selection of tools for FITS and WCS handling
image handling, and data analysis, used by other STScI packages.

The package is a dependency of the pyraf package. It will be maintained
by the Debian Astro team. A git repository will be created at

https://anonscm.debian.org/git/debian-astro/packages/stsci.tools.git

Best regards

Ole



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

2017-10-24 Thread Ole Streicher
Package: wnpp
Severity: wishlist
Owner: Ole Streicher <oleb...@debian.org>
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/radio-beam
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Tools for Radio Beam IO and Manipulation

Radio Beam is a simple toolkit for reading beam information from FITS
headers and manipulating beams. Some example applications include
Convolution/deconvolution and Unit conversion (Jy to/from K).

The package is a new dependency of the spectral-tools package. It will
be maintained by the Debian Astro team. A git repository will be created
at

https://anonscm.debian.org/git/debian-astro/packages/radio-beam.git

Best regards

Ole



Re: MBF for deprecating Python2 usage

2017-08-08 Thread Ole Streicher
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.
>> 
>
> my problem with that plan is all of the printed documentation saying to
> learn python, type "python".

All *actual* printed documentation? Which refers to Python 3? Could you
give an example here?

Otherwise, (if using a Python 2 book), one of the next steps would be
"print 'hello world'", and nothing would prevent from the horrible
experience that the book is outdated anyway.

Sorry, I don't see the problem with "printed documentation".

Best regards

Ole



Re: MBF for deprecating Python2 usage

2017-08-04 Thread Ole Streicher
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 build from source, which means they’ll be installing it into
> /usr/local/bin not /usr/bin, and they’ll have to change their shebang
> lines anyway.

It is very usual to use "#!/usr/bin/env python" as shebang, exactly for
the case that python is not installed in /usr/bin.

>> Such a change would be actively user hostile.
>> 
>> When python2.7 goes away, /usr/bin/python should go too.
>
> Maybe in the short term (as Matthias suggests), but I’m not so sure
> it’s best to disappear /usr/bin/python forever.  /usr/bin/python is
> not just the common shebang (and we should be actively transitioning
> to /usr/bin/python2 for that), but it’s also the command line UI for
> people wanting to learn Python, or just wanting to get an interactive
> interpreter to play with.

That is -- at least in my environmet -- "ipython", or (for Python 3)
"ipython3".

> There will be a day when, if they get a command not found when typing
> `python` at a shell prompt, they will wonder why Debian is broken.

IMO it would be better to communicate that the best way for an
interactive session is "ipython3" (or "python3", if you insist). I would
wonder when todays tutorials (that cover Python 3) recommend to use
plain "python".

> I think the transition should roughly be:
>
> * Update policy and tooling so that any scripts that require Python 2
> use /usr/bin/python2 in their shebang.
>
> * Educate our users that they should be using `python2` for anything
> that has not been ported.
>
> * Port as much as possible to Python 3 (eventually, everything
> maintained in Debian) and /usr/bin/python3 in their shebang.

I disagree here, and I don't see an advantage over letting
/usr/bin/python just die with Python 2.

I would also like to point PEP 394, which has a number of arguments why
/usr/bin/python should remain as Python 2.

https://www.python.org/dev/peps/pep-0394/

Best regards

Ole



How to package for jython?

2017-03-15 Thread Ole Streicher
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 the .py go? I assume /usr/share/jython/Lib/ ?

 * how should I set the classpath that the jar is found?

If you are curious, it is this:

http://www.star.bristol.ac.uk/~mbt/stilts/sun256/jystilts.html

Best regards

Ole



Re: PyPI source or github source?

2017-03-13 Thread Ole Streicher
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 debian/changelog instead, but this looks more like a hack than a
clean solution. Unfortunately, they did't provide pypi source; otherwise
I would have used them.

Use case: 

https://github.com/spacetelescope/pysynphot

The originally "relic" package which extracts the info from git:

https://github.com/jhunkeler/relic

The "fake" relic package is in a Debian patch:

https://sources.debian.net/src/pysynphot/0.9.8.5%2Bdfsg-1/debian/patches/Don-t-use-relic-package-for-version-info.patch

Best

Ole



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

2016-12-14 Thread Ole Streicher
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.

Since skimage is one of the central packages, I would again ask to put
it under science|python team maintenance. Especially when under some
time pressure (upcoming freeze, combined with autoremovals of packages)
it would help a lot if the problems could be debugged within a standard
Debian developer workflow, without the need to switch to github or so.

Best regards

Ole



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

2016-05-06 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://ejeschke.github.com/ginga
* License : BSD-3-Clause
  Programming Lang: Python
  Description : The Ginga astronomical FITS file viewer
 Ginga is a toolkit designed for building viewers for scientific image
 data in Python, visualizing 2D pixel data in numpy arrays.
 It can view astronomical data such as contained in files based on the
 FITS (Flexible Image Transport System) file format.  It is written and
 is maintained by software engineers at the Subaru Telescope, National
 Astronomical Observatory of Japan.
 .
 The Ginga toolkit centers around an image display object which supports
 zooming and panning, color and intensity mapping, a choice of several
 automatic cut levels algorithms and canvases for plotting scalable
 geometric forms.  In addition to this widget, a general purpose
 "reference" FITS viewer is provided, based on a plugin framework.
 A fairly complete set of standard plugins are provided for features
 that is expected from a modern FITS viewer: panning and zooming windows,
 star catalog access, cuts, star pick/fwhm, thumbnails, etc.

It will maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/ginga.git



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

2016-04-13 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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/esheldon/fitsio
* License : GPL-2+
  Programming Lang: Python
  Description :  Python library to read from and write to FITS files
 Fitsio is a Python wrapper on the CFITSIO library. It allows direct
 access to the columns of a FITS binary table which can be useful for
 reading large fits files.

This package will maintained within the Debian Astronomy Working Group.
A git repository will be created on alioth:

https://anonscm.debian.org/cgit/debian-astro/packages/python-fitsio.git

Best regards

Ole





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

2016-02-06 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://github.com/spacetelescope/pyasdf
* License : BSD
  Programming Lang: Python
  Description : Python tools to handle ASDF files
 ASDF (Advanced Scientific Data Format) is a proposed 
 next generation interchange format for scientific data.

This package will maintained within the Debian Astronomy Working Group.
A git repository is created on alioth [1].

Best regards

Ole

[1] https://anonscm.debian.org/cgit/debian-astro/packages/asdf.git



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

2016-02-04 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://ssb.stsci.edu/pysynphot/docs/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python Synthetic Photometry Utilities
 pysynphot simulates photometric data and spectra as they are observed
 with the Hubble Space Telescope (HST). Passbands for standard
 photometric systems are available, and users can incorporate their
 own filters, spectra, and data.

This package will maintained within the Debian Astronomy Working Group.
A git repository is created on alioth [1].

Best regards

Ole

[1] https://anonscm.debian.org/cgit/debian-astro/packages/pysynphot.git



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

2016-01-29 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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>
* URL : http://dan.iel.fm/emcee/
* License : MIT
  Programming Lang: Python
  Description :  Kick ass affine-invariant ensemble MCMC sampling for Python
 emcee is an extensible, pure-Python implementation of Goodman &
 Weare's Affine Invariant Markov chain Monte Carlo (MCMC) Ensemble
 sampler. It's designed for Bayesian parameter estimation.

This package will maintained within the Debian Astronomy Working Group.
A git repository will be created on alioth [1].

Best regards

Ole

[1] https://anonscm.debian.org/cgit/debian-astro/packages/emcee.git



Request to join DPMT

2016-01-06 Thread Ole Streicher
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 to astronomy.

My Alioth account is: olebole

I have read and accept the Debian Python Modules Team's Policy.

I already applied directly in alioth, but didn't get a response.

Best regards

Ole



Re: Request to join DPMT

2016-01-06 Thread Ole Streicher
Scott Kitterman <deb...@kitterman.com> 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 point "send
reminder" of my own todo-list :-) Sorry, and thanks.

Cheers

Ole



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

2015-12-12 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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
* License : BSD-2-Clause
  Programming Lang: Python
  Description : Software library for solar physics based on Python
 SunPy is a community-developed free and open-source software package
 for solar physics. SunPy is meant to be a free alternative to the
 SolarSoft data analysis environment which is based on the IDL
 scientific programming language sold by Exelis. Though SolarSoft is
 open-source IDL is not and can be prohibitively expensive. The aim
 of the SunPy project is to provide the software tools necessary so
 that anyone can analyze solar data.

This package will maintained within the Debian Astronomy Working Group.
A git repository is created on alioth [1].

Best regards

Ole

[1] https://anonscm.debian.org/cgit/debian-astro/packages/sunpy.git



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

2015-12-12 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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/pyephem/
* License : LGPL-3
  Programming Lang: Python
  Description : Compute positions of the planets and stars
 PyEphem provides an ephem Python package for performing high-precision
 astronomy computations. The underlying numeric routines are coded in C
 and are the same ones that drive the popular XEphem astronomy
 application, whose author, Elwood Charles Downey, generously gave
 permission for their use in PyEphem. The name ephem is short for the
 word ephemeris, which is the traditional term for a table giving the
 position of a planet, asteroid, or comet for a series of dates.

This package will maintained within the Debian Astronomy Working Group.
A git repository is created on alioth [1].

Best regards

Ole

[1] https://anonscm.debian.org/cgit/debian-astro/packages/pyephem.git



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

2015-12-07 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://astropy.org/montage-wrapper/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python wrapper for the Montage mosaicking toolkit
 The montage-wrapper module (formerly python-montage) is an Astropy
 affiliated package that provides a way to run the Montage Astronomical
 Image Mosaic Engine from Python, including both functions to access
 individual Montage commands, and high-level functions to facilitate
 mosaicking and reprojecting.

This is an Astropy Affiliated Package [1]. It will maintained
within the Debian Astronomy Working Group. A git repository is
created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/montage-wrapper.git



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

2015-11-29 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://github.com/astropy/specutils
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Base classes and utilities for astronomical spectra
 The specutils package implements base classes and utilities for
 interacting with astronomical spectra in Python and the Astropy
 project. It is intended for eventual merger with the astropy package,
 but for now is being developed independently.

This is an Astropy Affiliated Package [1]. It will maintained
within the Debian Astronomy Working Group. A git repository is
created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/specutils.git



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

2015-11-23 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://github.com/astropy/photutils
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Astropy affiliated package for image photometry
 Photutils contains functions for:
  * estimating the background and background rms in astronomical images
  * detecting sources in astronomical images
  * estimating morphological parameters of those sources (e.g., centroid
and shape parameters)
  * performing aperture and PSF photometry

This is an Astropy Affiliated Package [1]. It will maintained
within the Debian Astronomy Working Group. A git repository is
created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/photutils.git



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

2015-11-10 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://www.astroml.org/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python Machine Learning library for astronomy (performance 
addons)
 AstroML is a Python module for machine learning and data mining built on
 numpy, scipy, scikit-learn, and matplotlib. It contains a growing library of
 statistical and machine learning routines for analyzing astronomical data in
 python, loaders for several open astronomical datasets, and a large suite of
 examples of analyzing and visualizing astronomical datasets.
 .
 This package contains the performance add-ons

This package will be created as an extension of the "astroml" package [1].
It will maintained within the Debian Astronomy Working Group. A git
repository is created on alioth [2].

Best regards

Ole

[1] https://bugs.debian.org/756994
https://anonscm.debian.org/cgit/debian-astro/packages/astroml.git
[2] https://anonscm.debian.org/cgit/debian-astro/packages/astroml-addons.git



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

2015-11-08 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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/astropy/astroscrappy
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Optimized Cosmic Ray Annihilation in Python
 Astro-SCRAPPY is designed to detect cosmic rays in images (numpy
 arrays), based on Pieter van Dokkum's L.A.Cosmic algorithm.
 Parallelization is achieved using OpenMP.

This is an Astropy Affiliated Package [1]. It will maintained
within the Debian Astronomy Working Group. A git repository is
created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/astroscrappy.git



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

2015-10-26 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://ccdproc.readthedocs.org/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Basic data reductions of astronomy CCD images

The ccdproc package provides many of the necessary tools for processing
of ccd images built on a framework to provide error propagation and bad
pixel tracking throughout the reduction process.

It will maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/ccdproc.git



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

2015-10-20 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher <oleb...@debian.org>
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://aplpy.github.io/
* License : MIT
  Programming Lang: Python
  Description : Astronomical Plotting Library in Python

APLpy is a Python module aimed at producing publication-quality plots of 
astronomical imaging data in FITS format. The module uses Matplotlib, a 
powerful and interactive plotting package. It is capable of creating output 
files in several graphical formats, including EPS, PDF, PS, PNG, and SVG.

It will maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/aplpy.git



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

2015-08-16 Thread Ole Streicher
Hi Josue,

Debian FTP Masters ftpmas...@ftp-master.debian.org 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
Conflicts here. Did you investigate the other optione?

* Try to convince glue-sprite to change their Python package name. This
could work since their package seem to be used just internally.

* Try to convince glueviz upstream to change their package name (to
glueviz?)

Having two packages with the same name is at least very unfortunate.

Best regards

Ole



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

2015-08-16 Thread Ole Streicher
Dmitry Shachnev mity...@debian.org 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 change their Python package name. This
 could work since their package seem to be used just internally.

 * Try to convince glueviz upstream to change their package name (to
 glueviz?)

 Having two packages with the same name is at least very unfortunate.

 It is not just unfortunate, it is also a violation of Policy §10.1,
 which says:

   Two different packages must not install programs with different
   functionality but with the same filenames.

Strictly speacking, these are Python packages and not programs, so I was
not sure whether this applies here. Therefore I used the phrasing at
least :-)

Best

Ole



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

2015-08-14 Thread Ole Streicher
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 deil.christ...@gmail.com
An: sub...@bugs.debian.org



Package: wnpp
Owner: Christoph Deil deil.christ...@gmail.com 
mailto:deil.christ...@gmail.com

Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
mailto:debian-de...@lists.debian.org , debian-as...@lists.debian.org
mailto:debian-as...@lists.debian.org , debian-python@lists.debian.org
mailto:debian-python@lists.debian.org

* Package name: sherpa
  Version : 4.7
  Upstream Author : Smithsonian Astrophysical Observatory / Chandra 
X-Ray Center

* URL : https://github.com/sherpa/sherpa
* License : GPLv3+
  Programming Lang: Python
  Description : Modeling and fitting in Python

Sherpa is a Python package for modeling and fitting. It enables the user 
to construct complex models from simple definitions and fit those models 
to data, using a variety of statistics and optimization methods.


It was originally developed by the Smithsonian Astrophysical Observatory 
/ Chandra X-Ray Center as part of the larger CIAO package for X-ray data 
analysis [1].

Recently it became on open-source, open-development project [2] and
development was moved to Github [3].

It will maintained within the Debian Astronomy Working Group.
A git repository will be created on alioth [4].

I’ll attend the sprint [5] tomorrow and will try to follow the
instructions at [6] to get this packaged for Debian.

Best regards,
Christoph


[1] http://cxc.cfa.harvard.edu/sherpa/
[2] http://pysherpa.blogspot.de/2015/04/sherpa-becomes-open-project.html
[3] https://github.com/sherpa/sherpa
[4] https://anonscm.debian.org/cgit/debian-astro/packages/sherpa.git
[5] https://wiki.debian.org/Sprints/2015/Astro
[6] https://wiki.debian.org/DebianAstro/AstropyPackagingTutorial/Preparation



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

2015-07-10 Thread Ole Streicher

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 xarthisius...@gmail.com
To: sub...@bugs.debian.org



Package: wnpp
Owner: Kacper Kowalik xarthisius...@gmail.com
Severity: wishlist
X-Debbugs-Cc:
debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org

* Package name: yt
  Version : 3.1
  Upstream Author : yt devs yt-...@lists.spacepope.org
* URL : http://yt-project.org/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Framework for analyzing and visualizing simulation data

yt is an analysis and visualization system written in Python, designed
for use with Astrophysical Simulation codes. yt can process data in a
myriad of ways and make a variety of visualizations. It is designed to
be portable across simulation codes, and it is developed by developers
from a variety of institutions and backgrounds.

It will maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [1].

Best regards
Kacper Kowalik

[1] https://anonscm.debian.org/cgit/debian-astro/packages/yt.git






--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559f6944.2090...@debian.org



Astropy affiliated packages tutorial

2015-06-09 Thread Ole Streicher
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 a good value to Debian.

To make this easier, I started a tutorial that is specific for these
packages, using wcsaxes as an example [2]. The third part is not
complete yet. Since it is my first tutorial, it would be great if I
could get some review before I announce it on the astropy-devel mailing
list.

Best regards

Ole

[1] http://www.astropy.org/affiliated/
[2] https://wiki.debian.org/DebianAstro/AstropyPackagingTutorial/Preparation
https://wiki.debian.org/DebianAstro/AstropyPackagingTutorial/Packaging
https://wiki.debian.org/DebianAstro/AstropyPackagingTutorial/Advanced


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55768f7e.4070...@debian.org



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

2015-05-11 Thread Ole Streicher
Ben Finney ben+deb...@benfinney.id.au writes:
 Ole Streicher oleb...@debian.org 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: pybuild seem to install all files into /usr/lib/? As far as I
understand the FHS [1], architecture independent files should go to
/usr/share. But, almost all python files (except maybe compiled .so
extensions) are architecture independent?

* .py sources
* .pyc bytecode
* .egg-info
* helper files in png, xml, txt, ...

What is the rationale between having all this in /usr/lib? And what
should I do with lintian-warnings like the one above? Just silence them?

I am asking a bit rigide here since I wanted to write a small newcomers
tutorial to package astropy affiliated packages [2]. These packages are
quite standard and therefore a good start for newcomers -- but then the
final package should be lintian-clean with not too much efforts.

The package I am using as example is wcsaxes [3], and it ends up in
quite a couple of /usr/lib/.png lintian warnings. I don't want to
explain to a newcomer just ignore these, or make them silent.

The Debian Policy [4] states (9.1.1):

| 1. The FHS requirement that architecture-independent application-
| specific static files be located in /usr/share is relaxed to a
| suggestion. In particular, a subdirectory of /usr/lib may be used by a
| package (or a collection of packages) to hold a mixture of
| architecture-independent and architecture-dependent files. However,
| when a directory is entirely composed of architecture-independent
| files, it should be located in /usr/share.

which is a bit contradicting to the current practice: If it is just a
suggestion, then maybe the lintian warning has not right severity
warning and should be lowered? And are pure python packages
(Architecure: all) not covered by the last sentence and should *not* be
in /usr/lib/ by policy?

What is the best way here, also to explain this in a tutorial to an
absolute newcomer?

Best regards

Ole

[1] http://www.pathname.com/fhs/
[2] http://www.astropy.org/affiliated/index.html
[3] https://pypi.python.org/pypi/wcsaxes/0.3
[4] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fv738ujq.fsf...@debian.org



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

2015-05-11 Thread Ole Streicher
Matthias Klose d...@debian.org 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 should be located in /usr/share.

The policy talks about when to put *files* into /usr/share. code files
are also files, so they should (from the policy point of view) make no
exception. And, in fact there is no difference between emacs .el(c)
files, perl .pl files, and python .py(c) files, right? Do you think perl
is wrong putting their files to /usr/share?

Even if the FHS speaks about data files, they (in my opinion) suggest
that this includes code:

| It is recommended that application-specific, architecture-independent
| directories be placed here. Such directories include groff, perl,
| ghostscript, texmf, and kbd (Linux) or syscons (BSD). They may,
| however, be placed in /usr/lib for backwards compatibility, at the
| distributor's discretion.

(the last sentence is clarified by the Debian Policy).

I don't want to argue that python should move to /usr/share; however it
would be nice (especially for beginners) if policy, lintian, and reality
would match here. And I am just trying to find out whom to ask for a
change. So, do you think it is just Lintian? Shall I put the
recommendation make lintian silent here in my tutorial?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbfza17r@news.ole.ath.cx



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

2015-05-11 Thread Ole Streicher
Charles Plessy ple...@debian.org 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 that. 

Cheers

Ole


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qna0yt@news.ole.ath.cx



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

2015-05-11 Thread Ole Streicher
Package: wnpp
Owner: Ole Streicher oleb...@debian.org
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 thomas.robitai...@gmail.com
* URL : https://github.com/astrofrog/wcsaxes
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Framework for plotting astronomical and geospatial data

WCSAxes is a framework for making plots of Astronomical data in
Matplotlib. It is affiliated with the Astropy project and is intended for
inclusion in the Astropy package once stable.

I am packaging this mainly as an example for a small Debian packaging
tutorial/workshop for astropy affiliated packages [1].

It will maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [2].

Best regards

Ole

[1] http://www.astropy.org/affiliated/index.html
[2] https://anonscm.debian.org/cgit/debian-astro/packages/wcsaxes.git


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5550c934.40...@debian.org



pybuild --pytest: empty directory?

2015-05-11 Thread Ole Streicher
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 builddir/.pybuild/pythonX.Y_2.7/build; python2.
= test session starts ==
platform linux2 -- Python 2.7.9 -- py-1.4.25 -- pytest-2.6.3
collected 0 items

===  in 0.00 seconds ===

(repeated similarly for python3). Looking into these directories, they
are empty (the build tree is in builddirbuild/lib.linux-x86_64-2.7/wcsaxes
and they are created by pybuild and setup.py:

   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:170: /usr/bin/python setup.py build 
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/wcsaxes
[...]

What am I doing wrong here?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mw1aamfz@news.ole.ath.cx



image-file-in-usr-lib

2015-05-10 Thread Ole Streicher
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 this?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zj5ca9t9@news.ole.ath.cx



multiprocessing.queues.Queue does not work in pbuilder?

2015-01-29 Thread Ole Streicher
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 linux2
Type help, copyright, credits or license for more information.
 from multiprocessing.queues import Queue
 q = Queue(8)
Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python2.7/multiprocessing/queues.py, line 63, in __init__
self._rlock = Lock()
  File /usr/lib/python2.7/multiprocessing/synchronize.py, line 147, in 
__init__
SemLock.__init__(self, SEMAPHORE, 1, 1)
  File /usr/lib/python2.7/multiprocessing/synchronize.py, line 75, in __init__
sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
OSError: [Errno 38] Function not implemented

The cause for this seems to be that /run/user is not mounted; if I mount
manually, it works fine:

# mkdir /run/user
# mount none /run/user -t tmpfs
# python
Python 2.7.9 (default, Dec 11 2014, 08:58:12) 
[GCC 4.9.2] on linux2
Type help, copyright, credits or license for more information.
 from multiprocessing.queues import Queue
 q = Queue(8)
 

However, how can/should I do this in debian/rules?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzy4omnenw@news.ole.ath.cx



RFP: glueviz -- Linked data visualization in Python

2014-09-20 Thread Ole Streicher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist
Owner: Ole Streicher oleb...@debian.org
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, Thomas Robitaille, Michelle Borkin
* URL : http://glueviz.org
* License : BSD-3
  Programming Lang: Python
  Description : Glue is a Python library to explore relationships within 
and among related datasets.

Hi,

I just got a request to package the Glue package. The package looks very
promising to me, and I think it is absolutely worth having it packaged for
Debian. I would do it myself, however I already maintain a number of packages
and I think that this is a good package to get involved into the Debian
procedures: modern development style, responsive upstream, clear license
etc. So, I would encourage you to start packaging it, if you are interested.

- From the debian-astro mailing list, we can offer you any help for the
packaging process, as well as sponsoring when the package is ready to upload.
We would also encourage you to put the packaging under the umbrella of
the Debian Astronomy Working Group for collective maintenance.

Best regards

Ole

-  Weitergeleitete Nachricht 
Date: Wed, 17 Sep 2014 17:09:25 +0200
From: Thomas Robitaille thomas.robitai...@gmail.com
Subject: Fwd: [AstroPy] [ANN] Glue v0.3, linked data visualization in Python

Hi Ole,

Since you've done a great job with making a package available on Debian
for astropy, I was wondering whether it would be easy for you to create
a package for another project, Glue, which had its first official
release a few weeks ago? (v0.3).

Glue is actually a pure Python, but the dependencies can be a pain (e.g.
qt4) so if we could have it in the Linux package managers, it would be a
great way to get people set up with it and all its dependencies. Since
it's pure Python, and all the dependencies (including astropy) are
already in linux package managers, I don't think there should be any
difficulties in packaging it. Do you think this would be possible? If
so, we can send more information about dependencies and so on.

(I've cc-ed Chris, who is the lead developer of Glue)

Thanks!
Tom

-  Original Message 
Subject:[AstroPy] [ANN] Glue v0.3, linked data visualization in Python
Date:   Wed, 13 Aug 2014 16:48:27 -0400
From:   Chris Beaumont beaum...@hawaii.edu
Reply-To:   Astronomical Python mailing list astr...@scipy.org
To: astropy astr...@scipy.org

Hi Everyone,

I'm happy to announce the first formal release of Glue, a library to
make interactive, linked-view visualizations in Python and Matplotlib.
You can find more information about Glue, including demo videos and
installation instructions, at

http://glueviz.org

There is also a mailing list at

https://groups.google.com/forum/#!forum/glue-viz

Some of Glue's highlights include:

- - A GUI for creating standard interactive visualizations of images,
spectral data cubes, and catalogs (images, scatterplots, histograms, etc)
- - Support for brushing and linking to select subsets
- - Deep python integration, making it easy to integrate python-based
workflows into Glue
- - Saveable state

While this is the first versioned release for Glue, it has been steadily
developed for the past year. The purpose of this release is to create a
stable reference point, and standard installation option, for new users.
Glue is supported by the Space Telescope Science Institute, Harvard, and
NASA.

Cheers,
Chris Beaumont

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUHVtxAAoJEHEVr9B3ENz3H1QQANqgYgeSLLyJEFPDIkyH5Llh
zWPdZ7FtBU6dSRvWR0q9orvYpXdvGg4dgNQkuPdT+GQsFYRDuLbapIbyTcJgv23W
33WepxlexB3C052xmOWx+g3O9mBcV6bF4QXWs04S0bmM7Vgk87VGWHtHzy49022a
BD5Qtq44PofWj3h4mAPoWroWCJQtrxfP/OY0Cgrz/xytUgVU1+D10f472gCbiiA7
K8Hcl8Hkp9UvfK3AVLoBC3B0sMG1O1h7eqKsVp+mOAYYT0R9+5s8KtaWowPjMYDs
dUTt4rT+OrVtIfNGN4pQ+pce7w5oMMtzykmqjaExHzVVny5YV8D91N88r+jX1ecm
4aZ0V55vxguOLzEBem6/gVCC2NWiy7Y9HVP8sLCmeqzvMB7sN2ssmmbC4lkvCbN9
cfWQA/YOhhRwuM2wq6jxWpGzATlgkDBtOyfpmJpK+uHzcT/Dgw9ZUp6kSIiZ8qnF
5EEeYtGAyG0YyLmw5SM3d5TCwW1EHZBJLrZ42CbQ3ddts4Q1OML1u8Lwin7jcYZN
vPT+qyTCUCYm08vKOKN0o6UuwagMydFbmivxH21Bvyh4/JZigMd4zJySVbjEeZQd
wwou4hRrMzVpWR34iYVlHmghQEnxwk1W6MN8/vSMOMK4d3nZ4N7ov2swbdCMQhyk
mM8TANs9dyy+3Yj+5Pbr
=umqW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/541d5b71.4070...@debian.org



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

2014-08-20 Thread Ole Streicher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist
Owner: Ole Streicher deb...@liska.ath.cx
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 Author : The Astropy Developers
* URL : http://astropy.org
* License : BSD
  Programming Lang: Python
  Description : Utilities to build and install Astropy affiliated packages

This project provides a Python package, astropy_helpers, which
includes many build, installation, and documentation-related tools
used by the Astropy project, but packaged separately for use by
other projects that wish to leverage this work. The motivation
behind this package and details of its implementation are in the
accepted Astropy Proposal for Enhancement (APE) 4.

I am still not sure whether this will be built from a separated source
package, of as an additional package of the python-astropy source.

Best

Ole

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT9LR/AAoJEHEVr9B3ENz3xj0QAIPexnVRkMemUs0dS/CNfD9c
5zSigmAdEBKLfgsAosbUBgBDl6JrWDFgBnOMArb/w1PIp1oe+8gpsh+TjngJg/yq
DSGeADlwGu25oCeDmtiNA8AVHlirV13VbchFTFREkEey0U9w4Wahq2abfBQhXjC9
sMbNJH8cNvDG3ai+/IpYXRxrF3uN/KipUJSGBftfeNuPvunkNWkIt2I82EhezqR9
PAjOIdEAovIizafStyZTlNirmS8F5bSVG7XXTyA6jhx1T53FWagq6y1MP8B33L4S
3EH3eVVjcttD9XlMdsIqLxlsEVPZd3SzjKKQNP1eeLHBUpMOfED7Ao49vay4Pab4
/N4H0uP0DS9yl5hFF9Qg5dA9TsC558x5ufWeNh3PtJH9qKakna8noqIzTDh6dNuy
HowvzltCQquqh1fPDCvfR8SF/EKEziP+/gDzwx4XP0iDE/ZBDry/Bjy6bjiklM1L
eRhVPu4HC+z0JyBSkUL21W/5M5cjgVsID49bcrKFSuf6NyG88St0yFAYc1B36VWh
0Lgddb+vt6AOO1B4h7ftF6JAYGz24/4M5znHTYN08ISoqChfYbVxZ80JmFQQ6Yau
g77gzN/2pPVnghyyaT1z3j31BAGaCbr4Sixny/T8Y3hg+rsQmoE1OamJz55iZ3tL
9L5nWkTlrpYfpdr4hq9L
=6naU
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f4b47f.1030...@liska.ath.cx



Re: RFS: python-pywcs

2011-11-04 Thread Ole Streicher
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 unlucky when I would be moved from the front page to
 some ChangeLog since I did most of the packaging work for these
 packages.
 Don't worry, we, sponsors, are not trying to steal your credits.
 The place which matters (and which is shown) is the uploaders. 
 If we change the changelog

As long as my name is kept as uploader, I am fine. I would not agree if
my name was removed there.

 And, I want to be kept responsible for the package
 with you (or someone else) as a reviewer who makes comments and finally
 decides about the inclusion, but does not touch the package himself. I
 see this in the same sense as a review of a science journal paper, is
 this the right picture of the mentoring process?
 Well, it is not the way most teams work in Debian. If I have to fight
 with you to make changes in your package, I prefer you find an other
 sponsor.

I guess this is some kind of misunderstanding here. What do you mean
with fight with me? I would think it is normal that one takes the
responsibility for a piece of code, and the others discuss their changes
with him first, instead of just changing them. I would not name this
fight for changes (especially in our case since at the end you will
have the final decision on uploading the package). I would not call a
usual peer-review science process as fighting either, would you?

But maybe I missed something here in the debian-science-policy?

 BTW, do you have any comments on my packages? 
 No, I haven't look. For science (and Java) packages, I am only
 sponsoring team maintained packages.

I will put them into the repo when the configuration issues are solved.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb3a4f5.7050...@liska.ath.cx



Re: RFS: python-pywcs

2011-11-04 Thread Ole Streicher
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 remaining packages (wcslib, cpl, esorex, python-cpl)?

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb3b8a5.6050...@liska.ath.cx



RFS: python-cpl

2011-11-03 Thread Ole Streicher
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 : python

It builds those binary packages:

python-cpl - Control pipeline recipes from the European Southern Observatory

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/python-cpl

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/p/python-cpl/python-cpl_0.3.5-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards,

Ole Streicher

P.S. This package requires the cpl package,
http://mentors.debian.net/package/cpl


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb2f486.6080...@liska.ath.cx