577. Skype and webcam on debian wheezy: black screen

This is another shameless re-posting of a solution published by others. See e.g. 
http://community.skype.com/t5/Linux/Webcam-is-not-working-on-skype-with-Ubuntu-12-04/td-p/858418
https://bbs.archlinux.org/viewtopic.php?id=95388
http://ubuntuforums.org/showthread.php?t=966882

Why am I doing this? Mostly because this blog doubles as a notebook where I can write down solutions that worked for me so that I don't find myself scouring the internet over and over again for the same solution.

I hope that I'm adding a bit of value by providing step-by-step solutions and snazzy screenshots though.

The issue:
even though the camera is working fine there's only a completely black picture in skype (not underexposed -- just plain black):

The solution:
Use LD_PRELOAD to load the 32 bit V4L library (which you need to have installed -- use apt-file to find out what package). You can either start skype from the command line, or make changes to the launcher, either via main menu  as shown in the screenshot or by editing ~/.local/share/applications/skype.desktop i.e. run skype with 
env LD_PRELOAD="/usr/lib/i386-linux-gnu/libv4l/v4l1compat.so" skype

 At this point starting skype + webcam should be a happy marriage:

(aside from exposure, white balance etc. etc.)

123. Adding python support to nwchem under debian

I've posted the general build instructions for nwchem 6.0 with mpi support here: http://verahill.blogspot.com.au/2012/03/nwchem-60-with-openmpi-support-on.html

However, those instructions don't include python support.

0. Download,  extract nwchem and install blas etc. as shown in http://verahill.blogspot.com.au/2012/03/nwchem-60-with-openmpi-support-on.html

1. Edit nwchem-6.0/src/config/makefile.h
Change line 1962 from

EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl

to

EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl -lz -lssl

2. Install python headers
sudo apt-get install python2.7-dev

3. Execute the following commands (one by one or by putting them in a shell script)

export LARGE_FILES=TRUE
export TCGRSH=/usr/bin/ssh
export NWCHEM_TOP=`pwd`
export NWCHEM_TARGET=LINUX64
export NWCHEM_MODULES="all python"
export PYTHONHOME=/usr
export PYTHONVERSION=2.7
export USE_MPI=y
export USE_MPIF=y
export MPI_LOC=/usr/lib/openmpi/lib
export MPI_INCLUDE=/usr/lib/openmpi/include
export LIBRARY_PATH=$LIBRARY_PATH:/usr/lib/openmpi/lib
export LIBMPI="-lmpi -lopen-rte -lopen-pal -ldl -lmpi_f77 -lpthread"
cd $NWCHEM_TOP/src
make clean
make nwchem_config
make FC=gfortran

It should work fine and after a long build you'll have python enabled binaries.

4. Testing
You can test whether there's python support by creating test.nw with

python
for n in range(1,6):
        print n, n*2,n**2
end
task python

and running it with 

mpirun -n 1 nwchem test.nw

which gives

  NWChem Input Module
                                -------------------


                               NWChem Python program
                               ---------------------
for n in range(1,6):
        print n, n*2,n**2
1 2 1
2 4 4
3 6 9
4 8 16
5 10 25
1 2 1
2 4 4
3 6 9
4 8 16
5 10 25
 Task  times  cpu:        0.0s     wall:        0.0s

Done.


Note:
for ROCKS/CENTOS it was not necessary to edit src/config/makefile.h


The relevant parts in the the build configuration are

export NWCHEM_MODULES="all python"
export PYTHONHOME=/opt/rocks
export PYTHONVERSION=2.4

Other than that, just follow http://verahill.blogspot.com.au/2012/03/building-nwchem-60-on-rocks-543centos.html

---

Error:
gfortran: error: /usr/include/python2.7/lib/python2.7/config/libpython2.7.a: No such file or directory

make: *** [all] Error 1

locate libpython2.7.a

/usr/lib/libpython2.7.a

/usr/lib/python2.7/config/libpython2.7.a

Reason:
export PYTHONHOME=/usr/include/python2.7

Solution:
export PYTHONHOME=/usr

---

Error:

In function `PyZlib_compress':

(.text+0x1540): undefined reference to `deflateEnd'

Solution:
http://www.emsl.pnl.gov/docs/nwchem/nwchem-support/2012/02/0065.Re:_NWCHEM_undocumented_compilation_flag

