Closed perlpunk closed 2 weeks ago
[ 63s] # Failed test 'GSL LINALG LU DECOMP' [ 63s] # at t/Linalg.t line 64. [ 63s] # (in Math::GSL::Linalg::Test->GSL_LINALG_LU_DECOMP) [ 63s] # Structures begin differing at: [ 63s] # $got->[0] = '0' [ 63s] # $expected->[0] = '4'
@perlpunk Thanks for the report! Yes it is better to submit issues here than in RT. I think this is due to changed behavior in GSL 2.8. From this version on, gsl_linalg_complex_LU_decomp()
will return an integer > 0 if the matrix is singular, see: https://www.gnu.org/software/gsl/doc/html/linalg.html. For some reason the matrix in the test is not considered singular (which it is) or it is using a version of GSL < 2.8.
@perlpunk Would it be possible to extend the github action test cases with i586 and aarch64? Or reproduce the error in a docker container?
[ 63s] # $expected->[0] = '4'
Btw. the same behavior was observed on macOS, and I just did a quick fix here: https://github.com/hakonhagland/perl-math-gsl/blob/48e0aba6fcca8e95402d5e312acb0c80dab695e1/t/Linalg.t#L59
It would be interesting to know more details about why this happens
@perlpunk Would it be possible to extend the github action test cases with i586 and aarch64? Or reproduce the error in a docker container?
I don't know. But it's possible to create a free account on https://build.opensuse.org/ and even use it as a CI: See https://perlpunk.github.io/posts/2024-04-obs-as-a-ci-for-perl-modules/ and the previous article.
Thanks, I will have a look at that when I come back from holiday. Probably end of next week :)
@perlpunk I did some more experiments on macOS, and it seems that the failure there is due to round off errors causing the matrix to be almost singular but not quite. I pushed a new commit to fix the issue here: https://github.com/hakonhagland/perl-math-gsl/commit/98b00b879b0e10202e6ebb4442d8ae5091b73858
Can you try it on aarch64? Hopefully it will fix this issue.
ok, I'll run it tomorrow :)
@perlpunk Thanks! Looking at the error messages from i586 and aarch64 again now, I missed that they do not report the same error. The error for aarch64 is different:
[ 97s] # Error: Can't load '/home/abuild/rpmbuild/BUILD/Math-GSL-0.45/blib/arch/auto/Math/GSL/Matrix/Matrix.so'
for module Math::GSL::Matrix: /home/abuild/rpmbuild/BUILD/Math-GSL-0.45/blib/arch/auto/Math/GSL/Matrix/Matrix.so:
undefined symbol: gsl_matrix_char_norm1 at /usr/lib/perl5/5.40.0/aarch64-linux-thread-multi/DynaLoader.pm line 206.
I will try to reproduce this error tomorrow.
ok, i586 succeeded with the patch at least :) I attached the log: Math-GSL-i586.log
@perlpunk Thanks for the update! Seems like the issue on aarch64 is due to gsl_matrix_char_norm1()
is not defined in the generated libgsl.so
due to this macro https://git.savannah.gnu.org/cgit/gsl.git/tree/matrix/prop_source.c#n163
I will investigate this a little bit more to decide what to do.
undefined symbol: gsl_matrix_char_norm1
@perlpunk Yes, it seems that the failure on aarch64 was due to char being treated as unsigned on that platform. I have added some commits to master branch to address this, see e.g.
Can you check if the current master branch solves the reported test failure on aarch64? Thanks!
We've seen the same test failures in t/Linalg.t
in Debian:
After applying (parts of) the aforementioned commit 98b00b8 on top of 0.45 (+ 8be5b93), it looks like it builds everywhere (one architecture is still missing):
As @mohawk2 mentioned in #36, maybe this would be a good time to upload a new release to the CPAN?
Cheers, gregor, Debian Perl Group
@gregoa Thanks for the feedback! I have uploaded version 0.48 to CPAN now: https://metacpan.org/pod/Math::GSL
On Fri, 26 Jul 2024 23:52:51 -0700, Håkon Hægland wrote:
@gregoa Thanks for the feedback! I have uploaded version 0.48 to CPAN now: https://metacpan.org/pod/Math::GSL
Thank you!
--
.''. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
. ' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
-
Sorry for not being able to test, I was busy. Now I have the problem that I have to package the new dependency Math::GSL::Alien, and I'm not so familiar with packaging alien modules, so I can't test it yet. But @gregoa confirmed that it works, so thank you!
btw, the issue tracker on cpan still points to https://rt.cpan.org/Public/Dist/Display.html?Name=Math-GSL You can influence that with a setting in META.yaml/json.
Oh, and this is still looking weird and missing the last 4 versions: https://metacpan.org/dist/Math-GSL/view/Changes But that's probably a bug in the metacpan pod parser...
But that's probably a bug in the metacpan pod parser...
@perlpunk I think it might be missing some newlines around the Pod directives, see #38. Thanks for reporting!
You can influence that with a setting in META.yaml/json.
@perlpunk The module is not using META.json
I guess since it is using Module::Build
instead of ExtUtils::MakeMaker
? I am trying to figure out how set the bug tracker URL for Module::Build
I have to package the new dependency Math::GSL::Alien, and I'm not so familiar with packaging alien modules
@perlpunk It should be similar to packaging Alien::GSL
(which it used before version 0.48) ?
You can influence that with a setting in META.yaml/json.
@perlpunk The module is not using
META.json
I guess since it is usingModule::Build
instead ofExtUtils::MakeMaker
? I am trying to figure out how set the bug tracker URL forModule::Build
I couldn't find a complete example, but those links in combination should do it: https://metacpan.org/dist/Module-Build/view/lib/Module/Build/API.pod#meta_merge https://blogs.perl.org/users/neilb/2017/05/specifying-dependencies-for-your-cpan-distribution.html https://metacpan.org/pod/CPAN::Meta::Spec#resources
Your module does package a https://metacpan.org/release/HAKONH/Math-GSL-0.48/source/META.json and META.yaml Actually, you already have a meta_merge, so you just need to add the bugtracker: https://metacpan.org/release/HAKONH/Math-GSL-0.48/source/Build.PL#L128
Actually, you already have a meta_merge, so you just need to add the bugtracker
@perlpunk Thanks! Added this using meta_merge
in #39
I have to package the new dependency Math::GSL::Alien, and I'm not so familiar with packaging alien modules
@perlpunk It should be similar to packaging
Alien::GSL
(which it used before version 0.48) ?
Unfortunately not. I added gsl-devel
to the build requirements, but it still wants to fetch the gsl library from the intenet, which we don't allow in the build environment, So I need an existing library I can depend on. But I guess that's off topic for this issue. I might get help from colleagues how to do that.
It should be similar to packaging Alien::GSL... Unfortunately not.
@perlpunk It should not download GSL from the internet if it can find it on your system. In which directory on your system do you have libgsl.so
installed ?
% rpm -ql gsl-devel-2.8-2.1.x86_64 | grep libgsl.so
/usr/lib64/libgsl.so
This is the spec file for Alien-GSL:
https://build.opensuse.org/projects/devel:languages:perl/packages/perl-Alien-GSL/files/perl-Alien-GSL.spec?expand=1
So the only change we make is adding BuildRequires: gsl-devel
My experiment with Math-GSL-Alien is here: https://build.opensuse.org/package/show/home:tinita:branches:devel:languages:perl:CPAN-x/perl-Math-GSL-Alien
Hm, I actually made a mistake. Now that I added gsl-devel to perl-Math-GSL-Alien I get a different error: https://build.opensuse.org/package/live_build_log/home:tinita:branches:devel:languages:perl:CPAN-x/perl-Math-GSL-Alien/openSUSE_Tumbleweed/x86_64
[ 7s] rmdir: failed to remove '/home/abuild/rpmbuild/BUILDROOT/perl-Math-GSL-Alien-1.50.0-6.1.x86_64/usr/lib/perl5/vendor_perl/5.40.0/x86_64-linux-thread-multi/auto/Math/GSL/Alien': Directory not empty
[ 7s] rmdir: failed to remove '/home/abuild/rpmbuild/BUILDROOT/perl-Math-GSL-Alien-1.50.0-6.1.x86_64/usr/lib/perl5/vendor_perl/5.40.0/x86_64-linux-thread-multi/auto/Math/GSL': Directory not empty
...
@perlpunk I created a new release for the last two PRs, see: https://github.com/hakonhagland/perl-math-gsl/releases/tag/v0.49. Let me know if I should upload this to CPAN or if that would mess up your current packaging work..
Sure, go ahead!
In which directory on your system do you have libgsl.so installed ? ... /usr/lib64/libgsl.so
@perlpunk Thanks for the info. Then, there should also be a script gsl-config
usually installed in a bin
directory. Try to add that bin
directory to the PATH
environment variable. See:
@perlpunk You may need to set the PKG_CONFIG_PATH
environment variable to avoid Math::GSL::Alien
starting the download from the internet. For example if I have installed GSL in /opt/gsl/gsl-2.8
, then I would do:
$ export PKG_CONFIG_PATH=/opt/gsl/gsl-2.8/lib/pkgconfig
Let me know if this helps.
I wanted to create a ticket in RT but I got a 403 Forbidden, so I hope it's ok to put it here.
We see failing tests in openSUSE: https://build.opensuse.org/package/live_build_log/devel:languages:perl:autoupdate/perl-Math-GSL/standard/i586
https://build.opensuse.org/package/live_build_log/devel:languages:perl:autoupdate/perl-Math-GSL/standard/aarch64