Re: [update] math/octave 7.1.0
Le Sat, Apr 23, 2022 at 11:59:07AM +0200, Volker Schlecht a écrit : > > > i've tried your diff and it fails to package here, some tests are > > apparently installed in the wrong dir ? > > Ha ... yes, turns out I was missing a patch from upstream: > > https://savannah.gnu.org/bugs/index.php?62295 > > The attached diff includes that, and the fix to use PORTHOME instead of > tweaking TEST_ENV. thanks, that builds & packages fine, tests still running here. > steven@: I'd be willing to take over as maintainer, just in case you're > interested in passing it on. i can take care of commiting qhull/octave/plplot & tweaks here and there (WANTLIB fixes for gdal/postgis) anytime :) but usually MAINTAINER has the last word ! Landry
Re: [update] math/octave 7.1.0
Le Sat, Apr 16, 2022 at 10:11:11PM +0200, Volker Schlecht a écrit :
> Hi,
>
> so here's my shot at the octave update. There are some remaining failing
> tests (they have been failing in 5.2.0 as well), that are due to Octave
> banking on some specific behaviors of GNU libstdc++ ... (un)fortunately
> these are all documented:
>
> https://lists.gnu.org/archive/html/octave-maintainers/2018-04/msg00152.html
>
> The most disturbing one is the difference in parsing imaginary parts of
> complex numbers, so using dlmread or str2double is badly broken on systems
> building with libc++:
>
> https://bugs.llvm.org/show_bug.cgi?id=17782
>
> That's not a regression vs. the 5.2.0 port - it's been in there as well.
>
> I added a dependency on gtar, because Octave assumes either bsdtar or GNU
> tar, and enforcing GNU tar seemed to be the most straightforward way of
> addressing that.
thanks for all the details on the failing tests & the gtar thing, its
much clearer now.
i've tried your diff and it fails to package here, some tests are
apparently installed in the wrong dir ?
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@cell/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@char/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@double/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@function_handle/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@int16/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@int32/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@int64/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@int8/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@logical/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@single/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@struct/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@uint16/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@uint32/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@uint64/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/@uint8/tbcover.m
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/bc-overloads.tst
does not exist
Error:
/usr/obj/ports/octave-7.1.0/fake-amd64/usr/local/share/octave/7.1.0/etc/tests/fixed/build/pobj/octave-7.1.0/build-amd64/test/tbcover.m
does not exist
> +# Some tests fail when a tilde doesn't expand to a home directory
> +TEST_ENV = HOME="${WRKSRC}"
tb@ commented on this and said this should be PORTHOME=${WRKSRC}, so i've done
that locally and it failed to package => the below chunk of PLIST is wrong :)
> +share/octave/${VERSION}/etc/tests/fixed/build/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/build-amd64/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/build-amd64/test/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/build-amd64/test/@cell/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/build-amd64/test/@cell/tbcover.m
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/build-amd64/test/@char/
> +share/octave/${VERSION}/etc/tests/fixed/build/pobj/octave-${VERSION}/build-amd64/test/@char/tbcover.m
>
Re: [update] math/octave 7.1.0
Le Sat, Apr 16, 2022 at 10:11:11PM +0200, Volker Schlecht a écrit : > Hi, > > so here's my shot at the octave update. There are some remaining failing > tests (they have been failing in 5.2.0 as well), that are due to Octave > banking on some specific behaviors of GNU libstdc++ ... (un)fortunately > these are all documented: > > https://lists.gnu.org/archive/html/octave-maintainers/2018-04/msg00152.html so those are *not* regressions ? > > The most disturbing one is the difference in parsing imaginary parts of > complex numbers, so using dlmread or str2double is badly broken on systems > building with libc++: > > https://bugs.llvm.org/show_bug.cgi?id=17782 > > That's not a regression vs. the 5.2.0 port - it's been in there as well. > > I added a dependency on gtar, because Octave assumes either bsdtar or GNU > tar, and enforcing GNU tar seemed to be the most straightforward way of > addressing that. thanks for that tedious work - btw the port has a maintainer, which i'm ccing now :) steven, now is the time to comment on this update (which depends on qhull in the same thread) as for that last thing, from my reading of the patch, if it correctly detects bsd tar by running 'tar --version' and assuming its bsdtar if the latter fail, then we're sure that our tar will be properly detected/used ? or it assumes/looks for a command named 'bsdtar' ? either way, since on OpenBSD GNU tar is gtar i dont see how ther could be mixup between both, so if at runtime it works with our tar why the need to patch it ? looking at the patch all tar usages seems covered by our tar options.. Landry
