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

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-pyt...@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

Bug#943942: ITP: cds-healpix-java -- The CDS HEALPix library in Java

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-j...@lists.debian.org, debian-de...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: cds-healpix-java
  Version : none yet
  Upstream Author : Francois Xavier Pineau
* URL : https://github.com/cds-astro/cds-healpix-java
* License : BSD-3-Clause
  Programming Lang: Java
  Description : CDS HEALPix library in Java

HEALPix is an acronym for Hierarchical Equal Area isoLatitude
Pixelization of a sphere. As suggested in the name, this pixelization
produces a subdivision of a spherical surface in which each pixel
covers the same surface area as every other pixel. It is commonly
used to store all-sky astronomical images, most famously maps of the
cosmic microwave background. 

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

https://salsa.debian.org/debian-astro-team/cds-healpix-java

Best regards

Ole

Bug#951703: swig: does not install /usr/bin/swig anymore

[Ole Streicher]

Package: swig
Version: 4.0.1-2
Severity: serious
Affects: astrometry.net
Tags: +patch

The "swig" binary package does not install a symlink /usr/bin/swig -->
swig4.0 anymore. Since this breaks the build of a number of packages, I
set the severity to "serious".

Typical error message:

swig -python -I../include -I../include/astrometry -I/usr/include/wcslib
-I../include -I../include/astrometry -I/usr/include/wcslib -o
util_wrap.c util.i
error: command 'swig' failed with exit status 1

>From the source (on salsa), I guess this was just forgotten to adjust.

See

https://salsa.debian.org/debian/swig/merge_requests/1

for the trivial fix.

Best

Ole

Bug#956694: purify: FTBFS with spdlog 1.5.0

[Ole Streicher]

Hi Sebastian,

if spdlog does not ship with internal headersin Debian, shouldn't that
define be already set internally in spdlog?

Cheers

Ole

On 10.05.20 17:52, Sebastian Ramacher wrote:
> On 2020-05-10 17:45:00 +0200, Sebastian Ramacher wrote:
>> On 2020-04-26 10:49:31 +0200, Ole Streicher wrote:
>>> Control: affects -1 src:purify
>>>
>>> This now also affects the "purify" package, which is supposed to be
>>> rebuilt during the auto-casacore transition.
>> As far as I can tell, spdlog's pkg-config file adds
>> -DSPDLOG_FMT_EXTERNAL. With that define set, spdlog would use the
>> correct include files. However, purify seems to ignore these flag and
>> thus fails to build.
> … and spdlog's cmake config also contains this define.
>
> Best

Bug#961418: ITP: x11iraf -- Graphical tools to work with IRAF

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org

* Package name: x11iraf
  Version : 2.0~BETA
  Upstream Author : National Optical Astronomy Observatories
* URL : https://github.com/iraf-community/x11iraf
* License : Several MIT alike licenses
  Description : Graphical tools to work with IRAF

x11iraf provides graphical tools to work with IRAF, notably xgterm and
XImtool. IRAF (Image Reduction and Analysis Facility) is a general
purpose software system for the reduction and analysis of astronomical data.

This was in Debian until ~2004 [1], packaged by Zed Pobre, which then
was removed; mainly due to the licensing problem of IRAF (which are
resolved now as IRAF in in Debian since a while).

The package itself also contained some code that is not conform to DFSG,
notably the HTML and Table widgets. This code will be removed in the
package.

The package will be maintained in the Debian Astro Team, the repository is

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

Best regards

Ole

Ole

[1] http://bugs.debian.org/232472

Bug#961667: ITP: pfunit -- Parallel Fortran Unit Testing Framework

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: pfunit
  Version : 4.1.8
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/pFUnit
* License : NASA
  Language: Fortran 90
  Description : Parallel Fortran Unit Testing Framework

pFUnit is a unit testing framework enabling JUnit-like testing of
serial and MPI-parallel software written in Fortran. Limited suport
for OpenMP is also provided in the form of managing exceptions in a
thread-safe manner.

The package will be maintained in the Debian Science Team, the repository is

https://salsa.debian.org/science-team/pfunit

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#961668: ITP: fargparse -- Command line argument parsing for Fortran

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 961667 by -1

* Package name: fargparse
  Version : 0.9.5
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/fArgParse
* License : NASA
  Language: Fortran 90
  Description : Command line argument parsing for Fortran

This is a dependency of pfunit. The package will be maintained in
the DebianScience Team, the repository is

https://salsa.debian.org/science-team/pfunit

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#961669: ITP: gftl-shared -- Common gFTL containers for Fortran intrinsic types

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 961667 by -1
Control: block 961668 by -1

* Package name: gftl-shared
  Version : 0.9.5
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/
* License : Apache
  Language: Fortran 90
  Description : Common gFTL containers for Fortran intrinsic types

This is a dependency of pfunit. The package will be maintained in
the DebianScience Team, the repository is

https://salsa.debian.org/science-team/gftl-shared

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#961670: ITP: gftl -- Containers and iterators for Fortran

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 961667 by -1
Control: block 961668 by -1
Control: block 961669 by -1

* Package name: gftl
  Version : 1.2.5
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/gFTL
* License : Apache
  Language: Fortran 90
  Description : Containers and iterators for Fortran

gFTL provides a mechanism to easily create robust containers and
associated iterators which can be used within Fortran applications.
The primary methods are intended to be as close to their C++ STL
analogs as possible. These containers are a powerful productivity
multiplier for certain types of software development.

This is a dependency of pfunit. The package will be maintained in
the DebianScience Team, the repository is

https://salsa.debian.org/science-team/gftl

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#956578: libcasa-python3-4: package became uninstallable with update of libboost-python1.67.0

[Ole Streicher]

Control: tags -1 pending
Control: severity -1 serious
Control: severity 956580 serious

It compiles with the additional variables given as -D, and I intend to
upload this soon. I however lower the severity to "serious", as this is
the standard for FTBFS package (same for the aoflagger bug).

Cheers

Ole

Bug#956694: spdlog refers to files that it does not ship

[Ole Streicher]

Control: retitle -1 spdlog refers to header files that it does not ship
Control: reassign -1 spdlog-dev 1.5.0
Control: affects -1 src:sopt

This is an internal inconsistency of spdlog, therefore I am re-assigning
it. For me, the workaround in #953855 didn't work either, since then I
just get a number of unresolved fmt symbols:

cd /build/sopt-3.0.1/obj-x86_64-linux-gnu/cpp/tests && /usr/bin/cmake -E
cmake_link_script CMakeFiles/test_padmm.dir/link.txt --verbose=1
/usr/lib/ccache/c++  -g -O2 -fdebug-prefix-map=/build/sopt-3.0.1=.
-fstack-protector-strong -Wformat -Werror=format-security
-DSPDLOG_FMT_EXTERNAL -Wdate-time -D_FORTIFY_SOURCE=2  -std=gnu++11
-Wl,-z,relro >
/usr/bin/ld: CMakeFiles/copy_tiff.dir/copy_tiff.cc.o: in function
`fmt::v6::basic_format_context
>, char>::on_error(char const*)':
/usr/include/fmt/core.h:1169: undefined reference to
`fmt::v6::internal::error_handler::on_error(char const*)'
/usr/bin/ld: CMakeFiles/copy_tiff.dir/copy_tiff.cc.o: in function
`unsigned long long
fmt::v6::internal::width_checker::operator()(float)':
/usr/include/fmt/format.h:1977: undefined reference to
`fmt::v6::internal::error_handler::on_error(char const*)'
/usr/bin/ld: CMakeFiles/copy_tiff.dir/copy_tiff.cc.o: in function
`unsigned long long
fmt::v6::internal::precision_checker::operator()(float)':
/usr/include/fmt/format.h:1997: undefined reference to
`fmt::v6::internal::error_handler::on_error(char const*)'


Cheers

Ole

Bug#949762: Please update hypothesis package to >= 5.1

[Ole Streicher]

Hi Emanuel,

On Sat, 25 Jan 2020 08:59:00 -0300 Emmanuel Arias wrote:
> Hypothesis from >= 5.0.0 version drop Python 2 support. So, I think we
> should wait on Debian until
> python-hypothesis remove the Python2 support.

Since there is no more a Python2 package for hyptothesis, could I ask to
upgrade to 5.1 now? This starts to block upgrading the whole astropy
chain now.

Thanks

Ole

Bug#956694: purify: FTBFS with spdlog 1.5.0

[Ole Streicher]

Control: affects -1 src:purify

This now also affects the "purify" package, which is supposed to be
rebuilt during the auto-casacore transition.

Bug#944584: plplot-driver-qt: qtwidgets driver displays only greek characters in plplot-5.14.0-package

[Ole Streicher]

Hi Joachim,

could you provide a small program source that shows this behaviour? This
would make the debugging much easier.

Also, did you see it in the Debian version 5.15.0?

Best

Ole

Bug#944802: Package and executable "sextractor" renamed to "source-extractor"

[Ole Streicher]

Source: astrometry.net
Version: 0.78+dfsg-2
Severity: important

The package "sextractor was renamed to "source-extractor", and its
executable was renamed the same way. See #941466 for the rationale.

The package recommendation and the executable name in this package
should be adjusted accordingly.

https://bugs.debian.org/941466

Bug#944804: Package and executable "sextractor" renamed to "source-extractor"

[Ole Streicher]

Source: cpl-plugin-vimos
Version: 3.3.0+dfsg-1
Severity: important

The package "sextractor was renamed to "source-extractor", and its
executable was renamed the same way. See #941466 for the rationale.

The package recommendation and the executable name in this package
should be adjusted accordingly.

https://bugs.debian.org/941466

Bug#944803: Package and executable "sextractor" renamed to "source-extractor"

[Ole Streicher]

Source: cpl-plugin-fors
Version: 5.4.3+dfsg-1
Severity: important

The package "sextractor was renamed to "source-extractor", and its
executable was renamed the same way. See #941466 for the rationale.

The package recommendation and the executable name in this package
should be adjusted accordingly.

https://bugs.debian.org/941466

Bug#945824: [python3-numpy] Depends on python3.8 and python3.7

[Ole Streicher]

Package: python3-numpy
Version: 1:1.17.4-3
Control: affects -1 src:casacore

Dear numpy maintainers,

the numpy package depends on all possible Python 3 versions at the same
time:

* python
* python3.7
* python3.8

There is no need to depend on the individual Python versions; any
supported version should be sufficient. Otherwise both versions are
pulled, even when they are not used.

My specific problem with that is that CMake fails to find the Python 3.7
development libraries when Python 3.8 is installed without development
libs. This happens in the "casacore" package:

