Hi Dirk, Hi Christian (please look at my original bug report)
I upgraded current sarge nlme to etch, and have no troubles, although I
noted the following output from apt-get dist-upgrade:
Preparing to replace r-cran-lattice 0.11-6-1 (using
.../r-cran-lattice_0.14-13-1_i386.deb) ...
Unpacking replacement r-cran-lattice ...
/usr/bin/R: line 113: /usr/lib/R/etc/ldpaths: No such file or directory
dpkg: warning - old post-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
Preparing to replace r-cran-nlme 3.1.55-1 (using
.../r-cran-nlme_3.1.77-1_i386.deb) ...
Unpacking replacement r-cran-nlme ...
/usr/bin/R: line 113: /usr/lib/R/etc/ldpaths: No such file or directory
dpkg: warning - old post-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
dpkg: ... it looks like that went OK.
But I just now remembered that on the box where the bug occured I
upgraded starting from the R 2.4.0 backport of Christian Steigies, which
included r-recommended.
Looking at his r-recommended package (6.1 MB), it contains, among
others, the full nlme package!
So I guess the problem is the incompatibility of Christian's packages
with the official Debian ones in some way or the other. I have put him
in the CC of this mail.
Once could expect that the upgrade from an backport works without
problems, but not necessarily so. And it seems not to be a bug in the
Debian package. So I think the bug can be closed.
Johannes
* Dirk Eddelbuettel <[EMAIL PROTECTED]> [061213 17:00]:
>
> Hi Johannes,
>
> Thanks for the follow-ups. I'll combine my replies to both mails into this
> one.
>
> On 13 December 2006 at 14:10, Johannes Ranke wrote:
> | > Works for me on my testing box with 3.1.77-1 -- see below.
> | >
> | > Could you please grep for R_LIBS in
> | > /etc/R/
> |
> | jazzy:/etc/R# grep R_LIBS *
> |
> Renviron:R_LIBS=${R_LIBS-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
> |
> Renviron.dpkg-dist:R_LIBS=${R_LIBS-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
> |
> | > /usr/lib/R/etc/
> |
> | jazzy:/usr/lib/R/etc# grep R_LIBS *
> |
> Renviron:R_LIBS=${R_LIBS-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
>
> Defaults, so it finds the package.
>
> | > and it should come up once in
> |
> | ???
> |
> | I had the thought that the help index is not built in the postrm script
> | (there are a few lines commented out that would probably do this), but
> | this would not explain why the R packages can not be loaded...
>
> The help index has nothing to do with how library() works. The help index
> now gets rebuilt once you say help.start() in R.
> |
> | > Weird. Let's check -- we obviously need to fix this if it is a generic
> issue.
> |
> | Yes, definitely. For now I can only use packages installed directly from
> | CRAN via install.packages() on this box, or use my Windows XP instance in
> | Xen which also works nicely ...
>
> Ah. I still haven't tried Xen, but I do like vmware...
Well, I got new hardware (AM2 socket), and could not resist to try Xen.
The etch version with kernel 2.6.18 works nicely with windows xp
professional (needed for rdesktop connection).
Greetings,
Johannes
>
> On 13 December 2006 at 16:06, Johannes Ranke wrote:
> | I investigated some more and was able to solve the problem
> | by purging (!) r-cran-nlme + r-cran-lattice and reinstalling them.
> |
> | I am as yet unable to reproduce the problem. I will do another upgrade
> | from sarge to etch, and will report if the problem reappears.
>
> Sounds like a good idea. Please try to note which versions of r-cran-nlme et
> al you are upgraing from, and to, and under which R version. I may have a
> hard time replicating this but I can try ....
>
> Dirk
>
> --
> Hell, there are no rules here - we're trying to accomplish something.
> -- Thomas A. Edison
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
