On Thu, Jan 23, 2014 at 10:53 PM, kcrisman wrote:
> Also, is there a way to do this but not have the folder created called
> "sage"? (E.g. "my_sage_folder"?) Perhaps it is some option for git clone -
> that could be added to any help on the doc.
That's quite straight forward:
git clone git://g
>
>
> If you use git, you can do
>
> git clone git://github.com/sagemath/sage.git
> cd sage
> make
>
>
http://sagemath.org/doc/installation/source.html has no mention of this as
an alternate path to enlightenment.
Also, is there a way to do this but not have the folder created called
Obvious question would be: what is your Python path? I guess set to the
empty string. Unset variables that if you don't want, don't set them to the
empty string.
Cleaning up PYTHONPATH:
Old:
":/u/ggeorg/data/sync/software/python:/scratch/userdata/sage-6.0/local/lib/python"
New:
I just want to confirm that removing /usr/local64.hg/bin from the path
solves the problem.
But there is still one doctest failure:
sage -t --long src/sage/tests/cmdline.py
**
File "src/sage/tests/cmdline.py", line 204, in
sage.
Thanks for all the answers, I think I know what I'll do now:
* update package-version.txt if a rebuild is needed on any system where the
previous version did build as well.
* update a tarball name with date info if some change is needed without an
actual upstream version bump.
* remove old histor
On 23 January 2014 12:56, Volker Braun wrote:
> You *should* not change upstream tarballs. Sometimes, we have to. There is
> no good way to change the upstream tarball without changing the version
> number. Arguably, thats a feature. Maybe use package-2014123.tar.gz if you
> have to.
>
> There is
> (*) these really ought to be addressed in future changes to the build
> system.
By the way, wasn't there some talk at some point of automatically
testing optiona doctests when the corresponding spkg is installed ? I
do not know if anything happened on that front, but it would be
totally cool !!!
On 2014-01-23 10:51, Jean-Pierre Flori wrote:
* package-version.txt, should it only be updated when the tarball
changes?
package-version.txt is what triggers a rebuild of a package, so the .p
level must be increased whenever you make a change to a package which
affects the functioning of the pa
You *should* not change upstream tarballs. Sometimes, we have to. There is
no good way to change the upstream tarball without changing the version
number. Arguably, thats a feature. Maybe use package-2014123.tar.gz if you
have to.
There is no point in a spkg-src script if the tarball is not mod
On Thursday, January 23, 2014 12:07:44 PM UTC+1, John Cremona wrote:
>
> Yes, I was told that upstream tarballs should not contain any Sage
> changes, those should be done via patches in the install script. And
> hence upstream tarballs should not have any .p in them. I did that
> wrongly wh
Yes, I was told that upstream tarballs should not contain any Sage
changes, those should be done via patches in the install script. And
hence upstream tarballs should not have any .p in them. I did that
wrongly when I redid the database_stein_watkins optional spkgs for git
and was told to change
On Thursday, January 23, 2014 11:43:36 AM UTC+1, Jean-Pierre Flori wrote:
>
> Yet another question:
> * "upstream" tarballs are stored in the upstream dir without the ".p?"
> part, but are not really upstream, i.e. can be repackaged, stripped,
> include additional stuff.
> So how to update thes
Yet another question:
* "upstream" tarballs are stored in the upstream dir without the ".p?"
part, but are not really upstream, i.e. can be repackaged, stripped,
include additional stuff.
So how to update these tarballs when the actual upstream version is the
same, but the sage specific changes
On 23 January 2014 10:13, Jean-Pierre Flori wrote:
> To be completely clear, two additional questions:
>
>
> On Thursday, January 23, 2014 10:57:29 AM UTC+1, John Cremona wrote:
>>
>> Here is how I have interprested these questions for the packages I am
>> involved in maintining:
>> > * package-ve
> So you actually removed all the old info stored there?
It also happens there : http://trac.sagemath.org/ticket/9870
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, se
To be completely clear, two additional questions:
On Thursday, January 23, 2014 10:57:29 AM UTC+1, John Cremona wrote:
>
> Here is how I have interprested these questions for the packages I am
> involved in maintining:
> > * package-version.txt, should it only be updated when the tarball
> chan
Here is how I have interprested these questions for the packages I am
involved in maintining:
On 23 January 2014 09:51, Jean-Pierre Flori wrote:
> Ooops, end of message follows...
>
>
> On Thursday, January 23, 2014 10:43:42 AM UTC+1, Jean-Pierre Flori wrote:
>>
>> Dear all,
>>
>> I'm a little co
Ooops, end of message follows...
On Thursday, January 23, 2014 10:43:42 AM UTC+1, Jean-Pierre Flori wrote:
>
> Dear all,
>
> I'm a little confused by the way spkg should now be updated.
> The official doc is now here:
> * http://www.sagemath.org/doc/developer/packaging.html
>
My questions are mai
Dear all,
I'm a little confused by the way spkg should now be updated.
The official doc is now here:
* http://www.sagemath.org/doc/developer/packaging.html
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop
19 matches
Mail list logo
