Hi Adam,
On 14 December 2010 at 20:12, Adam D. Barratt wrote:
| On Tue, 2010-12-14 at 12:39 -0600, Dirk Eddelbuettel wrote:
| > reassign 605372 release.debian.org
| > thanks
|
| [For reference, at least right now debian-release has only received the
| result of your control@ mail, not the mail I'm replying to; it's
| generally a good idea to CC the receiving package]
[ I was thinking about that but then I didn't know the email handle of the
virtual BTS entity release.debian.org -- the release list ? ]
|
| > Dear release team,
| >
| > Can you please schedule a binary-only rebuild of package
| >
| > quadprog (binary: r-cran-quadprog)
| >
| > on the 'armel' architecture, and once completed, schedule a binary-only
| > rebuild of package
| >
| > tseries (binary: r-cran-tseries)
| >
| > on the 'armel' architecture.
|
| Looking through the bug log, I'm not convinced that this will help. The
| tseries build fails with:
|
| | unable to load shared object
'/usr/lib/R/site-library/quadprog/libs/quadprog.so':
| | libRblas.so: cannot open shared object file: No such file or directory
|
| and the quadprog build log on armel predictably contains:
|
| dpkg-shlibdeps: warning: couldn't find library libRblas.so needed by
debian/r-cran-quadprog/usr/lib/R/site-library/quadprog/libs/quadprog.so (ELF
format: 'elf32-littlearm'; RPATH: '').
libRblas is outdated by years. We used it when we had lapack 3.1.* years,
and for several years have used Debian's BLAS and LAPACK meaning that R's
linRblas is no longer built.
| libRblas.so comes from r-base-core-ra (on armel), which wasn't installed
| as part of the quadprog build on armel. In fact, so far as I can see,
| r-base-core-ra is a completely leaf package, with no reverse
Yes, Ra (aka r-base-core-ra) has nothing to do with this.
| {build-,}dependencies so there's no indication in the packaging that
| it's intended to be installed whilst building quadprog.
Yes, which is why I suspect a new build will fix it. I have no other idea
here, look at
https://buildd.debian.org/build.cgi?pkg=quadprog
so see that quadprog built fine several dozen builds on all arches, and also
see at
https://buildd.debian.org/build.cgi?pkg=tseries
tseries had never failed for armel before until this (random ?) break in
quadprog.
The R build process is __highly__ standardized; I maintain dozens of packages
in the space and once built a process to autobuilds 2000+ source package into
debs (at http://debian.cran.r-project.org -- but currently dormant).
I still think that it may have been random, and that a new build would cure it.
I'd be open to other fixes, but there is no issue with either tseries or
quadprog. These are super-stable upstream and use just vanilla C / Fortran.
No breakage from there AFAICT.
Cheers, Dirk
|
| Regards,
|
| Adam
|
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
