Hi Dirk,
thanks for the report. Access to the test system is not necessary, the
memory requirements of the byte-code compiler are usually
platform-independent and specifically with this package I can reproduce
they are very high. We'll have a look what we can do, certainly there
should at least be a way to recover and use the uncompiled version when
memory allocation fails, this is already done by the JIT but not when
compiling during installation. Before R or the package is patched, the
only workaround for memory constrained systems is probably to disable
byte-compilation of this package, as I read you are doing already.
Best
Tomas
On 06/04/2018 05:14 PM, Dirk Eddelbuettel wrote:
As you may know, I look after the R package for Debian. My fellow Debianers
make me follow a specific protocol -- a so-called "transition" in which all
dependent packages on an identified potential breakge are rebuilt under the
new (potentially breaking) change. We started adding an r-api-3.4 tag last
(major) release. Now it is r-api-3.5 and the transition got started with the
green light from the release team last Friday.
Now one build failure occurred for one of the (old, effectively litte
maintained) RMetrics packages: fBasics. It blows up at the byte-compilation
step on at least four (older, smaller) architectures: mips, mipsel, arm64
(ubuntu), ppc64el. More at https://bugs.debian.org/900756 where we also
worked out the "solution" of suppressing byte-compilation at installation.
Luke, Tomas, ...: Would it help you to get access to such hardware?
We may get you some sort of "guest pass" access to porter machines. Else I
could try but I have my hands plenty full with the transition (having built
[and finally transferred to our Debian Gitlab instance] 20+ package during
day two of R/Finance...).
Cheers, Dirk
PS I CC'ed the bug report, if any follow-up keep the CC it gets logged there.
PPS Happy to discuss / help off-list too, of course.
