No, it fails. The first significant error I can see is an invalid
syntax for the assembler, which by the way is the GNU assembler
version 2.20.
gcc -fPIC -m32 -x assembler-with-cpp -DL2SIZE=4194304
-I/export/home/drkirkby/unsets/sage-5.13.beta0/spkg/build/atlas-3.10.1.p6/ATLAS-build/include
-I/exp
Trac seems to not work, but update spkg is here:
http://boxen.math.washington.edu/home/vbraun/spkg/atlas-3.10.1.p6.spkg
Please test and let us know if you get any further...
On Saturday, October 12, 2013 12:14:03 AM UTC+1, Volker Braun wrote:
>
> Updated spkg at http://trac.sagemath.org/15270
>
Updated spkg at http://trac.sagemath.org/15270
On Saturday, October 12, 2013 12:05:58 AM UTC+1, Volker Braun wrote:
>
> No, thats not it. I used unlink and rm interchangeably. Its weird that
> unlink is superuser-only on that system but then its not used.
>
> The problem seems to be that you can'
No, thats not it. I used unlink and rm interchangeably. Its weird that
unlink is superuser-only on that system but then its not used.
The problem seems to be that you can't delete the current directory (cwd)
on that particular filesystem. On all other platforms thats not an issue.
I'll update t
The file system is the 128-bit ZFS. I could delete the directory using
rmdir. But a look at the man page for unlink says
"Only super-users can use these commands on directories."
so that is why it is failing. See below for part of the man page
drkirkby@hawk:~$ man unlink
Reformatting page.
I think the gcc -V is not a problem, just the ATLAS build system trying out
options.
It dies when it is unable to delete
/export/home/drkirkby/unsets/sage-5.13.beta0/spkg/build/atlas-3.10.1.p5/ATLAS-build,
whats up with that directory? Is there some weird filesystem that disallows
unlink for
Thanks!
The trac<->git changeset browser obviously has to grind through the repo
all the time, so this is the likely candidate for io load. But the repo
isn't all that large all things considered, it should easily fit into
memory. Some filesystem tuning might be really benefitial, in particular
I reported earlier that ATLAS breaks on SPARC, but it is breaking on
OpenSolaris too, so I would expect it to break on Solaris 12 too. The
reason it breaks on OpenSolaris seems a bit odd - a bad flag (-V) is
sent to gcc. So it is a non-GNUism !!!
drkirkby@hawk:~/unsets/sage-5.13.beta0$ cat /etc/re
The physical machine that Trac is running has been experiencing heavy disk
IO from different processes for the past 3 days, which is likely
contributing to the problems. The image file is also located on a ZFS
volume, and I've seen odd issues with ZFS recently. I think I will move
Trac to the n
Yes, we should allow indexing of tickets but not of the timeline and the
changeset browser.
On Friday, October 11, 2013 8:32:15 PM UTC+1, William wrote:
>
> On Fri, Oct 11, 2013 at 11:55 AM, Volker Braun
> >
> wrote:
> > Trac isn't using any swap. It is pulling quite a lot of CPU load.
> Loo
On Fri, Oct 11, 2013 at 11:55 AM, Volker Braun wrote:
> Trac isn't using any swap. It is pulling quite a lot of CPU load. Looking at
> the log, it seems somebody is indexing trac and pulling up old changesets
> and timeline (both are notoriously slow in trac). For example:
>
> http://trac.sagemath
Trac isn't using any swap. It is pulling quite a lot of CPU load. Looking
at the log, it seems somebody is indexing trac and pulling up old
changesets and timeline (both are notoriously slow in trac). For example:
http://trac.sagemath.org/timeline?from=2009-05-06T13%3A17%3A39-07%3A00&precision=s
I'm guessing it was set up to build Sage faster, but whoever
configured the buildbot would have done that. I very much doubt it is
done system wide, but I can't' recall my login details on that machine
to check.
Dave
On 11 October 2013 17:12, Jeroen Demeyer wrote:
> On 2013-10-11 15:59, Dr. Dav
On Fri, Oct 11, 2013 at 9:52 AM, William Stein wrote:
> On Fri, Oct 11, 2013 at 9:39 AM, Jean-Pierre Flori wrote:
>> Is it down again ?
>
> It's down. At the moment, I think Keith is the only one who knows how
> to fix it easily, so we should probably wait for him to wake up /
> check his email.
On Fri, Oct 11, 2013 at 9:39 AM, Jean-Pierre Flori wrote:
> Is it down again ?
It's down. At the moment, I think Keith is the only one who knows how
to fix it easily, so we should probably wait for him to wake up /
check his email. I'm sure he'll take additional steps today to make
trac more r
Is it down again ?
--
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...@googlegroups.com.
To post to this group, send email to sage-devel@googleg
On 2013-10-11 15:59, Dr. David Kirkby wrote:
On 11 October 2013 14:02, Jeroen Demeyer wrote:
Also compare with this, a successful build of ATLAS on a similar machine:
http://build.sagemath.org/sage/builders/Skynet%20mark%20%28SunOS%205.10-32%29/builds/353/steps/shell_5/logs/atlas
But that is
On Fri, Oct 11, 2013 at 9:01 AM, kcrisman wrote:
>
>
>> If you haven't been following the LMS scene for a while, a new AGPL
>> competitor is on the scene - with over 200 employees.
>>
>> http://voice.instructure.com/blog/bid/148942/Our-Open-Source-Strategy
>>
>> Interesting points, and of course t
If you haven't been following the LMS scene for a while, a new AGPL
> competitor is on the scene - with over 200 employees.
>
> http://voice.instructure.com/blog/bid/148942/Our-Open-Source-Strategy
>
> Interesting points, and of course the question of whether it stays open
> remains...
>
Thoug
If you haven't been following the LMS scene for a while, a new AGPL
competitor is on the scene - with over 200 employees.
http://voice.instructure.com/blog/bid/148942/Our-Open-Source-Strategy
Interesting points, and of course the question of whether it stays open
remains...
--
You received th
There is some discussion about the licence issue on ecl mailing list.
Juan did not reply yet.
http://sourceforge.net/p/ecls/mailman/ecls-list/thread/E1VTECl-ZM-2W%40hera.math.uni.wroc.pl/#msg31493829
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gr
On Oct 11, 2013 7:51 AM, "Dima Pasechnik" wrote:
>
> Hi, this might have a negative effect on Sage's lisp support status.
> Just in case.
> -- Forwarded message --
> From: "Juan Jose Garcia-Ripoll"
> Date: 7 Oct 2013 09:55
> Subject: [Ecls-list] Project status and changes (please
Hi, this might have a negative effect on Sage's lisp support status.
Just in case.
-- Forwarded message --
From: "Juan Jose Garcia-Ripoll"
Date: 7 Oct 2013 09:55
Subject: [Ecls-list] Project status and changes (please read)
To: "list-ecl"
Cc:
> Hi everybody,
>
> as you may have n
I confirm it fails in the same way for me and agree with VOlker: we don't
care if upstream shared stuff fails at the moment.
On Friday, October 11, 2013 4:32:08 PM UTC+2, Volker Braun wrote:
>
> We can just ignore the error and continue with our own libtool-based
> library build. This is now htt
We can just ignore the error and continue with our own libtool-based
library build. This is now http://trac.sagemath.org/15270
On Friday, October 11, 2013 2:59:20 PM UTC+1, Dr David Kirkby wrote:
>
> On 11 October 2013 14:02, Jeroen Demeyer >
> wrote:
> > Also compare with this, a successful
On 11 October 2013 14:02, Jeroen Demeyer wrote:
> Also compare with this, a successful build of ATLAS on a similar machine:
> http://build.sagemath.org/sage/builders/Skynet%20mark%20%28SunOS%205.10-32%29/builds/353/steps/shell_5/logs/atlas
But that is not building ATLAS! The system has a pre-ins
On Oct 11, 2013 5:58 AM, "Jeroen Demeyer" wrote:
>
> It seems we will lose access to rosemary.math.uga.edu. If you have
anything there, make sure it's backup up!
>
> Too bad, it was the most reliable and one of the fastest buildbot
machines we had... R.I.P.
>
>
> On 2013-10-11 14:52, "José R. Mala
On Oct 11, 2013 12:00 AM, "Jeroen Demeyer" wrote:
>
> Should we mention in the Sage manual (for example, here:
http://www.sagemath.org/doc/installation/quick-guide.html) that it is
entirely possible to run Sage without actually installation, using
SageMathCloud?
>
Yes, since this (+sage cell) wil
Also compare with this, a successful build of ATLAS on a similar machine:
http://build.sagemath.org/sage/builders/Skynet%20mark%20%28SunOS%205.10-32%29/builds/353/steps/shell_5/logs/atlas
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscr
It seems we will lose access to rosemary.math.uga.edu. If you have
anything there, make sure it's backup up!
Too bad, it was the most reliable and one of the fastest buildbot
machines we had... R.I.P.
On 2013-10-11 14:52, "José R. Malagón" wrote:
Hi,
Jon Hanke is no longer affiliated with U
It failed again after typing "make". I attached the original log as
you requested, but if you want the new one, which is likely to be
twice the size, then I can do that too.
BTW, I am purposly using an old version of Solaris 10
drkirkby@buzzard:~$ cat /etc/release
Solaris
On Friday, October 11, 2013 3:00:05 AM UTC-4, Jeroen Demeyer wrote:
>
> Should we mention in the Sage manual (for example, here:
> http://www.sagemath.org/doc/installation/quick-guide.html) that it is
> entirely possible to run Sage without actually installation, using
> SageMathCloud?
>
>
Do
Hi,
I'm using sage 5.11 (built from developer source code). I have written some
python scripts that I want to call within sage.
I copied my source files into my sage path but when I call *
sage:load("file_name.py")* sage fails to find some imported modules in my
code.
p.s. all source files and dep
(and I'm using the Sun ld as well)
On Friday, October 11, 2013 1:11:52 PM UTC+2, Jean-Pierre Flori wrote:
>
> I'm currently building sage 5.12 as well on sparc/solaris, I'll report the
> status of ATLAS for me here.
>
> On Friday, October 11, 2013 11:43:27 AM UTC+2, Volker Braun wrote:
>>
>> Ther
I'm currently building sage 5.12 as well on sparc/solaris, I'll report the
status of ATLAS for me here.
On Friday, October 11, 2013 11:43:27 AM UTC+2, Volker Braun wrote:
>
> There are two attempts to build shared libraries, once using upstream's
> method of a hand-crafted makefile (in ATLAS-bui
There are two attempts to build shared libraries, once using upstream's
method of a hand-crafted makefile (in ATLAS-build) and then once more with
our own libtool-based system (in ATLAS-lib). Your failure is in the former.
The build should have proceeded with another attempt. Post the full build
I know someone made some fairly major changes to the ATLAS package
some time ago, which are probably the cause of a new bug.
There is a problem on Solaris SPARC (but not necessarily x86) if the
linker is the Sun one (which is the best choice), and not the GNU
linker.
When ATLAS is configured, it
Should we mention in the Sage manual (for example, here:
http://www.sagemath.org/doc/installation/quick-guide.html) that it is
entirely possible to run Sage without actually installation, using
SageMathCloud?
Jeroen.
--
You received this message because you are subscribed to the Google Groups
38 matches
Mail list logo