Edit nwchem-6.0/src/config/makefile.h
For LINUX64 look at lines 1960-1964

1960      ifeq ($(BUILDING_PYTHON),python)
1961 #   EXTRA_LIBS += -ltk -ltcl -L/usr/X11R6/lib -lX11 -ldl
1962      EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl
1963   LDOPTIONS = -Wl,--export-dynamic
1964      endif

Change line 1962 to
EXTRA_LIBS +=    -lnwcutil  -lpthread -lutil -ldl -lz -lssl

80. Compiling octave 3.6.1 on Debian Testing

I originally was hesitant towards building my own packages, not so much because it is difficult (well-maintained packages are easy to build using configure/make), but because you can end up with a system where dependencies break and you constantly have to manually track new releases of packages you want.

Having had to struggle with outdated or bug-ridden debian packages during the past year has made me change my mind. It obviously depends on what you use you computer for -- the debian packages are supposed to be of high quality and they do unarguably go through a lot of stability testing before being released down the chain from SID to Stable. But I also get the impression that some debian maintainers aren't...well...maintaining their packages sufficiently.

Take the alt+f2 gnome bug for example -- in an ideal world a fix should've been rolled out within 24 hours, rather than just waiting for future version increments to take care of it. The gnuplot bug is another example. There's no solution in sight, even though it has been solved in upstream. Maybe there are reasons to which I'm oblivious for this, but the end result is that I'm a lot more cautious with trusting the debian vs upstreams maintainers now.

So, as part of the  series of science packages that you should compile yourself, here's Octave 3.6.1
At the moment of writing the versions in the deb repos are 3.4.2-8, 3.4.2-12 and 3.4.2-12+b1.

As an aside, if you know what you'll be doing with each software package, create a couple of test scripts so you can track regressions. That way you can be just a little bit more confident in the results you obtain -- if you publish incorrect data you will have to go through the humiliating experience of a retraction or correction.

In addition to everything listed below you need to have a working build environment  with a good fortran compiler.
sudo apt-get install gfortran build-essential 
at a minimum thus.

-- START HERE ---
sudo apt-get install libqhull-dev libpcre++-dev libblas-dev liblapack-dev libreadline-dev
sudo apt-get install libcurl4-openssl-dev libfltk1.3-dev libgraphicsmagick++-dev libhdf5-serial-dev libqrupdate-dev libsuitesparse-metis-dev glpk gperf flex bison libfontconfig1-dev
 wget ftp://ftp.gnu.org/gnu/octave/octave-3.6.1.tar.gz

tar -xvf octave-3.6.1.tar.gz
cd octave-3.6.1/
./configure

make -j4

where 4 is the number of cores +1 (for me 3 cores)

To validate your  compiled version, run
make check

Summary:
  PASS  10008
  FAIL      0
There were 2 expected failures (see fntests.log for details).
Expected failures are known bugs.  Please help improve Octave
by contributing fixes for them.

To install
either
sudo checkinstall
or
sudo make install
Done.

---

---

Error:

checking for qhull.h... no

configure: WARNING: Qhull library not found -- this will result in loss of functionality of some geometry functions.

Solution:

sudo apt-get libqhull-dev

---

Error:

checking pcre.h usability... no

checking pcre.h presence... no

checking for pcre.h... no

checking pcre/pcre.h usability... no

checking pcre/pcre.h presence... no

checking for pcre/pcre.h... no

checking whether pcre.h defines the macros we need... no

configure: error: to build Octave, you must have the PCRE library and header files installed

Solution:

sudo apt-get install libpcre++-dev

---

Error:

checking if sgemm_ is being linked in already... no

checking for ATL_xerbla in -latlas... no

checking for sgemm_ in -lblas... no

checking for sgemm_ in -lmkl... no

checking for sgemm_ in -framework vecLib... no

checking for sgemm_ in -lcxml... no

checking for sgemm_ in -ldxml... no

checking for sgemm_ in -lscs... no

checking for sgemm_ in -lcomplib.sgimath... no

checking for sgemm_ in -lblas... (cached) no

checking for sgemm_ in -lblas... (cached) no

configure: error: You are required to have BLAS and LAPACK libraries

Solution:

sudo apt-get install libblas-dev

(libopenblas-dev is still only in the unstable repo)

---

Error:

checking for cheev_... no
checking for cheev_ in -llapack... no
checking for cheev_ in -llapack_rs6k... no
configure: error: You are required to have BLAS and LAPACK libraries
Solution:
sudo apt-get install liblapack-dev

---

Error:

configure: WARNING: I need GNU Readline 4.2 or later

configure: error: this is fatal unless you specify --disable-readline

Solution:

sudo apt-get install libreadline-dev

---

Error:

configure: WARNING: I didn't find gperf, but it's only a problem if you need to reconstruct oct-gperf.h
configure: WARNING: UMFPACK not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: qrupdate not found.  The QR & Cholesky updating functions will be slow.
configure: WARNING: AMD library not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: COLAMD library not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: CCOLAMD library not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: CHOLMOD library not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: CXSparse library not found.  This will result in some lack of functionality for sparse matrices.
configure: WARNING: cURL library not found.  The ftp objects, urlread and urlwrite functions will be disabled.
configure: WARNING: GLPK library not found.  The glpk function for solving linear programs will be disabled.
configure: WARNING: GraphicsMagick++ library not found.  The imread function for reading image files will not be fully functional.
configure: WARNING: HDF5 library not found.  Octave will not be able to save or load HDF5 data files.
configure: WARNING: FLTK config script not found.  Native graphics will be disabled.
configure: WARNING: 
configure: WARNING: I didn't find the necessary libraries to compile native
configure: WARNING: graphics.  It isn't necessary to have native graphics,
configure: WARNING: but you will need to have gnuplot installed or you won't
configure: WARNING: be able to use any of Octave's plotting commands
configure: WARNING: 
configure: 
configure: NOTE: libraries may be skipped if a library is not found OR
configure: NOTE: if the library on your system is missing required features.

Solution:

First, make a few decisions:

Package libhdf5-dev is a virtual package provided by:
  libhdf5-serial-dev 1.8.4-patch1-3
  libhdf5-openmpi-dev 1.8.4-patch1-3
  libhdf5-mpich-dev 1.8.4-patch1-3
  libhdf5-lam-dev 1.8.4-patch1-3
You should explicitly select one to install.

Package libcurl-dev is a virtual package provided by:
  libcurl4-openssl-dev 7.24.0-1
  libcurl4-nss-dev 7.24.0-1
  libcurl4-gnutls-dev 7.24.0-1
You should explicitly select one to install.

Package libfltk-dev is a virtual package provided by:
  libfltk1.3-dev 1.3.0-5
  libfltk1.1-dev 1.1.10-10
You should explicitly select one to install.

Package libumfpack4-dev is a virtual package provided by:
  libsuitesparse-metis-dev 3.1.0-2
  libsuitesparse-dev 1:3.4.0-2
You should explicitly select one to install.

I chose thusly:

sudo apt-get install libcurl4-openssl-dev libfltk1.3-dev libgraphicsmagick++-dev libhdf5-serial-dev libqrupdate-dev libsuitesparse-metis-dev

The following errors/mesages remain:

  Do internal array bounds checking:  false
  Use octave_allocator:               false
  Build static libraries:             false
  Build shared libraries:             true
  Dynamic Linking:                    true (dlopen)
  Include support for GNU readline:   true
  64-bit array dims and indexing:     false

configure: WARNING: I didn't find gperf, but it's only a problem if you need to reconstruct oct-gperf.h
configure: WARNING: GLPK library not found.  The glpk function for solving linear programs will be disabled.
configure: 
configure: NOTE: libraries may be skipped if a library is not found OR
configure: NOTE: if the library on your system is missing required features.

The 64 bit issue can probably  be solved using ./configure --enable-64 BUT requires BLAS that is compatible with 64 bit integers.

---

Links to this page:
http://tata-box-blog.blogspot.nl/2012/04/install-octave-361-in-debian-squeeze.html
http://askubuntu.com/questions/124731/when-will-octave-3-6-1-be-available-to-be-installed

79. Bankid/nexus personal and iceweasel on Debian Testing

Update 19 Feb. 2013:
Here's an updated post: http://verahill.blogspot.com.au/2013/02/341-upgradinginstalling-bankid-on-64.html -- see that one instead, in particularly if you're upgrading.

Note that you may have to compile your own nspluginwrapper:
http://verahill.blogspot.com.au/2013/03/366-nspluginwrapper-on-debian.html

