hi there.
On Fri, Apr 12, 2013 at 05:13:14PM -0600, David Roe wrote:
> But speaking as someone who contributes a lot to the Sage library itself,
> I'm strongly in support of Robert Bradshaw's proposal that we combine the
> different Sage repositories (root, devel, script and ext). It's much
> eas
First a disclaimer: I was at Sage Days 47 (working on the transition to
git), but I'm not a git expert and I don't know the technical justification
for some of the choices made (I think the best people to speak up in that
direction would be Andrew Ohana, Keshav Kini, Robert Bradshaw, Timo Kluck
or
On 13/04/2013, at 4:24, "Felix Salfelder" wrote:
> On Fri, Apr 12, 2013 at 09:23:45PM +1200, Francois Bissey wrote:
>> I'd like to note that on gentoo we only use things like
>> sage-singular-xxx as an exception - singular is a particularly good
>> example, since it was the last one we had year
On Fri, Apr 12, 2013 at 09:23:45PM +1200, Francois Bissey wrote:
> I'd like to note that on gentoo we only use things like
> sage-singular-xxx as an exception - singular is a particularly good
> example, since it was the last one we had years ago. Compared to debian
> we have a little bit more free
On 04/11/2013 11:48 PM, Tobias Hansen wrote:
If they are each in a selfcontained folder it's not too much hassle to
repack them from the one tarball. (Ok, still some hassle.) However, I
don't see why they should not be in one source package. Because linking
to c_lib has to be done differently whe
On 12/04/13 20:59, Tobias Hansen wrote:
> Am 12.04.2013 10:25, schrieb Felix Salfelder:
>> Hi there.
>>
>> On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote:
so theres the inevitable question to ask:
would it be an option to eventually split c_lib and the python modules
t
Am 12.04.2013 10:25, schrieb Felix Salfelder:
> Hi there.
>
> On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote:
>>> so theres the inevitable question to ask:
>>> would it be an option to eventually split c_lib and the python modules
>>> to different packages?
>>
>> If they are each in
Hi there.
On Thu, Apr 11, 2013 at 11:48:17PM +0200, Tobias Hansen wrote:
> > so theres the inevitable question to ask:
> > would it be an option to eventually split c_lib and the python modules
> > to different packages?
>
> If they are each in a selfcontained folder it's not too much hassle to
>
Let's drop debian-science from CC. For those interested, the thread on
sage-devel is at
https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/1HGbf4EZGb0
Am 11.04.2013 22:27, schrieb Felix Salfelder:
> in debian, one source package can create multiple binary packages.
> this for example m
On Thu, 11 Apr 2013 22:27:48 Felix Salfelder wrote:
> Hi there.
>
> On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote:
> > From the point of view of a linux distribution, my opinion is that the
> > package management system should be extracted. If it comes from your
> > distro the pa
Hi there.
On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote:
> From the point of view of a linux distribution, my opinion is that the
> package
> management system should be extracted. If it comes from your distro the
> packages and upgrades are handled by the distro mechanism, ex
On 04/11/2013 01:36 PM, Travis Scrimshaw wrote:
On Thursday, April 11, 2013 4:29:33 AM UTC-4, Volker Braun wrote:
Also, a top-level configure script is the natural point to select
alternatives to 3rd party code. For example, one should be able to
./configure --with-mpir=/usr --wit
On Thursday, April 11, 2013 4:29:33 AM UTC-4, Volker Braun wrote:
>
> Also, a top-level configure script is the natural point to select
> alternatives to 3rd party code. For example, one should be able to
>
> ./configure --with-mpir=/usr --with-gap=/usr/local
>
> to use an external mpir and gap
Also, a top-level configure script is the natural point to select
alternatives to 3rd party code. For example, one should be able to
./configure --with-mpir=/usr --with-gap=/usr/local
to use an external mpir and gap install...
On Thursday, April 11, 2013 8:00:30 AM UTC+1, Jeroen Demeyer wrote
Hi there.
On Thu, Apr 11, 2013 at 01:04:23AM +0200, Tobias Hansen wrote:
> Remember the git transition. spkg's will go away. There will be just one
> tarball containing everything in the future. The sources of other
> projects will be better separated, so it will be easy to get a Sage
> tarball wi
On 04/11/2013 01:53 AM, R. Andrew Ohana wrote:
For those so inclined to browse the current status of the git
transition, the repository is at https://github.com/sagemath/sage.
Yes, it is completely obvious that this Debian packaging effort should
start from the GIT repository, not from the curre
On Wed, Apr 10, 2013 at 4:04 PM, Tobias Hansen wrote:
> Am 10.04.2013 17:43, schrieb Felix Salfelder:
> > several parts of fixing/changing/improving the sage (the system) build
> > system is unrelated to distributing sage "the library". so "changes to
> > the build system in Sage" is somewhat vag
Hi,
I'll give some answers from my point of view as one of the lead of sage-on-
gentoo https://github.com/cschwan/sage-on-gentoo. Some of the problems
discussed we encountered and have an opinion on. Whether some of the things
we do or have done are applicable to Debian is best answered by Debian
Am 10.04.2013 17:43, schrieb Felix Salfelder:
> several parts of fixing/changing/improving the sage (the system) build
> system is unrelated to distributing sage "the library". so "changes to
> the build system in Sage" is somewhat vague.
>
> i think a build system for the sage library should at le
On 10.04.2013 17:43, Felix Salfelder wrote:
> Hi Tobias
>
> On Tue, Apr 09, 2013 at 10:26:30AM +0200, Tobias Hansen wrote:
>> No, the toplevel install script must just be able to skip the
>> compilation of these spkg's. And tell the Sage library to use the
>> libraries that are available and were
On 09.04.2013 14:18, Tobias Hansen wrote:
> On 04/09/2013 10:26 AM, Tobias Hansen wrote:
>>>
>>> a build system for sage ("the library") could be used to switch between
>>> system headers/libraries and stuff installed to /some/sage/prefix.
>>> in order to make use of these switches from sage ("the
On 09.04.2013 10:26, Tobias Hansen wrote:
> Hi Felix,
>
> On 04/09/2013 09:49 AM, Felix Salfelder wrote:
>> a proper build system for sage ("the library") with the usual dependency
>> checks seems neccesary (if not sufficient) for distributions. i can
>> think of
>> a way to implement this (probab
Sorry, there were a few mails that missed the list:
On 09.04.2013 09:49, Felix Salfelder wrote:
> Hi
>
> thanks for establishing this!
>
> i can imagine applying for that project. at least i'll have some time
> left in summer, as i'm on parental leave and i found a nursery...
> i'd like to discu
Two people from Sage, Jeroen Demeyer and John Palmieri, volunteered to
cover the Sage side of mentoring the project. Julien Puydt, who already
put a lot of work into packaging Sage dependencies for Debian, is also
on board. All we need now is a student.
Cheers,
Tobias
--
You received this messag
On Sun, Mar 17, 2013 at 9:28 AM, Julien Puydt wrote:
> Le 17/03/2013 15:22, leif a écrit :
>
>> than...@debian.org wrote:
>>>
>>> Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif:
>>> But if we switch to git, improve Sage's package management (as a first
>>> step, split vanilla upstream sourc
Julien Puydt wrote:
H... there is no .hg in $SAGE_ROOT/devel/sage/, but there is one in
$SAGE_ROOT/, another in $SAGE_ROOT/local/bin/, another in
$SAGE_ROOT/devel/sage-main/ and a fourth in
$SAGE_ROOT/devel/ext-main/... [looking at a freshly compiled sage 5.7 on
my ARM box]
:-) devel/sage i
Le 17/03/2013 15:22, leif a écrit :
than...@debian.org wrote:
Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif:
But if we switch to git, improve Sage's package management (as a first
step, split vanilla upstream sources off the spkgs :P ), ...
Is splitting the vanilla upstream sources off
than...@debian.org wrote:
Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif:
But if we switch to git, improve Sage's package management (as a first
step, split vanilla upstream sources off the spkgs :P ), ...
Is splitting the vanilla upstream sources off planned? That would be
very
On 2013-03-17 09:38, Julien Puydt wrote:
> The impression I have is that
> by default, a patch in an spkg has not.
It really should be. It doesn't mean that upstream will *accept* the
patch of course.
Or sometimes, Sage contains patches to spkgs which are just meant for
the Sage <-> package inter
On 17/03/13 21:38, Julien Puydt wrote:
> Le 17/03/2013 00:36, than...@debian.org a écrit :
>> Is splitting the vanilla upstream sources off planned? That would be
>> very helpful for distributions. Another helpful thing would be a clear
>> distinction between fixes/adjustment to the library and Sag
Le 17/03/2013 00:36, than...@debian.org a écrit :
Is splitting the vanilla upstream sources off planned? That would be
very helpful for distributions. Another helpful thing would be a clear
distinction between fixes/adjustment to the library and Sage glue,
because we need all the Sage glue, but w
Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif:
>
> Julien Puydt wrote:
> > The proposition isn't to fork sage to get it into a single distribution,
> > but to modify it with upstream so any distribution can easily package it
> > correctly.
>
> But if we switch to git, improve Sage's pa
Paulo Andrade has done a ton of work packaging Sage for Fedora (1), which
is currently available as an experimental yum repository (2)
(1): https://bugzilla.redhat.com/show_bug.cgi?id=877651
(2): http://pcpa.fedorapeople.org/sagemath/sagemath-f18.repo
I'm definitely in favor of this, pushing Sag
Julien Puydt wrote:
Le 16/03/2013 18:36, leif a écrit :
Julien Puydt wrote:
Le 16/03/2013 16:57, Tobias Hansen a écrit :
== Desirable skills: ==
familiarity with shell scripts, makefiles and C libraries
You forgot python.
Autotools, C++, Common Lisp / ECL, Cython, Perl, ... ? ;-)
Do they
Le 16/03/2013 18:36, leif a écrit :
Julien Puydt wrote:
Le 16/03/2013 16:57, Tobias Hansen a écrit :
== Desirable skills: ==
familiarity with shell scripts, makefiles and C libraries
You forgot python.
Autotools, C++, Common Lisp / ECL, Cython, Perl, ... ? ;-)
Do they know about Sage-on-Ge
Julien Puydt wrote:
Le 16/03/2013 16:57, Tobias Hansen a écrit :
== Desirable skills: ==
familiarity with shell scripts, makefiles and C libraries
You forgot python.
Autotools, C++, Common Lisp / ECL, Cython, Perl, ... ? ;-)
Do they know about Sage-on-Gentoo, Jan's Ubuntu PPA, ... ?
-lei
Le 16/03/2013 16:57, Tobias Hansen a écrit :
== Desirable skills: ==
familiarity with shell scripts, makefiles and C libraries
You forgot python.
Snark on #debian-science and #sagemath
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubsc
37 matches
Mail list logo
