Pacman Package Signing – 4: Arch Linux

I have previously covered the more technical aspects of the implementation of PGP signing of packages and repository databases in pacman. You can read the previous entries here:

Since then, pacman-4.0 has been released and has been in the [testing] repository in Arch Linux for a while. That means that the signing implementation is starting to get some more widespread usage. No major issues have been found, but there are some areas that could be improved (e.g. the handling of the lack of signatures when installing packages with -UFS#26520 and FS#26729). And it has successfully detected a “bad package” in my repo… (well, not really a bad package, but a bad signature. Lesson: do not try creating detached signatures for multiple files at once because gnupg is crap…).

The Arch repos have been gradually preparing for the package signature checking in pacman-4.0. Support for uploading PGP signatures with packages was added in April and was made mandatory from the beginning of November. As of today, 100% of the packages in the [core] repo and approximately 71% of [extra] and 45% of [community] are signed.

So all the components are coming together nicely. But how does this work from a practical standpoint? I’ll start with setting up the pacman PGP keyring and pacman.conf.

When first installing pacman-4.0, you should initialize your pacman keyring using pacman-key --init. This creates the needed keyring files (pubring.gpg, secring.gpg) with the needed permissions, updates the trust database (obviously empty at this point…), and generates a basic configuration file. It also generates the “Pacman Keychain Master Key”, which is your ultimate trust point for starting a PGP web of trust. You may want to change the default keyserver in the configuration file (/etc/pacman.d/gnupg/gpg.conf) as some people have issues connecting to it.

The set-up of your pacman.conf file is somewhat a matter of personal preference, but the values I use are probably reasonable… I have the global settings for signature checking as the default value (Optional TrustedOnly). This basically sets the need for signatures to be optional, but if they are there then the signature has to be from a trusted source. See the pacman.conf man page for more details. For the Arch Linux repos with all packages signed, I set PackageRequired which forces packages to be signed but not databases. (For the small repo I provide, I use Required as both packages and databases are signed.)

Lets look at some output when installing a signed package:

# pacman -S gcc-libs
warning: gcc-libs-4.6.2-3 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
 
Targets (1): gcc-libs-4.6.2-3
 
Total Installed Size: 2.96 MiB
Net Upgrade Size: 0.00 MiB
 
Proceed with installation? [Y/n]
(1/1) checking package integrity [######################] 100%
error: gcc-libs: key "F99FFE0FEAE999BD" is unknown
:: Import PGP key EAE999BD, "Allan McRae ", created 2011-06-03? [Y/n] y
(1/1) checking package integrity [######################] 100%
error: gcc-libs: signature from "Allan McRae " is unknown trust
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

As you can see, pacman struck a package that had a signature from an unknown key. It then asks if you would like to import that key. Given the PGP key fingerprint matches that published in multiple places, importing that key seems fine. Then pacman errors out due to that key not being trusted. Well, that Allan guy seems reasonably trustworthy… so I could just locally sign that key using pacman-key --lsign EAE999BD and that key will now be trusted enough to install packages.

Validating every Arch Linux Developer’s and Trusted User’s PGP key would soon become annoying as there are a fair number of them (35 devs and 30 TUs – with some overlap). To make this (a bit…) simpler, five “Master Keys” have been provided for the Arch Linux repositories. The idea behind these keys is that all developer and TU keys are signed by these keys and you only need to import and trust these keys in order to trust all the keys used to sign packages. These key fingerprints will be published in multiple places so that the user can have confidence in them (see the bottom of this post for a listing of the fingerprints obtained relatively independently of those listed on the Arch website).

To set-up your pacman keyring with these keys, you can do something like:

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
    pacman-key --recv-keys $key
    pacman-key --lsign-key $key
    printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
        --no-permission-warning --command-fd 0 --edit-key $key
done

That will import those keys into your keyring and locally sign them. But that is not quite enough as those keys are not used to sign packages themselves. In order for pacman to trust PGP keys signed by the master keys you have to assign some level of trust to the master keys. The final line gives the master keys “marginal” trust. Note I use gpg directly rather than pacman-key as pacman-key does not understand the --command-fd option. You could use pacman-key --edit-key if you wanted to manually type in the commands to set the trust level. By default, the PGP web of trust is set up such that if a key is signed by three keys of marginal trust, then that key will be trusted. (We have five master keys rather than the minimal three so that we can revoke two – a worst case scenario… – and still have our packages trusted.) Note that setting the master keys to have marginal trust serves as a further safety mechanism as multiple keys would need to be hijacked to create a key that is trusted by the pacman keyring.

Now that the five master keys are nicely imported into your pacman keyring, any time pacman strikes a package from the Arch Linux repos with a signature from a key it does not know, it will import the key and it will automatically be trusted. At least that is the idea… We are still in a transition period so not all Developer and Trusted User keys are fully signed yet by the master keys yet, but we are not too far off. In the future we might provide a pacman-keyring package that streamlines this process a bit, or at least will save the individual downloading of each packager’s key.

That just leaves the signing of the databases, but that is a story for another day!


Arch Linux Master Key fingerprints:
    Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
    Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
    Ionuț Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
    Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
    Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8

Simple Arch Linux Theme for LXDM

LXDM is currently my login manager of choice since I abandoned Slim for becoming annoying in the configuration effort it required to keep my system working right. But with LXDM being fairly new to the scene, there are not particularly many good themes available yet.

So I decided to create a very simple theme based on the archlinux-simplyblack theme provided in the archlinux-themes-slim package. I dislike all the options crap typically displayed in a login manager, so this theme will not show a user selection dialog, session manager, keyboard layout changer, language selection or even a quit dialog, no matter what your configuration is. Also my guess is that this theme only works with the GTK greeter given I have not tested anything else…

Grab a copy of the theme here. Extract it into /usr/share/lxdm/themes/<name>, obviously providing the theme with whatever name you want. Adjust /etc/lxdm/lxdm.conf and you are possibly good to go… It works for me but there are no guarantees and I will likely not fix any issues other people have with it.

A Week of Arch Linux Development

I thought I would record what I contributed towards Arch Linux for a week so people can have an idea of what goes on “behind the scenes” in the development of the distribution. While there is no such thing as a typical week for me in Arch Linux development, this week will almost certainly be atypical given I am off work on sick leave for the week. So there is probably going to be more time for some coding than usual. Saying that, I am not intending to spend all that additional time doing Arch stuff (or even the majority of it), so we will see…

Monday

  • Starting the week with a fairly clean slate – no package updates or items on the developer TODO lists for me to deal with. Although the glibc-2.14 toolchain did move to [core] yesterday so that may result in looking for bug fixes…
  • Daily dealing with email. Typically I receive ~200 emails over night between the Arch mailing lists and the various software development lists I am subscribed to. A few emails to pacman-dev I will deal with later but the rest just get marked as read after skimming the subject line. This is of course ongoing during the day.
  • Nothing relevant to my packages reported on the forums or bugtracker overnight. Yay!
  • Quick patch review and follow-up on pacman-dev (makepkg: ln -sf and POSIX and makepkg: warning messages for missing VCS tools).
  • Investigated FS#24884 – a claim of a glibc memory leak. The bug report is wrong about the cause and the testcase is an entire piece of software which does not work out of the box. My bet is not a bug, so leave it for the user to prove me wrong.
  • Test out some software prereleases – sudo-1.8.2rc4 and alpha releases of wget (1.12.2504) and patch (2.6.1.136). All added to the [allanbrokeit] repo.
  • Updated the toolchain testsuite wiki page now that the glibc-2.14 toolchain build is in [core]. Should really investigate that x86_64 only failure in glibc… (Debian sees it too so probably not urgent.)
  • FS#24571 – “file -i” gives incorrect output on zip files. Annoying, because makepkg uses this to detect how to extract files (although it should fall back to the same method anyway…). It was not due to our patching (which all comes from upstream) so bisected the issue and reported upstream.
  • FS#23989 – readline does not update infodir. This is actually trickier than it sounds to deal with. We can not run a post_install script as readline will be installed before bash. Required double checking what pacman does when there is an install script but the function is not defined, but it looks fine to have post_upgrade only.
  • More patch review for pacman. This time a couple of patches from Dan making sync DB reading more flexible and a really interesting bug fix for our fgets function for reading from archives.
  • Binutils-2.21.1 is released. Not much of an update given we use CVS snapshots from the 2.21 branch anyway and only a small number of bugfixes landed since the last one. Package updated and pushed to [testing].

Tuesday

  • Check emails. A few comments on my patches on pacman-dev and new patches to review. Also a push to pacman git master to rebase my work upon. And gcc-4.6.1 is released so I will be updating that today.
  • Rebase my pacman git working branch. Revert a patch that got pushed incorrectly (and one claiming I broke something at that!).
  • Update to gcc-4.6.1. Takes about two to three hours to build and run the testsuite per architecture on my computer… Also do the required libtool rebuild.
  • Review new patches from Dan on pacman-dev. The package signing work is really starting to take shape.
  • Discussed lots of pacman development on IRC… Decide to continue with lots more API breakage for pacman-4.0!
  • Made a large patchset renaming a lot of structs in the libalpm codebase: 62 files changed, 1048 insertions(+), 1048 deletions(-). It is not as big as it sounds…
  • Fixed a small bug introduced into makepkg by a recent commit.
  • First pass review of patches for adding PGP signature checks for source files in makepkg. Need to think on the implementation more before commenting.

Wednesday

  • Checked emails/bug tracker/forums. Nothing new for me to deal with this morning!
  • Replied to patches for adding PGP signature checks to source files in makepkg. Still some areas to figure out, but I think the approach I proposed is fairly solid without adding too much complexity to makepkg. Then replied again with more thoughts after investigating what gpg does with its –signal-files option.
  • Dan tells me my code to determine whether makepkg signs a package or not is not working… It is all lies and we find an unexpected behavior in makepkg with respect to config file overrides instead.
  • Reviewed a patch to have makepkg automatically add packages to a repo after they are created. The patch needs work, but a good start for a first time contributor to any code base.
  • Move my packages (readline, binutils, gcc, libtool) from [testing] to [core]. Then look at what other packages I have installed from [testing] that need a sign-off.
  • Fix all packages in [core] that run “make check” but do not use a check() function. This will make the following run much faster with --nocheck
  • Rebuild the entire [core] repo to check for any failures due to recent toolchain updates. Without running testsuites, this takes about three hours on our build server.
  • More API breakage for pacman-4.0! This time rename functions using “grp” to “group” as it is much clearer for the cost of two letters…
  • Review patch from Dan on pacman-dev improving the reading of the local package database.
  • Hmm… a lot more build failures in [core] than I expected… or believe. Manually checking a few packages shows they should not have failed. And there goes the bad assumption in my rebuild script. Fix that and rerun the failures and we are back to only grub failing to build with the latest binutils.
  • Looked into the grub build issue. Did not solve. It is probably just time to drop this package with the number of patches required to have it being functional.

Thursday

  • Daily email/bug/forum reading. A new sudo RC and a follow-up to the makepkg source signature work is all of interest.
  • Subscribed to a bunch of mailing lists that I really should skim read (bug-autoconf, bug-automake, bug-findutils, bug-gawk, bug-libtool and bug-m4).
  • Tested out the sudo RC (1.8.2rc5) and an alpha of findutils (4.5.10). Added to the [allanbrokeit] repo.
  • Quick review of some patches sent to pacman-dev.
  • Fix the “pure 64bit” patch to work with the latest gcc developmental snapshots.
  • Researched and decided not to implement the changes to the gcc “pure 64bit” patch requested in FS#24271. In fact, the 32bit linker should go in /lib32 with a symlink in /lib and that would avoid any adjustments needing made.

Friday

  • What happened over night… A couple of pushes to the pacman git repo, a major mkinitcpio release and a new bug report for me (FS#24970).
  • Look at FS#24970. Definitely not a binutils bug as I can replicate using only sed.
  • Spent a lot of time trying to make a sed build from git complete… Failed, but as a bonus I did learn a lot about gnulib.
  • Made a package for gnulib and uploaded it to the AUR.
  • Looked at why we need a /lib64 folder in our x86_64 install. Probably only issues with binary blobs… Call for testing some real world usage without the folder to see what issues are run into.
  • More investigation of FS#24970. Valgrind finds memory issues only with the hu_HU.UTF8 locale. Interesting…
  • Prepare script to generate patches for one final large API breakage in libalpm: PM_* to ALPM_*

Saturday

  • Another morning with not much new to deal with. Some new patches from Dave on pacman-dev for improving the download code, but they look complex so I think I’ll leave those to others (i.e. Dan) to review.
  • Clean up SVN entries for some perl packages that were converted to arch=('any').
  • Discussion about including more information about installed files in the local pacman database and where that information should be calculated (during packaging or install). This will allow for more stringent system checking with pacman -Qk.
  • Review and merge some of Matt’s (our new ABS developer) patch queue. Rather big job (57 patches!), but is all my fault for dropping the ball for so long there. Got to the point where an abs-2.4.3 release should be made. Impressed with the progress towards ABS-3.0 and the new features there.
  • Updated my bigpkg script to work with pacman-3.5

Sunday

  • Read emails, etc… The db-5.2 rebuild has hit [testing] so that will be a big update to test. Also a new bug reported against bash.
  • Addressed comments on my patch for a memory usage optimization when removing packages with pacman. Revised patches posted.
  • Closed FS#24992 as “Won’t Implement”. I’m not adjusting man pages in our packages.
  • Spent lots of time looking at the alpm_list_t implementation. I really want to change it a whole lot…
  • Initial look at adjusting the option parsing code currently only used by makepkg. Started implementing a couple of new features to it so that it can be used in the new pacman keyring management script (pacman-key) too.

And that wraps up my Arch Linux contributions for this week. Looking back at the week, the amount done on Monday to Wednesday was more than what I would consider usual on account of me being off work, but the rest of the week is probably not too far off what I normally do. I definitely got more coding and patch review done for the week, but I also had only two minor package updates to do which was atypically low. And I still did not get to finishing the patch merge for pacman-key, which was one of my primary development goals at the start of the week. Oh, well… there is always next week…

The [allanbrokeit] Repo (That Might Really Break Your System…)

I often package pre-releases of software that various developers post for testing before making a final release. I thought it would be good to put these in a repo where others can easily test them out too, as finding bugs before the main release saves me time later… Note that this software is pre-release and so you should expect it to have bugs, but I will generally stick to releases that the upstream developers consider ready for widespread testing and not alpha quality code. However, if you want to use this repo, you should be prepared to rescue your system from a bad package upgrade and to report your issues to the upstream developers (and not me…).

To use this repo, add this to your pacman.conf:

[allanbrokeit]
Server = http://allanmcrae.com/$repo/$arch

The packages are built on top of [testing], so you should have that enabled too.

Note the repo is fully signed with my GPG key (get the full fingerprint from my About page), so when something breaks, you can be guaranteed that it is my package that caused the issue! More importantly, this serves as a bit of a test for the signature checking in the developmental version of pacman.

Currently, the only package in the repo is the beta of gawk-4.0.0. I will tend to only add packages that I deal with for Arch Linux (which is mainly packages in [core]), but if someone has a particular package that would be of interest then let me know and I will consider it.

How To File A Bug Report

I have been noticing that there are some things that people could be improve when reporting bugs to the Arch Linux bug tracker. So here are some guidelines for what I personally like to see in a bug report. Following these would make finding and fixing the bug less work for me (and I assume other developers).

1. Check the bug is not already reported. This includes checking the recently closed bug reports as your issue may already be fixed and in the process of propagating out to the mirrors. This will prevent multiple bug reports for the same issue, which just creates more work for everyone involved.

2. Provide all information. In particular, do not assume the bug is obvious. What might seem an obvious bug to you may not occur on the developers system, so full information about the packages involved and detailed information on how to replicate the issue is essential. I always like to see at minimum the exact package version involved (including pkgver and pkgrel) and the architecture the bug is occurring on (i686 or x86_64). Do not just report it is the “current version” of a package as that can be useless within a few days on a rolling release distro. The more specific you can be with the package update where the issue started occurring, the easier it is to track down the change that caused it.

3. Stick to relevant information. The list of 50 packages you updated before noticing this bug likely contains the problem package, but there is also a lot of unrelated updates. Reduce this down as much as possible before reporting the issue. More time spent by a packager filtering down to only the relevant information means less time actually fixing bugs.

4. Do not report bugs via links. Providing a link to a forum/mailing list thread that describes the bug is not enough. You still need to provide a detailed summary. This is to keep all information in one place, but also prevents the bug being lost if the link goes dead.

5. One bug report, one issue. Even if you have multiple issues with a package, it is usually better to open a new bug report for each issue. This allows each bug to be closed as it is fixed (which might not be all at the same time…) and prevents issues getting lost among the others. The possible exception to this is when many minor issues with a package are being reported along with a PKGBUILD that fixes them all.

6. Report upstream bugs upstream. If a bug is clearly an upstream bug and not a packaging error, then it needs to be reported upstream. It is fine to also report the issue in the Arch bug tracker (if it is a bug and not a feature request) with a link to the upstream report so the Arch package maintainer can track and apply the fix when available. This not only saves the packager a lot of time (they have many bugs to deal with) but it is also useful for upstream to be hearing the bug information directly from the person experiencing it. The exception to this is glibc who do not accept bug reports from users…

7. Follow up any queries. This is particularly important for bugs that can not be replicated by the relevant Arch packager. The longer a query sits unanswered, the longer it will take to trace and fix your bug. If you can no longer replicate the issue due to (e.g.) changing hardware or distribution, then tell us and we can close the bug report.

8. Do not “me too”. There is a vote link on the bug reports you can use to show you also experience the issue. Posting “me too” as a comment only clutters the tracker.

9. Use “LANG=C” for output. Prefixing a command with “LANG=C” will result in the output using the strings in the original code (English for most software). That way, we do not have to reverse-translate messages to understand the error.

Finally, remember that a bug does not exist until it is in the bug tracker. Reporting a bug on the mailing lists, forum, IRC, jabber, etc does not count. These are all fine for tracing the source of your bug before reporting it, but remember that bug trackers exist for a reason.

Edit (2001/05/12): Added #9.

Big Python Transition In Arch Linux

After a long time of planning and a massive rebuild, the “Great Python Rebuild of 2010″ has finally made its way into the [testing] repo for Arch Linux. And I do mean a massive rebuild… weighing in at 587 (and still growing) packages, that is a little more that 10% of our repos! That is bigger than the combined libjpeg/libpng rebuild earlier this year.

So what exactly has happened? Two things. Firstly, the python package now is from the python-3.x branch (currently 3.1.2). That means /usr/bin/python will point to /usr/bin/python3 being the default python-3.x interpreter. A new python2 package has been introduced containing the latest from the python-2.x branch (currently 2.7.0), with its primary binary being /usr/bin/python2. Note that also is an upgrade from python-2.6.5 which is currently in [extra]. While we were rebuilding everything anyway, I also enabled UCS4 (unicode) support in python2.

WHAT!!! Am I crazy? Python-3.x as the default /usr/bin/python? Well, my sanity may be questionable but the principles behind this transition are sound. Arch Linux is unashamedly bleeding edge so we do big transitions like this first. Other distros can follow in our wake. Also, python-2.7 will be the last in the python-2.x release series so we are following upstream intent and moving the focus to the python-3.x series.

Doing this transition now also allows us to gradually rename our packages. e.g. python-foo is still a package for python2 and will eventually need renamed to python2-foo. That would be much more difficult if we waited until we had a heap of (e.g.) python3-foo packages in the repos. Not being able to make a clean break in package naming like that is one of the disadvantages of a rolling release distro.

For all packages in the official repos, this transition should be very smooth. Packages from the AUR may need to be rebuilt to point at the /usr/bin/python2 binary rather than /usr/bin/python. A fair portion of packages will recognise the binary is named python2 and make all the required adjustments. Others will recognise the environmental variable PYTHON=python2 and use that. Finally, some packages will need a sed line to adjust scripts like:

sed -i -e "s|#![ ]*/usr/bin/python$|#!/usr/bin/python2|"
       -e "s|#![ ]*/usr/bin/env python$|#!/usr/bin/env python2|"
  $(find $pkgdir -name '*.py')

Of course, your own python scripts will need to point at /usr/bin/python2. However, by doing this you may run into portability issues across distros. There does not appear to be an easy solution for that at the moment. It seems that while most (all?) distributions include a /usr/bin/python3 link to their python3.x binary, none do the same thing for python2.x. Either create your own symlink in your path for those distros or even better file a bug with them asking for such a symlink. They are going to need one in the future…

If you are using the [testing] and [community-testing] repos go ahead and upgrade to the future of python. If see any of the following in one of our supported packages, report a bug:

  • files linked to libpython2.6.so.1.0
  • files with a “#!/usr/bin/python” or “#!/usr/bin/env python” shebang
  • files in /usr/lib/python2.6 or /usr/include/python-2.6
  • depends/makedepends/optdepends on “python” instead of “python2″
  • packages that no longer work…

So far it looks like the rebuild has gone remarkably smoothly. A big thank you to all the developers and trusted users who helped out with the rebuilds. It also shows the power of our new repo setup on the mirrors. Now moving all those packages between repos just moves some symlinks so syncing to mirrors is very fast. So your favourite mirror should sync very quickly unlike with big rebuilds in the past.

But there is no rest for the wicked… We will be onto rebuilds for db and heimdal next!

Installing Arch on a Macbook Pro (5.5)

I recently got a 13″ Macbook Pro (5.5) and of course need to install Arch Linux on it. So here goes a log of my install experience. I am not going to cover everything, as there is already basic instructions on the Macbook page in the Arch Wiki and all over the net.

The basic specs are:

  • 2.53GHz Intel Core 2 Duo
  • 4GB (2x2GB) 1066MHz DDR3 SDRAM
  • 500GB Serial ATA; 5400 rpm

More details as I deal with getting individual components working…

Installation: The install went fine using the latest test iso (2010.04.19-core-i686). The only “trick” was to change the partition table from GPT format (to msdos) before entering the installer. Luckily, parted is included on the install CD so this was simple. Also, install GRUB on the partition holding /boot instead of /dev/sda. There was no need to do anything with rEFIt as many guides prepared me for, but I think that is because I did not dual boot.

The final stage is to boot the OSX install CD and run:
bless --device /dev/disk0s2 --setBoot --legacy --verbose to speed up the boot time before you get to GRUB (3s vs 20s).

Video: This has a NVIDIA GeForce 9400M card, so a pacman -S nvidia and nvidia-xconfig then we are basically good to go.

Screen Brightness: There is mbp_nvidia_bl in the kernel, so you think that would work but no… Any changes made to the backlight level appear to be registered (and gnome-power-manager gives me a nice on-screen indicator that changes are being made) but the brightness stays the same. The Mactel PPA for Ubuntu contains a nvidia-bl kernel module which does the job. Grab the PKGBUILD here.

Keyboard Backlight: Using pommed is supposed to make this work and it did to an extent. The only issue was roll over from almost completely dimmed to fully on that made disabling the keyboard backlight impossible. Instead, I am just adjusting it manually using:
echo 255 > /sys/class/leds/smc::kdb_backlight/brightness(TODO: write a script using this to bind the adjustment keys to.) In OSX, this would automatically come on in low light conditions but I have no idea how to approach that.

Touchpad: This “works” out of the box, although is completely broken as far as I am concerned. I quickly found out that a major touchpad use is to click with your thumb and then use a finger to select text or move/resize a window, etc. That does not work as touching your finger after the click with the thumb is interpreted as some sort of multitouch event. A patched bcm5947 module fixes this (but is a hack and is unlikely to be included upstream…). Grab the PKGBUILD here.

Wifi: It has a Broadcom BCM4322 802.11a/b/g/m wireless card. That does not work with the b43 driver, so requires broadcom-wl driver. Grab the PKGBUILD here.

Suspend to RAM: Worked out of the box. I was only required to tell xfce4-power-manager to use it.

Webcam: Used the isight-firmware-tools package to extract the firmware from the file that I remembered to grab from OSX before wiping (or perhaps used google to find…) and restart.

Sound: Installed alsa, ran alsaconf and everything worked. Shortcut keys required setting up.

Keyboard: Ignoring the lack of Home/End/Page Up/Page Dn keys, the thing that most annoys me is that to by default the “action” functions take preference over F1-12. I use F1-12 a lot more that the action keys. So these need to be swapped (TODO: do this…)

Bluetooth: Untested. I have no real use for this at the moment…

Apple Remote: TODO

Reader Mail: Contributing to Arch

Long time reader Greg writes:

Why do you think that even though Arch’s userbase numbers have exploded during the last year, the number of contributors (not counting the AUR) remains almost the same?

Well Greg, here are my opinions on the issue. I should point out that these are my opinions and do not necessarily reflect the opinion of Arch developers as a whole.

Firstly, I tend to agree with this sentiment. Over the last six months to a year, there has only been one new person that has stood out to me as developer material based on the contributions they have made (and one who just will not accept the position no matter how much we ask – you know who you are!).

I think the primary reason for this is a very large change in userbase. The earliest comment by me that I can find noting this change was in the middle of 2008. A lot has changed since then (I was not an Arch developer or forum moderator then and I am now getting a Mac…), but the change in userbase has continued over the years. I think Arch has changed from what was a “Do It Yourself” distribution to one where people expect a lot of help. This is very evident on the forums, where very basic questions are asked on an hourly basis. People think there is a lot of “RTFM” on the Arch forums these days, but ask those same questions on the forum three years ago and that would be considered a polite response. It seems that despite the large increase in the number of users, the number of people with the skills required to fix a problem that they notice has not increased at the same rate.

The second reason I see is that there are less things to be fixed in Arch. The only reason I started contributing to Arch is so that I could fix things that annoyed me and that continues to be my primary motivation. I can imagine that the distribution as a whole runs rather smoothly from a users point of view, at least compared to historically. Also, a lot of the “easy” bugs in the user visible parts of the distribution have already been fixed, so the barrier to entry is higher. Saying that, I have made a couple of patches to pacman itself in the last few weeks and I still know next to nothing about the actual pacman codebase (I focus on makepkg). So there are still reasonably easy pickings for motivated individuals to get themselves familiarised with the code before tackling harder issues.

Finally, I think there is becoming a gulf between developers and users. Perhaps this is an entirely unintended side-effect of the change in userbase. I know that many long term Arch users (including some developers) found the change in the types of questions being asked and demands being made on the forums quite demotivational and now spend far less time there. This means less interaction between users and developers, resulting in the developers being seen as quite a separate group. From a developer point of view, this could not be further from the truth. Arch is a “community distro” and contributions from the community are strongly encouraged. Remember that the x86_64 port started as a community project. If a user comes up with a good idea, and more importantly provides some code or implementation to back it up, it will be considered by the development team just as it would if a developer suggested it. Equally, developers make suggestions that are not taken up (trust me… I have had ideas rejected, taken out the back and shot before being buried in a shallow grave in a forest). But remember, talk is cheap. There have been many, many threads about the importance of package signing in pacman, but no-one has but in a decent effort to get this completed.

In short, we need more community members to step up and help out wherever they can. The core Arch development team is relatively small and our continued progress (beyond pure packaging) relies on contributions from the community. Even packaging could use more people (and we do take applications to become a developer from known community members). I am sure that there is something that annoys every user about their system. Why not try and fix it?

Transparent x86_64 Kernel On An i686 Userland

A while back, I wrote about using an x86_64 kernel on an i686 userland. After using this setup for a while, I began to discover that it is not that user friendly to have to use linux32 in front many commands. In particular, when building software the ./configure needs to be prefixed with it and bash can not handle creating an alias to transparently do that. Also, I would need to make aliases for all build tools I could encounter (make, cmake, qmake, …), which is almost an impossible task.

In true Baldrick style, I came up with a cunning plan… What if I called my shell with a linux32 prefix and then my system would think it was always an i686 one. I only need my system to think it is an x86_64 when I enter an x86_64 chroot, so that is much easier to create aliases to deal with. The trick was to create a /bin/bash32 file containing:

#!/bin/bash
linux32 /bin/bash -l "$@"

Then add bash32 to the list of shells in /etc/shells and use “chsh -s bash32” to start using it.

After using this setup for several weeks, the only issue I notice is that when using chroot, it will look for /bin/bash32 in the chroot and likely fail. That can be fixed by prefixing with the SHELL environmental variable pointing at an appropriate shell (more than likely /bin/bash). I am sure that creating a wrapper script to handle that would be easy but using chroots via the Arch devtools does not suffer from this problem so I have not looked into it further.

Posted in Arch Linux on by Allan Comments Off on Transparent x86_64 Kernel On An i686 Userland

Chakra Installer Review

The Chakra Project is a “distrolet” based on Arch Linux and providing its own KDE packages (collectively called KDEmod). I really do not like KDE so I am only interested in how the install goes. I used QEMU with a 4GB image and 512MB RAM with the 2010-01-10 “Aesop” installer.

The installer is live CD based, so boots you into a nice looking desktop [01]. Starting the installation takes you to a graphical install system [02] with the prerequisite warning about being an alpha release and the issues it can cause your hamster. After reading some notes and agreeing to various EULAs [03], the install is all go.

Onto the preparation of your system. The language and time settings looked quite ugly [04], but I have suspicions that QEMU was running this quite slow and maybe this was an artefact. I found it good to know that despite the complexities of installing being hidden, there was options to go in deeper [05] if needed. Partitioning [06] was not particularly simple, but that is being reworked for the future.

The actual installation of packages [07] proceeds with a montage of screenshot to whet your appetite for your new install. Of course you probably have already seen what it looks like from the live CD… Then you create some new users [08] (although I do not know what exactly an “Administrator” is), enter the root password and install the bootloader. I have no idea what the “Configure System” item at the end of the installer sidebar does as after installing the bootloader I got a reboot dialog.

The booting system looks familiar [09] to any Arch Linux user. I had expected a graphical boot-up as I had heard something about it using Plymouth, but I guess that is for the future. The login screen indicates that the /etc/hosts file has issues with setting the hostname [10]. Other than that, I was left with a fully working KDE desktop with no obvious issues. Looking at some configuration files to see how well the automatic set-up went found some interesting points. The MODULES array in /etc/rc.conf both disables and enables the e1000 module [11]. Also, I noticed that kdm is started as a daemon rather than using the inittab method, which I guess is more in line with what Chakra wants to provide but I find that to be less flexible. The supplied pacman.conf has the repos listed in an interesting order [12] (I think [core] should at least come before the KDEmod repos).

Overall, the installer does its job despite a few rough edges. The install booted to the desktop with relatively few configuration issues that I could spot. Not bad for something labelled “alpha”. Is it the “Arch made easy” that is often touted on Distrowatch Weekly comments? Maybe. But with a distro like Arch, that is not necessarily a good thing.

Screenshot index:

[01] – Live CD Desktop
[02] – Installer start screen
[03] – EULAs
[04] – Language and timezone setup
[05] – Hidden “advanced” options
[06] – Partitioning
[07] – Package installation
[08] – User creation
[09] – Bootup
[10] – Login
[11] – /etc/rc.conf
[12] – /etc/pacman.conf