Arch Linux contains two kinds of packages: precompiled packages that you install through "pacman -S" and configured but not-yet-built packages in the Arch User Repository (AUR). For full instructions on how to build a package in the AUR, see https://wiki.archlinux.org/index.php/Arch_User_Repository
You can search the AUR directly at: https://aur.archlinux.org/ I've found that doing a general search (Google, etc.) on
Arch Linux DESIREDPACKAGENAME
Downloading the tarball from the AUR will be very quick, because it does not contain the package itself. It merely contains the instructions on how to build the package from its original source elsewhere on the net.
sudo pacman -S base-devel
Here are my incomplete notes on building from the AUR. (It is a simple process, but do not rely on my notes. Read and actually understanding the process as described on the https://wiki.archlinux.org/index.php/Arch_User_Repository page):
# Download the tarball from AUR and put it someplace convenient. # Extract tarball (gunzip, tar -xvf ). # cd to the extracted directory. # The "-s" pulls in dependencies. # If there are any, it'll prompt for the password to do # an installation of them (you must have sudo installed, of course). makepkg -s # The makepkg creates a .xz file sudo pacman -U /path/to/package.tar.xz
It is worth taking the time really to understand what a "rolling release" means, how it differs from the more common periodic releases, and the implications that this has for you when you want to update a particular package. In other words, read and understand:
Before the first run, it is necessary to set up the gpg keys for your system. Read Arch Linux System Maintenance first. GPG key installation will involve at least:
sudo pacman-key --init sudo pacman-key --populate archlinux
sudo pacman -Syyu
Note: Do not sync and then update a particular package. Sync only syncs the databases of packages. It does not update the system. So if you sync and then update an individual package, your updated individual package might be out-of-sync with the actual system you have installed. You must both sync the databases and update the system first. It is best, therefore, always to update the entire system rather than an individual package.
There are presently (2014) two packages in Linux for handling automounting of disks: the older "udisks" and the newer "udisks2". The older udisk package mounted removable media (such as USB sticks) in /media, in accordance with the Linux Filesystem Hierarchy standard. The newer udisk2 mounts them in /run/media/$HOME
There are plausible reasons why this might be a good thing (e.g., it lets the / level of the filesystem be readonly). But there are equally plausible reasons why it is not. More importantly, it is a poor design decision from the point of view of practical usability, as it substitutes a long and user-dependent path for a short, simple, fixed one.
One can at present solve this problem by reverting back to udisks, but eventually udisks is going to go away. I suspect that one can also solve it by creating a /media directory linked to /run/media/$HOME, but it isn't a certainty that this will work in all situations. Neither of these solutions is clean.
See: https://wiki.archlinux.org/index.php/udev#udisks2_-_mount_to_.2Fmedia for a discussion of this.
Note that during some upgrades this configuration file will be destroyed without warning (but no mount point in "/run/media" will be created, either). Once this happens, no USB devices will mount. You must manually re-create it. Here it is as a file: 99-udisks2.rules
Apparently the "net-tools" package (which contains the ifconfig and netstat programs) hasn't been updated "in years." (It's enough to make one feel old.) The replacements for them are in the iproute2 package (especially the "ip" command).
There's a useful blog entry by Doug Vitale at http://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ which discusses equivalent commands using the newer set of tools.
The chances that the "airplane mode" button (if present) will work with Linux are slight. (On my Lenovo g500s laptop, pressing it does bring the wireless interface down, but pressing it again does not bring the wireless back up.)
sudo netctl stop MyNetworkConfig
sudo netctl start MyNetworkConfig
However, it isn't clear to me that this actually turns off a wireless interface (it simply deconfigures the network's use of it). To turn the network interfaces off entirely, it seems that you need to use the "rfkill" kernel userspace tool. See: http://wireless.kernel.org/en/users/Documentation/rfkill ("RF" for Radio Frequency interface - that is, wireless).
sudo pacman -S rfkill
rfkill block all
All portions of this document not noted otherwise are Copyright © 2014 by David M. MacMillan and Rollande Krandall.
Circuitous Root is a Registered Trademark of David M. MacMillan and Rollande Krandall.
This work is licensed under the Creative Commons "Attribution - ShareAlike" license. See http://creativecommons.org/licenses/by-sa/3.0/ for its terms.
Presented originally by Circuitous Root®
Select Resolution: 0 [other resolutions temporarily disabled due to lack of disk space]