Re: [gentoo-science] sage-4.3.5-r1 && sage-core

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[Christopher Schwan]

Hi Steve,

thanks for reporting - I just pushed my latest changes which should fix the 
problem. Re-emerging sage-base should create the needed directories; sage-core 
contains your proposed patch.

Christopher

On Sunday 18 April 2010 07:32:05 Steven Trogdon wrote:
> Christopher,
> 
> The follow probably only applies to amd64. Sage will not install with the
> subject ebuilds. The
> "sage -c" during postinstall fails because the files
> 
> 	/opt/sage/local/lib/sage-flag.txt
> 	/opt/sage/local/lib/sage-current-location.txt
> 
> cannot be written since /opt/sage/local/lib doesn't exit. I suppose the
> files are needed. One can create the symlink lib -> lib64 if lib is needed
> or whatever. Even if this is fixed "sage -c" fails because the amd64-hack
> patch does't take. The spkg-install is bypassed with the sage-core ebuild.
> I tried a variety of things to get Sage to install and adding
> 
> 	append-flags -fno-strict-aliasing
> 
> to the sage-core ebuild works here. I'm not sure of the impact on ~x86 or
> ~pcc.
> 
> Steve

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[Steven Trogdon]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Christopher,

I've finally gotten around to trying the changes and a clean emerge of  
everything installs as it should. Here a revdep-rebuild reveals that  
libsingular.so can't be found. The proposed resolution is to re-emerge  
sage-core which, of course, doesn't resolve the issue. What's the procedure to  
update the ld cache when libraries like libsingular.so are not in the  
"standard" location? Should something be done in sage-singular that doesn't  
compromise things?

Steve

---
On 04/18/10 04:02:42, Christopher Schwan wrote:
> Hi Steve,
> 
> thanks for reporting - I just pushed my latest changes which should fix the
> problem. Re-emerging sage-base should create the needed directories;  
> sage-core
> contains your proposed patch.
> 
> Christopher
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[Christopher Schwan]

Hi Steve,

On Sunday 18 April 2010 21:10:17 Steven Trogdon wrote:
> Christopher,
> 
> I've finally gotten around to trying the changes and a clean emerge of
> everything installs as it should. Here a revdep-rebuild reveals that
> libsingular.so can't be found. The proposed resolution is to re-emerge
> sage-core which, of course, doesn't resolve the issue. What's the procedure
> to update the ld cache when libraries like libsingular.so are not in the
> "standard" location? Should something be done in sage-singular that
> doesn't compromise things?

I noticed the same behavior and looked at /etc/ld.so.cache which pointed to 
/etc/env.d/... - so the gentoo way of doing this would be to add a file which 
contains LDPATH="/opt/sage/local/lib". Though I did not test it, it should 
work and I will add this file tomorrow.

Cheers,

Christopher

> 
> Steve
> 
> ---
> 
> On 04/18/10 04:02:42, Christopher Schwan wrote:
> > Hi Steve,
> > 
> > thanks for reporting - I just pushed my latest changes which should fix
> > the problem. Re-emerging sage-base should create the needed directories;
> > sage-core
> > contains your proposed patch.
> > 
> > Christopher

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[François Bissey]

> Hi Steve,
> 
> On Sunday 18 April 2010 21:10:17 Steven Trogdon wrote:
> > Christopher,
> >
> > 
> >
> > I've finally gotten around to trying the changes and a clean emerge of
> > everything installs as it should. Here a revdep-rebuild reveals that
> > libsingular.so can't be found. The proposed resolution is to re-emerge
> > sage-core which, of course, doesn't resolve the issue. What's the
> > procedure to update the ld cache when libraries like libsingular.so are
> > not in the "standard" location? Should something be done in
> > sage-singular that doesn't compromise things?
> 
> I noticed the same behavior and looked at /etc/ld.so.cache which pointed
> to  /etc/env.d/... - so the gentoo way of doing this would be to add a
> file which contains LDPATH="/opt/sage/local/lib". Though I did not test
> it, it should work and I will add this file tomorrow.
Hi guys,

I don't like that solution at all. What will happen if you have system wide
singular and sage-singular? 
If you add this file there is a good  chance that someone wanting to use the
system provided singular will end up using sage-singular.

Just for the purpose of testing for side effects, I installed singular-3.1.1.
revdep-rebuild didn't pick up on sage-core after that. Probably because
libsingular lacks an soname and is completely unversioned.

No. sage-env takes care of telling sage where to look. There is no real 
perfect solution so long as we have ship sage-singular. 
For now I would put a file in /etc/revdep-rebuild masking the offending
libraries.
50sage-core:
#Those files look for a version of libsingular that will be located through
# LD_LIBRARY_PATH at run-time.
LD_LIBRARY_MASK="lib1.so lib2.so lib3.so"

-----
Of course that means that revdep-rebuild cannot pick up the fact that
they are broken. Which of course it may not be able to do anyway because
of the lack of versioning.
On the positive side a change in sage-singular will always coincide with 
a change of sage-core so there shouldn't be any trouble.

