I would like to continue the thread initiated by Matthew Kinkade,
concerning a problem with the CRAN binary of my "qtl" package.
If one uses install.package("qtl"), with apparently any mirror, the
Mac binary install is for the previous version of the package (1.11-12).
And it seems that the binary at either of the following
http://cran.us.r-project.org/bin/macosx/universal/contrib/r-release/qtl_1.12-26.tgz
http://cran.us.r-project.org/bin/macosx/universal/contrib/r-release/qtl_1.12-26.tgz
were mistakenly built with 2.10.0 rather than 2.9.1, and so loading
the library gives the error that Matthew Kinkade reported (with a
dyn.load error and a reference to R version 2.10).
I install the above directly with, for example
install.packages("qtl", contriburl="http://cran.us.r-project.org/bin/macosx/universal/contrib/2.9
")
Who should I talk to about getting the package on CRAN re-built? Does
anyone know why install.packages("qtl") grabs the previous version of
the package and not the most current one?
Thanks,
karl
-----------
Karl Broman
kbroman at biostat.wisc.edu
http://www.biostat.wisc.edu/~kbroman
R/qtl installation on Leopard 10.5.7
3 messages · Karl Broman, Simon Urbanek
On Jul 16, 2009, at 9:22 PM, Karl Broman wrote:
I would like to continue the thread initiated by Matthew Kinkade,
concerning a problem with the CRAN binary of my "qtl" package.
If one uses install.package("qtl"), with apparently any mirror, the
Mac binary install is for the previous version of the package
(1.11-12).
And it seems that the binary at either of the following
http://cran.us.r-project.org/bin/macosx/universal/contrib/r-release/qtl_1.12-26.tgz
http://cran.us.r-project.org/bin/macosx/universal/contrib/r-release/qtl_1.12-26.tgz
were mistakenly built with 2.10.0 rather than 2.9.1, and so loading
the library gives the error that Matthew Kinkade reported (with a
dyn.load error and a reference to R version 2.10).
I install the above directly with, for example
install.packages("qtl", contriburl="http://cran.us.r-project.org/bin/macosx/universal/contrib/2.9
")
Who should I talk to about getting the package on CRAN re-built?
Me. I was at the useR/DSC and in the meantime something went horribly wrong with the package builds since suddenly all packages have been built with R-devel instead of R-release. I have started a complete re- built, but it can take 1-2 days before it's done and propagated through the mirrors. Then I'll investigate the cause.
Does anyone know why install.packages("qtl") grabs the previous
version of the package and not the most current one?
If you referring to 64-bit builds then it's likely that the builds have not been run recently. I'll verify that part also tomorrow. Cheers, Simon
1 day later
On Jul 16, 2009, at 10:29 PM, Simon Urbanek wrote:
On Jul 16, 2009, at 9:22 PM, Karl Broman wrote:
I would like to continue the thread initiated by Matthew Kinkade,
concerning a problem with the CRAN binary of my "qtl" package.
If one uses install.package("qtl"), with apparently any mirror, the
Mac binary install is for the previous version of the package
(1.11-12).
And it seems that the binary at either of the following
http://cran.us.r-project.org/bin/macosx/universal/contrib/r-release/qtl_1.12-26.tgz
http://cran.us.r-project.org/bin/macosx/universal/contrib/r-release/qtl_1.12-26.tgz
were mistakenly built with 2.10.0 rather than 2.9.1, and so loading
the library gives the error that Matthew Kinkade reported (with a
dyn.load error and a reference to R version 2.10).
I install the above directly with, for example
install.packages("qtl", contriburl="http://cran.us.r-project.org/bin/macosx/universal/contrib/2.9
")
Who should I talk to about getting the package on CRAN re-built?
Me. I was at the useR/DSC and in the meantime something went horribly wrong with the package builds since suddenly all packages have been built with R-devel instead of R-release. I have started a complete re-built, but it can take 1-2 days before it's done and propagated through the mirrors. Then I'll investigate the cause.
It turns out that qtl was one of those unlucky packages that had dependency issues, so it wasn't re-built (there were five others) since the R-devel issue fix.
Does anyone know why install.packages("qtl") grabs the previous
version of the package and not the most current one?
If you referring to 64-bit builds then it's likely that the builds have not been run recently. I'll verify that part also tomorrow.
The builds were down due to a reboot of the 64-bit build machine - those are not quite automated (because it's not a dedicated machine), so I had to start them up manually. The updates should catch up soon. Cheers, Simon