On Jan 27, 2010, at 11:24 AM, Dr. David Kirkby wrote:
Robert Bradshaw wrote:
On Jan 27, 2010, at 8:22 AM, Dr. David Kirkby wrote:
Martin Albrecht wrote:
People often CC me onto tickets to test on Solaris.
Unfortunately, I
don't have the time to test every patch on Solaris.
Nor do I. Or test every patch on all of Ubuntu, RedHat, Debian, OS
X, etc. (and soon Cygwin), though building on Solaris seems to be
touchier than most systems. We should put Solaris/OpenSolaris one
one of the build farm VMs at least, so the release manager can
bounce patches that don't work there.
It does not seem unreasonable to check ones patches on Solaris, OS X
and one linux distro.
I would say that this is unreasonable. Especially for casual or first-
time contributors. But we've had this discussion before. Long term,
the solution is to automate; there was some talk about and even some
works towards this at the last Sage days.
Of course it does not guarantee it will work on every linux distro,
but it would have a reasonable probability of doing so.
I believing have a week after the last release candidate before
something is released would help.
Solaris 10 on SPARC can not go onto a virtual machine. VirtualBox
only support the x86 processors, not SPARC.
Solaris 10 on x86 could be installed in Virtualbox, but I don't know
how well Sage would work on that. My guess is there would be some
issues which would need resolving.
I'm sure that having any Solaris, even a virtualized x86 one, as part
of the existing build farm setup would be a step forward. You're
probably right about there being outstanding issues.
Fortunately the vast majority of patches shouldn't break anything
on this level.
The biggest problem seems to be to the Sage library. That's mainly
where there needs to be more testing on Solaris. The
individual .spkg files seem to present less problem.
I find this surprising--most of the Sage library is pure Python (which
should be platform independent, and most of the dependance is in stuff
like / vs \ for paths which is only an issue for Windows porting), or
Cython (which again should be platform independent for most of the
code (please file bugs if its not), and over half of the modules don't
link against anything but math and gmp). Of course, there are probably
some nasty surprises in there as well (libsingular always seems a bear
to port...)
There is general documentation on building on Solaris at
http://wiki.sagemath.org/solaris
However, it might be useful to have some very specifically for
't2'. I'll write some documentation on that and put it on the
Wiki. However, in the short term, the following will set up
everything on 't2' properly.
Thanks. I remember wanting to test something on Solaris a while
back and I didn't do it simply because I didn't have a clue how to
get a working Sage on t2, or even start compiling it.
Fair enough. I'll write something on that. But it would be good if I
had a release that I can tell people to build - currently there is
no way to get a successful build on t2 unless I disable the Sun
compilers. But the fix for that is in trac
Of course it's a chicken and egg problem--until one can just unpack
the sources and type make fewer people will bother to test on that
platform.
That and t2 is so slow for building and testing.
That is I admit very unfortunate. The machine is very badly suited
for what it is being used for.
For sure. Our webserving needs are much smaller at the moment (now
that we have mirriors to handle the heavy lifting of binary downloads).
Hence I believe there is some merrit in producing a 4.3.0.1, which
has the one patch needed to get Sage to build irrespective of
whether the Sun compilers are installed. That would avoid users
needing root access to build Sage.
Depending how immediate the need is, could it wait 'till 4.3.2? Or
are you worried something else Solaris will break by then?
There are several reasons I feel a 4.3.0.1 would be desirable.
Or would that be 4.3.1.1?
* I'm worried that the current issue wont be fixed 4.3.2 - it is not
obvious to me what the problem is. It's in the Sage library
somewhere. I don't understand that well enough, but with auto
generated code, it is less easy to understand.
There were tons of patches in that release, so that makes the task
even more difficult.
* With something that worked, I could produce some instructions
which allow someone to build Sage on 't2', without taking the step
of disabling compilers. It would then be relatively easy for someone
to build Sage on t2 and in most cases check their changes would be
easy to test.
* It would be good to have a release that worked, so Solaris users
could use it. I know some at Sun are quite keen to use it. Saying it
works if Sun Studio is not installed is not very nice. Most people
will have that installed, and most wont have the ability to disable
it, as it needs root access.
* William was asked recently by Sun whether there was anything they
could point users at.
If you volunteered to be release manager I don't think anyone would
disapprove.
I don't understand Mercurial that well. It is not a job I would
fancy doing I must admit.
It'd be a matter of applying the tickets and getting sufficient
testing. I don't have the time to do it, and I'm not sure who else
would volunteer.
I can understand it is not the easiest of tasks - I do admire anyone
that takes that role on.
Same here.
- Robert
--
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, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
