Allan McRae

SDL_mixer is my least favourite piece of software today and is being very closely followed by SDL_image. A few updates that should have taken me about half an hour today ended up taking over three hours due to bugs in these packages.

I had a bunch of SDL related packages (sdl_gfx, sdl_image, sdl_mixer, sdl_perl) to update. These are usually fun, because they require extensive game playing for testing! My first point of testing is always Chromium B.S.U. Everything looked good there so I upload the updated sdl_gfx and sdl_image packages. Now for the second line of testing: Frozen Bubble. Interesting… SDL_mixer has an soname bump despite being an update from 1.2.9 to 1.2.10. Stranger things have happened (heimdal likes slipping soname bumps into minor version releases). So a rebuild of many other packages is in order. Rebuild frozen-bubble and try again…

FATAL: Couldn't load '/usr/share/frozen-bubble/gfx/loading.png' into a SDL::Surface.

Hmm… looks like an SDL_image issue. I can confirm this using some other games too. It turns out the SDL_image 1.2.9 release is very broken; just not broken enough to break Chromium B.S.U. So much for my extensive testing… It appears fixed in upstream SVN, but I am feeling lazy and just downgrade it while waiting for the new release that appears to be due in the next day.

Now, try Frozen Bubble again. Still no good…

[Graphics..........] [Sound Init] at /usr/games/bin/frozen-bubble line 312


Looks like the SDL_mixer update is causing issues. That may not be surprising given the soname bump. This is confirmed by starting the game with the --no-sound option. While searching for a fix, I discovered that the soname bump was an accident. Apparently, this has been fixed, but either the source was missed or something else was going on. The good news is, I do not have to do a big rebuild now (but the rebuilds I had already done were a waste). The bad new is, SDL_mixer is still broken… The change-log in SVN lists this:

Fixed bug loading multiple music files

Pull that patch and we can all play games again! Luckily, not all updates are that painful.

Edit: updates are now available for both SDL_mixer and SDL_image that fix these issues.

I do not think I will be using Chihiro Fansubs to watch To Aru Kagaku no Railgun:

The grass is a deeper shade of green across the other side of the fence.

Close and somewhat better that the original in many ways…

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.