mount /tmp on tmpfs? compile and runtime tmpfs overloads

I located (via yaourt) a large wine client -- a few hundred megabytes and half an hour to compile on an older laptop. But two wine compilation problems appeared during the install: 1) wine doesn't compile because its PGP key is unrecognized by yaourt, 2) wine doesn't compile because the system runs out of available RAM.

First the PGP problem: when the PGP rejection error notice is generated, one can see the key in the notice. Users can then copy it and add it to their keyring. The reason for the confusion is that yaourt relies on the user's personal key ring, which is a different key ring than pacman's dedicated keyring. So accept the key into your personal gpg ring...then restart the install and yaourt will accept the app.

$ gpg --recv-key [key]

...or you can examine the key owner's information with --fingerprint [key].

memory

Now we have the application, we have several ways to check the memory parameters.

$ free
total used free shared buff/cache available
Mem: 2034884 330740 1301548 45624 402596 1512420
Swap: 50426196 0 50426196

$ swapon
NAME TYPE SIZE USED PRIO
/dev/sda2 partition 48.1G 0B -2

$ df
Filesystem 1K-blocks Used Available Use% Mounted on
dev 1010468 0 1010468 0% /dev
run 1017440 592 1016848 1% /run
/dev/sda1 258030980 27348180 217575600 12% /
tmpfs 1017440 2972 1014468 1% /dev/shm
tmpfs 1017440 0 1017440 0% /sys/fs/cgroup
tmpfs 1017440 8 1017432 1% /tmp
tmpfs 203488 0 203488 0% /run/user/1000

$ cat /etc/fstab
/dev/sda1 / ext3 rw,relatime,block_validity,barrier,user_xattr,acl 0 1

/dev/sda2 none swap defaults,pri=-2 0 0

Where do these additional entries not in fstab originate? Can they be controlled? It appears we need some strategy for our tmpfs to go onto swap space once RAM is full so that the system doesn't lockup.

memory during compiling

During application compiling, tmpfs is used for parking files spawned or used by make. The tmpfs space is in RAM, viewable inside /tmp, and it allows compilations to progress quickly. However, compiling larger applications can require so much /tmp space, that RAM becomes filled. Once RAM is nearly full, make aborts complaining of a lack of space. Although tmpfs is supposed to overflow into SWAP space it does not. How can we compile these larger programs?

As noted, /tmp naturally resides in RAM. At the expense of 1) time, perhaps 25% longer compilation, and 2) the risk of thrashing one's hard drive, one can mount their /tmp directory on the hard disk. The important thing then is to refer this directory back to RAM after compiling the project. /var/tmp is the answer, but how to get it to connect with RAM?

# nano /etc/fstab
tmpfs /tmp tmpfs size=25G 0 0

This is all that's necessary. Checking...

$ df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 1016196 5752 1010444 1% /dev/shm
tmpfs 26214400 8 26214392 1% /tmp

Now we can compile wine. We still have /dev/shm for regular RAM, but with spillover into 25G HDD swap if needed. Since I won't need this regularly, I will comment it from /etc/fstab once I compile wine.

Node.js breadcrumbs

Node.js is not properly installed until it's reliable in command line at the user level. Portions of node.js installed from Arch repositories are, of course, global to command line. The rest of the installation is mostly local to one project or another, as various modules become necessary.

global

For Arch, one can use pacman:

# pacman -S nodejs npm

These will work in any directory.

project

Suppose a user establishes a folder for their node.js project, and is working from that project directory. During their project, they recall that they need to install this or that module, say, express. The user roots up, runs # npm install express, then descends to user and continues working on their script, or some other operation which calls express. Eventually, to verify the express module's working, the user types "express" at the command line. Here's what would happen.

$ express
bash: express: command not found

Unlike pacman, npm is a node.js specific installer with its own directory structure. Node.js is roughly analogous to an independent LaTeX install: you can use $ tlmgr to update or control things, but not until the LaTeX directories are added to PATH. Likewise npm works from the command line, except that one must root-up when using it as an installer (# npm install [some package]). This is because the Arch version of npm places the modules into a root privilege directory /usr/lib/node_modules. This will hinder us throughout anything we do. We can place /usr/lib/node_modules/ in our PATH, which will allow execution, but we can never add or modify files in it. For this reason, I strongly believe that, like LaTeX, node.js should be installed in the HOME directory at user level, never requiring root privileges. If you install node.js with pacman, you'd have to pacman or yaourt every single module installed by node.js, or create PATH additions for each and every one that npm installs. No way, jose.

# pacman -Rs npm nodejs
$ rm -r .npm

nvm

For me, the easiest way to install a user-level node.js application was to use NVM volume manager to import node.js. NVM is upstream from node.js installations, so it can download and install any node.js version, allowing multiple releases to exist simultaneously on a system within the home director: users may select the version they wish to use directly from the user level.

The NVM script at the blog above downloads the latest git version of NVM, or just go directly to the install script here. I opened it with a word editor and reviewed it, then ran the script to download NVM.

$ sh ./install.sh

In addition to installing NVM at the user level, the install script appends to ~/.bashrc so the PATH is updated. I verified the changes, found them acceptable, and then sourced the .bashrc to activate the PATH change. Next, I verified nvm was detected and ran.

$ source .bashrc
$ nvm

npm

The next concept in user-space node.js is managing packages. Since node volumes can be placed using NVM, the packages for any version of node will be with a pacakage manager, NPM. it's good to use

[solved] vlc playback odds and ends

Links:

---

audio playback gaps

Several forums describe buffering issues with VLC audio. For me, it was during playback of files on my HDD. For example, in the previous post, I described using VLC with .m3u files to play with WAV ordering prior to burning a CD (assuming anyone still uses CD's). Playing M3U's which contain nothing but WAV's through VLC would trigger the audio gaps.

The symptom is a one second gap in playback, a simultaneous spike in CPU use, and generation of a two-line error. Subbing in some variables for actual numbers:

[0000x7f5d030f7df8] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 2232 ms)
[0000x7f5d030f7df8] core input error: ES_OUT_RESET_PCR called

Apparently a Program Clock Reference is called too late and, in response, VLC increases the delay for the Presentation Time Stamp delay. PCR and PTR are supposed to be related to MPEG playback, but this error appears in audio-only playback of WAV's, for example.

Most of the solution for me was found here, except for 1) which value to change, 2) increase or decrease and, 3) how much.