and you will need to enable multiarch to install ia32-libs:

sudo dpkg --add-architecture i386
sudo apt-get update

Original post:
Swedish banks and government institutions use bankid/nexus personal for electronic id verification. Sadly, it's a horrible solution -- it seems to be closed source, the bankid website is a POS which prevents me from downloading the 64 bit version claiming that it's not supported (I've used it for a few years now, so it's clearly bunkum).

Note that there's a FOSS alternative in Fribid (http://verahill.blogspot.se/2012/02/debian-testing-wheezy-64-fribid-as.html) which seems to be working perfectly -- and if you can use it, use it. The main limitation is that in practice you'll have to collect your certificate/ID with it, since newer versions of BankID saves the ID in an incompatible format. Like many foreigners, I don't have the opportunity to visit Sweden for the sole sake of picking up a new ID, so I'm stuck with BankID. But you may not be.

* A Swedish how-to is available here: http://ubuntu-se.org/wiki/NexusPersonal#Installation_p.C3.A5_64-bitarssystem

* Another, more recent how-to is here: http://popqvarnstrom.blogspot.com.au/2011/06/bankid-nexus-personal-on-ubuntu-1104-64.html

Note: I have never 'exported' my ID, but have always copied the ~/.personal directory between computers. The problem with exporting is that you are only allowed to do it once. The problem with Nexus allowing your to copy the file itself is that anyone with physical access to your computer can copy the key.

--START HERE --
 Here's a summary of how to get it working on debian testing wheezy:

In theory you should install nexus personal from here:
https://install.bankid.com/

I've got v 4.17.0.11 installed on a 64 bit system. The message on this page is a load of bollocks:

Whatever -- the good guys over at Arch supply a link:
wget http://install.bankid.com/Repository/BISP-4.19.0.11351.tar.gz

EDIT: you can use this generic url instead  https://install.bankid.com/Download?defaultFileId=Linux

tar -xvf  BISP-4.19.0.11351.tar.gz
cd  BISP-4.19.0.11351
 sudo sh install.4.19.0.11351.sh i

 Installing BankID Security Application
ln: failed to create symbolic link `/usr/lib/firefox-addons/plugins': No such file or directory
WARNING: Failed installing plugin for Firefox 3. Manually add symlink to libplugins.so in your Firefox 3 plugin directory if this browser is to be used.
Installation complete.

Since the plugin is 32 bit, you need to link it with nspluginwrapper, and you need 32 bit libs, so

sudo apt-get install nspluginwrapper ia32-libs



Also, as far as I can tell, you need iceweasel/firefox. Chrome/ium won't work.

sudo nspluginwrapper -i /usr/local/lib/personal/libplugins.so  

Check to see if it's installed:
nspluginwrapper -l

 /usr/lib/mozilla/plugins/npwrapper.libplugins.so 
 Original plugin: /usr/local/lib/personal/libplugins.so 
Plugin viewer: /usr/lib/nspluginwrapper/i386/linux/npviewer
Wrapper version string: 1.3.0  

And visit  the following page to make sure
 https://test.bankid.com/
Or your bank.

---

Your  key -- on a computer where you've used bankid before -- will be in ~/.personal -- don't bother trying to import or export it using the bankid/nexus personal programme (http://popqvarnstrom.blogspot.com.au/2011/06/bankid-nexus-personal-on-ubuntu-1104-64.html) since you're apparently only allowed to do that a certain number of times.

If you just plain copy the files, however, you can do it as many times as you want. I told you the programme is a POS. Anyway,

tree .personal
.personal
|-- backup
|   |-- config
|   |   `-- Personal.cfg
|   `-- store
|-- config
|   `-- Personal.cfg
`-- store
    |-- 1.ngp
    `-- 2.ngp

Nexus Personal/BankID is installed in /usr/local/lib/personal/

---

Links to this page:
http://popqvarnstrom.blogspot.se/2011/06/bankid-nexus-personal-on-ubuntu-1104-64.html

77. Compiling Wine 1.4-rc4 and wine 1.4-rc5 on debian testing

UPDATE 16 May 2013: See here for Wine 1.5.30: http://verahill.blogspot.com.au/2013/05/416-wine-1530-in-chroot.html

