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
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
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
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
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:
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
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
7 matches
Mail list logo