This seems to work. Thanks!
On Aug 23, 10:17 am, Ryan Hinton <iob...@email.com> wrote:
> You're right, the symbolic link had been dereferenced, so devel/sage
> and devel/sage-main were both normal directories. In my sandbox, it
> worked to remove devel/sage and recreate it as a link to sage-main.
> We'll try it on the real install soon.
>
> Thanks!
>
> - Ryan
>
> On Aug 21, 2:34 am, Mitesh Patel <qed...@gmail.com> wrote:
>
> > On 08/21/2010 02:12 AM, Jason Grout wrote:
>
> > > On 8/20/10 2:44 PM, Ryan Hinton wrote:
> > >> I have a build of Sage at school that I occasionally update when a bug
> > >> or upgrade affects me. I'm the only one who uses it, but it's
> > >> installed in a public location (i.e. not writable by me) in case
> > >> someone else *might* use it. And because I don't have enough disk
> > >> space in my personal quota. :-)
>
> > >> So I went through the motions again: download, build, test, notify the
> > >> sysadmin that a new build is ready to be copied over. But this time
> > >> we're having trouble with Sage fixing the install paths. There are
> > >> multiple levels of symbolic links in the path, and some components
> > >> (e.g. Zope) are picking up the absolute path (w/o symlinks), while
> > >> others are picking up the cd'ed path where "./sage" is being run (w/
> > >> symlinks). The symptom is that we get
>
> > >> /share/apps/contrib/sage-4.5.2/local/lib/python2.6/site-packages/sage/
> > >> misc/misc.py in branch_current_hg()
> > >> 1877 i = s.rfind('->')
> > >> 1878 if i == -1:
> > >> -> 1879 raise RuntimeError, "unable to determine branch?!"
> > >> 1880 s = s[i+2:]
> > >> 1881 i = s.find('-')
>
> > >> RuntimeError: unable to determine branch?!
> > >> Error importing ipy_profile_sage - perhaps you should run %upgrade?
> > >> WARNING: Loading of ipy_profile_sage failed.
>
> > >> while Sage is trying to fix the paths (next output after the "Do not
> > >> interrupt this" message).
> > >> Any suggestions?
>
> > Could you tell us the result of
>
> > cd SAGE_ROOT
> > ls -l devel/
>
> > ? For example, I get
>
> > total 8
> > drwxr-xr-x 2 mpatel mpatel 4096 2010-08-14 19:31 old
> > lrwxrwxrwx 1 mpatel mpatel 9 2010-08-14 19:33 sage -> sage-main
> > drwxr-xr-x 7 mpatel mpatel 4096 2010-08-19 18:25 sage-main
>
> > The branch_current_hg function looks for the symbolic link, which may be
> > missing because sage is an actual directory.
>
> > Perhaps the copy command didn't preserve symlinks? What happens if you use
>
> > cp -dR OLD_SAGE_ROOT NEW_SAGE_ROOT
>
> > ? The '-d' flag tells cp not to dereference links in the source and to
> > preserve them in the destination.
>
> > On 08/21/2010 02:12 AM, Jason Grout wrote:
>
> > > This probably does not directly address your problem, but after looking
> > > at the code in sage-location (which is the code that fixes paths when
> > > Sage is moved), and looking at the things that are not fixed (e.g., in
> > > $SAGE_ROOT/local/lib/pkgconfig), I decided that I wouldn't compile and
> > > then move Sage any more. A patch for the problems I found in pkgconfig
> > > is up at
>
> > >http://trac.sagemath.org/sage_trac/ticket/9210
>
> > > which involves a pretty substantial restructuring of sage-location. I
> > > think the patch is still ready for review. I don't know if it will fix
> > > your problem.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
