Allan McRae

With the toolchain rebuild for binutils-2.20, I decided it would be good idea to use package splitting to create the gcc and gcc-libs packages as that saved me a lot of build time. While I was at it, I split gcc-fortran, gcc-objc and added a gcc-ada package.

That was when I ran into fun… Once I had built gcc with package splitting, I decided to attempt to rebuild it again with the new packages just to make sure everything was OK. Turns out, that was not the case. The C pre-processor was failing basic sanity checks and that falls into the category of “not a good thing”.

So I compared the list of files in the split packages to the originals as I made quite a few changes and could have plausibly “lost” some files. Everything seemed as expected. The only real difference was the “fixed” include headers were gone. This was also expected as the previous PKGBUILD had this line:


# Remove fixed includes, either no need for them, or they're not complete
rm -rf ${pkgdir}/usr/lib/${CHOST}/${pkgver}/include-fixed/*


That comment is quite correct as the gcc packages are built in a minimal chroot and all headers in the packages within the chroot are in no need of fixing. However, earlier in the package splitting process I noted that the fixed includes directory was actually in /usr/lib/gcc/$CHOST/... and not /usr/lib/$CHOST/..., so I fixed the PKGBUILD.

And here was the problem… As of GCC-4.3, the compiler installs a limits.h file into the private include-fixed directory and that directory is an absolute requirement. So, the unnoticed bug in the PKGBUILD actually was saving us from a far more severe bug and had been for some time.

The only conclusion I can draw from all of this is we should never strive for bug free code as some bugs are good!

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.

Big dust storm in Brisbane today. Some reports have visibility down to 200m, but all I know is the CBD is no longer visible from my work, which normally only happens during the worst thunderstorms. Being inside does not stop the dust annoying your throat and eyes…

Not as exciting as in Sydney where the dust in combination with sunrise caused everything to turn red and Mars like.

Photo source: Brisbane Times

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.

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.

…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--;

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

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.

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…

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.