Bug#1052763: libgnuastro18 has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libgnuastro_make.so
Hi Helmut, Thank you very much for the complete explanation. Will this problem be fixed if we separate 'libgnuastro_make' as a separate package in 'debian/control'? I would indeed love to read the Debian policy in full detail as it evolves. I did read most parts when I was helping the Debian-Astro team package it several years ago. But I am finding it harder and harder to find the time: I am the developer of Gnuastro, I am not a packager (but I love to do it as best as possible for the sake of the users). If the above is no the solution, can you point me to the sub-section about this? Generally, it would be great if Lintian could complain about such issues. Before every push to salsa.debian.org (for the Debian astro team to inspect before pushing), I run it like below and correct all the important/relevant errors/warnings. lintian -E -I --pedantic ... Thank you very much, Mohammad
Bug#1052763: libgnuastro18 has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libgnuastro_make.so
Thank you very much for this report, The 'libgnuastro_make.so' is declared within the 'debian/libgnuastro18.install' file (see [1] below); a comment there also described what it is (an extension-library for GNU Make, described in [2]). Could you please point me to any other place that it should be declared? This is an important bug and I will fix it as soon as I know the solution. Thank you very much, Mohammad [1] https://sources.debian.org/src/gnuastro/0.20-1/debian/libgnuastro18.install [2] https://www.gnu.org/software/make/manual/html_node/Loading-Objects.html
Bug#998703: src:gnuastro: fails to migrate to testing for too long: ftbfs on mips64el
Dear Paul, Thank you very much for noticing this and marking the bug as fixed. Also, I really appreciate the great explanation of the significance of such situations, I completely agree. The delay originated from the Debian version freezing: version 0.15 of Gnuastro came in that time slot (so it couldn't be updated in Debian). By the time the freeze was lifted, Gnuastro had significantly grown (and almost ready for version 0.16). But we pushed version 0.15 only to keep continuity. It was only after uploading version 0.15 that we noticed the bug in 'mips64el'. So we fixed it and pushed it with all the other bug fixes that had been found as version 0.15.54. Because the library had changed in this time, the new upload went to the NEW stack (on September 22nd). However, it was stuck in the NEW list for about 1.5 months (with one rejection due to bad copyright statement that was immediately fixed and re-submitted). Ultimately it was approved this morning! Version 0.16 of Gnuastro is already released upstream [1], so as soon as Gnuastro 0.15.54 passes on all CPU architectures in the experimental branch [2], we will upload version 0.16 to 'testing'. Thanks again, Mohammad [1] https://lists.gnu.org/archive/html/info-gnuastro/2021-10/msg0.html [2] https://buildd.debian.org/status/package.php?p=gnuastro=experimental
Bug#868587: gnuastro FTBFS on big endian: test failures
Dear Adrian, Thank you so much for the reports. The cause of this bug was found and corrected: On Savannah (Gnuastro's bug tracking system): https://savannah.gnu.org/bugs/?51476 In the Gnuastro source: http://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=8ff37cf41 In the debian packaging: https://anonscm.debian.org/cgit/debian-astro/packages/gnuastro.git/tree/debian/changelog Once it is uploaded the problem will be fixed. Thanks again, Mohammad
Bug#868586: gnuastro FTBFS on 32bit: FAIL: mkprof/radeccat.sh
Dear Adrian, Thank you so much for the reports. The cause of this bug was found and corrected: In the Gnuastro source: http://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=8ff37cf41 In the debian packaging: https://anonscm.debian.org/cgit/debian-astro/packages/gnuastro.git/tree/debian/changelog Once it is uploaded the problem will be fixed. Thanks again, Mohammad
Bug#865973: Gnuastro 0.3.13 checks on 32bit big endian systems
Hi Adrian, Thank you very much for finding the problem. I really appreciate it. I have made the fix in the Gnuastro code and submitted it to Debian Astro. To fix the problem, a new machine-specific type code (GAL_TYPE_LONG) is defined. It is just an alias for GAL_TYPE_INT32 or GAL_TYPE_INT64 depending on the system (similar to how GAL_TYPE_SIZE_T is defined). The problem would also be fixed with GAL_TYPE_SIZE_T, but since the the arrays are of type `long' (mandated by the CFITSIO library that we use), I thought it would be more clear to define this new `long' type type code. Hopefully Debian Astro will upload the changed to Debian servers and this problem will be fixed. Thank you very much again for your great help in finding and solving this important bug. Gratefully yours, Mohammad
Bug#865973: Gnuastro 0.3.13 checks on 32bit big endian systems
Thank you very much, This is very strange because these test scripts all have the `--naxis1' and `--naxis2' options that the error message complains about! Here is one example (see line 53): https://sources.debian.net/src/gnuastro/0.3.13-1/tests/mkprof/mosaic1.sh So there is something deep in the code that is causing this failure. But I don't have any 32-bit big-endian system to try on. I tried downloading the Debian MIPS installation image, but couldn't build it in a virtual machine (using virtual box). Could you recommend an emulator or something that I can try this build and run Gnuastro on such a system (from my 64-bit intel processor) and find the cause of the bug? Thanks again, Mohammad -- Maintainer of GNU Astronomy Utilities (Gnuastro)