218. The end of Gnome in Debian?

Update 12/11/2012: And we're back to gnome: http://www.phoronix.com/scan.php?page=news_item&px=MTIyNTM

This is a bit of a bombshell: http://www.phoronix.com/scan.php?page=news_item&px=MTE1NTk

Also reported here: http://www.h-online.com/open/news/item/Debian-to-use-Xfce-as-its-standard-desktop-1663868.html
and here: http://www.neowin.net/news/debian-drops-gnome-chooses-xfce-as-default-desktop
and here: http://linux.slashdot.org/story/12/08/08/1455243/debian-changes-default-desktop-from-gnome-to-xfce

UPDATE: No, I don't have any more information. However, I've been thinking a little bit about this. Debian is not a targeted distro like Ubuntu, Red Hat, SUSE or Mint. I'm not sure how the discussions among the debian package maintainers go, but I'm suspecting that it's more of a matter of ironing out reported bugs, than to focus on providing a 'user experience'. SID and Testing are rolling releases, after all. So 'dumping' gnome really won't affect anything at all very much in the short to medium term. Those who like KDE will use KDE. Those who like Gnome will use Gnome. And so on. In the long term, enough people may encounter XFCE as their first DE via Debian that it starts to change the balance in the user bases of the different DEs, but given that a great majority of both current and future debian users come to debian via other distros  -- from red hat/fedora/knoppix back in the days, then ubuntu in the late 2000s, and now perhaps mint -- many users probably both have both experience in how to set up different DEs and preferences as to which one they want to use.

So yeah. Sorry about the hyperbole in the title.

Original post:
Basically, Debian is thinking about dropping Gnome as the default desktop and replacing it with XFCE when Wheezy goes stable. The official reason is (CD ROM) space, not that there's any issues with GNOME 3.

I wouldn't be surprised if the rumoured difficulties in communicating with the Gnome crowd may have played a role, in addition to the (a bit hysterical at times) general dissatisfaction with GNOME 3.

Having 'grown up' with gnome (Baby Duck Syndrome) I think it's sad news -- gnome is pretty, functional and makes linux just different enough to give it a distinct look.

[Btw, this article about the Baby Duck Syndrome is a nice read: http://www.ibm.com/developerworks/web/library/wa-cranky50/index.html ]

XFCE, LXDE and KDE are all capable desktops, and I've played with LXDE and KDE recently. Not being that familiar with XFCE -- or even LXDE really -- it does appear to me that what really sets KDE and GNOME apart is that they come with a complete package -- KDE and GNOME all have their awkwardly named software applications: epiphany vs konqueror, evolution vs kmail etc.

Apart from lxterminal and lxmusic for lxde, and thunar for xfce, similar DE specific apps appear to be thin on the ground for LXDE and XFCE. That's not necessarily a big issue, but we've all had issues with GTK vs QT and how pieces of software using either framework look in different environments. It's hardly a disaster, but just enough to be noticeable.

It would also be interesting if the netinstall and business-card isos would ask about which specific DE to install, rather than just ask about whether a desktop is to be installed , in particular if debian is interested in experimenting.

Offering more choice would really not be that bad of an idea. Personally, and for my own biased reasons, I'm  much more interested in LXDE than XFCE, and more interested in GNOME than KDE. XFCE, the way it's implemented in Debian Squeeze, looks a bit dated -- basically like GNOME 2. While I'm not really into that, given the uproar during the past year a lot of people seem to prefer the old gnome 2 look. Besides, the strength of the old desktops is that you can theme and modify them to the point of no recognition.

And if we're talking about slim installs of debian, we really should take a look at Crunchbang (#!) as well, which uses openbox.

Finally, what about Jessie? Will GNOME be back or is this the defining moment for XFCE?

217. Recently...

Recently I've been busy preparing lectures (phew!), which means I've been kinder to my computer than is normal. Still, I managed to get myself into a few situations. The need to 'get stuff done' overrode the importance of documentation, but here's the low-down in case someone finds themselves in a similar situation:


1. Upgrades keep on getting stuck when restarting nfs/nfsd (nfs-common, nfs-kernel-server).
Normally I don't have any problems with nfs -- it's a tried and tested technology -- but one of my cluster nodes was giving me grief.

The key was to comment out everything in /etc/exports and commenting out nfs mounted partitions in /etc/fstab, then adding nfs and nfsd to /etc/modprobe.d/blacklist.conf (not sure this actually did anything), rebooting, throwing in

sudo rmmod nfs nfsd 


to be on the safe side, then doing

sudo dpkg --configure -a

to get dpkg/apt back in working order. After that I could uncomment everything in /etc/exports and /etc/fstab, and whitelist my drivers again.

Problem solved.

2. Nvidia is still a headache.
Since I was given a rare opportunity to reboot my front node I did a bit of work on it. Mainly, I wanted to allow gdm to start again, and figured I'd return to my nvidia driver managment to dkms-y goodness.

So I fired up smxi, selected 'debian-nvidia' and...everything was messed up. Long story short: I got it working with gdm3 by picking 'current driver' in smxi (always blacklist nouveau if you want to use/install nvidia drivers), making sure that there was no 'vga' (e.g.  vga=0x0318 ) in GRUB_CMDLINE_LINUX in /etc/default/grub and rebooting liberally.

I later got the debian-nvidia (dkms) version working by 1) not using frambuffer and 2) manually removing all nvidia legacy drivers that smxi pulled in. Well, that's working as in no error messages and the desktop looking fine.

