Hi,
The python's spkg-install package contains the following "-i" switch
in "make install":
# the "-i" is crucial, esp. in the case of a major upgrade
make -i install
Does anyone know why this is crucial? It seems to me that it ignores
(silences) real errors, and it bit me today (when it did si
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 6:45 AM, David Kirkby wrote:
> On 7 May 2011 10:59, Jeroen Demeyer wrote:
>> On 2011-05-06 19:53, Robert Bradshaw wrote:
>>> Even better would be to checksum the source in a src.md5 file, and
>>> have sage -spgk warn/error if the checksums don't match.
>> I think it is nece
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 05/ 7/11 03:01 PM, Volker Braun wrote:
On Saturday, May 7, 2011 2:45:26 PM UTC+1, Dr David Kirkby wrote:
drkirkby@laptop:~/sage-4.7.rc0/spkg/standard/singular-3-1-1-4.p8$ find
src -exec cksum {} \; | awk '{print $1}' | cksum | awk '{print $1}'
3766045910
You also want to sort somewhere be
> conditional dependency it used to be that way but I don't see a
> > reason to change it.
>
> Here is the log:
>
> http://sage.math.washington.edu/home/burcin/gf2x-0.9.5:20110507-133059.log
>
Access forbidden for that one.
> All the logs from that build are here:
> On Sat, 07 May 2011 21:15:11 +1200
>
>
> I just pushed some more changes to bitbucket. The latest version builds
> on a 32-bit debian squeeze machine. I will also try it on other linux
> variants I find.
>
> http://sage.math.washington.edu/home/burcin/sage-prefix-20110
On Saturday, May 7, 2011 3:57:02 PM UTC+1, Burcin Erocal wrote:
>
> > Since there is already the standard CFLAGS variable I didn't
> > implement an extra WRAPPER_CFLAGS.
>
> I want the compiler wrapper to handle building programs within the
> prefix without the user having to keep track of the pref
On Sat, 7 May 2011 06:42:10 -0700 (PDT)
Volker Braun wrote:
> On Saturday, May 7, 2011 2:29:27 PM UTC+1, Burcin Erocal wrote:
> >
> > This tarball should also solve Volker's problem where ntl couldn't
> > find gf2x. I realized that I completely misunderstood what exactly
> > the compilerwrapper d
On Sat, 7 May 2011 07:30:52 -0700 (PDT)
Volker Braun wrote:
> You shouldn't need autotools to build anything, only the
> autogenerated scripts that are in the source tarball. But it seems
> like some patches are re-running autoconf. On my Fedora 14 install it
> breaks early on:
Unfortunately ge
On 5/6/11 4:21 PM, Ondrej Certik wrote:
Oh, and then people can simply send pull requests to the respective
packages directly. So I think it solves lots of the problems raised in
this thread. For sage, it would have to move to github though, so it
might not be an option.
Bitbucket has pull req
>>> Unpacking source...
>>> Unpacking eselect-python-20100321.tar.bz2 to
/home/vbraun/opt/sage-prefix-20110507/dist/tmp/portage/app-admin/eselect-python-20100321/work
* Applying eselect-python-20100321-prefix.patch ...
[ ok ]
o be that way but I don't see a
> reason to change it.
Here is the log:
http://sage.math.washington.edu/home/burcin/gf2x-0.9.5:20110507-133059.log
All the logs from that build are here:
http://sage.math.washington.edu/home/burcin/gf2x_sse2_logs.tar.bz2
This should be reproducible by j
On Saturday, May 7, 2011 2:45:26 PM UTC+1, Dr David Kirkby wrote:
>
> drkirkby@laptop:~/sage-4.7.rc0/spkg/standard/singular-3-1-1-4.p8$ find
> src -exec cksum {} \; | awk '{print $1}' | cksum | awk '{print $1}'
> 3766045910
>
You also want to sort somewhere because find doesn't return the matches
On 7 May 2011 10:59, Jeroen Demeyer wrote:
> On 2011-05-06 19:53, Robert Bradshaw wrote:
>> Even better would be to checksum the source in a src.md5 file, and
>> have sage -spgk warn/error if the checksums don't match.
> I think it is necessary and sufficient to checksum the output of "ls -lR".
I
On Saturday, May 7, 2011 2:29:27 PM UTC+1, Burcin Erocal wrote:
>
> This tarball should also solve Volker's problem where ntl couldn't find
> gf2x. I realized that I completely misunderstood what exactly the
> compilerwrapper does. After all it was necessary to add the include and
> library paths t
etween mpir and gmp. I am not sure how complete this is yet.
> I'll have to test from the mac :)
I just pushed some more changes to bitbucket. The latest version builds
on a 32-bit debian squeeze machine. I will also try it on other linux
variants I find.
http://sage.math.washington.edu
On 2011-05-06 19:53, Robert Bradshaw wrote:
> Even better would be to checksum the source in a src.md5 file, and
> have sage -spgk warn/error if the checksums don't match.
I think it is necessary and sufficient to checksum the output of "ls -lR".
--
To post to this group, send an email to sage-de
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)
> Hi Francois,
>
> On Thu, 05 May 2011 00:33:57 +1200
>
> Francois Bissey wrote:
> > > > Well done so far. We need a repo. While we are putting this
> > > > together I'd like it if you added the following to etc/make.conf:
> > > > PORT_LOGDIR="${SBASE}"/var/log/portage
> > > > PORTAGE_ELOG_CLASS
20 matches
Mail list logo
