Allan McRae

Dusty recently introduced his Arch Bounty project. The basic idea is people have an idea of what they would like implemented in Arch Linux but are unable to implement it themselves. Instead, they craft a clearly worded specification for their proposal and submit it to the Arch Bounty site. Once the proposal is accepted, people can make a donation towards the completion of the project.

That seems a great idea for those who have big ideas without the know-how to implement them. And if many people want the same things, I can see quite a nice monetary motivator building up to get the job done. However, after several weeks, there is still a dearth of projects. Someone proposed creating a fully featured usenet client, but I think that is really too big of a project to succeed with this system (and the project was rejected from the system). And that is the sum total of all projects proposed so far…

Here are some ideas that I know people want implemented that would make good proposals:

• Universal sign-in across Arch sites (forum, wiki, bug tracker, AUR)
• Package signing in pacman
• Finally finishing the AUR2 (may be a bit ambitious)

Those are just ideas from what I see repetitively asked for on the forums (and I could think of while typing this…). I am sure there are many other ideas out there that people want implemented and would be willing to put a couple of dollars towards.

I saw a post on the Arch Linux forums from a user wanting to build an Ada compiler and having issues with the PKGBUILD from the AUR. The main issue building the Ada compiler is that you need the Ada compiler to do it. Classic chicken and egg problem. The maintainer of the AUR package works around this by having the PKGBUILD download a tarball from his site that provides the necessary binaries to build the compiler. It is probably perfectly safe, but I would not be doing that… Also, according to the forum post, the binary compiler package seems slightly broken at the moment.

So I went on a mission to create some gcc-ada packages for Arch. I had some interesting problems along the way (you really should not try to compile on an x86_64 system with an i686 makepkg.conf…), but I succeeded in in the end. Get packages for i686 and x86_64 from here. Note that I provide the build files too, but remember you will need the package to build the package…

For those that are interested in how I bootstrapped this package (or do not trust my binaries), here are the details:

• Create a build chroot (sudo mkarchroot /path/to/chroot base base-devel sudo)
• Extract rpms from Fedora rawhide for gcc, libgnat, libgnat-devel and gcc-gnat into the chroot
• In the chroot: cd /usr/bin && ln -s ../lib/gcc/i686-pc-linux-gnu/4.4.1/cc1 cc1
• Comment out the makedepends and CC=gcc-ada lines in the PKGBUILD
• Build the package (sudo makechrootpkg -c -r /path/to/chroot)
• Revert the comments in the PKGBUILD, create a clean chroot, install the built gcc-ada package and rebuild

Then you end up with a nicely bootstrapped Ada compiler. Fedora packages were used as their tool-chain package versions are very similar to those in Arch and thus likely to actually work as drop-in replacements for our packages. Note that the last step is superlative given gcc bootstraps itself as part of its build process.

Edit: gcc-ada is now available from the Arch Linux repos.

I have been experimenting with running an x86_64 kernel with an i686 userland. The motivation for me was to be able to build both i686 and x86_64 packages on my primary system, because the access to the machine I have an x86_64 install on is becoming limited. I could have just reinstalled with x86_64, but I use wine regularly (I need MS Office for work, among other things) and I really dislike needing multilib or a chroot to run this in x86_64. Also, I did not want to do a reinstall on my primary production system (but other “risky” changes are fine…). Fedora had planned to ship an x86_64 kernel on 32-bit x86 with Fedora 11, but decided against it, so there is probably some issues with this setup.

The advantages I see of this setup are:

• The ability to use more than 4GB RAM without compiling (a reportedly slower) PAE kernel. However, individual processes will still have the 32bit memory limitation.
• Being able to create chroots for building both 32 and 64 bit packages.
• There is no need for ugly multilib packages for wine, skype or whatever 32bit only software you need.

The last one is the only real advantage over running pure x86_64. The disadvantages are:

• Not being able to automatically update the kernel and modules using the standard Arch repos.
• Some configure scripts use uname to figure out which architecture to build for. This is worked around by using linux32.

I work around the update issue by creating a local repo containing just the kernel and its firmware and having this automatically updated when I rsync my local package mirror. I suspect that the second issue is probably a factor in Fedora backing out this change as it would not be very user friendly (although I have no confirmation of this).

Actually achieving this setup is easy. Just download the x86_64 version of the kernel26-firmware, kernel26 and any additional drivers you need and then install them. Reboot and marvel as the output of “uname -m” says x86_64! It is now several days since I did this and I have noticed no issues, although I have not done any major package building in that time.

I had to make a couple of changes to get the Arch devtools to run correctly (using linux32 when appropriate within i686 build scripts, using /etc/makepkg64.conf and a separate package cache for x86_64), but the changes are very minor. One day I will look into patching these properly as it would probably be useful for people wanting to use these on a pure x86_64 system to build i686 packages.

Running out of space on /usr or just want to slim down your system? In Arch (or any distro using pacman as their package manager), you could just use “pacman -Qi” and parse the output. But that does not really tell you the “actual” amount of space required for a package. e.g. on my system skype is the only package using qt so having skype installed costs me at least 105Mb (~20Mb for skype and ~85Mb for qt).

I try to address this with a python script called bigpkg. It works by calculating the size of a package as its actual size plus the sum of its share of its dependencies (for each dependency, add the dep size divided by the number of packages needing that dep).

This was the output of the top 10 packages on my system:

...
deluge: 81306.0K
jabref: 83594.0K
wine: 85750.0K
r: 88727.0K
kernel26: 99609.0K
skype: 106191.0K
acroread: 150832.0K
neverball: 191562.0K
texlive-bibtexextra: 206465.0K
openoffice-base: 370234.0K


It is not perfect (e.g. jabref is one of two packages on my system using openjdk6 so removing it will not save 83MB as the ~75MB of openjdk attributed to it is still needed by the other package.) But gives a fair indication of what is taking up your hard-drive space.