Allan McRae

I have recently been thinking about a Linux distribution providing “vanilla packages” and what this really means. The basic idea is simple – provide packages as upstream released them. In practice, this is an impossibility (for reasons I will cover below).

Firstly, lets cover the reason for providing vanilla packages. And I use “reason” singular deliberately, because I think it comes down to a single point. The software developer knows their software better than you do. Your patch could unintentionally introduce a security issue – it has happened before… Or you could introduce a new feature that is then introduced by the developer in a different and incompatible way in the next official release. Also, any bugs that are found in your modified piece of software will need to be triaged in an unpatched version of the software in order to report the issue upstream.

So, in an ideal world, we would just run the equivalent of “./configure; make; make install” and all software would install perfectly. But the world is far from ideal… I will cover two points across two posts: firstly patching, followed by configure options and dependencies.

Patching software is a necessity in any Linux distribution. I am only considering rolling release distributions in the discussion below, so that removes backporting fixes and features from newer versions of a software package. So, what patching is minimally required:

1. Patches for build issues
2. Patches for security issues
3. Patches to fix major software features

I am completely ignoring patches released by upstream as part of their update process. For example the Linux kernel provides a large patch that updates from their x.y.0 release to x.y.z. Bash releases a patch for each minor update, so bash-4.2.042 requires applying 42 patches… These are obviously required patching and are fully sanctioned by the developer so do not deviate from vanilla.

It should be fairly obvious what patches for build issues are… the software will not compile for some reason so you need to do patching to fix that. A piece of software is almost never tested in every single environment before release and, even if it was, updates to other pieces of software can cause build issues. This is particularly common with gcc updates which have become progressively stricter on which headers needed included for a function. Even worse, a software developer might release with the “-Werror” flag enabled by default, meaning any new warning will result in a build failure (I do not have kind words about software developers that do that…). Then there are more complicated issues involving a library update with API changes requiring much more extensive fixes. While adding a single extra include really does not require upstream approval before applying, even that should be forwarded upstream.

Security issues are an important part of patching for non-rolling release distributions. However, new versions of software are usually released whenever a security hole is found, so rolling release distributions only need to update. Again, just grabbing a patch from anywhere on the internet and applying it is not a good idea – I have seen this actually result in a larger security issue than the original.

The final category of patches are those that fix major software features. For example, if an IRC client has a bug preventing it connecting to any channels, firstly shake your fist at the developer and tell them to do some testing before release, and then patch it. If there is a typo in the help output, file a bug or submit a patch upstream, but there is no need to patch it. The guiding principle should be something like “if this is the only issue found in the software, would the developer consider making a new release?”. The answer to that question “yes”, then it will be “yes” to provide the patch.

One guiding factor that can not be stressed enough here is that all patches should be approved by upstream. The best situation is if upstream have committed the patch into the version control repository – preferably on the branch for the version you are using so no mistakes can be made back-porting. Failing that, a post on a mailing list or bug tracker by one of the main developers of the software approving a patch is acceptable.

Of course, much of this is subjective. Is that broken feature big enough to patch? Does this bug constitute a security issue? If upstream is rather unresponsive at the moment, should I apply this fix for a security bug? Is this build fix minor enough that I do not need to wait on an upstream comment before applying? Given it is hard to formulate these ideas into precise rules, I think the answer becomes one of how strict the packager is. I was far more likely to include patches when I started packaging for Arch Linux than I am now. So maybe it is not how strict the packager is, but rather how grumpy…

And… do you know how easy it was to convince a Manjaro developer to ignore their entire stability scheme and push a known broken package into their repos?

The firefox-18-1 package in Arch Linux was known to have an issue with language packs. So all non-English users would have their interface changed into English. The behaviour was the same for dictionaries.

Users were complaining about this issue on the Arch Linux mailing list and forums. But make a comment about it and the entire stability mantra of Manjaro Linux is ignored and the package can is moved into the Manjaro stable repositories (that is about 8 hours after my posting).

So even known usability issues with packages, which is now fixed in the Arch Linux package firefox-18-2, do not get caught by Manjaro’s stability testing. I do not think I have any need to feel threatened…

