Hi Andre,
thank you for the patch! I now created a new version with the patch and
uploaded it. I also added a simple test as you proposed.
Indeed, I normally just take the tarball from the repository and if I
cant directly find a later fix, I ask upstream about what to do :-)
CMake is still
Control: severity -1 serious
Hi Andre,
sorry that I only now found time to look into your Debian bug. Indeed,
from the build log [1] the libradler is build as shared lib, but not
installed into the package, while it was supposed to be built as a
static lib.
However, I couldn't figure out why
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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
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.
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.
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.
sg-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
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.
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:
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
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
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
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
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.
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
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:
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
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:
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
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
Control: severity -1 important
Lowering severity to important since riscv64 is not a release
architecture yet.
Cheers
Ole
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.
Hi Gürkan,
I just found your ITP for nusolve; did you experience difficulties with
packaging?
Is the package somewhere on Salsa?
Cheers
Ole
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
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
Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction
laws
Control: owner -1 !
I take over this one to get sncosmo finally into Debian
Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction laws
Control: owner -1 !
I take over this one to get sncosmo finally into Debian
Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction
laws
Control: owner -1 !
I take over this one to get sncosmo finally into Debian
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
Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction laws
Control: owner -1 !
I take over this one to get sncosmo finally into Debian
Control: owner -1 !
As discussed by personal mail, I will take over this.
Cheers
Ole
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:
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
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
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
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
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
. 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
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
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
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
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
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 versio
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 +
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
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
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?
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
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
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.
/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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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:
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
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
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.
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:
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
1 - 100 of 938 matches
Mail list logo