Francois

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[Christopher Schwan]

On Monday 19 April 2010 05:18:21 François Bissey wrote:
> > Hi Steve,
> > 
> > On Sunday 18 April 2010 21:10:17 Steven Trogdon wrote:
> > > Christopher,
> > > 
> > > 
> > > 
> > > I've finally gotten around to trying the changes and a clean emerge of
> > > everything installs as it should. Here a revdep-rebuild reveals that
> > > libsingular.so can't be found. The proposed resolution is to re-emerge
> > > sage-core which, of course, doesn't resolve the issue. What's the
> > > procedure to update the ld cache when libraries like libsingular.so are
> > > not in the "standard" location? Should something be done in
> > > sage-singular that doesn't compromise things?
> > 
> > I noticed the same behavior and looked at /etc/ld.so.cache which pointed
> > to  /etc/env.d/... - so the gentoo way of doing this would be to add a
> > file which contains LDPATH="/opt/sage/local/lib". Though I did not test
> > it, it should work and I will add this file tomorrow.
> 
> Hi guys,
> 
> I don't like that solution at all. What will happen if you have system wide
> singular and sage-singular?
> If you add this file there is a good  chance that someone wanting to use
> the system provided singular will end up using sage-singular.

Yes, thats right! - I did not think of that.

> 
> Just for the purpose of testing for side effects, I installed
> singular-3.1.1. revdep-rebuild didn't pick up on sage-core after that.
> Probably because libsingular lacks an soname and is completely
> unversioned.
> 
> No. sage-env takes care of telling sage where to look. There is no real
> perfect solution so long as we have ship sage-singular.
> For now I would put a file in /etc/revdep-rebuild masking the offending
> libraries.
> 50sage-core:
> #Those files look for a version of libsingular that will be located through
> # LD_LIBRARY_PATH at run-time.
> LD_LIBRARY_MASK="lib1.so lib2.so lib3.so"

Another option (read: hack) would be to create a separate directory containing 
a symlink to libsingular.so (this is the only library which is reported by 
revdep-rebuild) and to point revdep-rebuild to this directory. Of course, this 
is not the best way of getting rid of this error.

In my opinion, the best "solution" would be to print out a warning/info after 
installing sage-core which basically says revdep-rebuild reports false 
positives and just wait for the Sage people upgrading to a new release of 
Singular (see http://trac.sagemath.org/sage_trac/ticket/8059 and 
http://trac.sagemath.org/sage_trac/ticket/8228).

> 
> -----
> Of course that means that revdep-rebuild cannot pick up the fact that
> they are broken. Which of course it may not be able to do anyway because
> of the lack of versioning.
> On the positive side a change in sage-singular will always coincide with
> a change of sage-core so there shouldn't be any trouble.
> 
> Francois

Christopher

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[François Bissey]

> In my opinion, the best "solution" would be to print out a warning/info
> after  installing sage-core which basically says revdep-rebuild reports
> false positives and just wait for the Sage people upgrading to a new
> release of Singular (see http://trac.sagemath.org/sage_trac/ticket/8059
> and
> http://trac.sagemath.org/sage_trac/ticket/8228).
Hi Christopher,

A warning is good but I would prefer to to put the libraries linking
to libsingular in quarantine for revdep-rebuild until that happens.
Otherwise revdep-rebuild will always want to rebuild sage-core again
and again. Furthermore:
1) we cannot count on users reading the warning.
2) during any genuine call to revdep-rebuild to catch other stuff
sage-core will be added and considering the time it takes it is
not nice.

Francois

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[François Bissey]

> > In my opinion, the best "solution" would be to print out a warning/info
> > after  installing sage-core which basically says revdep-rebuild reports
> > false positives and just wait for the Sage people upgrading to a new
> > release of Singular (see http://trac.sagemath.org/sage_trac/ticket/8059
> > and
> > http://trac.sagemath.org/sage_trac/ticket/8228).
> 
> Hi Christopher,
> 
> A warning is good but I would prefer to to put the libraries linking
> to libsingular in quarantine for revdep-rebuild until that happens.
> Otherwise revdep-rebuild will always want to rebuild sage-core again
> and again. Furthermore:
> 1) we cannot count on users reading the warning.
> 2) during any genuine call to revdep-rebuild to catch other stuff
> sage-core will be added and considering the time it takes it is
> not nice.
> 
I did go ahead and added a revdep-rebuild exception file.
The problem has completely disappeared now.

Francois

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[Christopher Schwan]

