Ada Compiler (GNAT) Packages For Arch

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.

A Glitch?

Walking to the bus stop from work today, I saw a ginger cat walk past some construction materials where building renovations are occurring. Then I looked away and when I looked back I saw the same thing again. That made me wonder if it was the same cat or a different cat. We all know:

A deja vu is usually a glitch in the Matrix. It happens when they change something.

That forced me to have a quick look to see if there was two cats. I could only see one, so that is a bit concerning. Then again, I did not want to seem like some weirdo breaking into a construction site to really check it out. I guess we will never really know… but it would be cool to know kung-fu.

I Do Not Use Twitter…

…but today I finally had something inane enough that I thought the world should know:

The lid from a Bundaberg Diet Ginger Beer is surprisingly easy to staple through with an everyday office stapler despite being made of metal.

That is right! Unfortunately I do not make amazing discoveries such as this on a regular basis, so a twitter account would be wasted on me. But never fear… I will keep you updated right here.

readership--;

New PKGBUILD syntax options with pacman-3.3

With the pacman 3.3 release expected in the coming weeks, I thought I would write about some of the new features that have been added to PKGBUILDs.

The most common change people will make in their PKGBUILDs is to add a package() function. This limits the of fakeroot to only during the file installation steps (so it is not used during the build process). Using fakeroot only during the install stages is considered a “good thing”, but this also provides a workaround for some bugs in fakeroot that can cause issues while attempting to compile a package. A partial example:

build() { cd $srcdir/$pkgname-$pkgver ./configure --prefix=/usr make } package() { cd $srcdir/$pkgname-$pkgver make DESTDIR=$pkgdir install -Dm644 $srcdir/license $pkgdir/usr/share/licenses/$pkgname/license }

Note the “cd” step is required in the package() function as makepkg currently does not remember what directory was being used between the build() and package() functions. The package() function is entirely optional, so all PKGBUILDs without one will continue to work as they always have.

The other main feature addition to PKGBUILDs is the ability to create split packages. In Arch Linux, this is useful for packages that are split due to providing separate packages for libraries and binaries (e.g. gcc) or where documentation is too large to justify distributing together with the main package (e.g. ruby). The Arch KDE-4.3 release will also use package splitting, as many lesser used components pulled in a large number of dependencies and made an unsplit KDE install very heavy.

Creating split packages is rather simple. All you have to do is assign an array of package names to the pkgname variable. e.g.

pkgname=('pkg1' 'pkg2') pkgbase="pkg"

This tells makepkg that it is creating two packages called pkg1 and pkg2. The pkgbase variable is optional, but can be used to hold (e.g.) the upstream package name and is used by makepkg in its output. Each split package requires its own package() function with name in the format package_foo(). e.g. for the above pkgname, the PKGBUILD would have functions package_pkg1() and package_pkg2(). In these functions, the use of the $pkgdir variable is mandatory as it is no longer equivalent to the deprecated $startdir/pkg. All options and directives for the split packages default to the global values given within the PKGBUILD. Most variables can be overridden within the package function. e.g

... depends=('glibc') makedepends=('perl') ... package_pkg1() { depends=('perl') } package_pkg2() { ... }

The pkg1 package will depend on perl while pkg2 does not override the depends array so will depend on glibc. As a general rule, almost every package in the split packages depends array should probably be present in the global makedepends array.

There are several other useful features added to makepkg such as improved handling of info files (automatic removal of $pkgdir/usr/share/info/dir and compression of info files) and being able to specify LDFLAGS in makepkg.conf. Check out a detailed list of changes in the NEWS file in pacman git repo.

For those that want to try out makepkg before the pacman 3.3 release, you can grab a copy of my makepkg-git package which installs alongside the current version of pacman.

Edit – clarified PKGBUILD directive overrides for split packages and added an note about makepkg-git

Expectations Of Services Provided For Free

It continuously amazes me… the number of people who expect something done for free and want it done now. The more I think about it, the more I wonder if it is a consequence of the internet era as I struggle to come up with non-internet based examples.

What started me on this rant was a comment I saw in the while investigating whether a new episode of an anime series I am watching was released by the fansub group yet. It had been a while since the last release, so I looked at the comments of the previous episode to see if there were any clues to when more releases would be made (I know for a fact the next two have been translated). To paraphrase one comment: “Why are you so slow… maybe you should find something else to sub? There’s already quality subs out there that are getting released at a stable pace, so why bother?“. My initial thought was that the poster put the solution to their “problem” right in their comment. Now consider that this is a one-woman subbing group (well, there is a timer and a quality checker for this series) and she has just had final exams and a fairly serious illness according to her Twitter posts. I bet that if you were not thinking “wanker” before, you are now. This behaviour is not just restricted to this particular subbing group; I have noticed similar posts in the comments section for almost all series I am currently watching.

