Packages for an Arch Linux System

(My Own Preferences)

image link-topic-sf0.jpg

1. Introduction

Everyone's idea of a set of packages for a system will differ, of course. Indeed, even for one person the set of packages for different machines will vary. These are just a few notes to remind me which packages I tend to want to install. It may be of use/interest to you; it may not. The whole point of Arch Linux is that you can roll your own.

I'll also include a few configuration notes for particular packages (e.g., how to turn of the annoying URL suggestions in new tabs in Firefox).

For Arch Linux, packages generally fall into three categories:

To find out if a regular or AUR package is installed on your system, query the local pacman database for a part of its name. For example:

 
pacman -Qs ttf-linux-libertine 

To discover a regular or AUR package, I find it easiest just to google on "arch linux PACKAGENAME". For example:

 
arch linux vim 

to find the Arch Linux page for the package for the vim editor.

There is a nice overview of available applications at: Arch Linux List of Applications. It isn't exhaustive (or intended to be so), but it's a good start if you want to see the range of what is available.

It doesn't hurt to (re)install a package over itself in Arch Linux.

2. Packages We Have Already

After the basic build and the first round of configuration, we'll already have the basic system (obviously) and also:

3. Regular Arch Linux Packages

3.1. Basic Operation and Maintenance

The package "base-devel", which provides the basic tools for Arch Linux PKGBUILDs, should be installed using the "--needed" parameter so as to pull in all required tools.

 
sudo pacman -S --needed base-devel 

Each of the rest of these can be installed via pacman -S as usual. Example:

 
sudo pacman -S vim 

Here's a short list of the basic system maintenance packages (in addition to those already installed) that I can't live without:

vi/vim: The base system comes with a "classic" version of the vi editor (Gunnar Ritter's port of the old vi code; see http://ex-vi.sourceforge.net/), but I find that vim is sufficiently nicer to warrant its use. After installation, in your .bashrc, add:

 
alias vi='vim' 

In any case, you probably want vim because the classic vi in Arch Linux ships with a bug which causes nmh to fail. (You are using nmh for e-mail, right?) Alternatively, you can wrap the classic vi in a bash script to circumvent this. Note, however, that in your ~/.mh_profile file you must call out /usr/bin/vim explicitly, because in a non-interactive shell the alias of vi to vim won't take effect. See ../ Mail with nmh --> The ~/.mh_profile Configuration File and ../ Miscellaneous Application Notes --> "Classic" vi and Its nmh Interactions.

3.2. Basic Graphics/Office/Media (but no CAD)

Each of these can be installed via pacman -S.

mupdf is a lightweight PDF viewer. It has a lot to recommend it, but you do still need a "heavyweight" PDF viewer because mupdf has some curious limits for scaling documents, and takes the PDF standard very literally.

For a "heavyweight" PDF viewer, the choices are now limited. Adobe has discontinued Linux support for "acroread" at a 32-bit backlevel version. It was once the reader of choice, but is now no longer viable. At present, I'm using KDE's "okular," but it is very heavy and by no means elegant. It's best to install vlc before okular so that the kdegraphics-okular package can pick up phonon-vlc.

(Notes: The foxit PDF reader is closed source, 32-bit only, and fails to install its own add-ons. Regrettably, kdegraphics-okular does pull in nepomuk and strigi, but it doesn't seem to run them, so that's ok.)

geeqie is the current revision of the old gqview. It's generally the nicest image viewer I've found (but of course this is very much a matter of opinion).

vlc is far better than any other moving picture viewer (and its "libdvdcss" is not the same as the legally challenged "DeCSS"). You need these three libs to view the DVDs you have purchased.

In my opinion, vlc also makes a nicer audio control program than any of the dedicated audio programs. They all try to lock you into a particular system of playlists. vlc plays audio just fine, and you can use the filesystem as your playlist.

vlc will also work for USB cameras and "USB microscopes" (which are basically tethered USB cameras with a different lens). I haven't yet figured out how to set the image size using for a USB camera using vlc, though, so for the moment I'm still using guvcview (see below).

Any audio mixer that works with your hardware should work. FVWM doesn't have a mixer of its own. I list the xfce4-mixer package here (the ALSA mixer for the Xfce4 desktop) because it works under FVWM and happens to work with my hardware.

The GIMP has issues as of 2.8. See Basic Principles: Avoiding Hubris (GIMP 2.8).

See also ../ Basic Principles: The CWD and GTK for the procedure to fix GTK's configuration so as to make the GIMP even minimally useful.

xlsfonts is a very simple program which lists all available fonts installed on a system.

Linux Libertine is one of the better open source digital typeface families.

The inkscape package also picks up the exceedingly useful imagemagick package in its dependencies.

To discover where the CWD went in Inkscape even though you set GTK FileChooser to open the CWD, see ../ Basic Principles: The CWD and GTK -> ../ A Hiccup.

LibreOffice is self-explanatory nowdays. It is heavyweight, though. For older hardware or special purposes I might stick to vi and gnumeric instead.

3.3. Net/Web

The situation for Linux and simple web browsing is getting worse, not better. This is not good.

Each of these can be installed via pacman -S.

This must be installed via the AUR

Midori is lightweight, and looks very promising. I've used it a bit on some of my older, smaller systems which couldn't handle things at the Firefox/Chrome level of bloat. Unfortunately, at least Midori 0.5.8 is unstable. It crashes randomly every few minutes, and crashes reliably every time you try to save a file. If Midori were to become stable, it would be a good choice.

The flash plugin for Midori is in AUR, and doesn't work on 32-bit.

So what browser can you use? For years I used Firefox, but as described below, I have abandoned it because it's performance has degraded to the point of unusability . I tried Midori, but as noted above, it is not yet stable enough to work for more than a few minutes in the real world. So, with regrets, I'm using Google's Chrome.

Chrome (the Google-licensed product, not Chromium), in Arch Linux, installs via the AUR. So far, it seems to consume about 10% of my CPU when just sitting there doing nothing with a few windows and tabs open (that's pretty good in these days of diminished expectations) and rarely goes much about 60% when busy.

Chrome is far from perfect, and seems to be suffering as all other software is now from a high-handed approach where useful features are taken away because they do not comply with the religious convictions of the code's owners. The most annoying of these is the now-enforced behavior on the opening of a new tab.

Chrome opens each new tab with a fixed content: (1) a Google search prompt, and (2) a list of recently visited pages. The first of these is merely annoying. The second is a privacy violation. You cannot configure proper behavior via Chrome itself (they took that feature out). To fix this, install the "New Tab Redirect" extension of Jim Schubert. (See also his page for it: https://github.com/jimschubert/newtab-redirect.) This allows you to specify exactly what Chrome should do when opening a new tab. (I have it open my home page.)

Chrome also defaults to using its built-in PDF viewer for all PDFs. You can disable this by entering the fake URL: "about:plugins" and clicking to disable the Chrome PDF viewer. I'm told that if you have another viewer installed as a plugin, then it will default to that viewer. But I'm only aware of the Adobe plugin, and the Adobe PDF viewer for Linux is no longer a useful product. I don't know of any way to enable either okular or mupdf. So for now I just disable the internal PDF viewer and let Chrome save the file to disk (where it can be viewed with a proper PDF viewer such as mupdf).

[Note to self: Take a look in the future at Vimprobable/vimperator, UZBL-Browser, Jumanji, & Luakit.]

For an index of Arch Linux browser-related topics, see: https://wiki.archlinux.org/index.php/Category:Web_Browser

rfkill allows you to turn of a wireless network interface (rather than just deconfiguring the network using it); this can be useful for going into "airplane mode." See Miscellaneous Arch Linux Notes -> Forcing the Wireless Network Down ("Airplane Mode").

3.4. Firefox

Firefox deserves a separate section - but unfortunately this section is primarily a memorial to a formerly great application.

As of 2014-05-26, I've finally given up on Firefox; this is a sad moment, since I've been using it and its predecessors for many years. But Firefox has one or more deeply embedded bad bugs which cause scripts on many websites to run uncontrollably. Even with a clean, new install of Firefox 29, in short order it is consuming 80+ of the CPU ordinarily and well over 100% (on a multi-core system) in many cases. It's bad enough that cursor movement becomes jerky. If you search around, these problems have been reported for years, but the FF developers just deny them. Unfortunately, they've now caused performance to degrade to an unusable level. I've tried it on several different systems, through several different releases. The runaway script bugs and consequent performance disasters are just getting worse and worse.

I'll leave these Firefox installation/configuration notes here, but they are no longer useful. Firefox must fix itself before you can fix it.

Firefox is comprehensive, but increasingly bloated. Unfortunately, as installed it also has several really annoying configuration bugs. These include:

For solutions to these and perhaps other Firefox configuration problems, see Fixing Firefox

As to Firefox "Add-Ons" ("Extensions"), only two are in my opinion absolutely necessary: "Disable Ctrl-Q Shortcut 20120821" and "NoScript".

After you've accidentally shut down a complex Firefox session with a Ctrl-Q intended for another window, you'll wish you'd installed the "Disable Ctrl-Q Shortcut." At present (2014), you seem to have to obtain this shortcut from the Mozilla size rather than via the Firefox "Tools" -> "Add Ons" manager ( https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-shortcut/).

It is sobering to run the NoScript Firefox extension to see just how many different sites are running scripts on an individual web page (often well over 20 different sites/companies running programs on your computer - for their benefit, not yours - just to display a single commercial webpage). Find and install it via the Firefox "Tools" -> "Add Ons" manager.

The Firefox "flickr original" Extension is also handy sometimes.

Install Firefox Add-Ons/Extensions through its Tools menu, not pacman.

flashplugin is the Flash plugin for Firefox. Flash is generally awful, but you need it for youtube. Unlike the Add-Ons/Extensions, it's installed via pacman -S.

3.5. Programming

base-devel contains the basic development environment (gcc, grep, make, m4, sed, etc.) It does not contain gas or nasm.

binutils (which probably got picked up already along the line) contains gas (the GNU Assembler). The gas executable is simply called "as", not "gas" (although you can get to it via gcc).

nasm is in the "extra" repository and may be installed conventionally via pacman. It is a BSD-licensed x86 assembler which uses a simplified derivative of the Intel syntax.

3.6. CAD, Tethered Photography/Microscopy

Each of these can be installed via pacman -S.

(See also Solvespace, below.)

If you think that OpenSCAD's program-based approach is new, take a look at Varkon (which has been doing program-based CAD since 1984). With OpenSCAD, I find it useful manually to add:

96714 TTF-to-DXF is very good. It really does require a recent (2014 at least) version of OpenSCAD, though, as the examples rely upon the fact that OpenSCAD is actually that strange mathematical beast, a "functional programming langauge" (meaning, from a programming point of view, a non-functional programming language).

25036 Inkscape-topOpenSCAD is pretty good, but buggy when you're working with 3-D text.

Note that in order to add scripts to ~/.config/inkscape/extensions that directory must exist. It is created the first time you run inkscape.

librecad is in the AUR (see below).

FreeCAD is not yet usable. In general, 3-D CAD under Linux is a problem.

guvcview is the interface for USB cameras. It works for USB microscopes too, which is why I use it.

Out-of-the-box on Arch Linux (and Linux Mint 16, btw) it crashes every time you try to save an image. This has been reported rather frequently, but as the 'G' in guvcview stands for Gnome/Gtk it's been ignored. There may be two stacked bugs here, as there are between one and two solutions.

If you install at least the GTK "cheese" webcam interface (itself generally a useless toy), it picks up some library in its dependencies which allows guvcview to capture JPEG images if and only if the camera output format is set to "BGR3". I'm not yet sure which library this is; it's easier just to install and forget "cheese".

In order to save a PNG-format image, you have to change the format in which guvcview saves its images. This is actually easy enough to do, but the place to do it is non-obvious. In the pull-down menus, select the Photo menu and choose the File option. Then in the resulting window set the File Format to PNG. It is possible (likely) that for PNG-only saves this will cause guvcview to work even without picking up the unknown library mentioned earlier.

gphoto2 is for conventional cameras, not webcams or USB microscopes. It allows not only image downloading but, for supported cameras, tethered control of the camera over USB.

4. Arch User Repository (AUR) Packages

The following have to be compiled and installed from the Arch User Repository.

pdftk is the universal tool for messing about with PDF files. You cannot live without it.

pdftk depends on gcc-gcj (the GNU Compiler for Java) and gcc-gcj-ecj (the Eclipse Java byetecode compiler for GCJ). Since both gcc-gcj and gcc-gcj-ecj are in AUR (they're not regular Arch Linux packages), the fetching of them as prerequisites fails. You must build them first. Building these Java tools is very slow.

Don't worry - all of the Java horribleness is hidden under-the-covers in pdftk. As a user of the utility, you never have to deal with it (unlike other applications such as saxon, where you do).

(Aside: pdfimages, which is also quite handy, is probably already present. It's part of poppler-utils, and that should have been picked up by one of the graphics packages earlier.)

librecad is 2-D (only) CAD. It's basically as good as any other open source non-parametric 2-D CAD, though its support for grouping is weak.

qprint decodes annoying "quoted printable" encoded text. This can be useful when, as I do, you view your e-mail as plain text (I need never worry about an e-mail virus).

entangle is a front-end for gphoto2 for tethered photo shooting.

nmh is a very good command-line based e-mail system (and command-line e-mail programs are the only really sensible way to read e-mail). nmh is particularly advantageous because it lets you use the regular filesystem for archiving your mail. See also uudeview, below, and Mail with nmh.

getxbook is a suite of programs for getting books (legitimately) one page at a time from various sources. getgbook, within it, is useful for downloading one-page-at-a-time those rare misbehaving Google Books which should allow PDF download but do not. It's in AUR under "getxbook"; the executable for Google Books is "getgbook". The author's page for it, which includes a philosophical discussion of the reasons for it, is at http://njw.me.uk/getxbook/

[Update: it would appear as if Google Books has changed their API, and pysheng has not (Dec. 2014) been updated to match it. I'm now using getgbook (in getxbook) instead.] pysheng is a useful program for downloading one-page-at-a-time those rare misbehaving Google Books which should allow PDF download but do not. There is a GUI version as well (pysheng-gui) which I do not use. https://code.google.com/p/pysheng/

arduino is the support software for the Arduino microcrontroller (which is great fun). As I write this (March 2014) there may be issues with the current build in AUR, so one may need to download and use the nightly builds from the Arduino site itself ( http://arduino.cc/en/Main/Software) - though certainly this is a temporary situation.

For more and better information on PGKBUILD and AUR, see the Arch User Repository page. In vastly simplified terms:

 
# download and unpack PKGBUILD tarball 
# cd into unpacked directory; then 
makepkg -s 
sudo pacman -U /path/to/package.tar.xz 

5. Non-Arch Programs

These programs have not yet been integrated at all into Arch. If you use them, you'll have to install them manually (and their presence won't be noted in the pacman database).

Most of these are relatively simple utilities:

But one is a standalone application:

uudeview is incredibly useful. It takes as input a collection of encoded files (e.g., a MIME-encoded e-mail) and unpacks and converts each part. This allows you to read your e-mail using the "more" command (which, in turn, allows you never, ever to have to worry about e-mail based attacks). http://www.fpx.de/fp/Softare/UUDeview

b64decode.pl is a base-64 file decoding script. If you have uudeview, it probably isn't really necessary any more, but I like to have it. It's been floating about since 1993. ftp://ftp.oreilly.com/examples/cjkvinfo/perl/b64decode.pl

convert-jp2-tiff is a short script I wrote which takes a directory of .tiff and/or .jp2 files (both formats which are poorly supported) and converts them to png (which is well-supported). The jp2 to png conversion is of necessity a rendering. It relies on the Arch Linux openjpeg package, which has probably been picked up in dependencies of previously installed packages. PLEASE READ AND UNDERSTAND THIS SCRIPT BEFORE USING IT. Here it is: convert-jp2-tiff

convert-ppm-pbm does the same thing for pbm and ppm files. (The pdfimages program produces files of this format, but geeqie can't read them.) PLEASE READ AND UNDERSTAND THIS SCRIPT BEFORE USING IT. Here it is: convert-ppm-pbm

Solvespace is a constraint-based parametric 3-D modeling system with an eye to CAD rather than CGI. 3-D CAD in Linux is (shall we be polite?) problematic, but Solvespace goes a long way to change that. It's an astonishingly well conceived modeling environment. If you have any interest in CAD-style 3-D modeling, I would recommend that you take a look at it. (For modeling for CGI and similar fields, Blender of course dominates.)

It was developed by Jonathan Westhues and was originally freeware under Windows. As such it ran successfully under the "wine" compatibility layer on Linux. See http://solvespace.com/ Westhues released the source under the GPL, however, and it has been ported to Linux. See https://gitorious.org/solvespace The discussion forum is on Westhues' site, at http://solvespace.com/forum.pl

Linux support for Solvespace is evolving rapidly (example: I'm writing this on 2014-04-15; the updates which enabled Solvespace to compile and run under Arch Linux were committed on 2014-04-12). So my notes here will almost certainly be out of date. But for now, this is what I need to do to compile Solvespace under Arch Linux:

Preliminaries: The "base-devel" package needs to be installed, of course, as does the libtool package. Solvespace seems to have been ported to both the gtk and fltk toolkits, but (for me, at present) only the fltk version works. This is picked up automatically if fltk is installed.

However, Solvespace also depends upon statically linked libraries for fltk (that is, .a rather than .so). In other distributions these probably just exist with the package, but in Arch Linux static libraries have been disabled in the default compiles. This means that you have to use the Arch Build System ("ABS") to recompile fltk with the 'staticlibs' option set. The instructions for using ABS are at https://wiki.archlinux.org/index.php/Arch_Build_System Note that ABS uses rsync, which needs to be unblocked at your firewall.

 
sudo pacman -S abs 
# now set the PACKAGER variable in /etc/makepkg.conf 
sudo vi /etc/makepkg.conf 
sudo abs extra/fltk 
mkdir $HOME/abs/ 
mkdir $HOME/abs/extra 
mkdir $HOME/abs/extra/fltk 
cd $HOME/abs/extra/fltk 
cp /var/abs/extra/fltk/* . 
#There will be one "options" line in the PKGBUILD file 
#(in the package_fltk{} section). 
#Add the option 'staticlibs' (in single quotes, no comma). 
makepkg -s 
sudo pacman -U fltk-EXACTVERSIONINFO.pkg.tar.xz 

Then download the entire "solvespace/solvespace" main repository (not the "user clone" versions) from https://gitorious.org/solvespace (At present I'm just doing a bulk download using the "download" button to get a .tar.gz archive; one could also use git.) Put it somewhere, unpack it, and build it.

 
mkdir software-nonarch 
cd software-nonarch 
# then download the solvespace tarball here 
gunzip solvespace-solvespace-BIGLONGUNIQUESTRING.tar.gz 
tar -xvf solvespace-solvespace-BIGLONGUNIQUESTRING.tar 
cd solvespace-solvespace 
./autogen.sh 
./configure 
make 

Curiously, at this point in time a "make install" fails (it tries to re-link the executable and barfs on a missing C++ reference), but the executable made by a regular "make", src/solvespace, runs just fine.

The procedure described above worked as of 2014. But sometime in late 2014 or the first few days of 2015, it would appear that certain functions in fltk disappeared entirely from the dynamic (but not the static) version of libfltk_gl. At the same time, the linking flags in solvespace changed to support dynamic linking. This would have been correct, had fltk_gl not become broken. Pending a fix in fltk_gl, it is necessary to:

1. Compile fltk with static libs, as above, and then manually delete the dynamic (.so) libs after installation.

2. Counterintuitively, force solvespace to use the regular (dynamic) linkage flags so as to avoid the (now bad) static flags. The linker will try dynamic linkage first, but, not finding the dynamic libraries, default to the static ones.

To accomplish this, replace:

 
solvespace_LDADD = $(FLTK_LDSTATICFLAGS) -lGLU $(LIBSPNAV_LIBS) 

with:

 
solvespace_LDADD = $(FLTK_LDFLAGS) -lGLU $(LIBSPNAV_LIBS) 

in:

 
src/Makefile.am 
exposed/Makefile.am 

before the ./configure.


Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]