Build-Depends: [...], python3-dev, python3-numpy, [...]

This pulls python3.7, python3.8, python3.7-dev, but not (on purpose)
python3.8-dev, which makes the following CMake fail:

 find_package(Python3 REQUIRED COMPONENTS Interpreter Development NumPy)

results in

CMake Error at
/usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
  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)
  python3/CMakeLists.txt:4 (include)

While this is probably a bug in cmake, it would help if one could avoid
installing a Python version that is not standard for the moment.

Best regards

Ole

Bug#945825: [cmake] Can't find development files for Python 3.7

[Ole Streicher]

Package: cmake
Version: 3.15.4-1
Control: affects -1 src:casacore
Severity: important

Dear maintainer,

when both Python 3.7 and 3.8 are installed, cmake does not find the
development files of Python 3.7 and fails if not 3.8 development files
are installed. Specifically, when I try to build casacore, with the
following build dependencies:

Build-Depends: [...], python3-dev, python3-numpy, [...]

Here, python3-dev pull the Python 3.7 development package, but
python3-numpy also depends on Python 3.8 (see bug #945824).

When one now uses cmake's

 find_package(Python3 REQUIRED COMPONENTS Interpreter Development NumPy)

to get the required Python 3 components (of the default Python package,
which is 3.7), the resulting error is

---8<---
CMake Error at
/usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
  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)
  python3/CMakeLists.txt:4 (include)
---8<---

This currently breaks the build of the casacore package for the standard
Python version (and it looks that this will always happen when the
standard version is not the newest supported one).

Best regards

Ole

Bug#945389: Tried to upgrade skimage to see whether #945389 is fixed but failed

[Ole Streicher]

Hi Andreas,

I think that is the moment where the skimage build should be simplified
to the "official" build process: Python convention is that symbols
starting with an underscore are internal only (and ofcourse subject to
quick and unannounced changes). debian/bin/process_pyx.py however
depends on them (_build.py and f.e. the _changed() function). IMO this
should be taken out completely in favor of a standard, simplified build.
No idea however how difficult this is.

Cheers

Ole

> I tried my luck with #945389 since two Debian Med packages are depending
> from skimage.  So at first I tried to upgrade to the latest upstream
> version to possibly forward some reasonable bug report.  Unfortunately
> the build starts very early:
> 
> ...
>  debian/rules build
> py3versions: no X-Python3-Version in control file, using supported versions
> /usr/bin/make -j 4 -f debian/rules _build
> make[1]: Entering directory '/build/skimage-0.16.2'
> py3versions: no X-Python3-Version in control file, using supported versions
> python3.7 debian/bin/process_pyx.py 4
> Traceback (most recent call last):
>   File "debian/bin/process_pyx.py", line 13, in 
> from _build import _changed, process_tempita_pyx
> ImportError: cannot import name '_changed' from '_build' 
> (/build/skimage-0.16.2/debian/bin/_build.py)
> make[1]: *** [debian/rules:71: debian/build-stamp-pyx] Error 1
> ...

Bug#939943: Please upload python-jsonschema version 3 to unstable

[Ole Streicher]

Dear maintainer,

the version 3 of python-jsonschema is now in testing since a couple of
months. Would it be possible to upload it to unstable as well?

I am also waiting for it, to upload a new version of gammapy, which
fixes an RC bug.

Thank you!

Best

Ole

Bug#968781: python3-sunpy: Breaks python3-asdf

[Ole Streicher]

Control: block -1 by 934667

While one could try to get rid of the aioftp dependency, it is probably
best to instead package aioftp. This is already started:

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

I will see how I can support this. If this gets stuck at some point, one
should probably just remove the dependency for the moment.

Cheers

Ole

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

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-j...@lists.debian.org, debian-de...@lists.debian.org

* Package name: jfreesvg
  Version : 0.4.1
  Upstream Author :  David Gilbert
* URL : http://www.jfree.org/jfreesvg
* License : GPL-v2
  Programming Lang: Java
  Description : Java graphics library to generate content in SVG format 

JFreeSVG is a fast, light-weight, vector graphics library for the Java
platform that makes it easy to generate graphical output in SVG format
directly from Java code (via SVGGraphics2D). 

This is a new dependency of the starjava-ttools package. I will
maintain it within the Debian Java team. Salsa dir shall be created at

https://salsa.debian.org/java-team/jfreesvg

Best regards

Ole

Bug#956580: closed by Ole Streicher (Re: aoflagger: boost update makes aoflagger uninstallable)

[Ole Streicher]

Hi Sebastian,


On 15.04.20 09:45, Sebastian Ramacher wrote:
> Looking at aoflagger's build system, it could be affected by the same
> issues during the next Python 3 transition. The build system currently
> doesn't ensure that the libpython and libboost-python versions are
> compatabile. So let's keep this bug open to get this properly fixed for
> the next Python 3 transition.

The problem now re-appears, since boost it now 1.71 by default and this
seems to not work. Pinning it to 1.67 helps. However, I think this is
fragile and will break in future again.

What is the right way to ensure libpython3 and libboost-python are
compatible? What is the reason that they are not in the moment?

Best regards

Ole

Bug#962175: Cannot merge bugs with (resolved) archived block

[Ole Streicher]

Package: bugs.debian.org

Dear bugs.d.o maintainers,

when I try to (force)merge 870457 and 832884, I get the response shown
below. The primary bug (870457) originally had a block that was resolved
and archived long time ago, and it also does not appear as blocking
anymore. However it is given as the reason why the forcemerge didn't work.

Best

Ole


 Forwarded Message 
Subject: Processed (with 1 error): Re-intending and re-assigning
Date: Thu, 04 Jun 2020 08:48:07 +
From: Debian Bug Tracking System 
To: Ole Streicher 
CC: w...@debian.org

Processing commands for cont...@bugs.debian.org:

> retitle 870457 ITP: gavodachs -- Virtual Observatory server suite
Bug #870457 [wnpp] RFP: gavodachs -- Virtual Observatory server suite
Changed Bug title to 'ITP: gavodachs -- Virtual Observatory server
suite' from 'RFP: gavodachs -- Virtual Observatory server suite'.
> owner 870457 Markus Demleitner 
Bug #870457 [wnpp] ITP: gavodachs -- Virtual Observatory server suite
Owner recorded as Markus Demleitner .
> forcemerge 870457 832884
Bug #870457 [wnpp] ITP: gavodachs -- Virtual Observatory server suite
Bug #832884 [wnpp] RFP: python-gavovotable -- library for Virtual
Observatory VOTables
No valid blocking bug(s) given; not doing anything
Failed to forcibly merge 870457: Failure while trying to adjust bugs,
please report this as a bug: Unknown/archived blocking bug(s):680188.
 at /usr/local/lib/site_perl/Debbugs/Control.pm line 2133.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
832884: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832884
870457: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870457
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#962815: Please upgrade to latest upstream version (1.1.1)

[Ole Streicher]

Source: pywavelets
Version: 0.5.1-1.3
Severity: wishlist

Dear maintainer,

The current version of pywavelet (0.5.1) is quite old, from 2016. The
newest version, 1.1.1, is out since Oct 2019 and is now required for the
new version (0.17.2) of skimage. Therefore, I would ask to upgrade the
package to the latest version.

Best regards

Ole Streicher

Bug#959703: ITP: jsofa -- Java translation of IAU SOFA library

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-j...@lists.debian.org, debian-de...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: jsofa
  Version : 20190722
  Upstream Author : 
* URL : http://javastro.github.io/jsofa/
* License : jsofa and SOFA
  Programming Lang: Java
  Description : pure Java translation of the IAU's C SOFA software library

jsofa provides algorithms and software for use in astronomical computing,
including routines for Astrometry, Calendars, Times, Coordinates etc.

It is a new dependency of the "aladin" package. The packages will be maintained
under Debian Astro team maintainance, with the repository at

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

Best regards

Ole

Bug#959710: RM: scamp [armel armhf i386 mipsel] -- RoM; FTBFS (32 no longer supported)

[Ole Streicher]

Package: ftp.debian.org
Severity: normal
Control: block 959540 by -1

Please remove the binary packages of scamp from armel, armhf, i386, and
mipsel. 32 bit archs are no longer supported upstream and lead to
errornous packages (failing in the build time test).

This would allow to migrate the new version of the package to testing.

The package has no reverse dependencies.

Thank you, best regards

Ole

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

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-pyt...@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#959885: inkscape: crashes when called without X server

[Ole Streicher]

Package: inkscape
Version: 1.0~rc1-4
Severity: important
Control: affects -1 src:debian-astro

Dear maintainer,

I use inkscape when building the debian-astro package to convert our
logo from svg into several end user formats (pdf, png).

This doesn't work any longer, since inkscape crashes when called without
an X server, even when the gui is not used (and not displayed) at all:

-8<--
$ inkscape --batch-process Debian-Astro-logo.svg 
--export-filename=Debian-Astro-logo.pdf
Unable to init server: Could not connect: Connection refused

** (inkscape:1932018): WARNING **: 16:59:25.874: Fonts dir 
'/usr/share/inkscape/fonts' does not exist and will be ignored.

** (inkscape:1932018): WARNING **: 16:59:25.874: Fonts dir 
'/home/soo/.config/inkscape/fonts' does not exist and will be ignored.

ConcreteInkscapeApplication::create_window: Should not be called!

-8<--

When trying with a running X server, the program works, but the X server
does not display anything from inkscape.

This significantly complicates the usability of inkscape for batch
processing.

Best regards

Ole

Bug#959889: python3-sphinx-gallery: AttributeError: 'URLError' object has no attribute 'url'

[Ole Streicher]

Package: sphinx-gallery
Version: 0.5.0
Severity: serious
Tags: affects -1 src:astropy

Dear maintainer,

when I try to use sphinx-gallery to build the new astropy package, I get
the following error from sphinx-gallery:

Exception occurred:
  File "/usr/lib/python3/dist-packages/sphinx_gallery/docs_resolv.py",
line 260, in _handle_http_url_error
msg, e.url, extra, e.msg)
AttributeError: 'URLError' object has no attribute 'url'

The reason seems to be that urllib.error.URLError indeed has no such
attribute (anymore?) on Python 3.8

This seem fixed upstream and could probvably be solved by uploading a
new version.

Best regards

Ole

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

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-pyt...@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#960142: ITP: pyerfa -- Python bindings for ERFA routines

[Ole Streicher]

Dear Antonio,

I would happily step back and leave the packaging for you, and only ask
to do it within the Debian Astro team (I just invited you there). I
already created an (empty) git repository on salsa

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

which you could fill. I can also sponsor the package when it is ready
for upload.