Since each setting has a pop-up, I read them. It appeared the item to change was "File Caching". On a guess, I adjusted the delay to near the pts_delay value noted in the error message above. Once set at 2000ms, I did not experience cut-outs during file playback.

the orange cone

Some don't like the cone at all; I dislike it during audio-only playback. It sits conspicuously where album art would go. I noted how to get rid of it in a previous post, but it bears repetition. During playback, to disable the orange cone when there is no album art: Tools, Preferences, Select All (Bottom), Interface, Main interface, Qt, unselect "Display background cone or art".

zenwalk - package management

Links:
Forum Thread: Prior release repositories
Forum Thread: Making a local repository for a release

The Zenwalk OS (Slackware-based) is updated once or twice a year. Following an update, the mirrors for packages (programs) are also updated and contain the latest package versions.

Let's suppose I like to use the audacious package to play music. In order to keep the installation disc as small as possible, packages such as audacious are not included in the Zenwalk installation disc. These additional packages are retrieved separately from one of the package mirrors. Open a terminal and it's easy to download and install any Zenwalk package (in this case, audacious) using the command line:

# netpkg audacious

Or, if removing:

# netpkg -remove audacious

That's about all there is to installing or removing applications Zenwalk maintains.

Maintaining Previous Versions
As noted above, Zenwalk releases entirely new distributions once or twice a year. What if I don't want to upgrade my entire operating system, but I still want to install applications? For example, suppose I've had Zenwalk 6.0 installed for a year before I remember I want to install audacious. I try to netpkg audacious but, when I do, I discover Zenwalk has upgraded to v.6.4. If I try to install the newer version of audacious, netpkg asks to upgrade portions of v.6.0. I can let netpkg do this, but maybe I don't want parts of my system to be in 6.4, while other parts are in 6.0. How do I avoid upgrading to 6.4, but still get the packages I want for 6.0?

Three Solutions

Solution a -- install without using netpkg
One can always go to the home page of any application they desire and simply download, unpack, configure, compile, and install the general release tarball (.tgz). In the case of audacious, the home page is http://audacious-media-player.org/. One might want to check for dependencies when doing so.

But a couple of solutions for installing older software can be accomplished inside of the netpkg package manager. Both of these require a small degree of manipulation of the /etc/netpkg.conf file. The second option additionally requires manipulation of the /usr/libexec/netpkg-functions file.

Solution b -- point netpkg to prior release mirrors
For a period of time after a new Zenwalk release, a few mirrors contain the previous release. One must open the /etc/netpkg.conf file with a text editor and manually add URLs for older mirrors. After doing so, I run

# netpkg mirror

and select one of the older mirrors. I found a few prior release URLs listed here, and had success with this mirror: http://viking.zenwalk.org/i486/current-old. Other archive URLs can probably be Googled, but there is a limitation to this solution: archive mirrors trail the current Zenwalk release by only one version. Users therefore only have a grace period of 6 months to a year before they will be forced to upgrade to some extent. The more permanent solution is the one below.

Solution c -- download all desired packages for dvd or other local access
This is a permanent solution, in case one wishes to never upgrade Zenwalk. The catch here is one needs to consider nearly any application they might need, because thinking of it two years later will be too late (if that happens, just use "solution a"). To download all potential applications in a Zenwalk release is roughly 10GB. I then alter netpkg to find the files on my hard drive or a dvd, instead of on a mirror. Alterations include the /etc/netpkg.conf and /usr/libexec/netpkg-functions files. Here are instructions:local repository

Supposedly it's also possible to point to a DVD with everything on it (if Apache is running) with this URL added to /etc/netpkg.conf and selected via # netpkg mirror:

http://localhost:8000

!! For "solution c", it's necessary to download PACKAGES.txt and PACKAGES.txt.gz/ from the mirror. Netpkg appears unable to traverse directories to locate packages without these meta-information files. Get these files before the previous release mirrors move to a newer release or face recreating them manually, a time-consuming, nearly prohibitive task.

slackware - application list

A baseline group of applications we typically install, mostly to solve the problem of how to retrieve various types of media or other information quickly. Slackware has several by default. The configuration file locations are not given. Whether or not they are command-line or gui apps is not always included.

ffmpeg: necessary media translator
streamtuner: media stream consolidation
recordmydesktop: screencasting. best with command-line settings.
audacious (netpkg): gui, audio, skins
eclipse (netpkg): C++/Java IDE
unison (netpkg): folder comparison and merging
cycas ($300): professional architectural program ($128 - basic)

---

database apps
Nola Pro: bookkeeping/accounting. MySQL, PhP, Browser