>> 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 ?
No, that's the same behavior as in our 5.2.0 port and for that matter in
the FreeBSD pkg as well (I checked with 6.4.0 ... the 7.1.0 pkg is not
available yet)
Some of the failing tests are due to relatively small tolerance
deviations b/w libc++ and libstdc++ ... The tolerances have been widened
in tests if "ismac" is true, but the libstdc++ tolerances are applied
for any other Unix.
Then there's an interesting deviation in acos:
On systems with libc++:
> acos(-1*1e150)
ans = 0 - Infi
whereas the real component should be close to Pi:
https://www.wolframalpha.com/input?i=acos%28-1*1e150%29
And then there's some hiccups in NaN vs. Inf (appearing in logspace tests).
What's *not* failing in FreeBSD but *is* failing in OpenBSD is:
> assert (nextpow2 (Inf),Inf)
error: ASSERT errors for: assert (nextpow2 (Inf),Inf)
Location | Observed | Expected | Reason
() -1377054984 Inf 'Inf' mismatch
I'm guessing that has something to do with one of these:
https://github.com/freebsd/freebsd-src/commit/7dbbb6dde39391c17de03d7901dad76de99a14ff
https://github.com/freebsd/freebsd-src/commit/b052ec90654afb91667abb5163edb399519ceec4
Perhaps we can look at those patches if they make sense to integrate
them into OpenBSD?
> 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' ?
It looks for the "bsdtar" string, in the output of "tar --version" and
if it isn't there, assumes it's GNU tar. So, our tar is considered to be
GNU tar.
My patch doesn't change that behavior, but I thought that since we
already know it isn't bsdtar, we might just as well have that function
always return false (= not 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..
Without the patch to unpack.m, we fail pkg/pkg.tst
Apparently there's a code path via pkg.m that tries to directly untar a
gzipped tar archive with "tar xvf". gtar handles that without the 'z'
option, OpenBSD tar isn't so lenient.
I figured that if one has the disk space and CPU resources for an octave
with a QT dependency, needing gtar won't raise eyebrows either, so using
gtar universally seemed to be the least intrusive option.
No comments:
Post a Comment