on Gentoo "help;" opens the help info
window.
On Sunday, February 20, 2022 at 10:24:41 AM UTC-7 Steven Trogdon wrote:
>
> When upgrading incrementally from 9.6.beta1 to 9.6.beta2, I have at this
> point in the configure:
>
> configure:43107: checking that Singular's
When upgrading incrementally from 9.6.beta1 to 9.6.beta2, I have at this
point in the configure:
configure:43107: checking that Singular's help is working
configure:43112: result: yes
a Singular help (info) window is opened and the configure stops until the
window is closed. A new configure fe
I have provided a solution to the jobserver warnings
at https://trac.sagemath.org/ticket/32928
On Saturday, November 20, 2021 at 7:56:05 PM UTC-7 Steven Trogdon wrote:
> Perhaps not directly related to this release but I have numerous jobserver
> warnings when building the pdf documen
Perhaps not directly related to this release but I have numerous jobserver
warnings when building the pdf documentation :
make[5]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
that seems to mostly occur when changing folders to run the LaTeX Makefile
[reference] The
Incremental upgrade from rc1 -> rc2 did not build here with
git pull && make
There was at least one Sage component that was linked against the old
Singular. Rebuilding sagelib then worked
./sage -f sagelib && make
Perhaps there was another way to accomplish the build.
On Tuesday, April 6, 2021 a
The LDFLAGS is set only when building Sage. I have set nothing explicitly
when building system python.
On Sunday, February 7, 2021 at 9:42:35 PM UTC-7 Steven Trogdon wrote:
> OK, here is the reason
>
> g++ -std=gnu++11 -fPIC -I/local/sage-git/sage/conftest_venv/include
> -I
d I've had this set for some time (several years).
On Sunday, February 7, 2021 at 9:30:29 PM UTC-7 Steven Trogdon wrote:
> This beta does not pick up on my system (Gentoo) python. From config.log
>
> configure:39140: result: python3-3.9.1: no
> suita
This beta does not pick up on my system (Gentoo) python. From config.log
configure:39140: result: python3-3.9.1: no
suitable system package; will be installed as an SPKG
And my system python
$ python
Python 3.9.1 (default, Jan 26 2021, 00:24:17)
[GCC 9.3.0] on lin
I was mistaken. Even though I have system Singular-4.1.1_p2-r2 installed
the subject doctest was actually using the Sage-provided
Singular-4.1.1p2.p0.
On Monday, October 12, 2020 at 3:13:45 PM UTC-6 Steven Trogdon wrote:
> On Gentoo with system Singular-4.1.1_p2-r2 the interfaces/singular
On Gentoo with system Singular-4.1.1_p2-r2 the interfaces/singular.py
doctest passes when running the testsuite
Running doctests with ID 2020-10-12-11-01-38-cba0598a.
Git branch: develop
Using --optional=build,dochtml,gentoo,pip,rubiks,sage,sage_spkg
Doctesting entire Sage library.
Sorting source
On Gentoo, incremental build from beta12 -> beta13, I see the following
failure
sage -t --long --warn-long 209.7 --random-seed=0
src/sage/interfaces/singular.py # Killed due to segmentation fault
which is identical to the failure on ubuntu-groovy with beta12
https://github.com/sagemath/sage/r
See https://trac.sagemath.org/ticket/30517
On Sunday, September 6, 2020 at 1:54:03 AM UTC-6, Dima Pasechnik wrote:
>
> These tests work for me. However, they are a bit too memory-hungry and
> slow, I agree.
> Please open a ticket if you like.
>
> On Sun, Sep 6, 2020 at 7:09
I have a new failure that no one seems to have reported:
sage -t --long --warn-long 127.5 --random-seed=0
src/sage/combinat/designs/gen_quadrangles_with_spread.pyx # Bad exit: 1
There are numerous failures of the type
File "src/sage/combinat/designs/gen_quadrangles_with_spread.pyx", line 201,
I've seen the following failures when doctesting Sage-on-Gentoo but I'm now
seeing them when doctesting vanilla Sage:
sage -t --long --warn-long 165.2 --random-seed=0 src/sage/rings/integer.pyx
**
File "src/sage/rings/integer.pyx
, Steven Trogdon wrote:
>
> This beta fails on Gentoo, apparently when building the html-docs, as and
> upgrade from beta7 which built successfully.
>
> [dochtml] File "sage/rings/polynomial/polynomial_element.pyx", line
> 7893, in sage.rings.polynomial.polynomial_elemen
I stated things incorrectly. This was an incremental upgrade from beta8 not
beta7.
On Tuesday, August 18, 2020 at 11:07:05 PM UTC-6, Steven Trogdon wrote:
>
> This beta fails on Gentoo, apparently when building the html-docs, as and
> upgrade from beta7 which built successfully.
>
This beta fails on Gentoo, apparently when building the html-docs, as and
upgrade from beta7 which built successfully.
[dochtml] File "sage/rings/polynomial/polynomial_element.pyx", line 7893,
in sage.rings.polynomial.polynomial_element.Polynomial.roots
(build/cythonized/sage/rings/polynomial
ne? I had doctested 9.1.beta8 with no
failures, so something has changed.
On Monday, March 30, 2020 at 4:54:19 PM UTC-5, Steven Trogdon wrote:
>
> *Gentoo*
>
> Incremental build 9.1.beta8 -> 9.1.beta9
>
> After make python3-clean &&
A feature or a bug? 'make distclean && make' always uses the system python
to build Sage. Is there some way to force building and using the
Sage-supplied python?
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group an
*Gentoo*
Incremental build 9.1.beta8 -> 9.1.beta9
After make python3-clean && make I have the following failures:
--
sage -t --long --warn-long 115.0 src/sage/doctest/test.py # 1 doctest
failed
sage -t --long --warn-long 115.0
Guessing, but perhaps related to https://trac.sagemath.org/ticket/21811
On Sunday, January 26, 2020 at 2:55:52 PM UTC-6, HG wrote:
>
> Any help ?
>
> AMD x8 16 Go RAM ubuntu 20.04, I could compile sagemath-9.0 but since 2
> weeks I can't anymore
>
> Regards
>
> Henri
>
>
--
You received thi
Your build may be picking up on the wrong version of pygments. Vanilla Sage
uses pygments-2.3.1.p0.
./sage -f pygments
may fix the issue. On my sage-on-gentoo build, which uses a system
pygments, I see the same lex literal_block as "python" Warning with
pygments-2.5.2. But pygments-2.4.2 is fi
omething in ~/.gap.
>> Not just on sage-on-gentoo.
>> The question is whether the pexpect interface should continue starting
>> `gap` with the
>> “-r” option or not.
>>
>> François
>>
>> > On 25/05/2019, at 12:17 PM, Steven Trogdon > > wrote:
> <https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F27681%23comment%3A30&sa=D&sntz=1&usg=AFQjCNGLqtTz9XzeI2hIeVClag4nuf5h_A>
>
>
> > On 25/05/2019, at 12:02 PM, Steven Trogdon > wrote:
> >
> > As far as I know this failure
As far as I know this failure started with this beta.
sage -t --long src/sage/tests/gap_packages.py
**
File "src/sage/tests/gap_packages.py", line 137, in
sage.tests.gap_packages.all_installed_packages
Failed example:
all_ins
With *python2 *I can expose these UnicodeEncodeError by inserting "-vv" in
SPHINXOPTS in sage/sage_setup/docbuild/build_options.py. I get two
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in
position 22: ordinal not in range(128)
UnicodeEncodeError: 'ascii' codec can't encode
Perhaps this is https://trac.sagemath.org/ticket/26996#comment:23. Or at
least very similar.
On Thursday, March 7, 2019 at 10:50:10 AM UTC-6, kcrisman wrote:
>
> upgrading from some early 8.6 beta, I get something weird with file
> permissions on gap. Everything seems to go well, but:
>
>
>
> p
Problem building libffi-3.2.1 on gentoo
cp: cannot overwrite non-directory
'/64bitdev/storage/sage-git_develop/sage/local/./lib64' with directory
'/64bitdev/storage/sage-git_develop/sage/local/var/tmp/sage/build/libffi-3.2.1/inst/64bitdev/storage/sage-git_develop/sage/local/./lib64'
On my Gentoo changing the ownership was not sufficient. After changing the
ownership I had to
git reset --hard HEAD
which revealed that
Updating f894105d0d..b36eca1990
error: The following untracked working tree files would be overwritten by
merge:
To correct this:
git clean -f build/pkgs/ba
evre wrote:
>
>
>
> Mon 2018-11-26 03:21:58 UTC+1, Steven Trogdon:
>>
>> Something rather weird here. I'm unable to complete a pull of the latest
>> 8.5.beta5 because of
>>
>> Updating f894105d0d..b36eca1990
>> error: unable to unlink old 'docker/e
Something rather weird here. I'm unable to complete a pull of the latest
8.5.beta5 because of
Updating f894105d0d..b36eca1990
error: unable to unlink old 'docker/entrypoint.sh': Permission denied
Now entrypoint.sh is owned by root which I find strange
ls -al docker/entrypoint.sh
-rwxr-xr-x 1 ro
e been
> bitten by that one as well. It's not your fault.
>
> > On 09/16/2018 09:42 PM, Steven Trogdon wrote:
> >
> > Just guessing, but do you by chance have the file 'test.py' in
> SAGE_ROOT? I think that's where it's looking. If so, rem
Just guessing, but do you by chance have the file 'test.py' in SAGE_ROOT? I
think that's where it's looking. If so, remove it and repeat the tests.
On Sunday, September 16, 2018 at 3:38:44 PM UTC-5, Andy Howell wrote:
>
> I'm getting two tests failing on Ubuntu 18.04.1 LTS
>
> sage -t --long --w
--upgrade pip' which re-installed pip-8.1.2 with a corresponding
local/bin/pip. This allowed 8.4.beta1 to build including the upgrade to
pip-18.0.
On Wednesday, August 15, 2018 at 8:59:21 PM UTC-5, Steven Trogdon wrote:
>
> Incremental upgrade 8.4.beta0 -> 8.4.beta1 fails here wi
nd I think some of the files there should not be there. Note the
timestamp. This was attempted on Aug 15th.
On Thursday, August 16, 2018 at 6:02:53 PM UTC-5, Steven Trogdon wrote:
>
> I've attached the complete build log for this. I does seem that pip3 did
> install but I'm
Incremental upgrade 8.4.beta0 -> 8.4.beta1 fails here with
Successfully installed pip-18.0
Cleaning up...
Removed build tracker '/tmp/pip-req-tracker-eqpf3wqk'
Usage:
/64bitdev/storage/sage-git_develop/sage/local/bin/python2 -m pip install
[options] [package-index-options] ...
/64bitdev/sto
Is this a consequence of fixing the banner
LC_ALL=C ./sage
SageMath version 8.2.rc4, Release Date: 2018-04-20
and thus no banner, or has it always been this way? I only noticed because
I had changed LC_ALL for some other purpose. I usually have LC_ALL unset
with the other LC_ variables set indi
The sage -t --long src/sage/combinat/posets/posets.py failure is now
https://trac.sagemath.org/ticket/22950
On Sunday, April 30, 2017 at 5:59:55 AM UTC-5, Emmanuel Charpentier wrote:
>
> On Debian testing runninng on Core I7 + 16 GB RAM, after fetching diffs
> over 8.0.beta3, I get three errors
aphviz would be
> the problem. My thought is more of that the DiGraph constructor is getting
> confused about the input. We might have to specify the input data to the
> DiGraph.
>
> Best,
> Travis
>
>
> On Thursday, May 4, 2017 at 9:14:28 AM UTC-5, Steven Trogdon wr
he failing test happen to have graphviz?
> And the one who don’t, not?
>
> François
>
> > On 4/05/2017, at 18:23, Steven Trogdon > wrote:
> >
> > The posets.py test fails here on my Gentoo machine with sage-on-gentoo
> installed, but with vanilla Sage on th
The posets.py test fails here on my Gentoo machine with sage-on-gentoo
installed, but with vanilla Sage on the same machine the test passes.
On Sunday, April 30, 2017 at 5:59:55 AM UTC-5, Emmanuel Charpentier wrote:
>
> On Debian testing runninng on Core I7 + 16 GB RAM, after fetching diffs
> ov
The same here on Gentoo with LDFLAGS=-Wl,-O1 -Wl,--as-needed
On Sunday, April 23, 2017 at 6:29:38 PM UTC-5, tsc...@ucdavis.edu wrote:
>
> This branch failed for me on linux at lcalc with what looks like linking
> errors. I reverted https://trac.sagemath.org/ticket/22840 and then I was
> able to
Similar issue here with the exception that I have no warnings. The 'sphere'
briefly appears and then disappears from the cell.
On Wednesday, March 1, 2017 at 2:13:36 PM UTC-6, Eric Gourgoulhon wrote:
>
> Hi,
>
> It seems that the three.js viewer is broken in this release: running
> show(sphere()
I believe the trace.py issue is
https://trac.sagemath.org/ticket/21258
On Wednesday, November 30, 2016 at 1:23:37 AM UTC-6, Sébastien Labbé wrote:
>
> On OSX 10.10.2, I get two errors with make ptestlong (only the one with
> singular.py reappears on a rerun) :
>
> sage -t --long --warn-long 263.
; wrote:
> >
> > I am guessing it is picked up automagically by zeromq.
> > Sage doesn’t provide it, it was detected from your system.
> > I’ll look into it.
> >
> > François
> >
> >> On 26/11/2016, at 19:46, Steven Trogdon > wrote:
> >>
r problem.
>
> François
>
> > On 26/11/2016, at 19:50, Steven Trogdon > wrote:
> >
> > The beta4 build was after doing a `git pull` && `make`.
> >
> > On Saturday, November 26, 2016 at 12:46:32 AM UTC-6, Steven Trogdon
> wrote:
> &g
The beta4 build was after doing a `git pull` && `make`.
On Saturday, November 26, 2016 at 12:46:32 AM UTC-6, Steven Trogdon wrote:
>
> OK, after looking at the logs beta3 was built on 11/17. libsodium was
> upgraded from libsodium.so.13 to libsodium.so.18 on 11/18. So there has
ther
> than a build of sage from scratch - and upgraded
> libsodium just before the upgrade?
>
> François
>
> > On 26/11/2016, at 18:46, Steven Trogdon > wrote:
> >
> > Fails here on Gentoo when building the docs:
> >
> > [dochtml] Traceba
Sorry, I meant 'is libsodium.so.13 really needed'? Perhaps something else?
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+unsubscr...@googlegroups.
Fails here on Gentoo when building the docs:
[dochtml] Traceback (most recent call last):
[dochtml] File
"/64bitdev/storage/sage-git_develop/sage/local/lib/python/runpy.py", line
162, in _run_module_as_main
[dochtml] "__main__", fname, loader, pkg_name)
[dochtml] File
"/64bitdev/storage
in the past with this same
doctest on the presently used hardware.
On Monday, September 19, 2016 at 10:39:47 PM UTC-5, Steven Trogdon wrote:
>
> On Gentoo 1 failure:
>
> sage -t --long src/sage/matrix/matrix_double_dense.pyx
>
On Gentoo 1 failure:
sage -t --long src/sage/matrix/matrix_double_dense.pyx
**
File "src/sage/matrix/matrix_double_dense.pyx", line 668, in
sage.matrix.matrix_double_dense.Matrix_double_dense.condition
Failed example:
A.condi
I have the following failure:
sage: P = graphs.PetersenGraph() ## line 539 ##
sage: P.tutte_polynomial() ## line 540 ##
x^9 + 6*x^8 + 21*x^7 + 56*x^6 + 12*x^5*y + y^6 + 114*x^5 + 70*x^4*y +
30*x^3*y^2 + 15*x^2*y^3 + 10*x*y^4 + 9*y^5 + 170*x^4 + 170*x^3*y +
105*x^2*y^2 + 65*x*y^3 + 35*y^4 + 180*x
On Tuesday, August 23, 2016 at 2:44:10 PM UTC-5, Daniel Krenn wrote:
>
> On 2016-08-17 22:28, Volker Braun wrote:
> > As always, you can get the latest beta version from the "develop" git
> > branch. Alternatively, the self-contained source tarball is at
> > http://www.sagemath.org/download-late
As a consequence of http://trac.sagemath.org/ticket/20498 the following has
been introduced:
grep -r "Error(f" src/sage/arith/multi_modular.pyx
raise ValueError(f"minimum value for lower bound is 2, given:
{l_bound}")
raise ValueError(f"upper bound cannot be greater than
't trust your library linkings you can always run ldd
> local/lib/python/site-packages/sage/rings/integer.so
>
>
> On Thursday, December 31, 2015 at 7:03:25 PM UTC+1, Steven Trogdon wrote:
>>
>> I have the following failure:
>>
>> ./sage -t src/sage/rings
Is it possible that a system component is contaminating the doctest? I get
a similar failure from a sage-on-gentoo install where the failure seems to
point to gmp?
On Thursday, December 31, 2015 at 12:03:25 PM UTC-6, Steven Trogdon wrote:
>
> I have the following failure:
>
> ./sage
I have the following failure:
./sage -t src/sage/rings/integer.pyx
too many failed tests, not using stored timings
Running doctests with ID 2015-12-31-11-59-48-9f43f0a3.
Git branch: develop
Using --optional=mpir,python2,sage
Doctesting 1 file.
sage -t src/sage/rings/integer.pyx
***
58 matches
Mail list logo
