How to deal with packages with multiple versions?
Let's say gcc.
With the old system we just had to offer multiple spkgs.
Should we now do something like gcc-4.6, gcc-4.7 and so on and a symlink
from gcc to the default version?
--
You received this message because you are subscribed to the
could be able to provide a Cygwin64/Windows 7 fat build.
Once again, ATLAS is the most problematic part.
On Tuesday, December 31, 2013 1:33:12 PM UTC+1, Harald Schilly wrote:
cool! I'm mirroring them right now.
Harald
On Tue, Dec 31, 2013 at 1:18 PM, Jean-Pierre Flori
jpf
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
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
changes?
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 when I
On Monday, March 17, 2014 3:35:17 PM UTC+1, kcrisman wrote:
On OS X 10.4 PPC, I get the following error. Incidentally, I'm used to
GAP compiling toward the very end of the process on this machine, so I was
surprised it showed up relatively early. I'd be grateful for any hints;
looks
On Monday, March 17, 2014 3:46:54 PM UTC+1, kcrisman wrote:
Also, a few questions.
1) We used to be able to just fake an installation by touching a
certain file. I assume that touching the log file in logs/pkgs would not
suffice here, though?
Thanks for those pointers! So...
On Thursday, March 20, 2014 7:54:35 PM UTC+1, kcrisman wrote:
OS X 10.4 continues... Here is my next build error, this time in linking
mwrank in the Sage library. Apparently something wasn't completely
compiled in the libflint build? In particular, there is apparently only a
libflint.a
Was it built in parallel?
On Thursday, March 20, 2014 9:26:25 PM UTC+1, François wrote:
They are. I just checked on my 10.9.2 machine and I don't have them. That,
to
me, suggests a variable in the makefile is not defined and -include is
taken
as a target which doesn't bod well.
On Thursday, March 20, 2014 9:44:57 PM UTC+1, François wrote:
I think I am starting to get some ideas. The missing includes are an
essential
key to understand the problem. We may need the result of the configuration
phase on that machine. The includes statements are present in the
kcrisman wrote:
On Thursday, March 20, 2014 5:11:23 PM UTC-4, Jean-Pierre Flori wrote:
On Thursday, March 20, 2014 9:44:57 PM UTC+1, François wrote:
I think I am starting to get some ideas. The missing includes are an
essential
key to understand the problem. We may need the result
On Friday, March 21, 2014 4:23:49 PM UTC+1, kcrisman wrote:
I'm going to have a stream-of-consciousness thing here.
At first sight the Makefile does not look that bad.
(And Makefile.subdirs is not touched, so yours is the same as every
other's one.)
Nonetheless this is the problem, I
On Thursday, April 17, 2014 12:54:32 PM UTC+2, John Cremona wrote:
This is a different problem to the one I reported on the other
sage-release thread. On my laptop (ubuntu 12.04) I had a working
build of a previous beta, I think beta6. I pulled from trac/develop
and ran a make. Here's
On Monday, May 26, 2014 3:39:33 PM UTC+2, Nathann Cohen wrote:
Whether we should make it the default in the top-level Makefile has been
discussed a couple of times in the past years, and IIRC most agreed we
should do so, but so far even 'sudo open a ticket' failed.
I really do not
On Monday, May 26, 2014 4:14:56 PM UTC+2, Nathann Cohen wrote:
Open a ticket and someone might feel less lazy :)
I don't believe in opening tickets without writing the patch and
setting them to needs_review :-P
Set them to blocker.
That will get the release manager attention.
--
You
(which can be read off from the name).
On Monday, May 26, 2014 3:23:32 PM UTC+1, Jean-Pierre Flori wrote:
On Monday, May 26, 2014 4:14:56 PM UTC+2, Nathann Cohen wrote:
Open a ticket and someone might feel less lazy :)
I don't believe in opening tickets without writing the patch
It seems that the tarball for the devel sources is very outdated on mirrors
(at least the french and chinese ones).
--
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, send an email
It's the only simple way from my point of view when you want to build on a
machine without internet access.
Much easier that copying a non-built git install with a full upstream
directory.
On top of that, make download pulls huge tarballs (including some of John
database if IIRC :) ).
On
On Monday, October 27, 2014 9:52:13 PM UTC+1, strogdon wrote:
I have these doctest failures (fresh build of vanilla 6.4.beta6 from the
git repo) that appear to be precision related:
I get similar erros on a ppc64 machine.
--
You received this message because you are subscribed to the
On Tuesday, November 4, 2014 2:16:43 PM UTC+1, John Cremona wrote:
It's a long time since I have done a make ptestlong and not had
several test failures. I have done make distclean first and have
pulled the latest develop branch (commit
8b95db32005c62e289d6698e8233218d5fda0f60) but see
On Tuesday, November 4, 2014 9:58:54 PM UTC+1, Thierry wrote:
Hi,
all those numerical noise appearing suddenly, couldn't that mean that
some numerical algorithm became less stable/accurate somewhere in the
code ?
I think its the way we treat tolerance which changed, so no real
I'll check this.
Thanks for the report.
On Saturday, November 15, 2014 5:32:22 PM UTC+1, Thierry wrote:
Hi,
On Fri, Nov 14, 2014 at 06:35:03AM -0800, Volker Braun wrote:
Both the develop and master git branch have been updated to Sage 6.4!
tarball:
Maybe GCC got stupid.
It seems you are now using 4.9.2, so that might be the difference.
Can you post the config.log with #15316 merged?
--
You received this message because you are subscribed to the Google Groups
sage-release group.
To unsubscribe from this group and stop receiving emails
On Friday, December 5, 2014 12:35:24 PM UTC+1, Johan S. R. Nielsen wrote:
I seem to have solved it: compilation halted when it wasn't able to find
the ATLAS header files. So I extracted the header files from
upstream/atlas-3.10.0.tar.bz2/ATLAS/include to some folder and set the
:28 PM UTC+1, François wrote:
Note that for OS X where the headers are missing I copied headers in the
source.
IML is the only package I can think of requiring cblas.h we could just
always copy
the header I don’t know how it would hurt.
François
On 6/12/2014, at 00:55, Jean-Pierre
On Friday, December 5, 2014 5:23:27 PM UTC+1, Jean-Pierre Flori wrote:
In fact there has been some failure from me when upstream updated IML.
I somehow failed to leave the netlib cblas.h (which should get picked up
if nothing else is found) in the tarball :(
In the README there is : * add
On Friday, December 5, 2014 6:38:37 PM UTC+1, Johan S. R. Nielsen wrote:
On Friday, December 5, 2014 6:23:56 PM UTC+1, Jean-Pierre Flori wrote:
François and Johan, could you try the tarball at:
http://boxen.math.washington.edu/home/jpflori/iml-1.0.4/iml-1.0.4.tar.bz2
which includes
On Friday, December 5, 2014 7:44:33 PM UTC+1, Jean-Pierre Flori wrote:
On Friday, December 5, 2014 7:06:48 PM UTC+1, Johan S. R. Nielsen wrote:
As long as the forced rebuild with the new tarball works there is nothing
to worry about.
Note that I meant run from $SAGE_ROOT the sage
On Friday, December 5, 2014 7:23:52 PM UTC+1, Volker Braun wrote:
We need a different tarball name or our caching will break. If upstream
doesn't rename it then you have to.
Ok, I'll suggest to add p1 to the version number.
And if needed will do it for Sage only.
--
You received this
Note that files only show the last commit that modigfied them.
On Wednesday, December 10, 2014 3:59:22 PM UTC+1, kcrisman wrote:
Just a question about this site. It has everything we need, apparently...
but the 'tree' and 'log' views don't seem to be on the current master. For
instance,
Did we loose the French mirror?
It's not uptodate nor listed on
http://www.sagemath.org/download-source.html anymore.
--
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, send an email
On Friday, April 17, 2015 at 12:25:58 AM UTC+2, Thierry wrote:
Hi,
my desktop is finishing to build binaries for all supported Debian and
Ubuntu versions in both 32 and 64 bits, you can get them here:
https://lipn.univ-paris13.fr/~monteil/hebergement/sage/binaries/6.6/
Great!
Thanks
On ppc64 running Linux I get a bunch of very bad looking errors
{{{
*** glibc detected *** python: malloc(): memory corruption:
0x010020662b90 ***
}}}
E.g. in src/sage/schemes/hyperelliptic_curves/hyperelliptic_generic.py
Apparently this involves Singular and Groebner Basis Strategy class.
When running on a ppc64 machine, I get:
sage -t --warn-long 97.8 src/sage/graphs/distances_all_pairs.pyx
**
File src/sage/graphs/distances_all_pairs.pyx, line 1205, in
sage.graphs.distances_all_pairs.diameter
Failed example:
Le lundi 6 juillet 2015 14:07:50 UTC+2, Jean-Pierre Flori a écrit :
Le lundi 6 juillet 2015 13:37:13 UTC+2, François a écrit :
On power7 I get 2 doctest failures:
frb15@p2n14-c /hpc/scratch/frb15/sandbox/sage-6.8.beta7 :./sage -t --long
--warn-long 95.7 src/sage/symbolic/expression.pyx
Or the code is buggy as well :)
I guess that s and d are returned but they are uninitialized and actually
contain memory addresses which are about 45 bits.
--
You received this message because you are subscribed to the Google Groups
sage-release group.
To unsubscribe from this group and stop
Le lundi 6 juillet 2015 14:56:14 UTC+2, Jean-Pierre Flori a écrit :
Or the code is buggy as well :)
I guess that s and d are returned but they are uninitialized and actually
contain memory addresses which are about 45 bits.
Fix for this one at http://trac.sagemath.org/ticket/18854
I vaguely remember having similar issues on gcc110 and another machine
where I use something like make -j64 or 80.
It fails first and then succeeds on second run.
And I remember something about ppl (or was it palp? similar letters...)
failing.
Maybe make is not robust enough?
Next time it
On Wednesday, August 17, 2016 at 4:43:49 PM UTC+2, leif wrote:
>
> leif wrote:
> > Jean-Pierre Flori wrote:
> >> On a POWER7 machine I get an error while building the docs I get a
> >> ZeroDivisionError in the plotting section.
> >> Did any
Starts ok on Mac OS 10.14.
Can compute the cardinality of an elliptic curve as well!
On Monday, October 15, 2018 at 12:43:40 AM UTC+2, Volker Braun wrote:
>
> I built OSX test binaries for 8.4.rc1, you can find them at the usual place
>
> http://files.sagemath.org/osx/intel/index.html
>
> These
40 matches
Mail list logo
