Bug#1068805: python3-pywt: distutils not available in Python 3.12

[Ole Streicher]

Package: python3-pywt
Version: 1.1.1-3
Severity: serious

Dear maintainer,

pywt directly depends on distutils, which is no longer available on 
Python 3.12. in pywt/__init__.py:


---8<--
from __future__ import division, print_function, absolute_import
from distutils.version import LooseVersion
---8<--

This makes the current version of pywt unusable on Python 3.12.

Best

Ole

Bug#1065104: ITP: xar -- Archiver for the macOS eXtensible ARchive format

[Ole Streicher]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist

 * Package name: xar
   Version : 498
   Upstream Author : Christopher Ryan, Apple
 * URL : https://github.com/apple-oss-distributions/xar
 * License : BSD-3-Clause
   Programming Lang: C
   Description : Archiver for the macOS eXtensible ARchive format

XAR (short for eXtensible ARchive format) is an open source file 
archiver and the archiver’s file format. It was created within the 
OpenDarwin project and is used in macOS for software installation routines.


This package can be used to unpack macOS .pkg files.

I intend to have the package team maintained, and will therefore create 
a git repository at https://salsa.debian.org/debian/xar.
Suggestions for a more specific team, or wishes to take over are welcome 
(the package is outside of my own topic, but I need it).


The package was already in Debian until ~2010, when it was removed 
because it was unmaintained. However it seems that it survived and is 
under maintenance again.


Best regards

Ole

Bug#1064275: autopkgtest failure with python-jsonschema 4.19.2

[Ole Streicher]

Hi Thomas,

it would be nice (and IMO common practice) to get a bug report on 
experimental *before* the upload to unstable, as this gives the chance 
to react before it becomes serious. I don't monitor pseudo-migration 
excuses.


Best

Ole

Bug#1063400: giza-dev: missing Conflicts: pgplot5t64

[Ole Streicher]

Hi Andreas,

shouldn't it pgplot5 which declares conflicts? giza-dev is part of 
Debian (main), while pgplot5 is in non-free which is formally not part 
of Debian.


Cheers

Ole

Bug#1063407: pybdsf fails to build with Python 3.12 as default

[Ole Streicher]

Control: forwarded -1 https://github.com/lofar-astron/PyBDSF/issues/214

