Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
On 04/06/2018 16:19, Dirk Eddelbuettel wrote: | So thank you, this seems to be the solution! I will upload to Ubuntu | proper now and keep an eye on the rest of fbasics' dependants. I'll let | you know how it goes. Awesome. I'll do the same here, starting with fBasics -- and we add as needed. All of fbasics' dependants built in Ubuntu without changes. \o/ One though though; should we not make that $ARCH dependent? We could, but it's not really the fault of the architecture; it's not like we need to add this flag for big-endian systems, or because i386 has weird floating point precision. It's just that mips, mipsel and sh4 in Debian, and arm64 and ppc64el in Ubuntu (currently) don't seem to have enough RAM. What are the implications of having --no-byte-compile across all architectures for this one package? I wonder why fbasics is the only one out of 600+ packages where we hit this issue. Thanks for the heads-up and quick test. Truly appreciated. You are welcome!
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
On 4 June 2018 at 15:28, Graham Inggs wrote: | On 04/06/2018 14:11, Dirk Eddelbuettel wrote: | > esp the env var it looks var (just like old make based on did) we can do | > this | > | >https://salsa.debian.org/edd/r-cran-rmpi/blob/master/debian/rules#L7 | > | > That may work. I should report it upstream either way. | | Adding the following to debian/rules worked on the mipsel porterbox | (fbasics still uses CDBS): Thinko on my part: I am updating only 'Binary: all'; may take me a moment to get to (all) of the 'Binary: any'. But I make sure I hit this one this evening when I get home. | extraInstallFlags="--no-byte-compile" | | I uploaded that to the Ubuntu PPA builders and it built on arm64 and | ppc64el as well. I also tried building fgarch, which depends on | fbasics, and it built too. | | So thank you, this seems to be the solution! I will upload to Ubuntu | proper now and keep an eye on the rest of fbasics' dependants. I'll let | you know how it goes. Awesome. I'll do the same here, starting with fBasics -- and we add as needed. One though though; should we not make that $ARCH dependent? | > Do we (or do "you" at Canonical) give guest accounts on these? I think I | > once did a lng time ago for mips or mipsel or ... | | Guest access for Debian porterboxes can be requested [1]. I don't know | about Ubuntu, I think it may be for employees only. I had forgotten about the guest accounts. I guess I once made use of that for an upstream of one of those "sometime hairy" package like rserve or rJava or ... Thanks for the heads-up and quick test. Truly appreciated. Dirk | | | [1] https://dsa.debian.org/doc/guest-account/ -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
On 04/06/2018 14:11, Dirk Eddelbuettel wrote: esp the env var it looks var (just like old make based on did) we can do this https://salsa.debian.org/edd/r-cran-rmpi/blob/master/debian/rules#L7 That may work. I should report it upstream either way. Adding the following to debian/rules worked on the mipsel porterbox (fbasics still uses CDBS): extraInstallFlags="--no-byte-compile" I uploaded that to the Ubuntu PPA builders and it built on arm64 and ppc64el as well. I also tried building fgarch, which depends on fbasics, and it built too. So thank you, this seems to be the solution! I will upload to Ubuntu proper now and keep an eye on the rest of fbasics' dependants. I'll let you know how it goes. Do we (or do "you" at Canonical) give guest accounts on these? I think I once did a lng time ago for mips or mipsel or ... Guest access for Debian porterboxes can be requested [1]. I don't know about Ubuntu, I think it may be for employees only. [1] https://dsa.debian.org/doc/guest-account/
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
On 4 June 2018 at 13:44, Graham Inggs wrote: | On 04/06/2018 13:27, Dirk Eddelbuettel wrote: | > For tests, can you add | > | > --no-byte-compile | > | > to R CMD INSTALL (via dh-r) to if that tickles it? | | I'm happy to run some tests, but where exactly should I add | '--no-byte-compile' ? I hear you -- not well documented, and I don't really know dh-h well but given where it happens here: https://salsa.debian.org/r-pkg-team/dh-r/blob/master/dh/R.pm#L160 esp the env var it looks var (just like old make based on did) we can do this https://salsa.debian.org/edd/r-cran-rmpi/blob/master/debian/rules#L7 That may work. I should report it upstream either way. Do we (or do "you" at Canonical) give guest accounts on these? I think I once did a lng time ago for mips or mipsel or ... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
On 04/06/2018 13:27, Dirk Eddelbuettel wrote: For tests, can you add --no-byte-compile to R CMD INSTALL (via dh-r) to if that tickles it? I'm happy to run some tests, but where exactly should I add '--no-byte-compile' ?
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
Graham, For tests, can you add --no-byte-compile to R CMD INSTALL (via dh-r) to if that tickles it? Else, for other (big) packages I have set the CFLAGS, CXXFLAGS, (et al) to a lower level too. We could look at (R)QuantLib as an example. It has massive C++ compilation demands for RAM. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
On 4 June 2018 at 13:03, Graham Inggs wrote:
| Source: fbasics
| Version: 3042.89-1
| Severity: serious
| Tags: ftbfs
| X-Debbugs-CC: r-pkg-t...@alioth-lists.debian.net
|
| Hi Dirk
|
| The recent binNMU of fbasics FTBFS on mips and mipsel where it built
| successfully in the past [1].
R 3.5.0 byte-compiles all R code in packages upon install, so that may be new.
| ** byte-compile and prepare package for lazy loading
| Error: compilation failed - cannot allocate vector of size 119 Kb at NULL
| Error in lazyLoadDBinsertVariable(vars[i], from, datafile, ascii,
| compress, :
|cannot allocate buffer
| ERROR: lazy loading failed for package 'fBasics'
|
| Admittedly, the builders for these architectures do not have much RAM,
| but I am seeing a very similar failure on the Ubuntu builders [2] on
| arm64 and ppc64el.
|
| ** byte-compile and prepare package for lazy loading
| ** help
| *** installing help indices
| ** building package indices
| ** testing if installed package can be loaded
| Error in system2(file.path(R.home("bin"), "R"), c(if (nzchar(arch))
| paste0("--arch=", :
|cannot popen ' '/usr/lib/R/bin/R' --no-save --slave 2>&1 <
| '/tmp/RtmpQUy0RV/file19c77181460d'', probable reason 'Cannot allocate
| memory'
| * removing
| ‘/<>/debian/r-cran-fbasics/usr/lib/R/site-library/fBasics’
| Warning in q("no", status = status, runLast = FALSE) :
|system call failed: Cannot allocate memory
|
| Would you please have look and see if there is any way around this?
I have neither special insight into these platforms, nor access to them. You
may be in a better position to do some tests.
Medium-bad case is we block theses architectures; worst is we remove fbasics
and its dependends. It is code that is (effectively) in maintenance mode as
the original author and driver, Prof Wuertz, died years ago.
As for the "R fails to install a package" issue, I can take this to R Core
but without access for one of them ... there is little we can expect them to
do.
Dirk
| Regards
| Graham
|
|
| [1] https://buildd.debian.org/status/package.php?p=fbasics=unstable
| [2] https://launchpad.net/ubuntu/+source/fbasics/3042.89-1build1
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#900756: fbasics: FTBFS compilation failed - cannot allocate
Source: fbasics
Version: 3042.89-1
Severity: serious
Tags: ftbfs
X-Debbugs-CC: r-pkg-t...@alioth-lists.debian.net
Hi Dirk
The recent binNMU of fbasics FTBFS on mips and mipsel where it built
successfully in the past [1].
** byte-compile and prepare package for lazy loading
Error: compilation failed - cannot allocate vector of size 119 Kb at NULL
Error in lazyLoadDBinsertVariable(vars[i], from, datafile, ascii,
compress, :
cannot allocate buffer
ERROR: lazy loading failed for package 'fBasics'
Admittedly, the builders for these architectures do not have much RAM,
but I am seeing a very similar failure on the Ubuntu builders [2] on
arm64 and ppc64el.
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
Error in system2(file.path(R.home("bin"), "R"), c(if (nzchar(arch))
paste0("--arch=", :
cannot popen ' '/usr/lib/R/bin/R' --no-save --slave 2>&1 <
'/tmp/RtmpQUy0RV/file19c77181460d'', probable reason 'Cannot allocate
memory'
* removing
‘/<>/debian/r-cran-fbasics/usr/lib/R/site-library/fBasics’
Warning in q("no", status = status, runLast = FALSE) :
system call failed: Cannot allocate memory
Would you please have look and see if there is any way around this?
Regards
Graham
[1] https://buildd.debian.org/status/package.php?p=fbasics=unstable
[2] https://launchpad.net/ubuntu/+source/fbasics/3042.89-1build1