3. GNOME 3 not diplaying all letters
e.g. 'guake' was rendered as 'g ak '. This happened on a low-powered system. A 'fix' was to go to advanced settings (gnome-tweak-tool), select font and change scaling from 1.0 to 1.2 and above.

It's not much of a 'fix', so I ended up nuking GNOME from that system and replacing it with KDE to have a reason to get more familiar with it. In the interest of balance I nuked all other DEs from another box and put LXDE on it. To paraphrase the Dos Equis commercial: I don't always use a DE, but when I do, I want to learn something new.

I've used KDE and GNOME on and off over the past 12 years, but you get rusty -- and both KDE and GNOME have changed enough from v 3.x and 2.x, respectively, that they aren't the same environment anymore. I still get an initial feeling of joy when I sit down by an NMR console and discover a red hat system with a 3.x desktop. Which is quickly followed by being annoyed over not having root access, but whatever. As for the usual gnome 2 vs gnome 3 arguments -- I like gnome3 in general. I just hate the idea of settings being hidden or disabled, and functionality being reduced. Enough so that I'm still looking for a potential replacement.

So far :
KDE -- I like it. It's overdoing the desktop effects a bit (out of the box) but, since it's KDE, it's easy to turn things on and off. I'm still a GNOME man, and KDE doesn't have the warm fuzzy feeling of home yet, but I can see how I could get used to it. I just need to get over my outdated idea that KDE is for windows users (I've never used a Mac so I guess I'm a reformed windows -- actually DOS -- user more than anything else).

KDE on one of my other systems seems to be messing up GNOME 3 though -- e.g. the mouse cursor theme gets transferred to gnome, and the pop-up notifications are those of kwin and not gnome-shell.  Not sure whether it's KDE causing it or whether I've messed a bit too much with my system.

LXDE -- it's functional and has long been my choice for virtual installations of linux for windows users. It's minimalistic in the sense that yes, it does provide a desktop, but no, it doesn't try to do anything beyond providing a set of menus and a bit of themeing. And that's a good thing. If you're going to impress a mate -- use gnome or kde. If you just need to get something done and launch a piece of software, lxde's your mate.

