On Tue, Mar 6, 2018 at 5:20 PM, Ralf Stephan wrote:
> Very good. Doesn't it only work if the user not only has the library but
> also the respective headers, i.e., the corresponding xyz-devel package
> installed?
Depends on the package, but if one package is a build dependency of
another package
Very good. Doesn't it only work if the user not only has the library but
also the respective headers, i.e., the corresponding xyz-devel package
installed?
On Tuesday, March 6, 2018 at 4:54:12 PM UTC+1, Erik Bray wrote:
>
> On Mon, Mar 5, 2018 at 12:02 PM, Dima Pasechnik > wrote:
> >
> >
> >
On Mon, Mar 5, 2018 at 12:02 PM, Dima Pasechnik wrote:
>
>
> On Monday, March 5, 2018 at 9:48:25 AM UTC, Ralf Stephan wrote:
>>
>> I'm interested in a fix because it prevents clean patchbot results on
>> OpenSuSE
>
>
> Erik has an implementation of such feature generically, on some recent open
> t
On Monday, March 5, 2018 at 9:48:25 AM UTC, Ralf Stephan wrote:
>
> I'm interested in a fix because it prevents clean patchbot results on
> OpenSuSE
>
Erik has an implementation of such feature generically, on some recent open
ticket.
>
>>- How to tell "configure" not to install the Sag
I'm interested in a fix because it prevents clean patchbot results on
OpenSuSE
>
>- How to tell "configure" not to install the Sage-shipped version ? I
>think I am able to look at the configuration of the Sage-shipped packages
>for which this happens in order to understand what is
On Saturday, September 2, 2017 at 9:10:51 AM UTC+1, Emmanuel Charpentier
wrote:
>
> I used to have the exact same problem (with libtinfo*) back when Sage
> shipped ncurses 5 (to which libtinfo* belong). My workaround was to move
> libtinfo* out of the way : Sage the used the systemwide libtinf
I used to have the exact same problem (with libtinfo*) back when Sage
shipped ncurses 5 (to which libtinfo* belong). My workaround was to move
libtinfo* out of the way : Sage the used the systemwide libtinfo*.
A recent upgrade to the Sage-shipped ncurses (which is now version 6) fixed
this.
IM
Removing system-wide R has no effect on ptestlong. The same three failures
occur.
I'm out of ideas and out of time to work on this. For now, I will redirect
the libreadline symlink to that belonging to the system, and get back to
mathematical physics!
Thanks for your efforts,
- Richard
On T
What does happen if you remove your system-wide (?) R installation, does it
have any effect?
I suspect it either interferes with running Sage (tests), or with building
Sage's R and Rpy...
On Thursday, August 31, 2017 at 9:37:26 PM UTC+1, Richard_L wrote:
>
> Both r-3.4.0.p0.log and rpy2-2.8.2
Both r-3.4.0.p0.log and rpy2-2.8.2.p0.log show
sh: /home/rllozes/Development/sage/local/lib/libreadline.so.6: no
version information available (required by sh)
With or without restoring my hacked symlink to its original state,
ldd local/lib/R/lib/libR.so and
ldd local/lib/python2.7/s
On Thursday, August 31, 2017 at 4:03:48 PM UTC+1, Richard_L wrote:
>
> No. LD_LIBRARY_PATH is not set.
> The curious thing is that there are 29 lib*.so in the sage/local/lib
> folder that are in common with the system /lib64 folder, although not
> necessarily of the same version/sub-version. Onl
No. LD_LIBRARY_PATH is not set.
The curious thing is that there are 29 lib*.so in the sage/local/lib folder
that are in common with the system /lib64 folder, although not necessarily
of the same version/sub-version. Only libreadline.so gives trouble during
make ptestall.
NB! Just grep'd all o
On Wednesday, August 30, 2017 at 6:14:06 PM UTC+1, Richard_L wrote:
>
> As I observed on the sage-release Sage.8.1.beta3 thread, a library
> conflict causes 'make ptestlong' to fail under openSUSE LEAP 42.2.
> Reworking the offending symlink in the sage installation to point to the
> system li
13 matches
Mail list logo
