On Monday, June 9, 2014 3:55:52 PM UTC-7, Volker Braun wrote:
Thanks for the investigative work!
Using the terminal echo isn't really a solution, maybe it doesn't fail as
often but it cannot work all the time. The terminal echo can and will
occasionally (rarely) be interleaved with the
On 9 June 2014 23:55, Volker Braun vbraun.n...@gmail.com wrote:
Thanks for the investigative work!
Using the terminal echo isn't really a solution, maybe it doesn't fail as
often but it cannot work all the time. The terminal echo can and will
occasionally (rarely) be interleaved with the
On 10 June 2014 09:53, leif not.rea...@online.de wrote:
John Cremona wrote:
On 9 June 2014 23:55, Volker Braun vbraun.n...@gmail.com wrote:
Thanks for the investigative work!
Using the terminal echo isn't really a solution, maybe it doesn't fail as
often but it cannot work all the time.
On Monday, June 9, 2014 1:50:17 PM UTC-7, John H Palmieri wrote:
On Saturday, June 7, 2014 12:09:50 PM UTC-7, John H Palmieri wrote:
On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
These are all due to the Singular interface..
I also see them relatively often but
On 2014-06-07, John H Palmieri jhpalmier...@gmail.com wrote:
On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
These are all due to the Singular interface..
I also see them relatively often but usually its only one or two that
fail. There was a bug in pexpect that got fixed
John H Palmieri wrote:
On Sunday, May 25, 2014 3:11:21 AM UTC-7, Volker Braun wrote:
New beta is out now, get it while its hot ;)
On two OS X 10.9 machines, I'm getting timeouts on some doctests.
That's presumably because it's no longer hot.
Do you also get (the same?) timeouts when
On Saturday, June 7, 2014 11:49:43 AM UTC-7, Volker Braun wrote:
These are all due to the Singular interface..
I also see them relatively often but usually its only one or two that
fail. There was a bug in pexpect that got fixed in beta3, maybe you can try
that version and report back.
On Tuesday, May 27, 2014 6:02:20 AM UTC+2, Ralf Stephan wrote:
I have reread this thread and I'm asking myself if the ecl upgrade
shouldn't have simply bumped the package-version.txt of maxima at
patchlevel, thus forcing a rebuild. I mean the author of that ticket surely
had the same
P Purkayastha wrote:
On Monday, May 26, 2014 10:08:19 PM UTC+8, leif wrote:
Nathann Cohen wrote:
Whether we should make it the default in the top-level Makefile
has been
discussed a couple of times in the past years, and IIRC most
agreed we
should do so, but so far
Ralf Stephan wrote:
John Palmieri recently helped me with a ticket (#16350) where the
spkg-install
of a package was changed but that was not enough to trigger the necessary
rebuild. That could be accomplished by adding '.p0' to the
package-version.txt
because patch level changes don't change the
Hello,
John Palmieri recently helped me with a ticket (#16350) where the
spkg-install
of a package was changed but that was not enough to trigger the necessary
rebuild. That could be accomplished by adding '.p0' to the
package-version.txt
because patch level changes don't change the actual
sage -f ecl, followed by sage -f maxima did it for me.
Did the job for me. Thanks ! :-)
nathann
--
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
Alternatively, build with SAGE_UPGRADING=yes (this will check dependencies
and reinstall Maxima after ECL has been updated).
Peter
Op maandag 26 mei 2014 13:23:37 UTC+1 schreef Nathann Cohen:
sage -f ecl, followed by sage -f maxima did it for me.
Did the job for me. Thanks ! :-)
Lazyness?
You are not lazy, and neither am I. Do we change that ? It seems that
setting this to False does not help in any way, least of all if it is
the default behaviour.
My problem is that I do not know how to change such things. Do you ?
Nathann
--
You received this message because you
Nathann Cohen wrote:
Alternatively, build with SAGE_UPGRADING=yes (this will check dependencies
and reinstall Maxima after ECL has been updated).
What is the reason for not making this the default ?
I cannot currently edit your ~/.bashrc (nor your ~/.sage/sagerc *) ...
Whether we should
Nathann Cohen wrote:
Whether we should make it the default in the top-level Makefile has been
discussed a couple of times in the past years, and IIRC most agreed we
should do so, but so far even 'sudo open a ticket' failed.
I really do not know how such things are changed ...
E.g. by simply
E.g. by simply adding the lines
SAGE_UPDGRADING ?= yes
export SAGE_UPGRADING
I know how to fix my problem, I just don't know how to fix Sage.
(And I originally only wanted to add an additional target 'upgrade', setting
the variable to 'yes' and depending on 'build'. When 'yes' is the
On Monday, May 26, 2014 3:39:33 PM UTC+2, Nathann Cohen wrote:
Whether we should make it the default in the top-level Makefile has been
discussed a couple of times in the past years, and IIRC most agreed we
should do so, but so far even 'sudo open a ticket' failed.
I really do not
Open a ticket and someone might feel less lazy :)
I don't believe in opening tickets without writing the patch and
setting them to needs_review :-P
Nathann
--
You received this message because you are subscribed to the Google Groups
sage-release group.
To unsubscribe from this group and stop
On Monday, May 26, 2014 4:14:56 PM UTC+2, Nathann Cohen wrote:
Open a ticket and someone might feel less lazy :)
I don't believe in opening tickets without writing the patch and
setting them to needs_review :-P
Set them to blocker.
That will get the release manager attention.
--
You
Yoo !!
Why would we need a buggy upgrade script ?
Backwards compatibility. And I personally don't want ATLAS to get rebuilt
just because someone decided to change the spkg-install script of readline
such that Python gets rebuilt upon which unfortunately ATLAS depends, just
Nathann Cohen wrote:
(And I originally only wanted to add an additional target 'upgrade', setting
the variable to 'yes' and depending on 'build'. When 'yes' is the default,
I don't know what the opposite target should be called;
'quick-and-dirty-upgrade-not-really-rebuilding-dependent-packages'
You have my attention. We can of course wait with any future releases until
somebody fixes this.
In an ideal world we would have reliable library versioning, so you
wouldn't need to rebuild maxima UNLESS the ecl library version changes in
an incompatible way (which can be read off from the
23 matches
Mail list logo