While many (or even all) distutils were replaced by a migration to cmake 
(https://github.com/lofar-astron/PyBDSF/pull/204), the package is still 
not Python 3.12 compatible, and the solutions seems not trivial. Waiting 
for upstream here.

Bug#1063334: iraf: IRAF's desktop file has disappeared

[Ole Streicher]

Hi Peter,

oops, the desktop file and the icon were forgotten when the installation 
procedure was changed in 2.17.1. I will upload a new Debian package with 
these files included.


The "irafcl" script is mentioned in /usr/share/docs/iraf/README.Debian; 
I agree that this is not the first place to look (although it is the 
canonical path for Debian specific READMEs). For the next upstream 
version it is planned to also switch to irafcl (but still have 
compatibility links for cl/ecl); this should be described in the 
upstream release notes then. I am happy to get suggestions on how to 
improve this.


Thank you for the report!

Best

Ole

Bug#1062414: ITP: iraf-xdimsum -- Deep Infrared Mosaicing Software for IRAF

[Ole Streicher]

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

* Package name: iraf-xdimsum
  Version : 2003.01.24
  Upstream Author : NOAO
* URL : https://github.com/iraf-community/iraf-xdimsum
* License : IRAF
  Programming Lang: IRAF SPP
  Description : Deep Infrared Mosaicing Software for IRAF

 XDIMSUM is a package for creating accurate sky subtracted images from
 sets of dithered observations. While the observations need not be in
 the infrared, the dominance of the variable sky background in
 infrared data requires the dithering and recombination of many short
 carefully sky subtracted exposures to produce deep images.

I will maintain it within the Debian Astro team. A git repository was
created at

https://salsa.debian.org/debian-astro-team/iraf-xdimsum

Best regards

Ole

Bug#1061946: ITP: iraf-st4gem -- Selected tools from the Space Telescope Science Data Analysis System

[Ole Streicher]

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

* Package name: iraf-st4gem
  Version : 1.0
  Upstream Author : STScI, NOIRLAB
* URL : https://gitlab.com/nsf-noirlab/csdc/usngo/iraf/st4gem
* License : BSD-3-Clause
  Programming Lang: IRAF SPP
  Description : Selected tools from the Space Telescope Science Data 
Analysis System

The Space Telescope Science Data Analysis System (STSDAS) is software
for calibrating and analyzing data from the Hubble Space Telescope
(HST). STSDAS includes the same calibration routines as are used in the
routine data processing pipeline, as well as general-purpose tools and
enhancements to the Image Analysis and Reduction Facility (IRAF).

The original STSDAS package contained non-free code and was 32-bit only.
For the Gemini legacy data reduction pipeline, selected tasks of STSDAS
were ported to 64 bit and non-free code was replaced. These tasks are
also useful outside of the Gemini data reduction context.

I will maintain it within the Debian Astro team. A git repository was
created at

https://salsa.debian.org/debian-astro-team/iraf-st4gem

Best regards

Ole

Bug#1057543: astroquery: FTBFS: ModuleNotFoundError: No module named 'imp'

[Ole Streicher]

Control: tags -1 fixed-upstream

The problem here is that the python3-astropy-helpers package is not 
ready for Python 3.12, see #1058104.


https://bugs.debian.org/1058104

Astropy-helpers is EOL upstream, therefore I think we should no longer 
rely on that package.


For astroquery, there is a merged Pull Request for Python 3.12 compatibility

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

This includes switching astropy-helpers to a personally-maintained 
version. IMO the best way would be to include that directly in the 
astroquery package until astroquery gets rid of astropy-helpers completely.


Cheers

Ole

Bug#1058104: astropy-helpers: FTBFS: ModuleNotFoundError: No module named 'imp'

[Ole Streicher]

Control: tags -1 wontfix

astropy-helpers is an outdated helper package for building packages in 
the Astropy ecosystem. It is recently superceded by extension-helpers. 
The package should end its career now, and be removed before trixie.


I think that there are no longer Debian packages build-dependent from 
astropy-helpers. If there are, thes should be instead updated and/or 
ported to extension-helpers.

Bug#1058477: poliastro: please (temporarily) drop python3-numba dependencies

[Ole Streicher]

Control: tags -1 wontfix

I am afraid that python3-numba is really a hard dependency of poliastro: 
The line


from numba import njit as jit

can be found in many source files of poliastro, and the package is 
completely unusable without numba. Having all individual imports patched 
out is not maintainable on the long run. So, unless there is a general 
solution of having a "fake" numba (at least supporting njit and prange), 
I don't see a way to remove the hard dependency.

Bug#1057865: reproject ftbfs with Python 3.12

[Ole Streicher]

Control: forwarded -1 https://github.com/astropy/reproject/issues/414
Control: reassign -1 python3-astropy-healpix 1.0.0-1
Control: affects -1 src:reproject
Control: tags -1 +pending

This bug isn't in reproject, but in astropy-healpix and slided through 
the CI tests there. A solution was found upstream 
(https://github.com/astropy/astropy-healpix/pull/208) and will be 
uploaded ASAP.

Bug#1056043: yt ftbfs with Python 3.12 (and cython 3.0.5)

[Ole Streicher]

Hi Matthias,

There is a new version of yt, which should resolve this. However, it 
can't be uploaded due to the missing cython-3 in Debian. If you have 
packaged cython-3.0.5, maybe you can make it available?


Best

Ole

Bug#1055630: cfitsio: Please forward patches upstream

[Ole Streicher]

Source: cfitsio
Version: 4.3.0-2
Severity: wishlist

Dear maintainer,

HEASARC now maintains CFITSIO in Github:

https://github.com/HEASARC/cfitsio

In the adass2023 Slack, they encouraged to submit patches to the 
repository, finally moving to an open development philosophy.


As there are few patches in the Debian package which may be useful 
upstream: could they be reviewed and forwarded if applicable?


Thank you for consideration!

Best

Ole

Bug#1055270: ITP: starjava-auth -- Authentication for resources in accordance with VO standards

[Ole Streicher]

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


 * Package name: starjava-auth
   Version : 0.2
   Upstream Author : Mark Taylor
 * URL : https://github.com/Starlink/starjava/tree/master/auth
 * License : LGPL-3+
   Programming Lang: Java
   Description : VO standard conform resource authentication

This package manages authentication for HTTP(S) resources in accordance
with VO standards. This package relies on VO standards that are still
under discussion.

The package will be maintained by the Debian Astro team. It is a new
dependency of the "topcat" and "ttools" (STILTS) packages.

A git repository will be created at

https://salsa.debian.org/debian-astro-team/starjava-auth

Best regards

Ole

Bug#1055158: python-imageio's autopkg tests fails with pillow 10.1.0

[Ole Streicher]

The problem is that imageio <= 2.31.6 is known being incompatible to 
pillow >= 10.1; see https://github.com/imageio/imageio/pull/1046


Therefore, I am waiting for an upstream fix.

Bug#1054757: blends: FTBFS: make[1]: *** [debian/rules:20: override_dh_auto_test] Error 1

[Ole Streicher]

Hi Andreas,

yes: the tests for the Python package fail because they depend on which 
packages are in the astro-education task. Specifically, the "starplot" 
package was removed from Debian after Bookworm.


I now updated the debian-astro Blends package to reflect the package 
changes after Bookworm. It needs to migrate to testing (because the 
"testing" list is used in the tests, as the whole blends machinery is 
based on "testing"), and then I will upload a blends-dev package with 
the tests fixed.


astro-education evolves rather slowly, that's why I have chosen this one 
for the test.


Cheers

Ole

On 01.11.23 10:29, Andreas Tille wrote:

Hi,

any idea what might be wrong here?

Kind regards
 Andreas.

Am Fri, Oct 27, 2023 at 09:29:30PM +0200 schrieb Lucas Nussbaum:

Source: blends
Version: 0.7.5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231027 ftbfs-trixie

Hi,

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


Relevant part (hopefully):

make[1]: Entering directory '/<>'
pytest-3 --doctest-modules
= test session starts ==
platform linux -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0
rootdir: /<>
collected 8 items

blends.py F..F   [100%]

=== FAILURES ===
 [doctest] blends.Task.fix_dependencies 
469 celestia-gnome | celestia-glut
470 starplot
471 gravit
472 >>> for dep in task.suggests:
473 ... print(dep.rawstr)
474 sunclock
475 xtide
476 >>> task += apt.Cache()
477 >>> missing = task.fix_dependencies()
478 >>> for dep in task.recommends:
Expected:
 starplot
 gravit
Got:
 gravit

/<>/blends.py:478: DocTestFailure
_ [doctest] blends.Task.update _
434 Instead of using ``update()``, also the ``+=`` operator can be used:
435
436 >>> import apt
437 >>> with open('education') as fp:
438 ... task = Task('debian-astro', 'education', fp)
439 >>> dep = task.recommends[1][0]
440 >>> print(dep.name + ": ", dep.summary)
441 starplot:  None
442 >>> task += apt.Cache()
443 >>> print(dep.name + ": ", dep.summary)
Expected:
 starplot:  3-dimensional perspective star map viewer
Got:
 starplot:  None

/<>/blends.py:443: DocTestFailure
=== short test summary info 
FAILED blends.py::blends.Task.fix_dependencies
FAILED blends.py::blends.Task.update
= 2 failed, 6 passed in 0.95s ==
make[1]: *** [debian/rules:20: override_dh_auto_test] Error 1



The full build log is available from:
http://qa-logs.debian.net/2023/10/27/blends_0.7.5_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20231027;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20231027=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1054647: ITP: asdf-unit-schemas -- ASDF schemas for validating unit 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-unit-schemas
  Version : 0.1.0
  Upstream Author : The ASDF Developers
* URL : https://github.com/asdf-format/asdf-unit-schemas
* License : BSD-3-Clause
  Programming Lang: Python
  Description : ASDF schemas for validating unit tags

This package provides ASDF schemas for validating unit tags. Users
should not need to install this directly; instead, install an
implementation package such as asdf-astropy, which will include
asdf-unit-schemas as a recommendation. 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-unit-schemas

Best regards

Ole

Bug#1053563: glueviz: doesn't start anymore

[Ole Streicher]

Package: glueviz
Version: 1.0.1+dfsg-2
Severity: serious

Dear maintainer,

when starting glue on Debian testing, I get a Python error:

$ glue
/usr/bin/glue:6: DeprecationWarning: pkg_resources is deprecated as an API. See 
https://setuptools.pypa.io/en/latest/pkg_resources.html
  from pkg_resources import load_entry_point
QSocketNotifier: Can only be used with threads started with QThread
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to 
disable this validation.
Traceback (most recent call last):
  File "/usr/bin/glue", line 11, in 
sys.exit(load_entry_point('glue_core==1.0.1', 'gui_scripts', 'glue')())
 ^
  File "/usr/lib/python3/dist-packages/glue/main.py", line 259, in main
start_glue(**kwargs)
  File "/usr/lib/python3/dist-packages/glue/main.py", line 156, in start_glue
load_plugins(splash=splash, require_qt_plugins=True)
  File "/usr/lib/python3/dist-packages/glue/main.py", line 347, in load_plugins
splash.set_progress(100. * iplugin / float(n_plugins))
  File "/usr/lib/python3/dist-packages/glue/app/qt/splash_screen.py", line 31, 
in set_progress
self.progress.setValue(value)
TypeError: setValue(self, value: int): argument 1 has unexpected type 'float'

Probably, it needs an update to the latest version.

Best

Ole

Bug#1053552: gavodachs2-server: Error while setting up with postgresql 16

[Ole Streicher]

Package: gavodachs2-server
Version: 2.8+dfsg-3
Severity: serious

Hi Markus,

While running the migration test for astropy 5.3.4-1, the installation
of gavodachs2-server failed. Relevant lines from the log:

103s Setting up gavodachs2-server (2.8+dfsg-3) ...
103s Created symlink /etc/systemd/system/multi-user.target.wants/dachs.service 
→ /lib/systemd/system/dachs.service.
103s info: Selecting GID from range 1000 to 5 ...
103s info: Adding group `gavo' (GID 1001) ...
103s info: The home dir /nonexistent you specified can't be accessed: No such 
file or directory
103s
103s info: Selecting UID from range 100 to 999 ...
103s
103s info: Adding system user `gavo' (UID 103) ...
103s info: Adding new user `gavo' (UID 103) with group `gavo' ...
103s info: Not creating `/nonexistent'.
103s info: Adding user `dachsroot' ...
103s info: Selecting UID from range 1000 to 5 ...
103s
103s info: Adding new user `dachsroot' (1001) with group `gavo (1001)' ...
103s info: Creating home directory `/home/dachsroot' ...
103s info: Copying files from `/etc/skel' ...
103s info: Adding new user `dachsroot' to supplemental / extra groups `users' 
...
103s info: Adding user `dachsroot' to group `users' ...
108s *** Error: While executing DB query:
108s
108s   alter role untrusted set extra_float_digits=3
108s
108s The database engine reported:
108s
108s   ERROR:  permission denied to alter role
108s DETAIL:  Only roles with the CREATEROLE attribute and the ADMIN option
108s on role "untrusted" may alter this role.
108s
108s dpkg: error processing package gavodachs2-server (--configure):
108s  installed gavodachs2-server package post-installation script subprocess 
returned error exit status 1
108s dpkg: dependency problems prevent configuration of autopkgtest-satdep:
108s  autopkgtest-satdep depends on gavodachs2-server; however:
108s   Package gavodachs2-server is not configured yet.
108s
108s dpkg: error processing package autopkgtest-satdep (--configure):
108s  dependency problems - leaving unconfigured
108s Errors were encountered while processing:
108s  gavodachs2-server

Full log here: 
https://ci.debian.net/data/autopkgtest/testing/amd64/g/gavodachs/38631770/log.gz

I don't think that has anything to do with the astropy update. This
seems to be connected to Postgresql version (16.0-2); a similar install
(with Postgresql 15.4-3) succeeded.

Bug#1053214: RFP: lustre -- distributed parallel, scalabe, high-performance, high-availability file system

[Ole Streicher]

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

* Package name: lustre
  Upstream Author : Whamcloud
* URL : www.lustre.org
* License : GPLv2
  Programming Lang: C
  Description : Distributed parallel, scalable, high-performance file system

The Lustre file system is an open-source, parallel file system that
supports many requirements of leadership class HPC simulation
environments.

Lustre is used in a number of science institutes (including mine), so
having a Debian package would be quite handy for us.

Their distribution already come with some Debian files (and they
actually build Ubuntu packages), but they are not compliant to Debian
Policy, and they are very outdated (source format 1, declared standards
version 3.8.2), depending on tools that are not in Debian anymore
(dpatch). However, for the kernel modules, it is possible to build them
with dkms support.

The package includes both the client and the server side. However,
upstream builds the server package only for RHEL, already even just
having the client packages for Debian would be a big win.

Best regards

Ole

Bug#1052320: Please update numpy to >= 1.25

[Ole Streicher]

Source: numpy
Version: 1:1.24.2-1
Severity: wishlist
Control: affects -1 source:astropy

Dear Maintainer,

the upstream development of Astropy includes tests of Astropy for 
several non-standard architectures, including s390x and ppc64el. One 
major reason to support these architectures is to support Debian's 
multiplatform approach.


Astropy has Numpy as a dependency, and since Numpy upstream does not 
provide wheels for non-standard platforms, they are going to use Debian 
(resp. Ubuntu) packages here.


For the upcoming Astropy 6.0 release, the version requirements of Numpy 
have been raised to 1.25; so they can't use the current Numpy 
Debian/Ubuntu packages anymore.


Therefore, I would ask whether Numpy could be updated in the next time? 
I could then backport this to the Debian/Ubuntu version that is used in 
the testing and provide it to Astropy. The update is also required for 
uploading Astropy 6.0, once it is ready (~December 2023).


The upstream issue for this topic is

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

Thank you very much for considering this!

Best

Ole

Bug#1052044: Without git, pybuild does not include data files into wheel

[Ole Streicher]

Package: python3-build
Version:  0.10.0-1
Severity: important

Dear maintainer,

I am trying to build the package "asdf-wcs-schema"

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

which includes a lot of metadata, f.e.

resources/manifests/gwcs-1.0.0.yaml

With the normal build procedure, the build does not include the data 
files see f.e.


https://salsa.debian.org/debian-astro-team/asdf-wcs-schemas/-/jobs/4706731

I traced this down to the "python3 -m build" call, which is

python3.11 -m build --skip-dependency-check --no-isolation --wheel 
--outdir 
/builds/debian-astro-team/asdf-wcs-schemas/debian/output/source_dir/.pybuild/cpython3_3.11 



Running this command locally on a system with just the build deps 
installed does (with the environment variable 
SETUPTOOLS_SCM_PRETEND_VERSION=0.2.0) not include the data files. 
However, when I install the "git" package, the data files are included.


The packages uses pyproject.toml, and the data files are specified as

8<---
[tool.setuptools]
packages = ["asdf_wcs_schemas", "asdf_wcs_schemas.resources"]

[tool.setuptools.package-data]
"asdf_wcs_schemas.resources" = ["resources/**/*.yaml"]

[tool.setuptools.package-dir]
'' = "src"
"asdf_wcs_schemas.resources" = "resources"
8<---

which looks reasonable to me.

I am not sure if python3-build is the relevant package for the bug; 
however I could not find out more from the output. Please re-assign if 
required.

Bug#1040761: ITP: astropy-iers-data -- Earth Rotation and Leap Second tables for astropy

[Ole Streicher]

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

* Package name: astropy-iers-data
  Upstream Author : Astropy Developers
* URL : https://github.com/astropy/astropy-iers-data
* License : BSD-3-Clause
  Programming Lang: Python 3
  Description : Earth Rotation and Leap Second tables for the astropy core 
package

This package provides access to the tables provided by the International
Earth Rotation and Reference Systems (IERS) service, in particular the
Earth Orientation data allowing interpolation of published UT1-UTC and
polar motion values for given times. This package is not currently meant
to be used directly by users, and only meant to be used from the core
astropy package.

It was cut-off from the astropy core package and will be a new
dependency of astropy.

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

https://salsa.debian.org/debian-astro-team/astropy-iers-data

Best regards

Ole

Bug#1039480: [astroplan] Please update to 0.8 for astropy 5.3 compatibility

[Ole Streicher]

Hi Vincent,

if there are only a few tests, I would disable them and update the 
package. The main goal for the tests in Debian are that the package 
works well in that environment - i.e. with the installed astropy etc. 
This can be tested also with a new tests disabled.


I usually just report failing tests upstream and then disable them is 
they are just a bug in the test (or if the problem looks minor to me).


Cheers

Ole

On 30.06.23 17:06, Vincent Prat wrote:

Dear Ole,

There is this long-running issue in astroplan 0.8: 
https://github.com/astropy/astroplan/issues/416.

It is claimed to be solved, but I just tried and it still fails.

I can try to patch the version currently in Debian so that it is 
compatible with astropy 5.3, or disable the problematic tests 
(potentially a lot) in astroplan 0.8.

What do you think is best?

Regards

Vincent

Bug#1039480: [astroplan] Please update to 0.8 for astropy 5.3 compatibility

[Ole Streicher]

Source: astroplan
Version: 0.7-4
Severity: serious
Tags: affects -1 src:astropy

Dear maintainer,

two days ago I uploaded the updated astropy_5.3-1 to unstable. With this 
new version, astroplan's autopkgtests no longer pass.


The reason is that Astropys "TestRunner.run_tests()" no longer accepts 
an "open_files" argument. This is fixed in version astroplan version 
0.8, therefore I would ask you to update the package accordingly.


I have set the severity to "serious", because the it blocks the 
migration of Astropy to testing.


If you don't want to do the update yourself, I would volunteer to do it 
as a team upload.


Best

Ole

Bug#1039067: [python-imageio] Please update to newer version

[Ole Streicher]

Package: python3-imageio
Version: 2.4.1-5
Affects: src:skimage

Dear maintainer!

The current packaged version of imageio is 2.4.1, while upstream reached 
2.31.1 in the meantime. Specifically, the packaged version now lacks the 
new "v3" API, which is required to build the new skimage package 
(skimage requires at least 2.27 in the moment). skimage is one of the 
central packages for scientific image processing.


Please consider updating python3-imageio, to allow updating its reverse 
dependencies.


Best

olebole (maintainer of skimage)

Bug#1038969: ITP: ewah-bool-utils -- EWAH Bool Array compression for Python

[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, debian-scie...@lists.debian.org

* Package name: ewah-bool-utils
  Version : 1.0.2
  Upstream Author : Matthew Turk, Meagan Lang, Navaneeth Suresh
* URL : https://github.com/yt-project/ewah_bool_utils
* License : BSD-3-Clause
  Programming Lang: Python
  Description : EWAH Bool Array compression for Python

EWAH Bool Array compression is a repackaging and Python-exposed version
of "Enhanced Word-Aligned Hybrid" (EWAH) compression. It's a python
wrapper to a compressed bitarray method, for storing large bitsets.

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/ewah-bool-utils

Best regards

Ole

Bug#1037112: release-notes: Release notes paragraph from Debian Astro team

[Ole Streicher]

Package: release-notes
Severity: normal
X-Debbugs-Cc: debian-as...@lists.debian.org

Please add an Debian Astro section to the Bookworm release notes. The 
merge request is available in


https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/188

Thank you!

Best regards

Ole

Bug#1036466: RM: cpl-plugin-xshoo/3.5.3+dfsg-2 -- ROM; outdated; required upstream file no longer available

[Ole Streicher]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal

The package is outdated, and upstream doesn't provide the calibration 
files any longer, which leads to an RC bug. The actual version cannot be 
packaged due to unresolved licensing issues. Therefore, the package is 
unsuitable for bookworm; please remove it (it is marked for autoremoval; 
however there is no need to wait so long).


Situation is similar to #1036157; I still want to keep the package in 
unstable.


Cheers

Ole
 Forwarded Message 
Subject: cpl-plugin-xshoo is marked for autoremoval from testing
Date: Thu, 18 May 2023 04:39:03 +
From: Debian testing autoremoval watch 
To: cpl-plugin-xs...@packages.debian.org

cpl-plugin-xshoo 3.5.3+dfsg-1 is marked for autoremoval from testing on 
2023-06-07


It is affected by these RC bugs:
1035786: cpl-plugin-xshoo-calib: xshoo-kit-3.5.3*.tar.gz is no longer 
downloadable

 https://bugs.debian.org/1035786



This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

Bug#1036157: RM: cpl-plugin-fors/5.5.7+dfsg-2 -- ROM; outdated; required upstream file no longer available

[Ole Streicher]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm
Severity: normal

The package is outdated, and upstream doesn't provide the calibration 
files any longer, which leads to an RC bug. The actual version cannot be 
packaged due to unresolved licensing issues. Therefore, the package is 
unsuitable for bookworm; please remove it (it is marked for autoremoval; 
however there is no need to wait so long).


Cheers

Ole

 Forwarded Message 
Subject: cpl-plugin-fors is marked for autoremoval from testing
Date: Tue, 16 May 2023 04:39:02 +
From: Debian testing autoremoval watch 
To: cpl-plugin-f...@packages.debian.org

cpl-plugin-fors 5.5.7+dfsg-2 is marked for autoremoval from testing on 
2023-06-05


It is affected by these RC bugs:
1035696: cpl-plugin-fors-calib: fors-kit-5.5.6*.tar.gz is no longer 
downloadable

 https://bugs.debian.org/1035696



This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

Bug#1033797: [saods9] Cannot connect from IRAF to saods9

[Ole Streicher]

Package: saods9
Version: 8.4.1+repack-1
Severity: important

With the current version, the connection from IRAF to saods9 fails, 
because ds9 does not create the UNIX socket /tmp/.IMT%d.


The severity is set to "important" because interaction with IRAF is the 
main use case for saods9.

Bug#1032923: unblock: ftools-fv/5.5.2+dfsg-2

[Ole Streicher]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package ftools-fv.

The new version fixes the "important" bug #1032280 "fv may not start if 
another Tcl/Tk is installed". This is accompanied by a no-change-needed 
push of the Standards Version in d/control.


The package does not come with autopkgtests and therefore requires a 
manual unblock in hard freeze. It is a zero-day miss of the "Hard 
Freeze" milestone.


This is a leaf package. There are no risks accompanied with the update.

Debdiff:

diff -Nru ftools-fv-5.5.2+dfsg/debian/changelog 
ftools-fv-5.5.2+dfsg/debian/changelog
--- ftools-fv-5.5.2+dfsg/debian/changelog	2020-09-04 11:16:57.0 
+0200
+++ ftools-fv-5.5.2+dfsg/debian/changelog	2023-03-02 22:33:03.0 
+0100

@@ -1,3 +1,11 @@
+ftools-fv (5.5.2+dfsg-2) unstable; urgency=medium
+
+  * Make sure the correct "wish" is executed when fv is started
+(Closes: #1032280)
+  * Push Standards-Version to 4.6.2, no changes
+
+ -- Ole Streicher   Thu, 02 Mar 2023 22:33:03 +0100
+
 ftools-fv (5.5.2+dfsg-1) unstable; urgency=low

   * New upstream version 5.5.2+dfsg. Rediff patches
diff -Nru ftools-fv-5.5.2+dfsg/debian/control 
ftools-fv-5.5.2+dfsg/debian/control

--- ftools-fv-5.5.2+dfsg/debian/control 2020-09-04 11:16:17.0 +0200
+++ ftools-fv-5.5.2+dfsg/debian/control 2023-03-02 22:33:03.0 +0100
@@ -1,23 +1,26 @@
 Source: ftools-fv
-Section: science
-Priority: optional
 Maintainer: Debian Astro Team 


 Uploaders: Ole Streicher 
+Section: science
+Priority: optional
 Build-Depends: debhelper-compat (= 13),
libcfitsio-dev,
tcl-dev,
tk-dev,
wcslib-dev
-Standards-Version: 4.5.0
-Homepage: https://heasarc.gsfc.nasa.gov/docs/software/lheasoft/ftools/fv/
-Vcs-Git: https://salsa.debian.org/debian-astro-team/ftools-fv.git
+Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian-astro-team/ftools-fv
+Vcs-Git: https://salsa.debian.org/debian-astro-team/ftools-fv.git
+Homepage: https://heasarc.gsfc.nasa.gov/docs/software/lheasoft/ftools/fv/
 Rules-Requires-Root: no

 Package: ftools-fv
 Architecture: all
-Depends: ftools-pow, iwidgets4, ${misc:Depends}
-Suggests: saods9, xpa-tools
+Depends: ftools-pow,
+ iwidgets4,
+ ${misc:Depends}
+Suggests: saods9,
+  xpa-tools
 Description: Tool for viewing and editing FITS format files
  Fv provides a graphical user interface to data stored in FITS
  (Flexible Image Transport System) files.  Local files can be created,
diff -Nru 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Change-default-temp-location-to-tmp.patch 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Change-default-temp-location-to-tmp.patch
--- 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Change-default-temp-location-to-tmp.patch 
2020-09-04 11:12:32.0 +0200
+++ 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Change-default-temp-location-to-tmp.patch 
2023-03-02 22:33:03.0 +0100

@@ -6,14 +6,14 @@
 the home directory. This patch moves the temp files there while 
keeping the

 FVTMP behaviour intact.
 ---
- ftools/guis/fv/class/fvApp.tcl | 22 +++---
- 1 file changed, 15 insertions(+), 7 deletions(-)
+ ftools/guis/fv/class/fvApp.tcl | 24 
+ 1 file changed, 16 insertions(+), 8 deletions(-)

 diff --git a/ftools/guis/fv/class/fvApp.tcl 
b/ftools/guis/fv/class/fvApp.tcl

-index e347cf0..74b8f26 100644
+index e347cf0..60547db 100644
 --- a/ftools/guis/fv/class/fvApp.tcl
 +++ b/ftools/guis/fv/class/fvApp.tcl
-@@ -445,37 +445,45 @@ itcl::body fvApp::_setupBackup { } {
+@@ -445,44 +445,52 @@ itcl::body fvApp::_setupBackup { } {
 if { $isWin } {
set fvBackupDir "fv_tmp"
set fvHOME FV_HOME
@@ -66,3 +66,11 @@
if ![file exists $g_backupDir] {
 file mkdir $g_backupDir
}
+}
+
+# cleanup previous temp directory
+-   set backupList [eval glob -directory {[file dirname $g_backupDir]} 
-nocomplain "*"]
++   set backupList [eval glob -directory {[file dirname $g_backupDir]} 
-nocomplain "fvTmp_*_*"]

+
+foreach dirname $backupList {
+set token [split [file tail $dirname] "_"]
diff -Nru 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Replace-the-startup-script-by-something-simpler.patch 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Replace-the-startup-script-by-something-simpler.patch
--- 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Replace-the-startup-script-by-something-simpler.patch 
2020-09-04 11:12:32.0 +0200
+++ 
ftools-fv-5.5.2+dfsg/debian/patches/Fv-Replace-the-startup-script-by-something-simpler.patch 
2023-03-02 22:33:03.0 +0100

@@ -9,7 +9,7 @@
  2 files changed, 4 insertions(+), 121 deletions(-)

 diff --git a/ftools/guis/fv/fv b/ftools/guis/fv/fv
-index 49afa8e..d6edc4c 100755
+index 49afa8e..d3cf700 100755
 --- a/ftools/guis/fv/fv
 +++ b/ftoo

Bug#1032280: fv may not start if another Tcl/Tk is installed

[Ole Streicher]

Package: ftools-fv
Version: 5.5.2+dfsg-1
Severity: important

When another Tcl/Tk is installed, f.e. from Astroconda, and its "wish" 
shell precedes the system's one, fv may not work properly, because the 
wrong "wish" command is used.

Bug#1030336: ... Darktable does not work well under OpenCL.

[Ole Streicher]

Control: affects -1 darktable

It is (for my driver) in the libnvidia-nvvm4 package:

 $ apt-file search libnvidia-nvvm.so
libnvidia-libnvidia-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-nvvm.so.4
libnvidia-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-nvvm.so.525.85.12
libnvidia-tesla-470-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/tesla-470/libnvidia-nvvm.so.4
libnvidia-tesla-470-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/tesla-470/libnvidia-nvvm.so.4.0.0
libnvidia-tesla-510-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/tesla-510/libnvidia-nvvm.so.4
libnvidia-tesla-510-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/tesla-510/libnvidia-nvvm.so.4.0.0
libnvidia-tesla-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/tesla/libnvidia-nvvm.so.4
libnvidia-tesla-nvvm4: 
/usr/lib/x86_64-linux-gnu/nvidia/tesla/libnvidia-nvvm.so.525.85.12

I think that there is a missing dependency somewhere, and probably a
missing alternatives selection. I have put darktable to the "affects" to
have them included in the discussion.

Bug#1030336: ... Darktable does not work well under OpenCL.

[Ole Streicher]

Dear maintainer,

I tried to debug this a bit with

$ strace -f darktable-cltest -d opencl

and found that the reason is that the library "libnvidia-nvvm.so.4" was 
not found for the compilation. Darktable searches


/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/tls/haswell/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/tls/x86_64/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/tls/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/haswell/x86_64/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/haswell/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/x86_64/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.525.85.12

(and also on more places outside of /usr/lib/x86_64-linux-gnu/).

The installed driver libnvidia-nvvm4 however puts them under

/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-nvvm.so.4
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-nvvm.so.525.85.12

which is *not* searched. Pragmatically creating a symlink

libnvidia-nvvm.so.4 -> nvidia/current/libnvidia-nvvm.so.4

in /usr/lib/x86_64-linux-gnu/ resolves this; the darktable-cltest 
succeeds and darktable runs with OpenCL support.


I have no idea whether this syslink was forgotten in the libnvidia-nvvm4 
package or darktable should be adjusted to search in the new places. 
However, with this hint the problem should be resolvable in one of the 
packages.


Cheers

Ole

Bug#1029690: Reassign to scipy

[Ole Streicher]

Control: reassign -1 src:scipy 1.10.0-3
Control: forwarded -1 https://github.com/scipy/scipy/issues/17718
Control: tags -1 fixed-upstream patch

This issue is related to a bug in scipy, and is fixed upstream with
https://github.com/scipy/scipy/pull/17726

Bug#1029549: ITP: unity-java -- Multi-syntax unit parsing

[Ole Streicher]

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


 * Package name: unity-java
   Version : 1.1b
   Upstream Author : Norman Gray
 * URL : https://purl.org/nxg/dist/unity
 * License : BSD-2-Clause
   Programming Lang: Java
   Description : Multi-syntax unit parsing

The library was written with the following goals:

* Producing formal grammars of the existing and proposed standard unit
  syntaxes, for reference purposes.

* Producing parsing libraries which are fast and standalone, and so
  could be conveniently used by other software; this also acts as an
  implementation of the VOUnits standard.

It is not a goal for this library to do any processing of the resulting
units, such as unit conversion or arithmetic. Parsing unit strings isn't
a deep or particularly interesting problem, but it's more fiddly than
one might expect, and so it's useful for it to be done properly once.

The package will be maintained by the Debian Astro team. It is a new
dependency of the starjava packages.

A git repository will be created at

https://salsa.debian.org/debian-astro-team/unity-java

Best regards

Ole

Bug#1024248: closed by Matthias Klose (Re: [python3.11] platform.python_version() returns wrong value)

[Ole Streicher]

Hi Mathias,

would you mind forwarding this bug to upstream to discuss this? It looks 
a bit weird to me if upstream violates its own versioning rules. And 
having the danger of unparseable Python versions worries me a bit.


Cheers

Ole

On 31.12.22 11:27, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the python3.11 package:

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

It has been closed by Matthias Klose .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Matthias Klose 
 by
replying to this email.

Bug#1026024: specutils: FTBFS, ModuleNotFoundError: No module named 'asdf_astropy.io'

[Ole Streicher]

Control: reassign -1 src:asdf-astropy 0.3.0-1
Control: affects -1 src:specutils

This is a bug in the current python3-asdf-astropy package that is 
incomplete. However, according to #1025434 the cause for the issue is 
probably in python3-installer.

Bug#1025669: saods9 command line escaping

[Ole Streicher]

Package: saods9
Version: 8.2+repack-2
Severity: normal
X-Debbugs-Cc: Mark Copper 

On 05.12.22 01:27, Mark Copper wrote:

Hello,

ds9 from stable (v8.2 repack) cannot open files whose filenames contain a space.

That is, the command
$ ds9 a\ b.fits
fails with alert that ds9 is unable to load file 'a'.

Not every character in the ds9 command line is literal, of course.
Simple globbing can be a workaround.

The DS9 help desk thinks I'm out of it so it got me to wondering if
"repack" meant anything.

Thanks.

Mark Copper


Dear Mark,

The problem you found is indeed a bug in the Debian package: While the 
original SAOImageDS9 program comes as a single executable that contains 
all required libraries and subpackages, the Debian package uses system 
installed libraries and subpackages whereever possible. It therefore 
comes with its own launching script which has the bug you discovered. It 
is best to open a Debian bug, which is done by this mail.


Best regards

Ole

Bug#1025434: python3-installer: sometimes not all files are installed in the wheel

[Ole Streicher]

Package: python3-installer
Version: 0.5.1+dfsg1-3
Severity: important
Control: affects -1 src:asdf-astropy

Dear maintainer,

The package asdf-astropy recently switched to use pyproject.toml, and 
now the installation is myteriously incomplete: The package consists of 
a number of subpackages:


$ du asdf_astropy
8   asdf_astropy/io/tests
16  asdf_astropy/io
8   asdf_astropy/resources/schemas/table
8   asdf_astropy/resources/schemas/time
[...]

When building interactively (on the shell) in a sid environment, the 
build is often complete -- it seems to depend on the installed packages 
(when git is installed, it is complete; without git often not).


When building with pbuilder, on Salsa [1], or on buildd [2], the package 
is however missing all subpackages:


--8<-
dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:107: Building wheel for python3.11 with 
"build" module
I: pybuild base:240: python3.11 -m build --skip-dependency-check 
--no-isolation --wheel --outdir 
/builds/debian-astro-team/asdf-astropy/debian/output/source_dir/.pybuild/cpython3_3.11 

/usr/lib/python3/dist-packages/setuptools/config/pyprojecttoml.py:108: 
_BetaConfiguration: Support for `[tool.setuptools]` in `pyproject.toml` 
is still *beta*.

  warnings.warn(msg, _BetaConfiguration)
running bdist_wheel
running build
running build_py
creating build
creating build/lib
creating build/lib/asdf_astropy
copying asdf_astropy/_version.py -> build/lib/asdf_astropy
[... no asdf_astropy/io files here ...]
* Building wheel...
Successfully built asdf_astropy-0.3.0-py3-none-any.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.11 
with "installer" module

--8<-

On a discussion on the debian-python@l.d.o list, Scott Kitterman 
suggested [3] that this may be a bug in python3-installer; that's why 
the bug is filed here. Please re-assign if not.


This problem currently prevents a successfull build for asdf-astropy.

Best regards

Ole

[1] https://salsa.debian.org/debian-astro-team/asdf-astropy/-/jobs/3605729
[2] 
https://buildd.debian.org/status/fetch.php?pkg=asdf-astropy=all=0.3.0-1=1670016252=0

[3] https://lists.debian.org/debian-python/2022/12/msg00036.html

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#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#1021405: ITP: starjava-tfcat -- Time-Frequency Radio Catalogues parser

[Ole Streicher]

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


 * Package name: starjava-tfcat
   Version : 1.0+
   Upstream Author : Mark Taylor
 * URL : https://github.com/Starlink/starjava/tree/master/tfcat
 * License : LGPL-3+
   Programming Lang: Java
   Description : Time-Frequency Radio Catalogues parser

This package contains a parser and validator for the Time-Frequency Radio
Catalogues standard, defined at https://doi.org/10.25935/6068-8528.
It currently implements v1.0 of the standard.

The package will be maintained by the Debian Astro team. It is a new
dependency of the "topcat" and "ttools" (STILTS) packages.

A git repository will be created at

https://salsa.debian.org/debian-astro-team/starjava-tfcat

Best regards

Ole

Bug#1019874: python3-specutils: FTBFS on riscv64, segfault in Fortran library

[Ole Streicher]

Control: severity -1 important

Lowering severity to important since riscv64 is not a release 
architecture yet.


Cheers

Ole

Bug#1019708: Waiting for upstream fix

[Ole Streicher]

Control: tags -1 -patch

Upstream will fix this probably soon by merging 
https://github.com/astropy/astropy/pull/13614 into their development 
branch and backporting it to the 5.1 version. Probably then they will 
issue a bugfix version, as the PR covers all fixes for the upcoming 
Python 3.11.


I will wait for this bugfix version, as Python 3.11  will also soon 
knock on the Debian's door, and we need this anyway.

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#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#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#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#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#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#941158: Taking over ownership of ITP

[Ole Streicher]

Control: owner -1 !

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

Cheers

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

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#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#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#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#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#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#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#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#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#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#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#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#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#1005725: gavodachs2-server: fails to install with new python3-twisted.

[Ole Streicher]

Hi Markus,

On 14.02.22 13:47, Markus Demleitner wrote:

My plan right now would be to fix this in unstable by just packaging
release 2.6, which ought to happen in May 2022 and will contain the
patch (or whatever else).  If that's a major problem for someone,
speak up and I'll try to provide a more timely fix.


Just FYI: The Ubuntu 22.04 LTS Debian import freeze is on Feb 24:

https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906

If you want to have the fixes in Ubuntu 22.04 LTS, you should act before.

Cheers

Ole

Bug#1005092: pytest-mpl: Please update to version 0.13

[Ole Streicher]

Package: python3-pytest-mpl
Version: 0.11-2
Severity: wishlist

Dear maintainer,

I am currently packaging cmyt [1], which is a new dependency of the "yt" 
package. For testing, cmyt requires at least version 0.13 of pytest-mpl. 
Could I ask to update the version in Debian to this latest version?


Thank you very much!

Ole


[1] https://bugs.debian.org/1004960

Bug#1004960: ITP: cmyt -- Matplotlib colormaps from the yt project

[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, debian-scie...@lists.debian.org

* Package name: cmyt
  Version : 1.0.4
  Upstream Author : Clement Robert
* URL : https://github.com/yt-project/cmyt
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Matplotlib colormaps from the yt project

cmyt integrates with matplotlib in a similar fashion to cmocean or cmasher

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/cmyt

Best regards

Ole

Bug#1004517: [pyvo] CI failure with astropy 5.0.1; please update to version 1.2.1

[Ole Streicher]

Source: pyvo
Version: 1.1-1
Severity: serious
Control: affects -1 astropy

Dear maintainer,

I just uploaded astropy-5.0.1 to unstable. It appears that pyvo 1.1 is 
no longer compatible and now leads to a CI test error:


https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyvo/18800419/log.gz

Relevant lines:

  File "/usr/lib/python3/dist-packages/pyvo/utils/decorators.py", line 
4, in 

from astropy.utils.decorators import wraps
ImportError: cannot import name 'wraps' from 'astropy.utils.decorators' 
(/usr/lib/python3/dist-packages/astropy/utils/decorators.py)

autopkgtest [15:19:32]:  summary
python3-pyvo FAIL non-zero exit status 1


This is fixed upstream in pyvo 1.2.1:

https://github.com/astropy/pyvo/pull/283

so the easiest would be to upload the new version.

Best regards

Ole

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#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#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#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#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#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#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#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#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#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#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#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=mips64el=5.0-1=1637626067=0

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

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

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#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#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#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#995922: ruby-pgplot: please consider switching to giza

[Ole Streicher]

Source: ruby-pgplot
Version: 0.2.0-1
Severity: wishlist

Dear maintainer,

ruby-pgplot is currently in contrib because it depends on the non-free 
"pgplot5" package. There is however a DFSG-free replacement library 
"giza" available that provides a compatibility layer for pgplot. The 
compatibility is almost complete, so this may fulfill your needs. It 
maybe enough to just replace the pgplot5 build dependency with "giza-dev".


Switching to giza would allow to bring ruby-pgplot into Debians "main" 
archive, with the benefit of automated builds etc. Also, pgplot5 is dead 
upstream and maintained with NMUs since almost ten years now.


I am the maintainer of giza, and I am happy to help out if there are 
problems.


Best regards

Ole

Bug#995706: lintian: Regression: false positive missing-build-dependency-for-dh-addon python3

[Ole Streicher]

Package: lintian
Version: 2.107.0

Dear maintainer,

The recently uploaded version of Lintian issues a false positive on the
following source (ITP; not uploaded yet):

https://salsa.debian.org/debian-astro-team/casa-formats-io/-/tree/5fec988b8b

E: casa-formats-io source: missing-build-dependency-for-dh-addon python3 
=> python3:any | python3-all:any | python3-dev:any | python3-all-dev:any 
| dh-sequence-python3


Full log on Salsa here:

https://salsa.debian.org/debian-astro-team/casa-formats-io/-/jobs/2034138

The package's d/control lists python3-all-dev as a build dependency. The 
problem was also checked locally. This is a regression, 2.106.0 
(currently in testing) does not show this problem.


Best regards

Ole

Bug#995696: ITP: casa-formats-io -- Code to handle I/O from/to data in CASA format

[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: casa-formats-io
  Version : 0.1
  Upstream Author : Thomas Robitaille
* URL : http://casa-formats-io.readthedocs.org
* License : LGPL
  Programming Lang: Python
  Description : Code to handle I/O from/to data in CASA format

The casa-formats-io package is a small package which implements functionality 
to read data stored in CASA formats (such as .image datasets). This 
implementation is independent of and does not use casacore. The motivation for 
this package is to provide efficient data access via dask arraye, 
cross-platform data access, and data access with all modern Python versions.

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

https://salsa.debian.org/debian-astro-team/casa-formats-io

Best regards

Ole

Bug#993252: Astroquery doesn't work with Astropy 4.3.1

[Ole Streicher]

Control: tags -1 patch

Hi Nilesh, Vincent,

from astropy's CHANGES.rst, version 4.3:

* astropy.utils.data.get_pkg_data_path is publicly scoped (previously
  the private function _find_pkg_data_path) for obtaining file paths
  without checking if the file/directory exists, as long as the package
  and module do. [#11006]

This should be the replacement. And this is the patch in astroquery that 
fixes it:


https://github.com/astropy/astroquery/commit/cfb75e1e50.patch

Cheers

Ole

Bug#993004: yt: tests fail with h5py 3

[Ole Streicher]

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

The new version of yt is ready. However it depends on a new package 
"unyt" that is currently in NEW.

Bug#993252: Astroquery doesn't work with Astropy 4.3.1

[Ole Streicher]

Package: python3-astroquery
Version: 0.4.1+dfsg-4
Severity: serious

Dear maintainer,

The unit tests of astrquery errors with astropy version 4.3.1 which is
currently in unstable. Could you please update astroquery to the latest
version 0.4.3, which should resolve this?

A test log is here:

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

and the relevant error:

 ERROR collecting vo_conesearch/validator/tests/test_inpect.py _
ImportError while importing test module 
'/usr/lib/python3/dist-packages/astroquery/vo_conesearch/validator/tests/test_inpect.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/usr/lib/python3/dist-packages/astroquery/vo_conesearch/validator/tests/test_inpect.py:8:
 in 
from astropy.utils.data import _find_pkg_data_path, get_pkg_data_filename
E   ImportError: cannot import name '_find_pkg_data_path' from 
'astropy.utils.data' (/usr/lib/python3/dist-packages/astropy/utils/data.py)


Thank you!

Cheers

Ole

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

[Ole Streicher]

On 26.08.21 15:29, Alastair McKinstry wrote:
It would be good to clarify. There is another package I maintain in 
Debian, udunits, thats a C library but also provides a "canonical" units 
database. It would be good not to  duplicate (reuse libudunits-data in 
unyt etc ?)


I know that the situation if far from perfect; however both unyts and 
astropy.units are currently hand-written (and hand-optimized) and do not 
have a structured "database" behind. This will probably make it 
difficult to unify them. And both packages are so deeply integrated in 
their "universe" (astropy resp. yp-project) that even a unification 
within the (rather small) astronomy community did not happen yet.


Cheers

Ole

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

[Ole Streicher]

On 26.08.21 11:36, Alastair McKinstry wrote:

How does this interact with xarray, etc?


I don't know; the reason to package it is that it is a new requirement 
of the "yt" package. It was first developed within yt, and then 
separated. There is another attempt to use units in the "astropy" 
package; as far as I know they are not compatible.


A quick search however brings up

https://github.com/pydata/xarray/issues/525

with some long-lasting, unresolved discussion of the situation.

Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.

[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, debian-scie...@lists.debian.org

* Package name: unyt
  Version : 2.8.0
  Upstream Author : Nathan Goldbaum
* URL : debian-de...@lists.debian.org
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Pyton package for handling numpy arrays with units.

Often writing code that deals with data that has units can be confusing.
A function might return an array but at least with plain NumPy arrays,
there is no way to easily tell what the units of the data are without
somehow knowing a priori.

The unyt package (pronounced like “unit”) provides a subclass of NumPy’s
ndarray class that knows about units.

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/unyt

Best regards

Ole