My ITP was aloready closed by someone else as a duplicate, so just keep
your one open and take it as the real one.

Best regards

Ole

On 10.05.20 12:26, Antonio Valentino wrote:
> Dear Ole,
> thank you for submitting an ITP for pyerfa.
> I'm also interested to this package (I'm also an upstream maintainer) so
> I could help with the maintenance if you are interested. My salsa user
> ID is antonio.valentino (please not that I'm not a DD/DM).
>
>
> Finally I also filed an ITP for the same package [1].
> I'm going to close hat one as a duplicate.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960121
>
>
> kind regards
> antonio
>
> Il 09/05/20 22:39, Ole Streicher ha scritto:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Ole Streicher 
>> X-Debbugs-Cc: debian-pyt...@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#960314: ITP: tifffile -- Read and write TIFF(r) files with Python

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-pyt...@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#960314: Re-"assigning" ITP bug

[Ole Streicher]

Control: reassign -1 src:tifffile 20181128-3
Control: retitle -1 Please add a python3-tifffile package

Hi Andreas,

I just found out that you already packaged tifffile, there is just not a
dedicated Python 3 package.

Could you split the python module in a separate package so that it
conforms to the Python policy?

Thank you!

Cheers

Ole

Bug#1000986: Montage-wrapper does not play well with astropy 5.0

[Ole Streicher]

Package: python3-montage-wrapper
Version: 0.9.9-4
Severity: serious

The package fails in CI test with astropy 5.0. Since it is abandoned 
upstream, I do not intend to fix this, but will remove the package 
(unless someone else is going to take it over).


The "montage" package now comes with its own wrapper, python3-montagepy. 
Please migrate to this package.


Ole

Bug#1000815: skimage FTBFS: sphinx_gallery.docs_resolv error

[Ole Streicher]

Control: tags -1 moreinfo unreproducible

Dear Rebecca,

I can't reproduce this problem; for me skimage builds find. Can you 
confirm that the package still FTBFSs, so that it was not a temporary 
glitch in one of the build dependencies (most probably 
python3-sphinx-gallery)?


Best

Ole

Bug#1001528: FTBFS with eigen3/3.4.0

[Ole Streicher]

Control: forwarded -1 https://github.com/astro-informatics/purify/issues/290

I am afraid that I am unable to fix this: the Debian version of purify 
uses a patched version of Eigen3, and since the patch still succeeds 
(with some offsets) I assume that it is not applied upstream yet.


There is a newer upstream version 3.0.1 of purify (which doesn't require 
the patch); however this doesn't compile for me as well -- with the same 
error as you see now. There are other compilation errors which I saw 
with earlier versions of purify.


These errors were reported upstream already two years ago in

https://github.com/astro-informatics/purify/issues/290

and I also reported some test failures; however without response. The 
last commit in the repository was on May 2021.


Unless the communication with upstream improves, we probably don't get 
this fixed (except you have an idea yourself).


Best

Ole

Bug#1001491: astroscrappy: autopkgtest regression on armhf

[Ole Streicher]

forwarded 1001491 https://github.com/astropy/astroscrappy/issues/71
thanks

On 10.12.21 22:06, Paul Gevers wrote:

Source: astroscrappy
Version: 1.1.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of astroscrappy the autopkgtest of astroscrappy 
fails in testing when that autopkgtest is run with the binary packages 
of astroscrappy from unstable on armhf. It passes when run with only 
packages from testing. In tabular form:


    pass    fail
astroscrappy   from testing    1.1.0-1
all others from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be 
found on

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=astroscrappy

https://ci.debian.net/data/autopkgtest/testing/armhf/a/astroscrappy/17430190/log.gz 



= test session starts 
==

platform linux -- Python 3.9.9, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
rootdir: /tmp/autopkgtest-lxc.ijtoh3o_/downtmp/autopkgtest_tmp
plugins: doctestplus-0.11.1, mock-3.6.1, arraydiff-0.3, 
filter-subpackage-0.1.1, cov-3.0.0, hypothesis-5.43.3, 
astropy-header-0.1.2, remotedata-0.3.2, openfiles-0.5.0

collected 25 items

tests/test_astroscrappy.py .  [  4%]
tests/test_cleaning.py F...  [ 20%]
tests/test_gmos.py .  [ 24%]
tests/test_utils.py ...  [100%]

=== FAILURES 
===
__ test_median_clean 
___


     def test_median_clean():
     # Because our image only contains single cosmics, turn off
     # neighbor detection. Also, our cosmic rays are high enough
     # contrast that we can turn our detection threshold up.
     _mask, clean = detect_cosmics(imdata, readnoise=10., gain=1.0,
   sigclip=6, sigfrac=1.0, 
cleantype='median')

     assert (clean[crmask] != imdata[crmask]).sum() == crmask.sum()
     # Run it again on the clean data. We shouldn't find any new 
cosmic rays

     _mask2, _clean2 = detect_cosmics(clean, readnoise=10., gain=1.0,
  sigclip=6, sigfrac=1.0, 
cleantype='median')

  assert _mask2.sum() == 0

E   assert 8780 == 0
E    +  where 8780 = 0xf3630530>()
E    +    where 0xf3630530> = array([[False, False, False, ..., False, False, False],\n 
   [False, False, False, ..., False, False, False],\n 
...alse],\n   [False, False, False, ..., False, False, False],\n
[False, False, False, ..., False, False, False]]).sum


/usr/lib/python3/dist-packages/astroscrappy/tests/test_cleaning.py:22: 
AssertionError
=== short test summary info 


FAILED tests/test_cleaning.py::test_median_clean - assert 8780 == 0
 1 failed, 24 passed in 23.13s 
=

autopkgtest [21:12:12]: test command1

Bug#1008915: BTS: setting to "notfound" doesn't work correctly

[Ole Streicher]

Package: bugs.debian.org
Severity: important
Control: affects -1 src:astropy

Dear bugs.d.o maintainer,

I had a bug [1] in the "astropy" source package that was fixed by a new 
upload. Since I forgot to mention the bug id, I resolved the bug with a 
mail to BTS (see attachment 1), making the mistake to use the wrong 
source package name (python-astropy instead of astropy). This was 
corrected with a subsequent mail (see attachment 2), which mentions that 
the error is not found in astropy (and the correct version). However, 
the BTS answered


Ignoring request to alter found versions of bug #1008441 to the same 
values previously set


and refused to set the bug fixed (Attachment 3). To me, this looks as 
the "notfound" algorithm doesn't compare the (explicitly given) source 
package name, but just the version number. This is obviously a bug.


Best regards

Ole


[1] https://bugs.debian.org/1008441--- Begin Message ---

Source: python-astropy
Source-Version: 5.0.2-2

This is fixed with the just-uploaded new release; I just forgot to mention
it in the changelog.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 27 Mar 2022 12:25:58 +0200
Source: astropy
Architecture: source
Version: 5.0.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Astronomy Maintainers 

Changed-By: Ole Streicher 
Changes:
 astropy (5.0.2-2) unstable; urgency=medium
 .
   * Update WCSLIB support to version 7.9
Checksums-Sha1:
 e52c1b0cc45c4bf3691a04486123955abb1e3a03 3069 astropy_5.0.2-2.dsc
 61707b00be06940605475740f1a2f34aa5410caf 27800 astropy_5.0.2-2.debian.tar.xz
Checksums-Sha256:
 b1e524e5ad9ca56bec95f31e82180a7c868448fe2c08214cfd8c24db11fa01ba 3069 
astropy_5.0.2-2.dsc
 5572895eecddef912f6c917e732d0d706562e42991531a29987320967bdc79cb 27800 
astropy_5.0.2-2.debian.tar.xz
Files:
 947410bcd02f6caad2c8f7102f0fd7a0 3069 python optional astropy_5.0.2-2.dsc
 1f71160e24823d760b03cf3a0336d5fe 27800 python optional 
astropy_5.0.2-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuvxshffLFD/utvsVcRWv0HcQ3PcFAmJAStkACgkQcRWv0HcQ
3PfUlA//Z8xpMvVDqJVpoPQuU8Zs+dU/V6u9YiYOa6tum/CsWrl0HXuH6E6Axful
zi2Zy2g/ww0gzmKaQxtTA6bVRpwqNknOwvkpjx043arj1AZOJt2jOIfp9ICM6xRT
GpLw54w8qwmCT7RVdzgG6BZ+MWF/CHsj2Z15EoOATdwrvQizwnKXBUZVPdFiDq22
2Fs0Mbs2fm+P6JjIJGKjwsm0PfJOo569imuD4DfGZjCvznExsKhnnZXo2TltGHDL
8hFxXuulpPly7sZcpWIx4BIZblHyTZBXgtDg5GobVCOdnhxPn0xF34TY91IDC1aa
BkCbKRxWq4FPYLhLcCOioeqatuL44OLxbyp+nfSf0UmIK/afeNEj1M5lgn+9woZK
0ipnh87VcYzvmuwmxQogEo0Kc+9/LocZtP4r3c6mZSN8/ubbpvt9QqfjuGXDg4FE
pm7oYT+COqahFwts6EvVGnALUQ1nLoz11vcmBcXP4KZcj/jaNbYiznXw/1dmsrIg
SV5gbdutokUZt8Y/GRieCVE4rH2feJkR640SgRMRqluEGYV9rhPMDujY7mnjfrGH
ep30yotx6I/9SiCcA14l2UtmiZ7fxjev1OGAUQIXULXBi5KNdKOa61wiXGsIvkYg
fcQ1vzGe5whsDgtehxKYowIJVPC+WFODksCvNnthcxP53Jv77WI=
=IhXl
-END PGP SIGNATURE End Message ---
--- Begin Message ---

notfound 1008441 astropy/5.0.2-2
thanks--- End Message ---
--- Begin Message ---
Processing commands for cont...@bugs.debian.org:

> notfound 1008441 astropy/5.0.2-2
Bug #1008441 {Done: Ole Streicher } [src:astropy] astropy: 
FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 
"3.10 3.9" returned exit code 13
Ignoring request to alter found versions of bug #1008441 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1008441: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008441
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

--- End Message ---

Bug#1000435: Matplotlib crashes on mips64el in lines.py

[Ole Streicher]

Source: matplotlib
Severity: serious
Version: 3.5.0-1
Control: affects -1 yt
Control: affects -1 astropy

With the new matplotlib version, I now have crashes with a segmentation fault
in at least two of my packages on mips64el, which cause a FTBFS: yt and
astropy. On both packages, the crash happens here:

--8<
  File "/usr/lib/python3/dist-packages/matplotlib/lines.py", line 840 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 299 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/axis.py", line 1163 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