Edit: It appears I misunderstood Phil’s comment in the last post exclaiming “Don’t know what the fuss is all about ?!?” with link to packages moving between repos to mean he moved it to the stable repository. It turns out it only moved to their testing repository. So, users are still exposed to security issues, which is what the fuss was about. And it is only the move from “unstable” to “testing” that showed a lack of the claimed quality control. So apologies to Manjaro – I only showed you have packages with security issues and the stabilization stage controlled by your developers is worthless.

I feel like having a rant today… so nothing particularly unusual there. But after reading yet another post saying:

I used Arch for two years and it was perfectly fine until one day when I updated and it broke my system. Now I have been using Manjaro for a month and it is completely stable.

I have found what to rant about! Is it just me that notices the issue with that statement?

I have no issue ranting about Manjaro because every time I read their forums I see one of their Core Team being less than congenial regarding Arch – but I suppose they have to be given one of the main selling points of their distribution is they can fix the Arch Linux updating “mess”. Also, the defensiveness of their community to any criticism and the amount of self congratulations for being a Manjaro user astounds me – and I spend a lot of time in the Arch forums and IRC channel where the community are widely considered to be elitist pricks (with me being no exception, as this post will plainly show).

For those who do not know how Manjaro works, I will paraphrase this post. The Arch stable repos are synced into Manjaro Unstable on a roughly daily basis. They sit there for 1-2 weeks before being declared stable and moving to Manjaro Testing. Then their test squad declares that stable enough to move to Manjaro Stable, about 3-4 weeks after the packages arrive in Arch Linux.

And this is the issue. There is four weeks until Manjaro users get package updates. That is still a lot quicker than a non-rolling release distribution I hear you say, but it ignores one of the fundamentals of a rolling release distribution. Security fixes come with a new software release. On a fixed-point release distribution, security fixes are backported into your out-of-date software versions to maintain stability. On a rolling release distribution, you just release the newer version of the software that comes with most security fixes (some backporting from the upstream VCS is required if a release is not made).

That means, Manjaro users are vulnerable to security bugs for around a month after Arch users are safe, unless of course the Manjaro Core Team monitors every package and pushes those with security fixes. How many packages in a distribution? Arch Linux has >6000 in its binary repositories. I suppose it is not impossible to monitor that many packages, unless of course your Core Team consists of three people. And given those three people provide five variants of their installation ISO (net install, XFCE, KDE, Cinnamon, MATE – with OpenBox and E17 on the way…) and provide a series of kernel packages and systemd… Things are looking bleak.

And so, Manjaro users are stuck with packages having security issues for a while. I’d assume the big ones get through quicker. Although their firefox package has not been updated to version 18 yet, which fixes 21 security issues – 12 of which are marked critical. In fact, firefox version 18 has not even made their Unstable repo as I am writing this…

Lets say Manjaro had the man-power to monitor all updates in Arch Linux for security issues. Could they be brought to the Stable repositories more quickly? Maybe… But remember Arch Linux rebuilds against new versions of libraries with soname bumps all the time and our toolchain gets updated very quickly after any upstream release. So any security update built against new libraries or with a new toolchain version require those components moved too. And they are the types of updates that could introduce stability issues.

In the end, I think the idea behind Manjaro – rolling release at a more relaxed pace – can be achieved. I am not entirely familiar with these distributions, but I guess that is exactly what apotsid and LMDE achieve. And they start form Debian Unstable, which is reportedly far more of a minefield than Arch Linux.

It is entirely possible that I am getting old(er) and grumpy(er), but I found this years anime selection very lacking. Lowlights included a series about anthropomorphized guns and one about licking drool left by another student resulting in a drool addiction.

As in previous years, I only consider anime that have finished their run during 2012. So any series that started this year and has not finished yet is not included. Also, I do not do real reviews, but just make my opinions known on a selection of anime that I thought would be interesting enough to watch.

Anime of the Year

Another
(TV Series, 12 episodes)

Admittedly, all horror anime series are fairly predictable and much of this is no exception. So how did this get my “Anime of the Year” stamp? Because when it killed people, it did so very gruesomely! That is enough when there is a lack of better choice… The beginning of this series was so slow that I was considering moving on – I am really talking up the winner this year – then something happened and I had to immediately see the next episode. Still, it is a sad year when an anime with a beach episode (in a horror series, really?!) makes it to this not-very-coveted-at-all spot. And I made it through this without using “another” in a pun, which was a struggle…