A more exhaustive description of installing wine in general is here: http://verahill.blogspot.com.au/2012/01/debian-testingwheezy-64-bit-installing.html

I'm not a fan of running windows programmes on linux -- there are enough high-quality packages out there for linux to last you a life-time, and no matter how good wine is¸ the experience of running a windows program on linux is likely to be worse (if faster) than running it natively.

But like most people I'm help prisoner by my fellow co-workers who insists on dog+world using MS Office etc. Also, in spite of everything there are a few pieces of specialised software which lack linux equivalents.

UPDATE (10th Jan 2013): See here for Wine 1.5.21 using the multiarch approach: http://verahill.blogspot.com.au/2013/01/308-compiling-wine-1521-on-debian.html

Finally, from the point of view of easing new users off of windows and onto a real OS, wine and virtualbox fill important functions. I was myself a heavy user of both in the beginning, before learning how to use gnuplot, latex etc.

JPEG support is a PITA, but possible -- see below.

opencl -dev and lib32opencl1 require the contrib non-free repos, e.g.

deb ftp://ftp.au.debian.org/debian/ testing main contrib non-free

Updated: I've tried the same guide on wine 1.4-rc5

--- START HERE ---
With that out of the way, here's building wine 1.4-rc4

First, you need a whole lot of packages -- these will be installed if you've previously compiled wine according to this:

sudo apt-get install bison flex gcc libc6-dev libfontconfig-dev libfreetype6-dev libglu-dev libgsm1-dev libice-dev libjpeg-dev libldap-dev libmpg123-dev libncurses5-dev libopenal-dev libpng-dev libsm-dev libssl-dev libusb-dev libx11-dev libxcomposite-dev libxcursor-dev libxext-dev libxi-dev libxinerama-dev libxml2-dev libxrandr-dev libxrender-dev libxslt-dev libxt-dev libxxf86vm-dev make libcapi20-dev liblcms-dev libsane-dev libhal-dev libdbus-1-dev valgrind prelink libcups2-dev opencl-dev lib32opencl1 oss4-dev gettext

sudo apt-get install lib32v4l-dev lib32ncurses5-dev lib32asound2-dev lib32z-dev ia32-libs-dev

To enable jpeg support you are SUPPOSED TO:
First, remove existing symlinks
sudo rm /usr/lib32/libjpeg.so.62 /usr/lib32/libjpeg.so.62.0.0
Then, create new ones
sudo ln -s /usr/lib32/libjpeg.so.8 /usr/lib32/libjpeg.so.62
sudo ln -s /usr/lib32/libjpeg.so.8 /usr/lib32/libjpeg.so.62.0.0

Download the sources and expand:
wget http://prdownloads.sourceforge.net/wine/wine-1.4-rc4.tar.bz2
bzip2 -d wine-1.4-rc4.tar.bz2
tar -xvf wine-1.4-rc4.tar
./configure

If you get errors, see below and here for solutions. Missing libraries are often ok -- it just means certain functionality will be missing. It's up to you what is important. If you followed the instructions above you'll have jpeg support in spite of what configure spits out.

make -j7

as usual 7 is the number of cores +1. If you have a dual core, replace 7 with 3. Parallel building is sometimes much, much faster than just using one core, sometimes not.
If you already have a version of wine installed, this is a good time to uninstall it. Then,

sudo checkinstall

builds a .deb package and installs it. It's useful if you need to uninstall in the future.

The

Copying documentation directory...
./
./VERSION
./AUTHORS
./LICENSE
./README
./ANNOUNCE
./COPYING.LIB

part takes forever. It will finish in about ten minutes or so. If the building of the debian package fails, make sure you set the version number correctly (see errors below).


aptitude show wine-1.4

Package: wine-1.4                      
New: yes
State: installed
Automatically installed: no
Version: 1.4-rc4-1
Priority: extra
Section: checkinstall
Maintainer: root@beryllium
Uncompressed Size: 129 M
Description: Wine 1.4-rc4

Done.

Updated 02/03/2012:

For Wine1.4-rc5:
 wget http://sourceforge.net/projects/wine/files/Source/wine-1.4-rc5.tar.bz2

tar -xvf wine-1.4-rc5.tar.bz2

cd wine-1.4-rc5/

./configure

gstreamer, libgsm, libtiff, libjpeg warnings. You can ignore them.
make
sudo checkinstall

---

---

List of errors:

