A different (Linux-only ?) approach to this problem might be to use unshare
(1) and private mounts.
See https://github.com/mwilliamson/whack
On Saturday, May 7, 2016 at 4:46:20 PM UTC+1, William wrote:
>
> On Sat, May 7, 2016 at 2:00 AM, Volker Braun > wrote:
> > The sage script in your PATH
This has been the default for a long time now, there is no need to add
it explicitly:
On 2016-05-09 00:17, Volker Braun wrote:
export SAGE_PARALLEL_SPKG_BUILD=yes
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this gr
On Sun, May 08, 2016 at 03:17:44PM -0700, Volker Braun wrote:
> The intended way to customize this is to create your own sage-debian.yaml
> where you modify the build instructions as you want them:
>
> build: |
> export SAGE_FAT_BINARY=yes
> export SAGE_PARALLEL_SPKG_BUILD=yes
> expor
On Sun, May 08, 2016 at 03:02:19PM -0700, William Stein wrote:
> On Sunday, May 8, 2016, Thierry wrote:
>
> > On Sun, May 08, 2016 at 02:53:58PM -0700, William Stein wrote:
> > > On Sunday, May 8, 2016, Thierry > > wrote:
> > >
> > > > Hi,
> > > >
> > > > i have to witness that for Sage Debian L
The intended way to customize this is to create your own sage-debian.yaml
where you modify the build instructions as you want them:
build: |
export SAGE_FAT_BINARY=yes
export SAGE_PARALLEL_SPKG_BUILD=yes
export MAKE='make -j{ncpu}'
make
git gc --aggressive --prune=now
Then "
On Sun, May 08, 2016 at 10:08:14PM +0200, Thierry wrote:
> On Sun, May 08, 2016 at 02:53:58PM -0700, William Stein wrote:
> > On Sunday, May 8, 2016, Thierry wrote:
> >
> > > Hi,
> > >
> > > i have to witness that for Sage Debian Live, i currently have to fork the
> > > behaviour of "sage -bdist"
On Sunday, May 8, 2016, Thierry wrote:
> On Sun, May 08, 2016 at 02:53:58PM -0700, William Stein wrote:
> > On Sunday, May 8, 2016, Thierry > wrote:
> >
> > > Hi,
> > >
> > > i have to witness that for Sage Debian Live, i currently have to fork
> the
> > > behaviour of "sage -bdist" to continue
On Sun, May 08, 2016 at 02:53:58PM -0700, William Stein wrote:
> On Sunday, May 8, 2016, Thierry wrote:
>
> > Hi,
> >
> > i have to witness that for Sage Debian Live, i currently have to fork the
> > behaviour of "sage -bdist" to continue maintain the live. Indeed, it is
>
>
> Where is your for
On Sunday, May 8, 2016, Thierry wrote:
> Hi,
>
> i have to witness that for Sage Debian Live, i currently have to fork the
> behaviour of "sage -bdist" to continue maintain the live. Indeed, it is
Where is your fork?
> still not clear to me how to use the new binary-pkg to package a
> custo
Hi,
i have to witness that for Sage Debian Live, i currently have to fork the
behaviour of "sage -bdist" to continue maintain the live. Indeed, it is
still not clear to me how to use the new binary-pkg to package a
customized sage install. To let the key be self-contained, i install most
optional
On Sunday, May 8, 2016, Volker Braun wrote:
> On Sunday, May 8, 2016 at 6:19:43 AM UTC+2, William wrote:
>>
>> which is 593M.
>>
>
> Sounds a bit too small, the buildbot binaries are always about twice that.
>
Ok that's good to know and explains why the binaries didn't work. I'll try
building
On Sunday, May 8, 2016 at 6:19:17 PM UTC+2, William wrote:
>
> > b) modifying a shared library in the destination /tmp/sage-dev/ has no
> > effect until you relink the binary/cython extension that uses it.
>
> Can you elaborate on b slightly? I don't understand for sure.
>
Say, you go to the
On Sun, May 8, 2016 at 1:34 AM, Volker Braun wrote:
> On Sunday, May 8, 2016 at 6:54:38 AM UTC+2, William wrote:
>>
>> time rsync -axH /projects/sage/sage-dev/ sage-dev/
>
>
> Thats fine. The only caveat is that rpaths are still pointing to the source.
> Therefore
> a) the copy stops working if y
On Sunday, May 8, 2016 at 6:54:38 AM UTC+2, William wrote:
>
> time rsync -axH /projects/sage/sage-dev/ sage-dev/
>
Thats fine. The only caveat is that rpaths are still pointing to the
source. Therefore
a) the copy stops working if you delete /projects/sage/sage-dev/
b) modifying a shared libra
On Sunday, May 8, 2016 at 6:19:43 AM UTC+2, William wrote:
>
> which is 593M.
>
Sounds a bit too small, the buildbot binaries are always about twice that.
instantly prints out massive screenfulls of information -- with no
> warning, and no indicator that hitting control+c is a bad idea.
Wait,
On Sat, May 7, 2016 at 12:18 PM, Volker Braun wrote:
> You can set it yourself in the environment after moving Sage, this may work
> with the aforementioned caveats about conflicts with system libraries. And
> change SAGE_LOCAL/lib/sage-current-location.txt to avoid the relocation
> error message.
Hi,
I just tested this package for creating binaries. It creates by default a file
sage-7.2.rc1-Ubuntu_15.10-x86_64.tar.bz2
which is 593M.
Doing
time tar jxf sage-7.2.rc1-Ubuntu_15.10-x86_64.tar.bz2
takes just under 2 minutes (for me) and results in a directory
SageMath, rather than sag
On Saturday, May 7, 2016 at 8:51:40 PM UTC+2, William wrote:
>
> My use case is building Sage on SageMathCloud (Ubuntu 15.10 right now)
> for people to develop on SageMathCloud (on the exact same machine).
Then just put sage in the same path for everyone (with a private union
mount), thats real
On Sat, May 7, 2016 at 11:32 AM, Volker Braun wrote:
> On Saturday, May 7, 2016 at 5:46:20 PM UTC+2, William wrote:
>>
>> I read that github page, but I don't know what binary-pkg actually
>> does.
>
>
> It compiles Sage in a long directory path.
>
>>
>> For context, I used to (1) build a copy of
On Saturday, May 7, 2016 at 5:46:20 PM UTC+2, William wrote:
>
> I read that github page, but I don't know what binary-pkg actually
> does.
It compiles Sage in a long directory path.
> For context, I used to (1) build a copy of Sage, (2) possibly
> customize it, then (3) type
>
> ./sage
On Sat, May 7, 2016 at 9:02 AM, Dima Pasechnik wrote:
> Yes, I know, I was puzzled by this some time ago too. The reason for all
> this mess is that in order to make
> a relocatable Sage binary (more precisely, a bunch of relocateable libs etc)
> that uses rpath, it has to be built at a location t
Yes, I know, I was puzzled by this some time ago too. The reason for all
this mess is that in order to make
a relocatable Sage binary (more precisely, a bunch of relocateable libs
etc) that uses rpath, it has to be built at a location that will allow
pattern-matching on binaries to work (so it h
22 matches
Mail list logo