Recommended

Fullmetal Alchemist – The Scared Star of Milos
(Movie, 110 minutes)

Side story to FMA: Brotherhood, which I gave Anime of the Year in 2010. If you like the series, you will like the movie although it really does not add much as it is essentially a long episode.

Kids On The Slope
(TV Series, 12 episodes)

There was not a chance of me skipping this anime given the director and who provided the music. This is despite it really not being a usual choice for me as, unlike Watanabe’s usual series, this is appeared relatively slow moving drama. However, I get the impression of there being quite a lot of content when I look back on the 12 episodes, so it can not have been that slow. I think the slower points were a needed tool to give room for the characters to develop. I am no expert on jazz or 1960s Japan, but I hear only good things about the attention to detail in both aspects. A surprisingly good series for something I went into with a mildly negative outlook.

Average

Fate/Zero
(TV Series, 25 episodes)

At one stage I was lacking much to watch and I remembered Fate/Stay Night being quite good. But watching this reminded me why as a rule any series based on a video game is bad. Lines like “Sabers parameters are particularly high. Most of them appear ranked A.” are just awful. There was enough dumb action to get beyond that.

Humanity Has Declined
(TV Series, 12 episodes)

I try watching at least one thing that seems a bit weird each year and here it is… My main issue with this series is that there was not enough of it. Most story-lines were two episodes long, which makes a 12 episode series too short to really achieve anything. Saying that, the short stories really do not link together very well, so extending it further could have made the series too disjointed.

Kokoro Connect
(TV Series, 13 episodes)

Everything I saw here made me thing this was a Melancholy of Haruhi Suzumiya wannabe that tried hard to be different enough. The body swapping was entertaining enough and I was amused at one of the girls saying she was getting good a peeing standing up. But then the ideas for where to take the series ran out. Well, they obviously did not run out, they were just bad.

Last Exile: Fam, The Silver Wing
(TV Series, 23 episodes)

Another sequel that yet again did not live up to the original. Part way through this I got the intense feeling that I did not understand the end of the original, so I went back an watched the final episode. That did not help… It turns out there is a manga that covers the gap between the two stories, but I guess most people (at least outside Japan) have not read it. But we do get a history lesson at the end of this series. That is not good for a series that really relies on the greatness of the original.

Sword Art Online
(TV Series, 25 episodes)

This was my pick of the “this video game just got real” genre for the year – there were quite a few series in it. How it approached the long-term effects of being stuck in a virtual reality world was quite interesting. And the over-the-top battle scenes were absolutely fine, because this is a game. And then there is the second half. Not only was the ball dropped, it was… (I got stuck thinking of a good enough hyperbole to use here). In fact, just don’t watch the second half; the ending of the first arc is just fine.

Sub-par

Bodacious Space Pirates
(TV Series, 26 episodes)

So… I watched this entirely because it had “Bodacious” in the title… Had I done a bit of research and seen that it is based on a light novel called “Miniskirt Space Pirates”, I probably would have reconsidered. Because this is the future, pirating is all about cyberwarfare and so we get to watch people type fast. To be fair, there is also lasers to counteract that boredom. And because the series is so seriously slow in places, there is plenty of boredom. One thing that did surprise me – well, because this is a bad anime and usually such an “opportunity” would be taken… – is that miniskirts do not lift up in zero gravity. Probably for the best given the ages of the characters.

K
(TV Series, 13 episodes)

I read this was a bit like Durarara!! so I took a look. I need to find that review, identify its author, buy a plane ticket, knock on their front door and tell them NO! Although at one stage I saw artwork that was similar and there was a large number of characters, any similarity ended there. The final episode is good and potentially could have done some redeeming if the second series was not announced in the middle and essentially gave away part of the ending.

The Future Diary
(TV Series, 26 episodes)

Only one can survive and there is no doubt which one it will be even though he is absolutely useless. His one advantage is the writers have no qualms using many, many contrived leaps of logic to help him. The one redeeming feature of this series is that it does teach a valuable life lesson: “Don’t stick your dick in crazy”.

