R devel - Apr 2020 - R 4.0.0 build error with sysdata.rda on ppc64el architecture

The R 4.0.0 package migration on Debian is being held back by a failed build
on ppc64el [1]. We can see from the history of builds logs [2] that it used
to build, briefly failed, worked again and then failed leading to R 4.0.0's
release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.)

I have however neither changed anything, nor did I ever have to accomodate
ppc64el (as it has happened with other platforms in the past).

The automated build gets killed after 150 mins at

make[7]: Entering directory
'/<<PKGBUILDDIR>>/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[7]: Leaving directory
'/<<PKGBUILDDIR>>/src/library/tools/src'
make[6]: Leaving directory
'/<<PKGBUILDDIR>>/src/library/tools/src'
make[5]: Leaving directory
'/<<PKGBUILDDIR>>/src/library/tools'
make[5]: Entering directory
'/<<PKGBUILDDIR>>/src/library/tools'
installing 'sysdata.rda'
E: Build killed with signal TERM after 150 minutes of inactivity

as can be seen in [3]. The Debian wiki has pointers for getting a shell
account on such platforms [4] (and that is not limited to Debianers but a
'Minipower' service).  I now have one such account on the VM farm at
Unicamp
[5] in Brazil. It uses OpenStack (slick, never used it before) and I just
provisioned a reasonably beefy machine, booted from one of the available OSs
(Ubuntu 20.04), installed the build-dependencies and ... am now hanging at
the exact same spot:

make[7]: Entering directory
'/home/ubuntu/git/r-base/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[7]: Leaving directory
'/home/ubuntu/git/r-base/src/library/tools/src'
make[6]: Leaving directory
'/home/ubuntu/git/r-base/src/library/tools/src'
make[5]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools'
make[5]: Entering directory '/home/ubuntu/git/r-base/src/library/tools'
installing 'sysdata.rda'

So at least it reproduces. But how do we go about addressing this? Why would
it be looping infinitely trying to assemble sysdata.rda?

Any hints or suggestions or debug flags I should set?

Thanks in advance for any pointers,  Dirk


[1] https://buildd.debian.org/status/package.php?p=r-base&suite=experimental
[2] https://buildd.debian.org/status/logs.php?pkg=r-base&arch=ppc64el
[3]
https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=ppc64el&ver=4.0.0-1&stamp=1587737274&raw=0
[4] https://wiki.debian.org/ppc64el
[5] https://openpower.ic.unicamp.br/minicloud/

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Hum, at least it is not Apple, so maybe you can attach a debugger to the running
process? (gdb -p process_id or something like that --- haven't actually done
it for a decade). Then at least we can get a stack trace and a clue about where
it is looping. Diddling optimization options can also sometimes provide a clue.

-pd
> On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel <edd at debian.org>
wrote:
> 
> 
> The R 4.0.0 package migration on Debian is being held back by a failed
build
> on ppc64el [1]. We can see from the history of builds logs [2] that it used
> to build, briefly failed, worked again and then failed leading to R
4.0.0's
> release. (And my bad for missing how the alpha1/alpha2/beta/rc builds
failed.)
> 
> I have however neither changed anything, nor did I ever have to accomodate
> ppc64el (as it has happened with other platforms in the past).
> 
> The automated build gets killed after 150 mins at
> 
> make[7]: Entering directory
'/<<PKGBUILDDIR>>/src/library/tools/src'
> mkdir -p -- ../../../../library/tools/libs
> make[7]: Leaving directory
'/<<PKGBUILDDIR>>/src/library/tools/src'
> make[6]: Leaving directory
'/<<PKGBUILDDIR>>/src/library/tools/src'
> make[5]: Leaving directory
'/<<PKGBUILDDIR>>/src/library/tools'
> make[5]: Entering directory
'/<<PKGBUILDDIR>>/src/library/tools'
> installing 'sysdata.rda'
> E: Build killed with signal TERM after 150 minutes of inactivity
> 
> as can be seen in [3]. The Debian wiki has pointers for getting a shell
> account on such platforms [4] (and that is not limited to Debianers but a
> 'Minipower' service).  I now have one such account on the VM farm
at Unicamp
> [5] in Brazil. It uses OpenStack (slick, never used it before) and I just
> provisioned a reasonably beefy machine, booted from one of the available
OSs
> (Ubuntu 20.04), installed the build-dependencies and ... am now hanging at
> the exact same spot:
> 
> make[7]: Entering directory
'/home/ubuntu/git/r-base/src/library/tools/src'
> mkdir -p -- ../../../../library/tools/libs
> make[7]: Leaving directory
'/home/ubuntu/git/r-base/src/library/tools/src'
> make[6]: Leaving directory
'/home/ubuntu/git/r-base/src/library/tools/src'
> make[5]: Leaving directory
'/home/ubuntu/git/r-base/src/library/tools'
> make[5]: Entering directory
'/home/ubuntu/git/r-base/src/library/tools'
> installing 'sysdata.rda'
> 
> So at least it reproduces. But how do we go about addressing this? Why
would
> it be looping infinitely trying to assemble sysdata.rda?
> 
> Any hints or suggestions or debug flags I should set?
> 
> Thanks in advance for any pointers,  Dirk
> 
> 
> [1]
https://buildd.debian.org/status/package.php?p=r-base&suite=experimental
> [2] https://buildd.debian.org/status/logs.php?pkg=r-base&arch=ppc64el
> [3]
https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=ppc64el&ver=4.0.0-1&stamp=1587737274&raw=0
> [4] https://wiki.debian.org/ppc64el
> [5] https://openpower.ic.unicamp.br/minicloud/
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com

On 29 April 2020 at 11:22, peter dalgaard wrote:
| Hum, at least it is not Apple, so maybe you can attach a debugger to the
running process? (gdb -p process_id or something like that --- haven't
actually done it for a decade). Then at least we can get a stack trace and a
clue about where it is looping. Diddling optimization options can also sometimes
provide a clue.

(Missed this earlier as the conversation moved off-list.)

And to keep the list abreast, this appears to be related to the long double
issue on powerpc where needed an extra #define to ensure compilation. That
commit is the difference in a bisection as I was able to demonstrate. The
issue can also be circumvented by disabling long double support on the
platform, but hopefully a better fix can be found.  Bryan Lewis was
eagle-eyed on this and very helpful. The issue is now back in the hands of R
Core and I and others will await the news.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org