On 05/13/11 07:45 PM, kcrisman wrote:
$ export SAGE_PARALLEL_SPKG_BUILD=yes
$ export MAKE='make -j8'
$ make
See the installation guide for information about the relevant environment
variables. I think that we should set SAGE_PARALLEL_SPKG_BUILD to "yes"
automatically -- it works very well, a
On Tue, May 10, 2011 at 3:35 PM, John H Palmieri wrote:
>
>
> On Tuesday, May 10, 2011 2:38:38 PM UTC-7, Ondrej Certik wrote:
>>
>> On Tue, May 10, 2011 at 7:19 AM, Volker Braun
>> wrote:
>> > IMHO the list of installed files is an integral piece of package
>> > management
>> > and should explici
> On Thursday, May 12, 2011 3:18:29 PM UTC-7, Ondrej Certik wrote:
> > On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
> > wrote:
> > [...]
> >
> > >> What would be the advantage of having it in the SPKG itself?
> > >
> > > That it wil be compatible with parallel building as mentioned earlier.
On Thursday, May 12, 2011 3:18:29 PM UTC-7, Ondrej Certik wrote:
>
> On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
> wrote:
> [...]
> >>
> >> What would be the advantage of having it in the SPKG itself?
> >>
> > That it wil be compatible with parallel building as mentioned earlier.
> >
> >> L
On Thu, May 12, 2011 at 5:29 AM, Maarten Derickx
wrote:
[...]
>>
>> What would be the advantage of having it in the SPKG itself?
>>
> That it wil be compatible with parallel building as mentioned earlier.
>
>> Like if you want to install two packages that overwrite the same file?
> I don't think w
On 05/10/11 11:35 PM, John H Palmieri wrote:
Does Sage work with parallel installation of packages?
Absolutely. Do:
$ export SAGE_PARALLEL_SPKG_BUILD=yes
$ export MAKE='make -j8'
$ make
See the installation guide for information about the relevant environment
variables. I think that we sho
On Tue, May 10, 2011 at 11:23 PM, Maarten Derickx
wrote:
>
>
> On May 10, 9:10 am, Ondrej Certik wrote:.
>>
>> It just occurred to me, that it should be possible to keep the current
>> SPKG format, and implement uninstall. One just needs to keep track of
>> all files in SPKG_LOCAL, then see what
On Tue, May 10, 2011 at 7:19 AM, Volker Braun wrote:
> IMHO the list of installed files is an integral piece of package management
> and should explicitly be part of the spkg. Automatically generating it is
> not an option during parallel compilation. There should be a "spkg-files" or
> so in the
On Tuesday, May 10, 2011 2:38:38 PM UTC-7, Ondrej Certik wrote:
>
> On Tue, May 10, 2011 at 7:19 AM, Volker Braun
> wrote:
> > IMHO the list of installed files is an integral piece of package
> management
> > and should explicitly be part of the spkg. Automatically generating it is
> > not an
On Tue, May 10, 2011 at 7:19 AM, Volker Braun wrote:
> IMHO the list of installed files is an integral piece of package management
> and should explicitly be part of the spkg. Automatically generating it is
> not an option during parallel compilation. There should be a "spkg-files" or
That's a go
IMHO the list of installed files is an integral piece of package management
and should explicitly be part of the spkg. Automatically generating it is
not an option during parallel compilation. There should be a "spkg-files" or
so in the spkg that lists them. During single package build one could
On 05/10/11 08:10 AM, Ondrej Certik wrote:
It just occurred to me, that it should be possible to keep the current
SPKG format, and implement uninstall. One just needs to keep track of
all files in SPKG_LOCAL, then see what new files were added + which
files have changed.
Why not something like
On Mon, May 9, 2011 at 4:48 PM, Ondrej Certik wrote:
> On Mon, May 9, 2011 at 4:01 PM, Robert Bradshaw
> wrote:
>> On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik wrote:
> [...]
>>> I was thinking about this a lot yesterday, and there are a lot more
>>> issues to resolve, than it seems at first si
On Mon, May 9, 2011 at 4:01 PM, Robert Bradshaw
wrote:
> On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik wrote:
[...]
>> I was thinking about this a lot yesterday, and there are a lot more
>> issues to resolve, than it seems at first sight. In particular, some
>> packages like Python is doing some
On Mon, May 9, 2011 at 2:57 PM, Ondrej Certik wrote:
> On Mon, May 9, 2011 at 9:11 AM, Robert Bradshaw
> wrote:
>> On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
>>> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
>>> wrote:
On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
>
On Mon, May 9, 2011 at 9:11 AM, Robert Bradshaw
wrote:
> On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
>> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
>> wrote:
>>> On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
> On
On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
> wrote:
>> On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
>>> On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
wrote:
>>>
On Mon, May 9, 2011 at 3:05 AM, Ondrej Certik wrote:
> On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
[...]
>> What about
>> dependencies (e.g. if the version of Cython was updated, would all the
>> stuff depending on Cython get re-compiled?
>
> No. Only the other way round -- if you want to inst
On Sat, May 7, 2011 at 9:41 PM, Robert Bradshaw
wrote:
> On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
>> On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
>>> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
>>> wrote:
>>> [...]
Were I to design the system from scratch, I'd put
On 2011-05-08 06:31, Robert Bradshaw wrote:
> But it isn't exposed as an hg repository anywhere
I'm happy to expose whatever as hg repository if somebody explains me
what and how.
> The
> fact that so much is not under (a single) revision control makes this
> harder.
You mean that it's harder to r
On Fri, May 6, 2011 at 2:21 PM, Ondrej Certik wrote:
> On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
>> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
>> wrote:
>> [...]
>>> Were I to design the system from scratch, I'd put
>>> all our code (devel/scripts/...) in a single repo, along wi
On Sat, May 7, 2011 at 2:55 AM, Jeroen Demeyer wrote:
> On 2011-05-06 20:26, Robert Bradshaw wrote:
>> And
>> I'd love to have a live head to test and rebase against. Something
>> like the sage merger script, but automated as every ticket on trac
>> with positive review + release manager approval
On 2011-05-06 20:26, Robert Bradshaw wrote:
> And
> I'd love to have a live head to test and rebase against. Something
> like the sage merger script, but automated as every ticket on trac
> with positive review + release manager approval + passing on these X
> systems (on top of last previous head)
On Fri, May 6, 2011 at 2:19 PM, Ondrej Certik wrote:
> On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
> wrote:
> [...]
>> Were I to design the system from scratch, I'd put
>> all our code (devel/scripts/...) in a single repo, along with the
>> top-level files, and a list of dependencies (spkgs)
On Fri, May 6, 2011 at 11:26 AM, Robert Bradshaw
wrote:
[...]
> Were I to design the system from scratch, I'd put
> all our code (devel/scripts/...) in a single repo, along with the
> top-level files, and a list of dependencies (spkgs). Building sage
> would fetch (locally or remotely) the depende
On Fri, May 6, 2011 at 11:41 AM, Martin Albrecht
wrote:
>> The other problem is that so much isn't under revision control (eg.
>> what versions of spkgs to use), or in multiple repositories that need
>> to be kept in sync. Were I to design the system from scratch, I'd put
>> all our code (devel/sc
> The other problem is that so much isn't under revision control (eg.
> what versions of spkgs to use), or in multiple repositories that need
> to be kept in sync. Were I to design the system from scratch, I'd put
> all our code (devel/scripts/...) in a single repo, along with the
> top-level files
On Fri, May 6, 2011 at 12:12 AM, Keshav Kini wrote:
> Hi Jeroen,
>
> I'd suggest that SPKG authors make their final commit themselves rather than
> just allowing Jeroen's script to do it for them - this keeps the "blame
> history" intact (assuming Jeroen's script doesn't mine people's names from
>
Hi Jeroen,
I'd suggest that SPKG authors make their final commit themselves rather than
just allowing Jeroen's script to do it for them - this keeps the "blame
history" intact (assuming Jeroen's script doesn't mine people's names from
SPKG.txt and commit under those names!).
I sometimes worry
On 5 May 2011 23:02, Francois Bissey wrote:
>> I suppose for my spkg workflow (mostly Cython) the new spkg doesn't
>> usually involve anything more than swapping out the sources and
>> perhaps adding/removing a patch. Adding an SPKG.txt entry is entirely
>> redundant with the hg commit (if one is
On Thu, May 5, 2011 at 3:02 PM, Francois Bissey
wrote:
>> On Thu, May 5, 2011 at 1:34 PM, Jason Grout
> wrote:
>> > On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
>> >> On 2011-05-05 20:20, Dr. David Kirkby wrote:
>> >>> I like SPKG.txt. Personally I would have called the file "ChangeLog"
>> >>> in
>>
> On Thu, May 5, 2011 at 1:34 PM, Jason Grout
wrote:
> > On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
> >> On 2011-05-05 20:20, Dr. David Kirkby wrote:
> >>> I like SPKG.txt. Personally I would have called the file "ChangeLog" in
> >>> common with just about every other software project, but SPKG.txt
On Thu, May 5, 2011 at 1:34 PM, Jason Grout wrote:
> On 5/5/11 3:29 PM, Jeroen Demeyer wrote:
>>
>> On 2011-05-05 20:20, Dr. David Kirkby wrote:
>>>
>>> I like SPKG.txt. Personally I would have called the file "ChangeLog" in
>>> common with just about every other software project, but SPKG.txt doe
On 2011-05-05 20:20, Dr. David Kirkby wrote:
> I like SPKG.txt. Personally I would have called the file "ChangeLog" in
> common with just about every other software project, but SPKG.txt does.
> I think that summerises the changes much better than what "hg log" does,
> where often there are numerou
On 05/ 5/11 04:47 PM, kcrisman wrote:
Further ideas, suggestions, complaints are welcome.
I agree with the sentiment expressed elsewhere in previous threads that
the changelog should be in the hg log, and not necessarily in the
SPKG.txt file. In other words, I feel like the changes you made
On Thu, May 5, 2011 at 8:47 AM, kcrisman wrote:
>
>> > Further ideas, suggestions, complaints are welcome.
>>
>> I agree with the sentiment expressed elsewhere in previous threads that
>> the changelog should be in the hg log, and not necessarily in the
>> SPKG.txt file. In other words, I feel li
36 matches
Mail list logo