_draw_list_compositing_images
  File "/usr/lib/python3/dist-packages/matplotlib/axes/_base.py", line 3082 in 
draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/image.py", line 132 in 
_draw_list_compositing_images
  File "/usr/lib/python3/dist-packages/matplotlib/figure.py", line 2803 in draw
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 50 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/artist.py", line 73 in 
draw_wrapper
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_agg.py", 
line 436 in draw
--8<

Build log on Astropy: 
https://buildd.debian.org/status/fetch.php?pkg=astropy&arch=mips64el&ver=5.0-1&stamp=1637626067&raw=0

Build log on yt: 
https://buildd.debian.org/status/fetch.php?pkg=yt&arch=mips64el&ver=4.0.1-3&stamp=1637588650&raw=0

This happens on both Python 3.9 and 3.10. The I will try to create a stacktrace 
for it.

Bug#1003331: ITP: asdf-wcs-schemas -- World Coordinate System (WCS) ASDF schemas

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: asdf-wcs-schemas
  Version : 0.1.1
  Upstream Author : The ASDF Developers
* URL : https://github.com/asdf-format/asdf-wcs-schemas
* License : BSD-3-Clause
  Programming Lang: Python
  Description : World Coordinate System (WCS) ASDF schemas

This package provides ASDF schemas for validating WCS tags.
Users should not need to install this directly; instead, install an
implementation package such as asdf-astropy, which will include
asdf-coordinates-schemas as a dependency. ASDF (Advanced Scientific Data
Format) is a proposed next generation interchange format for scientific
data,mainly used by the Space Telescope Science Institude (STScI).

It is a build dependency of the gwcs package. I will
maintain it within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/asdf-gwcs-schemas

Best regards

Ole

Bug#998999: tix: missing required debian/rules targets build-arch and/or build-indep

[Ole Streicher]

Control: tags -1 + patch

Dear maintainer,

I have a package (ftools-fv) that depends on tix, which is scheduled for 
autoremoval on 2021/02/08. To avoid this, I prepared an NMU, which I am 
going to upload to DELAYED/7. This NMU just fixed this one issue 
(debdiff attached).


When looking into the package, I would recommend a few more small steps:

 * simplify d/rules using debhelper,
 * put the package under tcltk team maintainance
 * create a repository on Salsa to help maintaining it

Best regards