And that is it for the year as far as I am concerned… Technically Hellsing Ultimate fits my criterion of finishing in 2012, but I doubt I will get ahold of the final OVA for a while yet – not that waiting is an issue with that series (the first OVA was released seven years ago). At this stage next year’s list looks to be improved, with the four series I am watching now (Space Brothers, From the New World, Psycho-Pass, Blast of Tempest) all worth a look at this stage.

Final collection of links for the year…

Software related:

• More posts on secure boot
• i386 support was dropped from the Linux kernel, which immediately sparked a discussion about dropping it from GCC (glibc has not for a long time)
• After several moths of discussion, eudev was officially announced
• A new release of the GNU C Library was announced (and is in the Arch repos)
• As was the release of LLVM 3.2
• A summary of C 2011 standard implementation status and why GNU should allow it
• The Wikipedia visual editor went live

Thinks happening in other Linux distributions:

• The Linux Format comparison of Linux distribtions (mentioned a few months back) was made available on-line
• But should OpenSUSE Tumbleweed have beaten Arch?
• A stroy about the history of the HURD
• Debian’s m86k port got some love
• Chakra fixed the bug I found in their installer
• A Manjaro demonstrated why automatically updating config files is bad – read the command they run for good entertainment value…

It was a month for some good rants:

• RMS does not like Ubuntu’s spyware…
• But he is childish, or maybe not!
• Anonymous bug reports are fun!
• GnuTLS is moving away from GNU and the maintainer of sed and grep feels the same way
• I am not sure if I understand what a Manjaro Linux release means

And because it is the end of the year:

• We moved ever so slowly into the future

According to Distrowatch, there are eleven “distributions” “based” on Arch Linux. I use “distributions” in quotes, because some are far less of a distribution than others and “based” gets quotes because some are so based that they are really Arch Linux in a poor disguise…

I have seen a bunch of new release announcements for several of these distributions in the last few days, so I thought I would take some for a spin and see what I am missing out on.

All distributions were tested in VirtualBox with a 128GB disk and 2GB RAM.

Contender #1: Chakra – 2012.12 Claire

The Chakra Project is my #1 contender as it is a real Linux distribution. They do use our PKGBUILDs (sometimes too directly…) but they rebuild everything for themselves. Chakra also has quite an interesting take on the rolling release model, opting for a “stable” core of the distribution and rolling release userland. So toolchain updates are rare, but the newest KDE will be packaged within days. I have issues with their “stable” core, because stable means no updates at all. Even minor bug fix updates are not considered and I am sure there is no backporting of any security fixes either as their team is too small to handle that. For example, I would not be running pacman-4.0.2 or even an unpatched pacman-4.0.3 as my distributions package manager. Another thing unique to Chakra is the pure KDE set-up. Any popular software that is not Qt based (e.g. firefox, GIMP) is supplied in a bundle. I find these a very bad idea, as many of the same libraries are on your system multiple times but in separate bundles, and it also appears that these are easy to break and under-maintained.

Onto the installer… Chakra wins points for being the only pure graphical installer out of the distributions I consider here. I did a review of the installer early in 2010 and there seemed a complete lack of improvement. The Live DVD booted fine and welcomed me with a window that pointed out the difference between Chakra and Arch, and noted that pacman is not designed for a GUI frontend (debatable…) so it will be replaced one day. Starting the install gives three screens worth of install notes which no-one has ever read and if anyone did read them, I am confident they did not care that their website is being redesigned. The partitioning took me to an external tool (KDE Partition Manager), which I actually found rather difficult to use. It took me several attempts to get everything set so that the installer would let me continue.

Once I finished the install, I rebooted… to a prompt. Whatever autodetection is done to get the KDE session up a running post-install had failed in VirtualBox. So no further review was done.

Contender #2: CinnArch – 2012.12.21

I had heard good things about the Cinnamon desktop, so CinnArch was my next choice. This distribution is Arch Linux – when I look at the package information for glibc, I see that I packaged it. The only difference is that an additional repo is provided with the packages needed for Cinnamon desktop to run.

The installer boots to a nice live system. There is two installation options – “CLI installer” and “Graphical Installer” but the latter is not selectable so “CLI” it is… In this case, CLI means an ascii-graphical menu driven installation environment that was easy to follow. The only steps that I found amusing was finding the fastest mirror to install from, which (with only slight exaggeration) took longer to complete than downloading the packages from the slowest mirror would have. And then on with installing the packages. Or not… It turns out that the installer detects I am using VirtualBox and tries to install the virtualbox-guest-modules package, which currently has a broken dependency and so can not be installed. There is no way to skip this that I could find.

