On 2014-08-15, Volker Braun wrote:
> --=_Part_231_1213945713.1408086090167
> Content-Type: text/plain; charset=UTF-8
>
> On Friday, August 15, 2014 6:25:05 AM UTC+1, kcrisman wrote:
>>
>> That's silly, especially because often someone else writes your name and
>> in the deluge of tickets it's
If you want to update your local "master" branch you should do:
git checkout master# switch to your local master branch
git pull --ff-only trac master
On Tuesday, August 12, 2014 1:26:30 PM UTC+1, Andrew wrote:
>
> git pull --ff-only 6.3
> not the recommended way to update the master branch t
Hmm, I have another issue then because, as shown above, the only 6.3 tag
that I am getting is 6.3.beta0 (my list is also alphabetical, it's just
missing all of the other 6.3 tags).
OK, I just fixed my problem with a "git fetch".
*Question*: Is
git pull --ff-only 6.3
not the recommended way t
The tags are in alphabetical order:
$ git tag | tail -15
6.2.rc0
6.2.rc1
6.2.rc2
6.3
6.3.beta0
6.3.beta1
6.3.beta2
6.3.beta3
6.3.beta4
6.3.beta5
6.3.beta6
6.3.beta7
6.3.beta8
6.3.rc0
6.3.rc1
On Tuesday, August 12, 2014 3:17:37 AM UTC+1, Andrew wrote:
>
> I compiled 6.3 happily on my macbook pro
On 12.08.2014 09:34, Jeroen Demeyer wrote:
On 2014-08-11 21:53, John H Palmieri wrote:
I guess they're being installed and the error message is
misleading. A number of packages produce the same error but also install
correctly.
That is indeed the case. There is an "mv" command in sage-spkg whic
On 2014-08-11 21:53, John H Palmieri wrote:
I guess they're being installed and the error message is
misleading. A number of packages produce the same error but also install
correctly.
That is indeed the case. There is an "mv" command in sage-spkg which is
not needed for all packages:
if [ "$U
I compiled 6.3 happily on my macbook pro running macosx 10.9.4.
┌┐
│ Sage Version 6.3, Release Date: 2014-08-10 │
│ Type "notebook()" for the browser-based notebook interface.│
│ Type "help()" for
On Monday, August 11, 2014 10:15:19 AM UTC-7, Volker Braun wrote:
>
> According to the gp manpage the directories should be called galdata/ and
> seadata/... I don't know how to test that they are being found, though.
>
Oh, I see them. I guess they're being installed and the error message is
m
According to the gp manpage the directories should be called galdata/ and
seadata/... I don't know how to test that they are being found, though.
On Monday, August 11, 2014 4:56:56 PM UTC+1, John H Palmieri wrote:
>
> This has probably been an issue for a while, but I hadn't noticed until
> no
On Sunday, August 10, 2014 8:31:01 AM UTC-7, Volker Braun wrote:
>
> Both the "master" and "develop" git branch have been updated to the 6.3
> release.
>
> Source tarball:
> http://boxen.math.washington.edu/home/release/sage-6.3.tar.gz
>
> sha512sum sage-6.3.tar.gz
> 03f8016ddd5029915846be01a6
Oh OK. This is a really old system and I don't have admin rights.
I guess AFM = Adobe Font Metrics, seems like something is wrong with your
system fonts.
On Monday, August 11, 2014 9:55:11 AM UTC+1, P Purkayastha wrote:
>
> File "src/doc/de/tutorial/tour_functions.rst", line 24, in doc.de.tutorial
I guess AFM = Adobe Font Metrics, seems like something is wrong with your
system fonts.
On Monday, August 11, 2014 9:55:11 AM UTC+1, P Purkayastha wrote:
>
> File "src/doc/de/tutorial/tour_functions.rst", line 24, in doc.de.tutorial
> .tour_functions
> Failed example:
> plot(f, 0, 2)
> Expect
On Sunday, August 10, 2014 11:31:01 PM UTC+8, Volker Braun wrote:
>
> Both the "master" and "develop" git branch have been updated to the 6.3
> release.
>
Got some strange doctest failures on "make ptestlong" on this system:
.../src/sage/sage-6.3.server> uname -a
Linux spms-banana 2.6.32-5-amd
Emmanuel Charpentier wrote:
The only annoying thing is the time for ATLAS/LAPACK to get optimized
(scratch build is 222 minutes, vs about 40 minutes with
SAGE_FAT_BINARY="yes", which doesn't optimize ATLAS). Is there a way to
save the result of optimization and use it later in a new
build-from-sc
FYI :
Rebuilt 6.3rc1 from scratch (after make distclean) on a large (Core i7, 16
Gb RAM) with no issues. Sage's R was able to install all the packages I use
(I g=had some issues with that lately). Passes make ptestlong.
The only annoying thing is the time for ATLAS/LAPACK to get optimized
(scr
This looks like it is picking up some environment variable. Can you post
the output of "env"?
On Thursday, August 7, 2014 8:46:33 AM UTC+1, Harald Schilly wrote:
>
> On Wed, Aug 6, 2014 at 1:35 PM, Volker Braun > wrote:
> > In any case, can you post logs/pkgs/r-3.1.1.p0.log
>
>
> Tried again
On Wed, Aug 6, 2014 at 1:35 PM, Volker Braun wrote:
> In any case, can you post logs/pkgs/r-3.1.1.p0.log
Tried again after pulling the new dev update, but no surprises:
http://boxen.math.washington.edu/home/schilly/logs/r-3.1.1.p0.log
harald
--
You received this message because you are subscr
Yes, I will. I'm just currently travelling ☺
H
On Aug 6, 2014 1:35 PM, "Volker Braun" wrote:
> In any case, can you post logs/pkgs/r-3.1.1.p0.log
>
> On Wednesday, August 6, 2014 8:37:09 AM UTC+1, Harald Schilly wrote:
>>
>>
>> On Tue, Aug 5, 2014 at 11:12 PM, Volker Braun wrote:
>>
>>> Also, w
In any case, can you post logs/pkgs/r-3.1.1.p0.log
On Wednesday, August 6, 2014 8:37:09 AM UTC+1, Harald Schilly wrote:
>
>
> On Tue, Aug 5, 2014 at 11:12 PM, Volker Braun > wrote:
>
>> Also, where is the /home/harri/.local coming from? Is that from some
>> environment variable that you have set
On Tue, Aug 5, 2014 at 11:12 PM, Volker Braun wrote:
> Also, where is the /home/harri/.local coming from? Is that from some
> environment variable that you have set?
Well, no idea, I've certainly adjusted some knobs on my ubuntu box … with
maybe not so fortunate effects. If it is just me havi
Also, where is the /home/harri/.local coming from? Is that from some
environment variable that you have set?
On Tuesday, August 5, 2014 9:33:20 PM UTC+1, Harald Schilly wrote:
>
> gcc -I/home/harri/.local/include -L/home/harri/.local/lib
> -I/home/opt/sage/sage-git/local/var/tmp/sage/build/r-3.1
On Tuesday, August 5, 2014 9:33:20 PM UTC+1, Harald Schilly wrote:
>
> that grep gave
> gcc -I/home/harri/.local/include -L/home/harri/.local/lib
> -I/home/opt/sage/sage-git/local/var/tmp/sage/build/r-3.1.1.p0/src/include
> -DNDEBUG -DNTIMER -I./SuiteSparse_config -fpic -g -O2 -c CHMfacto
On Tue, Aug 5, 2014 at 5:52 PM, Volker Braun wrote:
> On my machine the -std=gnu99 is present:
>
> $ grep CHMfactor.c logs/pkgs/r-3.1.1.p0.log
>
that grep gave
gcc -I/home/harri/.local/include -L/home/harri/.local/lib
-I/home/opt/sage/sage-git/local/var/tmp/sage/build/r-3.1.1.p0/src/include
-
leif wrote:
Volker Braun wrote:
The configure output is probably the interesting part, Harald.
FWIW, I'm having
checking for gcc-4.9.1 option to accept ISO C99... -std=gnu99
checking for gcc-4.9.1 -std=gnu99 option to accept ISO Standard C...
(cached) -std=gnu99
in the R build log.
But does
Volker Braun wrote:
The configure output is probably the interesting part, Harald.
FWIW, I'm having
checking for gcc-4.9.1 option to accept ISO C99... -std=gnu99
checking for gcc-4.9.1 -std=gnu99 option to accept ISO Standard C...
(cached) -std=gnu99
in the R build log.
But doesn't any rec
The configure output is probably the interesting part, Harald.
--
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 sage-release+unsubscr...@googlegroups.com.
To post
On my machine the -std=gnu99 is present:
$ grep CHMfactor.c logs/pkgs/r-3.1.1.p0.log
gcc -std=gnu99
-I/home/release/Sage/local/var/tmp/sage/build/r-3.1.1.p0/src/include
-DNDEBUG -DNTIMER -I./SuiteSparse_config -fpic -g -O2 -c CHMfactor.c
-o CHMfactor.o
On Tuesday, August 5, 2014 4:35:
On Tue, Aug 5, 2014 at 5:26 PM, Volker Braun wrote:
> Interesting, which gcc version?
>
well, mabye it is picking up the wrong file? (I'll delete my CCACHE and
try again) ... i don't know.
version numbers:
(sage-sh)$ which gcc
/home/opt/sage/sage-git/local/libexec/ccache/gcc
(sage-sh)$ gcc -
Interesting, which gcc version?
On Tuesday, August 5, 2014 4:19:02 PM UTC+1, Harald Schilly wrote:
>
>
>
> On Monday, August 4, 2014 7:39:40 PM UTC+2, Volker Braun wrote:
>>
>> Here is the first release candidate. Please give it a test and report any
>> build problems.
>>
>
> It failed for me in
On Monday, August 4, 2014 7:39:40 PM UTC+2, Volker Braun wrote:
>
> Here is the first release candidate. Please give it a test and report any
> build problems.
>
It failed for me in r-3.1.1.p0/Matrix
* DONE (lattice)
begin installing recommended package Matrix
* installing *source* package 'Ma
Fixed. Sorry, jet lag ;-)
On Tuesday, August 5, 2014 8:58:56 AM UTC+1, Dima Pasechnik wrote:
>
> On 2014-08-04, Volker Braun > wrote:
> > --=_Part_1781_1329544834.1407173980834
> > Content-Type: text/plain; charset=UTF-8
> >
> > Here is the first release candidate. Please give it a test an
On 2014-08-05, Dima Pasechnik wrote:
> On 2014-08-05, Dima Pasechnik wrote:
>> On 2014-08-04, Volker Braun wrote:
>>> --=_Part_1781_1329544834.1407173980834
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> Here is the first release candidate. Please give it a test and report any
>>> buil
On 2014-08-05, Dima Pasechnik wrote:
> On 2014-08-04, Volker Braun wrote:
>> --=_Part_1781_1329544834.1407173980834
>> Content-Type: text/plain; charset=UTF-8
>>
>> Here is the first release candidate. Please give it a test and report any
>> build problems. As usual, get the newest git "deve
On 2014-08-04, Volker Braun wrote:
> --=_Part_1781_1329544834.1407173980834
> Content-Type: text/plain; charset=UTF-8
>
> Here is the first release candidate. Please give it a test and report any
> build problems. As usual, get the newest git "develop" branch or
hmm, I can't get it:
seems t
On 2014-08-04, François Bissey wrote:
> On Mon, 04 Aug 2014 14:49:20 Jeroen Demeyer wrote:
>> On 2014-08-04 13:52, Volker Braun wrote:
>> > IMHO it is a reasonable burden to "make distclean" once in a while to
>> > back out of broken packages during the beta cycle.
>>
>> As long as the upgrade fr
Agree, we should get ready for 6.3. Outstanding issues:
* The permissions of the release folder on boxen need to be fixed
* I slammed my finger in a door and it is painful to type
And recently fixed:
* I was traveling and just got back to the UK a few hours ago
On Monday, August 4, 2014 12:54:3
On 2014-08-02, Jan Keitel wrote:
> --=_Part_883_789377487.1406978171680
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> Okay, found them:
>
> gmp: 4.3.1
> mpfr: 2.4.1
> mpc: 0.8.1
>
> Is there a way to force the sage installation not to use the globa
I've created http://trac.sagemath.org/ticket/16751 for this issue.
On Saturday, August 2, 2014 4:18:59 AM UTC-4, Jan Keitel wrote:
>
> I can't build this on a 2013 MacBook Air running Mac Os 10.9.4, because
> Singular fails to build:
>
> Error building Sage.
>
> The following package(s) may hav
Volker: The same error persists. I can attach the logs again if you're
interested, but I'm not sure that there's anything new to be learned.
Am Samstag, 2. August 2014 13:22:58 UTC+2 schrieb Jan Keitel:
>
> Sure, I'll do that right away. In fact, I think on this laptop beta5 might
> have been th
Sure, I'll do that right away. In fact, I think on this laptop beta5 might
have been the last working version. Not sure, but I might have left one
version out here.
Am Samstag, 2. August 2014 13:17:47 UTC+2 schrieb Volker Braun:
>
> Can you try a serial build? There might be a race in the singul
Can you try a serial build? There might be a race in the singular build
system. I've never seen this on the OSX 10.9 buildbot.
export MAKE='make -j1'
make
The ticket Trac #13331: Build Singular with FLINT support had already been
merged in beta6
On Saturday, August 2, 2014 4:18:59 AM UTC-4
On 2014-08-02, Jan Keitel wrote:
> I can't build this on a 2013 MacBook Air running Mac Os 10.9.4, because
> Singular fails to build:
>
> Error building Sage.
>
> The following package(s) may have failed to build:
>
> package: singular-3.1.6.p3
> log file: /Users/kabel/sage/sage/logs/pkgs/singula
I can't build this on a 2013 MacBook Air running Mac Os 10.9.4, because
Singular fails to build:
Error building Sage.
The following package(s) may have failed to build:
package: singular-3.1.6.p3
log file: /Users/kabel/sage/sage/logs/pkgs/singular-3.1.6.p3.log
build directory:
/Users/kabel/sag
> Doctesting shouldn't require a web connection, at least as long as you don't
> specify --optional=internet... NATHANNN ;-)
Sorry T_T
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop rece
With only 2gb of ram your are probably better off building in a single
process.
Doctesting shouldn't require a web connection, at least as long as you
don't specify --optional=internet... NATHANNN ;-)
On Thursday, July 31, 2014 8:04:52 AM UTC-4, Emmanuel Charpentier wrote:
>
> export MAKE="mak
FYI :
On an antique i686 2Gb RAM, starting from sage 6.3beta6:
git fetch
git pull
export MAKE="make -j2"
make
==> compilation successful in in about 1/2 hour, but with lots of swapping
(trashing ?)
make ptestlong ## needs 88 mins wall time, 148 mins CPU
2 errors :
--
On Wednesday, July 30, 2014 8:05:33 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Wednesday, 30 July 2014 05:49:09 UTC+1, John H Palmieri wrote:
>>
>>
>>
>> On Monday, July 28, 2014 10:40:42 AM UTC-7, Volker Braun wrote:
>>>
>>> See the "develop" git branch or download the all-in-one tarball
>>>
>>>
On Wednesday, 30 July 2014 05:49:09 UTC+1, John H Palmieri wrote:
>
>
>
> On Monday, July 28, 2014 10:40:42 AM UTC-7, Volker Braun wrote:
>>
>> See the "develop" git branch or download the all-in-one tarball
>>
>>
>> http://boxen.math.washington.edu/home/vbraun/tmp-release/sage-6.3.beta7.tar.gz
>
On Monday, July 28, 2014 10:40:42 AM UTC-7, Volker Braun wrote:
>
> See the "develop" git branch or download the all-in-one tarball
>
>
> http://boxen.math.washington.edu/home/vbraun/tmp-release/sage-6.3.beta7.tar.gz
>
I can't get the PDF documentation to build because of
http://trac.sagemath.o
>
> Is there a posting/page that lists what is needed
> to get rid of the expect interface?
>
Wishful thinking at
http://trac.sagemath.org/ticket/16688
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop rec
On 19 Jul 2014 14:57, "leif" wrote:
>
> Ralf Stephan wrote:
>>
>> Is there a posting/page that lists what is needed
>> to get rid of the expect interface?
>
>
> There's been some related discussion recently on this list (Sage
6.3.beta2 thread), and earlier [repeatedly ;-) ] on sage-devel, but AFAI
This meta-ticket tracks random doctest failures:
http://trac.sagemath.org/ticket/15459
On Saturday, July 19, 2014 8:14:22 AM UTC-4, Emmanuel Charpentier wrote:
>
> make ptestlong got me one failure in src/sage/interfaces/expect.py at line
> 796. Doctesting it standalone (./sage -t --long
> sr
Ralf Stephan wrote:
Is there a posting/page that lists what is needed
to get rid of the expect interface?
There's been some related discussion recently on this list (Sage
6.3.beta2 thread), and earlier [repeatedly ;-) ] on sage-devel, but
AFAIK there's not really a plan or schedule for comple
On 19 Jul 2014 14:14, "Emmanuel Charpentier"
wrote:
>
> make ptestlong got me one failure in src/sage/interfaces/expect.py at
line 796. Doctesting it standalone (./sage -t --long
src/sage/interfaces/expect.py ) was successful ("All test passed!").
>
> Looks like a timeout due to heavy parallelism
make ptestlong got me one failure in src/sage/interfaces/expect.py at line
796. Doctesting it standalone (./sage -t --long
src/sage/interfaces/expect.py ) was successful ("All test passed!").
Looks like a timeout due to heavy parallelism of tests. Probably a glitch,
at worst a boboo...
HTH,
-
Yo Volker !
I was wondering : when do you think the next "stable" release will occur ?
It's nothing important, I am just wondering when the online doc of Sage
will display the new "combinatorial design" pages :-)
Nathann
On Saturday, July 19, 2014 11:25:25 AM UTC+2, leif wrote:
>
>
On 19.07.2014 11:07, Emmanuel Charpentier wrote:
Ahem...
Le samedi 19 juillet 2014 07:14:20 UTC+2, Volker Braun a écrit :
Get it from the "develop" git branch or download the self-contained
source tarball at
http://boxen.math.washington.edu/home/tmp-release/sage-6.3.beta6.tar.gz
Ahem...
Le samedi 19 juillet 2014 07:14:20 UTC+2, Volker Braun a écrit :
>
> Get it from the "develop" git branch or download the self-contained source
> tarball at
>
> http://boxen.math.washington.edu/home/tmp-release/sage-6.3.beta6.tar.gz
>
[ Bandwidth savings : Snip... ]
My browser says :
"
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
On Tue, Jun 10, 2014 at 10:53 AM, leif wrote:
> R isn't used in Sage library code AFAIK.
>
There is one place in sage/stats/r.py which basically go away and be
replace by an rpy2 call.
> Not sure whether the library interfaces offer the full functionality [yet].
rpy2 can do everything what R ca
On 10 June 2014 10:23, leif wrote:
> John Cremona wrote:
>>
>> On 10 June 2014 09:53, leif wrote:
>>>
>>> John Cremona wrote:
On 9 June 2014 23:55, Volker Braun wrote:
>
>
> Thanks for the investigative work!
>
> Using the terminal echo isn't really a solution,
John Cremona wrote:
On 10 June 2014 09:53, leif wrote:
John Cremona wrote:
On 9 June 2014 23:55, 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 an
On 10 June 2014 09:53, leif wrote:
> John Cremona wrote:
>>
>> On 9 June 2014 23:55, 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 an
John Cremona wrote:
On 9 June 2014 23:55, 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 stdout.
On 9 June 2014 23:55, 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 stdout.
>
> Did I men
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 stdout.
Did I mention that I hate pexpect ;-)
--
You received this m
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 r
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 usually its only one or two that
>> fail. There was a bug in
On 2014-06-07, 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 usually its only one or two that
>> fail. There was a bug in pexpect that got fixed in beta3,
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 ba
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 Saturday, June 7, 2014 6:42:41 PM UTC+1, John H Palmieri wrote:
>
>
>
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 rer
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. Here is a
sample of the output from "make ptestlong":
-
John H Palmieri wrote:
On Tuesday, May 27, 2014 4:09:11 AM UTC-7, leif wrote:
P Purkayastha wrote:
> Just use "sage --upgrade"
Yes, that's what ordinary users should use (and developers /pulling/ a
new [devel] version, instead of 'git pull ... && make').
I just tried this: I w
On Tuesday, May 27, 2014 4:09:11 AM UTC-7, leif wrote:
>
> 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 co
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 ac
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
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 s
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 version string
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 even 'sudo open a ticket' f
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
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 fail when testing, and the reviewer too?
Please tell what I'm missing.
Reg
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 name
Nathann Cohen wrote:
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
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'
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
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.
Nathann Cohen wrote:
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.
To the top-level *Makefile* that is. ('?=' is not [ba]sh syntax AFAIK.)
(And I originally only wanted to add an additional
> 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 st
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 d
> 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 t
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 a
> 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 ...
Nathann
--
You received this mess
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 mak
> 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 a
On Monday, May 26, 2014 3:17:18 PM UTC+2, 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 ?
>
Lazyness?
--
You received this m
> 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 ?
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To un
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 ! :-)
>
>
> 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 sage-release+
I had the same problem. As I was in no hurry I just did a distclean
(doc-clean was not sufficient).
John
On 26 May 2014 11:58, Ralf Stephan wrote:
> sage -f ecl, followed by sage -f maxima did it for me.
>
> On 26 May 2014 12:41, "Nathann Cohen" wrote:
>>
>> Hello !!
>>
>> With this release I
1 - 100 of 118 matches
Mail list logo