Olediff -Nru tix-8.4.3/debian/changelog tix-8.4.3/debian/changelog
--- tix-8.4.3/debian/changelog  2017-07-12 09:45:53.0 +0200
+++ tix-8.4.3/debian/changelog  2022-01-10 14:01:21.0 +0100
@@ -1,3 +1,10 @@
+tix (8.4.3-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/rules: Add build_indep and build_arch targets (Closes: #998999)
+
+ -- Ole Streicher   Mon, 10 Jan 2022 14:01:21 +0100
+
 tix (8.4.3-10) unstable; urgency=medium
 
   * added a symlink Tix8.4 -> Tix8.4.3, by postinst and postrm
diff -Nru tix-8.4.3/debian/rules tix-8.4.3/debian/rules
--- tix-8.4.3/debian/rules  2017-07-12 09:45:53.0 +0200
+++ tix-8.4.3/debian/rules  2022-01-10 13:56:06.0 +0100
@@ -35,6 +35,8 @@
 d_run  = debian/$(p_run)
 d_dev  = debian/$(p_dev)
 
+build_indep:
+build_arch: build
 build: build-static build-shared
 
 build-static: build-static-stamp

Bug#1004041: gwcs FTBFS

[Ole Streicher]

Control: block -1 by 1003331

This is because the new gwcs needs asdf-wcs-schemas, which is in the NEW 
queue, but not accepted yet.

Bug#1006200: ITP: asdf-standard -- Standards document describing ASDF

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: asdf-standard
  Version : 1.6.0
  Upstream Author : The ASDF Developers
* URL : https://github.com/asdf-format/asdf-standard
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Standards document describing ASDF

This document describes the Advanced Scientific Data Format (ASDF).
ASDF is a proposed next generation interchange format for scientific
data. ASDF aims to exist in the same middle ground that made FITS so
successful, by being a hybrid text and binary format: containing
humanditable metadata for interchange, and raw binary data that is fast
to load and use. Unlike FITS, the metadata is highly structured and is
designed up-front for extensibility.

It is a build dependency of the asdf-astropy package. I will
maintain it within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/asdf-standard

Best regards

Ole

Bug#1006840: suckless-tools: Please remove "provides: swarp"

[Ole Streicher]

Package: suckless-tools
Version: 46-1
Severity: serious
Control: tags -1 patch
Control: affects -1 theli swarp cpl-plugin-visir


Dear maintainer,

suckless-tools has the following packages listed as "Provides":

dmenu, lsw, slock, sprop, sselp, ssid, swarp, tabbed, wmname, xssstate

"swarp" however is (since 2013) a complete different package, with 
different uses: it provides a tool to process astronomical images. As 
the file name of the executable conflicts between the two packages, the 
executable in the swarp package is not called /usr/bin/SWarp (the 
original spelling of the astronomical tool).


However, the binary package is called "swarp", and the "Provides" of 
suckless-tools conflicts with this. This runs into a problem when one 
has "swarp" as a dependency, which is the case for theli and 
cpl-plugin-visir. If suckless-tools was installed before theli or 
cpl-plugin-visir are installed, the required "swarp" package is not 
going to be installed, resulting in unusable packages. This is the 
reason I made this bug RC.


Could you please remove the "swarp" provides from suckless-tools? In 
Debian, the "swarp" Provides of suckless-tools is not used at all (and 
would also make problems because of this).


For convenience, a patch is applied.

Best regards

OleFrom 3344c9297ebd4009efab61b28a1db60eb0f86997 Mon Sep 17 00:00:00 2001
From: Ole Streicher 
Date: Sun, 6 Mar 2022 16:30:42 +0100
Subject: [PATCH] Don't provide "swarp"

This is in conflict with the "swarp" package.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 81ded25..56f24ce 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,7 @@ Depends:
  ${shlibs:Depends},
  libcap2-bin [linux-any],
 Suggests: dwm, stterm, surf
-Provides: dmenu, lsw, slock, sprop, sselp, ssid, swarp, tabbed, wmname, xssstate
+Provides: dmenu, lsw, slock, sprop, sselp, ssid, tabbed, wmname, xssstate
 Description: simple commands for minimalistic window managers
  This package provides simple commands designed to be used with a minimalistic
  window manager like dwm but they can be useful in scripts regardless of the
-- 
2.34.1

Bug#1003040: ITP: asdf-astropy -- ASDF serialization support for astropy

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: asdf-astropy
  Version : 0.1.2
  Upstream Author : The ASDF Developers
* URL : https://github.com/astropy/asdf-astropy
* License : BSD-3-Clause
  Programming Lang: Python
  Description : ASDF serialization support for astropy

This package includes plugins that provide ASDF serialization support
for astropy objects. The plugins are automatically enabled when the
package is installed. ASDF (Advanced Scientific Data Format) is a
proposed next generation interchange format for scientific data,
mainly used by the Space Telescope Science Institude (STScI).

It is a new build dependency of the gwcs package. I will
maintain it within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/asdf-astropy

Best regards

Ole

Bug#1003048: ITP: asdf-transmorm-schemas -- ASDF schemas for validating transform tags

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: asdf-transform-schemas
  Version : 0.2.0
  Upstream Author : The ASDF Developers
* URL : https://github.com/asdf-format/asdf-transform-schemas
* License : BSD-3-Clause
  Programming Lang: Python
  Description : ASDF schemas for validating transform tags

This package provides ASDF schemas for validating transform tags. Users
should not need to install this directly; instead, install an
implementation package such as asdf-astropy, which will include
asdf-transform-schemas as a dependency. ASDF (Advanced Scientific Data
Format) is a proposed next generation interchange format for scientific
data,mainly used by the Space Telescope Science Institude (STScI).

It is a build dependency of the asdf-astropy package. I will
maintain it within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/asdf-transform-schemas

Best regards

Ole

Bug#1003049: ITP: asdf-coordinates-schemas -- ASDF schemas for validating coordinates tags

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org

* Package name: asdf-coordinates-schemas
  Version : 0.1.0
  Upstream Author : The ASDF Developers
* URL : https://github.com/asdf-format/asdf-coordinates-schemas
* License : BSD-3-Clause
  Programming Lang: Python
  Description : ASDF schemas for validating coordinates tags

This package provides ASDF schemas for validating coordinates tags.
Users should not need to install this directly; instead, install an
implementation package such as asdf-astropy, which will include
asdf-coordinates-schemas as a dependency. ASDF (Advanced Scientific Data
Format) is a proposed next generation interchange format for scientific
data,mainly used by the Space Telescope Science Institude (STScI).

It is a build dependency of the asdf-astropy package. I will
maintain it within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/asdf-coordinates-schemas

Best regards

Ole

Bug#1003051: RM: montage-wrapper -- ROM: abandoned upstream; RC bugs

[Ole Streicher]

Package: ftp.debian.org
Severity: normal

Hi,

the montage-wrapper package was an attempt to wrap the binaries from the 
"montage" package into a Python package. Since the "montage" package now 
offers native python wrapping, the wrapper is not needed any longer and 
is abandoned upstream (github repository is archived). It now became 
incompatible to its dependencies (mainly astropy).


We should follow upstream and just remove it from the archive. There are 
no reverse dependencies (just some Recommends in the debian-astro task 
packages).


Best

Ole

Bug#973347: [python3-astroquery] Incompatible with Astropy 4.1

[Ole Streicher]

Package: python3-astroquery
Version: 0.4.1+dfsg-2
Severity: serious
Tags: patch

The released version of astroquery uses some internal structures of
astropy, which make it fail with the latest version:

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroquery/7800643/log.gz

There is a patch in the upstream Github which handles this:

https://github.com/astropy/astroquery/pull/1791

Please consider applying the patch and re-uploading.

Thanks!

Cheers

Ole

Bug#973348: [python3-astroplan] Incompatible with Astropy 4.1

[Ole Streicher]

Package: python3-astroplan
Version: 0.6-3
Severity: serious
Tags: patch

The released version of astroplan uses some internal structures of
astropy, which make it fail with the latest version:

https://ci.debian.net/data/autopkgtest/testing/amd64/a/astroplan/7800639/log.gz

There is a new version 0.7 available that should fix this.
Alternatively, there is a patch in the upstream Github:

https://github.com/astropy/astroplan/pull/481

Please consider uploading the new upstream version or applying the patch.

Thanks!

Cheers

Ole

Bug#974559: ITP: tkagif -- TK Animated GIF encoder

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-tcltk-de...@lists.alioth.debian.org

* Package name: tkagif
  Version : 1.0.3
  Upstream Author : Willian Joye
* URL : https://github.com/wjoye/tkagif
* License : GPL-v2
  Programming Lang: Tcl
  Description : TK Animated GIF encoder

This is a new requirement of saods9. It will be maintained
within the TclTk team. A salsa dir is created at 

https://salsa.debian.org/tcltk-team/tkagif

Best regards

Ole

Bug#974636: ITP: tkagif -- TK Animated GIF encoder

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-tcltk-de...@lists.alioth.debian.org

* Package name: ttkthemes
  Version : 1.0.3
  Upstream Author : RedFantom
* URL : https://github.com/TkinterEP/ttkthemes
* License : GPL-v3
  Programming Lang: Tcl, Python
  Description : A group of themes for the ttk extenstions for Tkinter

This is a new requirement of saods9. It will be maintained
within the TclTk team. A salsa dir is created at 

https://salsa.debian.org/tcltk-team/ttkthemes

Best regards

Ole

Bug#974638: ITP: awthemes -- Dark and light themes for Tk, loosely based on the adwaita themes

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-tcltk-de...@lists.alioth.debian.org

* Package name: awthemes
  Version : 9.5.1
  Upstream Author : Brad Lanam
* URL : https://sourceforge.net/projects/tcl-awthemes/
* License : zlib
  Programming Lang: Tcl
  Description : Dark and light themes for Tk

This is a new requirement of saods9. It will be maintained
within the TclTk team. A salsa dir is created at 

https://salsa.debian.org/tcltk-team/awthemes

Best regards

Ole

Bug#1024248: [python3.11] platform.python_version() returns wrong value

[Ole Streicher]

Package: python3.11
Version: 3.11.0-3
Severity: important
Control: affects -1 src:sunpy

The version number returned from platform.python_version() is not 
conform to its documentation and is not parseable with 
packaging.version.Version:


--8<
$ python3.11
Python 3.11.0+ (main, Nov  4 2022, 09:23:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

from platform import python_version
from packaging.version import Version
python_version()

'3.11.0+'

print(python_version.__doc__)

 Returns the Python version as string 'major.minor.patchlevel'

Note that unlike the Python sys.version, the returned value
will always include the patchlevel (it defaults to 0).



Version(python_version())

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/packaging/version.py", line 266, 
in __init__

raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '3.11.0+'
--8<

This is a bug of the Debian package itself, the trailing "+" is added in 
debian/patches/git-updates.diff.


Sunpy uses packaging.version.Version(python_version) to skip some tests, 
which creates an error and therefore prevents Sunpy from compilation.

Bug#1023795: Please undo the replace of pgplot with giza-pgplot

[Ole Streicher]

Hi,

I am the Debian maintainer of giza. I still think that the main problem 
here is that pgplot is not free software and therefore cannot be part of 
Debian; see Debian Policy section 2.2.1. The same applies to packages 
which depend on pgplot, like libpgplot-perl.


I would in the first place ask to report and discuss the compatibility 
problems with upstream .


The other way to go forward would be to apply to the copyright owner of 
pgplot (Caltech institute) to request a license change to an Open Source 
compliant license, and (once this is done) to ask the pgplot5 Debian 
maintainer to upload pgplot5 to the Debian "main" archive. Note however, 
that pgplot5 is not a well-maintained package (last upload by its 
maintainer is now 11 years ago), so volunterring to take over pgplot5 
maintainance would be probably the best way to push this forward.


Giza is here the wrong package for this issue; it should be re-assigned 
to libpgplot-perl; the discussion about pgplot (and its licensing) 
itself should happen in a bug for the pgplot5 package.


When pgplot5 is going to be repackaged for Debian "main", we should 
discuss how to resolve the package conflicts between the two packages; 
however this should happen after a license change for pgplot.


Best regards

Ole

Bug#1023795: Please undo the replace of pgplot with giza-pgplot

[Ole Streicher]

Hi James,

Citing from 2.2.1:
| The main archive area comprises the Debian distribution.
| Only the packages in this area are considered part of the
^^^
| distribution.
^^^
| [...]
| Every package in main must comply with the DFSG (Debian Free Software
| Guidelines).

Section 2.2.2 and 2.2.4 describe contrib and non-free as "supplemental 
packages intended to work with the Debian distribution".


I see this distinction as an major point (not just formally), and I 
myself concentrate on the support of free software, which is Debian 
devoted for. That's why I propagate to use giza here and propose to 
discuss any issues with the authors of giza first before using an old 
non-free package (that is also completely unmaintained today). And I 
would also propagate that those who want to see pgplot within Debian to 
put some efforts (maybe coordinated) and discuss this with Caltech as 
the copyright holder. I am wondering why one doesn't see any of these 
efforts happen up to now, which makes my own motivation to drive for a 
compromise quite low.


However, apart from propagating this, it is not my decision where to use 
giza as a replacement for pgplot. Responsible here are the maintainers 
of libpgplot-perl. So, if you want to have this changed, please open a 
bug for that package (or re-assign this one) and convince them.


Best

Ole

Bug#1013435: Please mark nasa_exoplanet xfail until a solution is found

[Ole Streicher]

Package: python3-astroquery
Version: 0.4.6+dfsg-3
Control: affects -1 src:astropy
Control: tags -1 +patch

Dear maintainer,

astroquery currently fails on 32-bit platforms in 
test_nasa_exoplanet_archive.py::test_api_tables[toi-query28]. This is 
reported upstream as


https://github.com/astropy/astroquery/issues/2435

it is still unclear whether the problem is going to be resolved in 
astroquery itself, or in astropy (see 
https://github.com/astropy/astropy/pull/13359). This will probably 
require some discussion.


For the meantime, it would be great if the affected test could be set to 
xfail so that both astroquery and astropy can migrate to testing.


The attached patch does this.

Best

OleFrom: Ole Streicher 
Date: Thu, 23 Jun 2022 17:19:17 +0200
Subject: Mark nasa_exoplanet_archive test xfail

This test fails on 32-bit architectures. It is an issue with astropy's
ASCII table reader. Until it is fixed, the test is marked as xfail.

https://github.com/astropy/astroquery/issues/2435
---
 .../nexsci/nasa_exoplanet_archive/tests/test_nasa_exoplanet_archive.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/astroquery/ipac/nexsci/nasa_exoplanet_archive/tests/test_nasa_exoplanet_archive.py b/astroquery/ipac/nexsci/nasa_exoplanet_archive/tests/test_nasa_exoplanet_archive.py
index d240a0d..93954b7 100644
--- a/astroquery/ipac/nexsci/nasa_exoplanet_archive/tests/test_nasa_exoplanet_archive.py
+++ b/astroquery/ipac/nexsci/nasa_exoplanet_archive/tests/test_nasa_exoplanet_archive.py
@@ -2,6 +2,7 @@
 import json
 import os
 import sys
+import struct
 from urllib.parse import urlencode
 
 import astropy.units as u
@@ -209,6 +210,8 @@ def test_backwards_compat(patch_get):
 
 
 @pytest.mark.parametrize("table,query", API_TABLES)
+@pytest.mark.xfail(struct.calcsize("P")==4,
+   reason="Known failures on 32-bit archs", strict=False)
 def test_api_tables(patch_get, table, query):
 NasaExoplanetArchiveMock = NasaExoplanetArchiveClass()
 

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: sncosmo -- Python library for high-level supervova 
cosmology analysis
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction
laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#757096: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction
laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#757096: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: sncosmo -- Python library for high-level supervova 
cosmology analysis
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#1017056: setuptools: cannot get metadata from pyproject.toml

[Ole Streicher]

Package: python3-setuptools
Version: 59.6.0-1.2
Severity: wishlist
Control: affects -1 src:asdf-standard

Dear maintainer,

I have a package (asdf-standard) that has no setup.py but a
pyproject.toml that contains (almost) all metadata. According to the
compilation hint, I added pybuild-plugin-pyproject to the build
dependencies. However it
still does not build properly. The build fails with the following
output:

8<
* Building wheel...
Successfully built UNKNOWN-1.0.3-py3-none-any.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.10
with "installer" module
E: pybuild pybuild:369: build: plugin pyproject failed with: UNKNOWN
wheel found: UNKNOWN-1.0.3-py3-none-any.whl. Does pyproject.toml specify
a build-backend?
dh_auto_build: error: pybuild --build -i python{version} -p 3.10
returned exit code 13
make: *** [debian/rules:5: binary] Error 25
8<

The build backend specified in pyproject.toml is

build-backend = "setuptools.build_meta"

In a discussion on the debian-python mailing list Scott Talberg gave the
hint:

> I *think* the issue might be that our setuptools is too old to
> understand how to get project metadata from pyproject.toml (PEP 621).
> This seems to indicate that it was added in setuptools 61.0.0:
> 
> https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

Therefore, I would ask if setuptools could be upgraded to at least
version 61?

Best regards

Ole

pyproject.toml
Description: application/toml

Bug#1016959: Packaging status?

[Ole Streicher]

Hi Gürkan,

I just found your ITP for nusolve; did you experience difficulties with 
packaging?


Is the package somewhere on Salsa?

Cheers

Ole

Bug#1010595: Please make xsimd available on all platforms

[Ole Streicher]

Source: xsimd
Version: 7.6.0-2
Control: affects -1 src:pythran src:skimage
Control: block 1009431 by -1
Control: block 1010430 by -1

Dear maintainer,

xsimd provides a unique API for SIMD instructions among different 
processor architectures. Additionally to many specific architectures, 
there is also a fallback scalar option for unsupported architectures (as 
far as I interpret the headers).


Currently, xsimd-dev fails to build on armel, armhf, mips64el, mipsel, 
ppc64el, s390x (armhf is built with 8.0.3-1 on experimental).


xsimd-dev is build dependency of pythran, which makes pythran 
uninstallable on the platforms where xsimd-dev fails.


In turn, python3-pythran is a new build dependency of skimage (0.19.2). 
The current version of skimage (0.18.3) is now starting to collect RC 
bugs because of incompatibilities with newer pil and tifffile versions 
(#1009431, #1010430).


skimage is also one of the basic scientific Python packages which is 
expected to be available on all platforms.


Therefore, could I ask to provide xsimd-dev for all platforms, using the 
scalar fallback for unsupported CPUs?


Best regards

Ole

Bug#1015324: ITP: synphot -- Simulate photometric data ans spectra in astronomy

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, 
debian-pyt...@lists.debian.org
Control: block 1012441 by -1

* Package name: synphot
  Version : 1.1.2
  Upstream Author : Space Telescope Science Institute
* URL : https://github.com/spacetelescope/synphot_refactor
* License : BSD-3-Clause
  Programming Lang: Python 3
  Description : Simulate photometric data ans spectra in astronomy

synphot simulates photometric data and spectra, observed or otherwise.
It can incorporate external filters, spectra, and data. One can also use
a pre-defined standard star (Vega), bandpass, or extinction law.
Furthermore, it allows one to:

 * Construct complicated composite spectra using different models.
 * Simulate observations.
 * Compute photometric properties such as count rate, effective
   wavelength, and effective stimulus.
 * Manipulate a spectrum; e.g., applying redshift or normalize it to a
   given flux value in a given bandpass.
 * Sample a spectrum at given wavelengths.
 * Plot a quick-view of a spectrum.
 * Perform repetitive operations such as simulating the observations of
   multiple type of sources through multiple bandpasses.

This is a dependency of the upcoming specreduce package (ITP #1012441).

I will maintain the package within the Debian Astro team in Salsa:

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

Best regards

Ole

Bug#1015838: ITP: specreduce-data -- Test and reference data for the specreduce package

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, 
debian-pyt...@lists.debian.org
Control: block 1012441 by -1

* Package name: specreduce-data
  Version : 0+git2021.11.18
  Upstream Author : Astropy Specreduce contributors
* URL : https://github.com/astropy/specreduce-data
* License : BSD-3-Clause
  Programming Lang: Python 3
  Description : Test and reference data for the specreduce package

This package contains general reference data for spectroscopic data
reduction (e.g. standard star spectra, atmospheric extinction curves,
line lists for calibration lamps) and test data for the specreduce
package.

This is a dependency of the upcoming specreduce package (ITP #1012441).

I will maintain the package within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/specreduce-data

Best regards

Ole

Bug#1016304: pyraf: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13

[Ole Streicher]

Control: tags -1 moreinfo unreproducible

Hi Lucas,

I can't reproduce this bug and the error message doesn't lead me to an 
obvious bug. Could you re-check whether this was an accidental glitch?


Thank you!

Best regards

Ole

On 29.07.22 20:23, Lucas Nussbaum wrote:

Source: pyraf
Version: 2.2.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220728 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

  debian/rules binary
dh binary --with python3 --buildsystem=pybuild
dh_update_autotools_config -O--buildsystem=pybuild
dh_autoreconf -O--buildsystem=pybuild
dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:239: python3.10 setup.py config
running config
dh_auto_build -O--buildsystem=pybuild
I: pybuild base:239: /usr/bin/python3 setup.py build
running build
running build_py
creating /<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/iraffunctions.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/__init__.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/gkicmd.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/newWindowHack.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/splash.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafhelp.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafpar.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/__main__.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafcompleter.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/msgiobuffer.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafnames.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafdisplay.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/fill_clcache.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/gwm.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafgwcs.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/clcache.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/tkplottext.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/urwfiledlg.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/cllinecache.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/gkitkplot.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/graphcap.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafukey.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/ipython_api.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/MplCanvasAdapter.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/fontdata.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/tpar.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/clparse.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/gkigcur.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/iraftask.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/wutil.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/cltoken.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/gki.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/msgiowidget.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/pseteparoption.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafecl.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/pycmdline.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/pyrafTk.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/iraf.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/gkiiraf.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/aqutil.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/clast.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafimcur.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafinst.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/textattrib.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/sqliteshelve.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/generic.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/cl2py.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/GkiMpl.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/filecache.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/cgeneric.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafimport.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/clscan.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
copying pyraf/irafexecute.py -> 
/<>/.pybuild/cpython3_3.10_pyraf/build/pyraf
c

Bug#941158: Taking over ownership of ITP

[Ole Streicher]

Control: owner -1 !

As discussed by personal mail, I will take over this.

Cheers

Ole

Bug#1012277: hipspy fails with astropy 5.1

[Ole Streicher]

Source: hipspy
Version: 0.2-3
Severity: serious
Tags: upstream ftbfs

Since the installation of astropy 5.1, hipspy fails its tests. The first
error is

ImportError while loading conftest '/usr/lib/python3/dist-
packages/hips/conftest.py'.
/usr/lib/python3/dist-packages/hips/conftest.py:6: in 
from astropy.tests.plugins.display import PYTEST_HEADER_MODULES,
TESTED_VERSIONS
E   ModuleNotFoundError: No module named 'astropy.tests.plugins'

however after fixing this, other appear. The same happens now when
hipspy is compiled on unstable.

Since it is unclear whether hipspy still gets upstream support in the
future (and therefore it is worth fixing), this bug is to autoremove
hipspy from testing and let astropy migrate.

Discussion about hipspys future:

https://github.com/hipspy/hips/issues/153

Bug#1012437: Please make pythran available on all platforms

[Ole Streicher]

Source: pythran
Version: 0.10.0+ds2-8
Severity: normal
Control: affects -1 src:skimage

Dear maintainer,

python3-pythran is a build dependency of scikit-image (skimage) since
version 0.19. skimage is currently in testing for all platforms.
The current version of skimage (0.18.3) is now starting to collect RC 
bugs because of incompatibilities with newer pil and tifffile versions 
(#1009431, #1010430).


Currently, pythran is built only on those platforms where xsimd is
available, which in turn restricts the build of skimage to those
platforms. I asked the xsimd maintainers to have a serial fallback for
unsupported platforms (Bug #1010595); however this is no longer
possible with the new version.

Since pythran seems to be buildable also without xsimd, I would ask
you to use this as a fallback on platforms where xsimd is not
available. This would allow dependent packates (like skimage) be built
on all platforms.

skimage is one of the basic scientific Python packages which is
expected to be available on all platforms.

Best regards

Ole

Bug#1012441: ITP: specreduce -- Astropy coordinated package to reduce and calibrate spectroscopic astronomical data

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, 
debian-pyt...@lists.debian.org

* Package name: specreduce
  Version : 1.0.0
  Upstream Author : Astropy Specreduce contributors 

* URL : http://astropy.org/
* License : BSD-3-Clause
  Programming Lang: Python 3
  Description : Astropy package to reduce and calibrate astronomical spectra

The specreduce package aims to provide a data reduction toolkit for
optical and infrared spectroscopy, on which applications such as
pipeline processes for specific instruments can be built. The scope of
its functionality is limited to basic spectroscopic reduction, with
basic image processing steps (such as bias subtraction) instead
covered by ccdproc and other packages, data analysis by specutils and
visualization by specviz or cubeviz. A few examples will nevertheless
be provided of its usage in conjunction with these complementary
packages.

I will maintain the package within the Debian Astro team in Salsa:

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

Best regards

Ole

Bug#1012719: Reassigning to astroplan

[Ole Streicher]

Control: notfound -1 astropy/5.1-1
Control: reassign -1 src:astroplan

The backward-compatible plugin ``astropy.tests.plugins.display`` has 
been removed in Astropy 5.1; use ``pytest-astropy-header`` instead.


This has been fixed in the new release astropy 0.8, which I would ask 
you to upload. A quick fix for 0.7 is attached here, however.


Cheers

Ole

From: Ole Streicher 
Date: Mon, 13 Jun 2022 10:09:26 +0200
Subject: Import pytest header modules from astropy-pytest-headers

---
 astroplan/conftest.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/astroplan/conftest.py b/astroplan/conftest.py
index 2b1c9d2..2e10d45 100644
--- a/astroplan/conftest.py
+++ b/astroplan/conftest.py
@@ -9,7 +9,7 @@ and then after that do things specific to astroplan.  But we also want astropy
 functionality for any functions we have *not* overriden, so that's why the
 ``import *`` happens at the top.
 """
-from astropy.tests.plugins.display import (TESTED_VERSIONS,
+from pytest_astropy_header.display import (TESTED_VERSIONS,
PYTEST_HEADER_MODULES)
 
 from astropy.tests.helper import enable_deprecations_as_exceptions

Bug#1013076: New astropy breaks pydl autopkgtest

[Ole Streicher]

Package: python3-pydl
Version: 1.0.0~rc2-1
Severity: serious
Control: affects -1 src:astropy

Dear maintainer,

with the upload of astropy 5.1, the autopkgtest of ... starts to fail.
Currently this regression is blocking the migration of astropy to
testing.

The failure is

 ERROR collecting pydlutils/tests/test_sdss.py _
ImportError while importing test module 
'/usr/lib/python3/dist-packages/pydl/pydlutils/tests/test_sdss.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/pydl/pydlutils/tests/test_sdss.py:5: in 
from astropy.tests.helper import remote_data, raises
E   ImportError: cannot import name 'remote_data' from 'astropy.tests.helper' 
(/usr/lib/python3/dist-packages/astropy/tests/helper.py)


This can be fixed by importing pytest.mark.remote_data; however then other 
failures appear due to deprecation of other places. It seems that this all is 
fixed in upstreams master branch.


Best

Ole

Bug#1013078: New astropy breaks pyregion autopkgtest

[Ole Streicher]

Package: python3-pydl
Version: 2.1.1-1
Severity: serious
Control: affects -1 src:astropy

Dear maintainer,

with the upload of astropy 5.1, the autopkgtest of pyregion starts to
fail. Currently this regression is blocking the migration of astropy to
testing.

The failure is

ImportError while loading conftest 
'/usr/lib/python3/dist-packages/pyregion/conftest.py'.
/usr/lib/python3/dist-packages/pyregion/conftest.py:15: in 
from astropy.tests.plugins.display import PYTEST_HEADER_MODULES, 
TESTED_VERSIONS
E   ModuleNotFoundError: No module named 'astropy.tests.plugins'


This can be fixed with the attached patch.


Best

OleFrom: Ole Streicher 
Date: Thu, 16 Jun 2022 15:33:56 +0200
Subject: Import PYTEST_HEADER_MODULES and TESTED_VERSIONS from
 astropy_pytest_header

The import from astropy was removed in astropy 5.1.
---
 pyregion/conftest.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pyregion/conftest.py b/pyregion/conftest.py
index 1b2e2b2..68357e4 100644
--- a/pyregion/conftest.py
+++ b/pyregion/conftest.py
@@ -12,7 +12,8 @@ else:
 # automatically made available when Astropy is installed. This means it's
 # not necessary to import them here, but we still need to import global
 # variables that are used for configuration.
-from astropy.tests.plugins.display import PYTEST_HEADER_MODULES, TESTED_VERSIONS
+from pytest_astropy_header.display import (PYTEST_HEADER_MODULES,
+   TESTED_VERSIONS)
 
 from astropy.tests.helper import enable_deprecations_as_exceptions
 

Bug#976912: coyote: FTBFS on ppc64el (arch:all-only src pkg): Magick: abort due to signal 6 (SIGABRT) "Abort"...

[Ole Streicher]

Control: reassign -1 gnudatalanguage 1.0.0~rc.3-1
Control: severity -1 important
Control: affects -1 src:coyote
Control: forwarded -1 https://github.com/gnudatalanguage/gdl/issues/559

This is a known, unresolved problem with gnudatalanguage itself.

Best

Ole

Bug#963564: gfortran: Internal error when processing pFUnit generated files with --coverage

[Ole Streicher]

Package: gfortran-10
Version: 10.1.0-3
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847

Dear maintainers,

copying https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847 for your
convenience:

With gcc 9 and 10, compiling the attached file with coverage info raises
an internal error:

$ gfortran-10 -c --coverage funit-bug.f90
during IPA pass: profile
funit-bug.f90:8:0:

8 |use foo
  |
internal compiler error: in coverage_begin_function, at coverage.c:656
0x7f6c0275ae0a __libc_start_main
../csu/libc-start.c:308
[…]
$ gfortran-10 --version
GNU Fortran (Debian 10.1.0-3) 10.1.0
[…]
$ gfortran-9 --version
GNU Fortran (Debian 9.3.0-14) 9.3.0

This does not happen with gfortran-8, so it is a regression:

$ gfortran-8 -c --coverage funit-bug.f90
$ gfortran-8 --version
GNU Fortran (Debian 8.4.0-4) 8.4.0

System is Debian 11 testing.
The attached file is derived from a pFUnit generated file where this was
originally observed .
module foo
contains
subroutine sbr()
end subroutine sbr
end module foo

function foo_suite() result(suite)
   use foo
   integer :: bar
   integer :: res
   res = bar(sbr)
end function foo_suite

Bug#963954: ndcube: test failure with new sunpy

[Ole Streicher]

Source: ndcube
Version: 1.3.2-1
Severity: serious
Tags: patch

Hi Vincent,

I just uploaded the new sunpy version, and this unfortunately breaks the
ndcube testing due to a missing dependency:

Sunpy no longer strongly depends on parfive, only recommends it. The
tests however require them (even when they actually can't download
data), so it must be explicitly added as build+test dependency.

I created a patch which is attached, and I also for convenience created
a merge request for it
<https://salsa.debian.org/debian-astro-team/ndcube/-/merge_requests/2>

Additionally, the patch fixes the CI command line: use the AUTOPKGTEST
instead of ADTMP environment variable, and directly invoke pytest
instead of using a sommand line Python script.

Severity is set to "serious", since ndcube now FTBFS.

Best

Ole
>From e80151a13ed14e48110c0b9ed1510a0df8429545 Mon Sep 17 00:00:00 2001
From: Ole Streicher 
Date: Mon, 29 Jun 2020 09:34:50 +0200
Subject: [PATCH] Add parfive to the test dependencies

Sunpy no longer strongly depends on parfive, only recommends it. The
tests however require them (even when they actually can't download
data), so it must be explicitly added as build+test dependency.

Additionally, the patch fixes the CI command line: use the AUTOPKGTEST
instead of ADTMP environment variable, and directly invoke pytest
instead of using a sommand line Python script.
---
 debian/control   | 1 +
 debian/tests/control | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 8687225..07531eb 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends: debhelper (>= 12),
python3-all,
python3-astropy,
python3-astropy-helpers,
+   python3-parfive,
python3-pytest,
python3-setuptools,
python3-setuptools-scm,
diff --git a/debian/tests/control b/debian/tests/control
index 6a2e1da..dbecc28 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,6 @@
-Test-Command: cd $ADTTMP && python3 -c "import ndcube; import pytest; exit(pytest.main(ndcube.__path__))"
+Test-Command: cd $AUTOPKGTEST_TMP && python3 -m pytest --pyargs ndcube
 Depends: python3-ndcube,
+ python3-parfive,
+ python3-pytest,
  python3-tk
 Restrictions: allow-stderr
-- 
2.27.0

Bug#997359: Inkscape crashes when running as batch without X11

[Ole Streicher]

Control: reassign -1 inkscape 1.1.1-2
Control: affects -1 src:debian-astro
Control: retitle -1 Inkscape crashes when running as batch without X11

Inkscape is used during the debian-astro package to create a png icon
from the original svg image. This now crashes:


--8<-
$ DISPLAY= inkscape --batch-process Debian-Astro-logo.svg --export-width=25 
--export-filename=Debian-Astro-logo-25x39.png
Unable to init server: Could not connect: Connection refused

(inkscape:187075): Gtk-CRITICAL **: 17:05:58.380: 
gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at 
https://inkscape.org/report
with a detailed description of the steps leading to the crash, so we can fix it.

(inkscape:187075): Gtk-CRITICAL **: 17:05:58.381: 
_gtk_style_provider_private_get_settings: assertion 
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(inkscape:187075): Gtk-CRITICAL **: 17:05:58.381: 
_gtk_style_provider_private_get_settings: assertion 
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(inkscape:187075): Gtk-CRITICAL **: 17:05:58.381: 
_gtk_style_provider_private_get_settings: assertion 
'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
Speicherzugriffsfehler (Speicherabzug geschrieben)
--8<-

This is the backtrace:

(gdb) bt
#0  0x74ac4eef in Gtk::IconTheme::prepend_search_path(Glib::ustring 
const&) ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgtkmm-3.0.so.1
#1  0x777ec85e in Inkscape::Application::Application(bool) ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so
#2  0x777ed1c0 in Inkscape::Application::create(bool) ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so
#3  0x7788a03a in InkscapeApplication::on_startup2() ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so
#4  0x77896389 in InkscapeApplication::on_open(std::vector, 
std::allocator > > const&, Glib::ustring const&) ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/libinkscape_base.so
#5  0x763393ad in  () at /usr/lib/x86_64-linux-gnu/libgiomm-2.4.so.1
#6  0x7546b6cf in g_closure_invoke ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
#7  0x7547dc92 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
#8  0x75483d5f in g_signal_emit_valist ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
#9  0x754842cf in g_signal_emit ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgobject-2.0.so.0
#10 0x755934c8 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
#11 0x7559376e in g_application_run ()
at /usr/bin/../lib/x86_64-linux-gnu/inkscape/../libgio-2.0.so.0
#12 0x75defe4a in __libc_start_main (main=
0x65e0 , argc=5, argv=0x7fffe0b8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe0a8) at 
../csu/libc-start.c:314
#13 0x6eba in _start ()


This happend before in #959885, but was not really reproducible.

Best regards

Ole

Bug#997359: Inkscape crashes when running as batch without X11

[Ole Streicher]

On 24.10.21 18:29, Mattia Rizzolo wrote:

Since you managed to reproduce it and all, could you perhaps consider
forwarding it yourself on https://gitlab.com/inkscape/inbox ?


I would prefer if you could do it. I am not very familar with inkscape, 
and the icon creation here is almost the only case where I use it.



This happend before in #959885, but was not really reproducible.


And it still is not for me:

(sid_amd64-dchroot)mattia@barriere ~ % inkscape --export-filename=foo.png 
/usr/share/inkscape/templates/about_screen.svg --export-type=png ; echo return 
code: $?

[...]

You did not use the "--batch-process" option. If you add this, you get 
the crash. From the man page, this option is mandatory for batch processing.


Cheers

Ole

Bug#997469: dh-python doesn't allow local connections via urllib

[Ole Streicher]

Control: reassign -1 dh-python 5.20211022.1
Control: retitle -1 dh-python doesn't allow local connections via urllib
Control: affects -1 src:gwcs

By Debian Policy (4.9), it is allowed to establish an loopback internet 
connection to a self-started service during build. This is used in some 
of my Python packages, namely gwcs (via the python3-asdf package) for 
roundtrip tests.


"Earlier" this worked well. However, in the last "sid" rebuild it turned 
out that the communication between dh-python and python's urllib doesn't 
make the "localhost" exception anymore. From the build log:


---8<
self = 
data = b'GET http://127.0.0.1:55011/test.asdf 
HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: 
127.0.0.1:55011\r\nUser-Agent: Python-urllib/3.9\r\nConnection: 
close\r\n\r\n'


def send(self, data):
"""..."""

if self.sock is None:
if self.auto_open:
>   self.connect()

/usr/lib/python3.9/http/client.py:974:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


self = 

def connect(self):
"""Connect to the host and port specified in __init__."""
>   self.sock = self._create_connection(
(self.host,self.port), self.timeout, self.source_address)

/usr/lib/python3.9/http/client.py:945:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _


address = ('127.0.0.1', 9), timeout = 
source_address = None
---8<

This shows that a connection to a loopback interface (here: 
127.0.0.1:55011) is now handled by the proxy, which is not how it should 
be. Connections to 127.0.0.1 should be passed directly.


Best regards

Ole

Bug#998234: ITP: mpl-animators: An interative animation framework for matplotlib

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-pyt...@lists.debian.org, debian-as...@lists.debian.org


* Package name: mpl-animators
  Version : 1.0.0
  Upstream Author : Sunpy Developers
* URL : https://github.com/sunpy/mpl-animators
* License : BSD-3-Clause
  Programming Lang: Python
  Description : An interative animation framework for matplotlib

The mpl_animators package provides a set of classes which allow the easy
construction of interactive matplotlib widget based animations. “Out of
the box” classes are provided for making line or image plots from numpy
arrays, with sliders to control the animation automatically added for
all dimensions not on the axes of the plot.

It is a new build dependency of the sunpy and ndcube packages. I will
maintain it within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/mpl-animators

Best regards

Ole

Bug#934959: python-mock breaks sunpy autopkgtest

[Ole Streicher]

Control: block -1 by 929438
Control: tags -1 pending

This will be fixed with sunpy version 1.0.2. However, the upload is
delayed due to a dependency which is currently still in the NEW queue.

Bug#935563: astropy 3.2.1 breaks sunpy

[Ole Streicher]

Control: reassign -1 python3-sunpy 0.9.6-2

That is rather an inaccuracy in sunpy, which is fixed with the latest
version.

Cheers

Ole

Bug#939473: Sextractor: improve tests (was: Bug#939048: transition: glibc)

[Ole Streicher]

Package: sextractor
Version: 2.19.5+dfsg-6


Hi Paul, Aurelien,

I maintain both packages (sextractor and iraf-fitsutil).

1st, quick answer for sextractor: You don't need to care; this is my
fault/problem: The test is home-made and directly compares string-wise
the result with a reference catalog, which fails due to minimal changes
in the numbers -- from a quick view, that should be neglilible. That
also happened in the past, and I solved it by updating the reference
(which is ofcourse not the smartest solution). If you have a good
general way to handle this, I am happy to apply this; otherwise I will
just read+compare the numbers with python3-numpy in future.

For iraf-fitsutil, I still have no glue what happens there. That is also
a bit painful to debug, since the package is mainly written in a domain
specific language (IRAF SPP; Aurelien may know it from work). So I am
afraid it may take a bit of time to analyze.

Best regards

Ole

On 04.09.19 22:47, Paul Gevers wrote:
> Hi maintainers of sextractor and iraf-fitsutil,
> 
> In bug 939048 we are discussing a transition slot for glibc 2.29. As
> part of the preparation we are checking autopkgtest results in unstable,
> when glibc 2.29 from experimental is installed. This e-mail is a heads
> up of failures in your packages. Can you please check that these are
> genuine? If so, please either let us know in this bug, or by filing a
> bug against your own package that blocks this bug.
> 
> On 04-09-2019 22:06, Aurelien Jarno wrote:
> 
> [...]
> 
>> Thanks for the info.
>>
>>> I'll check why there are so many "Test in progress" items. Most of them
>>> should be neutral I see.
>>  
>> Ok. I have checked the one marked as regression, and there are only two
>> if them that are real regressions in addition to postgresql-hll:
>> - iraf-fitsutil: this is a strange issue, I am able to reproduce it, but
>>   I haven't investigated more yet.
> 
> Log:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/i/iraf-fitsutil/2885704/log.gz
> 
>> - sextractor: I am able to reproduce the issue, it seems to be related
>>   to a math precision change, but I haven't investigated more yet.
> 
> Log:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/s/sextractor/2841528/log.gz
> 
> @aurelien, so, let's have the maintainers on board.
> 
> Paul
> 

Bug#939554: RM: dpuser [mips64el mipsel] -- RoM; FTBFS

[Ole Streicher]

Package: ftp.debian.org
Severity: normal

Drea ftp-masters,

please remove the mips64el and mipsel binaries of dpuser from unstable.
The sourse now build-depends on libqt5datavisualization5-dev, which is
not available for these architectures.

The package does not have any reverse dependencies.

Best regards

Ole

Bug#951768: Gallery generation broken with sphinx-gallery 0.2.0

[Ole Streicher]

Control: reassign -1 python3-sphinx-gallery 0.2.0-3

As suggested in
https://github.com/scikit-image/scikit-image/issues/4492#issuecomment-595581470
the failing package here is sphinx-gallery. An update to version 0.3.0
or later seems to solve the problem.

Cheers

Ole

Bug#946409: Please update pydantic to a newer version

[Ole Streicher]

Source: pydantic
Version: 0.30.1-1
Severity: wishlist

Dear Maintainer,

Pydantic is currently version 0.3, while 1.2 is already available. Also,
the package does not migrate because it is still the first (source-only)
upload.

python3-pydantic is now a new build dependency of the "gammapy" package,
that I would like to upload soon. Would it be possible to update to the
current version?

As the package is on LowNMU, I would volunteer to upload the latest
version as an NMU myself (also including the patch #940156).

Best regards

Ole

Bug#946411: Please put pydantic to salsa

[Ole Streicher]

Source: pydantic
Version: 0.30.1-1
Severity: wishlist

Dear Maintainer,

Specifically for LowNMU it may be useful to have a git repository to
keep the changes of pdantic. Therefore, I would ask you whether you
would agree to create a git repository on Salsa (in the Python group)
and to put it there. I would volunteer to do this if you agree.

Best regards

Ole

Bug#946514: RM: cpl-plugin-sinfo -- ROM; not DFSG free

[Ole Streicher]

Package: ftp-master

Dear ftp-masters,

please remove the source package cpl-plugin-sinfo and all its binary
packages from unstable. Among other problems, the package is not DFSG
free and there is no hope that this will happen ever.

Thank you

Ole

Bug#946513: RM: cpl-plugin-kmos -- ROM; no longer DFSG free

[Ole Streicher]

Package: ftp-master

Dear ftp-masters,

please remove the source package cpl-plugin-kmos and all its binary
packages from unstable. The newer versions depend on non-free software,
and the old version is not longer maintained upstream.

Thank you

Ole

Bug#946513: RM: cpl-plugin-kmos -- ROM; no longer DFSG free

[Ole Streicher]

Hi Andreas,

On 10.12.19 16:01, Andreas Beckmann wrote:
> On Tue, 10 Dec 2019 09:43:31 +0100 Ole Streicher  wrote:
>> please remove the source package cpl-plugin-kmos and all its binary
>> packages from unstable. The newer versions depend on non-free software,
>> and the old version is not longer maintained upstream.
> 
> what should happen to the package in buster? Is it still usable without
> cpl-plugin-kmos-calib which is no longer installable?

Some aspects (some processing steps) are still usable, but sure, its use
is limited. I have no strong opinion about the removal of the package
from Buster; the current popcorn suggests that it is mainly unused (the
number of installs comes transitively from the installation of the
astro-datareduction Pure Blends task).

Best

Ole

Bug#945389: skimage: FTBFS with python3.8 (test failures)

[Ole Streicher]

Control: tags -1 pending

Hi Andreas, Stefan,

the error message "no attribute '__reduce_cython__'" was actually
misleading. The problem here was that the required test files were not
installed in the .build directories. This had two causes:

1) the PYBUILD_VERSIONS variable is not set automatically, but is rather
an input to control the versions to be built

2) The files need to be copied and not just linked. Linking somehow
confuses pytest.

I am going to fix this (and the other problems) and plan to upload the
new version to unstable ASAP (today or tomorrow).

Let's hope that it doesn't break other's CI tests!

Cheers

Ole

Bug#917353: [python3-skimage] Cannot import skimage with new numpy

[Ole Streicher]

Package: python3-skimage
Version: 0.14.1-2
Severity: serious
Affects: python3-ccdproc, python3-hipspy, python3-sunpy
Tags: patch
Control: forwarded -1 https://github.com/scikit-image/scikit-image/issues/3551

$ python3
Python 3.7.2rc1 (default, Dec 12 2018, 06:25:49) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import skimage
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/skimage/__init__.py", line 167, in 

from .util.dtype import (img_as_float32,
  File "/usr/lib/python3/dist-packages/skimage/util/__init__.py", line 8, in 

from .arraycrop import crop
  File "/usr/lib/python3/dist-packages/skimage/util/arraycrop.py", line 8, in 

from numpy.lib.arraypad import _validate_lengths
ImportError: cannot import name '_validate_lengths' from 'numpy.lib.arraypad' 
(/usr/lib/python3/dist-packages/numpy/lib/arraypad.py)

This happens in the CI tests on a number of packages after the update of numpy 
(see "Affects").

Since `_validate_lengths` is an internal identifies by Python convention, the 
bug is clearly in skimage.

It is resolved in 

https://github.com/scikit-image/scikit-image/pull/3556

For convenience, a patch is attached.

Cheers

Ole
From: Egor Panfilov 
Date: Thu, 22 Nov 2018 22:16:02 +0200
Subject: Handle deprecation of numpy `_validate_lengths`

https://github.com/scikit-image/scikit-image/pull/3561
https://github.com/scikit-image/scikit-image/pull/3556
https://github.com/scikit-image/scikit-image/issues/3551
---
 skimage/util/arraycrop.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/skimage/util/arraycrop.py b/skimage/util/arraycrop.py
index e83a6c6..3787770 100644
--- a/skimage/util/arraycrop.py
+++ b/skimage/util/arraycrop.py
@@ -5,8 +5,15 @@ n-dimensional array.
 from __future__ import division, absolute_import, print_function
 
 import numpy as np
-from numpy.lib.arraypad import _validate_lengths
 
+# After numpy 1.15, a new backward compatible function have been implemented.
+# See https://github.com/numpy/numpy/pull/11966
+from distutils.version import LooseVersion as Version
+old_numpy = Version(np.__version__) < Version('1.16')
+if old_numpy:
+from numpy.lib.arraypad import _validate_lengths
+else:
+from numpy.lib.arraypad import _as_pairs
 
 __all__ = ['crop']
 
@@ -169,7 +176,10 @@ def crop(ar, crop_width, copy=False, order='K'):
 view of the input array.
 """
 ar = np.array(ar, copy=False)
-crops = _validate_lengths(ar, crop_width)
+if old_numpy:
+crops = _validate_lengths(ar, crop_width)
+else:
+crops = _as_pairs(crop_width, ar.ndim, as_index=True)
 slices = tuple(slice(a, ar.shape[i] - b)
for i, (a, b) in enumerate(crops))
 if copy:

Bug#917466: python-numpy breaks astropy autopkgtest

[Ole Streicher]

Control: notfound -1 python-numpy
Control: tags -1 pending

On 28.12.18 19:50, Sandro Tosi wrote:
> this is something astropy will have to update to. i see there is a
> 3.1 release, maybe packaging that will address this issue, else the 
> astropy maintainers would like to engage with upstream.

This is a compatibility problem with the new numpy version, which is not
fixed in astropy 3.1. However, there is a backport of the relevant
patch, which is going to be included in the upcoming astropy release.

https://salsa.debian.org/debian-astro-team/astropy/blob/master/debian/patches/Ensure-we-support-the-new-matmul-ufunc-in-numpy-1.16.patch

Cheers

Ole

Bug#917466: python-numpy breaks astropy autopkgtest

[Ole Streicher]

You will get the new astropy version in 2018; I just wait for a fix on a
build dependency (sphinx-astropy) to be installed on the buildds. That
is probably quicker than autoremove.

@sandro: Triggering of auto-removal is not part of the list of reasons
for severity "serious", as you already pointed out yourself some time ago:

https://release.debian.org/buster/rc_policy.txt

Delayed migration is *not* in the list, so raising severity for the goal
of package removal in testing (to let other packages migrate) is abusing
the severity system.

Best

Ole

Bug#917465: aplpy: autopkgtest needs update for new version of python-numpy

[Ole Streicher]

Control: reassign -1 python3-aplpy 1.1.1-4
Control: forwarded -1 https://github.com/aplpy/aplpy/issues/406

On 28.12.18 19:55, Sandro Tosi wrote:
>> warnings.warn('np.asscalar(a) is deprecated since NumPy v1.16, use '
>>> 'a.item() instead', DeprecationWarning, stacklevel=1)
>> E   DeprecationWarning: np.asscalar(a) is deprecated since NumPy
>> v1.16, use a.item() instead
> 
> it's a DeprecationWarning, why does aplpy tests suite treats it as an error?

That is an upstream setting.

Cheers

Ole