[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#605372: tseries: FTBFS on armel: unable to load shared object



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 | edd@debian.org | http://dirk.eddelbuettel.com



Reply to: