Bug#1052763: libgnuastro18 has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/libgnuastro_make.so

2023-09-26 Thread Mohammad Akhlaghi

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

2023-09-26 Thread Mohammad Akhlaghi

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

2021-11-06 Thread Mohammad Akhlaghi

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#980100: Problem on sh4 in Debian auto-building of Gnuastro

2021-01-14 Thread Mohammad Akhlaghi

Package: automake
Version: 1.16.3-2

Gnuastro's source tarball was recently built with the new Autoconf 2.70. 
After uploading it to Debian, we noticed that Gnuastro's build is 
crashing just after the './configure' script finishes and the error is 
from calling Automake (exact error in P.S.), the full log of this Debian 
auto-build is available here:


https://buildd.debian.org/status/fetch.php?pkg=gnuastro=sh4=0.13.93-1=1610475647=0

However, the build has successfully completed on all other systems:

https://buildd.debian.org/status/package.php?p=gnuastro=experimental

After, the crash, Automake complains with an error in Autoconf, but 
since the original crash is in Automake I thought its best to consult 
you about this crash first.


Could you please guide/help me in finding if this is a problem in 
Gnuastro's packaging, Automake or Autoconf?


Thanks a lot,
Mohammad

P.S.

make[1]: Entering directory '/<>'
 cd . && /bin/bash /<>/bootstrapped/build-aux/missing 
automake-1.16 --gnu

free(): invalid pointer
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
automake-1.16: error: autoconf failed with exit status: 134
make[1]: *** [Makefile:2091: Makefile.in] Error 1
make[1]: Leaving directory '/<>'



Bug#868587: gnuastro FTBFS on big endian: test failures

2017-07-17 Thread Mohammad Akhlaghi

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

2017-07-17 Thread Mohammad Akhlaghi

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

2017-06-30 Thread Mohammad Akhlaghi

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

2017-06-27 Thread Mohammad Akhlaghi

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)



Bug#841365: ITP: gnuastro -- Programs and libraries for astronomical data analysis and manipulation

2016-10-19 Thread Mohammad Akhlaghi

Package: wnpp
Owner: Mohammad Akhlaghi <akhla...@gnu.org>
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org

* Package name: GNU Astronomy Utilities (Gnuastro)
  Version : 0.2
  Upstream Author : Mohammad Akhlaghi <akhla...@gnu.org>
* URL : https://www.gnu.org/software/gnuastro/
* License : GNU GPL3+
  Programming Lang: C
  Description : Programs and libraries for astronomical data 
analysis and manipulation


The GNU Astronomy Utilities (Gnuastro) is an official GNU package 
consisting of various programs and library functions for the 
manipulation and analysis of astronomical data. All the programs share 
the same basic command-line user interface for the comfort of both the 
users and developers. Gnuastro is written to comply fully with the GNU 
coding standards so it integrates finely with the GNU/Linux operating 
system. This also enables astronomers to expect a fully familiar 
experience in the source code, building, installing and command-line 
user interaction that they have seen in all the other GNU software that 
they use.


For a list of Gnuastro programs see [1] and for the libraries, please 
see [2]. Ole Streicher Kindly recommended adding Gnuastro as a package 
in Debian, so I am making the official announcement here.


Cheers,
Mohammad

[1] 
https://www.gnu.org/software/gnuastro/manual/html_node/Gnuastro-programs-list.html
[2] 
https://www.gnu.org/software/gnuastro/manual/html_node/Gnuastro-library.html