On 21/12/2021 17.49, Lucas Nussbaum wrote:
[ /polytope/objects/Polytope/properties/Geometry/SLACK_IDEAL ] 1 ? cannot
open `standard.lib`
// ** Could not get 'Singular'.
// ** Either set environment variable 'SINGULAR_EXECUTABLE' to 'Singular',
// ** or make sure that 'Singular' is at "/usr/S
Hello David,
On 28/01/2021 12.59, David Bremner wrote:
The relevant output from the tests seems to be
[ /polytope/objects/Polytope/properties/Triangulation and volume/RELATIVE_VOLUME ] 1polymake:
WARNING: rule RELATIVE_VOLUME : SQUARED_RELATIVE_VOLUMES failed: Undefined subroutine
&Polymak
On 13/02/2020 16.53, Benjamin Lorenz wrote:
> On 13/02/2020 13.18, David Bremner wrote:
>> Benjamin Lorenz writes:
>>>> It looks like it's flint related?
>>>
>>> Yes, I think this is a bug in flint and for now I suggest disabling the
>>>
On 13/02/2020 13.18, David Bremner wrote:
> Benjamin Lorenz writes:
>
>>
>>> It looks like it's flint related?
>>
>> Yes, I think this is a bug in flint and for now I suggest disabling the
>> flint-interface of polymake with the configure option --with
After some time of setting this up and building I can reproduce it and
got a better backtrace which seems well inside flint (up to frame 6):
Program received signal SIGSEGV, Segmentation fault.
0x0040014cb29c in flint_mpz_set_ui (r=0x400c8e3dd0, r=0x400c8e3dd0,
u=9223372036854775837)
at ./
On 26/11/2019 01.51, Andreas Beckmann wrote:
> On 26/11/2019 00.00, Benjamin Lorenz wrote:
>> tldr: please rebuild normaliz and then try polymake again.
>
> Thanks for the analysis. binNMU of normaliz requested: #945504
Thanks.
>> This is very weird but after some diggi
On 23/11/2019 20.30, Andreas Beckmann wrote:
> Control: affects 941933 + src:polymake
> Control: retitle -1 polymake: FTBFS with normaliz 3.8.1: segfaults during
> tests
>
> On 23/11/2019 10.45, Benjamin Lorenz wrote:
>> On 22/11/2019 22.06, Andreas Beckmann wrote:
>&
On 22/11/2019 22.06, Andreas Beckmann wrote:
> polymake FTBFS against perl 5.30:
> https://buildd.debian.org/status/package.php?p=polymake&suite=unstable
>
> *** Summary ***
>
> *** Failed tests ***
>
> /<>/apps/polytope/src/gc_closure.cc:173: testcase 1
> expected: regular return
> got: EX
On 10/7/19 8:30 PM, Niko Tyni wrote:
> On Mon, Oct 07, 2019 at 08:59:47PM +0300, Niko Tyni wrote:
>> Source: polymake
>> Version: 3.2r4-4
>> Severity: serious
>> Tags: ftbfs
>> Control: block 935737 with -1
>>
>> This package failed to build in sid when rebuilding against Perl 5.30.
>>
>> Looking a
Hi,
this comes from a different output order produced by cdd version 0.94j
(probably caused by https://github.com/cddlib/cddlib/pull/10 ).
We have disabled this test in polymake 3.2r4. I have tried updating the
package and created a pull request here:
https://salsa.debian.org/bremner/polymake/mer
Dear Lev,
It seems a fix for this bug was merged into the upstream stable
repository some time ago:
https://github.com/SWI-Prolog/swipl/commit/3923765d56e5
I have an unstable i386 VM where I could reproduce these memory errors
and adding this to the patches resolves it.
Since there is still no n
created a pull request to for this:
https://github.com/SWI-Prolog/packages-jpl/pull/8
I have tried this on i386 and the package now compiles but make check
then fails with the same errors as in #887155.
Regards,
Benjamin Lorenz
On 01/06/2018 08:08 PM, Niko Tyni wrote:
> Running polymake currently fails with
>
> $ polymake
> Can't locate loadable object for module Polymake::Ext in @INC
>
> Apparently this is because it was built with Perl 5.26.0, but
> we've since moved to 5.26.1.
>
> I see two better alternatives:
>
>
Sending the attachment manually as it didn't come with the notification.
Benjamin Lorenz
>From f293923ae20196f34b1348bae9338fed0387388c Mon Sep 17 00:00:00 2001
From: Christof Soeger
Date: Tue, 8 Dec 2015 12:04:40 +0100
Subject: [PATCH] fix libnormaliz for gmp 6.1
adapted from
14 matches
Mail list logo
