Ah, ok. There is currently a race with the installation of setuptools-using
Python packages (which includes matplotlib dependencies). This looks very
much like it.
It will be fixed by http://trac.sagemath.org/ticket/13201, I hope...
--
You received this message because you are subscribed to t
~/.Sage is my SAGE_ROOT.
Nathann
On Monday, 10 March 2014, Dima Pasechnik wrote:
> On 2014-03-10, Nathann Cohen >
> wrote:
> >> By "this bug", you mean even after a "make distclean" it does not
> compile?
> >> Or just get to a step where "make" doesn't work, the latter is probably
> easy
> >> s
On 2014-03-10, Nathann Cohen wrote:
>> By "this bug", you mean even after a "make distclean" it does not compile?
>> Or just get to a step where "make" doesn't work, the latter is probably easy
>> since some packages can trip over headers that were left over by old /
>> incomplete installs.
>
> Th
> By "this bug", you mean even after a "make distclean" it does not compile?
> Or just get to a step where "make" doesn't work, the latter is probably easy
> since some packages can trip over headers that were left over by old /
> incomplete installs.
The report above was obtained by erasing SAGE_
By "this bug", you mean even after a "make distclean" it does not compile?
Or just get to a step where "make" doesn't work, the latter is probably
easy since some packages can trip over headers that were left over by old /
incomplete installs.
On Monday, March 10, 2014 2:23:30 PM UTC, Nathann
Because Sage would not start anymore after I "finally achieved" to
reproduce this bug, I tried to recompile Sage from scratch... And ended up
with that :
NOTE: Set SAGE_MATPLOTLIB_GUI to anything but 'no' to try to build the
Matplotlib GUI.
N
ccache doesn't cache autoconf tests or tuning runs, so it helps but isn't
the solution.
On Monday, March 10, 2014 11:48:10 AM UTC, Nathann Cohen wrote:
>
> > Just make a backup of the third-party files before installing a newer
> > version. When you reinstall the old version, just restore that
> Just make a backup of the third-party files before installing a newer
> version. When you reinstall the old version, just restore that backup. Of
> course we'd need a way to track installed files, but we need that anyways
> for multiple other reasons.
H... That's what ccache does, right ? I
On Monday, March 10, 2014 11:42:52 AM UTC, Nathann Cohen wrote:
>
> ? You think that there is an proper way to do that ?
>
Just make a backup of the third-party files before installing a newer
version. When you reinstall the old version, just restore that backup. Of
course we'd need a way to tr
> Agree, but the proper fix is to improve our build system. Not develop arcane
> tricks to work around it.
? You think that there is an proper way to do that ?
Well, what we could do is auto-merge the git branches hosted on trac
against the latest devel, to be sure that a git branch that you impo
On Monday, March 10, 2014 11:24:28 AM UTC, Nathann Cohen wrote:
>
> Well, the problem with this method is that you have to checkout a
> potentially old branch, which forces you to recompile everything O_o
>
Agree, but the proper fix is to improve our build system. Not develop
arcane tricks to wo
> That's to say, you recommend that I keep doing this:
Well, the problem with this method is that you have to checkout a
potentially old branch, which forces you to recompile everything O_o
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-release" grou
Hi Volker,
On 2014-03-10, Volker Braun wrote:
> Both just add a merge commit on top of my_branch, so history is preserved.
Really? That's a relief...
> The customary (and hence slightly easier to understand later on) option is
> the first one, which also requires fewer git commands.
>
Tha
On Monday, March 10, 2014 9:01:52 AM UTC, Simon King wrote:
>
> Up to now, in the above situation, I would *not* merge new_branch into
> the updated develop and call the result again new_branch, since I was
> too often told that this is changing history
No, that is not changing history. You are
Y !!
> Thank you! I was thinking about a different situation: I already have the
> new_branch, I want to merge it with an updated develop branch, and the result
> of
> the operation should still be called new_branch.
H Well, in this case if you have never compiled the updated
Hi Nathann,
On 2014-03-09, Nathann Cohen wrote:
> git checkout trac/develop # or whatever the name of develop is on your install
> git checkout -b new_branch
> git pull trac u/ncohen/whatever
>
> This creates an empty branch on develop, then merges the distant
> branch into it, i.e. above develop
16 matches
Mail list logo
