Can a 4.3.5 be created to fix the Fedora/Mandriva/OpenSUSE build problem?
Dr. David Kirkby
prevent 4.3.4 building on several linux distros.
A patch is here:
http://trac.sagemath.org/sage_trac/ticket/8567
If that is added, Sage should build ok on these linux distros, which otherwise
do not like it when there are two copies of iconv (system install and $SAGE_LOCAL)
Dave
Jaap Spies
+1
Jaap
>
> Dave
>
William Stein
I'll make such a release, hopefully tomorrow. I'm also going to
include #8612 and #8539, which are blocker bug fixes.
William
William Stein
I just want to record in this thread that just now when preparing the
Ubuntu-based VirtualBox Sage for Windows, I built sage-4.3.4. I then
did "sage -upgrade", and the result did not work due to some weird
iconv issue that appeared when importing the Sage library. I then
manually forced installation of the iconv spkg (even though it is
supposed to be disabled on Ubuntu), and then everything worked.
So probably we're still going to have trouble with 4.3.5 and iconv.
-- William
Dr. David Kirkby
Could it be a forward compatibility issue?
1) Sage 4.3.4 contains the latest iconv (1.13.1)
2) Code is Sage tests iconv, finds it's a late version, and makes use of the
features in the the latest version.
3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.
4) After 'sage -upgrade' the system supplied iconv is the only iconv package
available. Any code which relied on new features in the latest iconv library
suddenly breaks, as those features no longer exist.
Note, the iconv package I created deletes old copies of itself, as spkg-install
contains:
-------------------
echo "Removing old iconv files if they exist"
# If iconv is updated, please double-check these are still necessary
# and that there are no extra files added.
rm -f $SAGE_LOCAL/bin/iconv $SAGE_LOCAL/lib/charset.alias
rm -f $SAGE_LOCAL/lib/*libiconv* $SAGE_LOCAL/lib/libcharset*
rm -f $SAGE_LOCAL/include/iconv.h $SAGE_LOCAL/include/libcharset.h
rm -f $SAGE_LOCAL/include/localcharset.h
rm -rf $SAGE_LOCAL/share/doc/libiconv
rm -f $SAGE_LOCAL/share/man/man1/iconv* $SAGE_LOCAL/share/man/man3/iconv*
# Only build iconv on Solaris and Cygwin
if [ "x$UNAME" != xSunOS ] && [ "x$UNAME" != xCYGWIN ] ; then
echo "iconv will not be installed, as it is only installed on"
echo "Solaris and Cygwin - see:"
echo "http://trac.sagemath.org/sage_trac/ticket/8567"
exit 0
fi
echo "Installing iconv as the operating system is Solaris or Cygwin"
------------------------
If iconv becomes a major issue, then perhaps downgrading R, which needed iconv,
might be a sensible solution. The ticket on which R was updated:
http://trac.sagemath.org/sage_trac/ticket/6532
has the title "Make R build with recommended packages". The purpose of the
ticket was never to update R, but the update was an incidental change. The
ticket says:
"Incidentally, we might as well upgrade now too - see
http://www.r-project.org/, where 2.10.0 has been released, and in a few days
2.10.1 will be."
Note there is a comment from Peter Jeremy "At least on FreeBSD, r-2.10.1 is more
broken than r-2.9.2."
Given all the iconv issues were a result of updating R, which was not done in
response to any need to update R, but rather a "we might as well upgrade", the n
downgrading R would not be such a big loss in my opinion.
That said, the iconv package will not build on anything except Solaris or
Cygwin, so I suspect the the .spkg removes iconv could be the problem. The 'sage
-upgrade' will actually *downgrade* the version of iconv. That downgrade might
be the cause of the problems.
dave
William Stein
Yes, I'm sure this is the problem. Thus your iconv package in
sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade...
Can you make a version of the spkg that doesn't delete the previous
version on operating systems where iconv isn't going to be installed?
I.e., make an spkg asap that tests if not on solaris or cygwin, and in
that case immediately exits. This test should be first, before
anything else.
I can then post that spkg online, so "sage -upgrade" isn't broken.
-- William
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
> To unsubscribe, reply using "remove me" as the subject.
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
David Kirkby
> On Tue, Mar 30, 2010 at 4:33 PM, Dr. David Kirkby
>> Could it be a forward compatibility issue?
>>
>> 1) Sage 4.3.4 contains the latest iconv (1.13.1)
>>
>> 2) Code is Sage tests iconv, finds it's a late version, and makes use of the
>> features in the the latest version.
>>
>> 3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.
>>
>> 4) After 'sage -upgrade' the system supplied iconv is the only iconv package
>> available. Any code which relied on new features in the latest iconv library
>> suddenly breaks, as those features no longer exist.
>>
>> Note, the iconv package I created deletes old copies of itself, as
>> spkg-install contains:
>
> Yes, I'm sure this is the problem.
I only postulated this. I'm certainly not sure it is the reason,
though I suspect quite strong it is.
> Thus your iconv package in
> sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade...
No it will not. It will only be version 4.3.4, as that is the only
version which will have installed iconv. The iconv package never
existed in earlier releases.
> Can you make a version of the spkg that doesn't delete the previous
> version on operating systems where iconv isn't going to be installed?
> I.e., make an spkg asap that tests if not on solaris or cygwin, and in
> that case immediately exits. This test should be first, before
> anything else.
>
> I can then post that spkg online, so "sage -upgrade" isn't broken.
>
> -- William
I can do that, but it will have to wait until the weekend, as I am
tied up and are not at home. I don't have time to create the revised
spkg and test it.
I believe this incident highlights a number of issues I've raised
before, but sometimes I feel I'm hitting my head against a wall.
1) Firstly R get's updated without testing on Solaris, so it broke
Sage 4.3.3 on Solaris, because the latest R needs iconv.
This shows a lack of testing to me. (See also point 5 below).
2) The fact R's configure script indicated the option to disable iconv
was not a valid option was ignored.
3) Iconv had to be hurriedly put into Sage as a standard package
(bypassing optional) in order for Sage to build on Solaris again.
With adequate testing of R, this would not have been necessary.
4) Having a global iconv and one in Sage caused problems on some linux
distributions. One of the libtool developers has told me this is a
fundamentally flawed method. He was not surprised when there was a
similar issue with another library, with the linker reporting two
copies of the same library.
I must admit, I thought LD_LIBRARY_PATH would take care of that, but
it is clear that multiple copies of the header files will be included
when building iconv - or any other library for that matter.
I don't know a totally satisfactory solution to this, but I believe
the current method does have a fundamental flaw. When one of the main
libtool developers tells me it is flawed, and he is not surprised we
get problems, I tend to worry.
5) The new iconv package I created was merged into Sage 4.3.4, without
it being fully tested. I personally confirmed it worked on sage.math
(Linux - I don't know what distribution), bsd.math (OS X), t2.math
(latest Solaris 10 release) and one of my own Solaris machines (first
Solaris 10 release). But the iconv package was *not* tested on all
supported platforms before a release was made.
To me, the release system is fundamentally flawed. I believe the
release managers should wait for confirmation from at least one
developer (preferably 2 or 3), that Sage builds on each supported
platform before the release is made. Instead, 4.3.3 was released
without confirmation Sage built on Solaris, and 4.3.4 was released
without confirmation Sage built on SUSE, Fedora and what other
supported platforms it broke on.
I don't have time to find it now, but I've made the analogy before
about how F1 teams tell the driver to go after there is confirmation
that the process of changing tyres and/or refueling have been
completed.
It so happens in this case, Jaap Spies actually raised the issue Sage
4.3.4.alpha0 was broken on Fedora, but that was not noticed by the
release manager. I don't critise the release manager for this, as it
is unreasonable for them to notice every single email.
But I believe the method should change to "Don't release until there
is confirmation Sage builds on every supported platform". Currently
the method is "Release if we don't see a report of a breakage".
In fact, the method for Solaris has been even worst, as when I created
a blocker ticket on some earlier release the build got broken on
Solaris, (some other reason), the release still went ahead.
6). I believe the release numbers (X.Y.Z) should indicate something
useful, not be semi-random. If this was done, it would be possible to
allow 'sage -upgrade' to work if the changes are small (i.e. only if Z
changes).
7) I've made the point before that there could be issues if Sage
binaries are built with new GCC libraries and the person installing
the library has only an older version. Whilst this issue is probably
not related to gcc, the use of older libraries may well have caused
the problem here.
8) You personally wrote a day or two ago you were intending making a
Sage release in a day or so whilst merging 3 tickets. I suspect that
release would have been made without confirmation Sage builds on all
supported systems.
I like the idea of "release early, release often", but I personally
believe that should confined to developer shanshots, alpha/beta
releases (call them what you want). Making public releases without
fully checking seems a bad idea to me.
Another example of a rushed change was the removal of Fortran compiler
binaries, which was marked as a blocker and merged into sage-4.3.1.rc2
http://trac.sagemath.org/sage_trac/ticket/7485
I personally can't see why that was ever a blocker, as Sage had
shipped with the fortran binaries for ages. After that last minute
change, so it needed another blocker to add back the gfortran library
http://trac.sagemath.org/sage_trac/ticket/8049
IMHO, if Sage is ever to become a viable alternative to Mathematica,
Maple, MATLAB and Macsyma, you are going to have to shift the emphasis
towards more thorough testing before making releases. I can't imagine
Wolfram Research shipping binaries for platforms without testing them
first. Of course bugs do occur, and what works on one machine does not
necessary work on another. But it seems to me a lot of Sage bugs are
avoidable.
What I personally perceive as a lack of sufficient testing of Sage,
leaves me questioning myself whether I ever want to use Sage. I've
used Mathematica on and off for many years, and have come across bugs.
But never have I come across bugs so easily avoided as I see in Sage.
I'm trying to be constructive here, by pointing out what I believe are
deficiencies in the current process of releases.
I'll make a new package for iconv at the weekend if nobody beats me to it.
Dave
William Stein
> On 31 March 2010 01:57, William Stein <wst...@gmail.com> wrote:
>> On Tue, Mar 30, 2010 at 4:33 PM, Dr. David Kirkby
>
>>> Could it be a forward compatibility issue?
>>>
>>> 1) Sage 4.3.4 contains the latest iconv (1.13.1)
>>>
>>> 2) Code is Sage tests iconv, finds it's a late version, and makes use of the
>>> features in the the latest version.
>>>
>>> 3) After doing a 'sage -upgrade', iconv 1.13.1 is removed.
>>>
>>> 4) After 'sage -upgrade' the system supplied iconv is the only iconv package
>>> available. Any code which relied on new features in the latest iconv library
>>> suddenly breaks, as those features no longer exist.
>>>
>>> Note, the iconv package I created deletes old copies of itself, as
>>> spkg-install contains:
>>
>> Yes, I'm sure this is the problem.
>
> I only postulated this. I'm certainly not sure it is the reason,
> though I suspect quite strong it is.
>
>> Thus your iconv package in
>> sage-4.3.5 will *break* most sage's version <= 4.3.4 that upgrade...
>
> No it will not. It will only be version 4.3.4, as that is the only
> version which will have installed iconv. The iconv package never
> existed in earlier releases.
See sage-support. We already have a report of this happening today.
It's happening to hundreds of people probably, at least.
>
>> Can you make a version of the spkg that doesn't delete the previous
>> version on operating systems where iconv isn't going to be installed?
>> I.e., make an spkg asap that tests if not on solaris or cygwin, and in
>> that case immediately exits. This test should be first, before
>> anything else.
>>
>> I can then post that spkg online, so "sage -upgrade" isn't broken.
>>
>> -- William
>
> I can do that, but it will have to wait until the weekend, as I am
> tied up and are not at home. I don't have time to create the revised
> spkg and test it.
>
> I believe this incident highlights a number of issues I've raised
> before, but sometimes I feel I'm hitting my head against a wall.
Instead of reading the rest of this long email, I'm posting a new
spkg, which took all of 3 minutes.
William
Robert Bradshaw
[...]
> IMHO, if Sage is ever to become a viable alternative to Mathematica,
> Maple, MATLAB and Macsyma, you are going to have to shift the emphasis
> towards more thorough testing before making releases. I can't imagine
> Wolfram Research shipping binaries for platforms without testing them
> first. Of course bugs do occur, and what works on one machine does not
> necessary work on another. But it seems to me a lot of Sage bugs are
> avoidable.
>
> What I personally perceive as a lack of sufficient testing of Sage,
> leaves me questioning myself whether I ever want to use Sage. I've
> used Mathematica on and off for many years, and have come across bugs.
> But never have I come across bugs so easily avoided as I see in Sage.
>
> I'm trying to be constructive here, by pointing out what I believe are
> deficiencies in the current process of releases.
We all want more testing. I see two options:
(1) Change lots of other people's behavior.
(2) Set up a large-scale automated build farm.
Though we have neither right now, I see (2) happening before (1).
- Robert
William Stein
If I don't either
(a) get much more money in grants,
(b) have more volunteers willing to do (2) and (1), or
(c) start a company and sell Sage binaries that are more polished,
then indeed Sage releases will likely never be as polished as
Mathematica, or even RedHat releases.
Regarding (a), if anything, grant funding for Sage that would cover
costs like build farms, etc., has only gotten more difficult.
Regarding (b), somebody volunteer. Regarding (c), yes, the RedHat
model for selling GPL'd software has the potentially to (legally) work
-- we would provide source code for Sage for free, but all the
binaries would only be available from *us* to people who pay for a
support contract (redistribution of binaries would be technically
legal but discouraged). Maybe Kirkby wants (c)?
I don't personally want (c).
-- William
David Kirkby
> If I don't either
>
> (a) get much more money in grants,
> (b) have more volunteers willing to do (2) and (1), or
> (c) start a company and sell Sage binaries that are more polished,
>
> then indeed Sage releases will likely never be as polished as
> Mathematica, or even RedHat releases.
>
> Regarding (a), if anything, grant funding for Sage that would cover
> costs like build farms, etc., has only gotten more difficult.
> Regarding (b), somebody volunteer. Regarding (c), yes, the RedHat
> model for selling GPL'd software has the potentially to (legally) work
> -- we would provide source code for Sage for free, but all the
> binaries would only be available from *us* to people who pay for a
> support contract (redistribution of binaries would be technically
> legal but discouraged). Maybe Kirkby wants (c)?
>
> I don't personally want (c).
>
> -- William
No, Kirkby (or David is most people call me), does not want all of
(c). In particular distribution of binaries should be made available
and sharing encouraged.
But I see nothing wrong with selling support contracts, as long as
free support is still available.
I certainly was going to purchase wireshark support when I wanted some
changes made to the software for commerical purposes. Using public
support forums would simply not have been appropiate.
People pay for support on Apache, which is open-source. People pay for
support on Mathematica. Whether they will for Sage I do not know. I
suspect perhaps not. Wireshark and Apache are in a good position of
arguably being the best software of their type - there is nothing
better available commerically or for free.
Dave
Andrey Novoseltsev
>
> > (1) Change lots of other people's behavior.
> > (2) Set up a large-scale automated build farm.
>
> > Though we have neither right now, I see (2) happening before (1).
>
> If I don't either
>
> (a) get much more money in grants,
> (b) have more volunteers willing to do (2) and (1), or
> (c) start a company and sell Sage binaries that are more polished,
>
> then indeed Sage releases will likely never be as polished as
> Mathematica, or even RedHat releases.
Sage does have now the policy of 100% doctests, patch review system
and detailed guidelines for reviewers (thanks to Minh!). How can
waiting for build confirmations be more difficult? How about, say,
such a policy:
- release candidate is made
- if there are no blockers/build problems reported for it during one
WEEK (instead of like 24 hours), it is completely released
- if there are things that must be fixed, they get fixed and the one
week timer is reset
- meanwhile, this release candidate can be used as a base for the NEXT
release, making sure that all the new blockers also get merged
Even if not all platforms will get checked, most of them probably will
be, at least more than in one day. Is it actually more work for the
release managers to do this?.. No, I don't volunteer to be a release
manager who does this, but if there are mandatory policies for patch
writers and reviewers, why should not there be policies for release
managers?
By the way, while it is possible to make a patch/package for Sage in 3
minutes,
http://sagemath.org/doc/developer/walk_through.html#creating-a-change
states
"Once you have something you like, do everything suggested for
reviewing a patch."
and
http://sagemath.org/doc/developer/walk_through.html#reviewing-a-patch
states
"If affected files pass tests, then run ./sage -testall. This will
take a while to complete. No, it is not optional. "
so I don't think that it is possible to follow standard policies and
make something which is "ready to merge" so fast... Perhaps in this
case it was reasonable to make an exception, but I also understand how
David can have enough time to write a long email, but not enough to
post a patch.
I definitely prefer Sage over Maple, which I used for a while, and
from my little experience with other "M"s I also think that Sage has a
lot of advantages. I also think that Sage has a lot of advantages
compared to some other free/open-source math programs. So - I think
that Sage is great and I intend to continue using it indefinitely.
However more than once I regretted "sage -upgrade" because it broke
something that I was using and had to use it again right then. I also
had several occasions of "live Sage introductions" when I had to say
"Usually, you can do this cool thing: ... , but unfortunately now it
is broken and probably will be fixed in the next release." It would be
really nice not to say it often.
Thank you,
Andrey
John H Palmieri
> However more than once I regretted "sage -upgrade" because it broke
> something that I was using and had to use it again right then.
Don't use "sage -upgrade" like this! I always copy the entire Sage
directory first: if I have a directory "sage-4-3.4", then I do
$ cp -pR sage-4.3.4 sage-4.3.5-upgrade
$ cd sage-4.3.5-upgrade
$ ./sage -upgrade
Then if something breaks, I still have the old version. No, it's not
as fast as just running "sage -upgrade", but it's still a lot faster
than building from scratch.
--
John
William Stein
>> > We all want more testing. I see two options:
>>
>> > (1) Change lots of other people's behavior.
>> > (2) Set up a large-scale automated build farm.
>>
>> > Though we have neither right now, I see (2) happening before (1).
>>
> ...
>> If I don't either
>>
>> (a) get much more money in grants,
>> (b) have more volunteers willing to do (2) and (1), or
>> (c) start a company and sell Sage binaries that are more polished,
>>
>> then indeed Sage releases will likely never be as polished as
>> Mathematica, or even RedHat releases.
>
> Sage does have now the policy of 100% doctests, patch review system
> and detailed guidelines for reviewers (thanks to Minh!). How can
> waiting for build confirmations be more difficult?
It is way more difficult. If you did release management you might understand.
> How about, say,
> such a policy:
> - release candidate is made
> - if there are no blockers/build problems reported for it during one
> WEEK (instead of like 24 hours), it is completely released
Reported by whom? The above policy doesn't guarantee anything.
> - if there are things that must be fixed, they get fixed and the one
> week timer is reset
My first worry -- how can you fix the problems that do get reported?
Often when people report build problems, those problems are on their
personal crufty Linux installs, which they won't or can't give access
to, and which can be (mis-)configured in all kinds of ways, or even
have faulty hardware.
> - meanwhile, this release candidate can be used as a base for the NEXT
> release, making sure that all the new blockers also get merged
> Even if not all platforms will get checked, most of them probably will
> be, at least more than in one day. Is it actually more work for the
> release managers to do this?.. No, I don't volunteer to be a release
> manager who does this, but if there are mandatory policies for patch
> writers and reviewers, why should not there be policies for release
> managers?
>
> By the way, while it is possible to make a patch/package for Sage in 3
> minutes,
> http://sagemath.org/doc/developer/walk_through.html#creating-a-change
> states
> "Once you have something you like, do everything suggested for
> reviewing a patch."
> and
> http://sagemath.org/doc/developer/walk_through.html#reviewing-a-patch
> states
> "If affected files pass tests, then run ./sage -testall. This will
> take a while to complete. No, it is not optional. "
> so I don't think that it is possible to follow standard policies and
> make something which is "ready to merge" so fast... Perhaps in this
> case it was reasonable to make an exception, but I also understand how
> David can have enough time to write a long email, but not enough to
> post a patch.
If you understand the details of the change in the spkg we're talking
about, you might have a different perspective....
> I definitely prefer Sage over Maple, which I used for a while, and
> from my little experience with other "M"s I also think that Sage has a
> lot of advantages. I also think that Sage has a lot of advantages
> compared to some other free/open-source math programs. So - I think
> that Sage is great and I intend to continue using it indefinitely.
> However more than once I regretted "sage -upgrade" because it broke
> something that I was using and had to use it again right then.
As John said later, don't use "sage -upgrade" in a context that could
*possible* result in such a regret. The "sage -upgrade" command asks
you the explicit question: "WARNING: This is a source-based upgrade,
which could take hours, fail, and render your Sage install useless!!
Do you want to continue [y/N]?" for a reason.
> I also
> had several occasions of "live Sage introductions" when I had to say
> "Usually, you can do this cool thing: ... , but unfortunately now it
> is broken and probably will be fixed in the next release." It would be
> really nice not to say it often.
That's unfortunate. Some ways you can help:
(a) help us get the doctest coverage of the Sage library up from
80+eps% to 100%
(b) help referee patches -- There are over 150 tickets needing
review right now: http://trac.sagemath.org/sage_trac/report/10
(c) help fixing bugs -- There are over 800 bugs listed here:
http://trac.sagemath.org/sage_trac/query?group=status&type=defect&milestone=sage-4.4
-- William
Dr. David Kirkby
> My first worry -- how can you fix the problems that do get reported?
> Often when people report build problems, those problems are on their
> personal crufty Linux installs, which they won't or can't give access
> to, and which can be (mis-)configured in all kinds of ways, or even
> have faulty hardware.
>
> -- William
>
It's undoubtedly true what you say about peoples broken Linux installations or
faulty hardware. Hence a report of a build problem does not necessarily indicate
a problem with Sage, though if you get several of them, it is quite likely to be
a problem.
Conversely, if you do as I suggest and wait until there is a report of a
*successful* build before making an "official" release, a large number of these
problems could be avoided. In the case of 4.3.4-rc1, you would not have received
any reports of successful builds on SUSE, Fedora, Mandriva ... whatever else.
It needs people to fill in a page like this, which Minh created
http://wiki.sagemath.org/devel/BuildFarm/sage-4.3
and report their success/failure. Wait until there is a successful build report
from each supported platform before releasing.
It would be fairly easy to create a similar(ish) web page, where people listed
what systems they have access to. So Jaap would for example enter Fedora and
OpenSolaris. Hopefully someone else would have access to SUSE. Then if there
are no reports of successful builds on SUSE, a very polite email could be sent
to those with SUSE access, asking if they have have time to build
sage-x.y.z.rc0, that they report it, since there has been no confirmed
successful builds.
dave
William Stein
<david....@onetel.net> wrote:
> William Stein wrote:
>
>> My first worry -- how can you fix the problems that do get reported?
>> Often when people report build problems, those problems are on their
>> personal crufty Linux installs, which they won't or can't give access
>> to, and which can be (mis-)configured in all kinds of ways, or even
>> have faulty hardware.
>>
>> -- William
>>
>
> It's undoubtedly true what you say about peoples broken Linux installations
> or faulty hardware. Hence a report of a build problem does not necessarily
> indicate a problem with Sage, though if you get several of them, it is quite
> likely to be a problem.
>
> Conversely, if you do as I suggest and wait until there is a report of a
> *successful* build before making an "official" release, a large number of
> these problems could be avoided. In the case of 4.3.4-rc1, you would not
> have received any reports of successful builds on SUSE, Fedora, Mandriva ...
> whatever else.
>
> It needs people to fill in a page like this, which Minh created
>
> http://wiki.sagemath.org/devel/BuildFarm/sage-4.3
>
> and report their success/failure. Wait until there is a successful build
> report from each supported platform before releasing.
That would result in never releasing another version of Sage. Even
that page you point to above doesn't even come close to covering our
standard officially supported platforms.
> It would be fairly easy to create a similar(ish) web page, where people
> listed what systems they have access to. So Jaap would for example enter
> Fedora and OpenSolaris. Hopefully someone else would have access to SUSE.
> Then if there are no reports of successful builds on SUSE, a very polite
> email could be sent to those with SUSE access, asking if they have have time
> to build sage-x.y.z.rc0, that they report it, since there has been no
> confirmed successful builds.
And when they fail!?!?!?!? What, we sit there and wait for the SUSE
users to fix the problems?
I'm just repeating what I said above: if the developers do not have
access to the hardware with the problems, then they can't fix them.
-- William
David Kirkby
> On Wed, Mar 31, 2010 at 4:19 PM, Dr. David Kirkby
>>
>> and report their success/failure. Wait until there is a successful build
>> report from each supported platform before releasing.
>
> That would result in never releasing another version of Sage. Even
> that page you point to above doesn't even come close to covering our
> standard officially supported platforms.
Well then remove official support for so many platforms, and ensure
Sage definately builds on those for which there is official support.
>> It would be fairly easy to create a similar(ish) web page, where people
>> listed what systems they have access to. So Jaap would for example enter
>> Fedora and OpenSolaris. Hopefully someone else would have access to SUSE.
>> Then if there are no reports of successful builds on SUSE, a very polite
>> email could be sent to those with SUSE access, asking if they have have time
>> to build sage-x.y.z.rc0, that they report it, since there has been no
>> confirmed successful builds.
>
> And when they fail!?!?!?!? What, we sit there and wait for the SUSE
> users to fix the problems?
No, drop offical SUSE support if it's impractical to test Sage on it.
> I'm just repeating what I said above: if the developers do not have
> access to the hardware with the problems, then they can't fix them.
>
> -- William
If developers do not have access to a platform, and/or they do not
have the time to test Sage on that platform, then remove offical
support for the platform. Given the following two possibilites, I know
what one I'd chose.
1) Have official support for a large number of Linux distributions,
even though there are not the resources to test on them.
2) Have a smaller number of offically supported distributions on which
it is practical to test Sage on before an official release of Sage is
made.
I personally think number 2 is better than number 1. Do you agree? If
so, the solution is obvious.
IMHO, there's little point in having official support for a large
number of platforms, if that results in broken Sage releases on the
more common platforms.
Dave
William Stein
There *are* hardware resources. The only problem is the people effort
to configure them and organize them.
Sage didn't get to where it is now and won't get to where it needs to
go by such an attitude of not supporting platforms. If anything, we
need to solidly support far more platforms than we currently support.
> I personally think number 2 is better than number 1. Do you agree? If
> so, the solution is obvious.
I definitely do not agree. The solution is to get our act together
and get the infrastructure organized so that we can properly test on
*all* supported platforms. Either help or... help.
William
David Kirkby
I personally see a third option.
3) Drop offical support for any platforms where the current resources
do not permit Sage to be tested on it.
If a large scale automated build farm is set up, which allows Sage to
be checked on a larger number of distributions, then the list of
officially supported distributions could be enlarged.
Can you see much point in haing offical support for more distributions
of Linux than it is practical to Sage test on?
Dave
David Kirkby
> On Wed, Mar 31, 2010 at 11:50 PM, David Kirkby <david....@onetel.net> wrote:
>> If developers do not have access to a platform, and/or they do not
>> have the time to test Sage on that platform, then remove offical
>> support for the platform. Given the following two possibilites, I know
>> what one I'd chose.
>>
>> 1) Have official support for a large number of Linux distributions,
>> even though there are not the resources to test on them.
>
> There *are* hardware resources. The only problem is the people effort
> to configure them and organize them.
Resources must consist of hardware, software and time.
> Sage didn't get to where it is now and won't get to where it needs to
> go by such an attitude of not supporting platforms. If anything, we
> need to solidly support far more platforms than we currently support.
>> I personally think number 2 is better than number 1. Do you agree? If
>> so, the solution is obvious.
>
> I definitely do not agree.
I find it astonishing you feel it is more important to have offical
support for a larger number of platforms than there are the resources
to test Sage on.
> The solution is to get our act together
> and get the infrastructure organized so that we can properly test on
> *all* supported platforms. Either help or... help.
>
> William
IMHO, platforms should never be offically supported until the
resources are in place to test on those platforms before a Sage
release is made.
Once the resources are in place, then increase the number of
officially supported platforms. But only when the resources are in
place.
Dave
David Kirkby
1) Have official support for a large number of Linux distributions,
even though there are not the resources to test on them.
2) Have a smaller number of officially supported distributions on
which it is practical to test Sage on before an official release of
Sage is made.
I personally feel 2 is better than 1, yet William disagrees with that.
I'd be interested what others think.
Dave
Jason Grout
> Sage didn't get to where it is now and won't get to where it needs to
> go by such an attitude of not supporting platforms. If anything, we
> need to solidly support far more platforms than we currently support.
William, what is your definition of the statement, for example, that
Sage officially supports Suse?
It sounds like David's definition is that every release of Sage is
tested on Suse before release by at least compiling it and running all
doctests without errors (David, correct me if I'm misinterpreting your
views!). How does your definition differ, if it does?
Thanks,
Jason
Dr. David Kirkby
> On 04/01/2010 01:56 AM, William Stein wrote:
>
>> Sage didn't get to where it is now and won't get to where it needs to
>> go by such an attitude of not supporting platforms. If anything, we
>> need to solidly support far more platforms than we currently support.
>
>
> William, what is your definition of the statement, for example, that
> Sage officially supports Suse?
That's obviously for William to answer.
> It sounds like David's definition is that every release of Sage is
> tested on Suse before release by at least compiling it and running all
> doctests without errors (David, correct me if I'm misinterpreting your
> views!). How does your definition differ, if it does?
Jason, you are not mis-representing my views. That would be my close to my
definition, though I would suggest it is modified a little, to be more precise.
We state the version of openSUSE we support, not just 'openSUSE'. Ideally that
would be the latest stable release, but not necessarily so. I would not suggest
holding up a release of Sage just because SUSE have released a new version, and
nobody has had the time to set up that installation. Neither would I remove SUSE
support if Sage does not build on the latest release, but builds on an earlier
version.
Of course, if we chose to support older and never versions of openSUSE, that is
better, as long as Sage is tested on them.
Since in the case of openSUSE, there is official Sage support for both 32-bit
and 64-bit, then it should be checked on both 32-bit and 64-bit installations.
We should also state the GCC version we support for each platform. That
statement is clarified by saying "Any gcc >=4.0.1 should work, but Sage is
tested by building with the gcc version stated".
Of course, the fact a platform is not officially supported does not mean that
Sage will not work on it, but simply that we don't have the resources to test
every Sage release on it.
I believe the 'supported' definition used by MATLAB is reasonable
http://www.mathworks.com/support/sysreq/current_release/linux.html
(not necessarily the same operating systems or versions, but just the general
principle).
===============================================================
===============================================================
* Ubuntu 8.04, 8.10, 9.04, and 9.10
* Red Hat Enterprise Linux 5.x
* SUSE Linux Enterprise Desktop 11.x
* Debian 5.x
* The listed distributions are those Linux distributions that MathWorks products
have been validated against. It is likely that other distributions with kernel
version 2.6 or later and glibc version 2.5 or later can successfully run
MathWorks products, but The MathWorks will be in a limited position to provide
technical support for those distributions.
===============================================================
===============================================================
By adopting something similar to this, I see four advantages:
1) We ensure releases are not made which are broken on so-called supported
platforms.
2) Sage releases are not held up forever, because nobody is able to verify Sage
works on them.
3) If people want to set up a Sage server for access by students, then can be
reasonably certain that new releases of Sage will work on that operating system
version.
4) If people get problems building Sage on one of the supported platforms, we
can indicate to them that they try a specific version of GCC, as that is known
to work. If they still report problems, we can point out that Sage has been
verified to work on that platform, and it is therefore likely to be a problem
with their installation.
As and when the resources become available to test on more platforms, we should
do so. If it is no longer practical to test on a certain version of the
operating system, then official support should be dropped for that.
The main limit on testing Sage would usually be peoples time. In the case of
Itanium, it might be limited by the hardware resources available, as few people
have access to machines with Itanium processors. If that is the case, then we
should not consider Itanium as a supported platform.
Dave
Florent Hivert
>> It sounds like David's definition is that every release of Sage is tested
>> on Suse before release by at least compiling it and running all doctests
>> without errors (David, correct me if I'm misinterpreting your views!).
>> How does your definition differ, if it does?
>
> Jason, you are not mis-representing my views. That would be my close to my
> definition, though I would suggest it is modified a little, to be more
> precise.
>
> We state the version of openSUSE we support, not just 'openSUSE'. Ideally
> that would be the latest stable release, but not necessarily so. I would
> not suggest holding up a release of Sage just because SUSE have released a
> new version, and nobody has had the time to set up that installation.
> Neither would I remove SUSE support if Sage does not build on the latest
> release, but builds on an earlier version.
>
> Of course, if we chose to support older and never versions of openSUSE,
> that is better, as long as Sage is tested on them.
>
> Since in the case of openSUSE, there is official Sage support for both
> 32-bit and 64-bit, then it should be checked on both 32-bit and 64-bit
> installations.
I there ! I don't know why among all the other distributions openSuSE is
driving so much attention, but to add my two cents I want to tell the
following:
I've been using onpenSUSE for quite a long time and except if sage drop
support to it, I'll keep using it. My distro is currently openSuSE 11.1, I
said on this very mailing list 5 month ago that I'll upgrade to 11.2 and I
didn't. Part of the reason is that I've only one serious machine which I use
for research and teaching and I can't afford to have anything broken during
classes. I planned to do it during Christmas vacations but, as usual, time is
very short during those vacations.
Concerning the recent iconv problem, I've been one of the first reporting it
and trying to solve (unsuccessfully) the problem. See the historic of
#8567. So there is at least one active sage developer keeping an eye on what's
happening on openSuSE. Now as I said, I don't have a lot a machine at home so
that I only test on 11.1 64bit.
I understood that among sage's virtual machines build farm, there is one
running openSuSE 11.1. Please someone correct me if I'm wrong. In conclusion,
I'm strongly +1 on keeping openSuSE support, and as far as I've time and
resource for that, I'm willing to help (and I think I do) to support it.
Cheers,
Florent
Jason Grout
> I there ! I don't know why among all the other distributions openSuSE is
> driving so much attention
I just picked something at random. No offense or other interpretation
intended.
Thanks,
Jason
Dr. David Kirkby
> Hi There,
>
>>> It sounds like David's definition is that every release of Sage is tested
>>> on Suse before release by at least compiling it and running all doctests
>>> without errors (David, correct me if I'm misinterpreting your views!).
>>> How does your definition differ, if it does?
>> Jason, you are not mis-representing my views. That would be my close to my
>> definition, though I would suggest it is modified a little, to be more
>> precise.
>>
>> We state the version of openSUSE we support, not just 'openSUSE'. Ideally
>> that would be the latest stable release, but not necessarily so. I would
>> not suggest holding up a release of Sage just because SUSE have released a
>> new version, and nobody has had the time to set up that installation.
>> Neither would I remove SUSE support if Sage does not build on the latest
>> release, but builds on an earlier version.
>>
>> Of course, if we chose to support older and never versions of openSUSE,
>> that is better, as long as Sage is tested on them.
>>
>> Since in the case of openSUSE, there is official Sage support for both
>> 32-bit and 64-bit, then it should be checked on both 32-bit and 64-bit
>> installations.
>
> I there ! I don't know why among all the other distributions openSuSE is
> driving so much attention, but to add my two cents I want to tell the
> following:
openSUSE was first used by me as an example of where there was a failure of Sage
4.3.4 to build. The same was true of Fedora, Mandriva and probably other Linux
distros too.
My point being, that if a platform is fully supported, each Sage release should
be tested on it. If we don't have the resources to test on it, then we can't
consider it supported in the way software is usually considered 'supported'.
IMHO, having a set of fully supported (i.e. tested and works) systems is
essential.
Offering help/support for someone wishing to run on other Linux distro is
another matter altogether.
> I understood that among sage's virtual machines build farm, there is one
> running openSuSE 11.1. Please someone correct me if I'm wrong. In conclusion,
> I'm strongly +1 on keeping openSuSE support, and as far as I've time and
> resource for that, I'm willing to help (and I think I do) to support it.
>
> Cheers,
>
> Florent
I was certainly not implying openSUSE support should be dropped. Only that for
Linux $distribution, then $distribution should be dropped unless we test Sage on
$distribution.
If
http://www.brighthub.com/computing/linux/articles/21108.aspx
is to be believed (and I'm not implying it should be), then openSUSE is the
second most popular distribution (Ubuntu is first). If that is so, undoubtedly
Sage should be tested on openSUSE before a new version of Sage is released.
Dave
Peter Jeremy
>What do others feel about these two cenaros
>
>1) Have official support for a large number of Linux distributions,
>even though there are not the resources to test on them.
>
>2) Have a smaller number of officially supported distributions on
>which it is practical to test Sage on before an official release of
>Sage is made.
IMHO, "official support" means that a tested binary package is
available for download. Sage is a comparatively complex package
that relies on parts of the OS+userland that are probably not
well tested.
Note that it does not mean that the package has passed every doctest
(though this is desirable). There could (and probably should) be a
"known issues" or "errata" section in the release notes which lists
problems with specific packages in specific environments.
Expecting a prospective user to download and build Sage themselves is
unrealistic. If they are using a supposedly supported distro and Sage
doesn't actually build for them or fails its doctests, you've probably
lost them as users.
--
Peter Jeremy
Robert Bradshaw
> On 2010-Apr-01 08:37:12 +0100, David Kirkby
> <david....@onetel.net> wrote:
>> What do others feel about these two cenaros
>>
>> 1) Have official support for a large number of Linux distributions,
>> even though there are not the resources to test on them.
>>
>> 2) Have a smaller number of officially supported distributions on
>> which it is practical to test Sage on before an official release of
>> Sage is made.
>
> IMHO, "official support" means that a tested binary package is
> available for download. Sage is a comparatively complex package
> that relies on parts of the OS+userland that are probably not
> well tested.
>
> Note that it does not mean that the package has passed every doctest
> (though this is desirable). There could (and probably should) be a
> "known issues" or "errata" section in the release notes which lists
> problems with specific packages in specific environments.
I was under the impression that, with few exceptions, all the binaries
posted pass all doctests, at least on the machines they were compiled
on. Is this not the case anymore? This is a fair number of platforms,
and could be taken to be the "official list" for any given release.
Unfortunately, the problem seems to be that just because it builds and
runs fine on my copy of openSUSE, or the one in the build farm,
doesn't mean it always will on yours.
- Robert