On Monday 19 April 2010 12:36:01 François Bissey wrote:
> > > In my opinion, the best "solution" would be to print out a warning/info
> > > after  installing sage-core which basically says revdep-rebuild reports
> > > false positives and just wait for the Sage people upgrading to a new
> > > release of Singular (see http://trac.sagemath.org/sage_trac/ticket/8059
> > > and
> > > http://trac.sagemath.org/sage_trac/ticket/8228).
> > 
> > Hi Christopher,
> > 
> > A warning is good but I would prefer to to put the libraries linking
> > to libsingular in quarantine for revdep-rebuild until that happens.
> > Otherwise revdep-rebuild will always want to rebuild sage-core again
> > and again. Furthermore:
> > 1) we cannot count on users reading the warning.
> > 2) during any genuine call to revdep-rebuild to catch other stuff
> > sage-core will be added and considering the time it takes it is
> > not nice.
> 
> I did go ahead and added a revdep-rebuild exception file.
> The problem has completely disappeared now.
> 
> Francois

Ok, fine !

Christopher

[gentoo-science] sage-4.3.5-r1 && sage-core

[Steven Trogdon]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Christopher,

The follow probably only applies to amd64. Sage will not install with the  
subject ebuilds. The
"sage -c" during postinstall fails because the files

	/opt/sage/local/lib/sage-flag.txt
	/opt/sage/local/lib/sage-current-location.txt

cannot be written since /opt/sage/local/lib doesn't exit. I suppose the files  
are needed. One can create the symlink lib -> lib64 if lib is needed or  
whatever. Even if this is fixed "sage -c" fails because the amd64-hack patch  
does't take. The spkg-install is bypassed with the sage-core ebuild. I tried a  
variety of things to get Sage to install and adding

	append-flags -fno-strict-aliasing

to the sage-core ebuild works here. I'm not sure of the impact on ~x86 or ~pcc.

Steve


	

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[François Bissey]

> Christopher,
> 
> The follow probably only applies to amd64. Sage will not install with the
> subject ebuilds. The
> "sage -c" during postinstall fails because the files
> 
> 	/opt/sage/local/lib/sage-flag.txt
> 	/opt/sage/local/lib/sage-current-location.txt
> 
> cannot be written since /opt/sage/local/lib doesn't exit. I suppose the
> files are needed. One can create the symlink lib -> lib64 if lib is needed
> or whatever. Even if this is fixed "sage -c" fails because the amd64-hack
> patch does't take. The spkg-install is bypassed with the sage-core ebuild.
> I tried a variety of things to get Sage to install and adding
> 
> 	append-flags -fno-strict-aliasing
> 
> to the sage-core ebuild works here. I'm not sure of the impact on ~x86 or
> ~pcc.
> 
Hi Steve,

thanks for the report. We need to patch the sage-location script. I would 
prefer to get rid of it actually but that may not be possible in the short 
term.
The problem is right there at the top of the script:
#!/usr/bin/env python

import os, sys

SAGE_ROOT     = os.environ['SAGE_ROOT']

location_file = '%s/local/lib/sage-current-location.txt'%SAGE_ROOT
flags_file    = '%s/local/lib/sage-flags.txt'%SAGE_ROOT

-----------------
We put things nicely into lib/lib64 now, so it is a problem.
We may have to grep all the sage scripts for other offenders.

I am not sure I can post a fix straight away:
sed -i "s:local/lib/sage:local/$(get_libdir)/sage:g" sage-location
in src_prepare should do the trick.

Francois 

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[François Bissey]

After looking more closely you want just local/lib to local/$(get_libdir)
in the previous sed command.
I haven't thought about the other problem yet.

Francois

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[François Bissey]

> I tried a variety of things to get Sage to install and adding
> 
> 	append-flags -fno-strict-aliasing
> 
> to the sage-core ebuild works here. I'm not sure of the impact on ~x86 or
> ~pcc.
OK third answer, I think this is fine I have that in my cflags both on x86 and 
ppc. There are a variety of programs out there that just don't take aliasing
seriously (or even now about it) so it is not a bad work-around. strict 
aliasing is usually triggered with various optimization.
So I think we will adopt it, at least on amd64 and probably ppc (although
I have a feeling most ppc gentooist already have it in their cflags as it is a
known offender in ppc-land).

Francois

Re: [gentoo-science] sage-4.3.5-r1 && sage-core

[Christopher Schwan]

Hi Steve,

thanks for reporting - I just pushed my latest changes which should fix the 
problem. Re-emerging sage-base should create the needed directories; sage-core 
contains your proposed patch.

Christopher

On Sunday 18 April 2010 07:32:05 Steven Trogdon wrote:
> Christopher,
> 
> The follow probably only applies to amd64. Sage will not install with the
> subject ebuilds. The
> "sage -c" during postinstall fails because the files
> 
> 	/opt/sage/local/lib/sage-flag.txt
> 	/opt/sage/local/lib/sage-current-location.txt
> 
> cannot be written since /opt/sage/local/lib doesn't exit. I suppose the
> files are needed. One can create the symlink lib -> lib64 if lib is needed
> or whatever. Even if this is fixed "sage -c" fails because the amd64-hack
> patch does't take. The spkg-install is bypassed with the sage-core ebuild.
> I tried a variety of things to get Sage to install and adding
> 
> 	append-flags -fno-strict-aliasing
> 
> to the sage-core ebuild works here. I'm not sure of the impact on ~x86 or
> ~pcc.
> 
> Steve