Error:
configure: OpenCL 32-bit development files not found, OpenCL won't be supported.

Solution:
sudo apt-get install lib32opencl1 opencl-dev

---

Error:
configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled
No solution:
Not the only one with this problem...I don't care enough about video to follow this up any more. Likely, an approach similar to this will work: http://forum.winehq.org/viewtopic.php?t=5797&sid=afde9de83a98b8cb24df2bb3646930b6

---

Error:
configure: OSS sound system found but too old (OSSv4 needed), OSS won't be supported.

Solution:
 sudo apt-get install oss4-dev

---

Error:
configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported.
Solution, maybe:
I don't care too much,  but there are solutions if you are desperate enough: http://forum.winehq.org/viewtopic.php?t=5797&sid=afde9de83a98b8cb24df2bb3646930b6

---

Error:

configure: libtiff 32-bit development files not found, TIFF won't be supported.

No soution:

This comes up on some boxes, but not others. Comparing the installed packages I have no idea why.

aptitude search tiff|grep dev

v   libtiff-dev                     -                                        
i A libtiff4-dev                    - Tag Image File Format (TIFF) library (old
p   libtiff5-dev                    - Tag Image File Format library (TIFF), deve

ls /usr/lib32/libtiff* -lah

 /usr/lib32/libtiff.a

 /usr/lib32/libtiff.la

 /usr/lib32/libtiff.so -> libtiff.so.4.3.3

/usr/lib32/libtiff.so.4 -> libtiff.so.4.3.3

 /usr/lib32/libtiff.so.4.3.3

 /usr/lib32/libtiffxx.a

 /usr/lib32/libtiffxx.la

 /usr/lib32/libtiffxx.so -> libtiffxx.so.0.0.7

---

Error:

configure: WARNING: gettext tools not found, translations won't be built.
Solution:
sudo apt-get install gettext

---

Error:
configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported.

Solution:
First, install
sudo apt-get install libjpeg8-dev

This pointed me here.

Here's how to check for the bug
 locate libjpeg | grep 32

/usr/lib32/libjpeg.a
/usr/lib32/libjpeg.la
/usr/lib32/libjpeg.so
/usr/lib32/libjpeg.so.62
/usr/lib32/libjpeg.so.62.0.0
/usr/lib32/libjpeg.so.8
/usr/lib32/libjpeg.so.8.0.2

ls /usr/lib32/libjpeg.* -lah

 /usr/lib32/libjpeg.a

/usr/lib32/libjpeg.la

/usr/lib32/libjpeg.so -> libjpeg.so.62.0.0

/usr/lib32/libjpeg.so.62 -> libjpeg.so.62.0.0

/usr/lib32/libjpeg.so.62.0.0

 /usr/lib32/libjpeg.so.8 -> libjpeg.so.8.0.2

 /usr/lib32/libjpeg.so.8.0.2

Yup, libjpeg.so points to v 6.2 instead of v 8 which I have installed.

According to the bug report, the cause of the error is that the header file jpeglib.h states one version, and the /usr/lib32/libjpeg.so points to another:

cat /usr/include/jpeglib.h|grep "LIB_VERSION"| grep define

#define JPEG_LIB_VERSION        80 /* Compatibility version 8.0 */
#define JPEG_LIB_VERSION_MAJOR  8
#define JPEG_LIB_VERSION_MINOR  4

FIX:

Remove existing symlinks

sudo rm /usr/lib32/libjpeg.so.62 /usr/lib32/libjpeg.so.62.0.0

Create new ones

sudo ln -s /usr/lib32/libjpeg.so.8 /usr/lib32/libjpeg.so.62

sudo ln -s /usr/lib32/libjpeg.so.8 /usr/lib32/libjpeg.so.62.0.0

ls /usr/lib32/libjpeg.* -lah now gives

 /usr/lib32/libjpeg.a

 /usr/lib32/libjpeg.la

/usr/lib32/libjpeg.so -> libjpeg.so.62.0.0

 /usr/lib32/libjpeg.so.62 -> /usr/lib32/libjpeg.so.8

 /usr/lib32/libjpeg.so.62.0.0 -> /usr/lib32/libjpeg.so.8

/usr/lib32/libjpeg.so.8 -> libjpeg.so.8.0.2

/usr/lib32/libjpeg.so.8.0.2

The error message remains on ./configure, but jpeg support is /supposed/ to work in spite of this.

---

Error:

Building Debian package... FAILED!
*** Failed to build the package
Do you want to see the log file?  [y]:
dpkg-deb: error: parsing file '/var/tmp/tmp.Y50XUaisW0/package/DEBIAN/control' near line 7 package 'wine-1.4':  error in Version string 'rc4-1': version number does not start with digit

Solution:

sudo checkinstall

This package will be built according to these values:
0 -  Maintainer: [ root@beryllium ]
1 -  Summary: [ Wine 1.4-rc4 ]
2 -  Name:    [ wine-1.4 ]
3 -  Version: [ rc4 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ wine-1.4-rc4 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ wine-1.4 ]
12 - Conflicts: [  ]
13 - Replaces: [  ]
Enter a number to change any of them or press ENTER to continue: 3
Enter new version:
>> 1.4-rc4

58. Higher resolution on a Dell E177FPb monitor using modelines in xorg.conf on Debian Testing

Update 24 May 2013: this still works fine on the optiplex (with intel onboard graphics) but when trying it on a different machine with an external nvidia card I couldn't get it to work. There only "xrandr --output VGA-0 --scale 1.1x1.1" worked.

Original post:
I've hooked up my fancy new-ish optiplex 990 to an old Dell E177FPb monitor which I bought back in 2007. For various reasons I've also removed the nvidia quattro graphics card that the optiplex 990 came with -- the main reasons being 1) I hate displayport and _need_ vga and 2) the bios forces you to press 'any key' on each boot if you leave the card in, even though you've configured the OS to use the integrated onboard graphics.

