Bug#1064810: transition: mpi-defaults
On 05/05/2024 16:59, Sebastiaan Couwenberg wrote: On 2/26/24 7:40 AM, Alastair McKinstry wrote: OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH. This transition is blocking many of the remaining packages rebuilt for 64-bit time_t. The autopkgtest for slurm-wlm on i386 is blocking testing migration of mpich: https://qa.debian.org/excuses.php?package=mpich Testing migration of openmpi is likewise blocked by autopkgtest failures on i386 of several rdeps: https://qa.debian.org/excuses.php?package=openmpi I'm starting to think that it'd be better to drop support for 32bit architectures from all these rdeps so they can just use openmpi everywhere and not have i386 autopkgtest failures able to block testing migration. Should we advocate this to the maintainer of these packages or is there something else we can do to improve this situation? Dropping 32-bit support for so many packages is a bit more radical than I had considered, but I'd go with it. Regards Alastair Kind Regards, Bas -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1069745: magics-python: wrong arch: any packaging builds potentially uninstallable packages
Hi Andreas Yes, thanks for this. I'm moving all packages I have in science-team to Science Maintainers. regards Alastair On 24/04/2024 07:23, Andreas Tille wrote: Control: tags -1 pending thanks Hi Alastair, as far as I learned in past example cases its rather by chance that you did not set Maintainer: Debian Science Maintainers in packages that are residing in science-team space on Salsa. I took the freedom to fix this in Git as well as applying the patch for this bug + routine-update (doing several tiny polishing changes). I hope you don't mind if I'll upload those changes this evening. Kind regards and thanks for maintaining this package in Debian Science team Andreas. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 02/04/2024 21:29, Sebastian Ramacher wrote: To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers It looks like libpmix-dev is only used by mpich, openmpi and slurm-wlm. mpich will be configured not to use pmix on 32-bit systems anyway slurm-wlm builds ok without pmix; it can be patched to use pmix only on 64-bit systems. openmpi in sid (4.1.6-7) has an internal copy of pmix 4.1.2 that it can be configured to use. I can prepare this for openmpi on the debian/trixie branch; to upload with a fix for #1067055, regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 02/04/2024 21:29, Sebastian Ramacher wrote: OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. So it is technically not a transition, but breaks 32-bit builds. Doesn't make it better. This is not the time to do that without tests builds and bugs filed. The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH builds on all archs, but testing all dependencies of the change has not been tested, and I don't know how you would do that - setting up eg ratt to rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) Beside the easy part of chaning mpi-defaults, I count 30 something packages that have explicit build dependencies on libopenmpi-dev. None of those packages has bugs filed to change to mpich on 32 bit architectures. To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers I checked with "build-rdeps libopenmpi-dev" and checked the packages. They are mostly false-alarms. What is needed: * mpich not to use libpmix for 32-bit archs. I've a patch i'm testing. * armci-mpi builds on both mpich, openmpi. Needs work to only build on openmpi on 64-bit. #10683219 * code-saturne: Uses the default mpi version of hdf5. #1068318 * adios: fix just uploaded. * vtk9: Depends on libhdf5-openmpi-dev instead of libhdf5-mpi-dev. #1068321 * trilinos: deps on openmpi , but only available on 64-bit systems. No change needed * hdf5: Needs to depend on 64-bit archs for libopenmpi-dev. #1068320 * scalapack: Needs to dep on 64-bit archs only for libopenmpi-dev. #1068322 Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1068322: scalapack: Please change the Build-dep on libopenmpi-dev to 64-bit systems only
Source: scalapack Version: 2.2.1-3.1 Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org As of version 5, OpenMPI will no longer support 32-bit systems. The upcoming mpi-defaults transition reflects this, making MPICH the only MPI variant for 32-bit systems. Please limit the B-D on libopenmpi-dev to 64-bit only (ie $(OPENMPI_AVAILABLE_ARCHITECTURES) ). Thanks Alastair McKinstry -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068321: vtk9: Please change B-D on libhdf5-openmpi-dev to libhdf5-mpi-dev
Source: vtk9 Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org As of version 5, OpenMPI no longer supports 32-bit systems. The upcoming mpi-defaults transition will reflect this, making MPICH the default on these systems. Vtk9 depends on libhdf5-openmpi-dev which will no longer ship on 32-bit systems. Please build-dep on libhdf5-mpi-dev instead. Thanks Alastair McKinstry -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068320: hdf5: Needs to not depend on libopenmpi-dev for 32-bit systems
Source: hdf5 Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org As of OpenMPI 5 (and PMIX 5), OpenMPI will no longer work on 32-bit systems. Hence there is an mpi-defaults transition coming to reflect this and use MPICH only for 32-bit systems. HDF5 currrently assumes libopenmpi-dev is available for all archs. Please fix this for the mpi-defaults transition. Thanks Alastair McKinstry -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068319: armci-mpi: debian-...@lists.debian.org
Source: armci-mpi Version: 0.3.1~beta-7 Severity: normal As of the OpenMPI 5 release, OpenMPI will no longer support 32-bit systems. So there is an upcoming mpi-defaults transition (https://release.debian.org/transitions/html/mpi-defaults.html) that points MPICH as the only MPI for 32-bit systems. Please prepare armci-mpi for this transition. Regards Alastair McKinstry -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068318: code-saturne: Build against mpich for MPI on 32-bit systems
Source: code-saturne Version: 6.0.2-2 Severity: normal X-Debbugs-Cc: debian-...@lists.debian.org As of openmpi 5, OpenMPI will no longer build on 32-bit systems. So mpi-defaults will point to MPICH on 32-bit systems after the MPI transition. Please enable code-saturne to build on systems where OpenMPI is not present. Thanks Alastair McKinstry -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 01/04/2024 23:25, Sebastian Ramacher wrote: There is a transition to openmpi-5 / mpi-defaults which is stalled by the t64 transition. It drops 32-bit support from OpenMPI. Because of this, I don't think the solution is to port 32-bit atomics for armel/armhf, as it will be removed in a few weeks/months. While we didn't want the transitions to be done simultaneously, it might be the best answer. What does the release team think? Adding another transition on top will just delay the time_t transition even more. So if we can avoid that, I'd prefer to not do this transition now. Unfortunately, uploads such as the one of pmix that no dropped support for 32 bit architectures (#1068211) are not really helpful. Also, #1064810 has no information on test builds with the new mpi-defaults on a 32 bit architecture. So has this transition been tested? Cheers OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. So it is technically not a transition, but breaks 32-bit builds. The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH builds on all archs, but testing all dependencies of the change has not been tested, and I don't know how you would do that - setting up eg ratt to rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) I'm sorry I missed the dropped 32-bit support for pmix; I tested on 64-bit platforms only. Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 23/03/2024 01:58, Thorsten Glaser wrote: Andrey Rakhmatullin dixit: OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64 And I assume this arch doesn't have 64-bit atomics. No native ones, yes. I *think* either libatomic or libatomic_ops(?) make them available, but very slowly, using a syscall to guarantee atomicity (those systems are normally uniprocessor) on m68k. If possible, avoiding them would be preferrable. (For example, in some cases, like reading a 64-bit timestamp, if the writing direction is known and stable, reading twice then comparing is a possible alternative at least for some architectures (e.g. I know BSD code for sparc does it that way). I guess you’ll have to ask the porters of 32-bit arches with no native 64-bit atomics for details. Though I had thought GCC’s builtin atomics use the aforementioned kernel-based workaround from that library these days? There is a transition to openmpi-5 / mpi-defaults which is stalled by the t64 transition. It drops 32-bit support from OpenMPI. Because of this, I don't think the solution is to port 32-bit atomics for armel/armhf, as it will be removed in a few weeks/months. While we didn't want the transitions to be done simultaneously, it might be the best answer. What does the release team think? bye, //mirabilos -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1064902: ratt fails to add deb:// line if appropriate line not in apt/sources.list
Package: ratt Version: 0.0~git20190123.9e77a6d-1+b6 Severity: normal I ran ratt on a system without a deb: line in /etc/apt/sources.list for the dist. It calls dose-ceve without the necessary deb:// and silently fails to find the right rdeps to rebuild. Please add some --verbose debugging and more checking args. Thanks Alastair -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ratt depends on: ii libc6 2.36-9+deb12u4 ii sbuild 0.85.0 Versions of packages ratt recommends: ii dose-extra 7.0.0-1+b2 ratt suggests no packages. -- no debconf information
Bug#1064810: transition: mpi-defaults
On 26/02/2024 12:03, Drew Parsons wrote: On 2024-02-26 07:40, Alastair McKinstry wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: mpi-defau...@packages.debian.org, debian-scie...@lists.debian.org Control: affects -1 + src:mpi-defaults OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH. notes = "https://lists.debian.org/debian-release/2023/11/msg00379.html;; Be mindful that Ubuntu is about to freeze for their noble LTS release. We're (or I'm) still updating some Debian packages with the hope to get the new versions (and new packages) into noble. Since it's an LTS release, our packages will still be supporting their users in, say, 3 or 4 years time. Would it be reasonable to pause the 32-bit mpich transition until after they've frozen noble? Or alternatively, can this mpich transition be completed in time to make it into their freeze (only days left). Drew Hi I think we can get mpich 4.2.0 into noble. I've been doing a full rebuild of mpich repds and mpich4.2 is not a transition (as feared); I'll do an upload later today. This is independent of mpi-defaults. I'm test-building mpich on armhf and hopefully will have a test completed today/tomorrow. Regards Alastair Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1064810: transition: mpi-defaults
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: mpi-defau...@packages.debian.org, debian-scie...@lists.debian.org Control: affects -1 + src:mpi-defaults OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH. notes = "https://lists.debian.org/debian-release/2023/11/msg00379.html;; Ben file: title = "mpi-defaults"; is_affected = .build-depends ~ /mpi-default-dev/; is_good = .depends ~ /libmpich.*/; is_bad = .depends ~ /libopenmpi.*/; architectures = [ "armhf","armel","i386" ]; ignored = [ ];
Bug#962786: Are you still working on pcpp?
Hi Just checking again. Do you mind if I upload python3-pcpp? Thanks Alastair On 01/02/2024 14:55, Alastair McKinstry wrote: Hi, I need pcpp for my own package "loki-ecmwf". I have it ready to upload if you have no interest anymore. Best regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1063532: ITP: ford -- Fortran Documentation tool
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: ford Version : 7.0.5 Upstream Contact: Christopher MacMackin * URL : https://github.com/Fortran-FOSS-Programmers/ford * License : GPL Programming Lang: Python Description : Fortran Documentation tool The goal of FORD is to be able to reliably produce documentation for modern Fortran software which is informative and nice to look at. The documentation should be easy to write and non-obtrusive within the code. While it will never be as feature-rich as Doxygen, hopefully FORD will be able to provide a good alternative for documenting Fortran projects. Ford is already used (if present) by several projects packaged in Debian. I intend to manage it in Salsa; perhaps in Debian-Science team.
Bug#1063521: ITP: pymbolic -- Easy Expression Trees and Term Rewriting library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pymbolic Version : 2022.2 Upstream Contact: Andreas Klöckner * URL : https://github.com/inducer/pymbolic * License : MIT/X Programming Lang: Python Description : Easy Expression Trees and Term Rewriting library I am packaging this as Pymbolic is a small expression tree and symbolic manipulation library. Two things set it apart from other libraries of its kind: * Users can easily write their own symbolic operations, simply by deriving from the builtin visitor classes. * Users can easily add their own symbolic entities to do calculations with. Pymbolic currently understands regular arithmetic expressions, derivatives, sparse polynomials, fractions, term substitution, expansion. It automatically performs constant folding, and it can compile its expressions into Python bytecode for fast(er) execution. It is not expected to be a replacement for Sympy, which is more complex.
Bug#1063520: ITP: codetiming -- A Timer package for Python code
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: codetiming Version : 1.4.0 Upstream Contact: David Beazley * URL : https://pypi.python.org/pypi/codetiming * License : MIT Programming Lang: Python Description : A Timer package for Python code This is a dependency of loki-ecmwf, already submitted. It is a simple timer class for Python.
Bug#962786: Are you still working on pcpp?
Hi, I need pcpp for my own package "loki-ecmwf". I have it ready to upload if you have no interest anymore. Best regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1061367: ITP: loki-ecmwf -- Source-to-source code translator for Fortran
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: loki-ecmwf Version : 0.1.6 Upstream Contact: Michael Lange (michael.la...@ecmwf.int) * URL : https://github.com/ecmwf-ifs/loki * License : Apache-2 Programming Lang: Python Description : Source-to-source code translator for Fortran Loki is an experimental tool to explore the possible use of source-to-source translation for ECMWF's Integrated Forecasting System (IFS) and associated Fortran software packages. Loki is based on compiler technology (visitor patterns and ASTs) and aims to provide an abstract, language-agnostic representation of a kernel, as well as a programmable (pythonic) interface that allows developers to experiment with different kernel implementations and optimizations. The aim is to allow changes to programming models and coding styles to be encoded and automated instead of hand-applying them, enabling advanced experimentation with large kernels as well as bulk processing of large numbers of source files to evaluate different kernel implementations and programming models. This software is now in use beyond ECMWF, and I intend to work and develop it with other Fortran environments in Debian. I intend to maintain it within Debian Science team as part of the Meteorology stack. As Loki is a pre-existing name in Debian, I intend to follow convention and rename the package loki-ecmwf.
Bug#1061366: python3.12: Python3.12 segfaults on python-xarray testsuite
Package: python3.12 Version: 3.12.1-2 Severity: serious Justification: 4 X-Debbugs-Cc: debian-pyt...@lists.debian.org Python3.12 segfaults on the unittest suite for python-xarray (2024.01.0, head of tree in debian/latest) Unfortunately I cannot get a core dump yet to be more specific; this is on arm64 at least. -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1061246: newt FTCBFS: uses the wrong python-config
Hi, Yes, I'm willing to apply this. Alastair On 20/01/2024 20:35, Helmut Grohne wrote: Source: newt Version: 0.52.24-2 User: debian-cr...@lists.debian.org Usertags: ftcbfs Tags: patch upstream Hi, thanks for quickly fixing the error trapping. newt also fails to cross build from source, because it fails finding some Python stuff. This is rooted in Makefile.in hard coding the build architecture python-config, which works badly when combined with a host architecture compiler. Fixing this is rather tricky. In principle, we'd want to use AC_PATH_TOOL to disocver python-config, but it really is python$ver-config and we cannot loop over all available Python versions and call AC_PATH_TOOL for each as AC_PATH_TOOL needs to know the program name at autoconf time rather than at configure time. So what I'm proposing here is to emulate AC_PATH_TOOL in the Makefile.in by passing ac_tool_prefix to the Makefile.in and there trying the prefixed python-config before the plain one. In a cross build, the prefixed one will be selected and things work. When the prefixed one does is not exist, it'll fall back to the unprefixed one and work as before. Is that something you're willing to apply? Do you have other ideas for solving this? Helmut -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1055848: Reproducing
I've now been able to setup autopkgtest locally based on sbuild. I get failures in an autopkgtest (sbuild sid) chroot, but not when I do a clean pbuilder chroot via sid to do "pbuilder login". Investigating the differences between what should be identical chroots. Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1060667: radicale: Radicale is not logging to a log file under /var/log/radicale as per systemd unit "LogsDirectory"
Package: radicale Version: 3.1.8-2 Severity: normal Dear Maintainer, I have installed Radicale Card/CalDAV server on Debian Bookworm (12.4). apt install radicale Install adds "radicale" user and group OK. Config file in /etc/radicale/config I did not change the config file (initially). Enable and use systemd service (installed as /lib/systemd/system/radicale.service). systemctl enable radicale.service systemctl start radicale.service systemctl status radicale.service : --- ● radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server Loaded: loaded (/lib/systemd/system/radicale.service; enabled; preset: enabled) Active: active (running) since Fri 2024-01-12 10:50:29 GMT; 5s ago Docs: man:radicale(1) Main PID: 61961 (radicale) Tasks: 1 (limit: 9249) Memory: 20.9M CPU: 726ms CGroup: /system.slice/radicale.service └─61961 /usr/bin/python3 /usr/bin/radicale Jan 12 10:50:29 vesta systemd[1]: Started radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server. --- In /var/log/syslog (and journal) : Jan 12 10:50:29 vesta systemd[1]: Started radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server. Radicale systemd unit includes a "[Service]" section : [Service] ExecStart=/usr/bin/radicale Restart=on-failure LogsDirectory=radicale User=radicale and should use a log file : /var/log/radicale ls -l /var/log : drwxr-xr-x 2 radicale radicale 4096 Jan 12 10:50 radicale However this directory is empty and never populated. Set logging to "info" in config file and : systemctl restart radicale : /var/log/syslog : 2024-01-12T10:53:49.958708+00:00 vesta systemd[1]: Stopping radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server... 2024-01-12T10:53:50.050017+00:00 vesta systemd[1]: radicale.service: Deactivated successfully. 2024-01-12T10:53:50.050667+00:00 vesta systemd[1]: Stopped radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server. 2024-01-12T10:53:50.066160+00:00 vesta systemd[1]: Started radicale.service - A simple CalDAV (calendar) and CardDAV (contact) server. 2024-01-12T10:53:50.585767+00:00 vesta radicale[62111]: [2024-01-12 10:53:50 +] [62111] [INFO] Loaded default config 2024-01-12T10:53:50.586197+00:00 vesta radicale[62111]: [2024-01-12 10:53:50 +] [62111] [INFO] Loaded config file '/etc/radicale/config' 2024-01-12T10:53:50.586326+00:00 vesta radicale[62111]: [2024-01-12 10:53:50 +] [62111] [INFO] Skipped missing config file '/var/lib/radicale/.config/radicale/config' 2024-01-12T10:53:50.586435+00:00 vesta radicale[62111]: [2024-01-12 10:53:50 +] [62111] [INFO] Starting Radicale /var/log/radicale is still empty. No log file written here. I assume I should see logging go to a file under this directory. I also assume that I might be doing something wrong. Many Thanks for having a look. Alastair -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages radicale depends on: ii adduser3.134 ii init-system-helpers1.65.2 ii python33.11.2-1+b1 pn python3-radicale ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages radicale recommends: ii ssl-cert 1.1.2 Versions of packages radicale suggests: pn apache2 pn apache2-utils pn libapache2-mod-proxy-uwsgi pn python3-bcrypt pn python3-passlib pn uwsgi pn uwsgi-plugin-python3
Bug#1060077: transition: g2clib
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g2c...@packages.debian.org, sramac...@debian.org Control: affects -1 + src:g2clib There is a minor transition I wish to proceed. g2clib upstream have added an SOVERSION of .0 so the package name has changed libg2c0d -> libg2c0 Three dependencies will need rebuilding: pygrib, ncl and grads. I also maintain these 3 packages and they trivially rebuild. So this can be done in a day, without impacting other transitions. Ben file: title = "g2clib"; is_affected = .depends ~ "libg2c0d" | .depends ~ "libg2c0"; is_good = .depends ~ "libg2c0"; is_bad = .depends ~ "libg2c0d";
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 27/12/2023 21:30, Drew Parsons wrote:
Hi Alistair, given the complexity around hacking openmpi to
accommodate placing the mod files under /usr/include, I'm starting to
wonder whether it's the best way of resolving Bug#1058526 in the first
place.
I did it bit of background reading on the fortran mod files. There's a
fair bit of dissent about them, and no consensus on a proper
location. e.g. https://fortranwiki.org/fortran/show/Library+distribution
The files are binary dependent (and compiler version dependent), and
not clear that /usr/include is the best place for them anyway.
mpich seems to be fine placing them in
/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/mpich, and openmpi
seemed to be happy enough doing the same up until Bug#1058526.
Is there a different way of resolving Bug#1058526 without moving the
mod files to /usr/include?
Drew
I had altered FMODDIR from /usr/lib/ to /usr/include to match what
appears to be most conventional, but given the problems caused, I'm
backing out that change and reverting to /usr/lib/${DEB_HOST_MULTIARCH}/.
It will take changes in dh-fortran-mod and openmpi which I'm doing today.
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 27/12/2023 08:45, Drew Parsons wrote:
On 2023-12-26 12:45, Drew Parsons wrote:
I can manually reproduce the error trivially on an arm64 chroot
(amdahl.debian.org). Copying hello.f90 from openmpi's debian/tests
and manually running
mpif90 -o hello hello.f90
reproduces the error reference to the x86_64 include path on the
arm64 machine.
`mpif90.openmpi -print-search-dirs` only shows aarch64 paths though.
I guess the problem must be the common files from openmpi-common in
/usr/share/openmpi/. They're not actually arch-independent. Do
mpif90.openmpi and the other components actively read them at runtime?
For instance, /usr/share/openmpi/mpif90.openmpi-wrapper-data.txt contains
fmoddir=/usr/include/x86_64-linux-gnu/fortran/gfortran-mod-15
Since openmpi-common is marked Arch: all, it's only built once, on
amd64, hence x86_64-linux-gnu gets carried to the other arches. The
compiler_flags variables is also affected, alongside as fmoddir.
It looks like only the mpi fortran wrapper txts are affected,
mpif77-wrapper-data.txt
mpif77.openmpi-wrapper-data.txt
mpif90-wrapper-data.txt
mpif90.openmpi-wrapper-data.txt
mpifort-wrapper-data.txt
mpifort.openmpi-wrapper-data.txt
Should these be moved from openmpi-common to libopenmpi-dev (or
openmpi-bin)
at /usr/lib//openmpi/share ?
This appears to be it. I've been building on arm64 recently (a VM on a
mac) and don't see this.
There appears to be a mechanism for including ${includedir} and
${libdir} and evaluating the wrapper-data files at runtime. My hacking
on these files in d/rules is causing the errors. I'll work on a better
solution.
Alastair
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 24/12/2023 10:50, Drew Parsons wrote: reopen 1058876 block 1058944 by 1058876 thanks Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi fortran modules has hardcoded x86_64-linux-gnu This is preventing builds and tests on other architectures, e.g. rebuilding sundials for the petsc transition. I think openmpi's debian/tests will also need Depends: pkg-config for the new compile_run_cc_pkgconfig test. The problem appears to be the heuristics in upstream/FindMPI.cmake in adios2 (and sundials). It happens in sid tests but not my arm64 devel environment. Debugging slowly. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1058923: transition: g2clib
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g2c...@packages.debian.org, debian-rele...@lists.debian.org Control: affects -1 + src:g2clib There is a minor transition I wish to proceed. g2clib upstream have added an SOVERSION of .0 so the package name has changed libg2c0d -> libg2c0 Three dependencies will need rebuilding: pygrib, ncl and grads. I also maintain these 3 packages and they trivially rebuild. So this can be done in a day, without impacting other transitions. title = "g2clib"; is_affected = .depends ~ "libg2c0d" | .depends ~ "libg2c0"; is_good = .depends ~ "libg2c0"; is_bad = .depends ~ "libg2c0d";
Bug#1057727: Breaking multi-arch: foreign
Hi, Using mpicc,etc is the conventional approach for MPI, but I favour moving to pkg-config. The reason is that we've seen a 'wrapper-war' with other packages adding eg hdf5cc etc wrappers on top of mpicc , etc and above - one wrapper on top of another which as an approach is unsustainable. pkg-config can sort out the stacking as needed. Thanks Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1055848: Processed: Re: cfgrib failing to find eccodes
I cannot reproduce this locally yet - running the tests in a clean chroot works fine. However ecmwflibs was failing when I tested it - but worked ok when rebuilt, so I've added a superficial test for autopkgtest to it, to see if it breaks on its own in the CI pipeline. Alastair On 10/12/2023 18:51, Debian Bug Tracking System wrote: Processing control commands: retitle -1 cfgrib: test failure - can't find eccodes Bug #1055848 [src:cfgrib] cfgrib: autopkgtest regression Changed Bug title to 'cfgrib: test failure - can't find eccodes' from 'cfgrib: autopkgtest regression'. -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1057476: flang-17: flang-new-17 fails to compile code that gfortran accepts
Package: flang-17
Version: 17.0.6-1
Severity: normal
Tags: upstream
Taking code "mo_cdi.f90" from the package "cdo",
flang-new-17 -c mo_cdi.f90 gives:
"""
error:
loc("/home/alastair/git/dh-fortran-mod/tests/flang-17/../mo_cdi.f90":19:16):
redefinition of symbol named 'free'
error: Lowering to LLVM IR failed
"""
The code mo_cdi.f90 looks like:
"""
module mo_cdi
use iso_c_binding
implicit none
private
public ctrim
public c_len
interface
integer(c_size_t) function lib_strlen(charPtr) bind(c, name = "strlen")
import c_size_t, c_ptr
type(c_ptr), value :: charPtr
end function lib_strlen
subroutine lib_free(ptr) bind(c, name = "free")
import c_ptr
type(c_ptr), value, intent(in) :: ptr
end subroutine lib_free
end interface
"""
-- System Information:
Debian Release: 12.2
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_IE.UTF-8), LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1057266: ITP: lfortran -- Fortran compiler
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: lfortran Version : 0.29.0 Upstream Contact: @lfortranorg * URL : https://www.lfortran.org/ * License : Apache Programming Lang: C++ Description : Interactive Fortran compiler LFortran is a modern open-source (BSD licensed) interactive Fortran compiler built on top of LLVM. It can execute user’s code interactively to allow exploratory work (much like Python, MATLAB or Julia) as well as compile to binaries with the goal to run user’s code on modern architectures such as multi-core CPUs and GPUs. This is currently the most mature Fortran compiler on LLVM.
Bug#1056054: Reported upstream
I've opened a bug upstream in prrte. https://github.com/openpmix/prrte/issues/1849 -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1050854: Please push your changes to python-xarray
Hi Apologies I am swamped on this. Please go ahead and apply. Thanks Alastair On 13/11/2023 12:51, Andreas Tille wrote: Ping? I'd love to apply the patch from the bug report and push everything properly. If I do not hear from you I might consider mass-commiting all the releases you made without pushing to the repository in one single commit and add what I'd like to commit. Kind regards Andreas. Am Tue, Nov 07, 2023 at 09:26:13AM +0100 schrieb Andreas Tille: Hi Alastair, I realised that the Git repository on salsa[1] is lagging a couple of uploads behind the package pool. Please be so kind to push your changes to Salsa. Thanks a lot for your work on this package Andreas. [1] https://salsa.debian.org/science-team/python-xarray -- http://fam-tille.de -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1052191: unicode-data: Please update for the new 15.1 release
Hi Graham Apologies for not treating this properly as a transition. Changes have been limited to adding new symbols to the set, I had not thought that this would break dependencies. regards Alastair On 27/09/2023 14:42, Graham Inggs wrote: Please coordinate transitions with the release team. https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1052934: plocate: Error running inside LXC container using systemd service (timer) with PrivateNetwork=true set
I'll sort it out. The debian bug system seems a bit arcane compared with what I'm used to but I'll manage it. Thanks for your help. Alastair On Tue, 26 Sep 2023, at 6:02 PM, Steinar H. Gunderson wrote: > On Tue, Sep 26, 2023 at 05:57:03PM +0100, Alastair Sherringham wrote: >> Is a re-assignment to LXC something you do, or I do? > > Anyone can do it; you probably know better than me what the package name is. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ -- Alastair Sherringham http://www.sherringham.net
Bug#1052934: plocate: Error running inside LXC container using systemd service (timer) with PrivateNetwork=true set
Thanks, that's fine. Is a re-assignment to LXC something you do, or I do? Cheers, Alastair On Tue, 26 Sep 2023, at 5:05 PM, Steinar H. Gunderson wrote: > On Tue, Sep 26, 2023 at 04:11:12PM +0100, Alastair Sherringham wrote: >> Yes, probably something somewhere else. Maybe a library plocate uses breaks >> with "PrivateNetwork" on. I do not know enough about the internals of >> containers, namespaces or systemd to know. > > No, my point is; I don't see that this is plocate-specific at all. > Every service or timer that uses PrivateNetwork=yes will be affected > by this. So plocate is the wrong place to fix it, and also the wrong > place to document it. > > I guess a good place to start would be to reassign the bug to LXC > and see if they can work something out with systemd. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ -- Alastair Sherringham http://www.sherringham.net
Bug#1052934: plocate: Error running inside LXC container using systemd service (timer) with PrivateNetwork=true set
Thanks Steinar. Yes, probably something somewhere else. Maybe a library plocate uses breaks with "PrivateNetwork" on. I do not know enough about the internals of containers, namespaces or systemd to know. I am not sure what to do but thought it worth adding to the system. I think it is reasonable to expect the timer to work in an LXC container - maybe it is at least worth a "README" mentioning this problem? Like a "known issues" document? e.g. Debian 12 Bookworm LXC 5.0.2-1 systemd 252.12-1~deb12u1 plocate 1.1.18-1 Note: If the Systemd unit setting "PrivateNetwork" is set as "true", plocate may fail to run via the systemd unit file (from a systemd timer) inside an LXC container with an error : Failed to set up network namespacing: Permission denied This is due to the default setting "PrivateNetwork=true" in the unit file : /usr/lib/systemd/system/plocate-updatedb.service To avoid this, either : 1) Modify systemd unit Copy the unit file to the directory : /etc/systemd/system and override the setting to "false" (or remove it). You will then need to re-load the systemd daemon : systemctl daemon-reload or : 2) Use cron Instead of a systemd timer, use standard cron. You can remove the systemd check and "exit" in the plocate cron file "/etc/cron.daily/plocate". Cheers, Alastair On Tue, 26 Sep 2023, at 3:21 PM, Steinar H. Gunderson wrote: > On Tue, Sep 26, 2023 at 02:45:43PM +0100, Alastair Sherringham wrote: >> So there seems to be a problem with the systemd "PrivateNetwork" and >> plocate inside an LXC container - which might not surprise due to LXC >> using namespace magic as well. > > Hi, > > Thanks for tracking this down. > > To me, this sounds like a bug in either systemd or LXC; plocate isn't > involved at all? I mean, there's nothing I can change in plocate to fix > this issue, short of just not using the not-working systemd option. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ -- Alastair Sherringham http://www.sherringham.net
Bug#1052934: plocate: Error running inside LXC container using systemd service (timer) with PrivateNetwork=true set
Package: plocate Version: 1.1.18-1 Severity: normal Tags: upstream Dear Maintainer, I have an LXC container with plocate installed. Both host and container run Debian 12 Bookworm. The LXC container was created using basic LXC and the root filesystem using Debian "mmdebstrap". Plocate runs on a systemd timer. I saw that it had not run. Looking at the system logs using journalctl, I saw a plocate run error reported : Sep 26 10:22:34 eos (.plocate)[82]: plocate-updatedb.service: Failed to set up network namespacing: Permission denied Sep 26 10:22:34 eos systemd[1]: Starting plocate-updatedb.service - Update the plocate database... Sep 26 10:22:34 eos (.plocate)[82]: plocate-updatedb.service: Failed at step NETWORK spawning /usr/sbin/updatedb.ploc> Sep 26 10:22:34 eos systemd[1]: plocate-updatedb.service: Main process exited, code=exited, status=225/NETWORK Sep 26 10:22:34 eos systemd[1]: plocate-updatedb.service: Failed with result 'exit-code'. If I run plocate from the CLI (per systemd unit ExecStart) : /usr/sbin/updatedb.plocate It runs OK. So a problem with plocate running from systemd inside a container. To Fix : I edit the systemd unit file : /usr/lib/systemd/system/plocate-updatedb.service Change : PrivateNetwork=true to (comment out) : #PrivateNetwork=true Reload systemd and re-run : systemctl daemon-reload systemctl start plocate-updatedb This now works, and I see in the logs : Sep 26 10:23:58 eos systemd[1]: Reloading. Sep 26 10:24:01 eos systemd[1]: Starting plocate-updatedb.service - Update the plocate database... Sep 26 10:24:01 eos systemd[1]: plocate-updatedb.service: Deactivated successfully. Sep 26 10:24:01 eos systemd[1]: Finished plocate-updatedb.service - Update the plocate database. I put my own version of the "plocate-updatedb.service" (without the "PrivateNetwork" line) in the directory : /etc/systemd/system So there seems to be a problem with the systemd "PrivateNetwork" and plocate inside an LXC container - which might not surprise due to LXC using namespace magic as well. Rather than adjusting the security of the plocate systemd unit, it might be sufficient to document this problem in a README perhaps. Many Thanks, Alastair -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plocate depends on: ii adduser 3.134 ii libc6 2.36-9+deb12u1 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 ii liburing2 2.3-3 ii libzstd11.5.4+dfsg2-5 plocate recommends no packages. Versions of packages plocate suggests: ii systemd-sysv 252.12-1~deb12u1 -- no debconf information
Bug#1051017: cdo: Major data error with ICON files
Package: cdo Version: 2.2.1 Severity: serious Tags: upstream Justification: 2 X-Debbugs-Cc: Momtchil Momtchev Just a heads up that there is a serious issue with the cdo version in bookworm - it produces broken (flipped on the Y-axis) GRIBs when "remapping" (extracting) data from the ICON output files. The one in bullseye works correctly. As this is probably the number one reason commoners use cdo, it is a major showstopper. Here is the original bug report: https://code.mpimet.mpg.de/boards/1/topics/14808 The issue has been fixed in 2.2.2. -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cdo depends on: ii libc6 2.36-9+deb12u1 pn libcdi0 ii libcurl3-gnutls 7.88.1-10+deb12u1 ii libfftw3-double3 3.3.10-1 ii libgcc-s1 12.2.0-14 ii libgomp1 12.2.0-14 pn libhdf5-103-1 pn libmagplus3v5 pn libnetcdf19 pn libproj25 ii libstdc++612.2.0-14 pn libudunits2-0 Versions of packages cdo recommends: pn python3-cdo cdo suggests no packages.
Bug#1039871: proposed patch fails
Hi Unfortunately the proposed patch doesn't fix the problem. With later versions of xarray now using pooch to download data, and failing if its not setup, a better fix to the download issue is needed. regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Bug#1041202: flang-16: flang fails to compile: missing libraries
Package: flang-16 Version: 16.0.6-4 Severity: normal flang-new fails to compile a hello world program: alastair@debian:/tmp$ flang-new-16 -o foo hello.f90 /usr/bin/ld: cannot find -lFortran_main: No such file or directory /usr/bin/ld: cannot find -lFortranRuntime: No such file or directory /usr/bin/ld: cannot find -lFortranDecimal: No such file or directory flang-new: error: linker command failed with exit code 1 (use -v to see invocation) regards Alastair -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1039997: RFP: go-mega -- A client library in go for mega.nz storage service, required for rclone
Package: wnpp Severity: wishlist * Package name: go-mega Version : Unknown Upstream Contact: See https://github.com/t3rm1n4l/go-mega * URL : https://github.com/t3rm1n4l/go-mega * License : MIT Programming Lang: Go Description : A client library in Go for mega.co.nz storage service This is an API client library for MEGA storage service. Currently, the library supports the basic APIs and operations as follows: * User login * Fetch filesystem tree * Upload file * Download file * Create directory * Move file or directory * Rename file or directory * Delete file or directory * Parallel split download and upload * Filesystem events auto sync * Unit tests It would be used by rclone so rlcone can support Mega.nz cloud storage. https://github.com/rclone/rclone/issues/3980#issuecomment-654415017 has details and the rlcone package patch where the Mega backend is disabled is at https://sources.debian.org/patches/rclone/1.60.1%2Bdfsg-2/0002-Disable-mega-backend.patch/ Thank you.
Bug#1022255: fixed in python-xarray 2022.11.0-2
Dear Antonio Apologies but I saw this too late to stop the transition to testing. At this stage, I believe the best solution is to work on the issues in satpy and dask; I can help. Best regards Alastair On 07/12/2022 08:38, Antonio Valentino wrote: Dear Alastair, On Mon, 21 Nov 2022 15:12:02 + Debian FTP Masters wrote: Source: python-xarray Source-Version: 2022.11.0-2 Done: Alastair McKinstry We believe that the bug you reported is fixed in the latest version of python-xarray, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1022...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Alastair McKinstry (supplier of updated python-xarray package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 21 Nov 2022 14:37:38 + Source: python-xarray Architecture: source Version: 2022.11.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Alastair McKinstry Closes: 1004869 1022255 1023222 Changes: python-xarray (2022.11.0-2) unstable; urgency=medium . * Ack bogs fixed in this and previous releases: Closes: #1022255, #1004869, #1023222 Checksums-Sha1: 25bfc4ad68c46f9f7428c7a008736478f3bd2fa7 3395 python-xarray_2022.11.0-2.dsc 9d5fa48523ea38b6684f9b18e3d3a10a8aee2875 14092 python-xarray_2022.11.0-2.debian.tar.xz Checksums-Sha256: 2921fcf4d7b5b82ed54813180ceacb2261264e99eb22e1b9bcf11e8660755e6e 3395 python-xarray_2022.11.0-2.dsc c480af287094772516773b559ac385d6eed33001e1ded8aa1ddab4db721fc91b 14092 python-xarray_2022.11.0-2.debian.tar.xz Files: 16ee7843761bf700d78213b6a8061f38 3395 python optional python-xarray_2022.11.0-2.dsc b483b08efbb572a27c4af434d3df17d1 14092 python optional python-xarray_2022.11.0-2.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEgjg86RZbNHx4cIGiy+a7Tl2a06UFAmN7jiUACgkQy+a7Tl2a 06Vb0Q//YmFju6NG15oqqygNRQiiGIGPXS+qvtwPbXKGJDq6g3rX24KdF2tP77i6 Aw9LjfskclEe7TRQCwaS/49qh+6CE+Tndv47nMGb3jnBGL0vYa9YqOn3XeBAHCcw aYCvbkks5HxDWizJ6Kh2Ohef0okEl2Q/pHDKMDfF+Q8DEvGh7iFtedVF6ARquPSW 95u3V6QhCCQPws26cYPz1L2a+QJuEf49lohoVDC8u4EtaJHbv1NKXtQP1srEqf10 zqbSd6KDqT3mn4dONtF7etxzQGxSHRySEPJpXQ+2kkdmcueLUT5UAEazC6SCdCUB GMCqMFbwi4kY7CaaK5646XxCm3QQUg3UeZAMHqsBI9gYModfKG8twRhlyA4N9mam Unfortunately version 2022.11.2 and 2022.12.0 of xarray still causes test failures in satpy. According to the satpy upstream developers [1] (also reported in one of the previous messages [2]), the problem should be related to some kind of incompatibility between new versions of xarray and the version of dask currently in Debian (2022.02.0). I can confirm that updating dask to 2022.11.1 fixes the issues and satpy tests pass with dask 2022.11.1 and xarray 2022.12.0. I have started preparing a Merge Request [3] to update the dask package. Unfortunately, while the Python package itself builds and works well, it is currently not possible to build the -doc package because of outdated build dependencies or new build dependencies still not in debian. In addition, there are some other test failures in satpy that are not related to xarray/dask and could be fixed with an update to the latest upstream version of satpy (0.38.0). I have the packaging work done (locally), but I cannot upload until the problem with xarray/dask is solved. In conclusion the satpy version currently in testing works perfectly with xarray 2022.06.0, but the migration of xarray 2022.12.0 would break satpy and make it unbuildable both in testing and unstable. Honestly I'm not sure about what is the best way to proceed. In principle I think that this issue should be re-open and xarray 2022.12.0 should not migrate, for the moment at least. But then the way forward is not clear to me. Waiting for an update of dask could take some time. Of course I would be more that happy to help to prepare a new version of the dask package. What is your idea about how to proceed? [1] https://github.com/pytroll/satpy/issues/2248#issuecomment-1296325915 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022255#16 [3] https://salsa.debian.org/python-team/packages/dask/-/merge_requests/1 kind regards -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1025890: RM: flang -- ROM; replaced by flang from llvm-toolchain
Package: ftp.debian.org Severity: normal Please remove flang from unstable (libflang-dev in particular) as flang is to be build directly from llvm-toolchain
Bug#1024859: change in the extention importation with 3.11
On 06/12/2022 16:13, PICCA Frederic-Emmanuel wrote: There is a fix from the upstream around enum. https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 Fix enum_type_object type on Python 3.11 The enum_type_object type inherits from PyLong_Type which is not tracked by the GC. Instances doesn't have to be tracked by the GC: remove the Py_TPFLAGS_HAVE_GC flag. The Python C API documentation says: "To create a container type, the tp_flags field of the type object must include the Py_TPFLAGS_HAVE_GC and provide an implementation of the tp_traverse handler." https://docs.python.org/dev/c-api/gcsupport.html The new exception was introduced in Python 3.11 by: python/cpython#88429 an opinion ? I'd favour that being added to boost1.74. It would fix my ecflow bug (#1024911). A minor (?) fix also needed for Swig wrapping too (#1024555) -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024555: Fwd: swig4.0 bug causes FTBFS of XDMF
clone 1023911 -1 reassign -1 swig thanks As of the latest swig4.1.0 , Xdmf FTBFS due to bad code being generated. Some elements such as SWIGPY_SLICEOBJECT are not defined. Adding """ %include """ to /usr/share/swig4.0/python/python.swg fixes this. This is currently a blocker for the python3.11 transition. Best regards Alastair McKinstry -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024911: change in the extention importation with 3.11
On 06/12/2022 13:47, picca wrote:
Hello, I am trying to fix this bug
I'm debugging something similar,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024911
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024859
I find the error message not very informative...
:~/$ 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.
import scitbx_linalg_ext
Traceback (most recent call last):
File "", line 1, in
SystemError: initialization of scitbx_linalg_ext raised unreported
exception
The problem is that python is catching a C/C++ exception.
You can debug with:
gdb /usr/bin/python3.11
...
(gdb) catch throw
(gdb) run
>> import scitbx_linalg_ext
...
I would like your opinion and some help in order to fix this or at
least understand what is going on.
ther extension was build with boost_python, maybe something is wrong
also with boost_python and Python3.11.
I do not know if other packages using boost_python are affected like
this.
thanks for considering
Frederic
Both cctbx and ecflow are breaking on generating new enums.
A simple test case is:
```
#include
using namespace boost::python;
// enum has flags 0x42000, no traversefunction set
class CheckPt {
public:
/// NEVER - the check pt file is never saved
/// ON_TIME - the check pt file is saved periodically. specified by
checkPtInterval.
/// ALWAYS - the check pt file is saved after any state change
/// UNDEFINED - Internal use only
enum Mode { NEVER, ON_TIME, ALWAYS, UNDEFINED};
};
void inc_enum () {
enum_("CheckPt",
"CheckPt is enum that is used to control check pointing in
the `ecflow_server`_\n\n"
"- NEVER : Switches of check pointing\n"
"- ON_TIME: `check point`_ file is saved periodically,
specified by checkPtInterval. This is the default.\n"
"- ALWAYS : `check point`_ file is saved after any state
change, *not* recommended for large definitions\n"
"- UNDEFINED : None of the the above, used to provide
default argument\n"
)
.value("NEVER", CheckPt::NEVER)
.value("ON_TIME",CheckPt::ON_TIME)
.value("ALWAYS", CheckPt::ALWAYS)
.value("UNDEFINED", CheckPt::UNDEFINED)
;
}
char const *greet()
{
return "Hello world\n";
}
BOOST_PYTHON_MODULE(wrapper)
{
def ("greet", greet);
inc_enum();
}
```
What appears to be happening is a change in python3.11:
https://docs.python.org/ja/3.11/whatsnew/3.11.html
The PyType_Ready() function now raises an error if a type is
defined with the Py_TPFLAGS_HAVE_GC flag set but has no traverse
function (PyTypeObject.tp_traverse). (Contributed by Victor
Stinner in bpo-44263.)
and indeed, the enum types are created without a traverse function but
with the HAVE_GC flag set.
It doesn't at first glance look like the code for boost1.80 is different.
A Python/boost expert is now needed.
Regards
Alastair McKinstry
mckins...@debian.org
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024551: ITP: fiat -- Fortran IFS and Arpege Toolkit
On 21/11/2022 11:28, Drew Parsons wrote: On 2022-11-21 10:10, Alastair McKinstry wrote: Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name : fiat Version : 1.0.0 Upstream Author : ECMWF * URL : https://github.com/ecmwf-ifs/fiat * License : Apache Programming Lang: C, Fortran Description : Fortran IFS and Arpege Toolkit FIAT is a collection of selected Fortran utility libraries, extracted from the IFS/Arpege model used at ECMWF. It provides: drhook : tracing gstats : timing parkind : choose precision mpl : MPI communication mpi_serial: MPI dummy symbols compiled into static library other various routines . ECMWF is the European Centre for Medium-Range Weather Forecasts. FIAT is a new dependency of the atlas-ecmwf library already in Debian, as ECMWF is open-sourcing its stack. Hi Alastair, note that namespace FIAT is occupied by the python package python3-fiat (src:fiat), used by python3-ffc and related FEniCS/Dolfin packages (python3-dolfin etc). We could consider moving FEniCS FIAT to src:fenics-fiat, but perhaps that is administrative overkill. On the other hand I did do that for other FEniCS components for the next generation fenicsx. I didn't change the source package name for components of old fenics on the grounds that they are in a sense deprecated and could be removed in the future. Removal would be in the far future though, since some groups are still using old fenics for calculations. To complicate the point further, while the new fenicsx library no longer uses FEniCS FIAT, it is being developed further by the firedrake project at https://github.com/firedrakeproject/fiat (Debian has not packaged firedrake itself yet). Alternatively your FIAT could be src:ecmwf-fiat. Which naming solution looks best for you? Drew Hi Drew Thanks. I hadn't spotted that with "apt-cache search fiat" missing src:fiat. My preference is for "fiat-ecmwf", as there is a consistency with "atlas-ecmwf" and "silo-llnl" Best regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1024552: ITP: ectrans -- Spherical Harmonics Transforms library
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: ectrans Version : 1.1.0 Upstream Author : ECMWF * URL : https://github.com/ecmwf-ifs/trans * License : Apache Programming Lang: C,C++, Fortran Description : Spherical Harmonics Transforms library ecTrans is the global spherical Harmonics transforms library, extracted from the IFS weather model from ECMWF. It uses a hybrid of MPI and OpenMP parallelisation strategies. The package contains both single- and double precision Fortran libraries (trans_sp, trans_dp), as well as a C interface to the double-precision version (transi_dp) ECMWF is the European Centre for Medium-Range Weather Forecasts. ecTrans is a new dependency of the ECMWF atlas-ecmwf library already present in Debian, as ECMWF open-source their stack.
Bug#1024551: ITP: fiat -- Fortran IFS and Arpege Toolkit
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org * Package name: fiat Version : 1.0.0 Upstream Author : ECMWF * URL : https://github.com/ecmwf-ifs/fiat * License : Apache Programming Lang: C, Fortran Description : Fortran IFS and Arpege Toolkit FIAT is a collection of selected Fortran utility libraries, extracted from the IFS/Arpege model used at ECMWF. It provides: drhook : tracing gstats : timing parkind : choose precision mpl : MPI communication mpi_serial: MPI dummy symbols compiled into static library other various routines . ECMWF is the European Centre for Medium-Range Weather Forecasts. FIAT is a new dependency of the atlas-ecmwf library already in Debian, as ECMWF is open-sourcing its stack.
Bug#884648: Bug still current in bullseye
I have not been successful in finding a specific upstream bug. Here is my stack trace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f3936329ac4 in gtk_drag_finish () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #1 0x7f3936329f0e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #2 0x7f393632a159 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #3 0x7f3935e8ddd9 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #4 0x7f39359648f4 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7f3935963d6f in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7f3935964118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x7f393596440b in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x7f39361afa65 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #9 0x55aba742ea51 in main () Any help in further diagnosis would be appreciated.
Bug#1021603: libpmix2
It appears that openmpi needs to be rebuilt with the latest pmix. This works locally for me, but an attempt to do so (on the autobuilds) was blocked by a separate bug in pmix. Will retry Alastair On 16/10/2022 23:23, Ron Lovell wrote: Should have said Arch Linux Issue 75727. On Sun, Oct 16, 2022 at 5:20 PM Ron Lovell wrote: Same issue as Arch issue 279267? -- James Ronald Lovell Huntsville, AL, USA -- James Ronald Lovell Huntsville, AL, USA -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e:alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1021603: libpmix2: mca_base_component_repository_open: unable to open mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored)
This appears to be fixed locally for me by rebuilding openmpi against the latest pmix. I'm doing a rebuild now Alastair On 11/10/2022 16:50, Andreas Beckmann wrote: Package: libpmix2 Version: 4.2.1-2 Severity: serious Hi, the new pmix version in sid causes autopkgtest regressions, e.g. https://ci.debian.net/data/autopkgtest/testing/amd64/o/openmpi/26943322/log.gz autopkgtest [01:13:33]: test check_shared_objs: [--- [ci-284-796c5454:01766] mca_base_component_repository_open: unable to open mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored) autopkgtest [01:13:34]: test check_shared_objs: ---] autopkgtest [01:13:34]: test check_shared_objs: - - - - - - - - - - results - - - - - - - - - - check_shared_objsFAIL non-zero exit status 1 I see similar errors when rebuilding src:p4est while the tests are running. This works fine with the version in testing. Andreas -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support
Hi, As maintainer would be open to changing Glew to EGL support, but need to understand better the consequences. I have a test build of glew with egl (for Linux, not hurd or freebsd yet) and it builds fine. Any pointers to docs on EGL/non-EGL builds, or opinions and evidence would be welcome. Alastair On 03/10/2022 03:42, Olly Betts wrote: On Sat, Sep 24, 2022 at 09:50:10PM +0100, Olly Betts wrote: On Sat, Sep 24, 2022 at 06:09:31PM +0200, Andreas Metzler wrote: wxwidgets and glew disagree over EGL support, glew is built without, wxwidgets (since 3.2) with. That causes problems (crashes, "Unable to init glew library") in software using glew and wxwidgets. Google finds multiple instances, I know about hugin. FWIW, these are the packages which seem to depend on both wx and glew (just based on checking dependencies): hugin megaglest qutemol scorched3d darkradiant limesuite The last two have already switched to wx3.2 in unstable and testing, but I don't see reports in the BTS of glew-related problems, and didn't see any issues from a quick test myself. At least with darkradiant I did get what looked like a GL rendered pane to appear - I'm not sure I actually exercised any GL code with limesuite (it seems to need some hardware I don't have to be useful). Cheers, Olly -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@sceal.ie, im: @sceal.ie:mckinstry
Bug#1017727: autoconf-archive: ax_cc_maxopt.m4 change breaks code due to syntax error
Package: autoconf-archive Version: 20220211-1 Severity: serious Tags: patch Justification: Policy 4.6 m4/ax_cc_maxopt.m4 has a syntax error that causes silo-llnl to FTBFS. See #1017240. The following patch fixes it: --- ax_cc_maxopt.m4.orig2022-08-19 16:13:36.230050352 +0100 +++ ax_cc_maxopt.m4 2022-08-19 16:13:47.994113092 +0100 @@ -146,6 +146,7 @@ nvhpc) # default optimization flags for nvhpc CFLAGS="$CFLAGS -O3" +;; gnu) # default optimization flags for gcc on all systems thanks Alastair -- System Information: Debian Release: 11.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-16-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages autoconf-archive depends on: ii dpkg 1.20.11 Versions of packages autoconf-archive recommends: ii autoconf 2.69-14 autoconf-archive suggests no packages. -- no debconf information
Bug#1011751: ecmwflibs: versions() uses hard-coded values
Package: ecmwflibs Version: 0.4.16 Severity: normal This package has several problems: credits() uses a file that is not shipped with the package versions() uses hard-coded values (at compile-time) not the Debian releases -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1010601: transition: g2clib
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-scie...@lists.debian.org After much ambiguity upstream have changed the name of a library from libgrib2c to libg2c in version 1.6.4 (!) So, the dev file is changing libgrib2c-dev -> libg2c-dev and library from libgrib2c0d to libg2c0d There are 3 dependencies: grads, ncl, pygrib which trivially build when the B-D is changed to libg2c-dev | libgrib2c-dev I maintain all 3 dependencies and have uploads ready to go. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: title = "g2clib"; is_affected = .depends ~ "libgrib2c-dev" | .depends ~ "libg2c-dev"; is_good = .depends ~ "libg2c-dev"; is_bad = .depends ~ "libgrib2c-dev";
Bug#980107: python-rioxarray
Hi Antonio and Magnus Thanks, I've uploaded this to the new queue. Best regards Alastair On 25/04/2022 16:20, Magnus HAGDORN wrote: Hi Antonio, thanks for updating the package. I have built and uploaded the package to debian mentors: https://mentors.debian.net/package/python-rioxarray/ but we will need a sponsor to upload the package to the new queue. Regards magnus On Sat, 2022-04-23 at 16:20 +0200, Antonio Valentino wrote: This email was sent to you by someone outside the University. You should only click on links or attachments if you are certain that the email is genuine and the content is safe. Dear Magnus and Alastair, I have recently pushed to the salsa repository a new upstream version of the rioxarray package (v0.11.1). I would really like to have this package in debian. If you are still interested in this package please go ahead with the upload into the new queue. I you are no longer interested or do not have time to dedicate, please let me know and I will try to find another sponsor for the first upload. Of course I will take in charge also the maintenance. kind regards antonio On Fri, 5 Nov 2021 07:44:10 +0100 Antonio Valentino wrote: Dear Alastair and Magnus, yesterday I have pushed on the salsa repository an updated version of the rioxarray package including the latest upstream version 0.8.0. Please consider it for your review and upload. kind regards antonio Il 02/10/21 17:08, Antonio Valentino ha scritto: Thank Magnus, all branches and tags have been pushed now. Now the package is ready for a review. kind regards antonio Il 02/10/21 16:34, Magnus HAGDORN ha scritto: Hi Antionio, Excellent. I am very happy for you to push directly to the repo. magnus On Sat, 2021-10-02 at 09:48 +0200, Antonio Valentino wrote: This email was sent to you by someone outside the University. You should only click on links or attachments if you are certain that the email is genuine and the content is safe. Dear Alastair and Magnus, I have update the package on my fork [1]. I have temporary removed the -doc package because it not buildable at the moment due to #995299 [2]. We can re-add the -doc package in a future version if necessary. I have also updated the package to the latest upstream version 0.7.1. @Magnus please let me know if you prefer me to push directly on the debian-science repository or to submit a merge request. [1] https://salsa.debian.org/antonio.valentino/python-rioxarray [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995299 kind regards Antonio Il 27/09/21 11:59, Alastair McKinstry ha scritto: Hi Magnus I downloaded and reviewed the package. As it currently stands it needs some work to deal with privacy issues (The lintian tests). Basically sphinxdocs is adding links to cloudflare etc that leak user information. You can look at "python-xarray" to see some solutions - some can be fixed with a patch to the sphinxdocs configuration, some needs editing of the html files in debian/rules to use javascript helpers that you -- Antonio Valentino The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336. -- Alastair McKinstry, mckins...@debian.org matrix: @sceal.ie:mckinstry GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
Bug#1004556: libmpich-dev: The simplest MPI program compiled with mpich crashes
I can disable pmix support in mpich. Pmix is working fine in openmpi, so it’s an mpich/pmix issue of some sort (or maybe ch4) Regards Alastair On 22/02/2022, 14:57, "debian-science-maintainers on behalf of Drew Parsons" wrote: Package: mpich Followup-For: Bug #1004556 My guess is that this bug is ongoing in 4.0-2 because of pmix support. 4.0-2 is still configured --with-pmix=/usr/lib/x86_64-linux-gnu/pmix2 and still Depends: libpmix2 (>= 4.1.2) pmix support was added in 4.0~b1-2 along with ucx. I gather ucx was deactivated in 4.0-2 but pmix was not. Looks like pmix also needs to go (unless the problem is ch4, which was also added in 4.0~b1-2). But the error message references PMIX. Ironically, I find that an executable compiled against mpich 4.0-1 fails with mpiexec.mpich (as raised in this bug) but actually passes when run with mpiexec.openmpi. Awkward. -- debian-science-maintainers mailing list debian-science-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1001464: paraview: enable web support
Hi Christophe Yes, I'll test this on the next release (post GDAL transition) Regards Alastair On 10/12/2021, 13:18, "debian-science-maintainers on behalf of Christophe Trophime" wrote: Package: paraview Version: 5.10.0~rc1-1 Severity: wishlist Dear Maintainer, Could you please enable web support by simply changing DPARAVIEW_ENABLE_WEB to ON in d/rules? I would like to use pywebvue with paraview. Best -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages paraview depends on: ii libavcodec58 7:4.4.1-2+b1 ii libavformat58 7:4.4.1-2+b1 ii libavutil567:4.4.1-2+b1 ii libc6 2.32-5 ii libdouble-conversion3 3.1.5-7 ii libexpat1 2.4.1-3 ii libfreetype6 2.11.0+dfsg-1 ii libgcc-s1 11.2.0-12 ii libgdal29 3.3.3+dfsg-2 ii libgl2ps1.41.4.2+dfsg1-2 ii libglew2.2 2.2.0-4 ii libglx01.3.4-2+b1 ii libhdf5-103-1 1.10.7+repack-4 ii libjpeg62-turbo1:2.1.2-1 ii liblz4-1 1.9.3-2 ii liblzma5 5.2.5-2 ii libnetcdf191:4.8.1-1 ii libopengl0 1.3.4-2+b1 ii libopenmpi34.1.2-1 ii libpdal-base13 2.3.0+ds-2+b1 ii libpng16-161.6.37-3 ii libpython3.9 3.9.9-1 ii libqt5core5a 5.15.2+dfsg-14 ii libqt5gui5 5.15.2+dfsg-14 ii libqt5help55.15.2-5+b1 ii libqt5network5 5.15.2+dfsg-14 ii libqt5widgets5 5.15.2+dfsg-14 ii libstdc++6 11.2.0-12 ii libswscale57:4.4.1-2+b1 ii libtiff5 4.3.0-2 ii libx11-6 2:1.7.2-2+b1 ii libxcursor11:1.2.0-2 ii libxml22.9.12+dfsg-5+b1 ii python3-autobahn 17.10.1+dfsg1-7 ii python3-matplotlib 3.3.4-2 ii python3-mpi4py 3.1.2-2 ii python3-six1.16.0-2 ii python3-twisted20.3.0-7 ii tcl [tclsh]8.6.11+1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages paraview recommends: ii mpi-default-bin 1.14 pn paraview-doc ii python3-paraview [python3-paraview] 5.10.0~rc1-1 Versions of packages paraview suggests: pn h5utils ii hdf5-tools 1.10.7+repack-4 -- no debconf information -- debian-science-maintainers mailing list debian-science-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1000691: RM: cylc -- ROM; replaced by cylc-flow
Package: ftp.debian.org Severity: normal This package (cylc) is being split upstream into two source packages - cylc-flow and cylc-ui. The original cylc is now replaced by cylc-flow, now present in unstable/testing. Please remove the cylc source package and binaries
Bug#998682: libgetdata: b-d on python3-all-dev, but not built for all supported Python3 versions
Hi Investigating locally this fails because numpy does not yet support python3.10. Some form of tracking is needed as I think multiple packages are in this situation, and the ben tracker in transitions.debian.org is incomplete. Regards Alastair On 06/11/2021, 08:36, "debian-science-maintainers on behalf of Graham Inggs" wrote: Source: libgetdata Version: 0.10.0-11 Severity: important Tags: ftbfs User: debian-pyt...@lists.debian.org Usertags: python3.10 python3-all-dev Hi Maintainer This package build-depends on python3-all-dev, but does not build extensions/libraries for all supported python3 versions. This is seen on the transition tracker for adding python3.10 support [1] and creates false positives. Please either replace the b-d python3-all-dev with python3-dev, or build for all supported Python3 versions. With the former solution you get later exposure to a new python3 version, with the latter solution you get early exposure. Regards Graham [1] https://release.debian.org/transitions/html/python3.10-add.html -- debian-science-maintainers mailing list debian-science-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#997796: unicode-data: Missing emoji-data.txt since 14.0.0-1
Hi Nilesh A build is in the NEW queue to fix this, Regards Alastair From: Nilesh Patra Reply to: Nilesh Patra , <997...@bugs.debian.org> Date: Tuesday 2 November 2021 at 09:48 To: Alastair McKinstry Cc: <997...@bugs.debian.org> Subject: Bug#997796: unicode-data: Missing emoji-data.txt since 14.0.0-1 Resent from: Nilesh Patra Resent to: Resent date: Tue, 02 Nov 2021 11:48:02 + Hi Alastair, > Since 14.0.0-1, emoji-data.txt file is no longer available. > This causes src:golang-github-mattn-go-runewidth FTBFS, since it needs this > file to generate emoji related information. > This file is in UCD.zip, so please include it. This is now triggering removals of a number of packages. Could you please include the emoji-data.txt file to fix this? Humble request. Kind Regards, Nilesh
Bug#997997: transition: netcdf-parallel
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-scie...@lists.debian.org Hi dear release team, I request permission to undetake the netcdf-parallel transition. netcdf-parallell is the parallel build(s) of netcdf; netcdf 4.8.1 is now in testing, and nertcdf-parallel 4.8.1 builds successfully in experimental. This is a mini-transition; the packages depending on netcdf-parallel are: netcdf-parallel adios exodusii I maintain all three, and adios and exodusii build against netcdf-parallel-4.8.1 successfully. There are uploads of adios and exodusii ready. Ben file: title = "netcdf-parallel"; is_affected = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)" | .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)"; is_good = .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)"; is_bad = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)";
Bug#996642: FTBFS with glibc 2.32
Hi Nilesh Just uploaded a patched csh now. Apologies I was trying to port a later snapshot of csh but ran into porting issues. Regards Alastair From: Nilesh Patra Date: Monday 25 October 2021 at 11:17 To: <996...@bugs.debian.org> Cc: Alastair McKinstry Subject: Re: csh: FTBFS with glibc 2.32 (Resending with a different email, since my earlier mail bounced back, because of your DNS seeing it with invalid SPF) Hi Alastair, On Sat, 16 Oct 2021 18:47:48 +0200 Graham Inggs wrote: > Source: csh > Version: 20110502-6 > Severity: serious > Tags: ftbfs patch bookworm sid > > Hi Maintainer > > As can be seen in reproducible builds [1], csh FTBFS since glibc 2.32 > was uploaded. > I've attached a patch from Ubuntu where this was fixed already. Can you please upload this with Graham's patch? Since this is triggering a huge number of (warnings for) autoremovals Nilesh
Bug#993624: RM: eckit [armel i386 armhf mipsel] -- ROM; 32-bit archs no longer supported
On 13/10/2021 16:25, Sebastiaan Couwenberg wrote: On 10/13/21 5:15 PM, Alastair McKinstry wrote: I've updated fdb, odc, metkit and fckit to also remove 32-bit packages That doesn't not get the old binary packages removed from the archive, RM bugreports for those will be required too. Kind Regards, Bas RM bugreports submitted on all relevant packages. Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#996458: RM: fdb [i386 armel armhf mipsel] -- ROM; Dependency eckit no longer supports 32-bit archs
Package: ftp.debian.org Severity: normal Dependency eckit no longer supports 32-bit archs
Bug#996457: RM: metkit [armel armhf mipsel i386] -- ROM; Dependency eckit no longer supports 32-bit archs
Package: ftp.debian.org Severity: normal Dependency eckit no longer supports 32-bit archs
Bug#996456: RM: odc [i386 mipsel armhf armel] -- ROM; Dependency eckit no longer supports 32-bit archs
Package: ftp.debian.org Severity: normal Dependency eckit no longer supports 32-bit archs
Bug#996454: RM: fckit [armel armhrf i386 mipsel] -- ROM; Dependency eckit no longer supports 32-bit archs
Package: ftp.debian.org Severity: normal fckit is a Fortran wrapper for a package eckit that no longer supports 32-bit archs. The latest build no longer tries to build on 32-bit archs, but existing binaries remain.
Bug#993624: RM: eckit [armel i386 armhf mipsel] -- ROM; 32-bit archs no longer supported
I've updated fdb, odc, metkit and fckit to also remove 32-bit packages (metview was already 64-bit only) Alastair On 10/10/2021 09:08, Sebastiaan Couwenberg wrote: On Fri, 03 Sep 2021 20:50:51 +0100 Alastair McKinstry wrote: Please remove the 32-bit archs - they are no longer supported upstream Looks like this cannot happen until at least fckit & metkit are also removed from these architectures: $ dak rm -Rn -b -a armel,i386,armhf,mipsel \ eckit libeckit-dev libeckit-utils libeckit0d W: -a/--architecture implies -p/--partial. Will remove the following packages from unstable: libeckit-dev | 1.16.3-1 | armel, armhf, i386, mipsel libeckit-utils | 1.16.3-1 | armel, armhf, i386, mipsel libeckit0d | 1.16.3-1 | armel, armhf, i386, mipsel Maintainer: Alastair McKinstry --- Reason --- -- Checking reverse dependencies... # Broken Depends: fckit: libfckit0d metkit: libmetkit-dev libmetkit-utils libmetkit0d # Broken Build-Depends: atlas-ecmwf: libeckit-dev (>= 1.4.7-7) fckit: libeckit-dev (>= 1.15.4-1~) fdb: libeckit-dev metkit: libeckit-dev (>= 1.16.0-1~) metview: libeckit-dev (>= 1.10.1~) odc: libeckit-dev (>= 1.16.0-1~) Dependency problem found. Kind Regards, Bas -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#995662: info-beamer: Please change build-depends to libglew-dev
Package: info-beamer Followup-For: Bug #995662 As part of the glew transition, libglew1.5-dev is going away, while building against libglew-dev works. Please update the build-depends accordingly. Thanks Alastair -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages info-beamer depends on: ii libavcodec587:4.3.2-0+deb11u2 ii libavformat58 7:4.3.2-0+deb11u2 ii libavutil56 7:4.3.2-0+deb11u2 ii libc6 2.31-13 pn libdevil1c2 ii libevent-2.1-7 2.1.12-stable-1 pn libftgl2 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 pn libglfw3 ii libglu1-mesa [libglu1] 9.0.1-1 ii liblua5.1-0 5.1.5-8.1+b3 ii libswscale5 7:4.3.2-0+deb11u2 info-beamer recommends no packages. info-beamer suggests no packages.
Bug#995700: phlipple: Please update the build-depends to libglew-dev
Package: phlipple Severity: normal As part of the glew transition, libglew1.5-dev is going away, while building against libglew-dev works. Please update the build-depends accordingly. Thanks Alastair -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#995698: rlvm: Please update the build-depends to libglew-dev
Package: rlvm Severity: normal As part of the glew transition, libglew1.5-dev is going away, while building against libglew-dev works. Please update the build-depends accordingly. Thanks Alastair -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rlvm depends on: pn fonts-vlgothic | fonts-japanese-gothic pn libboost-filesystem1.74.0 ii libboost-iostreams1.74.01.74.0-9 pn libboost-program-options1.74.0 pn libboost-serialization1.74.0 ii libc6 2.31-13 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libglib2.0-02.66.8-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgtk2.0-0 2.24.33-2 pn libguichan-0.8.1-1v5 pn libguichan-opengl-0.8.1-1v5 pn libguichan-sdl-0.8.1-1v5 ii libjpeg62-turbo 1:2.0.6-4 ii libpng16-16 1.6.37-3 pn libsdl-image1.2 pn libsdl-mixer1.2 pn libsdl-ttf2.0-0 pn libsdl1.2debian ii libstdc++6 10.2.1-6 ii libvorbisfile3 1.3.7-1 rlvm recommends no packages. Versions of packages rlvm suggests: ii ttf-dejavu-core 2.37-1
Bug#995699: pymol: Please update the build-depends to libglew-dev
Package: pymol Severity: normal As part of the glew transition, libglew1.5-dev is going away, while building against libglew-dev works. Please update the build-depends accordingly. Thanks Alastair -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pymol depends on: pn python3-pymol Versions of packages pymol recommends: pn apbs pymol suggests no packages.
Bug#995441: ITP: pyodc -- A Python interface to `odc` for encoding/decoding ODB-2 files
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pyodc Version : 1.1.0 Upstream Author : European Centre for Medium-range Forecasts (ECMWF) * URL : https://github.com/ecmwf/pyodc * License : Apache-2 Programming Lang: Python Description : A Python interface to `odc` for encoding/decoding ODB-2 files This is a Python interface to ODC, a package already in Debian, for handling ODB-2 (weather observation) files. I will maintain this within the Debian Science team, alongside its sister packages for GRIB and BUFR formats
Bug#995293: ITP: cylc-flow -- rename of upstream source - splitting package
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: cylc-flow Version : 8.0 Upstream Author : NIWA * URL : http://cylc.github.io/cylc * License : GPL-3 Programming Lang: Python Description : rename of upstream source - splitting package This is a workflow manager used in the weather and climate community. Cylc 7.0+ is already in Debian, but is being split into several upstream componets - cylc-ui, cylc-uiserver and cylc-flow. cylc-flow is a binary package in the current cylc. I intend to replace cylc source package with cylc-flow and add the cylc-ui* source packages.
Bug#994086: transition: netcdf
The ncl FTBFS (#993992) is fixed in the last upload. On 29/09/2021 09:02, Sebastian Ramacher wrote: Control: tags -1 confirmed On 2021-09-11 13:06:27 +0200, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-netcdf.html Control: block -1 by 994003 991057 993992 The SONAME for NetCDF was bumped in 4.8.0 requiring a transition. Most rdeps built successfully, exception grace, gri, and ncl which FTBFS for unrelated reasons. Transition: netcdf libnetcdf18 (1:4.7.4-1) -> libnetcdf19 (1:4.8.1-1~exp1) The status of the most recent rebuilds is as follows. adios (1.13.1-28.2) OK cmor (3.6.1-1) OK coda (2.22.1-1)OK dx (1:4.4.4-13) OK eccodes(2.23.0-1)OK exodusii (6.02.dfsg.1-8) OK gdal (3.3.2+dfsg-1)OK gerris (20131206+dfsg-19)OK grace (1:5.1.25-9) FTBFS (#994003) grads (3:2.2.1-4) OK gri(2.12.27-1) FTBFS (#991057) kst(2.0.8-4) OK labplot(2.8.2-1) OK libminc(2.4.03-3)OK libpdl-netcdf-perl (4.22-2) OK nco(5.0.1-1) OK ncview (2.1.8+ds-4) OK netcdf-cxx (4.3.1-3) OK netcdf-cxx-legacy (4.2-12) OK netcdf-fortran (4.5.3+ds-2) OK netcdf4-python (1.5.7-1) OK octave-netcdf (1.0.14-1)OK pymol (2.4.0+dfsg-2)OK r-cran-ncdf4 (1.17-2) OK r-cran-rnetcdf (2.5-2-1) OK ruby-netcdf(0.7.2-5) OK v-sim (3.7.2-8) OK abinit (9.2.2-1) OK cdftools (3.0.2-4) OK emoslib(2:4.5.9-7) OK etsf-io(1.0.4-5) OK ferret-vis (7.6.0-2) OK gmt(6.2.0+dfsg-1)OK gnudatalanguage(1.0.0-4) OK grass (7.8.5-2) OK harp (1.13-1) OK metkit (1.8.4-1) OK minc-tools (2.3.00+dfsg-6) OK ncl(6.6.2-8) FTBFS (#993992) oasis3 (3.mct+dfsg.121022-15)OK paraview (5.9.0-2) OK python-escript (5.6-3) OK vtk6 (6.3.0+dfsg2-8.1) OK vtk7 (7.1.1+dfsg2-10) OK vtk9 (9.0.1+dfsg1-8) OK lammps (20210122~gita77bb+ds1-2) OK magics++ (4.9.0-1) OK pyferret (7.6.3-3) OK qgis (3.16.10+dfsg-1) OK cdo(2.0.0~rc5-1) OK metview(5.13.0-1)OK Please go ahead Cheers Kind Regards, Bas -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#995055: transition: glew
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-de...@lists.debian.org This transition is triggered by an SONAME change upstream. It does not appear to have any API transition though, and seems to cause no glew-related failures. Ben file: title = "glew"; is_affected = .depends ~ "libglew2.1" | .depends ~ "libglew2.2"; is_good = .depends ~ "libglew2.2"; is_bad = .depends ~ "libglew2.1"; I've rebuilt all dependencies, with a number of unrelated FTBFS: Bugs have been submitted against all FTBFS. glew OK info-beamer : : change bd libglew1.5-dev -> libglew-dev OK phlipple: change bd libglew1.5-dev -> libglew-dev OK pymol: change bd libglew1.5-dev -> libglew-dev OK rlvm: change bd libglew1.5-dev -> libglew-dev OK asymptote: OK avogarolibs: OK ball: FTBFS (#994480) unrelated (glibc/ rpc header change) bino: OK blastem: OK blender: OK bzflag: OK casparcg-server (sid only): FTBFS (#947518) colmap: OK colobot: OK compiz-plugins-experimental: OK darkradiant: OK ddnet: OK dreamchess: OK endless-sky: OK fife: OK freeorion: OK frogatto (contrib): OK gambas3: OK gource: OK hugin: OK hyperrogue: OK k3d (sid only): FTBFS (python2 issues) kicad: OK limesuite: OK logstalgia: OK mediastreamer2: (FTFBS with gcc-11), OK megaglest : OK mesa-demos: OK mupen64plus-video-z64: OK mygui: OK open3d: OK openclonk: opencsg: OK openctm: OK openmsx:: OK otb: OK paraview: OK qutemol: OK rbdoom3bfg: OK renpy (sid only):FTBFS - needs python-sphinx rss-glx: OK scorched3d: OK slic3r-prusa OK slop: FTBFS (#994824) unrelated sludge: OK sofa-framework: FTBFS (#875184): QT4 removed spring: OK supertux: OK supertuxkart: OK trigger-rally: OK tulip: OK vice (contrib): FTBFS #994835 (jpeg support missing) vtk7: OK vtk9: OK warzone2100: OK widelands: OK cegui-mk2: OK meshlab; OK openscad: FTBFS (#994937) CGAL-related ? pcl:OK
Bug#994937: openscad: FTBFS ( due to cgal changes ?)
Package: openscad Version: 2021.01-1) Severity: serious Tags: ftbfs openscad now FTBFS: g++ -c -pipe -DSTACKSIZE=8388608 -fno-strict-aliasing -g -O2 -ffile-prefix-map=/build/openscad-2021.01=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++1y -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include -I/usr/include/libxml2 -I/usr/include/lib3mf -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DEIGEN_DONT_ALIGN -frounding-math -D_REENTRANT -Wall -Wextra -Wno-unused-local-typedefs -fPIC -DOPENSCAD_VERSION=2021.01 -DOPENSCAD_SHORTVERSION=2021.01 -DOPENSCAD_YEAR=2021.0 -DOPENSCAD_MONTH=01.0 -DOPENSCAD_DAY=.0 -DSTACKSIZE=8388608 -DUSE_QOPENGLWIDGET -DENABLE_DBUS -DENABLE_JOYSTICK -DENABLE_QGAMEPAD -DENABLE_CAIRO -DENABLE_SPNAV -DENABLE_LIBZIP -DENABLE_LIB3MF -DENABLE_OPENCSG -DENABLE_CGAL -DCGAL_HEADER_ONLY -DUSE_SCINTILLA_EDITOR -DQSCINTILLA_DLL -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_GAMEPAD_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_NETWORK_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -Isrc -Isrc/ext/libtess2/Include -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtMultimedia -I/usr/include/x86_64-linux-gnu/qt5/QtGamepad -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtConcurrent -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork -I/usr/include/x86_64-linux-gnu/qt5/QtDBus -I/usr/include/x86_64-linux-gnu/qt5/QtCore -Iobjects -I/usr/include/eigen3 -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o objects/src/cgalutils-polyhedron.o src/cgalutils-polyhedron.cc src/cgalutils-polyhedron.cc: In instantiation of 'std::string CGALUtils::printPolyhedron(const Polyhedron&) [with Polyhedron = CGAL::Polyhedron_3 >; std::string = std::__cxx11::basic_string]': src/cgalutils-polyhedron.cc:351:63: required from here src/cgalutils-polyhedron.cc:346:29: error: 'generic_print_polyhedron' was not declared in this scope 346 | generic_print_polyhedron(sstream, p, writer); | ^~~~ make[2]: *** [Makefile:5723: objects/src/cgalutils-polyhedron.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/build/openscad-2021.01' dh_auto_build: error: make -j2 returned exit code 2 make[1]: *** [debian/rules:41: override_dh_auto_build] Error 25 make[1]: Leaving directory '/build/openscad-2021.01' make: *** [debian/rules:32: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openscad depends on: pn lib3mf1 pn libboost-filesystem1.74.0 pn libboost-program-options1.74.0 ii libboost-regex1.74.0 [libboost-regex1.74.0-icu67] 1.74.0-9 ii libc6 2.31-13 ii libcairo2 1.16.0-5 ii libdouble-conversion3 3.1.5-6.1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libglib2.0-0 2.66.8-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgmp10 2:6.2.1+dfsg-1 ii libharfbuzz0b 2.7.4-1 ii libmpfr6 4.1.0-3 pn libopencsg1 pn libqscintilla2-qt5-15 pn libqt5core5a pn libqt5dbus5 pn libqt5gamepad5 pn libqt5gui5 | libqt5gui5-gles pn libqt5multimedia5
Bug#994835: vice: Fails to build -- missing JPEG support
Package: vice Version: 3.5.0.dfsg-3 Severity: serious Tags: ftbfs Justification: ftbfs checking for png.h... yes checking for png_sig_cmp in -lpng... yes checking for jpeglib.h... no configure: error: JPEG support is missing make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 1 make[1]: Leaving directory '/build/vice-3.5.0.dfsg' make: *** [debian/rules:60: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 I: copying local configuration Best regards Alastair -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#994824: slop: FTBFS on sid
Package: slop Version: 7.5 Severity: serious Tags: ftbfs Justification: FTBFS This package now Fails to build in unstable: [ 80%] Building CXX object CMakeFiles/slopy.dir/src/glrectangle.cpp.o /usr/bin/c++ -DCXXOPTS_USE_UNICODE -DSLOP_OPENGL=\"True\" -DSLOP_VERSION=\"v7.5\" -Dslopy_EXPORTS -I/build/slop-7.5/obj-x86_64-linux-gnu -g -O2 -ffile-prefix-map=/build/slop-7.5=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -MD -MT CMakeFiles/slopy.dir/src/glrectangle.cpp.o -MF CMakeFiles/slopy.dir/src/glrectangle.cpp.o.d -o CMakeFiles/slopy.dir/src/glrectangle.cpp.o -c /build/slop-7.5/src/glrectangle.cpp /build/slop-7.5/src/framebuffer.cpp: In member function 'void slop::Framebuffer::setShader(slop::Shader*)': /build/slop-7.5/src/framebuffer.cpp:55:9: error: 'XDestroyImage' was not declared in this scope; did you mean 'eglDestroyImage'? 55 | XDestroyImage( image ); | ^ | eglDestroyImage make[3]: *** [CMakeFiles/slopy.dir/build.make:219: CMakeFiles/slopy.dir/src/framebuffer.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory '/build/slop-7.5/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Makefile2:114: CMakeFiles/slopy.dir/all] Error 2 make[2]: Leaving directory '/build/slop-7.5/obj-x86_64-linux-gnu' Best regards Alastair McKinstry -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages slop depends on: ii libc62.31-13 ii libgcc-s110.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libicu67 67.1-7 ii libstdc++6 10.2.1-6 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxrender1 1:0.9.10-1 slop recommends no packages. slop suggests no packages.
Bug#994756: ITP: findlibs -- Trivial python package to find C libraries
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: findlibs Version : 0.0.2 Upstream Author : ECMWF (The European Centre for Medium-Range Weather Forecasts) * URL : https://github.com/ecmwf/findlibs * License : Apache-2 Programming Lang: Python Description : Trivial python package to find C libraries This is a trivial package used to find C libraries. I'm packaging it as it is now a dependency of the ECMWF stack for meteorology libraries (eecodees-python, etc) and hence cfgrib and xarray. I intend to maintain within Debian Science teams.
Bug#994480: ball: FTBFS following glibc change
Package: ball Version: 1.5.0+git20180813.37fc53c-6) Severity: serious Tags: ftbfs Justification: 4 FTBFS The package FTBFS : /srv/build/glew/rebuild/ball-1.5.0+git20180813.37fc53c/include/BALL/CONCEPT/XDRPersistenceManager.h:12:10: fatal error: rpc/types.h: No such file or directory 12 | #include | ^ This is due to a recent change in glibc; these headers are now in libtirpc-dev regards Alastair -- System Information: Debian Release: 11.0 APT prefers master APT policy: (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_IE.UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#993992: i386 regression
The bugs on mips, mips64el were unrelated – a problem with the proj8.patch (headers now conflicting due to proj.h in proj8 conflicting with hdf-eos5). This was resolved in 6.6.2-9. Remaining is a definite regression with gcc, or more correctly gfortran ; testing with gfortran 10.2.1-6 from bullseye works ; regression with 10.3.0-10 (and also 11.2.0-5). The generated “Iftran” compiler created from Iftran.f fails to compile correctly. Alastair
Bug#993631: cfgrib FTBFS: test failures
This is a bug in python3-eccodes which now depends on ecmwflibs. Ecmwflibs in now in the NEW queue On 03/09/2021, 21:51, "Adrian Bunk" wrote: Source: cfgrib Version: 0.9.9.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=cfgrib=0.9.9.0-1
Bug#993624: RM: eckit [armel i386 armhf mipsel] -- ROM; 32-bit archs no longer supported
Package: ftp.debian.org Severity: normal Please remove the 32-bit archs - they are no longer supported upstream
Bug#993581: ITP: ecmwflibs -- A Python package that wraps some of ECMWF libraries to be used by Python interfaces to ECMWF software.
Package: wnpp Severity: wishlist Owner: Alastair McKinstry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ecmwflibs Version : 0.13.3 Upstream Author : European Centre for Medium-Range Forecasts * URL : https://github.com/ecmwf/ecmwflibs * License : Apache 2.0 Programming Lang: Python Description : A Python package that wraps some of ECMWF libraries to be used by Python interfaces to ECMWF software. A Python package that wraps some of ECMWF libraries to be used by Python interfaces to ECMWF software. This is now a dependency of other ECMWF libraries (python3-eccodes, cfgrib) and hence xarray and other python code. I intend to manage this within the Science Team and it is on Salsa already.
Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.
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 ?) On 26/08/2021 10:51, Ole Streicher wrote: 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. -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#992999: ITP: unyt -- Python package for handling numpy arrays with units.
How does this interact with xarray, etc? On 26/08/2021 07:42, Ole Streicher wrote: 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 -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#984956: Pmix issues with openmpi-4.1.0
Ok, openmpi, redone ucx (to avoid 1.10.1~rc1 ) uploaded and unblock sent. Alastair On 16/05/2021, 06:39, "Lucas Nussbaum" wrote: Hi Alaitair, Thanks a lot for fixing this. Unfortunately, I noticed that the upload to unstable was built against ucx 1.10.1~rc1-1, so both need to migrate to testing. Did you already engage discussions with the release team? I did not find an unblock request. Lucas
Bug#984956: Pmix issues with openmpi-4.1.0
Hi Paul To confirm: You mean do an upload of 1.10.0~rc1-7 <https://packages.debian.org/source/testing/ucx> (current testing UCX) as 1.10.1 <https://packages.debian.org/source/unstable/ucx>~rc1.really.1.10.0-1? <https://packages.debian.org/source/unstable/ucx> thanks Alastair On 20/05/2021 16:33, Paul Gevers wrote: Hi Alastair, On Sun, 16 May 2021 07:25:51 +0100 Alastair McKinstry wrote: No, I wanted to wait and check if there were any issues before issuing an unblock request. ucx is not bullseye material, it doesn't comply at all with the release policy. It would be best if ucx is reverted to the previous version (e.g. using an +really version name). And openmpi rebuild after that. On 16/05/2021 06:35, Lucas Nussbaum wrote: Unfortunately, I noticed that the upload to unstable was built against ucx 1.10.1~rc1-1, so both need to migrate to testing. Did you already engage discussions with the release team? I did not find an unblock request. Paul -- Alastair McKinstry, email:alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#989111: libopenmpi-dev: broken symlinks: /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_{ofi,ompio}.so
This appears to be limited to i386/ 32-bit systems. They're shipped elsewhere. There have been changes on 32-bit support. Thanks Alastair On 26/05/2021 08:15, Andreas Beckmann wrote: Package: libopenmpi-dev Version: 4.1.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. From the attached log (scroll to the bottom...): 7m38.7s ERROR: FAIL: Broken symlinks: /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_ofi.so -> libmca_common_ofi.so.10.0.1 (libopenmpi-dev:i386) /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_ompio.so -> libmca_common_ompio.so.41.29.1 (libopenmpi-dev:i386) The corresponding libraries do not seem to be shipped in libopenmpi3 any longer. cheers, Andreas -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
Bug#984956: Still occurring here with 4.1.0-9
Alastair McKinstry
Hi
Can you confirm that openmpi 4.1.0-9 is present on all the nodes ?
Regards
Alastair
From: Dominique Brazziel
Reply to: Dominique Brazziel , <984...@bugs.debian.org>
Date: Thursday 20 May 2021 at 13:03
To: "984...@bugs.debian.org" <984...@bugs.debian.org>
Subject: Bug#984956: Still occurring here with 4.1.0-9
Resent from: Dominique Brazziel
Resent to:
Resent date: Thu, 20 May 2021 12:03:02 +
I installed openmpi-{bin, common} V4.1.0-9 from unstable and still have the
problem.
mpirun.openmpi -host X:2,Y:2 hostname results in the same ORTE_ERROR_LOG
messages
followed by FORCE-TERMINATE.
Bug#984956: Pmix issues with openmpi-4.1.0
Hi Lucas Yikes. No, I wanted to wait and check if there were any issues before issuing an unblock request. Alastair On 16/05/2021 06:35, Lucas Nussbaum wrote: Hi Alaitair, Thanks a lot for fixing this. Unfortunately, I noticed that the upload to unstable was built against ucx 1.10.1~rc1-1, so both need to migrate to testing. Did you already engage discussions with the release team? I did not find an unblock request. Lucas -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#984956: Pmix issues with openmpi-4.1.0
See in part the discussion upstream at : https://github.com/open-mpi/ompi/issues/8596 One workaround might be to use the internal pmix. 4.1.0-4 worked, and using the internal pmix works, BUT reverting to using internal pmix has big testing consequences: We'd move libpmix.so.2 from the external libpmix ($LIBDIR/libpmix.so.2) to libopenmpi3 ($LIBDIR/openmpi/lib/libpmix.so.2) also involves including pmix headers in libopenmpi-dev and re-testing apps accordingly. Currently libopenmpi-dev depends on libpmix-dev , which means 'build-rdeps libpmix-dev' lists 313 packages. Fortunately only the pmix and openmpi source packages are really involved (mpich 3.4.1 didn't correctly work with libpmix so its not built with it - a flag/hint?) but if we simply move to internal pmix we will be shipping 2 sets of pmix headers. I get 4.1.0-4 to work only by excluding libpmix-dev when building to avoid accidental collisions. We could put Build-Conflicts: libpmix-dev into openmpi but we need to test this. Regards Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Bug#982601: python3-paraview Conflicts: python3-vtk9
python3-paraview has just been given Conflicts: python3-vtk9, which is a little confusing. Does it mean python3-paraview replaces python3-vtk9? Or should not python3-paraview not be used at all? (obviously there are other packages which use vtk via python). For this release, python3-paraview ships its own vendored vtk9. This is suboptimal, but the only way I can see of getting paraview working and in the next release. It _could_ work as a drop-in replacement for python3-paraview, but it hasn't been tested, and I don't guarantee it; Especially as I plan on getting paraview back working with the normal python3-vtk9 for the next release. Alastair I think more documentation or explanation is needed. What's going on here? Alternatively, does it just mean python3-paraview should add Provides: python3-vtk9 ? python3-vedo, for instance, needs python3-vtk9 and is therefore affected by this change. Is python3-paraview intended as a drop-in replacement for python3-vtk9 ? Drew -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-paraview depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-6 ii libpython3.9 3.9.1-4 ii libstdc++610.2.1-6 ii paraview 5.9.0-2 ii python3 3.9.1-1 python3-paraview recommends no packages. python3-paraview suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#981289: udunits breaks gnudatalanguage autopkgtest
Ok, found the bug (and a fix). Instead of looking at the default xml path for the datafile, it tries to calculate the path in absolute terms, does it badly, and always prepends "/lib". Simple fix is to revert to 2.26 behaviour. Regards Alastair On 28/01/2021 19:59, Ole Streicher wrote: Control: notfound -1 gnudatalanguage Dear udunits maintainer, unfortunately, the test log of gnudatalanguage is a bit confusing; these are the relevant lines from it: % Compiled module: TEST_CONSTANTS. % IMSL_CONSTANT: UDUNITS: failed to load the default unit database % IMSL_CONSTANT: UDUNITS: failed to load the default unit database % Execution halted at: TEST_CONSTANTS 36 /tmp/autopkgtest-lxc.tr9rpg1n/downtmp/build.2hE/src/testsuite/test_constants.pro % $MAIN$ This looks that udunits didn't find its unit database. Since from the log one can see that the libudunits2-data package was loaded, I would guess that there is some problem with the library. When looking into the failed CI test for gyoto, the message is a bit similar: In gyoto.C: Error initializing libgyoto: Converters.C:56 in void Gyoto::Units::Init(): error initializing arcsec unit Could you check that? Best regards Ole -- Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, phone: 087-6847928 Green Party Councillor, Galway County Council
