On 06/28/10 06:12 AM, John H Palmieri wrote:
On Jun 27, 9:56 pm, Nils Bruin wrote:
On Jun 27, 7:41 pm, John H Palmieri wrote:
But there is now also a directory spkg/logs/ in which the output for
each package gets written into a separate file. So you can use those
for troubleshooting.
That
On 06/28/10 05:30 AM, William Stein wrote:
It makes absolutely no sense to run a "make check" for pynac, since
pynac can't do anything without the Sage library already built. The
only conceivable test suite for pynac is the Sage library's test
suite.
-- William
OK. I just added it, but I c
On Jun 27, 9:56 pm, Nils Bruin wrote:
> On Jun 27, 7:41 pm, John H Palmieri wrote:
>
> > But there is now also a directory spkg/logs/ in which the output for
> > each package gets written into a separate file. So you can use those
> > for troubleshooting.
>
> That is not present (does that get c
On Sun, Jun 27, 2010 at 9:55 PM, John Cremona wrote:
> On 27 June 2010 18:17, Minh Nguyen wrote:
>> Hi David,
>>
>> On Mon, Jun 28, 2010 at 10:43 AM, Dr. David Kirkby
>> wrote:
>>
>>
>>
>>> Do you know of any project where it is difficult to report a bug upstream
>>> because the upstream develo
On Jun 27, 7:41 pm, John H Palmieri wrote:
> But there is now also a directory spkg/logs/ in which the output for
> each package gets written into a separate file. So you can use those
> for troubleshooting.
That is not present (does that get cleaned up by make clean?) so
perhaps I didn't do eve
On 27 June 2010 18:17, Minh Nguyen wrote:
> Hi David,
>
> On Mon, Jun 28, 2010 at 10:43 AM, Dr. David Kirkby
> wrote:
>
>
>
>> Do you know of any project where it is difficult to report a bug upstream
>> because the upstream developers are regularly unhelpful?
>
> Not that I know of. But Pari/GP
On Sun, Jun 27, 2010 at 9:02 PM, Dr. David Kirkby
wrote:
> I've just created an spkg-check file for pynac, so it runs the test suite.
> But if it does check anything, it is not exactly making it clear what it is
> checking. I'm left wondering what, if anything is tested. Whatever is tested
> takes
On Sun, Jun 27, 2010 at 12:57 PM, Dr. David Kirkby
wrote:
> At the moment, once a package 'foobar.x.y.z' gets installed, a file
>
> spkg/installed/foobar.x.y.z
>
> gets created.
>
> I personally think it would be sensible if there was another directory
>
> spkg/tested
>
> which gets a file
>
> spk
I've just created an spkg-check file for pynac, so it runs the test suite. But
if it does check anything, it is not exactly making it clear what it is
checking. I'm left wondering what, if anything is tested. Whatever is tested
takes next to no time to test, so it does not look like its a very e
On 06/28/10 03:41 AM, John H Palmieri wrote:
On Jun 27, 6:33 pm, "Dr. David Kirkby"
wrote:
There's too little information above for me to see what went wrong. It should be
noted that the output of commands will be mixed too, as different packages are
all being built at the same time.
But ther
On Jun 27, 6:33 pm, "Dr. David Kirkby"
wrote:
> There's too little information above for me to see what went wrong. It should
> be
> noted that the output of commands will be mixed too, as different packages are
> all being built at the same time.
But there is now also a directory spkg/logs/ in
On 06/28/10 01:19 AM, Nils Bruin wrote:
I tried building sage 4.4.4 with
export SAGE_PARALLEL_SPKG_BUILD="yes"
export MAKE="make -j4"
make
but got:
"""
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating sys
Hi David,
On Mon, Jun 28, 2010 at 10:43 AM, Dr. David Kirkby
wrote:
> Do you know of any project where it is difficult to report a bug upstream
> because the upstream developers are regularly unhelpful?
Not that I know of. But Pari/GP comes a bit close. The last time I
tried to email its list
On 06/27/10 09:19 PM, Peter Jeremy wrote:
On 2010-Jun-24 13:54:24 +0100, "Dr. David Kirkby"
wrote:
Here's a suggestion, which I think could be useful.
If a reviewer sees that a bug on trac is an upstream bug, that they are required
to see evidence that this has been reported upstream before t
I tried building sage 4.4.4 with
export SAGE_PARALLEL_SPKG_BUILD="yes"
export MAKE="make -j4"
make
but got:
"""
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
>
> I would have thought using platform.system() or os.uname to decide what set
> of commands to run, then just run some half a dozen useful command on each
> platform, making sure they do not require root access, and do not require
> things installed which people may not have.
>
>
Yes, exactly. Fo
On 06/27/10 10:58 PM, Jason B. Hill wrote:
Thanks!
Do you think there is an advantage to using lsb_release over the 'platform'
Python module in sage/local/lib/python? My idea here is to limit execution
to within Sage (I'm assuming that this platform module can be imported in
any Sage, compiled /
Thanks!
Do you think there is an advantage to using lsb_release over the 'platform'
Python module in sage/local/lib/python? My idea here is to limit execution
to within Sage (I'm assuming that this platform module can be imported in
any Sage, compiled / binary, so let me know if that is incorrect)
I am forwarding your request to sage-devel, since I'm not sure who to suggest.
-- Forwarded message --
From: André-Patrick Bubel
Date: Sat, Jun 26, 2010 at 7:42 PM
Subject: Re: trac tickets needing review
To: Robert Miller
Hi, I don't know anyone from the development team. Do
On Sun, Jun 27, 2010 at 1:05 PM, Dr. David Kirkby
wrote:
> On 06/27/10 08:55 PM, Robert Miller wrote:
>>
>> Feel free to put me in charge of the memleak component.
>
> Done.
>
> As a matter of interest, what techniques are you using for memory leak
> testing? I assume valgrind is one, but are ther
> Matplotlib is used as part of the Sage project, where we aim to run
> test-suites that are part of upstream packages where possible. Someone
> suggested it would be good if we did that for Matplotlib, which we
> currently do not do. However, on reading the contents of the source
> directory (READ
On 2010-Jun-24 13:54:24 +0100, "Dr. David Kirkby"
wrote:
>Here's a suggestion, which I think could be useful.
>
>If a reviewer sees that a bug on trac is an upstream bug, that they are
>required
>to see evidence that this has been reported upstream before the fix gets a
>positive review.
>
>He
On 06/27/10 07:20 PM, Nathann Cohen wrote:
I *think* the main point of them is that if a trac ticket gets created with that
as a component, the owner gets an email about the trac ticket. So they are aware
of it.
If I can interrupt, I think this actually does not work in my
situation... I have s
On 06/27/10 08:55 PM, Robert Miller wrote:
But for several there the owner is "tbd" which I assume means "to be
determined" and so there is no real owner. The following have no owner
cygwin, debian-package, distribution, dsage, experimental package,
factorization, memleak, msvc, packages, perf
On 06/27/10 06:42 PM, Minh Nguyen wrote:
Hi David,
On Mon, Jun 28, 2010 at 3:34 AM, Dr. David Kirkby
wrote:
I don't know how one adds an owner to a trac ticket. Whilst I have admin
rights on the server, it is not immediately obvious to me how one takes an
existing component and adds an add
At the moment, once a package 'foobar.x.y.z' gets installed, a file
spkg/installed/foobar.x.y.z
gets created.
I personally think it would be sensible if there was another directory
spkg/tested
which gets a file
spkg/tested/foobar.x.y.z
added when foobar.x.y.z has been successfully tested wi
> But for several there the owner is "tbd" which I assume means "to be
> determined" and so there is no real owner. The following have no owner
>
>
>
> cygwin, debian-package, distribution, dsage, experimental package,
> factorization, memleak, msvc, packages, performance, relocation and
> spkg-che
If you have not seen it, it is now possible to build Sage packages in parallel.
See http://trac.sagemath.org/sage_trac/ticket/8306
This is in my mind one of the most impressive improvements I've ever seen to aid
building Sage.
On my Sun Ultra 27, running OpenSolaris, I can build 52 packages i
> I *think* the main point of them is that if a trac ticket gets created with
> that
> as a component, the owner gets an email about the trac ticket. So they are
> aware
> of it.
If I can interrupt, I think this actually does not work in my
situation... I have seen new tickets created in Graph t
Hi David,
On Mon, Jun 28, 2010 at 3:34 AM, Dr. David Kirkby
wrote:
> I don't know how one adds an owner to a trac ticket. Whilst I have admin
> rights on the server, it is not immediately obvious to me how one takes an
> existing component and adds an additional owner. So I'm not going to add
On Sunday, June 27, 2010, John H Palmieri wrote:
> At ticket #8263, we're trying to document the environment variables
> used by Sage.
>
> SAGE_FAT_BINARY: In SAGE_ROOT/README.txt, it says
>
> Fat Binaries: To make a binary that will run on the widest range of
> target machines, set the SAGE
There are several components of the Sage trac server which have more than one
owner
For graph theory there are 4 owners - jason, mvngu, ncohen, rlm
But for several there the owner is "tbd" which I assume means "to be determined"
and so there is no real owner. The following have no owner
cy
At ticket #8263, we're trying to document the environment variables
used by Sage.
SAGE_FAT_BINARY: In SAGE_ROOT/README.txt, it says
Fat Binaries: To make a binary that will run on the widest range of
target machines, set the SAGE_FAT_BINARY environment variable to
"yes" before building S
On some 64-bit platforms, which include, but is not limited to:
* Some version of OS X (I don't know what versions or processors)
* Solaris on SPARC processors.
* Solaris on x86 processors.
* OpenSolaris on SPARC processors.
* OpenSolaris on x86 processors.
* HP-UX on PA-RISC processors.
t
Matplotlib is used as part of the Sage project, where we aim to run test-suites
that are part of upstream packages where possible. Someone suggested it would be
good if we did that for Matplotlib, which we currently do not do. However, on
reading the contents of the source directory (README.txt,
On 06/26/10 11:36 PM, Jason Grout wrote:
On 6/21/10 3:18 PM, Dr. David Kirkby wrote:
On 06/21/10 10:09 PM, Robert Bradshaw wrote:
On Jun 21, 2010, at 2:03 PM, Dr. David Kirkby wrote:
It seem strange we are only checking about 20% of the packages, even
if SAGE_CHECK is yes.
MPIR, MPFR an
The hard-coded directory currently breaks "sage --upgrade" if the
install directory has been moved. It fails on opencdk-0.6.6.p4 .
--walter
On Jun 11, 8:09 am, leif wrote:
> On 11 Jun., 08:43, Jason Grout wrote:
>
>
>
> > > On 06/10/2010 04:49 PM, Jason Grout wrote:
> > >> There seem to be a lo
Yes, the output is;
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --
with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/
share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-
languages=c,c++,objc,fortran,ja
Hi!
I have a $152 credit at Vistaprint due to the t-shirt order we half
canceled last year because they arrived too late at the Sage-Combinat
meeting at FPSAC 2009. The credit will expire on the 27th of July.
So, if anyone wants a T-Shirt from last year, I can easily get a
couple more pri
On Jun 27, 2010, at 1:40 AM, caleb miles wrote:
Hello,
I am attempting to compile SAGE 4.4.4 on an OpenSUSE cluster for
local use, however, the build process fails while installing Cython,
and I have attached the portion of install.log corresponding to the
build process.
Thanks. The key
40 matches
Mail list logo
