Oh yes. You are right. For some reason, my git repo changed back to
`master`. The build has finished now. Thanks for your foresight, Matthias.
Best
Michael
Am 26.04.20 um 19:34 schrieb Matthias Koeppe:
On Sunday, April 26, 2020 at 2:55:51 AM UTC-7, Michael Jung wrote:
still, ecl won't wo
On Sunday, April 26, 2020 at 2:55:51 AM UTC-7, Michael Jung wrote:
>
> still, ecl won't work.
>
>From your ecl log:
Setting up build directory for ecl-16.1.2.p5
Finished extraction
Applying patches from ../patches...
Applying ../patches/16.1.2-getcwd.patch
patching file src/c/unixfsys.d
Applying
On Sunday, April 26, 2020 at 2:55:51 AM UTC-7, Michael Jung wrote:
configure:3693: checking for root user
configure:3698: result: yes
configure:3700: error: You cannot build Sage as root, switch to an
unpriviledged user
This is not the right configure file
--
You received this message becau
Yes, exactly. Thank you Eric.
I could compile pillow now, but still, ecl won't work.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@google
> Someone posted a new list of all packages that have to be preinstalled on the
> system som time ago, but I cannot found it again. Could this be the issue
> here?
>
>
Is https://wiki.sagemath.org/prerequisites/Ubuntu the list you are looking
for?
Maybe it should be updated for Ubuntu 20.04.
On Saturday, April 25, 2020 at 4:12:47 PM UTC-7, Michael Jung wrote:
>
> Today, I have managed a clean installation of the new Ubuntu version 20.04
> LTS on my machine. Now, I try to build Sage from the source files and my
> build always stops at
>
> * package: pillow-5.3.0.p0
> log file: /hom
On Saturday, April 25, 2020 at 4:12:47 PM UTC-7, Michael Jung wrote:
>
> Today, I have managed a clean installation of the new Ubuntu version 20.04
> LTS on my machine. Now, I try to build Sage from the source files and my
> build always stops at two packages:
>
> * package: ecl-16.1.2.p5
> log
Hi Jeroen,
thanks, I'll do the changes accordingly.
Best regards,
Simon
On 2017-12-08, Jeroen Demeyer wrote:
> On 2017-12-07 23:57, Simon King wrote:
>> from libc.string cimport memcpy
>
> This one is fine.
>
>> include "cysignals/signals.pxi"
>
> from cysignals.signals cimport FOO
>
>> include
On 2017-12-07 23:57, Simon King wrote:
from libc.string cimport memcpy
This one is fine.
include "cysignals/signals.pxi"
from cysignals.signals cimport FOO
include 'sage/ext/stdsage.pxi'
from MODULE cimport BAR
You'll have to fill in the exact values for FOO, BAR and MODULE though.
Th
> On 8/12/2017, at 11:57, Simon King wrote:
>
> I just see the following in the diff:
>
> +from libc.string cimport memcpy
> +include "cysignals/signals.pxi"
> +include 'sage/ext/stdsage.pxi'
>
> I recall from some trac ticket I was involved in that all three of the
> above statements should
On 2017-12-07, Simon King wrote:
> On 2017-12-07, François Bissey wrote:
>> No. I believe we stopped relying on that file when upgrading to cysignals
>> 1.6.x.
>> So the proper include to get that file may have been removed from somewhere.
>> Your branch would be quite peculiar to be caught betw
On 2017-12-07, François Bissey wrote:
> No. I believe we stopped relying on that file when upgrading to cysignals
> 1.6.x.
> So the proper include to get that file may have been removed from somewhere.
> Your branch would be quite peculiar to be caught between two changes.
> Could you rebase it?
No. I believe we stopped relying on that file when upgrading to cysignals 1.6.x.
So the proper include to get that file may have been removed from somewhere.
Your branch would be quite peculiar to be caught between two changes.
Could you rebase it?
François
> On 8/12/2017, at 10:56, Simon King w
Hi!
On 2017-12-07, François Bissey wrote:
> OK this looks suspiciously like
> https://bugs.python.org/issue30074
> which was fixed by
> https://github.com/python/cpython/pull/1154
> which should be in 2.7.14.
> What I suspect is happening is that those failures happen when
> people upgrade pyth
Thank you so much, that fixed the problem!
On Tuesday, June 7, 2016 at 6:13:24 PM UTC-5, Paul Masson wrote:
>
> You need to perform an explicit installation of the Xcode command line
> tools. I had the same error recently and that solved it.
--
You received this message because you are subscrib
Setting the effective group to the same as the group on the build directory
did allow pynac to compile. I am now stuck on an error in
conway_polynomials-0.4.p0.
ImportError: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
(required by
/hpc/tstapps/src/sage/sage-6.4.1/local/lib/p
Le 09/01/2015 12:30, Jean-Pierre Flori a écrit :
That is easy to fix.
Just add gmp to the linked libraries in module_list.py for these files.
Indeed, this is very easy, and works like a charm. After this,
everything compiles, and a lot of things are working! (well, a lot of
things are also
On Friday, January 9, 2015 at 12:30:16 PM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Friday, January 9, 2015 at 9:49:52 AM UTC+1, Sebastien Gouezel wrote:
>>
>> The webpage http://trac.sagemath.org/wiki/Cygwin64Port indicates that
>> sage can now be built under cygwin64 almost out of the box. So
>
> That is easy to fix.
> Just add gmp to the linked libraries in module_list.py for these files.
> People should really pay attention to what they use in their code, Linux
> is just too nice.
>
This is a very, very typical Cygwin-type fix, adding additional libraries
to module_list.py - but u
On Friday, January 9, 2015 at 9:49:52 AM UTC+1, Sebastien Gouezel wrote:
>
> The webpage http://trac.sagemath.org/wiki/Cygwin64Port indicates that
> sage can now be built under cygwin64 almost out of the box. So, I tried,
> but I failed...
>
> Here are the problems I encountered, maybe someone
I didn't really follow this conversation, but it sounds like there is an
easy fix and just no one ever committed it. Is there even a ticket?
Yep, still an issue with 6.3 & 6.4 using Fedora 20 32-bit.
> My pie-neck be bugging...
>
> ...Compiling from source code is no fun; my penguin is tired.
Yep, still an issue with 6.3 & 6.4 using Fedora 20 32-bit.
My pie-neck be bugging...
...Compiling from source code is no fun; my penguin is tired.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
Hey Stephen,
I'll take this occasion to ask you whether all patches needed to build Sage
on FreeBSD are currently submitted on our trac?
If so, I might update my FreeBSD vms, try them and review them.
It would be very nice to be able to build Sage on FreeBSD from scratch.
IIRC at some point I cou
On 2014-07-21, Montgomery-Smith, Stephen wrote:
> Hey people,
>
> FreeBSD people do like to build their ports as root. The problem
> described below could be easily fixed by simply removing the group write
> permissions of all the files in the tarball upstream/pynac-0.3.2.tar.bz2.
>
> It's not su
Vincent Delecroix wrote:
Have a look at the commands
chown: change the owner/group
chmod: change permissions
What you have to do is to make /opt/sage-6.2 writable by you, not the
whole /opt. The simplest way, assuming that your username is alasdair,
is to change the owner of everything in /o
my latest mail, after I checked in the changes which I believe is
right, did not include a tar.gz file indeed. Will create one later.
E.
On Fri, Oct 4, 2013 at 7:50 PM, Andrew Fiori wrote:
> I never did figure out how to grab the latest snapshot off the gf2x dev
> site, I had been working with t
I never did figure out how to grab the latest snapshot off the gf2x dev
site, I had been working with the tarballs linked in this thread, of which
I never tested one that worked (though, I believe we determined which
changes would fix the problem).
Right now that machine is being tortured by runnin
It seems I only sent my reply to Emmanuel.
So briefly:
- Andrew: can you please confirm that the latest tarball provided by
Emmanuel is fixed?
- if that's the case, I'll open a trac ticket to update the gf2x spkg
provided by Sage and it should make its way into Sage 5.12 or 5.13.
Best,
JP
On Fr
could you pleae confirm that the fix I've committed to the gf2x main
branch fixes the issue you encounter ? This is a genuine bug which
deserves to be fixed, so:
- I care about whether my changes correct the issue.
- I don't mind creating a bugfix tarball if deemed useful.
On the other hand, if
The bug appears to be something in gf2x's configure.ac file, but as I know
little about writing config scripts it's hard to give advice.
In the meantime, here is a simple step-by-step for those who want SAGE-5.11
but have an old pre-SSE2 machine (schools & cheapskates like me):
1) Confirm that
You're right about rand(). printf() does not matter here, as using the
computed value via the return code of main() suffices to "use" the value as
far as optimization is concerned.
Checked in a new test.
E.
On Tue, Sep 24, 2013 at 10:55 AM, Andrew Fiori wrote:
> On closer inspection, the s
On closer inspection, the sse2 test code in:
http://www.loria.fr/~thome/vrac/gf2x-201309240733-4b5636d.tar.gz
the previously linked
http://www.loria.fr/~thome/vracgf2x-201309232352-49027b2.tar.gz
and the code above all compile (gcc -msse2 test.c), however when they are
run the output of:
.
On Tuesday, September 24, 2013 2:41:58 AM UTC+2, Andrew Fiori wrote:
>
> The linked tar.gz file doesn't appear to fix the problem (I am assuming
> this is what you wanted me to test).
> It still tries to compile with sse2 on the non-sse 2 machine
>
> I am attaching the config.log as well as the o
On Friday, September 20, 2013 3:01:13 PM UTC+2, Andrew Fiori wrote:
>
> This is likely a build error bug on all systems which do not support SSE2
> but where building is done using the current version of gcc. It may also
> manifest as a runtime error on binary builds installed on systems which
Jean-Pierre,
[please forward to sage-devel, since I'm not subscribed, thus my mail will
be rejected]
thank you for forwarding us that message:
> Date: Fri, 20 Sep 2013 11:36:26 -0700 (PDT)
> From: Jean-Pierre Flori
> Cc: Zimmermann Paul
>
> [1:multipart/alternative Hide]
> [1/1:text/p
Hey,
I think you should report this to the gf2x dev as well... you never know.
I've CC'ed Paul Zimmermann in case he cares.
Best,
JP
On Friday, September 20, 2013 3:01:13 PM UTC+2, Andrew Fiori wrote:
>
> This is likely a build error bug on all systems which do not support SSE2
> but where buil
I thought that its a missing dependency at first, too. But then he's
compiling sage/libs/mpmath/ext_impl.c, which is a cython file from the Sage
library. That should be after all spkgs have been installed. In fact, it
seems to be the Sage port to FreeBSD so who knows how it is being built.
Prob
On 26/12/12 23:47, Dima Pasechnik wrote:
> On 2012-12-25, Stephen Montgomery-Smith wrote:
>> On 12/25/2012 01:22 PM, Stephen Montgomery-Smith wrote:
>>> When I am building sage-5.5 inside of sage-5.5, I get the following
>>> error in my build log. I was able to build sage-5.5.rc1 with no
>>> prob
On 2012-12-25, Stephen Montgomery-Smith wrote:
> On 12/25/2012 01:22 PM, Stephen Montgomery-Smith wrote:
>> When I am building sage-5.5 inside of sage-5.5, I get the following
>> error in my build log. I was able to build sage-5.5.rc1 with no
>> problem. Am I unique with this problem? I am buil
>> Do you see any problem with using the mount defaults for /dev/pts
>> (rw,noexec,nosuid,gid=5,mode=0620) from the container system inside
>> the chroot system?
>
> Should IMHO work.
Just tested it. It indeed works. My sageserver user can now run Sage
(plus other pts stuff... sshd and so on) with
On 14 Aug., 20:30, Jason B Hill wrote:
> >> How about /dev/pts ?
>
> /dev/pts was indeed mounted. But, the generic mount-defaults file in
> schroot mounted it as:
>
> /dev/pts (chroot_path)/dev/pts none defaults 0 0
>
> and this (a bit curiously) mounts it with permissions 0600. So, the
>> How about /dev/pts ?
/dev/pts was indeed mounted. But, the generic mount-defaults file in
schroot mounted it as:
/dev/pts (chroot_path)/dev/pts none defaults 0 0
and this (a bit curiously) mounts it with permissions 0600. So, the
script you posted (along with a bunch of other stuff)
On 13 Aug., 03:34, leif wrote:
> On 13 Aug., 00:24, Jason B Hill wrote:
>
> > It actually doesn't appear to give an error then. Under both root and
> > sageserver users in the chroot, I get the
>
> > ... stuff + gap version + stuff ... 62+@&67542+@ngap>
>
> > prompt.
>
> How about /dev/pts ?
>
>
On 13 Aug., 00:24, Jason B Hill wrote:
> It actually doesn't appear to give an error then. Under both root and
> sageserver users in the chroot, I get the
>
> ... stuff + gap version + stuff ... 62+@&67542+@ngap>
>
> prompt.
How about /dev/pts ?
(/opt/sage/local/lib/python2.6/site-packages/sage/
On 2011-02-03 15:02, Volker Braun wrote:
> Use "make distclean" to evict every file than doesn't pay rent. The next
> "make" will compile everything from scratch.
This might be true, but I still agree with Dima that "make clean" should
also clean all spkgs.
--
To post to this group, send an emai
On 02/ 2/11 04:50 PM, Volker Braun wrote:
On Wednesday, February 2, 2011 3:55:27 PM UTC, Dr. David Kirkby wrote:
There is never any point in setting SAGE64=no. [...] ONLY if it is set
to "yes" will anything different happen. That is usually adding the
compiler flag "-m64", though in some cases
Use "make distclean" to evict every file than doesn't pay rent. The next
"make" will compile everything from scratch.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options,
On Wednesday, February 2, 2011 7:52:08 PM UTC, John H Palmieri wrote:
>
> if [ "$SAGE64" = "yes" ]; then
>echo "64 bit build"
>CFLAGS="-O2 -g -fPIC -m64 "; export CFLAGS
>LDFLAGS="-m64"; export LDFLAGS
> fi
>
Just overwrite CFLAGS/LDFLAGS, no ap/prepending? Nice.
if [ "x`uname -sm`" =
On Wednesday, February 2, 2011 8:50:36 AM UTC-8, Volker Braun wrote:
>
> Dave, can you elaborate on what SAGE64 is good for besides adding -m64?
> Adding the compiler flag could easily be done in the gcc wrapper:
>
> http://trac.sagemath.org/sage_trac/ticket/10572
>
> Sorry if this is slightly O
On Wednesday, February 2, 2011 3:55:27 PM UTC, Dr. David Kirkby wrote:
>
> There is never any point in setting SAGE64=no. [...] ONLY if it is set
> to "yes" will anything different happen. That is usually adding the
> compiler flag "-m64", though in some cases it's a bit more complex.
>
Dave, can y
On 1 February 2011 20:17, jtyard wrote:
> Thanks Georg,
>
> Before I posted my question, I had tried an earlier build with
> SAGE64="yes", but (of course) that didn't work and I received the same
> error that I posted. Then I had set SAGE64="no", tried again and got
> the same error.
There is ne
Dima,
It looks like it is getting set pretty early, so I'm just posting here
the beginning of the install.log, rather than the whole huge file.
But it sounds to me that somehow the problem is that "make clean"
leaves too much behind. For instance, it seems to want to start
building r right away,
Thanks Georg,
Before I posted my question, I had tried an earlier build with
SAGE64="yes", but (of course) that didn't work and I received the same
error that I posted. Then I had set SAGE64="no", tried again and got
the same error. I then ran "make clean" and got the same error. I
even reboote
It would be useful if you put the complete install.log somewhere, so
that one could see where the 64-bit setting comes from...
On Jan 29, 7:02 am, Jon Yard wrote:
> Hello,
>
> I am having trouble building sage 4.6.1 on an iMac8,1 (2.4 GHz Intel Core 2
> Duo) running OS X 10.5.8. Below is the las
Hmm,
the important information seem to be:
a)
You try to build Sage on Mac OS X 10.5 (Leopard).
b)
There's a "-m64" in the third line of your output, i.e. the build
system tries to build a "64-bit" library.
(Then it seems that qdCocoa.o is only a 32-bit object file, hence
rejected, hence later s
On Nov 7, 4:33 am, "Dr. David Kirkby" wrote:
> On 11/ 7/10 10:50 AM, rafaelf wrote:
>
> > I don't know if this can be considered a bug: it seems that source
> > files are generated via 'grep', but if the variable $GREP_OPTIONS
> > contains '--color=always', these sources won't compile because of t
On 23 September 2010 10:42, Volker Braun wrote:
> Something is wrong with escaping the quotation marks in the gcc call.
> How are you implementing the delay? Are you sure it preserves shell
> escapes? If anything it seems to be a bug in the shell or make, but
> not sqlite.
>
> Cheers,
> Volker
Y
On Sep 23, 12:11 am, "Dr. David Kirkby"
wrote:
> gcc "-DPACKAGE_NAME=\"sqlite\"" "-DPACKAGE_TARNAME=\"sqlite\""
> "-DPACKAGE_VERSION=\"3.6.22\"" "-DPACKAGE_STRING=\"sqlite 3.6.22\""
> "-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\""; "-DPACKAGE=\"sqlite\""
> "-DVERSION=\"3.6.22\"" -D_FILE_OFFSET_
4.0.1. built successfully.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/g
On Jun 16, 4:56 pm, Minh Nguyen wrote:
> Do you also get the same/similar errors if you build Sage 4.0.1 from
> source? It looks like you were trying to build version 3.4.
>
> --
> Regards
> Minh Van Nguyen
I downloaded 3.4 because it was the most recent source version from
the Boston mirror. R
Minh Nguyen wrote:
> This looks to me like your system was overloaded or something (just a
> guess). But can you give some information about your hardware, like
> CPU speed, etc.
>
Would it not be sensible for Sage to at least give an option of
continuing if ATLAS can't be optimized? The fact
On Wed, Jun 17, 2009 at 6:36 AM, bparkis wrote:
>
>> This looks to me like your system was overloaded or something (just a
>> guess). But can you give some information about your hardware, like
>> CPU speed, etc.
>>
>> --
>> Regards
>> Minh Van Nguyen
>
> Intel core duo, dual core 1.83 Ghz, cac
On Jun 16, 4:15 pm, Minh Nguyen wrote:
> Hi,
>
>
>
> On Wed, Jun 17, 2009 at 4:23 AM, bparkis wrote:
>
> > I'm on Ubuntu-8.04 on an i386 Macbook using KDE. Kernel is 2.6.24-21-
> > server.
>
> > The install log is 45 megs, so here's just the last stage where it
> > failed:
>
> > STAGE 2-4-5:
Hi,
On Wed, Jun 17, 2009 at 4:23 AM, bparkis wrote:
>
> I'm on Ubuntu-8.04 on an i386 Macbook using KDE. Kernel is 2.6.24-21-
> server.
>
> The install log is 45 megs, so here's just the last stage where it
> failed:
>
> STAGE 2-4-5: GEMV TUNE
> make -f Makefile INSTALL_LOG/cMVRES pre=c 2>&1 |
How far away is the eMPIRe spkg? Isn't it about time we got that up?
It should resolve a number of issues.
Bill.
On 27 Oct, 18:57, mabshoff <[EMAIL PROTECTED]> wrote:
> On Oct 27, 11:47 am, mcelis <[EMAIL PROTECTED]> wrote:
>
> > Forgot to mention it is SAGE 3.1.4
>
> > On Oct 27, 11:44 am, mcel
On Oct 27, 11:47 am, mcelis <[EMAIL PROTECTED]> wrote:
> Forgot to mention it is SAGE 3.1.4
>
> On Oct 27, 11:44 am, mcelis <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I am trying to build SAGE on a SiCortex machine with MIPS processors
> > running Linux Gentoo Base System release 1.12.12.
> >
Forgot to mention it is SAGE 3.1.4
On Oct 27, 11:44 am, mcelis <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying to build SAGE on a SiCortex machine with MIPS processors
> running Linux Gentoo Base System release 1.12.12.
>
> The build/install for libpari-gmp failed (results below). I believe it
>
Yep, I'm using gcc 4.3.0.
On Apr 10, 11:07 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Apr 11, 5:02 am, Walt <[EMAIL PROTECTED]> wrote:
>
>
>
> > Just got this build error that told me to post it here:
>
> > mpn_extras.o:mpn_extras.c:(.text+0x2630): first defined here
> > collect2: l
On Apr 11, 5:02 am, Walt <[EMAIL PROTECTED]> wrote:
> Just got this build error that told me to post it here:
>
> mpn_extras.o:mpn_extras.c:(.text+0x2630): first defined here
> collect2: ld returned 1 exit status
> make[2]: *** [libflint.so] Error 1
> make[2]: Leaving directory `/home/zarathustr
On Aug 31, 2:30 am, William Stein <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Sage on Linux ppc64 is definately *not*
> supported. Nobody has ever built any version of sage on that
> architecture. I would be interested in doing a port if someone were
> handing out accounts on such a machine...
>
I w
Hi,
Sage on Linux ppc64 is definately *not*
supported. Nobody has ever built any version of sage on that
architecture. I would be interested in doing a port if someone were
handing out accounts on such a machine...
- William
(Sent from my iPhone.)
On Aug 30, 2007, at 3:26 PM, Lukas <[EMA
Same error occurs with rc3. Pity.
As far as i know Mac Pro machines are moving to Intel now..
Thanks for all the help anyways.
L
On Aug 30, 3:23 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> Hello,
>
> On Aug 30, 9:10 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:
>
> > There is now a rc
Hello,
On Aug 30, 9:10 pm, "David Joyner" <[EMAIL PROTECTED]> wrote:
> There is now a rc3 athttp://sage.math.washington.edu/home/was/dist/s/dist/
> Can you try it too and let us know if it has the same problem?
>
Lukas should try, but I doubt it will help. The problem is that
building Sage under
There is now a rc3 at http://sage.math.washington.edu/home/was/dist/s/dist/
Can you try it too and let us know if it has the same problem?
++
On 8/30/07, Lukas Diduch <[EMAIL PROTECTED]> wrote:
>
> - build failed for libiml @ linking stage
>
> replacing '/local/home/ldemo/softwar
On Thu, 25 Jan 2007 00:03:02 -0800, Robert Miller <[EMAIL PROTECTED]> wrote:
>
> Awesome. Not only is my confusion cleared, but the option that was
> causing it no longer exists...
Yep. This confused everybody! The code to do it is still in the
script SAGE_ROOT/local/bin/sage-sage, but it's
Awesome. Not only is my confusion cleared, but the option that was
causing it no longer exists...
On Jan 24, 11:45 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> I think it's a distinction between packages (optional or otherwise)
> and the core sage library (found in devel/sage/...). The latter
I think it's a distinction between packages (optional or otherwise)
and the core sage library (found in devel/sage/...). The latter is
under the repository and you can have many branches ("clones")
whereas the former is not.
- Robert
On Jan 24, 2007, at 11:39 PM, Robert Miller wrote:
> Ok
A relevant conversation with William, earlier:
William wrote:
>> By the way, what are the differences between the following?
>>
>> sage -update
>
>This is the first step of doing "sage -upgrade". It downloads new
>packages but doesn't apply them. It confuses WAY more people (at least 3)
>than i
"sage -update" is not supported in 1.8.2.1 which is out. I got it
confused with upgrade.
On 1/24/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> So I guess -update followed by -update-build /should/ be the same as -
> upgrade then. Let me know if that works.
>
> On Jan 24, 2007, at 11:31 PM, a
Ok, I think I know a little more about what went wrong:
After doing sage -update-build, sage compiles just fine. My assumption
was that
sage -update
sage -br
would do the trick, but it seems as if sage -br doesn't build the
downloaded updates... I'm wondering, what does sage -br actually do?
Wh
So I guess -update followed by -update-build /should/ be the same as -
upgrade then. Let me know if that works.
On Jan 24, 2007, at 11:31 PM, alex clemesha wrote:
> if you type 'sage -advanced' you get an explanation
> of all possible flags:
>
> (at the bottom:)
>
> -update -- download la
if you type 'sage -advanced' you get an explanation
of all possible flags:
(at the bottom:)
-update -- download latest non-optional SAGE packages (do not build
them)
-update-build -- build and install all downloaded non-optional SAGE
packages
-upgrade -- download, build and install
Ok, I got it mixed up, what I did was -update followed by -br. Point
is, after update, my sage fails to build.
On Jan 24, 11:27 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> Yeah, upgrade != update (though to be honest I don't know the
> intricacies of the differences).
>
> On Jan 24, 2007, at
Yeah, upgrade != update (though to be honest I don't know the
intricacies of the differences).
On Jan 24, 2007, at 11:26 PM, Robert Miller wrote:
> Look carefully at my previous post: all I did was sage -upgrade
> followed by sage -br.
>
> On Jan 24, 11:23 pm, Robert Bradshaw <[EMAIL PROTECTED
Look carefully at my previous post: all I did was sage -upgrade
followed by sage -br.
On Jan 24, 11:23 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> Doesn't look like it got the new sagex package, have you tried sage -
> upgrade?
>
> On Jan 24, 2007, at 11:14 PM, Robert Miller wrote:
>
> > Thi
Doesn't look like it got the new sagex package, have you tried sage -
upgrade?
On Jan 24, 2007, at 11:14 PM, Robert Miller wrote:
> This only emphasizes my frustration with mercurial:
>
> robert-millers-powerbook-g4-12:/Volumes/DATA/sage-1.7 robert$ sage
> -update
> Using SAGE Server http://sag
This only emphasizes my frustration with mercurial:
robert-millers-powerbook-g4-12:/Volumes/DATA/sage-1.7 robert$ sage
-update
Using SAGE Server http://sage.math.washington.edu/sage//packages
http://sage.math.washington.edu/sage//packages/install --> install
[.]
http://sage.math.washington.edu/sa
You have an old old version of sagex, which is before Robert Bradshaw
added support for "+=" (etc.). You must do
sage -upgrade
not just hg_sage.pull(), which only gets the Python/SageX library code.
In particular, Nick's guess is exactly right:
On Wed, 24 Jan 2007 19:23:58 -0800, Nick Ale
Just a guess, but I believe that in place update (+=, *=) were just
added to sagex. You might try updating that package.
Nick
Robert Miller wrote:
> Getting the following error when building the latest version of SAGE:
>
> robert-millers-powerbook-g4-12:/Volumes/DATA/sage-1.7 robert$ sage -br
>
89 matches
Mail list logo
