32. Apt-pinning in Debian -- simple example

---------------------------------------------------------
Summary:
* create an /etc/apt/preferences files
* add the repos to /etc/apt/sources.list
* put a hold on packages if downgraded
---------------------------------------------------------


I'm not an expert at this. However, I managed to get apt-pinning to work using this approach. I wish I had a better grasp of how .d directories work, but I don't, which is why a monolithic /etc/apt/preferences files is used

Anyway, apt-pinning is an interesting approach to having a system in which some packages are pulled from stable, some from testing and some from unstable. For example, if the Evolution version in stable is missing what you consider critical functionality, and a better version is present in the testing repos, you can install the testing version of Evolution, while still running a mainly stable version of debian. In other words, apt-pinning allows you to pull single packages from other debian releases.

You need to add the repos to your /etc/apt/sources.list
e.g.

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

You also need to create a file called /etc/apt/preferences
e.g.

Package: *
Pin: release a=testing
Pin-Priority: 990

Package: *
Pin: release a=unstable
Pin-Priority: -10

Package: *
Pin: release a=stable
Pin-Priority: -10

The example preferences file prioritises testing over unstable and stable. Default apt behaviour is to use the highest version and revision of each package is there are several alternatives i.e. without /etc/apt/preferences you will end up with the unstable/sid release. The Pin-Priority values are a science onto themselves.

Here's what
 man apt_preferences
 says:


P > 1000
           causes a version to be installed even if this constitutes a downgrade of the package

       990 < P <=1000
           causes a version to be installed even if it does not come from the target release, unless the installed version is more recent

       500 < P <=990
           causes a version to be installed unless there is a version available belonging to the target release or the installed version is more recent

       100 < P <=500
           causes a version to be installed unless there is a version available belonging to some other distribution or the installed version is more recent

       0 < P <=100
           causes a version to be installed only if there is no installed version of the package

       P < 0
           prevents the version from being installed

I think negative values for the unwanted releases is a good place to start, or you may start automatically pulling over packages that depend on the one package which you want.

A way to see if it's working is to (for the package Evolution)
apt-cache showpkg evolution

Package: evolution
Versions: 
3.0.3-3+b1 (/var/lib/apt/lists/ftp.au.debian.org_debian_dists_unstable_main_binary-amd64_Packages)
..
3.0.3-3 (/var/lib/apt/lists/ftp.au.debian.org_debian_dists_testing_main_binary-amd64_Packages)
..
2.30.3-5 (/var/lib/apt/lists/ftp.au.debian.org_debian_dists_stable_main_binary-amd64_Packages)
..

..

Provides: 
3.0.3-3+b1 - mail-reader imap-client 
3.0.3-3 - mail-reader imap-client 
2.30.3-5 - mail-reader imap-client 


Basically, it returns the different versions in the different release repos.

I've already described how to put a hold on a package so that it won't be upgraded, but here it is again (using the mpich2 package as an example):

sudo su
echo "mpich2 hold" | dpkg --set-selections

31. Update flash -- chrome on debian wheezy/testing 64 bit

You may have had problems playing flash videos recently and have been presented with a message saying that your player is out of date, and that you can either play (just this time) or upgrade. Clicking on upgrade takes you to the adobe website -- downloading the file is easy enough, but then what?

Well, here's how to upgrade.
Download the file install_flash_player_11_linux.x86_64.tar.gz
extract the libflashplayer.so file from the root of the compressed file

Figure out what files to replace:

locate libflashplayer.so
yields
/usr/lib/chromium-browser/plugins/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so

So, in the directory where you put your new libflashplayer.so
sudo cp libflashplayer.so usr/lib/chromium-browser/plugins/libflashplayer.so
and
sudo cp libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so


Restart your browser, and you should be good to go.

30. "Bench-marking" nwchem with mpich2 on debian wheezy

For various reasons my beowulf has been dismantled and in boxes for most of the year, with only the six-core node seeing use a normal work computer.

Anyhow, here's a very unscientific test of the performance of my six-core (phenom II, 2.8 GHz, 8Gb RAM) running the nwchem code compiled in the previous post.

The speed-tests were performed by starting up mpd
mpd --ncpus=6&
and then executing with
time mpdrun -n x ./nwchem input.nw
where x is an integer signifying the number of cores

The nwchem.nw files I used was

nwchem.nw
start benzene 

geometry units angstroms
C  0.100  1.396  0.000
C  1.209  0.698  0.000
C  1.209 -0.698  0.000
C  0.000 -1.396  0.000
C -1.209 -0.698  0.000
C -1.209  0.698  0.000
H  0.000  2.479  0.000
H  2.147  1.240  0.000
H  2.147 -1.240  0.000
H  0.000 -2.479  0.000
H -2.147 -1.240  0.000
H -2.147  1.240  0.000
end
basis
 H library sto-3g
 c library sto-3g
end
dft
    xc b3lyp
end
task dft optimize

Here are the results:

(x is number of cores; times in seconds)
x   Run 1   Run 2    Run 3   Run 4   Run 5
1* 40.8     37.9     40.7     40.3      39.9
1   22.2     40.7      40.6    44.8      38.2
2   22.8     22.4     16.3     23.5       21.5
3   14.1     12.3     15.7     15.5       15.1
4   14.5     11.5     12.0     14.9       14.7
5   11.4     11.5     8.9       11.9       12.5
6   16.0     12.2     13.4     9.9        9.6

* No mpd running; executed using time nwchem nwchem.nw



So here's the unscientific part -- the computer is running a full desktop environment with evolution, chrome etc open in the background so that each run sees a slightly different system. I've tried to vary the order in which the runs were made though.

 A guess would be that a longer run would yield more reproducible results. As it is now, the length of the runs vary significantly. The only lesson that can be obtained is that it doesn't help much throwing more cores at a problem as the optimisation times only drop off slowly past a certain point.

Edit: I've run the same file using an almost identical set-up on two more boxes
Don't compare the benchmarks when running at maximum numbers of cpu, since this will be heavily affected by other processes.

Optiplex 990 (Intel i5 2400, 4 cores @ 3.1 GHz, 8 Gb RAM)

x   Run 1   Run 2    Run 3   Run 4   Run 5
1   45.80   46.97  46.56   46.95   39.01
2   22.77  25.81   26.93  26.61   25.81
3   17.18  16.48   18.89  19.26  19.18
4   11.62  16.62   15.82  15.86   16.03

Homebuilt (3 core AMD Athlon 2 X3 @ 3.1 GHz, 4 Gb RAM)

x   Run 1   Run 2    Run 3   Run 4   Run 5   Run 6   Run 7
1   43.74   57.02   40.22   47.89   53.87
2   31.41   22.31   25.83   32.31   33.00
3   36.19   31.01   43.55   24.75   37.82   33.95   27.06