So lets play around in the live media to see what might have been. It turns out that CinnArch provides two repos: cinnarch-repo and cinnarch-core. I could not find the justification for requiring a second repo. The repo looks fairly good on a quick glance, with all packages signed and a keyring provided. Theoretically, you can just enable that repo and install cinnamon from there, but I could not find where to see a list of keys that the developers use that would enable me to install the keyring package and then verify the rest of the packages. One thing I was concerned about was the filesystem package that was being provided for reasons I could not ascertain. The biggest issue with providing a repo for Arch Linux is that you need to keep up with our rolling base. That means your repo needs to have rebuilds available when we push (e.g.) a library update with an soname change. Providing an unnecessary filesystem package seems to only make things difficult for them. This was also my first time seeing the Pacman-XG GUI for the pacman package manager. That is enough said about that…

Contender #3: Manjaro – 0.8.3 XFCE edition

I was not expecting much from Manjaro given I had read this review of a previous installer. But given the “success” of the last two distros, it has a chance… Some things from that review had not changed – in the live environment there is still the unnecessary password of “manjaro” for both the user and root. And I was not endured by the green colour scheme or the logo which is used for the “start” menu. But to give Manjaro credit, I successfully installed using the old style Arch ascii-graphical install, which was easy for those that are use to that. Reiser3 as the default filesystem still confuses me.

So what do you get from Manjaro? It seems to be Arch delayed plus extras. The idea is that the Arch repos are delayed reaching you for a few days while everything is sorted out to give you an easy upgrade. This happens by adding a package manjaro-system which is always upgraded first and runs a script that automatically handles any manual intervention that would be required on a pure Arch Linux system. As a heads up, this uses a feature of pacman called SyncFirst that is removed for the upcoming pacman-4.1, so they may need to rethink their entire system soon.

The first difference I noted was it ran a 3.4.24 kernel, so that have held that back from being updated to the newest release, but at least it is the newest 3.4 series release. Looking at the glibc package once again, I am the packager, but it is a repo called [platform]. The Arch [extra] and [community] repos appear to be used as-is, so the need for [basis], [platform] and [addon] repos to replace our small [core] repo is strange. Also, this was the first time I had ever heard of a GUI for pacman with the imaginative name pacman-gui. It allows you to run pacman -Sy, which just refreshes the databases – a crazy thing to do without immediately updating in a rolling release distribution that does not provide multiple versions of a library. And it is not much of a GUI either, as it just launches a terminal that runs the pacman command you just clicked. There was also a LibreOffice installer that called pacman in the background.

The Winner?

Sadly, I do not think there was any winners today. Chakra had the most polished live environment, but failed to boot to the desktop. CinnArch failed through no fault of its own, which is sort of a fault of its own for not being a real distribution. Manjaro installed, although I saw nothing to make me want to recommend it.

The may be the most painful statement I have ever made… but ArchBang might be the winner!

Edit: Twelve hours later and the bug on the Arch end preventing the CinnArch install has been fixed. CinnArch installed and booted to the desktop without an issue.

I was going to add a pastebin to my site (for reasons I can not determine other than “because”), but that ended up being too much effort. Then I remembered that GNU Source Highlight can output HTML… So here is my pastebin client in less than ten lines of bash!

#!/bin/bash
 
file=$(mktemp ~/web/paste/XXXXXX)
 
[[ ! -z "$1" ]] && lang="-s $1"
 
cat - > ${file}.in
source-highlight -i ${file}.in -o ${file} ${lang}
rm ${file}.in
 
lftp -e "put -O /dir/to/paste ${file}; bye"
     -u user,password sftp://example.com
 
echo "http://example.com/paste/${file##*/}"


Done. Just use “foo | pastebin” to send the output of foo to the web. Or for files, use “pastebin < file". If auto-detection of highlighting style is bad, just use "pastebin <lang>" with one of the supported languages. The seemingly wasteful cat is because GNU source highlight can not autodetect the style from a pipe if it is not provided.