4. One of my systems lacked /etc/init.d/vboxdrv
Not all my collaborators use linux, so I keep a virtual copy of XP around for when I'm absolutely forced to use MS Word (OpenOffice sometimes changes the layout and it quickly becomes messy on collaborative documents). When taking a quick break to edit a manuscript in virtualbox I got the usual no driver present, 'run /etc/init.d/vboxdrv setup' message. Well, there was no /etc/init.d/vboxdrv in spite of dkms and vboxdrv-dkms being installed in addition to all the kernel headers. Turns out that the quickest way, assuming that locate vboxdrv doesn't come up empty (i.e. it's somewhere in the kernel tree) is just to mod it.
modprobe vboxdrv


To avoid it in the future, stick
vboxdrv
somewhere in your /etc/modules


5. Mysteriously self-rotating gnuplot images in latex 
Came down to a stupid mistake. I was doing:

set term postscript enhanced colour
set output 'acid.eps'
set border 3
set xtics nomirror
set ytics nomirror

I forgot to add eps -- getting rusty I suppose.

set term postscript enhanced eps colour
set output 'acid.eps'
set border 3
set xtics nomirror
set ytics nomirror

Surprised it hasn't happened before during all these years of latex usage.

6. Setting default line printer
me@beryllium:$ lpq

lpq: Error - no default destination available.

me@beryllium:$ lpstat -a

AdobePDF accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF7 accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF8 accepting requests since Mon 06 Aug 2012 10:04:13 EST
AdobePDF8@johnbowmansimac.dbs.monash.edu.au accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF9 accepting requests since Mon 06 Aug 2012 08:01:32 EST
AdobePDF9@130.194.162.66 accepting requests since Mon 06 Aug 2012 08:01:32 EST
biol08r159p1 accepting requests since Mon 06 Aug 2012 08:01:32 EST
Canon_iP4300 accepting requests since Mon 06 Aug 2012 08:01:32 EST
Canon_MP460 accepting requests since Mon 06 Aug 2012 10:09:36 EST
Colour_109a accepting requests since Mon 06 Aug 2012 08:01:32 EST
global-mfp accepting requests since Mon 28 May 2012 14:27:30 EST
GlobalMFP@s0001203.dbs.monash.edu.au accepting requests since Mon 06 Aug 2012 08:01:32 EST
HP_LaserJet_Professional_P1102w accepting requests since Sat 04 Aug 2012 23:08:16 ESTHPColourLaserCP3505 accepting requests since Mon 06 Aug 2012 08:01:32 EST
HPLaserJetP3005 accepting requests since Mon 06 Aug 2012 08:01:32 EST

 me@beryllium:$ lpoptions -d HP_LaserJet_Professional_P1102w

auth-info-required=none copies=1 device-uri=hp:/usb/HP_LaserJet_Professional_P1102w?serial=000000000Q91K4WVSI1c finishings=3 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=AutoConfigure,Clean,PrintSelfTestPage printer-info='HPIJS -- drv:///hpijs.drv/hp-laserjet_professional_p1102w-hpijs.ppd' printer-is-accepting-jobs=true printer-is-shared=true printer-location printer-make-and-model='HP LaserJet Professional p1102w, hpcups 3.12.4, requires proprietary plugin' printer-state=5 printer-state-change-time=1344085696 printer-state-reasons=paused printer-type=8425484 printer-uri-supported=ipp://localhost:631/printers/HP_LaserJet_Professional_P1102w

7. The next Debian is codenamed Jessie!
I'm only 6 days late...apparently that's the cowgirl.

216. Quantum Espresso on ROCKS 5.4.3 / CentOs 5.6 -- Almost got it.

Preamble:

I've seen just about any error message imaginable when compiling Quantum Espresso. You can most likely get around them by following this guide ad verbatim 
(no parallel environment detected, can't build fortran programs, no linker, parallel vs serial compiler etc.)

This compile is nothing like the easy-breezy one on debian, because of one reason: CentOS 5.6 is old. It's so old that the default gcc version can't compile QE. You'd encounter similar problems with an increasing number of software packages, including ABINIT.

      CentOS 5.6: gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
      Wheezy:       gcc version 4.7.1 (Debian 4.7.1-2)

The crusty compiler collection means we have to hammer out errors like these during compilation:

In file dfile_star.f90:28

    INTEGER,ALLOCATABLE ::  npert (:), irgq (:)
                      1
Error: Attribute at (1) is not allowed in a TYPE definition
 In file dfile_star.f90:37

    REAL(DP),ALLOCATABLE :: gi (:,:), gimq (:), eigen(:)
                       1
Error: Attribute at (1) is not allowed in a TYPE definition
 In file dfile_star.f90:42

    COMPLEX(DP),ALLOCATABLE :: u(:,:), t(:,:,:,:), tmq (:,:,:)
                          1
Error: Attribute at (1) is not allowed in a TYPE definition

Hence the requirement to first compile GCC 4.7, even if it takes a couple of hours. 

To the students out there swearing (and sweating) over their professors' insistence on using ROCKS/CentOS: compiling a compiler is not a wasted skill and just might be useful in building cross compilation environments for the time when you decide that science can take a hike and there's more money in working on setting up embedded systems. At least it'll buy you a little geek cred. 

Also, it seems that you need to use math and mpi libs compiled with the same compiler as you use to compile quantum espresso. So...lots of steps today as well!

Also, I haven't reported the configure bug for openmpi 1.6. Feel free to reproduce and report it.

I'm not happy that Quantum Espresso ignores the compile flags I've given it and defaults to things it should not default. I've had to jump through way too many hoops to be happy about this. OpenMPI not supporting program-suffix annoys me as well.

This is another massive compile...I'd rate it as my most annoying, troublesome and infuriating one yet.

---

---

1. Build GCC (gfortran, g++, gcc) 4.7 according to this post:
 http://verahill.blogspot.com.au/2012/07/compiling-gcc-471gfortran-471-on-centos.html
Make sure that
export PATH=$PATH:/share/apps/tools/gcc/gcc47/bin

2. Create target directory structure
sudo mkdir /share/apps/libs
sudo chown $USER /share/apps/lib

3. Recompile GNU OpenMP (libgomp)
It's probably easier you start with a freshly extracted gcc-4.7.1
cd ~/tmp/gcc
mkdir newgcc
cp gcc-4.7.1.tar.gz newgcc/
cd newgcc
tar xvf gcc-4.7.1
cd gcc-4.7.1/libgomp
mkdir build
cd build/
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpfr/lib
.././configure CC=gcc-gcc-4.7 CXX=g++-gcc-4.7 F77=gfortran-gcc-4.7 FC=gfortran-gcc-4.7 --prefix=/share/apps/tools/gcc/gcc47

md5sum /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0
23db68121aacf1e7d896704474e26350  /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0

make
make install

md5sum /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0
791a1ceb0ea4009e22703b82e8ce1ff4  /share/apps/tools/gcc/gcc47/lib/libgomp.so.1.0.0

4.  Compile OpenMPI using your new GCC 
cd ~/tmp/
wget http://www.open-mpi.org/software/ompi/v1.6/downloads/openmpi-1.6.tar.gz
tar xvf openmpi-1.6.tar.gz
cd openmpi-1.6
mkdir build
cd build/
export LD_LIBRARY_PATH=/share/apps/tools/gcc/gcc47/lib64:/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1:/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/mpfr/lib

.././configure --prefix=/share/apps/libs/openmpi47 CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 F77=gfortran-gcc-4.7 F90=gfortran-gcc-4.7 CPP=cpp-gcc-4.7 CXX=g++-gcc-4.7 --with-sge LDFLAGS="-L/share/apps/tools/gcc/gcc47/lib64 -L/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/share/apps/tools/gcc/gmp/lib -L/share/apps/tools/gcc/mpc/lib -L/share/apps/tools/gcc/mpfr/lib -L/share/apps/tools/gcc/gcc47/lib" CPPFLAGS="-I/share/apps/tools/gcc/mpc/include -I/share/apps/tools/gcc/gmp/include -I/share/apps/tools/gcc/mpfr/include -I/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include"

** There's a bug in the openmpi configure script leading to config failure due to to an extra space being introduced in front of -L when testing the F77 compiler. Exporting the LD_LIBRARY_PATH is done to get around that. **

make
make install

cd /share/apps/libs/openmpi47bin/
ls mpi* |xargs -I {} ln -s {} {}-gcc-4.7
echo 'export PATH=$PATH:/share/apps/libs/openmpi47/bin' >> ~/.bashrc
source ~/.bashrc

cd /share/apps/libs/openmpi47share/openmpi/

ln -s mpif77-vt-wrapper-data.txt mpif77-gcc-4.7-vt-wrapper-data.txt

ln -s mpif90-vt-wrapper-data.txt mpif90-gcc-4.7-vt-wrapper-data.txt

ln -s mpicc-vt-wrapper-data.txt mpicc-gcc-4.7-vt-wrapper-data.txt

ln -s mpic++-vt-wrapper-data.txt mpic++-gcc-4.7vt--wrapper-data.txt

ln -s mpicxx-vt-wrapper-data.txt mpicxx-gcc-4.7-vt-wrapper-data.txt

ln -s mpif77-wrapper-data.txt mpif77-gcc-4.7-wrapper-data.txt

ln -s mpif90-wrapper-data.txt mpif90-gcc-4.7-wrapper-data.txt

ln -s mpicc-wrapper-data.txt mpicc-gcc-4.7-wrapper-data.txt

ln -s mpic++-wrapper-data.txt mpic++-gcc-4.7-wrapper-data.txt

ln -s mpicxx-wrapper-data.txt mpicxx-gcc-4.7-wrapper-data.txt

5. Compile FFT using your new GCC
cd ~/tmp
wget ftp://ftp.fftw.org/pub/fftw/fftw-3.3.2.tar.gz
tar xvf fftw-3.3.2.tar.gz

cd fftw-3.3.2/
./configure --enable-float --enable-mpi --enable-threads --with-pic --prefix=/share/apps/libs/fftw-3.3.2-gcc47/single CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 CPP=cpp-gcc-4.7 MPIF90=mpif90-gcc-4.7 F77=gfortran-gcc-4.7 MPICC=mpicc-gcc-4.7 MPIF77=mpif77-gcc-4.7

make
make install
make check

--------------------------------------------------------------
         FFTW threaded transforms passed basic tests!
--------------------------------------------------------------
..
Executing "mpirun -np 1 ..
..
make[3]: *** [check-local] Error 1
..

That mpirun won't work isn't that surprising since it's still point to /opt/openmpi/bin instead of our mpirun-gcc-4.7

make distclean
./configure --disable-float --enable-mpi --enable-threads --with-pic --prefix=/share/apps/libs/fftw-3.3.2-gcc47/double CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 CPP=cpp-gcc-4.7 MPIF90=mpif90-gcc-4.7 F77=gfortran-gcc-4.7 MPICC=mpicc-gcc-4.7 MPIF77=mpif77-gcc-4.7

make
make install
make check

--------------------------------------------------------------
         FFTW threaded transforms passed basic tests!
--------------------------------------------------------------

...followed by the same error as above.
It's fine.

6. Optional: Compile openblas using your new GCC
cd /share/apps/tools/gcc/binutils/bin
ln -s ar-gcc-4.7 gcc-ar

cd ~/tmp
wget http://nodeload.github.com/xianyi/OpenBLAS/tarball/v0.1.1
mv v0.1.1 openblas.tar.gz
tar xvf openblas.tar.gz
cd xianyi-OpenBLAS-e6e87a2/
wget http://www.netlib.org/lapack/lapack-3.4.1.tgz

export LD_LIBRARY_PATH=/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/tools/gcc/mpfr/lib

make all BINARY=64 CC=gcc-gcc-4.7 FC=gfortran-gcc-4.7 MPICC=mpicc-gcc-4.7 USE_THREAD=0 INTERFACE64=1 

make PREFIX=/share/apps/libs/openblas47 install

cp libopenblas_* /share/apps/libs/openblas47/lib
cd /share/apps/libs/openblas47/lib
ln -s libopenblas_nehalem-r0.1.1.so libopenblas.so.1
ln -s libopenblas.so.1 libopenblas.so
ln -s libopenblas.so libopenblas.so.0
ln -s libopenblas_nehalem-r0.1.1.a libopenblas.a

7. Compile Quantum Espresso using your new GCC
sudo mkdir /share/apps/QE
sudo chown $USER /share/apps/QE
mkdir /share/apps/QE/lapack-3.2

mkdir ~/tmp/QE
cd ~/tmp/QE

wget http://qe-forge.org/frs/download.php/211/espresso-5.0.tar.gz
wget http://qe-forge.org/frs/download.php/214/PWgui-5.0.tgz
wget http://qe-forge.org/frs/download.php/204/xspectra-5.0.tar.gz

Edit environmental_variables

PREFIX=/share/apps/QE
TMP_DIR=/tmp/QE
PARA_PREFIX="mpirun-gcc-4.7 -n 8"

Time to configure and compile:
cd ~/tmp/QE
tar xvf espresso-5.0.tar.gz
cd espresso-5.0/
cp lapack-3.2 -R /share/apps/QE/
cp BLAS -R /share/apps/QE/

Create a script called compile.sh:

make clean
export PATH=""
export PATH="/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/ecce/apps/scripts/share/apps/pvm/pvm3/bin/LINUX64:/share/apps/libs/openmpi47/bin:/share/apps/nwchem/nwchem-6.1/bin/LINUX64:/share/apps/sinfo/bin:/share/apps/sinfo/sbin:/share/apps/gromacs/bin:/share/apps/cmake/bin:/share/apps/tools/babel/bin:/share/apps/tools/htop/bin:/share/apps/tools/xmgrace/grace/bin:/share/apps/tools/rasmol/src:/share/apps/tools/strace/bin:/share/apps/tools/gcc/gcc47/bin:/share/apps/tools/gcc/binutils/bin"
which mpif90
read -p "press any key"
export CC=gcc-gcc-4.7
export FC=gfortran-gcc-4.7
export MPIF90=mpif90-gcc-4.7
export MPIF77=mpif77-gcc-4.7
export F77=gfortran-gcc-4.7
export F90=gfortran-gcc-4.7
export CPP=cpp-gcc-4.7
export CXX=g++-gcc-4.7
export CFLAGS=""
export DFLAGS="-DFFT_FFTW3"
export CPPFLAGS="-I/share/apps/tools/gcc/mpc/include -I/share/apps/tools/gcc/gmp/include -I/share/apps/tools/gcc/mpfr/include -I/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include -I/share/apps/libs/openmpi47/include -I//share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include"
export LDFLAGS="-L/share/apps/tools/gcc/gcc47/lib -L/share/apps/tools/gcc/gcc47/lib64 -L/share/apps/tools/gcc/gcc47/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/share/apps/tools/gcc/gmp/lib -L/share/apps/tools/gcc/mpc/lib -L/share/apps/tools/gcc/mpfr/lib -L/share/apps/libs/openmpi47/lib -L/lib64 -lc"
#export BLAS_LIBS="-L/share/apps/libs/openblas47/lib -lopenblas" 

export BLAS_LIBS="/share/apps/QE/BLAS/blas.a"
export LAPACK_LIBS="/share/apps/QE/lapack-3.2/lapack.a"
export FFT_LIBS="-L/share/apps/libs/fftw-3.3.2-gcc47/double/lib -lfftw3 -lfftw3_mpi -lfftw3_threads"
export MPI_LIBS="-L/share/apps/libs/openmpi47/lib -l:/share/apps/libs/openmpi47/lib/libmpi.so"
export LD_LIBRARY_PATH=/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpfr/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/libs/openmpi47/lib
./configure --prefix=/share/apps/QE/bin|tee conf.log
read -p "Press key to continue"

cd PW
make |tee make.log
cd ../
make all |tee makeall.log

Then run it using

sh compile.sh

Which gives:

--------------------------------------------------------------------
ESPRESSO can take advantage of several optimized numerical libraries
(essl, fftw, mkl...).  This configure script attempts to find them,
but may fail if they have been installed in non-standard locations.
If a required library is not found, the local copy will be compiled.

The following libraries have been found:
  BLAS_LIBS=/share/apps/QE/BLAS?blas.a
  LAPACK_LIBS=/share/apps/QE/lapack-3.2/lapack.a
  FFT_LIBS=-L/share/apps/libs/fftw-3.3.2-gcc47/double/lib -lfftw3 -lfftw3_mpi -lfftw3_threads
  MPI_LIBS=-L/share/apps/libs/openmpi47/lib -l:/share/apps/libs/openmpi47/lib/libmpi.so
Please check if this is what you expect.

If any libraries are missing, you may specify a list of directories
to search and retry, as follows:
  ./configure LIBDIRS="list of directories, separated by spaces"

Parallel environment detected successfully.\
Configured for compilation of parallel executables.

For more info, read the ESPRESSO User's Guide (Doc/users-guide.tex).
--------------------------------------------------------------------
configure: success

and more...Once it's over do

cd ~/tmp/QE/espresso-5.0
cp * -R /share/apps/QE/
echo 'export PATH=$PATH:/share/apps/QE/bin' >> ~/.bashrc
source ~/.bashrc

8. Testing PW -- STUCK
export LD_LIBRARY_PATH=/share/apps/tools/gcc/gmp/lib:/share/apps/tools/gcc/mpfr/lib:/share/apps/tools/gcc/mpc/lib:/share/apps/libs/openmpi47/lib:/share/apps/libs/openblas47/lib:/share/apps/tools/gcc/gcc47/lib64
cd /share/apps/QE/PW/examples/example02
./run_example

/share/apps/QE/PW/examples/example02 : starting

This example shows how to use pw.x to compute the equilibrium geometry
of a simple molecule, CO, and of an Al (001) slab.
In the latter case the relaxation is performed in two ways:
1) using the quasi-Newton BFGS algorithm
2) using a damped dynamics algorithm.

  executables directory: /share/apps/QE/bin
  pseudo directory:      /share/apps/QE/pseudo
  temporary directory:   /tmp/QE
  checking that needed directories and files exist...
Downloading O.pz-rrkjus.UPF to /share/apps/QE/pseudo...
Downloading C.pz-rrkjus.UPF to /share/apps/QE/pseudo... done

  running pw.x as: mpirun-gcc-4.7 -n 8  /share/apps/QE/bin/pw.x  

  cleaning /tmp/QE... done
  running the geometry relaxation for CO... from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
 from test_input_xml: Empty input file .. stopping
STOP 2
STOP 2
--------------------------------------------------------------------------
mpirun-gcc-4.7 noticed that the job aborted, but has no info as to the process
that caused that situation.
--------------------------------------------------------------------------
Error condition encountered during test: exit status = 2
Aborting

It's more insidious than that though -- pw.x crashes with "STOP 2" for any type of input.

NOTE: Like on Debian I had segfaults happening when using my own openblas (which works fine with gromacs and nwchem). Hence why I show you how to compile it, yet never use it.