At any rate, hooking my old screen to my dell lead to a less than overwhelming experience -- and querying the 'Displays' setting in gnome showed only two resolution options: 1024x768 and 800x600. Well, I knew for a fact that the maximum resolution should be 1280x1024.

This was a bit of a surprise given that the same xorg.conf had been used together with a fancy widescreen 1920x1080 display -- yet it would not handle a 1280x1024 display? I guess this might say more about my lack of understanding how display drivers work, but whatever.

Well, in the end it turned out to be easy to enable the missing resolution mode.

First, a minimal amount of googling told me that the max resolution was 1280x1024 at 75 Hz.
"Preset Resolution: 1280 x 1024 @ 75 Hz"

Next, using gtf I generated a Modeline line.

gtf 1280 1024 75

Modeline     "1280x1024_75.00" 138.54 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync

Finally, I then edited the xorg.conf (again, see this post for the entire xorg.conf), changing

Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName    "Monitor Model"
EndSection

to

Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName    "Monitor Model"
Modeline     "1280x1024_75.00" 138.54 1280 1368 1504 1728 1024 1025 1028 1069 -HSync +Vsync
EndSection

Doing startx to start up gnome, followed by selecting Displays, then selecting Resolution: 1280x1024 (5:4) yielded a beautifully satisfying  user experience.

I'm not one to fiddle with xorg.conf, but this time it turned out that the fix was easy once I had figured out what to do.

49. Gromacs -- hangs on multicore when doing normal mode analysis

Symptom:
when doing
mdrun -s nm.tpr -mtx nm.mtx -v -deffnm nm
on a system with 637 atoms you end up with:

...Finish step 636 out of 637

and it hangs there with all cores running at 100%

Reason:
For some reason the normal mode analysis of at least this particular system won't run on multiple cores.

Solution:
Use an mpi compiled version of mdrun (see previous posts on compiling _dd, _mpi and _ddmpi versions of gromacs) and force the use of ONE core.

mpd --ncpus=4 &
mpdrun -n 1 mdrun_mpi -s nm.tpr -mtx nm.mtx -v -deffm nm

works!

Confirmation
This was confimed by running it on four computers:
64 bit: a six core AMD 64 using a compiled version of gromacs. Hangs.
64 bit: a four core intel i5 using both the debian version and a compiled version of gromacs. Hangs.
64 bit: an older four core intel using a compiled version of gromacs. Hangs.
32 bit: an old single-core laptop using the debian version of gromacs. Works.

Next, three single-core virtual machines were set up -- a stable 32 bit, a testing 32 bit and a testing 64 bit machine, all with the debian version of gromacs (sudo apt-get install gromac). They all worked, as they only had a single core.