One fairly common criticism of the pacman package manager is that is very slow due to not using some sort of binary database as its backend. I found suggestions to use sqlite dating back to 2005 (although I am sure they go back further) and mailing list activity peaked around late 2007. Speed is one of pacman’s main features – and it beats the competition by a wide margin according to Linux Format – but I guess people want it even faster.

The problem is that we use a filesystem based “database” where each package has its information stored in multiple files. This means that we can get fragmentation of our “database” and the reading of all these files from the filesystem can be quite slow. Usually most of this is cached by the kernel after the first read so speed improves markedly after the first usage.

This was improved a lot in the pacman 3.5 release (March 2011). The sync databases started to be read directly from the downloaded tarball and the local database had the “desc” and “depends” files for each package merged into one file. This increased the speed of reading from the sync databases massively and was a reasonable improvement to the local database too.

So the local package “database” could be improved by reducing it to one or a few files. But every time I think about changing it, I am reminded why I like the plain text file format. I was updating a reasonably out of date computer when I had an issue with the python-pygame package being renamed to python2-pygame. All packages needing in the Arch Linux repos were rebuilt with the new dependency name, so it did not need a provides entry. But my solarwolf package from the AUR still depended on the old name:

$ pacman -S python2-pygame
resolving dependencies...
looking for inter-conflicts...
:: python2-pygame and python-pygame are in conflict. Remove python-pygame? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: solarwolf: requires python-pygame


As we have a file based database, adjusting the dependency is easy without rebuilding the package. Just open the relevant file and edit away (or use sed…)

$ vim /var/lib/pacman/local/solarwolf-1.5-5/desc


Now I can see my local database has an issue using the handy testdb tool – solarwolf depends on python2-pygame, but that is not installed.

$ testdb
missing python2-pygame dependency for solarwolf


But now I update as usual, installing python2-pygame which removes python-pygame, and my local pacman database is fully consistent.

I am sure all of this would still be possible if the database was in some other format, but it would have required more tools than a simple text editor. Of course, most people should never need to edit their local database, but I have introduced changes to it several times during pacman development and I consider being able to easily fix or revert these in the category of a “good thing”. And yes, I develop and test directly on my production system…

Of course, it is better to use a real database in performance critical situations. But pacman really does not fall into that category.

Software related:

• Fedora 18 was delayed until next year
• GNOME dropped fallback mode but the “old-style” GNOME look may appear via extensions
• Another month, another udev fork – is this number three? This time is is done by people at Gentoo and is called udev-ng… no, its eudev. But is that fork any good? Some opinions…
• glibc-2.17 is in freeze and it looks like it will be a relatively easy update
• A “new” package manager – Guix – which is just Nix with some Guile thrown on top…
• A post about Upstart working in Debian – speed comparisons are the most interesting thing there
• And while we are speaking of upstart, what does Lennart think?

And things that entertained me:

• This song was stuck in my head…
• Which lead me to some great ukulele playing (including weirdness such as this)
• And that reminded me of a great comedy sketch

Another month, another bunch of links…

Software and release announcements:

• openSUSE released RC1 of their 12.2 release on the ARM architecture. RC2 has made an appearance too!
• Speaking of ARM, multiplatform support was merged into the kernel.
• There was probably earlier releases, but this was the first time I noticed the Cinnarch distrolet.
• There is a fork of Arch Linux initscripts, which I do not recommend given the lack of understanding of bash shown by some of the changes…
• Wayland 1.0 had a fairly quiet release announcement.
• I “discovered” the pkgng package manger for FreeBSD. I need to look at it in detail to see if there are ideas to steal for pacman.

There were many posts about UEFI and secure boot:

• Although most of them came from Matthew Garrett…
• The Linux Foundation made an announcement too.

Other collected Linux-ish links that interested me:

• Ubuntu has a donation screen shown on the way to the download. I accept Amazon.com gift vouchers!
• A tutorial on how to remove watermarks in GIMP.
• Details of the systemd journal file format.
• A report on issues with major updates in Gentoo.

And some fun stuff…

• Anime News Network’s Fall 2012 preview guide.
• I am enjoying xkcd’s What If – especially this one
• The Handbook of the Birds of the World is being adapted into an online version.
• My idea got made into a cartoon! Well… sort of… not really… But I am mentioned.