Provide a workaround for tar/pax dogfight in R packages

[fgeorgatos]

Hi,

I am being bitten time and again by a fancyness (incompatibility if you prefer),
about how git(hub) prepares the tarballs and how R^Hpython expects them. Example:

fgeorgatos@gaia-57:~: $ time eb Rgputools-876c10d-ictce-5.3.0-R-3.0.1.eb --try-software-version=725088c
== temporary log file in case of crash /tmp/easybuild-pXjTcu.log
== resolving dependencies ...
== processing EasyBuild easyconfig /tmp/Rgputools-725088c-ictce-5.3.0-R-3.0.1.eb
== building and installing Rgputools/725088c-ictce-5.3.0-R-3.0.1...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== testing...
== installing...
ERROR: EasyBuild encountered an exception (at easybuild/main.py:770 in build_and_install_software): autoBuild Failed (last 300 chars): brary=/home/users/fgeorgatos/.local/easybuild/software/Rgputools/725088c-ictce-5.3.0-R-3.0.1 " exited with exitcode 1 and output:
Warning in untar2(tarfile, files, list, exdir) :
  checksum error for entry 'pax_global_header'
Error in untar2(tarfile, files, list, exdir) : unsupported entry type 'g'


real    0m4.120s
user    0m1.384s
sys 0m1.348s
fgeorgatos@gaia-57:~: $

The technical explanation of what is going on, and a fix, is visible at:
https://stat.ethz.ch/pipermail/r-devel/2011-April/060386.html
https://mailman.stat.ethz.ch/pipermail/r-help/2010-December/263490.html
ie. tarballs from github make R have a hickup.

i am still exploring the path of least resistance for resolving this...

[boegel]

So, the solution would be to unpack tarballs first, and only then pass it to R for installation? Seems easy enough to fix... @fgeorgatos: care to look into a PR for this?

[boegel]

I can't reproduce this anymore (via easybuilders/easybuild-easyconfigs#546), yet the commit ID & R version are exactly the same... What shall we do with this @fgeorgatos?

[fgeorgatos]

@boegel: I'm surprised you are emphatic you can't see it and I hit it all the time :-(
can we have more volunteers give it a shot?!

[fgeorgatos]

btw. I hit this bug once more yesterday, either with this:

• time eb --from-pr 571 PyCUDA-2013.1.1-goolf-1.4.10-Python-2.7.3-CUDA-5.5.22.eb
  or with this:
• time eb --from-pr 571 PyCUDA-2013.1.1-goolf-1.4.10-Python-2.7.3-CUDA-5.5.22.eb --try-software-version=2016.1.1
  (ie. try both)