I see similar things all the time in the Arch Linux forums and bugtracker and even my email inbox. I can guarantee that every time there is a kernel release, there will be a post asking when it will be packaged within a day. What I am finding amusing is that 1/3 of the first page I get with the “Show new posts” link is threads asking for help with issues caused by the 2.6.30 release. But it is sad that the overlap of the users demanding the release and those complaining about it afterwards is not as big as it is in my dream world. Although, going back through old posts, there was definitely some overlap when KDE-4.x was released.

I had plenty of emails telling me of the immediate need to update ruby to the 1.9 branch. In the end I gave in and pushed the release to [testing], breaking gvim in the process. I got no angry emails about breaking gvim, which leads me to conclude gvim users > ruby users or (more likely) [testing] users > ruby users, on some scale where being greater than is a good thing. Those in the overlap of those groups are questionable… Similarly, I have had a number of emails telling me that python-3.0 is out and it is a “production release” (to somewhat laughably quote one user). That means that Arch is not keeping to its rolling release mantra and the python package needs updated. NOW! I used to reply with an email asking for patches for every package in our repos so they would either run with python-3.0 or would use python-2.x when the main binary was located at /usr/bin/python2. I never got a response.

Now I just add people who complain to a filter list so I will never see another email from them. This makes me immensely satisfied.

Spam, Spam, Spam

I had turned off the need to moderate comments before their appearance on this blog as an experiment to see how long it took for spammers to start posting. Turns out, it was not very long… but taking 25 days is still slightly longer than I had expected. So comment moderation is turned back on.

While most spam is obvious posting of links to websites, I just do not understand some of the spam that I have received. One IP address (which is well know for its spam), posted messages like “The best information i have found exactly here. Keep going Thank you” and “Hi, very nice post. I have been wonder’n bout this issue,so thanks for posting“. Do a google search for those phrases and note how frequent those exact comments are. What is strange is that the “people” posting these comments seem to have nothing to gain, at least initially. They listed website their website as google.com and their email address is not shown so no-one can reply to them. I suppose they want to get through that initial moderation phase so that they can posted unhindered crap in the future. You have got to admire their determination…

Using An x86_64 Kernel On An i686 Userland

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.

Taking Moblin For A Spin

I thought I should take the Moblin v2 Beta release for a spin to see what all the excitement is about. While most distros would run fine on a netbook with little modification (e.g. The EEE repo for Arch essentially just contains a kernel), Moblin started from scratch and provides an interface specifically designed to get the most out of netbooks. Also, it is optimized for Intel’s Atom processor, so should provide a boost to multimedia applications on those less powerful processors that netbooks contain (in particular optimizations for the SSE2 and SSE3 instruction sets).

I was intending to test the Moblin Beta (20090529) in VirtualBox as I do not actually have a netbook, but that is not supported yet. While the live CD will boot, the screen resolution is too small for the upper menu to fit and the functionality is severely impaired. It did boot and run well on my laptop (any computer with recent Intel parts should be fine), but I was limited to testing from the live CD due to lack of spare partition to install it on.

My initial impressions are all positive. The interface makes it easy to do what I would want to do on a netbook (browse the internet and watch videos). Connecting to wireless internet was simple and sound worked out of the box. The web browser and media players did their job. The concept of “zones”, rather than multiple desktops, also works well. I would not be expecting to run too many applications at the same time on a reasonably underpowered machine anyway. I would need more time to assess how useful “the myzone” actually is, but my initial impress is that it could use improvement.

A couple of things did frustrate me:

The inability to configure the top menu. I do not use Twitter or Last.fm so it would be good to get rid of the “status panel”.
The “myzone” page can only have its background customized. This seems an area where more configuration options would be useful.
I spent a lot of time looking for a shut-down button. It appears hitting the power button on the laptop does a shutdown (without a confirmation dialog…).
The lack of a system tray. An instant messager is a bit useless without one.

I am sure some/all of these will be addressed as the distro heads towards an actual release. Only not being able to configure the top menu and the lack of system tray are critical as far as I am concerned.

Overall, I will definitely consider Moblin quite favorably if/when I get a netbook.

Finding “Large” 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.

Posting (with) Drivel

It does not take long to realize that posting from within WordPress is not the most efficient process. For me, two posts was enough… So, the hunt was on to find a desktop application to post with.

Gnome Blog is in the Arch repos, but is a bit basic. The main feature missing for my purposes was the ability to add a category to posts.

A search in the AUR found Drivel. It has several useful features, including the ability to add a category to posts (however, only one per post and not tags), being able to edit recent posts and integrated spell-checking. Even better, its development is now being continued after a several year break.

Allan McRae

I love gluten

Author Archives: Allan